AAA ARCH 

The AAA Architecture (AAAarch) Research Group meeting Dec 14th. at 52th IETF in Salt Lake City, Utah, USA.



Minutes by Bob Morgan and Leon Gommans (as the two front row sitters...)

1th contribution:

Cees, status on RG
2 revised drafts, 1 draft in last call
no teleconferences on aaaarch, 2 teleconfs on AUTH
little participation
charter items not assigned
  auditability framework for multi-domain env:  JohnV, JoeS to work
  mesh management model
  generic interdomain
  ...
4 current drafts
  taal-generic-pol, superseded by policy lang
  aaa-pol
  generic policy grammar
  policy-based accounting

policy-based accounting, Zsaby
draft reviewed by IESG
comments on conflicting wording
new version of draft sent to aaaarch list
changes:
motivation statment enhanced
clarify that providers need to establishe policies beforehand
clarify that metering/collection can be based on acctg policies
  also charging/billing, multiple rules
distinguish acctg attrs from acctg-policy attrs
  and acctg policy condition from policy action
more realistic examples
terminology
  align "meter" with RFC2722-RTFM doc, different from DiffServ defs
  align "classifier" with RFC2475-DiffServ
  comment from diffserv co-author:
    changing model to be more flexible
    allow meter/filter/classifier to all be separate
    support (de-)multiplexing
    OK to use a different def here ...
  align "service class" with pol-term doc
technical issues
comment:  accounting not a specific layer, should apply to all
  is "accting" really "record generation"?  TZ:  stick with "acctg"
Ellesen:  maybe distinguish sub-functions of "acctg" by different name?
  TZ:  yes, acctg is overloaded, but seems like right term
  EE:  maybe add a qualifier before "acctg" to clarify?
comment:  does AAA configure services?
  general issue for aaaarch, discussed on list
  perhaps:  ASM configs, not AAA
  CDL:  distinguish "enabling" from "configuring" from "provisioning"
Henry Sinnreich:  what is relation to "web services"?  use of XML?
  CDL:  let's not dive too much into implementation/protocol
EE:  this doc seemed to go into config space, as did arch
  so is that in scope?  setting up "experience" info in device?
  basic arch docs didn't clarify this for him
CDL:  arch docs are clear, we're just about decision part
JV:  well, may need to go back and clarify in arch docs
  distinguish service setup (config) from per-user (aaa)?
WW:  a hard problem, need both tight integration and flexibility
  hard to achieve in today's world

Proxy certificate profile, Doug Engert, ANL
Globus project since 1998, high-end computing "grid"
  GSI is globus security, adopted by GGF
draft-ietf-pkix-proxy-02.txt
  current code implements simpler version
infra
  ID via X509 certs, authn via SSL
  authz via local "grid-map" file, mapping X509 SN to local user
  acctg ...
delegation of identity
  server creates request, keypair
  client signs, uses
  proxy cert only used along with regular client cert
  actual use is "double-proxy", two levels of delegation
supports Kerberos(like) "user to user"
  also access by servers to backend services such as AFS
Q:  what's the deal with GSSAPI and SSL?
  it's a GSSAPI authn mechanism based on SSL
Q:  Kerberos supports user-to-user doesn't it?
  yes, but GSSAPI doesn't support this use, yet


AAA and GSI and Grids, Leon Gommans
grids allow sharing resources
GSI supports SSO across multiple domains
  orgs remain in control of their resources
RFC 2904 "push" model shown
  user gets token from home, presents to service
  home and service have trust relationship
GSI model shown as being conformant, but extension
"industrializing" the Grid
  moving it out of high-end science env
  collab between commercial orgs
  grid "ad hoc" usage doesn't scale to subscribed services
  procurement has to be dealt with
commercial workflow
  create relation with home org
  then create rel with community, authz by home org
  the rel with service provider, based on community
Globus developing Community Authorization Service to implement this
YD:  is this user-centered?  isn't Grid data-centered?
  DE:  CAS issues proxy to user, resource only knows about CAS
RLM:  NSF funding integration in US between Grids and university IT
  library licensed resource access model looks very similar

Walt Weiss, policy and access bind PIB
DiffServ model as inspiration
"accessor" concept deals with dynamic classifier setup
  look for and create session, bind session to policy
hierarchical classifiers provide scalability
  define set of services for session, based on policy
COPS extended to support multiple outstanding transactions to PDP
  aka parallel processing
  define session handles to identify them
COPS traditionally used for RSVP
  response from PDP not just yes/no, but more setup info
  separate session scope attrs from session trigger attrs
use case for wireless apps

accessor issues in access bind PIB, Freek Dijkstra
basic PEP-PDP model
config step
  PEP tells PDP what it can do, PDP tells PEP what it should do
PIB data structures
  accessor is root, has accessor elements, authprotocols, contexts
  accessor elements have session scopes, and datapath
  session scopes have filters
comment:  PIB doc (?) is on its way to IESG ...
model can support any kind of trigger
depend on other framework PIBs, which may be issue
comment:  separating classifier from meter is a good thing

policy grammar, CDL and Taal
doc changes
  AVPs have become Objects
  looking at message types sent between AAA servers
  type checking material
object reference example, password request in expression
  object tree diagram ...
message types
  authn request has identity and authn data
    one-to-one mapping of requests to driving policies
  remote policy evaluation request
    contains policy ref, possibly at a different AAA
    reply contains service data
    policy ref can also be local
  type checking now considered unnecessary ...
example driving policy:  Kerberos authn
scope questions
  exception handling not done now, should it?
  parallel operations

PANA, Subir Das
motivation
  authentication methods tied to link access type
  would be better to have common one applied across schemes
