2.4.2 Authentication, Authorization and Accounting (aaa)

NOTE: This charter is a snapshot of the 50th IETF Meeting in Minneapolis, Minnesota. It may now be out-of-date. Last Modified: 14-Mar-01


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/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

Minutes of the AAA WG Meeting
IETF 50, Minneapolis, MN
March 19 & 23, 2001


Chairs: Bernard Aboba aboba@internaut.com and Dave Mitton, dmitton@nortelnetworks.com
Based on minutes taken by John Alayari (johnal@cisco.com) and John Vollbrecht (jrv@interlinknetworks.com)
Editor: Bernard Aboba

WG web page: http://www.ietf.org/html.charters/aaa-charter.html

Monday, March 19, 2001 Evening Session

Agenda bashing
AAA Milestone review

Document status review
Published so far: RFC 2924, 2975, 2977, 2989
Sent to IESG: draft-ietf-aaa-proto-eval-02.txt
Sent to RFC editor: draft-hiller-cdma2000-aaa-02.txt
Last call comments received: Draft-ietf-aaa-issues-04.txt, updates needed
Still outstanding: draft-ietf-nasreq-criteria-06.txt (now expired, referenced by RFC 2989)

Standards track:

Diameter base protocol,

MobileIP extension,

NASREQ extension,

Transport profile,

Proxy behavior,

Strong crypto (taken on as a WG work item as decided later),


Diameter implementation guidelines,

Diameter APIs (taken on as a WG work item as decided later),

To be discarded:

AAA accounting (to be incorporated into the Diameter base draft, as decided later in the meeting):

AAA framework document (pieces to be incorporated into the Diameter base draft):

Working documents to be discarded eventually:
AAA issues:
AAA solutions:

AAA milestone review

A new target date for WG last call was set for July 1, 2001. There was discussion on the process by which we would meet this schedule. It was noted that the goal of the AAA WG meeting was to make major decisions on the data modeling and security functionality in the Diameter protocol. After the WG meeting, we would not be accepting major new additions in functionality to the base protocol. Changes to the protocol will still be accepted, particularly those that are needed in order for the protocol to fulfill the requirements. We will also make changes to improve the clarity and readability of the protocol specification. It was noted that the AAA WG would have an interim meeting in May, after which we would raise the bar on taking changes -- after this meeting is it likely that only minor changes will be accepted.

Interoperability testing

Tony Johannson announced that he was looking to schedule interoperability bakeoffs. Those interested in participating should contact him (tony.johansson@ericsson.com)

Data Modeling

SMIng and DIAMETER, J. Schoenwaelder

There was discussion on what SMIng was and was not, and the reasons why Diameter needs data modeling. Data modeling is useful because it enables protocol sniffers and Diameter server implementations to be extended without modifying code. It thus improves the extensiblity of implementations, even if on-the-wire encodings are not affected.

It was noted that using SMIng did not necessarily imply that Diameter AVPs or PDUs would be ASN.1 encoded, and that the draft were not proposing this. However, SMIng can be used to formally describe the semantics of Diameter messages. This would be useful if you wanted to be able to put those semantics in machine-readable form. It was also noted that SMIng could be used to describe both the syntax and relationship of data structures.

AAA Data Modelling David Spence

Dave Spence presented work on addition of AVPs to Diameter that would enable support for data modeling SPPI, SMIng, and SNMP MIBs. Among these was a pointer AVP that would enable objects to reference each other. The goal of this work was to enable Diameter to make use of the data modeling work of other WGs and express more complex data structures. The current protocol specification is more oriented toward transmission of very simply structured parameters. The major application which seems to require more complex data structures is Quality of Service (QoS). There were questions as to whether this implied changes in the on-the-wire protocol, and the answer is that it does not.

DIAMETER Data Modelling proposal, Erik Guttman

Eric discussed the data modeling functionality currently in the Diameter specification, including the ABNF, which is used to describe Diameter semantics. Eric also described the functionality of the data dictionary which could be expressed in XML, SMI or other alternatives. Since it doesn't affect the on-the-wire protocol this is an implementation decision. RADIUS didn't standardize the data dictionary, so it isn't clear that we need to either. Eric proposed that we allow any number of (optional) dictionary description formats.

There was discussion about the benefits of a data dictionary and the Diameter extensibility model in general. RADIUS supported several simple data types and was extensible via a data dictionary. This meant that RADIUS servers could add support for AVPs without changing code. However, on the NAS side, code changes for new AVPs are always necessary, because the NAS actually has to understand and carry out the intent of the AVP. RADIUS also supports extensible authentication via EAP. Addition of new EAP methods requires code changes on the server, which needs to terminate the EAP conversation, but not on the NAS, which acts as an EAP passthrough. RADIUS does not support command extensibility - the commands in RFC 2865-2869 are all there is.

