2.4.1 Authentication, Authorization and Accounting (aaa)

NOTE: This charter is a snapshot of the 58th IETF Meeting in Minneapolis, Minnesota USA. It may now be out-of-date.

Last Modified: 2003-10-24

Bernard Aboba <aboba@internaut.com>
David Mitton <david@mitton.com>
John Loughney <john.loughney@nokia.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:
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.
Done  Submission of AAA Transport as a Proposed Standard RFC
Done  Submission of Diameter Base as a Proposed Standard RFC
Done  Submission of Diameter NASREQ as a Proposed Standard RFC
Apr 04  Submission of Diameter EAP as a Proposed Standard RFC
Apr 04  Submission of Diameter Credit Control as a Proposed Standard RFC
Apr 04  Submission of Diameter SIP application as a Proposed Standard RFC
  • - draft-ietf-aaa-issues-05.txt
  • - draft-ietf-aaa-diameter-mobileip-15.txt
  • - draft-ietf-aaa-diameter-nasreq-13.txt
  • - draft-ietf-aaa-diameter-api-03.txt
  • - draft-ietf-aaa-diameter-cms-sec-04.txt
  • - draft-ietf-aaa-eap-03.txt
  • - draft-ietf-aaa-diameter-cc-01.txt
  • - draft-ietf-aaa-diameter-sip-app-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
    RFC3539 PS Authentication, Authorization and Accounting (AAA) Transport Profile
    RFC3588 PS Diameter Base Protocol

    Current Meeting Report

    Authentication, Authorization and Accounting WG (aaa)
    IETF-58 meeting minutes
    Date:   Thursday, November 13 at 1300-1500
    Chairs: Bernard Aboba <aboba@internaut.com>
             David Mitton <david@mitton.com>
             John Loughney <john.loughney@nokia.com>
    Scribe: Jari Arkko <jarkko@piuha.net>
    Diameter NASREQ, David Mitton
       The URL for this draft is
       The current revision is -13, published last month. The document has been 
    in the WG last call during the whole year!
       Draft 13 incorporates the following modifications:
       - Issues closed: 416, 417, 418, 423, 425, 426, 428.
       - Removed references to CMS.
       - There has been some code point updates.
       - Accounting-Auth-Method AVP was added.
       - Yet more work on RADIUS interactions was done.
       - Additional reference updates were made.
       Issues pending are:
       - Issue 430 - 3GPP comments, mostly editorial
       - Issues 427 & 431 - Identities in RADIUS translation. The issue was 
    filed by Pasi Eronen.
       Next steps for the document are finishing this document -- no more 
    issues are accepted unless they are serious.  We are awaiting for IESG 
    review comments.
       Glen Zorn: I'm puzzled because this is draft 13. In draft 11, you said 
    this is past WG last call. It seems to be a pattern that they are WG last 
    called, and three years later they go to an IESG review. I would ask the WG 
    to respect the WG last call. Bernard: There is no requirement that 
    there's just one WG last call, if there's substantial issues found in one WG 
    last call. The current comments -- such as those from 3GPP2 -- are IETF 
    last call comments, not WG last call comments. Randy Bush: Do you have 
    trouble with the actual changes? If not, lets get back to work. Bernard 
    Aboba: By the way, have you Glen Submitted any last call comments. Glen 
    Zorn: No.
    Diameter EAP, Pasi Eronen
       The URL for this draft is
       This documents the combination of RFC 3579 (RADIUS EAP) for 
    Diameter, and the addition of keying AVPs for Diameter. The document may be 
    dependent on the results of the EAP keying framework document 
    (draft-ietf-eap-keying-01.txt). There is no technical dependency, but the 
    security considerations of the whole system are described in the EAP 
       A couple of small changes have been done since Vienna:
       - Removed EAP-MTU AVP (issue 435)
       - Rewrote the security considerations section as a shorter section, 
    relying more on the EAP keying framework draft (issue 437)
       - Changed the AVP numbers to TBD.
       THe main open issue is how to transport keys, what kind of AVPs are 
    needed. The alternatives are:
       - A simple MSK AVP
       - More complex AVP for separate uplink/downlink keys and so on
       - Including even the initialization vectors
       Another open issue is the authorization step. The -02 draft added a 
    mechanism which allows the authorization AVPs to be retrieved via a 
    separate step, if redirects are used and the usual proxy chain 
    mechanism can not be used. Sense of the room: Is it necessary to support two 
    conversations: one between the NAS-home, and another via the proxy chain? 
    Pro: 1, Against: 0. One abstained.
       Next steps for this document is to see whether the EAP keying 
    framework document puts now requirements for this document. Hopefully we can 
    achieve WG last call soon.
       Bernard: One issue is that keys may be at least 64 bytes, not 
    necessarily exactly 64 bytes.
    Diameter MIPv4, Pete McCann
       Pete presented this draft on the behalf of Tom Hiller who could not be 
    here this time. The URL for this draft is
       The purpose of this draft is to support MIPv4 registration both for 
    foreign-agent care-of address and co-located care-of address modes of 
       The biggest issue is that we should not expose distributed keys to 
    entities that don't need to see them, such as intermediate Diameter 
    agents. The basic solution for this is done in the same manner as the 
    Diameter EAP application works. But after this was done, it resulted in it 
    being hard to support one existing feature in the document. But there 
    appears to be no requirement from 3GPP2 for this feature.
       The security mechanisms work using a Redirect server that allows the FA to 
    establish a direct TLS connection to the home AAA server.
       Steven Bellovin has reviewed the document and has raised a number of 
       - How is the preconfigured shared security association defined? The 
    document has been clarified.
       - What are the rules on firewalls mentioned in the document. The 
    response is that the firewall part has been ruled out of scope for this 
       - Key length has been increased from 64 to 128 bits.
       - Unclear how the FA and HA know and authorize each other. The 
    response for this issue is the direct TLS connection between the FA and the 
    home AAA.
       The remaining issues for this document are:
       - Who actually picks the SPIs? Changed from the home AAA to the 
    foreign agent.
       - Can the foreign AAA server also act as a redirect server?
         Bernard: I would agree there is no need to delete the 
    possibility that intermediaries can act as redirect servers.  But the 
    document should be clarified.
       - Issue 445: Radia Perlman's review. The authors wish that the review 
    could be finalized. In Radia's preliminary opinion the document is 
    incomprehensible. The authors will rewrite the introduction.  She also 
    complained that intermediaries will see the keys. But the TLS redirect 
    scheme will prevent this from happening.
         Pasi: I have serious objections to the terminology used. The three 
    keys are not all keys, two of them are nonces. Pete disagrees, thinks the 
    keys are still keys and have to be distributed. Pasi thinks that some AVPs 
    are nonces. Bernard: This issue has been raised before, lets take it 
    offline. Pasi: Key material is what you keep secret, nonces can be 
       Bernard: From a technical point of view, we are through WG last call, 
    IESG review, and now we have gotten another review. We need to address the 
    IESG comments, and then we can ask whether we have addressed them in a 
    satisfactory manner.
    Diameter Credit Control Application, John Loughney
       The URL for this draft is
       This draft started as an individual draft from 3GPP, and has gone 
    through several revisions before becoming a working group draft. The draft is 
    its official working group version 01.  The main changes since -00 
    document are:
       - Graceful service termination has been added (issue 419).
       - Abnormal-Termination-Reason AVP (issue 433) removed.
       - Separation of sent and received bytes was provided.
       - Failover procedures were updated
       - Cost-information AVP was enhanced.
       - Missing message flows for refund and price enquiry were added to the 
       - And so on
       The open issue which still need to be addressed are:
       - Update of the security considerations section based on Jari Arkko's 
    comments and Pasi Eronen's work in the Diameter EAP application.
       - A tarif change principle has been agreed, but not specified yet.
       - A re-authorization trigger scheme will also be needed.
       Since the document is getting large, a feature freeze is 
    suggested. The remaining issues need to be solved, and an editorial 
    clean-up is needed. Then a decision has to be made whether the draft is 
    ready for WG last call. John has been informed that a couple of 
    implementations are being worked on. 3GPP has also asked the IETF to 
    finalize this document.
    Diameter SIP application, Pete McCann
       The URL for this draft is
       Pete presented the Diameter SIP application on behalf of Miguel 
    Garcia-Martin who could not be here this time. This draft is designed to 
    support SIP applications in their AAA functions. It defines six new 
    commands, and the authors think it satisfies the requirements laid out for 
    it. Pete continued the presentation with an architecture picture that 
    shows how this draft can be used in the 3GPP IMS model.
       The changes from the last version are:
       o New name for the application to show that is a general SIP related AAA 
       o Some definitions and an applicability statement were added.
       o Some AVPs were renamed.
       o MAR command can now be used in a more generic fashion.
       o Some new scenarios were added to highlight that this can be used many 
    environments, not just the 3GPP one.
       o The IANA section has been touched up.
       Next steps for this document include resolving the four pending 
    issues, add clearer description of the semantics of the commands, add a 
    missing security considerations section, provide support to use SIP and 
    Diameter in conjunction of authentication methods that use HTTP Digest, and 
    perform a full review.
       Wolfgang Beck: Is there a plan to add media routing accounting?
       Pete: Accounting is not in the draft. We need to have a discussion 
    about that.
    o Multicast Security, George Gross
       This is a talk George made on monday in the MSEC working group. What 
    motivates the combination of MSEC and AAA is large scale secure 
    multicast groups that cross administrative domain boundaries. It is 
    necessary to enforce contractual relationships, and to allow the service 
    providers to control their multicast transit routing service. MSEC AAA 
    would also enable dynamic MSEC groups with the service provider AAA as the 
       Background reading for this document include:
       - Diameter base, RFC 3588
       - Generic authorization framework, RFC 2904
       - Diameter NASREQ
       - Generic policy token draft 
    (draft-ietf-msec-gspt-04.txt which will be submitted within a couple of 
    weeks). This document defines a signed policy object that defines who is 
    allowed to enter the group.
       The work is based on two different modes: the GDOI/AAA and 
    GSAKMP/AAA models. The GDOI pull-based roaming model. Here Diameter 
    NASREQ and Diameter MSEC are used between two domains.  Diameter AAA 
    server sends information to the domain's GC/KS (Group Controller / Key 
    Server), which manage the multicast clients via GDOI. A minimal amount of 
    extensions are needed for the NASREQ application to support MSEC. 
    Alternatively, credit control application could be used; this needs to be 
    looked at.
       The GDOI/AAA approach can leverage an existing IKE/ISAKMP AAA.
       Bernard: How would the identity used in either IKE or MIKEY relate to 
    this? George: That's a tough question. Bernard: Can this be an 
    authorization-only mechanism? George: I wouldn't characterize this like 
       The model that is being considered by MSEC is the GSAKMP 
    push-based AAA model. This is quite different from the pull model. The 
    domains would use only Diameter accounting between themselves in this 
    case. In GSKAMP/AAA, the authentication is based on PKI only, not NAIs. 
    Multicast policy token encodes membership authorization, acts as AAA 
    service ticket. This does not fit the Diameter NASREQ model, but uses 
    Diameter backend for accounting.
       The future direction of this work involves the definition of a 
    generic polocy token attributes to encode multiple service 
    authorizations. Long-term, Diameter extensions could be defined for MSEC.
       Bernard: It seems that there are some deployment problems in 
    multicast services that you are trying to address. George: Currently, 
    there is not much multicast services deployed, but you can imagine some 
    services such as gaming that could make this commercial. bernard: The 
    reason I ask is that there's been more interest in other groups to look at 
    the authentication issues, what you seem to define is looking more at what is 
    requirement for deployment.
       Bernard: Have you talked to the MAGMA group? George: Not yet, but would 
    like to get them involved.
    Roadmap (15 minutes) WG Chairs and ADs
       The first AAA meeting was held in March, 1999. The proceedings of that 
    meeting show the milestones to all complete in 1999. The sign of success it 
    to get the protocols done and deployed. Some implementations are being 
    worked on, and even some prototype deployments are being done.
       The proposal is to have the last AAA WG meeting in Seoul, Korea, in 
    March 2004. The Diameter EAP and cost control drafts can be revised and WG 
    last calls can be started. Then SIP AAA needs to be worked on to get it to be 
    ready for WG last call.
       Creg Webber: Has the MIBs charter item been dropped. John: Yes. Are you 
    volunteering. Greg: No. John: The IETF will not work on MIBs unless there is 
    interested folks to work on it.
       Pete McCann: What happens in the future? Would future 
    applications transition to the application WGs. Someone: just run a AAA 
    extensions BOF. Pete: But do we have to do that, for instance, in the case of 
    QoS authorization protocols? John: It would be possible to handle them in 
    the specific application area.
       Bernard: The suggestion is not to end the AAA WG, just that it should go 
       Bernard: There's been a general question of whether all AAA work in the 
    IETF should be done here. The general answer is no.
       John: Is this proposal acceptable (some amount of humming). Is this 
    proposal not acceptable (no one hums).
       Meeting was 


    Diameter NASReq Application Status
    Multicast Security with Authentication, Authorization, and Accounting
    Diameter EAP Application
    Diameter CC Application
    Diameter SIP Application