Current Meeting Report
Jabber Logs

2.4.2 Authentication, Authorization and Accounting (aaa)

NOTE: This charter is a snapshot of the 55th IETF Meeting in Altanta, Georgia USA. It may now be out-of-date.

Last Modifield: 02/11/2002

Bernard Aboba <>
D Mitton <>
Operations and Management Area Director(s):
Randy Bush <>
Bert Wijnen <>
Operations and Management Area Advisor:
Randy Bush <>
Mailing Lists:
General Discussion:
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.
  • - draft-ietf-aaa-issues-05.txt
  • - draft-ietf-aaa-transport-07.txt
  • - draft-ietf-aaa-diameter-12.txt
  • - draft-ietf-aaa-diameter-nasreq-09.txt
  • - draft-ietf-aaa-diameter-mobileip-11.txt
  • - draft-ietf-aaa-diameter-api-02.txt
  • - draft-ietf-aaa-diameter-cms-sec-04.txt
  • - draft-ietf-aaa-eap-00.txt
  • Request For Comments:
    RFC2924 I Accounting Attributes and Record Formats
    RFC2975 I Introduction to Accounting Management
    RFC2989 I Criteria for Evaluating AAA Protocols for Network Access
    RFC3127 I Authentication, Authorization, and Accounting:Protocol Evaluation

    Current Meeting Report

    AAA WG Minutes
    IETF 55
    Wednesday, November 20, 2002 at 1300-1500
    CHAIRS:	Bernard Aboba <>
    	      David Mitton <>
    Minutes:    Jari Arkko
    AAA Issues list:
    Document Status
    Diameter Base, Transport and MobileIPv4 Documents have completed IETF last 
    call. Base and Transport have received IESG comments, which are being 
    AAA WG last call will begin in NASREQ-10 as soon as the archive opens 
    Interoperability events
    There have been no Diameter interoperability events since the AAA WG last 
    met at IETF 53. 
    Diameter Base -- John Loughney
    IETF Last call expired on nov 5th. IESG evaluation results are 
    available online at
    UATIONS/draft-ietf-aaa-diameter.bal. The main issues are as follows:
        - John can agree with some of the comments directly and make the 
    edits, on some others we need WG input.
        - Definitions: need to use non-OS dependent terminology, need to 
    define what "user" means.
        - Transport issues: Does "RESET call" mean sending a TCP RST or an 
    application layer termination? How many SCTP streams should be created?
        - Redirect agents: Not clear if these should be application 
    agnostic.  Bernard Aboba: In my reading they don't have to be 
    application agnostic, but they can be.
        - Reserved bits: Shouldn't the spec say that they must be set to zero 
    and ignored upon receipt?
        - Security: What TLS/IPsec certificates should be used, and are there 
    any specific things that needs to be checked from the 
    certificates.  Bernard Aboba: Basic issue is that just 
    authentication through a certificate does not guarantee that the other side 
    is allowed to be a Diameter agent. Text has been proposed on the list.
        - Why is the flag "MAY Encr" when confidentiality is mandatory?  Need to 
    clarify this.
        - RAA messages: There is some confusion on these messages. Is a 
    nested sequence intended? This issue is still open.
        - Reordering of accounting records. There's a concern that there is no 
    way to determine that accounting records have been reordered. Proposed 
    solution is monotonically increasing record number.
        - The definition of end-to-end security needs to be improved, 
    perhaps the right term is "object security".
        - Is there any end-to-end authorization model provided? How does a NAS 
    know that it will be paid when an authorization comes from five proxies 
    away. Bernard: There is an implicit assumption that the path 
    represents authorization and business agreements.  Steven Bellovin: I am 
    concerned that there is lack of explanation on the security 
    architecture for AAA. All the issues are typically easy, except for 
    authorization which is always the hardest problem. Bernard Aboba: I think 
    this is a reasonable request. John Loughney: Should we document this in CMS 
    document?  Stephen Farrell: For some questions this is the right 
    document, but not for the authorization.  Steven Bellovin: I'm looking for 
    the top-level view. Bernard Aboba agrees to write an introductory 
        - A clarification was needed for Vendor ID.
        - Filter rules: Why are these different from the MIBs and PIBs?  
    John's proposal is to align. Pat Calhoun: I really don't understand why we 
    need to change, NASes support this type of filters.  John: I see, this is 
    building on current solutions, may not be reasonable to change. Bernard 
    Aboba: Yes. Finally, the WG agrees that the white space details etc need to 
    be resolved but the formats stay the same.
        - Is the use of IPAddress as a datatype misleading? Why not use a 
    union of InetAddressType and InetAddress? Does anyone have an opinion. Dave 
    Mitton: This would break backwards compatibility.  Pat Calhoun: The issue 
    came up when designing the protocol; separate AVPs for IPv4 and IPv6 would 
    lead to complexity, and we felt this approach was the right one. 
    Bernard: Since have to support backwards compatibility with Radius, we have 
    to have Framed-IPv6-Address AVPs in any case.
        - DiameterIdentity: should we use OctetString as we do now, or UTF-8?  
    Patrick Faltsrom suggests creating a separate profile for stringrep and how 
    it is used in Diameter. John says this approach sounds quite heavy. 
    Bernard: UTF-8 for this purpose complicates issues and does not allow 
    anything. However, for FQDNs the situation is different and we'll just use 
    whatever IETF has defined FQDN format to be. No need for new work.
        - IANA has asked an initial registry to be created either in the 
    document or elsewhere. The preference is latter. John volunteers to do 
    - The interesting topic is schedule. John promises a new revision before 
    Christmas, and thinks that most issues can be resolved without too much 
    Transport - Bernard Aboba
    There were several Transport issue, brought up by Steve Bellovin in IESG 
    review. Most are minor. Bernard will work with John Loughney to address 
    issues relating to SCTP stream usage. 
    Diameter MobileIPv4 - Bernard Aboba
    - The two issues that have come up are visible in the ID Tracker and in the 
    Diameter issues page. The first issue is from Bert Wijnen and largely 
    - Steven Bellovin's issue is technical. One issue is the use of 64 vs. 128 
    bit keys. His bigger problem is that this draft depends on several things 
    which have not been done.  He finds it hard to evaluate the draft until the 
    use of the keys has been specified. Bernard Aboba: Luis Sanchez has 
    reviewed draft. How to move forward? Steven Bellovin: I think you are 
    blocked until the security adivisors for both AAA and MIP can take a look at 
    the complete set of documents.
    Diameter NASREQ -- David Mitton
    David Mitton went over the remaining NASREQ issues, most of which are 
    resolved in NASREQ-10. This just missed meeting the IETF 55 
    submission deadline, and is available for inspection at: 
    As soon as the archive opens again, NASREQ-10 will be submitted, and will go 
    into AAA WG last call. So if you haven't read it already, please do. This 
    draft has been requested by 3GPP2, so it is on the fast track. 
    - Only four people present have read the document all the way through.
    - Major changes include section reorganization and removal of EAP to 
    another document. Added mapping of RADIUS 
    Acct-Termination-Cause to Termination-Cause AVP. RADIUS interaction 
    section has been updated with VSA handling. Keying AVPs have been 
    removed as a part of issue 355.
    - Open issues available at the Diameter issue list. Closed issues 
    include 255, 295, 297, 308, 321, 347, 348, 355. Open issues include the 
        - Reconciliation of AVP descriptions with RADIUS descriptions.
        - More proofreading needed
        - Glen Zorn has checked the status of 355 and there was no 
    discussion.  Why has the issue been adopted. Bernard: the split has been 
    made according to request from 3GPP2. He expects the EAP document to pick up 
    the key AVPs, even if they are currently not anywhere.  Glen Zorn feels 
    that there are other reasons for these keys than EAP. Bernard explains that 
    we don't put in things just because there might be uses for them. Tom 
    Hiller noted that 3GPP had not requested keying attributes in 
        - Is accounting definition good enough?
        - Pull up more text from RADIUS?
        - Do the RADIUS interaction rules for Origin-Hopst and 
    Origin-Realm AVPs work as needed?
        - Clarify User-Password & Tunnel-Password data.
        - Issues 331, 379, 380, 381. Glen says 331 i.e. ABNF issues is fine, as 
    the ABNF compiles OK.
    Diameter C++ API, Y. Ohba
    Y. Ohba presented on the status of the open Diameter 
    implementation. This has merged two previous open source Diameter 
    implementation projects into The Open Diameter Project 
    (  The C++ API is part of this, and has been 
    widely downloaded, indicating substantial interest. There has not been much 
    progress on the existing Diameter API recently (this is a WG work item), so 
    work has shifted toward progress on the C++ API. 
    Question: Is there interest in making the C++ API a separate WG work item? 
    Humming indicates that there is not interest in a separate work item for 
    Diameter Credit Control -- Harri Hakala
    - During last years pre-paid accounting has become very popular. Only 
    SS7-based protocols are used today for this purpose. For this reason there is 
    a need for a new IP-based protocol for this purpose. Current base 
    protocol mechanisms are not sufficient for this kind of protocol.
    - The specified protocol is general-purpose, not tied to any specific 
    - In 3GPP a stage 1 specification exists to show the requirements for 
    online accounting, and this draft follows the principles set out in those 
    specifications. What will happen next is that 3GPP will have a copy of this 
    in its specifications.
    Question: Is there interest in taking this on as a WG work item?
    Humming indicated strong interest in taking on this work item. 
    Diameter Multimedia Application - Maria-Carmen Belinchon
    - This draft is to allow AAA operations from SIP proxies. User 
    authentication is include. The draft also includes a function for 
    allocating the serving SIP proxy from an interrogating SIP proxy.  The 
    handling registrations and registration termination are also included.
    - A request was made to make this a working group item. Bernard said that 
    the request will be considered. Steven Bellovin said Allison Mankin is in 
    favor of this. Question: what is the deadline for this. Stephen Hayes: The 
    deadline for this is the Release 6 deadline.
    MIPv6/AAA - Franck Le
    - Mobile IPv6 is a routing protocol. Additionally, authorization and 
    authentication tasks are required to provide for roaming part of the 
    functionality. The functionality provoided is:
       - Mobile node authentication
       - Home agent assignment
       - Key distribution
    Question: What does it take to take this on as a AAA WG work item?
    Bernard Aboba: AAA WG takes on work items that have been vetted by 
    another WG or standards body. So the MobileIP WG would need to complete 
    work on MIPv6 as well as a MIPv6/AAA architecture document before AAA WG 
    could take on this work item. 
    - Comment: Several ongoing attempts at this: PANA, Secure Neighbor 
    Discovery, this draft.


    AAA and Mobile IPv6
    Diameter Base Update
    Diameter Multimedia Application
    Diameter credit control application
    Diameter C++ API and Open Diameter Project