In contrast, DIAMETER supports richer data types including grouped AVPs, as well as authentication extensibility via EAP and in addition, command extensibility. It was noted that adding new commands will require code changes on both the client and server. Data modeling cannot help you there -- both server and client need to understand the command in order to carry it out. There is no such thing as a non-mandatory command. Given this, why is being able to express the command in a data modeling language useful? Perhaps you can generate a code skeleton from the description? This is the kind of thing that is done with MIBs and SNMP agent skeleton generators. It wasn't clear from the discussion whether anyone was really interested in this.

Eric offered that the existing capabilities meet the AAA requirements, so we should be done. We can add other capabilties later -- but should continue with the base specification as it exists. He proposed that we freeze Diameter data modeling functionality in the base spec and work towards incorporating bug fixes so as to move to WG last call by the previously stated deadline (July 1, 2001).

Paul Funk asked about flexible "optional" AVPs in grouped AVP. Was this allowable? Discussion will be taken to the mailing list.

Data Modelling Discussion and wrapup

It was decided that SMIng-based data modeling was useful for Diameter, but that these drafts should proceed in parallel with the base specification, and not be incorporated into it. There was discussion as to whether the ABNF encoding currently in the spec was OK. There seemed to be consensus that it was sufficient. The desire of those present was not to delay the base protocol by trying to incorporate more sophisticated data modeling into it.

There was discussion on whether there needed to be a definitive data dictionary definition. David Harrington and Dave Spence noted that having a single definition would make it easier for people to post definitions so as to enable people to load those definitions into their server. Having more than one definition would mean that you'd have to create the definition within each "flavor" of definition language, so it would be more work. A consensus of those present felt that there could be more than one data dictionary definition and a definitive one was not required. So data dictionary work will also occur in parallel, and will be informational status, since this does not affect the protocol on the wire and therefore will not be standardized.

It was decided that the AVPs that David proposed would probably be useful, but that work on these AVPs should proceed separate from the base specification, and would become an optional feature. This implies that there will be implementations that won't support these specifications, but the concern was that putting this work on the critical would delay the base specification.

These decisions will be taken to the mailing list to see if there is WG consensus on them.


Kerberos for DIAMETER End-to-end security, Jonathan Trostle

It was noted that this draft was substantially changed from the previous RADIUS strong security draft. For example, in this draft initiation of GSS_API occurs on the server, not on the client. There were question about this -- how can the AAA server know which end-to-end clients it will establish security associations with? In a roaming environment you could have thousands of NASen, most of which will never talk to a particular AAA server. So it may make more sense to initiate on the client.

There were discussions about the operational requirements of the proposal. For example, do all the principals along the roaming relationship path need to implement Kerberos? Yes, typically the KDC trust relationships will correspond to the business relationships. This will enable the AAA server to get a ticket to the NAS by using Kerberos cross-realm trusts.

How do you find the appropriate Kerberos servers? This is handled via the DNS, as specified in the recent Kerberos/DNS drafts. So you need to advertise your Kerberos KDC via DNS SRV.

Does this imply that the Kerberos KDCs are on the Internet? Not necessarily -- you can protect them behind an IAKERB proxy.

What about non-repudiation? Kerberos cannot provide this, but CMS can. Kerberos can use certificates for authentication , though, via PKINIT.

What about computational demands? Kerberos does not require public key infrastructure or computations so the computational demands are very modest - you only need DES, although 3DES is probably advisable.

It was noted that there was Kerberos V source code available from MIT, and that Kerberos implementations can be quite small so that they are easily incorporated on NASen. Quite a few NASen already implement Kerberos, such as Cisco IOS. Interoperability among implementations has been demonstrated. So Kerberos is very much a known quantity.

Friday, March 23, 2001, Morning Session



Authentication Key Agreement (AKA), Pete McCann

AKA in Diameter draft was presented. This draft defines new AVPs for Diameter. This is protocol used in the UMTS networks to authenticate mobile nodes. 3GPP is the standard body defining this for UMTS networks. 3GPP has decided to use Diameter for network layer authentication and eventually access layer authentication for their all IP networks. This draft proposed two ways to carry AKA authentication parameters from home network (HA) to visited network (FA). The first method is using 2 round trip access request messages to Home to and the second is modify legacy AKA. This draft is not part of mobile IP extension, which is network layer authentication. It is used as the access layer authentication extension to Diameter.

