2.4.1 Authentication, Authorization and Accounting (aaa)

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

Last Modified: 2004-06-24

Bernard Aboba <aboba@internaut.com>
David Mitton <david@mitton.com>
John Loughney <john.loughney@nokia.com>
Operations and Management Area Director(s):
Bert Wijnen <bwijnen@lucent.com>
David Kessens <david.kessens@nokia.com>
Operations and Management Area Advisor:
Bert Wijnen <bwijnen@lucent.com>
Mailing Lists:
General Discussion: aaa@ietf.org
To Subscribe: aaa-request@ietf.org
In Body: subscribe
Archive: http://www.ietf.org/mail-archive/web/aaa/index.html
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
Done  Submission of Diameter EAP as a Proposed Standard RFC
Done  Submission of Diameter Credit Control as a Proposed Standard RFC
Sep 04  Submission of Diameter SIP application as a Proposed Standard RFC
  • - draft-ietf-mobileip-reg-tunnel-09.txt
  • - draft-ietf-aaa-diameter-mobileip-19.txt
  • - draft-ietf-aaa-diameter-nasreq-17.txt
  • - draft-ietf-aaa-eap-08.txt
  • - draft-ietf-aaa-diameter-cc-05.txt
  • - draft-ietf-aaa-diameter-sip-app-03.txt
  • - draft-ietf-aaa-uri-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
    RFC3539 PS Authentication, Authorization and Accounting (AAA) Transport Profile
    RFC3588 PS Diameter Base Protocol

    Current Meeting Report

    AAA WG meeting Tuesday, August 03, 2004, IETF-60, San Diego

    Bernard Aboba <aboba@internaut.com>
    David Mitton <david@mitton.com>
    John Loughney <john.loughney@nokia.com>

    Operations and Management Area Director(s):
    Bert Wijnen <bwijnen@lucent.com>
    David Kessens <david.kessens@nokia.com>

    Operations and Management Area Advisor:
    Bert Wijnen <bwijnen@lucent.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/

    Minute taker:
    Lakshminath Dondeti, ldondeti@nortelnetworks.com

    NASREQ: some comments off the mic. Currently in IESG hands.

    Diameter Credit Control: waiting for Allison M., comment

    Diameter EAP finished WG last call

    DIAMETER-SIP and aaa-uri in AAA WG last call

    First session presentations:

    Diameter EAP: Pasi E.

    first WGLC ended in Seoul meeting

    Which application id to be used.

    Open: issues 465-7

    Proposal to incorporate 465 and 466 , but not 467

    Send to IESG

    %no discussion

    EAP key management issues: Bernard, A.

    Review of the doc:

    participants: EAP peer (multiple ports), Authenticator w/multiple ports, and then the AS

    0 Discovery
    1 Authentication
    1a EAP auth
    1b AAA key xport
    2 SA establishment
    2a unicast
    2b multicast


    Requirements: Outlined by Russ H at IETF-56

    Algorithm independence, fresh and strong keys, replay detection, authenticate all parties.

    + perform client and NAS authorization
    + Maintain confidentiality of sess keys
    + confirm selection of best suite
    + address cascading vulnerability problem
    + bind key to ctxt

    *Some relate to AAA*

    EAP: media, method and ciphersuite independence

    Types of EAP keys: calculated locally, exported by EAP method, etc.,

    EAP key hierarchy: changes: long term credential

    Key naming: MSK, EMSK, AMSK, AAA-Key

    Key lifetime issues: negotiation, out of band mgmt

    Lifetime mgmt:
    Transient EAP keys

    existing attr: session-timeout
    AAA-Key caching

    Glenn Z., force key lifetime to be of the same lifetime as the session can't have a key lifetime shorter than session lifetime

    Bernard: can conceivably do rekeying during a session do you rekey or reauth to renew?

    G Z: force rekey and reauth to be the same

    Pasi E: since EMSK is between client and AAA server; they talk EAP, which does not separate reauth and rekey.

    B A: in WPA can rekey without reauth

    Jari A: that's a rekey at a lower layer

    B A: need to be clear about what is being rekeyed

    Pat C: PMK rekey vs. PTK rekey

    B A: w.r.t exported keys there is no rekey without reauth (Transient keys can be rekeyed)

    G Z: in EAP that's true; from AAA pov it's not true.
    e.g., session timeout is forever; but we want to change key without reauth

    B A: this is not the same as fast resume

    J A: problem with AAA rekeying GZ proposes is that we need a new mechanism

    P E: EAP can't do that!

    J A: it's DIAMETER EAP; probably something that can be done in the future; not in any of the current WG docs

    ??: not good to cache EMSK

    J A: can you explain that? If you don't cache the EMSK, when can the app request an AMSK

    ??: app based

    J A: how would that work: chick and egg problem

    ??: discuss in

    B A: EAP WG

    more on this at the EAP WG ...


    Glenn Z: Alternative EAP keying approaches.
    1. RADIUS-keywrap

    Govt requirements

    This makes it easy for companies to sell to govt bodies:

    Just use IPsec does not work: run RADIUS over IPsec; hardly anyone supports it

    does not authenticate to a process which you are speaking

    vulnerable to Trojans (talking to right box, without the right server/process does not work)

    Is not possible for an app to know that IPsec is running; need verifiable security.

    App layer security is better.

    Pasi E: widely known that IPsec for app layer security does not work.

    G Z: IPsec might require a PKI for "proper" operation

    J A: keywrap is better. Works for DIA/RAD. key protected by TLS can be "keywrap"ped.

    P C: NIST approval is still harder. MD5 is still used

    G Z: no there is no MD5

    2. RADIUS-keyreq

    EAP rekeying and authentication are the same operation.

    AAA client authenticating to server or vice versa, and needs a new key is the app being considered.

    J A: Q: Is this not going to be applied for RAD/DIA?

    G Z: can't think of why not?

    J A: we are not doing another keying model!


    Missed some discussion between Bernard and Glen

    John L: does not impact RAD/DIA. So, no updates needed there.

    2nd session

    Diameter Mobile IPv4:

    18 & 19 Addressing IESG comments



    fixing last minute issues/bugs, and addressing IESG review doc going to the RFC editor


    issues: 464, 466, 468


    Addressing Allison M.'s discuss:

    I: Too 3GPP specific
    A: AVPs are extensible

    I: need to think broadly about SIP
    A: will add text

    I: Message flow diags too 3GPP specific
    A: will update to be more general

    IANA issues TB addressed

    Ted H Discuss:

    I 4.1 needs clean up: guidelines for interoperability
    A: proposed text ok'ed

    I: 5.5

    I: credit fragmentation

    (has been cleared)

    > Allison's Discuss needs to be resolved

    G Z: add service id AVP

    Glenn Z: don't understand how this is expected to work thru anything other than a case where there is a direct connection with a BCC server. Dropping that issue, but that was the issue.



    Updating 3588

    -01- in WGLC, ending Aug 18th; please send comments

    latest changes are editorial; no known open issues


    in WGLC, ending Aug 26th

    need comments
    need to analyze comaptibility with draft-sterman-aaa-sip

    B A: last opportunity to review; this will be deployed widely, so please review.

    will request SIP & SIPPING WG for review

    changes: SIP registration -> SIP soft state management
    -> digest-expected-response AVP
    updatd: authentication details section

    Please use the issue tracker:


    e.g., open issue 14: support for qop=auth-int
    SIP UA <--> SIP server <---> Diameter server

    SIP server creates the hash upon indication from DIAMETER server.


    DIAMETER QoS application


    % Authn Authz for QoS req, and Acc for QoS reservations
    More discussion in NSIS

    interface to app servers:
    allow them to dynamically authorize/de-authorize flows
    propogate knowledge of bearer flows

    Without this:
    every QoS routing domain deploys an app server

    with this:

    subscriber DB <-> diameter cloud <-> app server
    Bearer entity

    uniform interface etc

    lot of open issues ...

    need to carry authentication for NSIS

    ??: don't understand your QoS diagrams/model

    A: please send comments to AAA list of NSIS list

    J. L: as NSIS WG co-chair:

    need something like this in NSIS; not sure this fits exactly

    B A: after negotiation, what if a "big fish" kicks you off

    J. L: hum

    interested: several folks
    not interested: none (inaudible)

    will talk to Allison M on how to progress

    individual I-D, sponsored by her; will run WGLC process in AAA WG.

    this was agreed upon by other chairs and the author.

    This will/could be the last meeting of the AAA WG. The mailing list will continue to exist. There may be a subsequent DIAMETER maintenance WG.


    Diameter EAP Application
    EAP Key Management Framework
    Diameter Mobile IPv4 Application
    Diameter NASReq Application Status
    Diameter Credit Control Application
    Diameter SIP application
    Diameter QoS Application