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|
|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
Bernard Aboba <email@example.com>
David Mitton <firstname.lastname@example.org>
John Loughney <email@example.com>
Operations and Management Area Director(s):
Bert Wijnen <firstname.lastname@example.org>
David Kessens <email@example.com>
Operations and Management Area Advisor:
Bert Wijnen <firstname.lastname@example.org>
General Discussion: email@example.com
To Subscribe: firstname.lastname@example.org
In Body: subscribe aaa-wg
Lakshminath Dondeti, email@example.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
EAP key management issues: Bernard, A.
Review of the doc:
participants: EAP peer (multiple ports), Authenticator w/multiple ports, and then the AS
1a EAP auth
1b AAA key xport
2 SA establishment
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
Transient EAP keys
existing attr: session-timeout
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.
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
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.
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: 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.
-01- in WGLC, ending Aug 18th; please send comments
latest changes are editorial; no known open issues
in WGLC, ending Aug 26th
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
every QoS routing domain deploys an app server
subscriber DB <-> diameter cloud <-> app server
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.