Current Meeting Report

2.3.2 Authentication, Authorization and Accounting (aaa)

NOTE: This charter is a snapshot of the 53rd IETF Meeting in Minneapolis, MN USA. It may now be out-of-date. Last Modified: 11-Feb-02
Bernard Aboba <>
David Mitton <>
Operations and Management Area Director(s):
Randy Bush <>
Bert Wijnen <>
Operations and Management Area Advisor:
Randy Bush <>
Mailing Lists:
To Subscribe:
In Body: subscribe 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:
Done   Submission of requirements document as an Informational RFC.
Done   Submission of evaluation document as an Informational RFC.
Done   Submission of design team recommendations on protocol improvements.
Done   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:
RFC2924 Accounting Attributes and Record Formats
RFC2975 Introduction to Accounting Management
RFC2989 Criteria for Evaluating AAA Protocols for Network Access
RFC3127 Authentication, Authorization, and Accounting:Protocol Evaluation

Current Meeting Report

Minutes of the AAA WG
IETF 53, Minneapolis, MN, USA
March 21, 2002, 1300-1500
Chairs: Bernard Aboba <>, David Mitton <> (regrets)

Sivasundar Ramamurthy <>
John Vollbrecht <>


Preliminaries [15 minutes]
Agenda bashing
Blue sheets
Call for minute takers (2)
Document status
AAA Milestone review
Connectathon Report (David Frascone)

Diameter base draft, John Loughney (10 minutes)
Credit control application, Hari Hakala (5 minutes)
Mobile IPv4/AAA, Tony Johansson (10 minutes)
CMS Security, Pat Calhoun (10 minutes)
Transport draft, Bernard Aboba (5 minutes)
NASREQ draft, David Spence (10 minutes)
NASREQ keying issues, Jesse Walker (10 minutes)
Accounting (10 minutes)
Diameter multimedia application (5 minutes)
Mobile IPv6/AAA (10 minutes)
Draft-dupont-mipv6-aaa-01.txt, Maryline Laurent-Maknavicius
Draft-le-aaa-diameter-mobileipv6-01.txt, Franck Le

AAA WG Document Status

Published so far:
Accounting: RFC 2924, 2975
Requirements: RFC 2977, 2989, 3141
Protocol evaluation: RFC 3127
Previously unpublished docs referenced by RFC 2989
RFC 3141: CDMA 2000/AAA Requirements
RFC 3169: NASREQ Criteria

Completed WG last call with comments:
Draft-ietf-aaa-issues-05.txt (not for publication)
Draft-ietf-aaa-diameter-09.txt (Standards track)
Draft-ietf-aaa-transport-05.txt (Standards track)
Draft-ietf-aaa-diameter-nasreq-09.txt (Standards track)
Draft-ietf-aaa-diameter-mobileip-09.txt (Standards track)
Draft-ietf-aaa-diameter-cms-sec-04.txt (Standards track)

Not yet ready for WG last call:
Draft-ietf-aaa-diameter-api-01.txt (Informational)
Not yet WG work items:

WG Last Call Summary

Issue list:

70 issues raised in WG last call (244 , 313)
49 closed
6 rejected
26 still open
150 issues raised in second WG last call (94 , 243)
93 issues raised in first WG last call

41 issues (67 in previous WG last call)
32 closed (244, 245, 247, 249, 250, 252, 253, 254, 256, 257, 259, 260, 261, 262,
263, 268, 269, 270, 271, 273, 274, 275, 277, 279, 281, 282, 283, 285,
287, 288, 289, 310)
4 rejected (248, 272, 280, 284)
5 still open (218, 302, 303, 304, 311)

8 new issues (42 in previous WG last call)
4 closed (276, 279, 291, 310)
1 rejected (307)
4 still open (218, 278, 312, 313)

14 new issues (25 in previous WG last call)
6 closed (250, 264, 265, 266, 267, 286)
1 rejected (292)
8 still open (218, 290, 296, 298, 299, 301, 305, 306)

12 new issues (11 in previous WG last call)
6 closed (246, 250, 251, 264, 293, 309)
0 rejected
9 still open (188, 189, 190, 255, 294, 295, 297, 300, 308)

1 new issue (5 in previous WG last call)
0 closed
0 rejected
2 still open (199, 258)

