Authentication Authorization Accounting and Auditing

1. Authentication Authorization Accounting and Auditing Open Issues for irtf AAAARCH working group IWS2000 February 16, 2000 John Vollbrecht Director, Merit AAA Server Consortium jrv@merit.edu 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 Jrv@merit.edu IWS2000 !6 Feb.2000

3. User AAA infrastructure – vision for the future User org AAA Appl with AAA AAA Broker AAA Broker AAA Broker AAA Broker User org AAA Appl with AAA Jrv@merit.edu 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 Jrv@merit.edu 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 Jrv@merit.edu 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 Jrv@merit.edu 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 Jrv@merit.edu 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 jrvJrv@merit.edu 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 Jrv@merit.edu 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 Jrv@merit.edu 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 Jrv@merit.edu 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 Jrv@merit.edu IWS2000 !6 Feb.2000

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

15. Distributed Policy • Policy Description • 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 Jrv@merit.edu IWS2000 !6 Feb.2000

16. Distributed Policy 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 Jrv@merit.edu 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 Jrv@merit.edu 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 jrv@merit.edu or delaat@phys.uu.nl) • Questions/ comments? (Thanks)