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)