AAA milestone review

The chair provided the current versions of the drafts: Diameter Base -09, MIP - 09, CMS - 04, NASREQ - 09, and Transport - 05. He acknowledged that we are a year behind and that our progress, though good, has not been quick enough. He called for the group to read all docs and file issues ASAP; another last call will be issued from 4/2 to 4/16.

Connectathon Report

We forgot about David Frascone's Connecthon Report (sorry, David).
However, he sent in the following notes via email:

From: On Behalf Of David Frascone
Sent: Friday, March 22, 2002 9:19 AM
Subject: [AAA-WG]: Interop Results / Request

Since we ran out of time in the meeting, I thought I'd give a brief synopsis of the testing that occured at Connectathon: No one showed up.

Well, to be fair, there were several Mobile-Ip vendors present that had AAA servers, but none of them supported the applications / extensions that we wanted to test.

On a good note, I was able to get a successful interoperation of Nasreq, over the 'net.

So, here is a synopsis of what has been interoperated:

o Base Protocol
o TLS (only once)
o Mobile-IPv4
o Accounting
o Nasreq (only once, and AAR/AAA only, no DER/DEA)

And, here is what really needs to be hammered on:

o TLS - Since it has only interoperated once, it needs more testing.
o Nasreq - Needs more testing, and DER/DEA needs to be tried.
o CMS Security
o Diameter over IPSec

