1 / 16

EAP WG

EAP WG. EAP Key Management Framework Draft-ietf-eap-keying-03.txt Bernard Aboba Microsoft IETF 61, Washington, DC. Outline. Requirements Issues Summary Proposed Resolutions. The Requirements. Outlined by Russ Housley at IETF 56

lorie
Download Presentation

EAP WG

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. EAP WG EAP Key Management Framework Draft-ietf-eap-keying-03.txt Bernard Aboba Microsoft IETF 61, Washington, DC

  2. Outline • Requirements • Issues Summary • Proposed Resolutions

  3. 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

  4. 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

  5. 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

  6. Issues Summary • 21 Issues filed since IETF 60 • Type • 7 Editorial (257, 258, 270, 272, 273, 274, 277) • 14 Technical (254, 259, 260, 261, 262, 263, 264, 265, 266, 267, 275, 276, 278, 279) • Status • Accept – 52% (257, 258, 259, 261, 262, 265, 270, 272, 273, 275, 276) • Reject – 24% (260, 261, 263, 264, 266) • Open – 24% (254, 267, 277, 278, 279)

  7. Proposed ResolutionIssue 254 – Key Lifetimes • EAP does not support re-key of exported keys (MSK, EMSK, IV) without re-authentication. • Secure Association Protocol may support rekey of the TSKs without EAP re-authentication. • Keys expire on the AAA-server after they are transported. • Example: MSK not stored on the AAA server after it is sent in the AAA-Key • Example: AMSKs deleted on the AAA server after transport.

  8. Issue 254 – Key Lifetimes (cont’d) • Session-Timeout attribute sent by the AAA server in the Access-Accept indicates: • Maximum lifetime on the AAA server of the exported keys (MSK, EMSK, IV). • Maximum lifetime on the authenticator of the AAA-Key and all keys derived from it. • This is true whether or not a session has begun (e.g. EAP pre-authentication) • Where a session has begun, Maximum AAA-Key lifetime = Maximum re-authentication time • Authenticator may negotiate a lower AAA-Key lifetime with the peer, or may choose to expire the AAA-Key prior to the AAA-Key maximum lifetime. • Lower layer protocol may enable negotiation of a lower AAA-Key lifetime between the peer and authenticator.

  9. Issue 254 – Key Lifetimes (cont’d) • No AAA attribute controlling the maximum TSK lifetime on the authenticator • No need for one. • TSK lifetime can be negotiated between the peer and authenticator in the lower layer, based on authenticator configuration. • TEKs usually expire on the peer and server after the session ends • Requirement: Fresh session keys required prior to wrapping of the replay counter • Derivation of fresh session keys for every session, fresh replay counter one way to guarantee no reuse

  10. Proposed ResolutionIssue 262: Key Naming • MSK Name: This key is created between the EAP peer and EAP server, and is uniquely named by the [HMAC-SHA1 hash of the] concatenation of the string "MSK", EAP Method Type, EAP peer name, EAP server name, and unique material defined by the method. The EAP peer and server names are included only if they are exchanged within the method. Where a peer or server name is missing the null string is used. The definition of "unique material" is left to method specifications (appendix G defines this material for methods that have been published prior to this specification), but typically consists of nonces or sequence numbers exchanged within the method. Since multiple MSKs may exist between an EAP peer and EAP server, the unique material allows MSKs to be differentiated; it also provides uniqueness for methods that do not exchange peer/server names. The inclusion of the Method Type in the name ensures that each EAP method has a distinct name space. • EMSK Name:  The EMSK is named similarly to the above. Its name is the HMAC-SHA1 hash of the concatenation of the string "EMSK", the EAP Method Type, EAP peer name (if securely exchanged), EAP server name (also only if securely exchanged), and unique material defined by the method. • Add Appendix G with examples of key names used by various methods.  

  11. Proposed ResolutionIssue 267: PRF Negotiation • What PRF is used for AMSK derivation? • Default: PRF taken from IKEv2 (HMAC-SHA1) • PRFs can be securely negotiated within the EAP Method

  12. Proposed ResolutionIssue 275: AAA-Key Should Be Derived from AMSK • AAA-Key = MSK(0,63) • AMSK = KDF(EMSK, "EAP AAA-Key derivation for multiple attachments", length) • AAA-Key-B = prf(AMSK(0,63),"EAP AAA-Key derivation for multiple attachments", AAA-Key, B-Called-Station-Id, Calling-Station-Id, length) • AAA-Key-C = prf(AMSK(0,63),"EAP AAA-Key derivation for multiple attachments",AAA-Key, C-Called-Station-Id, Calling-Station-Id, length) • Where: Calling-Station-Id = STA MAC address • B-Called-Station-Id = AP B MAC address • C-Called-Station-Id = AP C MAC address • prf = hmac-sha1 • KDF = defined in Appendix F • length = length of derived key material

  13. Issue 277: Draft Organization • Draft mixes standards track, architecture and requirements material in one document • Meaning of normative language is different between standards track and requirements documents. • Result: The term MUST has different meaning in different sections! • Two distinct EAP use cases • Lower layers that do not cache the AAA-Key (e.g. PPP, IKEv2), • Lower layers that cache the AAA-Key (e.g. 802.11i). • Draft does not clearly articulate the incremental security requirements arising from AAA-Key caching • Question: Split the document? • Architecture + Requirements in one document • Standards Track material in another document • AMSK derivation • AAA-Key derivation • Key names • Key lifetimes

  14. Proposed resolutionIssue 278: Lifetime of Keys Internal to EAP Methods “When using TEKs within an EAP conversation or across conversations, it is necessary to ensure that replay protection and key separation requirements are fulfilled. For instance, if a replay counter is used,TEK rekey MUST occur prior to wrapping of the counter. Similarly, TSKs MUST remain cryptographically separate from TEKs despite TEK rekeying or caching. This prevents TEK compromise from leading directly to compromise of the TSKs and vice versa.”

  15. Issue 279: Secure Association Protocol Requirements • Request: Add the following requirements to the SAP requirements section: • A SAP instance must be bound to the particular instance of the EAP method that derived the AAA-Key. • A SAP must include a session identifier that allows the EAP Peer to distinguish one instance of the keying protocol from every other instance. • A mechanism must be specified to include a session identifier that allows the NAS to distinguish one instance of the keying protocol from every other instance. • The SAP must protect the EAP Peer from forgeries of keying protocol messages. • A mechanism must be specified to protect the NAS from forgeries of SAP messages.

  16. Feedback?

More Related