July 16, 2003 AAA WG, IETF 57 1

AAA WG Meetinghttp://www.drizzle.com/~aboba/IETF57/AAA/

IETF 57Vienna, Austria

Wednesday, July 16, 20031300 - 1500

July 16, 2003 AAA WG, IETF 57 2

Agenda• Preliminaries (15 minutes)

– Bluesheets– Minute Takers– Agenda Bashing– Document Status

• Diameter Mobile IPv4, Tom Hiller (15 minutes)– http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-mobileip-14.txt

• Diameter NASREQ, David Mitton (15 minutes) – http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-nasreq-12.txt

• Diameter EAP, Jari Arkko (15 minutes) – http://www.ietf.org/internet-drafts/draft-ietf-aaa-eap-02.txt

• Diameter Credit Control Application, John Loughney (15 minutes) – http://www.ietf.org/internet-drafts/draft-ietf-diameter-cc-00.txt

• Diameter Multimedia Application, Miguel Garcia (15 minutes) – http://www.ietf.org/internet-drafts/draft-belinchon-aaa-diameter-mm-app-01.txt

• AAA key management review, Bernard Aboba (15 minutes)• Roadmap (15 minutes)

July 16, 2003 AAA WG, IETF 57 3

Document Status• Charter: http://www.ietf.org/html.charters/aaa-charter.html• Published as an RFC

– Transport: RFC 3539• In RFC Editor Queue

– Diameter Base-17• IESG Review completed

– Diameter MIPv4-14• Completed AAA WG Last Call and comment resolution

– NASREQ-12• Work in progress

– Diameter EAP– Diameter Credit Control

• Initial reviews in progress– Diameter Multimedia

• Dropped due to lack of interest– Diameter CMS

July 16, 2003 AAA WG, IETF 57 4

AAA Key Management Review

Bernard AbobaMicrosoftIETF 57

Vienna, Austria

July 16, 2003 AAA WG, IETF 57 5

Key Management Overview• Key Management requirements presented by Russ

Housley at IETF 56• EAP Key Management Framework document to

provide system analysis– EAP, AAA, Secure Association requirements– Detailed discussion in EAP WG 2nd session

• AAA documents can no longer reference Diameter CMS (work discontinued)– Best alternative is Diameter Re-direct

• Outstanding Issues– Key naming/binding (EAP Key Framework)– Re-direct authorization

July 16, 2003 AAA WG, IETF 57 6

Acceptable solution MUST…– Be algorithm independent protocol

• For interoperability, select at least one suite of algorithms that MUST be implemented

– Response• Diameter supports IKE, TLS security

– Can negotiate ciphersuites, security parameters for protecting AAA sessions

• EAP provides algorithm, media independence– Any EAP method can work with any media and ciphersuite

• EAP provides a mandatory-to-implement method– Issue: Mandatory method does not support key derivation or

mutual authentication

July 16, 2003 AAA WG, IETF 57 7

Acceptable solution MUST…• Establish strong, fresh session keys

– Maintain algorithm independence• Include replay detection mechanism• Response

– Diameter security protocols (TLS, IKE) negotiate strong, fresh session keys to protect traffic, provide replay protection

• Key strength, replay protection can be provided regardless of key management algorithm

– Key strength, Replay protection are security claims for EAP methods

• Issue: Not all methods will provide “strong” keys• Issue: Not all methods will provide replay protection

– Proposal to add Key freshness requirement • Nonce exchange in EAP method guarantees MSK/EMSK freshness,

unique key naming• Nonce exchange in secure association protocol guarantees freshness

of transient session keys even if MSK/EMSK is not fresh

July 16, 2003 AAA WG, IETF 57 8

Acceptable solution MUST…• Authenticate all parties

– Maintain confidentiality of authenticator– NO plaintext passwords

• Response– EAP does not support PAP– Diameter requires mutual authentication between NAS and AAA

server, supports confidentiality• Issue: authorization issues being addressed

– Mutual authentication required for key-deriving EAP methods, secure association protocol

– Question: What does “maintain confidentiality of authenticator” mean?

• Support for identity privacy?

July 16, 2003 AAA WG, IETF 57 9

Acceptable solution MUST also …

• Perform client and NAS authorization

• Response– Client authorization issues being addressed in

RFC 2284bis– NAS/AAA server authorization issues being

addressed in NASREQ, Diameter EAP

July 16, 2003 AAA WG, IETF 57 10

Acceptable solution MUST also …

• Maintain confidentiality of session keys

• Response– MSK transport is protected by Diameter

transport security (IPsec, TLS) – Re-direct can restrict MSK access to those with

“need to know” (NAS, AAA server, EAP peer)– Transient Session Keys are derived via secure

association protocol

July 16, 2003 AAA WG, IETF 57 11

Acceptable solution MUST also …• Confirm selection of “best” ciphersuite

– Secure association protocol responsible for secure capabilities negotiation

• Used for communication of data between the EAP peer and NAS

– Diameter security (IPsec, TLS) provides for secure negotiation of security parameters

– EAP methods negotiate ciphersuites for use in protecting the EAP conversation

• Issue: Should we require that this negotiation be protected?

July 16, 2003 AAA WG, IETF 57 12

Acceptable solution MUST also …• Uniquely name session keys• Response

– Work in progress• EAP SA name: <EAP peer name, EAP server name, Peer Nonce, Server Nonce>

– Potential for multiple EAP SAs between an EAP peer and EAP server

• MK name: <EAP SA name, Method session-id>• MSK name: <EAP SA name, “MSK”, NAS Name>

– Binds the MSK to a particular NAS, avoids (inappropriate) reuse– Called-Station-Id best candidate for NAS Name since EAP peer may not know NAS-Identifier

or NAS-IP-Address

• EMSK name: <EAP SA name, “EMSK”>• TSK name: <Key name, peer Nonce, NAS Nonce>• Since names may be long, hash of the name used as a surrogate

– Issue: How do the NAS, EAP peer and AAA server come to agree on the Key names?

• NAS operates in pass-through, does not have access to MK or EMSK

July 16, 2003 AAA WG, IETF 57 13

Acceptable solution MUST also …

• Compromise of a single NAS cannot compromise any other part of the system, including session keys and long-term keys

• Response– MK, EMSK only available to EAP peer, server, not to the NAS– Key freshness required in EAP method, secure association protocol– Requires that MSK, TEKs, TSKs at one NAS not be derivable based on

quantities at another NAS• For “fast handoff”, implies that master session keys be on different branches of

the key hierarchy

– Diameter security uses dynamic, not static session keys, and well understood ciphersuites

• Compromise of one NAS will not reveal Diameter session keys of another NAS

• Issue: Do we need to say not to use the same IKE pre-shared key for every NAS?

July 16, 2003 AAA WG, IETF 57 14

Acceptable solution MUST also …• Bind key to appropriate context• Response

– Peer-Server• Binding is implicit; no explicit key lifetime negotiation or EAP SA “delete”

message

– NAS-Peer• Binding of TSKs to securely negotiated capabilities is the responsibility of

the secure association protocol• Binding of the key to the secure association SA the responsibility of the

secure association protocol

– AAA server-NAS• Binding and context provided by Grouped Key AVP

– Issue: Does the key name need to be provided along with the key in the Key Grouped AVP?

– Issue: What other AVPs are needed to define the context?

July 16, 2003 AAA WG, IETF 57 15

Summary

• We are making progress

• Key naming and binding issues the most challenging

• System analysis work will occur in EAP WG as part of Key Management Framework document