All of the Nasreq interoperation has been done across the net. Since all of the tests that need to be done are basically point to point exchanges, internet tests should be more than sufficient. (Mobile-IP is very difficult to test when you're not in the same room, but the other tests are not as complex to set up)

So, my request: If you have implemented, or are implementing any of the untested extensions *please* send an e-mail to this list (or to me) so we can test.


Diameter Base -09 Draft

John Loughney presented the current status of the base draft (draft-ietf-aaa-diameter-10.xt). The draft needs closure and comments are appreciated.

Interoperability remains the main focus of the draft; new features will need to meet a *very* high bar.

A list of rejected issues with reasons was provided. The presenter called for reviews on DNS usage (section 5.2), Accounting state machine changes (section 8.2), and the split between Diameter URL and ID (issue 286).

As far as security is concerned, the WG would require or strongly recommend Diameter nodes to implement same security mechanism across peer-to-peer connections. If IPSec is used, the node should have mechanism to prevent non-IPSec protected traffic from reaching the node. Also, issues that apply to PKI need to be discussed.

Diameter Credit Control

A new application for Diameter Credit Control was introduced next (draft-hakala-diameter-credit-control-01.txt). While the objective is to support real time cost and credit control, application features include Accounting messages (ACR and ACA) with additional AVPs, and session based credit control. Mailing list messages have suggested need for supporting one-time events like balance check and refund, and spontaneous updates.

An 02 version will be created after IETF53. Some of the open issues include whether a new application-id is required. The Base text needs to be clarified to indicate that a new application id is not required just because some vendor-specific AVPs are used; a new application id is only needed when new commands are introduced or changes to the ABNF. It still needs to be decided whether this will be a new work item for the WG; until the AAA WG finishes current work items it cannot take on new ones.

Mobile IP -09

Tony Johansson presented the current status of the Mobile IP draft (draft-ietf-diameter-mobileip-09.txt). Some of the open issues include ABNF/table inconsistencies, and a new AVP (code: 55) for Event-Time-stamping. Minor corrections in the current draft are regarding the use of FA-Host AVP, and the issue of Session-timeout vs auth-lifetime vs key-lifetime.

Issue #299 concerning MN handoffs was discussed in detail. A couple of solutions have been proposed. One was requiring each sub-domain to have only one AAAH or to have a synchronization mechanism between AAAH servers. The other was require MN to support an updated GNAIE draft that includes the definition of AAAH NAI. Including AAAH NAI will guarantee that the user ends up in the same initial AAAH. Audience supported the second solution and this is currently being pursued with the Mobile IP WG (GNAIE draft may come back!).

Issue #301 regarding securing the AAAH generated keys was another issue discussed. There was a big confusion on whether the WG interpreted the security review of this draft correctly: did the review suggest periodical refreshing of the AAA generated keys or the MN-AAA key itself? This was left unresolved as time ran out.

CMS Security -04

An update on CMS security (draft-ietf-diameter-cms-04.txt) was provided by Pat Calhoun. Changes include removal of left over text, issue of deleting expected AVP and knowing when encryption is needed, removal of restrictions, AVP reordering, and processing of grouped AVPs (new section 1.7).

Transport -05

Bernard Aboba provided a brief status update of the Transport draft (draft-ietf-diameter-transport-05.txt). Some of the open issues are 199, 247, 258. Issue 258 was resolved during the meeting; the issue was whether the client should do a CER or DWR upon a reconnet. The audience pointed out that the state machine does provide the answer for this. Issue 199 will be presumed closed by the rewrite of the transport state machine in -05. Issue #247 was resolved by a change to the Base document. Thus, it appears that there are no currently open issues against this document.


A detailed update on NASREQ (draft-ietf-diameter-nasreq-09.txt) was provided by David Spence. A list of issues that are currently discussed was provided.

Bernard Aboba gave a presentation on some of the open issues relating to AAA/EAP. These issues represent areas for clarification within RFC 2869 and thus are not unique to Diameter NASREQ.

The issues included:

1. Should a Reply-Message attribute sent within a AAA/EAP conversation bet transport to an EAP-Request/Notification?

a. What if there is an EAP message attribute and a reply-message attribute in the same AAA message?
b. Will AAA server be expecting an Access-request/EAP-message/EAP-response/notification?

The recommendations here are that the AAA server should send EAP message/EAP request/notification instead of Reply-message. If received, NAS should translate Reply-message to EAP-request/notification. And if an EAP-message is in the AAA packet, a Reply-message MUST NOT be included.

2. Multiple EAP messages in the same AAA message. It was pointed out that the AAA server can do this, but it will violate RFC 2284. The consensus was not to allow this. Same with inclusion of reply-message with EAP message attributes, if translated to EAP request/notification.

3. Some corner issues were also presented and the group felt that bad things should be outlawed rather than have NAS server fix situations that arise from these bad things. Glen Zorn noted that some of the "corner conditions" were in fact OK messages, so we need to refine the list of prohibited message combinations further prior to resolution.


Jesse Walker made a presentation regarding Security issues with the NASREQ Keying Attributes. The motivation for the work is that IEEE 802.11 security does not work and that TGI wants to use AAA servers for authorization and key distribution. But it seems that Diameter NASREQ may not meet TGI's key distribution requirements!

The issue is that the Diameter NASREQ key distribution functionality consists of two two-party key exchanges: one between the AAA server and the client, which is carried out in the EAP exchange; and another between the AAA server and the NAS, carried out via the NASREQ keying attributes. Jesse Walker's concern is that two two-way key exchanges do not equal a secure three-way key exchange.

The Objective is to enhance NASREQ to meet 802.11 key distribution requirements. Some of the discussions on issue prior to meeting involved:

a. Simplification of combining NASREQ state machines with those at different layers of protocol stack.

b. Need for new fields (new AVP) in message exchanges for key distribution between NAS and AS.

The resolution to the presentation is:

a. Jesse Walker and Russ Housley agreed to prepare a draft within 30 days explaining what is wrong with the current NASREQ Keying attributes, and proposing an alternative.

b. The AAA WG will seek the appointment of a security advisor to review the draft and rule on its validity. It was noted that the AAA WG's current security advisor, Steve Bellovin, has accepted the position of IESG Security Area Director, and so is too busy to do the review, so we will need to get someone else.


The session concluded with a brief presentation by Franck Le on Mobile IPv6 AAA Requirements (draft-le-add-mipv6-requirements-00.txt). Work in AAA Support for MIPv6 is needed in order to enable large scale deployment; also, current Mobile IP application does not apply to MIPv6.

The Draft is result of off-line discussion and it lists requirements of what MIPv6 diameter should support. The status of MIPv6 does not impact AAA MIPv6 work. While the final objective is MIPv6 support, requirements are the first step. The work has been accepted by AAA WG


Requirements for Diameter Support for Mobile IPv6
Diameter Base Specification
Key Distribution Observations
Diameter credit control application
Provably Secure Session Key Distribution- The Three Party Case
3GPP-IETF Status Report
Current Status of 3GPP SIP related Internet Draft dependencies
Diameter Issues
Issues (Text list)
Updates - Issues