"[slides]" means there was stuff I didn't write down and one should refer to
the presentation slides for info.

-------------------------------------------------------------
IRTF/IETF AAAarch meeting 49th IETF   10-Dec-2000  San Diego
-------------------------------------------------------------

interim meeting in Jan/Feb

hope to have a roud of drafts submitted for rfcs by spring IETF 2001

Interlink <www.interlinknetworks.com> sponsored this room and the t-shirts.
 

Overview
 goal to figure out how to do AAA between apps, user orgs, with postulated "brokers" in the mix

 the lines between entities in the diagram rep SLAs and perhaps security associations

 the fact that these are SLAs are impt

overview examples
 combining resources
  qos + network access
  sip conns + netwk bandwidth

 muktiple authz
  distrib academic course admin

 b2b e-commerce stuff

tasks in AAAarch
 generic aaa server
  working on..

[see slides]

user authn
 (various aspects)
 

lots of related ietf stuff
 [see slides]

updated doc from -00 to -01

[see slides]
 

Policy Language: what do we need?
 gave examples of distinctions between "accounting policies" and
 "metering policies"

SLA seen as the "information base"
 drives the provisioning and config of the accounting environment.

Policy Parameters
 [see slides]

Future work & open issues

 derivation of policies from sla

 binding of user ids to sessions and accounting data is a key aspect, that's
 where the session id doc comes in.

AAA servers need to exchange and parse policies

 there's network environment issues wherein it isn't possible to have a policy
eval'd at a "remote" server.
  e.g. proxy environ.
  home agent not reachable
  [slides]

goal of the policy draft
 [slides]

Policies are..
 logical exprs
 actions attached to results of subexpr
 can do computations on varbs
 actions can send ? to ASMs (?)  [slides]
 

what possible ways to express policies?
 DNF disjunctive normal form
 ?
 XML
 Java
 

XML
 adv
  off the shelf parsers around
  lightweight
  supports strict def of policy language
 disadv
  xml is just a "preparser"
  extending the language means extending and spreading new DTDs (but this is
  just schema)
 

Java
 adv
  very versitile
  byte-compiled: optimizes execution time
  easily extendable
 disadv
  hard to check for validity
  security issues
 

analogy with smartcards
 (claim that smartcards provide many of the things we need for AAA)
 [slides]
 

Termination of distributed policies
 TTL, timeout?, loop detection, all the usual stuff in here
 

Problems left
 policy conflicts
  must AAA servers resolve them or must policy implementors?
  IBM Courteous Logic Programming?

 how to represent actions? AVPs?

 Policy Language - is v. open question

 termination of eval of distrib policies.
 

Strasner question: are you postulating all AAA servers are omipotent and
equally-capable. original policy doc acknowledged conflicts but didn't really
explore it.
 

main point is to try to align policy terminology

where is draft going?
 should be merged into policy working groups
 parts into other docs, specfic to authn
 

distrib policy
 intra-domain policy
  entirely within one domain
 inter-domain policy
  origs in a diff domain
 extra-domain policy
 [slides]
 

Ed ques: in ipsec there's a policy exch when setting up a tunnel -- there's
multiple levels of policy exchange going on or need to go on, some might need
to get negotiated, so this concept ought to be included into the terminology.
 

strasner: in ipsec one goes thru neg to construct a policy, and in other authz
settings, pol is already constructed and simply needs to be eval'd.
 

Application vs. generic policy
 generic
  eval'd by generic aaa server
 app-specific
  eval'd w/ help from ASM
 app proprietary
  opaque to generic aaa?
 

specific policy types
 e.g. registration, authn, authz, etc.
 
 

RLBob: what about term to describe hierarchically-related domains?
 

would be nice to have a common terminology basis between aaaarch & policy-wg

historical
 had policy terminology bofs at a couple of past ietf meetings.

 pol terminology is being worked on in the policy-wg by AD fiat.

PolTerm goals
 goal is no creativity -- not attempting a taxonomy. want to doc the way
 words are presently being used today, in order to keep them from being
 redefined.
 want to bridge gaps & diffs

usage of draft
 reference
 as a resource to constrain term migration & creep.
 

approch
 51 terms defined presently, 31 acronyms
 scaned & incorp'd many diff docs
 using rfc 2828 techniques

current issues
 filter issues
  filter in terms of packet filtering
 SLA
  see RFC2475
  there's an SLA bof (this meeting?)

