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.

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

User org AAA

AAA Broker

AAA Broker

Appl with AAA

User org AAA

Appl with AAAAAA Broker

AAA Broker

User

AAA infrastructure – vision for the future

Jrv@merit.edu IWS2000 !6 Feb.2000

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

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

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

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

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

Data Objects

Service AAA

Broker AAA

User-org AAA

(DO1) (AAA-HDR) (DO1) (DO2)(AAA-HDR)

(AAA-HDR)(DO3)(AAA-HDR)(DO3)(DO4)

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

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

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

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

Distributed Session State(proposal)

NAS

Primary AAA Server

Backup AAA Server

Request/reply

State update

Sess state

Sess state

State request

Jrv@merit.edu IWS2000 !6 Feb.2000

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

Distributed Policy

User-org AAA

Broker AAA

Application AAA

Policy Repository

Policy Repository

Policy Repository

User info db

Broker agreements db

Application state dbDevice

PEP

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

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

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)