2.4.2 Authentication, Authorization and Accounting (aaa)

NOTE: This charter is a snapshot of the 49th IETF Meeting in San Diego, California. It may now be out-of-date. Last Modified: 11-Oct-00


Bernard Aboba <aboba@internaut.com>
David Mitton <dmitton@nortelnetworks.com>

Operations and Management Area Director(s):

Randy Bush <randy@psg.com>
Bert Wijnen <bwijnen@lucent.com>

Operations and Management Area Advisor:

Randy Bush <randy@psg.com>

Mailing Lists:

General Discussion:aaa-wg@merit.edu
To Subscribe: majordomo@merit.edu
In Body: subscribe aaa-wg
Archive: http://www.merit.edu/mail.archives/html/aaa-wg/

Description of Working Group:

The Authentication, Authorization and Accounting Working Group focused on the development of requirements for Authentication, Authorization and Accounting as applied to network access. Requirements were gathered from NASREQ, MOBILE IP, and ROAMOPS Working Groups as well as TIA 45.6. The AAA WG then solicited submission of protocols meeting the requirements, and evaluated the submissions.

This incarnation of the AAA Working Group will focus on development of an IETF Standards track protocol, based on the DIAMETER submission.

In this process, it is to be understood that the IETF does not function as a rubber stamp. It is likely that the protocol will be changed significantly during the process of development.

The immediate goals of the AAA working group are to address the following issues:

- Clarity. The protocol documents should clearly describe the contents of typical messages and the requirements for interoperability.

- Error messages. The protocol should define categories of error messages, enabling implementations to respond correctly based on the category. The set of error messages should cover the full range of operational problems.

- Accounting. The accounting operational model should be described for each type of network access.

- IPv6. The protocol must include attributes in support for IPv6 network access and must be transportable over IPv6.

- Transport. The protocol should be transport independent and must define at least one mandatory-to-implement transport mapping. Other transport mappings may also be defined. All transport mappings must effectively support congestion control.

- Explicit proxy support. The protocol should offer explicit support for proxies, including support for automated message routing, route recording, and (where necessary) path hiding.

- RADIUS compatibility. The protocol should provide improved RADIUS backward compatibility in the case where only RADIUS attributes are used or where RADIUS proxies or servers exist in the path.

- Security. The protocol should define a lightweight data object security model that is implementable on NASes.

- Data model. The proposal should offer logical separation between the protocol and the data model and should support rich data types.

- MIBs. A MIB must be defined, supporting both IPv4 and IPv6 operation.

Goals and Milestones:



Submission of requirements document as an Informational RFC.

Sep 00


Submission of evaluation document as an Informational RFC.

Oct 00


Submission of design team recommendations on protocol improvements.

Nov 00


Incorporation of design team recommendations into protocol submission.

Dec 00


Improved protocol submission accepted as an official WG draft.

Apr 01


Submission of protocol document(s) as a Proposed Standard RFC.


Request For Comments:






Accounting Attributes and Record Formats



Introduction to Accounting Management



Criteria for Evaluating AAA Protocols for Network Access

Current Meeting Report

aIETF 49 - Minutes of the AAA Working Group
Dec 11 & 13, 2000, San Diego

Recorded by: John Vollbrecht
Edited by: David Mitton

Monday, 11th, 1:00pm

Agenda bashing

Document Status:
draft-ietf-aaa-proto-eval-01.txt (Mitton) has few comments, in WG last call
draft-hiller-cdma2000-aaa-02.txt (Hiller) ready to send to RFC editor

AAA Milestone Review:

- Development of AAA protocol based on Diameter - need results soon!!
- Solicit Issues on current specifications and document
- Solicit Solutions proposals and document
- Discuss Proposals, reach consensus
- Check in accepted solutions to Diamter drafts

Solutions Doc is scheduled for Feb 1
Rework into protocol submission - Jan 15?
April 1 submission of protocol docs as proposed standard RFC

Diameter Issues Review -- Pat Calhoun

Pat reviewed the issues laid out in this draft and any discussion of the solutions proposed.

