1. Authentication Authorization Accounting and Auditing
Open Issues for irtf AAAARCH working group
IWS2000 February 16, 2000
John Vollbrecht
Director, Merit AAA Server Consortium
Merit Network Inc.

2. AAARCH irtf working group– goals and objectives
Research rather than engineering group
Long term architecture group, related to AAA working group
Architecture and models for AAA/A in 9-12 months
Feed full requirements to AAA wg in early 2001
As opposed to
AAA ietf wg goals –
to have an “interim” protocol requirements by end of March (Adelaide ietf)
Hope to recharter as a Protocol selection group and have interim protocol by early 2001
IWS2000 !6 Feb.2000

3. AAA infrastructure – vision for the future
User org AAA
Appl with AAA
AAA Broker
AAA Broker
AAA Broker
AAA Broker
User org AAA
User
Appl with AAA
IWS2000 !6 Feb.2000

4. AAA irtf basic concepts
Focus on inter-organization issue
Service provider and user-organization
each “own” policy
Push, Pull, Agent sequences for Authorization
Brokers and Proxies as intermediaries between service providers and user-organizations
IWS2000 !6 Feb.2000

5. Brokers and Proxies Different types of intermediaries
Brokers aggregate applications and/or “user-orgs”
Facilitate inter-organization cooperation
Proxies promote interaction between AAA servers within an administrative domain
Often translate between organization specific and standard interface
Much of AAA work deals with how Brokers and Proxies fit with AAA protocols
IWS2000 !6 Feb.2000

6. Brokers and Proxies – Requirements- tentative definitions
Brokers have business relationship with multiple organizations
Implies enough trust to do business
Perhaps not “complete” trust
Requires audit friendly AAA system
Proxies interact with AAA servers in the same organization
Implies organizational trust (not network/security trust)
Typically uses
translate between AAA protocols
aggregate AAA servers in an organization
Interface to AAA servers in other organizations
IWS2000 !6 Feb.2000

7. AAAARCH –Open Issues Data representation Data security
Interaction between accounting and authorization
State maintenance with no single point of failure
Distributed policy
Storage/ evaluation/ enforcement
Policy description
Auditing requirements
IWS2000 !6 Feb.2000

8. Data Representation Groups of objects Groups of groups
Integrity by group
Identify originating and destination server(s)
Data Object contents could be
Policy description
Policy “data”
Policy evaluation
Possibly Self defining syntax for objects
IWS2000 !6 Feb.2000

9. Data Objects (DO1) (AAA-HDR) (DO1) (DO2)(AAA-HDR) Service AAA
Broker AAA
User-org AAA
(AAA-HDR)(DO3)(DO4)
(AAA-HDR)(DO3)

10. Data Object Security Integrity Role of mac vs. signatures
Role of intermediary
Broker
Trusted 3rd party
Performance and business model
IWS2000 !6 Feb.2000

11. Data Object Security Confidentiality When is it required
Examples
Clear text password
Session key for FA/HA in MobileIP
What is required
Some external authority trusted by originator and receiver of confidential data object
IWS2000 !6 Feb.2000

12. Accounting and Authorization
Authorization can include Accounting Policy
Accounting to demonstrate that requested policy was implemented ( i.e. that QOS requested was delivered)
Requirement for a “session id” to identify Accounting and Authorization activity for the same session
IWS2000 !6 Feb.2000

13. State Maintenance
State is what is known about a session – often most important is whether the session is currently “up”
Information about state of session may be maintained in multiple AAA servers
There is one source of authoritative information about each state element of the session
Making sure that what is kept in AAA server matches authoritative source is tricky and has led to systems with difficulty doing fail over between a primary and backup server
IWS2000 !6 Feb.2000

14. Distributed Session State (proposal)
Request/reply
Primary AAA Server
State request
Sess state
State update
NAS
Backup AAA Server
Sess state
IWS2000 !6 Feb.2000

15. Distributed Policy Policy Description Policy Data Policy Enforcement
Repository maintained by organizational owner
Policy Data
Data to be evaluated by policy
Policy Enforcement
Doing what the Policy describes
Owner of policy may not be owner of Policy Data
Enforcement of Policy decision may be by different organization than the one defining policy
IWS2000 !6 Feb.2000

16. Distributed Policy User-org AAA User info db Broker AAA
Policy Repository
User-org AAA
User info db
Policy Repository
Broker AAA
Broker agreements db
Policy Repository
Application AAA
Application state db
Device
PEP

17. Auditing
With multi-organization process, each organization must trust that others are doing what is expected
Auditing verifies that processes are reasonable, appropriate for expected results
Equivalent to what CPA would require for standard business systems
Expands network management to multi-organization process
IWS2000 !6 Feb.2000

18. Some Audit Mechanisms
Logging signed requests and session status records
Logging by trusted 3rd party of appropriate records
Real time “check” that appropriate programs are running
Comparing log entries from cooperating servers
IWS2000 !6 Feb.2000

19. Summary Active Group working on AAA issues
Goal is to find and define a simple mechanism that permits complex services
Open mail group
We encourage interested people to join the group (mail to or
Questions/ comments? (Thanks)