EAP Keying Problem Draft-aboba-pppext-key-problem-03.txt

1. EAP Keying ProblemDraft-aboba-pppext-key-problem-03.txt Bernard Aboba bernarda@microsoft.com

2. Observations • Some EAP methods derive keys, some don’t • Where keys are derived, strength varies widely • The type of keys derived varies as well • Some methods derive ciphersuite-specific “session keys” • Some methods derive ciphersuite-independent “master keys” • Some methods describe key hierarchy, some don’t

3. Goals and Objectives • To describe basic concepts of EAP • To describe the EAP keying architecture • To point out pitfalls in design of EAP methods that derive keys • To identify problems that require solution

4. Why Derive Keys? • Key derivation not required in all uses • EAP can be used for authentication only • Where EAP methods derive keys, it is possible to “bind” the authentication to: • Subsequent data packets encrypted/integrity protected with those keys • Subsequent EAP methods running within a sequence • The tunnel within which EAP runs • To accomplish these things, it is necessary to define a “key hierarchy”

5. EAP Terms • Peer – desires network access • NAS – provides network access • AAA server (optional) provides centralized authentication, authorization and accounting for NASes

6. EAP Overview +-+-+-+-+-+ +-+-+-+-+-+ | | | | | | | | | Cipher- | | Cipher- | | Suite | | Suite | | | | | +-+-+-+-+-+ +-+-+-+-+-+ ^ ^ | | | | | | V V +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ | | EAP | | | | | | Conversation | | | | | |<================================>| AAA | | Peer | | NAS/ | | Server | | |==============>| |<=======| | | | Keys | | Keys | | | | (Optional) | | | | +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ ^ ^ | | | EAP API | EAP API | | V V +-+-+-+-+-+ +-+-+-+-+-+ | | | | | | | | | EAP | | EAP | | Method | | Method | | | | | +-+-+-+-+-+ +-+-+-+-+-+

7. Assumptions of the Architecture • EAP methods • EAP methods are implemented on the peer and AAA server • NAS does not implement EAP methods except perhaps the mandatory method • NAS typically “passes through” the authentication • NAS may not have knowledge of the EAP method selected by the peer and AAA server • Peer and AAA server typically negotiate the EAP method • Ciphersuites • NAS & Peer negotiate and implement ciphersuites • Ciphersuites may be negotiated before or after EAP authentication, depending on the media • PPP, 802.11i pre-auth: ciphersuite negotiated after authentication • 802.1X: ciphersuite negotiated before authentication • AAA server may not have knowledge of the selected ciphersuite • EAP method residing on the peer or AAA server may not have knowledge of the selected ciphersuite

8. Corollaries • EAP key derivation should be ciphersuite independent • Key derivation separated into two phases: • Master session key derivation (occurs on AAA server, peer) • MSK derivation is EAP method-specific • MSKes sent from AAA server to NAS via AAA protocol • Session key derivation from MSKes (occurs on NAS, peer) • Session key hierarchy is ciphersuite specific • Reasons • Method may not know what the selected ciphersuite is at the time of key derivation • If key derivation is ciphersuite dependent, then EAP method will need to be revised each time a new ciphersuite comes out • New EAP methods coming along all the time (36 so far, and counting) • New media adopting EAP • New ciphersuites being defined • Matrix of ciphersuites times methods is big!

9. What is a Key Hierarchy? • A description of how the session keys required by a particular cipher are derived from the keying material provided by the EAP methods • Implies that you need a hierarchy per ciphersuite/media • Desirable characteristics • Key strength (64 bits typically not enough) • “Cryptographic separation” between keys used for different purposes (encryption, authentication/integrity, unicast/multicast, etc.)

10. Hierarchy Overview +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+--- | | | | ^ | Is a raw master key | | Can a pseudo-master key | | | available or can | | be derived from | | | the PRF operate on it? | | the master key? | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | K | K' | | | | V V | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | EAP | | Master Session Key | Method | | Derivation | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | Master Session Key Outputs | | | | | V V | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | Key and IV Derivation | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | P->A | A->P | P->A | A->P | P->A | A->P EAP V | Enc. | Enc. | Auth. | Auth. | IV | IV API ---+--- | Key | Key | Key | Key | | ^ | (PMK) | | | | | AAA | | | | | | | Keys V V V V V V V ---+--- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^ | | | | Ciphersuite-Specific Key Hierarchy | NAS | | | | | | V +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+---

11. Pairwise Master Key (PMK) • PRF-X(PMK, “Pairwise key expansion”, Min(AA,SA) || Max(AA,SA) || Min(ANonce,SNonce) || Max(ANonce,SNonce)) Pairwise Transient Key (PTK) (X bits) EAPOL-Key MIC Key L(PTK,0,128) (MK) EAPOL-Key Encrption Key L(PTK,128,128) (EK) Temporal Key 1 L(PTK,256,128) (TK 1) … Example Key Hierarchy (802.11i)

12. Pitfalls for the Unwary • Arbitrary AAA EAP key attributes • Transport keys derived by EAP methods • Critical to EAP interoperability: NAS expects MSK, not session key • Can encourage bad practices: ciphersuite-specific EAP methods • Improper key hierarchies • Loops can dilute key strength • Early 802.11i proposals had this problem • EAP methods generating keys without sufficient entropy • 802.11i assumes a 256-bit PMK! • Issue for EAP SIM and EAP GSS • EAP methods without nonce exchanges • May not be able to generate required crytographic separation without a subsequent nonce exchange • Could cause method to work only on some media (e.g. 802.11 vs. PPP) • Issue for EAP SRP

13. Summary • Secure key derivation is important to a number of uses of EAP • Secure ciphers lose their security when combined with insecure key derivation • EAP key derivation architecture currently not well understood • Current EAP methods exhibit a number of problems relating to key derivation • Secure key hierarchy derivation is a complex subject, best left to experts • Need to consider hierarchy when designing EAP method

14. EAP GSSDraft-aboba-pppext-eapgss-12.txt Bernard Aboba bernarda@microsoft.com

15. Intended Purpose • Integrated network/Kerberos login • Depends on IAKERB GSS-API method • Media: PPP, IEEE 802 • Kerberos vulnerable to dictionary attack on IEEE 802.11 • Key derivation may not meet 802.11i criteria • Requested Track: Experimental

16. Security Claims Mechanism: Depends on GSS-API mechanism (Kerberos: Passwords, Certs, Token cards) Mutual/one-way auth: typically mutual (Kerberos: Mutual) Key derivation 1. Supported: yes 2. Key size: depends on GSS-API method negotiated 3. Key hierarchy description: no Dictionary attack resistance: depends on method (Kerberos: no) Identity hiding: Depends on method (Kerberos: no) Protection 1. Method negotiation: Yes (SPNEGO) 2. Ciphersuite negotiation: No 3. Success/failure indication: No 4. Method packets: Yes Fast reconnect: depends on method (Kerberos: no)

17. Issues • Scope • Does exchange end with AS_REP? TGT_REP? AP_REP? • Security • Dictionary attack on AS_REQ/AS_REP • Keying • How are tickets transmitted from peer to NAS? • Key derivation: initial draft did not include a nonce exchange, -12 does • Key derivation: Master key cannot be retrieved via GSS-API; need to derive “pseudo master key” via GSS_WRAP() calls • Key strength: depends on negotiated GSS-API method