An issue was raised with the Result-Code AVP, and whether proxies could add values and if multiple were allowed. This was not completely resolved.

A rough consensus was reached that ADIF descriptino of accounting data should be dropped from Diameter documents, dues to issues of definition and efficiency. This implies significant cleanup of the solutions draft

Accounting polling, has significant problems, particularly with scale in proxy situations, but is required, in some form, to support resource management. (this seems to tie in with the tight state consistency issue)

Batched accounting is no longer supported as part of the Diameter message format. Transport level batching may be supported and this may be dealt wit as a transport issue.

End-to-end security was discussed for a fair while. Secure key distribution is still a major problem, particularly if there is a proxy chain. There was some suggestion if this could be layered into the protocol at a later time. There is some disagreement as to whether we need ETE from the NAS or the user's accessing system. This topic is still being discussed on the mailing list.

Issues with transport have been taken outside of this draft. See Bernard's presentation.

There has been a suggestion to add an AVP to indicate if a Diameter message has been translated from RADIUS, as an aide to upstream systems.

Issues relating to the Data model have not be put in this draft, but are being discussed in later presentations.

The Mandatory AVP flag bit was discussed. Some do not see the purpose or think the issue can be solved by definition. Randy made the point that Mbit does not force the receiver to implement a feature (known or unknown), but could allow the receiver to nak the request without prejudice to the receiver's implementation.

It was also pointed out that the word extensions is overloaded. There is a difference between diameter extensions for a service, and vendor specific extensions.

Discussion also pointed out that future systems might include situation where sender must know that the receiver is able to deal with an attribute, and may have an alternate strategy if the receiver does not understand the attribute.

A hum overwhelmingly indicated consensus for retaining the M flag.

There is no progress on a MIB at this time, as protocol objects have not been identified. Should each extension have its own MIB? How are how are sensitive objects transferred in MIB? e.g. passwords, shared secrets, etc. The MIB definition can be deferred until other parts of protocol definition are complete.

The solutions draft introduces the concepts of tight and loose consistency state across client/proxy/server systems. Pat would like to drop tight state, but there was some push back and the suggestion that a problem statement should be made.

Non-IP filters are a descriptive problem, no one seemed to care. They will be dropped from protocol requirements.

IANA will need to create a new registry for Diameter identifiers. We will have to recommend a procedure for future allocation. We also need to figure out when it makes sense to start this process.

Paul Funk raised an issue with Identifiers, which was decided to be discussed on the the mailing list.

Proxies Draft -- Dave Mitton

This document describes a number of proxy issues, and defines terminology and motivation. Dave presented an overview of it's topics.

The types of proxies; routing, policy and brokers were defined. Proxies need to handle some state information to do their job. The types of state information required depends on the reliability and transactional role.

By retaining state proxies require help from the protocol to reliably track the network operation, in the face of network failures, failover, and shutdowns.

Generic problems with transport reliability and congestion are amplified by proxies

Diameter API- James Kempf

A C language API that supports both client and server, is now complete. Java implementation now well in progress.

IPV6 implications - Charlie Perkins

This draft proposes a way for IPv6 notes to automatically offer credentials to a local AAA server to access the network. The document presumes that routers and DHCP servers will help perform this task. The handling of Mobile IPv6 nodes is also included.

Some discussion as to were this fits in this or other working groups. Clearly working on ICMP messages is not. The work is currently an individual submission, looking for appropriate place to land.

Transport issues -- Bernard Aboba

Goal was to understand how transport and AAA protocols interact with each other.

RADIUS had single NAS AAA connection, some had a connection per port, implication that a NAS could send multiple uncorrelated packets.

AAA must use a congestion friendly transport, and pipelining is highly desirable.

Firewall issues need to be examined; that is DNS and AAA traffic must be allowed, but Denial-of-services attacks prevented. Perhaps we need port specific rate limiting on router or built-in DoS solution.

Potential problem with lots of NASs may create a traffic problem for a single AAA server, because for all of them might create traffic and cause congestion and packet loss near AAA. Because NAS is unaware of downstream proxy issues, it can't rate limit.

