1. EAP Keying Framework Draft-aboba-pppext-key-problem-06.txt EAP WG IETF 56 San Francisco, CA Bernard Aboba

2. Goals & Objectives To provide a framework for evaluation of EAP key derivation mechanisms and transport mechanisms –Terminology –Key hierarchy overview –Requirements for EAP methods, AAA protocols and TSK derivation protocols Key derivation algorithms or mechanisms are not specified in this document.

3. EAP Invariants Media independence –EAP methods are designed to function on any lower layer meeting criteria in RFC 2284bis, Section 3.1 Ciphersuite independence –Ciphersuite negotiation occurs out of band of EAP –EAP methods generate Master Session Keys (MSKs) that are suitable for use with any ciphersuite Method independence –Pass-through authenticators cannot be assumed to implement method-specific code

4. Master Key Types EAP Master Key (MK) –A key derived between the EAP client and server that is local to the EAP method and MUST NOT be exported. Possession of other keys (MSK, TSKs, TEKs, EMSK) MUST NOT provide information useful in recovering the MK. The MK is proof of successful authentication, and therefore may enable fast re- authentication (e.g. TLS session resume) Master Session Key (MSK) –64B of keying material that is derived between the EAP client and server and exported by the EAP method. Used in derivation of Transient Session Keys (TSKs). Where a AAA server is present, the MSK is transported between the AAA server and NAS. The MSK allows a particular client to access the network via a particular NAS.

5. Master Key Types (cont’d) Extended Master Session Key (EMSK) –64B of keying material that is derived between the EAP client and server and exported by the EAP method. Use of the EMSK is reserved, and it MUST NOT be transported by the AAA server to the NAS. The EMSK MUST be cryptographically independent from the MSK. The EMSK is the residue of successful authentication, although possession does not enable fast re- authentication. Initialization Vector (IV) –64B derived between EAP client and server, optionally exported by the EAP method, which is suitable for use in an initialization vector. Due to export requirements the IV may be a known quantity. Currently the IV is not used in either the two-way or three-way exchanges.

6. Transient Key Types Transient EAP Keys (TEKs) –Session keys used to provide protection for portions of the exchange between the EAP client and server. Not used to protect data. Transient Session Keys (TSKs) –Session keys used to protect data sent between the EAP client and NAS, derived from the MSK via the TSK derivation protocol.

7. EAP Key Hierarchy

8. EAP Exchanges Two-way exchange –EAP client and NAS, no AAA server. –Popular in small networks (e.g. home AP) –Usable in larger networks Certificate-based roaming IAPP-based fast handoff between APs to reduce load Three-way exchange –EAP client, NAS and AAA server. –Not usable in small networks. –Most frequently deployed model for large networks.

9. Two-Way Exchange

10. Three-Way Exchange

11. The (Bermuda?) EAP Triangle

12. Security Requirements Mutual authentication at each leg of the triangle. –Mutually authenticating EAP method –TSK derivation protocol supporting mutual auth, secure ciphersuite and capabilities negotiation –Mutual authentication between NAS and AAA server Fresh session keys at each leg of the triangle –EAP method provides fresh MSK, EMSK, IV –No AAA static keys as in [RFC2865] RADIUS over IPsec Diameter over TLS/IPsec –TSK derivation protocol guarantees freshness Keys protected from compromise –Appropriate key strength (see [KeyLen]) –MK not derivable from other master or transient key types –MSK transported securely from AAA server to NAS Established key wrap algorithms (not RFC 2548) Protection from compromise by AAA intermediaries Binding to correct session, NAS, client

13. Security Requirements (cont’d) Protection against man-in-the-middle attacks Per-packet authentication, integrity and replay protection at each leg of the triangle –EAP method Uses TEKs to provide security services Typically doesn’t cover EAP header or Identity, Notification, Success/Failure packets –AAA protocol Transmission layer security (IPsec, TLS) RFC 2869bis now has IPsec as a SHOULD –TSK derivation protocol Example: IEEE 802.11i

14. Open Issues Issue 15: missing security reqts. –Additional discussion of key naming, sychronization and binding required Issue 47: key requirements unspecified –Size of MSK and EMSK? Each is 64B at the moment –Minimum key strength in some/all scenarios? –Nonce exchange required in EAP methods? Issue 99: Double expansion –Expansion typically occurs from MK to MSK and MSK to TSK –What is the effect of this?