2.4.2 Authentication, Authorization and Accounting (aaa)

NOTE: This charter is a snapshot of the 56th IETF Meeting in San Francisco, California USA. It may now be out-of-date.

Last Modified: 2003-01-22

Bernard Aboba <aboba@internaut.com>
David Mitton <david@mitton.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
JAN 03  Submission of Diameter Base as a Proposed Standard RFC
FEB 03  Submission of Diameter NASREQ as a Proposed Standard RFC
JUN 03  Submission of Diameter EAP as a Proposed Standard RFC
DEC 03  Submission of Diameter CMS as a Proposed Standard RFC
  • - draft-ietf-aaa-issues-05.txt
  • - draft-ietf-aaa-transport-12.txt
  • - draft-ietf-aaa-diameter-17.txt
  • - draft-ietf-aaa-diameter-mobileip-13.txt
  • - draft-ietf-aaa-diameter-nasreq-11.txt
  • - draft-ietf-aaa-diameter-api-03.txt
  • - draft-ietf-aaa-diameter-cms-sec-04.txt
  • - draft-ietf-aaa-eap-01.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

    Minutes of the Authentication, Authorization and Accounting WG 
    (aaa)IETF 56, San Francisco, 
    Wednesday, March 19 at 
    CHAIRS: Bernard Aboba 
    <aboba@internaut.com>        David Mitton 
    Scribe: Jari Arkko 
    1. Agenda Bashing & 
    2. Document 
       The document status is as 
       - Diameter BASE-17 and TRANSPORT-12 are in the RFC Editor 
       - Diameter MIPv4-13 has completed IESG review, but is held waiting for an 
    author update, as well as completion of the MIPv4/AAA keys draft, which has 
    just been updated. 
       - Diameter NASREQ-11 completed AAA WG last call. Five issues remain 
       - Diameter EAP and CMS are in progress to be published in June and 
    December, 2003. We are probably going to split key attributes from EAP to a 
    separate draft to give more focus to the 
       - New working group items include documents for Diameter key wrap, 
    credit control, and 
    3. Diameter NASREQ, David Mitton (10 
       The latest draft was published Feb 14th. Changes in draft 11 include the 
       - Issues 389 and 395 have been 
       - Sections renumbered so that the outline is 
       New issues have been filed against draft 11: 402, 403, 404, 405, 406 
    Most serious things relate to RADIUS compatibility with ability to 
    fallback to RADIUS-only AVPs from either the server or client 
       The next steps for this document 
       - David comes up with proposed changes and sends them to the mailing 
       - New issue acceptance to be closed 
       - New draft version to be published with the next month and be sent to 
    4. Diameter Credit Control Application, John Loghney (10 
       This draft will become a AAA WG work item after addressing initial 
    review comments. The motivation for this work is on-line/prepaid 
    accounting, which is popular in mobile networks.  The draft enhances 
    Diameter base accounting messages with new AVPs, but there are no new 
    messages. This work has been officially included in 3GPP 
    specifications TS 32.225, which can be viewed at the 3GPP web site 
       Major changes in draft version 06 
       - A server or client is not required to implement all 
    functionality. That is, the M bit settings have been 
         Question: The 'M' bit does not reflect whether an AVP is 
    mandatory to implement or not -- just whether a Diameter peer can 
    discard it if it is not supported. Is the Credit Control using the 'M' bit 
       - New result code has been 
       On the to do list there are the following items: editorial 
    improvements, ID nits check, and working with 3GPP to ensure that it fits 
    their needs. This may be possibly nearly ready for WG last 
       Bernard Aboba: It is essential to get many reviewers. Can we get 3GPP 
    comments on this? 
       John: Yes, the intention is to request a "3GPP last call" and ask for 
    comments to be sent to the IETF AAA WG list. Comments from IETF and other 
    groups are solicited as 
       Next steps for this work 
       - Get reviews, address 
    comments.   - Issue a new version as a WG work item. 
    5. Credit Control and Prepaid Applications, Avi Lior (10 
       Avi Lior, Bridgewater systems, talked about his draft on RADIUS 
    prepaid extensions. Prepaid data services are very important to 3GPP, 
    3GPP2, and WLAN. AAA infrastructure is central in these services. 3GPP2 and 
    WLAN rely on RADIUS-based infrastructure. Deployment is happening 
       Requirements for these services include service portability and 
    continuity, no revenue leakage, support for multiple sessions, and 
    support for different prepaid schemes. Good picture of the 
    requirements in 
       Bernard Aboba: What does "no revenue leakage" mean? 
       Avi Lior: If there are errors in the network, you want to make sure that 
    you don't give free service. 
       Bernard Aboba: Is this the same as reliability of 
    accounting?   Avi: Roughly speaking yes it 
       Bernard Aboba: Who created the requirements draft, does this come from 
    some standardization organization? 
       Avi: The requirements draft is not related to our 
       One major difference in the approach of RADIUs pre-paid is that this is 
    handled with authentication/authorization messages, not accounting 
    messages. The Access request includes the prepaid operations and quota 
    allocation. Additional quotas can be allocated using accounting 
    messages, a new Access Request, or the use of RADIUS dynamic 
    [draft-chiba-radius-dynamic-authorization-07.txt]. The former two 
    mechanisms are problematic in large 
       When the prepaid account runs out, the session is not directly 
    terminated, but rather the user is directed to a web site to where he can, 
    for instance, use a credit card to continue the use of the 
       Bernard Aboba: Is RADIUS - Diameter translation for this 
    application feasible? 
       Avi Lior: We need to look at this. 
       Bernard Aboba: So we do have a problem with this? 
       Avi Lior: The fact of life is that Diameter and RADIUS need to live 
    side-by-side for a long time. If translation is not possible it is going to 
    be a problem. 
    6. Diameter Multimedia Application, Miguel Garcia (10 
       This is a diameter application tailored for the 3GPP IP Multimedia 
    Subsystem. Provides SIP servers with authentication, 
    authorization, and accounting functionality. Includes 6 new commands and a 
    few AVPs. This is an evolution of 
    draft-johansson-aaa-diameter-mm-app-02.txt, and is a solution for 
       John Loghney: I was going to be mention that 
    draft-ietf-sipping-aaa-req-02.txt is in WG last call. It is going to be 
    discussed in the SIPPING meeting as well right after this 
       Next steps for this work 
       - Get reviews, address 
    comments.   - Issue a new version as a WG work item. 
       - Decouple from SIP 
       Bernard Aboba: Here too we will need significant review prior to 
    making this an official WG work item. 
    7. Diameter Session Mobility, Dan Forsberg (10 
       Diameter base protocol can only handle static sessions, it can not 
    handle session mobility. Diameter MIPv4 application suggests that a new 
    session should be setup when movement happens. Dan's draft has a 
    requirement that movements must be possible without causing any actions in 
    the home 
       Problem is that when movement has occurred, how does the home AAA send 
    unsolicited messages to the foreign AAA? 
       James Kempf: Why does the home AAA server have to do it? 
       Dan Forsberg: There is AAAF on the picture as well, it is 
       The AAA mobility problem can be seen as a context transfer between two 
    local AAA 
       Question: Why isn't the context transferred between access routers, 
    rather than between AAA servers? Is this because of the difficulty of 
    doing such transfers between providers? 
       James Kempf: There's a lot of roundtrips in this protocol.  Should this 
    happen before, during, or after handover? 
       Dan Forsberg: This is an open issue. 
       James Kempf: Could the two AAA nodes act as Diameter peers and not go 
    through proxies higher in the AAA hierarchy? 
       Dan Forsberg: It may be possible but then the old access router would 
    have to know the address of the new access router. 
       Question: Can't this be learned through an inter-access point 
       James Kempf: It would be desirable to avoid additional roundtrips and 
    just have the two access routers discuss with each other.  Anyway, this is 
    just something to think about. 
       Someone: Is this mainly for Mobile IPv6 or for IPv4? Is this for 
    foreign agents or for access routers? Can this be used in the 
    co-located case? Wouldn't it be a problem if the both access router and 
    foreign agents are used at the same time. If co-location is not used, then 
    both would be handling AAA and it seems like a conflict would result. 
       Jessie Walker: One advantage of the hierarchical approach is that it 
    allows the security properties to be stated. One can't pass around keys 
    directly and maintain the desired security 
    issues:   - 
    Security   - Performance and 
    scalability   - Session updates between two different 
    domains   - Relationship with mobility 
    protocols   - Race condition requirements described in the 
    steps:   - Further study with the Diameter MIPv4 
    application.   - Performance 
    8. Diameter APIs, Yoshihiro Obha and James Kempf (10 
       No one to present 
    9. Diameter Mobile IPv4, Tony Johansson (10 
       No one to present 
       Someone: I had a question on MIPv4. About nine months ago issue 326 was 
    filed, but as I recall it hasn't been resolved. The Mobile IP WG should 
    answer the issue but they have not done so 
       Bernard: Your issue is not listed as open. Checking the list, it says the 
    status is Rejected. 
       Jari, do you remember anything about it?  
       Jari Arkko: No. 
       Bernard Aboba: Why don't you ask this question on the list? Maybe 
    someone will remember. 
    10. Diameter CMS, Stephen Farrell (10 
        No one to present 
    11. Issues in AAA Key Distribution (20 minutes), Russ 
        Bernard Aboba: Let me start with some sobering facts: no AAA 
    application supporting key distribution has ever been approved as an IETF 
    Proposed Standard. RFC 2548 is Informational and 
    vendor-specific. Diameter MIPv4 is blocked due to security issues. No 
    progress on Diameter EAP or CMS.  
        So the question is: What does AAA WG need to do in order to make more 
    progress? Are there aspects of the problem that we have missed? What 
    criteria does the IESG expect us to meet? To answer these questions we have 
    invited Russ Housley, the incoming security area director, to give us some 
        Russ Housley: Some people are concerned that working group outside the 
    security area is designing a key management protocol. 
        - Key management protocols are 
        - An expert can easily miss a 
        - Peer review by multiple experts is 
        There are also concerns with 
        - Employs new key distribution architecture, with poorly 
    understood security properties. Three party models have been studied but 
    these do not align directly with 
        - Select one e2e mechanism to protect distributed 
        - Needs robust key naming 
        - Needs to establish fresh session keys i.e. not get the same key 
        - The principle of least privilege not followed. That means the 
    session keys should not be exposed to parties that do not have an 
    absolute essential reason to see the key 
        An acceptable solution 
        - Be algorithm independent. For interoperability, select at least one 
    suite of algorithms that MUST be 
        - Establish strong, fresh session keys. Maintain algorithm 
        - Include a replay detection mechanism for all 
        - Authenticate all parties. Maintain confidentiality of the 
    authenticator. Public key mechanisms could be used to send keys so that 
    only the recipient who has the private key can come back with the sent key. 
    No plaintext 
        The solution MUST 
        - Perform client and NAS 
        - Maintain confidentiality of the session 
        - Confirm selection of the "best" 
        - Uniquely name session 
        - Compromise of a single NAS cannot compromise any other part of the 
    system, including session keys and long-term 
        - Bind key to appropriate 
        To me, the question is what's next. This was what the 
    requirements are and Bernard tells you more about how to get this 
        Someone: You mentioned EAP, will you reject EAP as well before it 
    solves these problems? 
        Russ Housley: No, that's not what I meant. These issues will be 
    presumably addressed in the EAP Keying Framework draft being worked on in 
        Bernard: Where do we go from 
        - We need a fresh start on Diameter MIPv4. Look at the whole system. 
    Make it clear how to meet the requirements articulated by Russ. 
        - We need an EAP key framework document. This will describe the 
    architecture and security requirements for each element of the system and 
    analyze how they interact. It will also address key naming and binding 
    issues. This is being done in the EAP WG in 
    draft-aboba-pppext-key-problem-06.txt. The next revision will attempt to 
    address Russ's requirements explicitly. 
        - Split out Diameter key wrap into separate document from Diameter EAP. 
    This will allow more focus in this critical part of the document. 
        - Take a fresh look at Diameter CMS. Can we remove deployment 
    barriers? Can we decrease complexity of the specification? Any 
        Anybody want to comment on the barriers? 
        Jessie Walker: I think it's a curiosity. Is anyone going to 
    implement Diameter CMS? If not, then why are we working on it? 
        Robert Moskowitz: I have a question. I'd like to know if there's any 
    performance measurements that have been done with the Diameter CMS 
    application? Its not very lightweight. It would be very worthwhile to get 
    some numbers. 
        Bernard Aboba: Would the CMS numbers from pure CMS (not Diameter CMS) 
    implementations be sufficient?  
        Robert Moskowitz: Not sure. 
        Russ Housley: the S/MIME group is doing interoperability tests and 
    there should be at least 4-5 implementations for which you can get some 
    performance data. 
        Jessie Walker: What comes to my mind is mainly the complexity. 
        If its too big for embedded implementations, it's the wrong 
        Paul Funk: I suspect people are sufficiently happy with 
    hop-by-hop security. Once Diameter starts to carry money in some format, 
    then its an issue. 
        Bernard Aboba: But we do already have usage-based billing. 
        Paul Funk: Yes, if there would be attack that can be used to cause an 
    incorrect bill to be sent. 
        Bernard Aboba: If you have an untrusted proxy handling accounting 
    records and it is compromised, it can forge accounting data. Isn't that 
        Randy Bush: I just wanted to remind the WG that not everybody is happy 
    with hop-by-hop security. I have been warning about this before. And we are 
    now paying for the proxy architecture, and we are unhappy. But we are far 
    less unhappy than if the kind of attacks just were discussed were to 
        Russ Housley: I wanted to clarify that the first slide was not a 
    reason to say "STOP", but rather to make sure that the security area is 
    12. Any Other 
        Francis Dupont: Now, Mobile IPv6 is ready. I propose to resume the work 
    on AAA and Mobile IPv6. Bernard: Need to talk about this with the Mobile IP 
    Meeting adjourned. 


    Diameter NASReq Application Status
    Diameter Session Mobility
    Diameter Credit Control Application
    Credit Control and Prepaid Applications
    Key Management in AAA
    Diameter Multimedia Application