1. EAP Keying Problem Draft-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- | | Suite | | | +-+-+-+-+-+ ^ ^ | | V V +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ | | EAP | | | | | | Conversation | | | | | | | AAA | | Peer | | NAS/ | | Server | | |==============>| |<=======| | | | Keys | | Keys | | | | (Optional) | | | | +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ ^ ^ | | | EAP API | EAP API | | V V +-+-+-+-+-+ | | | EAP | | 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. Example Key Hierarchy (802.11i) 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) …

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