EAP WG EAP Key Management Framework Draft-ietf-eap-keying-05.txt Bernard Aboba Microsoft IETF 62, Minneapolis, MN

Outline Requirements Issues Summary Proposed Resolutions

The Requirements Outlined by Russ Housley at IETF 56 All AAA WG documents doing key distribution need to meet these requirements EAP Key Management Framework document chartered to analyze the security of the EAP system

Acceptable solution MUST… (Housley, IETF 56) Be algorithm independent protocol For interoperability, select at least one suite of algorithms that MUST be implemented Establish strong, fresh session keys Maintain algorithm independence Include replay detection mechanism Authenticate all parties Maintain confidentiality of authenticator NO plaintext passwords

Acceptable solution MUST also … Perform client and NAS authorization Maintain confidentiality of session keys Confirm selection of “best” ciphersuite Uniquely name session keys Compromise of a single NAS cannot compromise any other part of the system, including session keys and long-term keys Bind key to appropriate context

Issues Summary 7 Issues filed since IETF 61 Type 1 Editorial (277) 6 Technical (254, 279, 288, 289, 291, 292) Status Accept – 57% (254, 288, 289, 292) Reject – 0% Open – 43% (277, 279, 291)

Proposed Resolution to Issue Organization Problems Document mixes discussion of existing technology with analysis of potential future extensions. Causes confusion about how current implementations behave. Document touches on proposed extensions only briefly and does not analyze them for compliance with the security criteria. Proposals may not be accurately stated. Suggested Resolution: Split the document into two parts EAP Key Management Framework: Goal is to document and analyze existing applications (e.g. RADIUS/EAP, Diameter EAP, i) and implementations. EAP Key Management Extensions: Focus on documenting and analyzing extensions to EAP key management.

Issue 277 (cont’d) Suggested breakdown: Key management framework Section 1 Section 2 (minus AMSK and pre-emptive key derivation) Section 3 (EAP-Key SA) Section 4: Key Management (minus speculative material) Section 5: Handoff Support (minus speculative material) Section 6: Security Considerations Section 7: Security Requirements Key management extensions Section 2.4 (AMSK derivation) Section 3.2 (EAP-Key SA) Section 4 (Speculative Material) Section 5 (Speculative Material)

Proposed Resolution Issue 279 – Requirements Requirements document submitted by Jesse Walker Needs to be integrated with Section 7. Volunteer to review this submission + Section 7 and ferret out the high level requirements?

Issue 291 – Key Cache Synchronization Change submitted by Jari Arkko, noting disadvantages of method-specific key lifetime negotiation. Proposal: Accept. Any objections?

An Architectural Issue How is the EAP key cache managed on the peer and authenticator? To date, key names and cache architectures have been “link specific” What happens when a host is multi-homed? Example: , , interfaces Do we now have separate EAP key caches for each media? For each interface? Do we now have distinct key names for the same key, one for each media/interface? How does this impact inter-media handoff, code footprint, and complexity?

A solution Media Independence The EAP key cache is media independent and is managed at or above the EAP layer. Implication: all media should use EAP key names to manage cache entries. What about PSK support? What about the key name format? Does an ASCII format make sense?

Roadmap Produce split strawman based on -05 Post strawman links to the EAP WG list File additional issues on proposed changes Resolve issues Submit the split documents to the archive: Draft-ietf-eap-keying-06.txt Draft-ietf-eap-keying-ext-00.txt Bring key management framework document to EAP WG last call by IETF 63.

Feedback?