A question came out whether we can use EAP instead. The answer was further research is needed for this. EAP is used for Nasreq extension and is used for dialup connections.

Results: it was decided to continue to collect input on this draft.

CMS for DIAMETER End-to-End security, Stephen Farrell

For hop-by-hop security Diameter uses IPsec between NAS and servers and SSL between servers and proxies.

This draft describes how end-to-end strong authentication and encryption can be achieved in the Diameter protocol, by encapsulating Cryptographic Message Syntax (CMS) objects in AVPs. The end-to-end sec CMS vs. Kerberos was discussed and the following CMS advantages were presented:

· Simpler inter-domain setup and operation than Kerberos

· No additional on line services for CMS

· Fewer message for CMS

Pat mentioned that in the initial deployment of the Diameter in 3G wireless, that end-to-end security is not required. These 3G networks are effectively private networks and so don't require end-to-end security. The standard bodies like 3GPP and 3GPP2 have set a firm release date and as long as Diameter is not available, they will select RADIUS. And Diameter with no end-to-end security is much better than RADIUS.

There was a big concern that Diameter end-to-end security would delay the protocol. Yet it is necessary because of the issues raised by proxies. Can we eliminate proxies? Answer seems that they are necessary in many circumstances. It was decided that the e2e security draft could proceed in parallel with the other DIAMETER drafts and would become a AAA Working Group document. Stephen Farrell believed that the CMS Strong Crypto draft could be ready for WG last call by July 1, 2001. It was decided that end-to-end encryption policy would exist at each end and the e2e protocol specification should discuss this.

It was agreed to have base specification separate from the security specification and both should be finished by July 1, 2001 deadline.

Then there was a discussion whether e2e security should be optional or required. Representatives from service providers indicated that they wanted e2e security to be optional in Diameter.

A canvas was taken as to which e2e security draft the WG members presented preferred. Those present preferred the CMS approach unanimously. The issue will be taken to the AAA WG mailing list to confirm that this is the WG consensus. If affirmed, work can still proceed on the Kerberos e2e draft, but it will be informational status.

The question came out whether to use proxies or not. Proxy functionality is mandatory to implement but not mandatory to use. Diameter implementations should support proxies.


3GPP requirements

Thad K. from AT&T Wireless presented and discussed the differences between 3GPP SA5 billing& charging requirements and AAA requirements.

The 3GPP Charging group is in the process of selecting a AAA protocolfor their all-IP network. This presentation was intended to ensure that their requirements are fulfilled in the AAA protocol. Requirements such as ability to run multiple copies of Diameter servers on a system not switching any process/ transaction between them were presented. There was also considerable discussion on reliability requirements. It was noted that the Diameter specification has incorporated many changes to enhance protocol reliability, including load balancing, failover/failback, application layer error messages, application layer heartbeat, and a transport layer profile, and that these were reflected in the latest drafts. Work on the application heartbeat is still in progress and is expected to be included in the next revision of the specification.

It was decided to revisit the differences based on the next version of the specification and come up with resolution ASAP to any remaining issues.

The major remaining transport are heartbeat and failover. There was discussion of timing requirements. There are two parameters to be concerned about -- the time between application layer heartbeats, and the failover time. The time between heartbeats is 30 seconds -- but should the failover time also be 30 seconds or can it be shorter, such as 6 seconds? It was noted that 6 second failover times have been suggested in other protocols. This provides the opportunity for several re-transmissions, perhaps as many as 6 with RTOmin = 1 second. On the other hand, the RTO timer can be larger than 1 second, and even with multiple re-transmissions, one does not know that the cause is not a route flap. According to Vern Paxson's thesis, the 1 percent confidence interval for route flaps is 30 seconds. So if you want strong assurance that a connectivity failure is not due to a route flap you need to wait longer than nRTO.

Application layer heartbeat timers will be discussed further on the mailing list and with Allison Mankin, the transport AD.

Interim meeting

It was noted that a AAA WG interim meeting would be held in May. The goal is to bring the Diameter documents to WG last call by July 1, 2001.

3GPP correspondence

Several people asked about the correspondence between 3GPP and AAA WG.

A copy of the correspondence will be included in the proceedings.


AAA Data Modeling
AAA Data Modeling
Diameter Strong Security Using GSSAPI v2
Diameter Strong Security Using GSSAPI v2
Diameter Data Modeling
3GPP TSG-SA5 (Telecom Management)
Protocol Requirements Differences Between...
Data Modeling & Diameter