authentication authorization accounting and auditing open issues for irtf aaaarch working group...

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)