Possible solutions: Send a "busy" indicator - tell NAS or proxy to stop for a while because;(it is too busy, or because next AAA server is not responding, additionally: can't locate server, can't forward, waiting to get sufficient info to reply). Conclusion: this message resolves a lot of the problems.

Application vs Network driven message timing: Time between AAA requests is much larger than rtt by a lot. (e.g. small nas 20 minute sessions) Network driven (e.g. 8am office startup) would like to piggyback acks rather than have delayed acks. Rtt times are not necessarily reflective of actual response because of the TCP could run without delayed acks. This would fix rtt. A good discussion of TCP congestion control and slow start interactions with AAA sequences was held.

Conclusions: TCP feasible, SCTP feasible, UDP not so much.

Discussion: turning off delayed acks in TCP requires immediate ack, therefore doesn't it increase number of packets? Not if TCP acks are piggybacked on AAA acks. This requires some investigation.

Second Meeting; Wed, Dec 13th, 1:00pm

<No one has volunteered any notes, the following minutes were reconstructed by Dave Mitton>

Due to a time conflict, people interested a presentation on CMS, are encouraged to attend Stephen Farrel's presentation in the SMIME WG.

CHAP Improvements - Uri Blumenthal

Uri briefly presented improvements in CHAP challenge processing that would improve security across AAA. He will write them up in a draft and bring to the mailing list's attention.

Transport Issues - Bernard Aboba

Continued discussion on prior day's presentation.

Some problems were found in piggy-back ACK assumptions that were corrected. Acks will happen and contribute to RTO measure. May want to adjust ack delay from proxy to optimise, but it is hard to predict server latency.

Application level re-transmits are a different issue. We should try to keep transport connection problems separate from upper level problems. Networks problems should not happen too often and some loss may be acceptable. Race conditions may arise if a NAS attempts to failover while a proxy is also trying to find a working server. Server state could become incorrectly over subscribed. Ideally, we'd like the connections to be end-to-end self-clocking/regulating. Application feedback messages may be the only good and practical solution for this.

Discussions: Can we write off UDP as too problematic? Can we characterize single connect vs multi-threaded implementations? (Some RADIUS implementations use multiple sockets as clients and send/receive without any centralized queueing or coordination on the host system. Does Diameter have different requirements that cannot support this?)

[OT] Acct-Start message sent before PPP NCP finish is not good. Will Diameter define this?

Kerberos for End-to-End Security - Kaushik Narayan

Presentation of method to use Kerberos for AAA security.
Issues with proxies and multiple domains.
Can this be used for End-to-end encryption?

There is also discussion of these issues in the IRTF AAAarch group.

Service Discovery Protocol - Erik Guttman

1) a static list
2) Use SLP protocol for local servers
3) Use DNS SRV RRs (requires domain name)

Looking for interest

Data Modeling:
Requirements and Issues - Erik Guttman

Attempting to separate data description from actual messages.
Type of message now indicated in header flags.
Type of AVPs simplied and extended to allows complex data to be built out of primary types.

Develop a formal notation for Diameter AVPs:
We now have three proposals; XML, SMIng, and UML.
The XML is attached to the current solutions draft

Data Modeling Proposal - Jurgen Schoenwaelder

Jurgen has developed an approach to describe Diameter AVPs using the new SMI

AAA Data Modelling - Dave Spence

This model complements SMIng, and includes a PIB. Diameter/RADIUS AVPs are grouped according to message role (Auth Request/Response, Accounting) and service type, and represented in a UML model schema. This notation allows one to describe the AVPs in different types of requests and responses as well. It does not describe on-wire format.

[The meeting ran over into the break about 20 some minutes.]

Due to lack of time, the 3GPP Accounting and the IRTF AAAarch presentations were not given, but are in the minutes.


Protocol Requirements Differences Between
AAA Design Team Data Modelling Issues & Solutions
SMing Mappings to DIAMETER
Data Model for Network Access
AAAARCH - IRTF Research group
AAA Transport Issues
AAA Pending Issues
Radius Security Extensions Using Kerberos V5
AAA Proxies