EAP WG EAP Key Management Framework Draft-ietf-eap-keying-03.txt Bernard Aboba Microsoft

Outline The problem The participants The conversation The requirements The invariants EAP key hierarchy Key naming Key lifetime issues

The Participants | | | EAP | | Peer | | | | | | Peer Ports / | \ Phase 0: Discovery / | \ Phase 1: Authentication / | \ Phase 2: Secure / | \ Association / | \ / | \ | | | | | | | | | Authenticator Ports | | | | | | | Auth. | | Auth. | | Auth. | | | | | | | \ | / EAP over AAA \ | / (optional) \ | / \ | / | | | AAA | |Server | | | AAA WG

Conversation Phases Phase 0: Discovery Phase 1: Authentication 1a: EAP authentication (RFC 3748) 1b: AAA-Key Transport (optional) Phase 2: Secure Association Establishment 2a: Unicast Secure Association 2b: Multicast Secure Association (optional) EAP WG AAA WG Lower Layer

The Conversation EAP peer Authenticator Auth. Server | | | | Discovery (phase 0) | | | | | | EAP auth (phase 1a) | AAA pass-through (optional) | | | | | | AAA-Key transport | | | (optional; phase 1b) | | | | | Unicast Secure association | | | (phase 2a) | | | | | | Multicast Secure association | | | (optional; phase 2b) | | | | |

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

EAP Invariants Media Independence EAP methods can operate on any lower layer meeting the criteria outlined in [RFC3748], Section 3.1. EAP methods cannot be assumed to have knowledge of the lower layer over which they are transported. Method Independence Authenticators can support any method implemented on the peer and server. Authenticators acts as forwarders for methods not locally supported. Ciphersuite Independence EAP methods negotiate the ciphersuite used in protection of the EAP conversation only; data protection is negotiated out-of-band. The backend authentication server is not a party to the ciphersuite negotiation nor is it an intermediary in the data flow between the EAP peer and authenticator. An EAP method may not have knowledge of the ciphersuite that has been negotiated between the peer and authenticator.

Types of EAP Keys Keys calculated locally by the EAP method but not exported by the EAP method, such as the Transient EAP Keys. Keys exported by the EAP method: MSK, EMSK, IV Keys calculated from exported quantities: AAA-Key, Application Master Session Keys (AMSKs). Keys calculated by the Secure Association Protocol: Transient Session Keys.

EAP Key Hierarchy | EAP Method | | | | | | | | | | | | | | | | | EAP Method Key | | Long-Term | | | | | Derivation | | Credential | | | | | | | | | | | | | | Local to | | | | | EAP | | | Method | | | | | | | | V | | | | | | | | | TEK | | MSK | |EMSK | |IV | | | | |Derivation | |Derivation | |Derivation | |Derivation | | | | | | | | | | | | | | | | | V | | | ^ | | | | | MSK (64B) | EMSK (64B) | IV (64B) | | | | Exported| | | | by | V V V EAP | Method| | AAA Key Derivation, | | Known | | | Naming & Binding | |(Not Secret) | | V | ---+ | Transported | | AAA-Key by AAA | | Protocol | V V | | ^ | TSK | Ciphersuite | | Derivation | Specific | | | V

Key Placement | | | | | Cipher- | | Cipher- | | Suite | | Suite | | | | | ^ ^ | | V V | |===============| |========| | | |EAP, TEK Deriv.| | | | | | | backend | | | | | | | | | Secure Assoc. | | AAA-Key| | | peer | |Authenti-|< | auth | | |===============| cator |========| server | | | Link Layer | | AAA | (EAP | | | (PPP,IEEE 802)| |Protocol| server) | |MSK,EMSK | | | | | | AAA-Key | | AAA-Key | |MSK,EMSK,| | (TSKs) | | (TSKs) | | AAA-Key | | | | | | | ^ ^ | | | MSK, EMSK | MSK, EMSK | | | | | | | EAP | | EAP | | Method | | Method | | | | | | (TEKs) | | (TEKs) | | | | |

Key Naming MSK MSK and EMSK names are only known by the EAP method, and are exported from the method. Name is the (hash of the?) concatenation of the string "MSK", EAP Method Type, EAP peer name, EAP server name, EAP peer nonce, and the EAP server nonce. EMSK (Hash of the?) concatenation of the string "EMSK", the EAP Method Type, EAP peer name, EAP server name, EAP peer nonce, and the EAP server nonce. AMSK (Hash of the?) concatenation of the string "AMSK", key label, application data (Appendix F) and EMSK Name. AAA-Key (Hash of the?) concatenation of the string "AAA-Key", the authenticator name, and the name of the key from which the AAA-Key is derived (MSK or AMSK Name). For the purpose of identifying the authenticator, the contents of the NAS- Identifier attribute is recommended. In order to ensure that all parties can agree on the authenticator name the authenticator needs to advertise its name. Note that the AAA-Key name does not include the peer or authenticator port over which the EAP conversation took place. This is because the AAA-Key is not bound to a specific peer or authenticator port.

Key Name Characteristics Key Name is not based on the key itself (unlike IEEE i) Key Name used for cache negotiation between peer and authenticator AAA server provides the Key Name (and AAA-Key) ot the authenticator Key Name sent to the authenticator by the EAP server along with the key Key Name not known by the authenticator prior to this. No reason for an authenticator to ask the AAA server for a key by name.

Key Lifetime Issues Management How are the key lifetimes managed on the peer, authenticator, and AAA server? Negotiation Out of band management Resource reclamation What happens if resources need to be reclaimed and key state is removed by one or more of the parties?

Key Lifetime Management Transient EAP Keys (TEKs) Internal to the EAP method. Valid only for the duration of the EAP conversation. MSK, EMSK, IV Existing attributes (e.g. Session-Timeout) define the lifetime of a key that is in use. In EAP, not possible to re-key the exported keys without re- authentication (but can re-key the TSKs) Exported keys may be cached prior to session start (pre- authentication), and may continue to live after the session has ended. AAA-Key may be cached on the authenticator EMSK may be cached on the AAA server Calculated keys The lifetime of keys calculated from key material exported by EAP methods can be no larger than the lifetime of the exported keying material.

Thoughts on Exported Key Lifetimes Where we are today EAP methods do not negotiate the lifetime of the exported keys. EAP, defined in [RFC3748], also does not support the negotiation of lifetimes for exported keying material such as the MSK, EMSK and IV. To date, Secure Association Protocols also do not negotiate the lifetime of exported keys. Gap may exist between EAP authentication and the Secure Association Protocol, so not clear it would help Discovery (phase 0) solutions under investigation Recommendations On the EAP server, it is RECOMMENDED that the cache lifetime of exported keys be managed as a system parameter. Where a negotiation mechanism is not provided by the lower lower, it is RECOMMENDED that the peer assume a default value of the exported key lifetime. May be desirable to manage the TSK re-key time via AAA. Not clear it is helpful that AAA management of exported key cache lifetime is helpful. AAA server is not aware of authenticator resource constraints Not clear how AAA server, authenticator and peer keep in sync Per-user cache lifetime management may complicate discovery phase solutions

Feedback?