Last Modified: 2004-06-24
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.
| 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 |
| RFC | Status | Title |
|---|---|---|
| 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 |
|
AAA WG meeting Tuesday, August 03, 2004, IETF-60, San Diego
Chair(s): 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 Clarifications 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 Conversation: 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 ++++++++++++++ NASREQ-17: fixing last minute issues/bugs, and addressing IESG review doc going to the RFC editor Changes: issues: 464, 466, 468 ++++++++++++++ CC-05: 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. ++++++++++++ AAA-URI: Updating 3588 -01- in WGLC, ending Aug 18th; please send comments latest changes are editorial; no known open issues ++++++++++++ Diameter-SIP-03 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: http://danforsberg.info:8080/draft-ietf-aaa-diameter-sip/ 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 why? % 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 ^ | v Bearer entity advantages: 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. |