July 16, 2003AAA WG, IETF 571 AAA WG Meeting IETF 57 Vienna, Austria Wednesday, July 16,

July 16, 2003AAA WG, IETF 572 Agenda Preliminaries (15 minutes) –Bluesheets –Minute Takers –Agenda Bashing –Document Status Diameter Mobile IPv4, Tom Hiller (15 minutes) – Diameter NASREQ, David Mitton (15 minutes) – Diameter EAP, Jari Arkko (15 minutes) – Diameter Credit Control Application, John Loughney (15 minutes) – Diameter Multimedia Application, Miguel Garcia (15 minutes) – AAA key management review, Bernard Aboba (15 minutes) Roadmap (15 minutes)

July 16, 2003AAA WG, IETF 573 Document Status Charter: 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, 2003AAA WG, IETF 574 AAA Key Management Review Bernard Aboba Microsoft IETF 57 Vienna, Austria

July 16, 2003AAA WG, IETF 575 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 2 nd 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, 2003AAA WG, IETF 576 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, 2003AAA WG, IETF 577 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, 2003AAA WG, IETF 578 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, 2003AAA WG, IETF 579 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, 2003AAA WG, IETF 5710 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, 2003AAA WG, IETF 5711 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, 2003AAA WG, IETF 5712 Acceptable solution MUST also … Uniquely name session keys Response –Work in progress EAP SA name: –Potential for multiple EAP SAs between an EAP peer and EAP server MK name: MSK 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: TSK name: 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, 2003AAA WG, IETF 5713 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, 2003AAA WG, IETF 5714 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, 2003AAA WG, IETF 5715 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