model
  client - edge_device - PANA authn agent - AAA
  another:
    client gets unauthenticated access to local service
    has to authenticate to get to wider Internet
proposed work
  client authenticates "to" PAA
  device discovery of IP address of PAA
  PAA can use either local data or AAA, this is out of scope
  secondary task:  security association between device and PAA
    ie, supporting SSO as user roams among access points?
q:  relation to PPP authn or 802.11x?
  similar but different ...
  JV:  there is much confusion on this point


PERMIS PMI-based authorization system, David Chadwick
based on ISO 10181
role-based attribute certs stored in LDAP DS
clients authenticated by any means
  authn supplies "name of user"
XML DTD established, published at xml.org repository
code available for research purposes
local components
  PKCS-11 interface to do cert checking
  access enforcement function
  etc
policy expressions
  each has distinct OID
  subject policy based on LDAP subtrees
  role hierarchy policy
  SOA policy:  who can issue attr certs
  role assignment policy
    which SOAs can give which roles to which subjects
  target policy:  targets in LDAP subtrees
  action policy:
  target access policy:
  X.509 Annex D (2000) has sample policy expressions
    outcall to local evaluation modules
  use time constraints from IETF Policy framework
use IBM Xeena tool for XML creation
user tool for attr cert creation/management
four simple calls in PERMIS API
  loosely based on OpenGroup AZN API
four sample applications
  Salford, Barcelona, Bologna city stuff
  electronic prescriptions

access device model, JV
device functions:  trigger, authentication, session
  eg trigger on power up, or client request
power up transaction to setup device
authentication dialog, interaction with authn authority (eg PDP)
session start does PDP transaction to provision session
q:  what does client want to use authn for?
  JV:  question is what security association is bound to at client
    just IP address?  that's scary
RLM:  need to distinguish different services, not all in one box
q:  what about delay in authentication processing?
  what happens to flow in mean time?
  JV:  application-specific
q:  what do triggers look like?  what about abuse, DoS?



2nd contribution:


Difference configuring service and configuring accounting thru policies.
A clear difference must be made as pointed out by the IESG

JRV: Clearify configuring the service for the user and configuring the accounting service.

Changes will  be made in the ID to this respect .

Comment Walter Weiss : strong relationship between the services and how accounting is related is a classic problem that is difficult to solve.

Douglas Engert

Proxy Cert profile

Globus Proxy certs is simpler form of PKIX draft.

Explanation of proxy cert which is delegation of identity

Explanation of operational aspects of using proxy certs.


Eigen presentatie


BIND PIB

Looks at diffserv model – breaks up functional components
Classifier = function that evaluates datapath and could lead to functions
Such as meters, queues etc.
Piece that was missing was binding of specific policies to specific users/identies
Construct the concepts of accessor that looks for new criteria on which to create a session and bind policies to it
Accessor is configured to look at criteria, when not matched it is dropped in the default path otherwise it will it will cause actions. A request will then be send to the PDP
A response will set a number of functional behaviours

Issues refer to notion of hierarchical classification Same set of classifiers are maintained
For every session – a notion of hierarchical was introduced that groups a set of classifiers

Issue in COPS PR was parralle processing If a complex session was received it needs
Completion before an next request could be processed. A handle of per-session bases was
Introduces allowing parallel processing.=convenient way to handle / distr

COPS was used for RSVP. COPS model RSVP specific with simple yes or no. Our
Model enhances this. Needed modification to support RSVP filtering as this was not
Specified and separate out the criteria for creating a session and triggering a session.
Use case for Wireless (work on 3GPP) where cops PR is used.


FREEK

Datastructure of PIB

Dependency on onther drafts

Explain Relation to PIB to pull model

Accessor concept explanation,

PIB datastructure

Flexibility of the model was pointed out (separation of trigger
and session semantics (filters)) and acknowledged.



Cees: Structures draft examples of how requests can be referenced and how messages
Are handled, remote polices are called
No typechecking and error checking is difficult and research topic (no provisions for this yet)
Example driving policy for kerberos (example in draft)
Two things remain : identify message types
Define return trees.
Push and pull policy

Exeption handling & parallelism.


PANA

New WG in internet area

Motivation:

Access technology determines authentication process

Each time a new hardware technology is defined a new access technology needs to be developed

Defines position of PAA (PANA Autnetication Agent)
Defines position of PAA that recognized local network that does not need PANA
Only when internet is accessed.

Goals of PANA

Primary
A device (on behalf of user) Authenticate to agent
Device should discover IP @ of PAA
PAA use either local mechanism or AAA infrastructure (client of AAA)
Secondary
Create local security association (is it possible to create a

Dave chatwick

PERMIS

Explained  Attribute cert usage
User name is used to get attributes certs after authentication
Authenticaiton is fully external

Policy is written in XML and DTD is published.
Privilige allocator
PMI implementation.

Policies : each policy has OID
Subject policy (users must come from this ldap domain)
Role must exist (hierarchy that is described in policy)
AC contain roles.

Who is trusted to sign (multiple AA may sign and trusted)
Role assignment.
Target policy (that is controlled) and defined which action are supported.

Policy is based on X.509 + escape mechanism to allow local java object to evaluate
Policy.

JRV

Define what goes into the PEP if you want to do authentication
Worth to thing about the pieces.

Diagram shows potential architectural issues that can be studied.

Indicates needs to investigating how to bind the authentication to something.

Q Does the PDP need to be one or 3 boxes

Q When authentication is done, how are packets handled.

Q how to avoid abuse of trigger (i.e. what are allowable triggers)




CdL - oct 22th 2001 Visitors of this page: