1 / 17

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

EAP Keying Problem Draft-aboba-pppext-key-problem-03.txt. Bernard Aboba bernarda@microsoft.com. Observations. Some EAP methods derive keys, some don’t Where keys are derived, strength varies widely The type of keys derived varies as well

zelia
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related