EAP WG EAP Key Management Framework Draftietfeapkeying05 txt

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

Outline l l l Requirements Issues Summary Proposed Resolutions

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

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

Acceptable solution MUST also … l l l 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 l l 7 Issues filed since IETF 61 Type l l l 1 Editorial (277) 6 Technical (254, 279, 288, 289, 291, 292) Status l l l Accept – 57% (254, 288, 289, 292) Reject – 0% Open – 43% (277, 279, 291)

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

Issue 277 (cont’d) l Suggested breakdown: l Key management framework l l l l 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 l l Section 2. 4 (AMSK derivation) Section 3. 2 (EAP-Key SA) Section 4 (Speculative Material) Section 5 (Speculative Material)

Proposed Resolution Issue 279 – Requirements l l l 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 l l l Change submitted by Jari Arkko, noting disadvantages of method-specific key lifetime negotiation. Proposal: Accept. Any objections?

An Architectural Issue l How is the EAP key cache managed on the peer and authenticator? l l l To date, key names and cache architectures have been “link specific” What happens when a host is multi-homed? l Example: 802. 16, 802. 11, 802. 20 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 l Media Independence l l 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 l l l 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: l l l 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?