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

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)

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.

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.

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

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.    

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

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

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

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

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.

Feedback?