recommendations
 want input from IRTF aaaarch folks
 want to go to last call as soon has have this input
 [again, not wanting to do a taxonomy]
 

JV: so since aaaarch is doing a taxonomy + defining terms, how do we resolve
this?

JS: one can do a taxonomy w/o doing an explicity definition doc.

Ed?: we can get in input that we can this week, but there'll be more stuff to
do after the meeting.

[slides]

related work
 radus
 diameter
 www based services
 rtsp
 sip
 sdp/sap
 

[slides]
 

JV: it doesn't say anything about the rel between authn ids and session ids.

SZ: need some input on that sort of stuff.
 
 
 

Interdomain SIP usage with AAA and QoS (with SIP mobility)

there's related drafts in other WGs with "sip" in their filenames

VoD -- voice over data?

MA "Media agent"
CH "Clearinghouse"
APS "Application and policy server"

[slides]

slide for "Call setup for interdomain SIP call with AAA and QoS"
 very complex

in telephony community there's two concepts: if you don't have qos, the call
doesn't go thru. another is if you don't get qos, give the end user a choice
whether to put the call thru (at reduced cost) or not.
 

ques: what's relation in this work to work in the session id doc. are there
specific reqs about what entities need to keep knowledge of some of the state
from the "call" afterwards?

ans: there's a notion in  sip of "call id", and that needs to be kept around.
 

JV: (some question about
 

ques: any policy exchange provided for?
ans: nope.
 
 

Multi-kingdom AAA with Krb v5
 

Association is a rel btwn two endpoints

contexts consists of specific context attrs that are used to establish,
maintain, and release associations.

krb sec contexts
 sec contexts cover only the krb application exchange and not the comm with
the kdc
 

end to end mode
 data is opaque to interstitial kingdoms

hop by hop mode
 data decrypt & re-encrypt at each hop

need a combo of these modes
  use hop-by-hop to send info along path that each interstitial kingdom needs
to see, use end2end for stuff that needs to be seen just by each end.
 

dependency on data modeling
 need to know the distinctions btwn diff data so it is used in the proper
 sec association type
 

JV: what's key here is sep of authn and authz in "some very interesting ways"

(taxonomy of the various message types that entities in the AAA model will
need to exchange)

(taxonomy of various "top level" objects that gett passed around)

[slides]
 

ques: list of top level objects is nicely abstracted, except "authn challenge"
-- lots of authn mechs don't know how to challenge.

ans: it's just a place holder for if some info needs to flow in the opposite
direction.
 

rlbob: there could be an unlimited # of exchanges in doing the authn
exchange(s), so maybe calling it "challenge" is too specific.

rlbob: is there a higher-level agregation of these objects? have you persued
it or decided not to do it that way? (object modeling?)
 

daves: (his answer went down into more detail instead of going "up" into more
agregated objects -- missunderstood question?)
 
 
 
 

looking at making a video about AAA reqs.

[slides]

leon.gommans@enterasys.com
betty.de.bruijn@planet.nl
 
 

www.ispworld.com -- article on AAA and thsi group (boardwatch zine)

AAAarch is 1 yr old now.

slide on the different perspectives on AAA from a requester (user) asks for
some service.
 perspectives:
  service
  user
  intermediaries
  organizational

[slides]

Roles
 [slides]

Authorization Models
 agent, pull, push
 do we need these three models? too much, not enough? discuss on list.
 

Starting point
 the prior work on having a PDP and PEP
 generic AAA engine that uses applciation specific engine as necessary (in
 PDP), and then..
 communicates with PEP.
 

Multi-domain case
 
 

Basic principles
 RBE - rule based engine
 asm - application spec. module
 service equip

2. there is a global addres space btwn the rbe and the asm

3. there is only generic stuff in the rbe and all the application specific
stuff is in the ASMs

4. the rel btwn AAA servers is symmetric

5.

[slides]
 

issues

rels in pcitural model
type 1-7 comm.
internal struc in model
global address space
revine layered model
scalable aaa server model
 

ques: we're straying outside of aaaarch's orig domain? e.g. resource
discovery, complexity due to genericism?
 

we need to think about the interim meeting in (probably) Jan. discuss on list

proposal to NANOG for a AAA operations group? source of reqs & practices?

lots of ietf interactions for this group --
 authn security context area
 accounting/auditing/session id stuff
 SLS -- service level specification -- how's that play in the aaaarch space?
 

?: CdNP folks are looking at accounting stuff

rlbob: there's work in the "web services" space that's related to the work in
this group.

-----
end