2.4.1 Authentication, Authorization and Accounting (aaa)

Last Modified: 2003-06-25

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
Done  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-diameter-17.txt
  • - draft-ietf-aaa-diameter-mobileip-14.txt
  • - draft-ietf-aaa-diameter-nasreq-12.txt
  • - draft-ietf-aaa-diameter-api-03.txt
  • - draft-ietf-aaa-diameter-cms-sec-04.txt
  • - draft-ietf-aaa-eap-02.txt
  • - draft-ietf-aaa-diameter-cc-00.txt
  • Request For Comments:
    Accounting Attributes and Record Formats (RFC 2924) (75561 bytes)
    Introduction to Accounting Management (RFC 2975) (129771 bytes)
    Criteria for Evaluating AAA Protocols for Network Access (RFC 2989) (53197 bytes)
    Authentication, Authorization, and Accounting:Protocol Evaluation (RFC 3127) (170579 bytes)
    Authentication, Authorization and Accounting (AAA) Transport Profile (RFC 3539) (93110 bytes)

    Current Meeting Report

    time)Minutes of the AAA WG meeting in Vienna, Wed July 16 2003 at 1300-1500
    CHAIRS: Bernard Aboba <aboba@internaut.com>
            David Mitton <david@mitton.com>
    Scribe: Jari Arkko <jari.arkko@piuha.net>
    o Preliminaries (10 minutes)
      - Bluesheets
      - Minutes
      - Agenda Bashing
        No comments.
      - Document Status
        Diameter transport specification is now RFC 3539.
        Diameter base status is unknown. It is claimed to be held up by IANA 
    considerations, but IANA does not respond to e-mail and according to the 
    authors the IANA issues should have been resolved already. The chairs and 
    editors will ping the RFC editor and IANA for the status.
        IESG review has been completed on Diameter MIPv4 draft (-14).
        AAA WG Last Call has been completed on Diameter NASREQ draft (-12).
        Work in progress includes the following:
         - Diameter EAP application
         - Diameter credit control application
        Initial reviews are in progress with the following:
         - Diameter multimedia application
        Dropped due to lack of interest
         - Diameter CMS (end-to-end security)
    o Diameter MIPv4 (15 minutes), Tom Hiller
      - Tom has edited AAA-keys since January, which works closely with the 
    MIPv4 draft
      - Draft provides registration support for mobile nodes, as well as key 
    distribution. AAA keys update: delivers MN-FA and MN-HA keys to the 
    mobile, using nonces generated by the home AAA.
      - Security update is needed, since the AAA WG dropped support of CMS. 
    Guidance from the IESG says that we should give the keys only those 
    entities that really need them. The implication is that since current 
    draft sends the keys in the clear through the AAAF, this needs to be 
      - One solution is to use Redirects. Not clear to the author how to 
    eliminate the AAAF involvement, however. Decided to take a look at other 
    issues. Instead, take the keys out of some of the messages, and use a 
    separate TLS connection where the keys are sent. This adds some extra 
      - But the author wants to keep the AAAF in the loop as much as 
    possible, just get it out of handling keys. New Diameter commands 
    allocated for the purpose of requesting and sending keys between the HA and 
    the AAAH, or AAAF and AAAH.
      - As a result, only the HA and FA see the keys, AAAF and brokers do not 
    see keys. May create some extra latency. AAAF still sees 
    authorization attributes.
      - There is a possible security hole of a rogue AAA node in the home 
    network, where AAA broker lies about the identity of the home agent. The 
    author does not think is a practical issue.
      - Proposed plan is to review slides and current draft. Post a  new 
    version in about three weeks.
      - Bernard Aboba: Dramatic similarities between Diameter EAP and this 
    approach. Looks good that we are converging. Even the 
    authorization issue is the same.
      - Jari Arkko: I agree that the issues are the same.
    o Diameter NASREQ (15 minutes), Bernard Aboba on behalf of David Mitton
      - Issues closing 402, 403, 404, 405, 406
      - Issues open: 402, 404
      - Next steps: review all the changes
      - No more issues accepted at this time, unless they expose serious 
      - New draft version to be published and presened for IESG review, real 
    o Diameter EAP (15 minutes), Jari Arkko on the behalf of Pasi Eronen
      - Diameter-eap-02 is a "RFC 2869bis" plus key AVPs
      - Uses roughly the same approach as MIPv4 & AAA keys in avoiding key 
    exposure to proxies.
      - Still problematic to do authz check for NAS-Server after redirect - 
    certs extensions, domain checks, ...
      - Bernard: need to think about the reasons why NASes use proxies. In some 
    cases if they had e.g. real tables they might not need to use proxies, and 
    they could go direct
      - (Someone) This is a general problem, has appeared in other 
    o System level security and keying transport issues (30 minutes), 
    Bernard Aboba
      - Slide 6: Russ wants to have a mandatory protocol and algorithm, but the 
    current mandatory method does not generate keys in EAP.
        Russ Housley: I'm happy with your answer on the slide, but we should 
    require key-generating methods to be used when AAA is used.
      - Slide 7: Russ wants to have strong, fresh session keys. It turns out 
    that in some cases the EAP methods do not provide freshness. It may be 
    necessary to add a key freshness requirement for methods in RFC 2284bis 
    (EAP WG).
      - Slide 8: We need to authenticate all parties, no plaintext 
        We provide this as follows:
        - No PAP i.e. no plaintext passwords.
        - Diameter supports mutual authentication.
        - Remaining issue is authorization.
        What does maintain confidentiality of the authenticator mean?
        Russ Housley: I didn't want identity privacy. Just that if you have a 
    secret, you don't disclose it in an inappropriate manner.
      - Slide 9: We need to perform client and nas authorization: this one is 
    kind of interesting as we learned from Jari's presentation. We're still 
    working that too. But we are making some progress in understanding how we 
    can detect that the NAS is lying.
      - Slide 10: We need to maintain confidentiality of the session keys: 
    redirect can restrict the MSK to only those nodes that have a need to 
      - Slide 11: We need to confirm selection of best ciphersuite. We 
    understood this to affect all legs of the triangle. An open issue is 
    whether we should require that ciphersuite negotiation in EAP (if 
    provided by methods) be protected?
      - Slide 12: We need to uniquely name the session keys: This is work in 
    progress. On the list, we have discussed the naming of the EAP SAs, based on 
    peer and serve names, and pairwise nonces.
        Russ Housley: is the MK somehow related to the SA? 
        Another issue: What to use as NAS name? Bernard thinks 
    Called-Station-Id AVP is the best candidate, because in 802.11i this will be 
    the MAC address of the NAS.
        A third issue: We now know how to come up with the names. But how does 
    the nas get to know the names?
        Jari: Why do we need to name SAs?
        Bernard Aboba: Partially due to new functions such as roaming, but 
    mainly because roaming has shown us that this is an issue. It could 
    happen elsewhere too.
        Russ Housley: If you can't name something, its hard to manage it, i.e. 
    communicate it over the network, delete it etc.
      - Slide 13: Compromise of a single NAS cannot compromise any other part of 
    the system.
      - Slide 14: Bind the key to appropriate context. In the 
    peer-server case this is implicit, there is  no delete message. In the 
    NAS-peer case it is the responsibility of the secure association 
    protocol, such as the 802.11i 4-way handshake. In the AAA-NAS case it is 
    unclear. Does the key name need to be provided along with the key? Sense is 
        Russ Housley: well, if some of the components are available, maybe not 
    all have to be sent. If you hash names and nonces separately then you have to 
    communicate a lot smaller amount of data.
        Bernard Aboba: What other AVPs are needed to define the context?
        Russ Housley: how does the integrity mechanism protect this?
        Bernard Aboba: It's over the whole AAA request. If it goes through a 
    proxy, the binding is not clear. If you have end-to-end security or 
    redirects there is no issue.  Russ Housley: Ok, but you took a narrow 
    context. Its not just where, but also how it is used. E.g. MSK used as some 
    other key.
      - The summary is as follows:
        . We are making progress.
        . Key naming and binding issues are the most challenging along with AAA 
    authorization problems.
        . System analysis work will occur in EAP WG as a part of the keying 
    framework document.
    o Diameter Credit Control Application (15 minutes), John Loughney
      - The editors have done a heavy edit, but apologize since they 
    couldn't do a thorough review at the end.
      - The goal of the draft is a generic credit control scheme, for 3GPP as 
    well as WLAN. Should interwork with existing AAA protocols.
      - The draft has been updated to authorization-based model instead of an 
    accounting based application, due to earlier discussion on the list.
        The main changes are:
        - introduction and architecture diagram
        - new commands and AVPs
        - updated protocol operation, state machines, and examples
      - Tom Hiller: Why not submit proposals that use your messages, but use a 
    different procedure? 
        John Loughney: It would be general service. 
        Tom Hiller: Or just one set of command codes, but different usage -- 
    diameter commands codes are hard to come by.
      - Bernard Aboba: Is there a request here for a review?
      - Tom Hiller: We can arrange that.
    - tom: seems like you could substitue aa requests with mipv4 commands?
      john: that's the idea, you can substitute any application.
    - requests reviews from group
    o Diameter Multimedia Application (15 minutes), M. Garcia-Martin
      - This was originally a diameter application born in 3GPP for the IMS (IP 
    Multimedia System).
      - There is interest to move this work to the IETF.  When coming to the 
    IETF, we do not want to solve only the 3GPP specific problem, but a wider 
      - The draft provides SIP servers with authentication, 
    authorization, and accounting services. It is designed for SIP, i.e., RFC 
    3261. It includes 6 new Diameter commands and a few AVPs. It is a 
    solution for draft-ietf-sipping-aaa-req-03.
      - Changes from version 00 are the following:
        - Rewrote the whole draft, moved to XML,
        - Clearly differentiate normative and informative text.
        - Decoupling from SIP procedures.
        - Editorial corrections.
      - Next steps are as follows. Comments are coming in from reviewers. 
    Additional reviews are solicited. We need to analyze compatibility with 
    RADIUS, remove remaining 3GPP assumptions, crosscheck fullfillment of 
    requirements, and issue a new version of the draft as a WG item.
      - Bernard Aboba: This is ok.  But one question is what RADIUS 
    compatibility will be judged against, since there are no standards this 
      - (Someone): You do the SIP redirection through AAA, not sure if that's a 
    typical AAA function. Miguel Garcia: in a distributed case you need to have a 
    centralized database to say which server to go to. Its a routing 
    function. (Someone): This is more of a directory service than an AAA 
    service. Its just a redirection. Miguel Garcia: its not a static 
    directory server, the information may change dynamically.
    o Roadmap (15 minutes) WG Chairs and ADs
      - Next major steps in the WG are finishing MIPv4 and NASREQ drafts, and 
    then EAP or credit control in the next month or two.
      - Multimedia application will become a WG item.


    Diameter NASReq Application Status
    Diameter Multimedia Application
    Diameter EAP Application
    Diameter Credit-control Application
    MIPv4-Diameter Update