1 / 27

EAP Keying Overview

EAP Keying Overview. Bernard Aboba Microsoft. Outline. Terminology Status of EAP The EAP architecture EAP keying Details Derivation of master session keys from master key Format for RADIUS keying attributes What happens next?. Terminology. Master key

makya
Download Presentation

EAP Keying Overview

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 Overview Bernard Aboba Microsoft Bernard Aboba/Microsoft

  2. Outline • Terminology • Status of EAP • The EAP architecture • EAP keying • Details • Derivation of master session keys from master key • Format for RADIUS keying attributes • What happens next? Bernard Aboba/Microsoft

  3. Terminology • Master key • The key derived between the EAP client and EAP server during the EAP authentication process. • Master session key • The keys derived from the master key that are subsequently used in generation of the transient session keys for authentication, encryption, and IV-generation. So that the master session keys are to be usable with any ciphersuite, they are longer than is necessary, and are truncated to fit. • Transient session keys • The chosen ciphersuite uses transient session keys for authentication and encryption as well as IVs (if required). The transient session keys are derived from the master session keys, and are of the appropriate size for use with the chosen ciphersuite. Bernard Aboba/Microsoft

  4. Status of EAP • IETF Proposed Standard (RFC 2284) • RFC 2284bis effort underway to promote to Draft Standard • EAP increasingly adopted for network access authentication • Now: PPP, IEEE 802.1X, PIC (EAP over IP) • Future: PANA, Hiperlan? Bluetooth? • Vendor interest in EAP increasing • 31 EAP type codes allocated by IANA • Potential interoperability problems • RFC 2284 unclear in a number of places • EAP increasingly used for keying: but no architectural description of how this works • Confusion about key interfaces can result in interoperability problems • Example: If EAP method doesn’t generate a master session key and AAA server assumes master session keys, NAS and client will end up with incompatible keys Bernard Aboba/Microsoft

  5. Allocated EAP Type#’s Type Description Reference Implemented? Spec Available? ---- ----------- --------- ------------ --------------- 1 Identity [RFC2284] Yes RFC 2284 2 Notification [RFC2284] Yes RFC 2284 3 NAK (Response only) [RFC2284] Yes RFC 2284 4 MD5-Challenge [RFC2284] Yes RFC 2284 5 One Time Password (OTP) [RFC2284] No RFC 2284 6 Generic Token Card [RFC2284] No RFC 2284 7 No No 8 No No 9 RSA Public Key Authentication [Whelan] No Expired 10 DSS Unilateral [Nace] Yes I-D? 11 KEA [Nace] Yes I-D? 12 KEA-Validate [Nace] Yes I-D? 13 EAP-TLS [Aboba] Yes RFC 2716 14 Defender Token (AXENT) [Roselli] Yes No 15 Windows 2000 EAP [Asnes] ? No 16 Arcot Systems EAP [Jerdonek] ? No 17 EAP-Cisco Wireless [Norman] Yes No 18 Nokia IP smart card auth [Haverinen] ? No 19 SRP-SHA1 Part 1 [Carlson] Yes I-D 20 SRP-SHA1 Part 2 [Carlson] No I-D 21 EAP-TTLS [Funk] Yes I-D 22 Remote Access Service [Fields] ? No 23 UMTS Auth and Key agreement [Haverinen] ? ? 24 EAP-3Com Wireless [Young] Yes No 25 PEAP [Palekar] Yes I-D 26 MS-EAP-Authentication [Palekar] Yes No 27 Mutual auth w/key exchange (MAKE) [Berrendonner] ? No 28 CRYPTOCard [Webb] Yes No 29 EAP-MSCHAP-V2 [Potter] ? I-D 30 DynamID [Merlin] ? No 31 Rob EAP [Ullah] ? No Bernard Aboba/Microsoft

  6. Some Observations • Rate of Type allocation is increasing • 31 Type values allocated since March 1998 • 4 Type values allocated in the last month • Two Type values allocated to the same Method • EAP SRP-SHA1 Parts 1 and 2 • EAP-MSCHAP-v2 and MS-EAP-Authentication • Most allocations done without a specification for vendor-specific use • Not all allocated Types are used • At least 5 of the allocated types have not been implemented (~15 percent!) • Conclusion • EAP Type space is a finite resource (255) - could probably be managed more effectively • IANA considerations needed! • Should allocation of EAP type codes require “expert review”? Bernard Aboba/Microsoft

  7. The EAP Architecture • NASen/APs • Don’t have to understand EAP methods, act as a “passthrough” • NAS code does not need to be updated to support a new EAP method • NASen can work with any EAP method • Negotiates ciphersuite with client • Can be expected to have ciphersuite-specific knowledge, since they implement the ciphersuites • NAS can know what key lengths/types are required for each ciphersuite • AAA servers • Act as a “passthrough” to EAP methods hosted via EAP API • AAA server core code should not need to be updated to support a new EAP method • AAA server can host any EAP method • May not know ciphersuite negotiated between NAS and client • PPP ECP occurs *after* authentication • 802.11 ciphersuite negotiation occurs *before* authentication • AAA server cannot be assumed to have the information to pass back ciphersuite-specific keys • AAA server code should not need to be updated to support a new ciphersuite Bernard Aboba/Microsoft

  8. The EAP Architecture (cont’d) • EAP methods • May not know the negotiated ciphersuite • Ciphersuite may not be known at the time the method is invoked • EAP API may not support passing this down from AAA server • Should not need to be updated to support a new ciphersuite • Differ in their access to the master key • Some methods have direct access to the master key (SRP) • Some methods cannot access the master key directly (TLS, GSS-API) • Implication: EAP methods are generally incapable of supporting ciphersuite-specific keys • RFC 2716 derives “master session keys” – passed by AAA server to the NAS • Ciphersuite-specific keys can be derived by the NAS Bernard Aboba/Microsoft

  9. Some Basic Groundrules • EAP methods should be engineered to work in any application • Example: EAP methods that work only with 802.11 • EAP methods should be engineered to key any ciphersuite • Example: EAP methods that include their own methods for key truncation • EAP methods should be engineered to work with any AAA protocol • Example: EAP methods that require RADIUS (or Diameter) • EAP methods should be engineered to work with any AAA server • Example: EAP methods incompatible with keying attributes supported by a particular AAA server • EAP methods should not rely on features unsupported by RFC 2284bis • Examples: • Use of Notification for nonce passing • Use of NAK for version negotiation within an EAP method • Passing additional data within EAP Success or Failure Bernard Aboba/Microsoft

  10. The EAP Keying Problem • The problem: How can EAP methods be used to derive ciphersuite-specific keys for any ciphersuite? • EAP methods are generally incapable of supporting ciphersuite-specific keys • EAP methods may not have direct access to the master key • EAP methods need to be independent of media (PPP, 802.1X) • NASen are generally incapable of hosting EAP-method specific code • NASen can host ciphersuite-specific code • The solution: • EAP methods derive generic “master session keys” from the master key • Enables EAP methods to provide the NAS with “generic keying material” which requires no EAP-method specific processing • Master session keys are passed by the AAA server to the NAS • Ciphersuite-specific transient session keys are derived by the NAS from the “master session keys” • Implications: • Context transfers move the AAA context from the old AP to the new AP; new APs process the context as though it came from the AAA server • This means that “master session keys” are transferred from the old AP to the new AP, not transient session keys! Bernard Aboba/Microsoft

  11. The EAP Keying Architecture +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | Is 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Master Session Key | | Derivation | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Master Session Key Outputs | V V +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Key and IV Derivation | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | P->A | A->P | P->A | A->P | P->A | A->P | Enc. | Enc. | Auth. | Auth. | IV | IV | Key | Key | Key | Key | | | | | | | | | | | | | | | | | | | | V V V V V V +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Ciphersuite-Specific Truncation & | | Key utilization | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ EAP Method (client and AAA server) EAP API AAA attributes NAS/AP and client Bernard Aboba/Microsoft

  12. Roles of Client, NAS/AP and AAA Server • EAP client and EAP server (AAA) • EAP methods derive master keys • EAP method derives master session keys from the master key • EAP method passes master session keys to AAA server via EAP API • AAA server and NAS • AAA server transmits master session key to the NAS/AP via attributes • Client and NAS • Select a ciphersuite • Derive ciphersuite-specific keys from the master session keys • Use the ciphersuite-specific keys with the selected ciphersuite Bernard Aboba/Microsoft

  13. What is Needed to Fully Specify the Keying Architecture? • Algorithms for the derivation of the master session key from the master key for each EAP method • Example: RFC 2716, section 3.5 includes algorithms for “master session key” derivation • Some proposed EAP methods do not describe how to generate master session keys! • Format for the AAA attributes used to transmit the master session keys from the AAA server to the NAS/AP • Example: RFC 2548 defines vendor-specific AVPs for transmission of encryption master session keys: MS-MPPE-Send-Key (16), MS-MPPE-Recv-Key (17) • Algorithms for the derivation of ciphersuite-specific keys from the master session keys for each ciphersuite • Example: RFC 3079 section 4 defines algorithms for deriving MPPE transient session keys from RFC 2716 master session keys • These techniques are not generally applicable to other ciphersuites! Bernard Aboba/Microsoft

  14. What is Required of EAP Methods Generating Keys? • EAP methods generating keys must also describe the key hierarchy • How are encryption, authentication and IV master session keys derived from the master key? • Examples: • RFC 2716 describes how master session keys are derived from TLS master key • EAP SRP and EAP GSS drafts didn’t describe how master session keys are generated • Result: Methods won’t work on all AAA servers, NASen, clients • Key hierarchy derivation is method-specific • No general solution that works for any EAP method • SRP: may be able to leverage IKE or TLS key hierarchy • GSS: needs to describe key hierarchy valid for use with any GSS-API method • This may be difficult if GSS_GetMIC() doesn’t supply sufficient randomness • Generating master session keys in a secure way is hard • IKE and TLS are the best examples • Need cryptographic separation between authentication, encryption and IV master session keys • Need to ensure “liveness” in master session keys • EAP methods can get this (and more) for free via TLS/IKE protection • TLS: PEAP, EAP TTLS • IKE: PIC Bernard Aboba/Microsoft

  15. Alternatives • Attempt to validate many EAP methods providing keying material • Will require creation of a key hierarchy for each protocol • Could stretch the resources available for security review • Limit the number of EAP methods generating keys • Focus on methods that can leverage existing, well analyzed key derivation techniques • Adopt key hierarchies adopted in existing standards or analyzed by NIST • If method doesn’t fit into the above two categories – punt! • Focus on protecting EAP with well-analyzed key derivation technology • Would protect EAP exchange using protocols such as IKE (PIC) or TLS (TTLS, PEAP) • Would enable EAP methods to focus on authentication and leverage protection mechanism to handle keying • Key derivation, hierarchies for IKE, TLS are well documented and analyzed • Much better chance of getting a method running under “protection umbrella” to work correctly • Other benefits likely • TTLS/PEAP provides segmentation/reassembly, fast reconnect without requiring any work on the part of the EAP method developer Bernard Aboba/Microsoft

  16. What Additional Pieces Does 802.11 Need To Support Rekeying? • Algorithm for encryption, authentication, integrity and replay protection of EAPOL key descriptors • Rekeying algorithm • Algorithm for authentication of management frames • Reassociation Request/Response • Disassociation • Deauthentication • Cryptographic separation needed between: • Transient session keys • Keys used to encrypt/authenticate EAPOL key descriptors • Keys used to authenticate management frames Bernard Aboba/Microsoft

  17. Details • 802.11 ciphersuite keying requirements • AES-CTR + CBC-MAC w/XCBC extensions: a single 128-bit encryption key in each direction: APEncKey (MS-MPPE-Send-Key) , PAEncKey (MS-MPPE-Recv-Key) • AES-OCB: a single 128-bit encryption key: APEncKey (MS-MPPE-Send-Key) • Derivation of master session keys from master key • RFC 2716 • Format of RADIUS Keying AVPs • RFC 2548 • draft-simon-radius-keys-00.txt • Format of EAPOL key descriptors • Questions to ask Bernard Aboba/Microsoft

  18. RFC 2716 Derivation of Master Session Keys • K = TLS master key (generally not exportable) • Random = client_hello.random | server_hello.random • PRF1=PRF(K, “client EAP encryption”, random) [128B] • Peer to authenticator encryption key: first 32B • Authenticator to Peer encryption key: second 32B • Peer to authenticator authentication key: third 32B • Authenticator to peer authentication key: fourth 32B • PRF2=PRF(“”,”client EAP encryption”, random) [64B] • Peer to authenticator IV: first 32B • Authenticator to peer IV: second 32B • Note: • For NAS and AAA server to derive the same master session keys, the nonces need to be exchanged as part of the EAP method • Client_hello.random and server_hello.random are specific to TLS Bernard Aboba/Microsoft

  19. RFC 2716 Master Session Key Derivation +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | Is 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Master Session Key | | Derivation | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PRF1 (128B) | PRF2 (64B) | | V V +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | Key | | IV | | Derivation | | Derivation | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | P->A | A->P | P->A | A->P | P->A | A->P | Enc. | Enc. | Auth. | Auth. | IV | IV | Key | Key | Key | Key | 32B | 32B | 32B | 32B | 32B | 32B | | | | | | | | | | | | | | V V V V V V +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Ciphersuite-Specific Truncation & | | Key utilization | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ EAP Method (client and AAA server) EAP API AAA attributes NAS/AP and client Bernard Aboba/Microsoft

  20. RADIUS Vendor-Specific Key Attribute(RFC 2548) MS-MPPE-Send-Key (Vendor-Type = 16) (Encrypts packets from Auth to Peer) MS-MPPE-Recv-Key (Vendor-Type = 17) (Encrypts packets from Peer to Auth) 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor-Type | Vendor-Length | Salt | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | String... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Vendor-Length > 4 • Overview: • Provides 2 x 32B of keying material (although keys can be up to 251B) • Only supports sending encryption master session keys in each direction • Sufficient for WEP, proposed AES ciphersuites • No support for auth or IV master session keys • Can make cryptographic separation more difficult Bernard Aboba/Microsoft

  21. Proposed RADIUS Key Attribute(draft-simon-radius-key-attr-00.txt) 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Salt | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PAEncKey... (32B) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | APEncKey... (32B) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PAAuthKey... (32B) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | APAuthKey... (32B) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PAIV... (32B) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | APIV... (32B) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ • Overview: • Provides 6 x 32B of keying material (192B total) • Master Session keys each 32B (256 bits) in length • Supports sending encryption, auth, IV master keys in each direction Bernard Aboba/Microsoft

  22. What Happens Next? • At this point, client, NAS/AP, and AAA server all have the same master session keys • Could occur via a AAA conversation • Could occur via a context transfer • Next steps • NAS and client discard keys not required for the negotiated ciphersuite or key transmission • Broadcast key transmitted from AP to STA • NAS and client truncate keys to the appropriate length for the negotiated ciphersuite • Liveness added? Bernard Aboba/Microsoft

  23. RC4 Key Descriptor Format(IEEE 802.1X) 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Key Length |Replay Counter... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Replay Counter... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Replay Counter | Key IV... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key IV... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key IV... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key IV... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key IV... |F| Key Index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key Signature... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key Signature... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key Signature... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key Signature... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type (1 = RC4) Replay Counter = 64-bit NTP KeyIV = 128-bit random number F = Key flag (0 for broadcast, 1 for unicast) Key index = 7 bits Key Signature = HMAC-MD5(APEncKey, Entire EAPOL Packet w/Key Signature = 0) Key = Key of length = Key Length Bernard Aboba/Microsoft

  24. RC4 Key Descriptor Issues • Alignment • Replay counter, Key IV fields not aligned • Replay counter • NTP used; replay window not specified • Key Signature • Calculation not specified in IEEE 802.1X 7.6.8 • The Key Signature is a MIC calculated over all fields of the EAPOL packet, from and including the EAPOL protocol version field, to and including the Encrypted Key field, with the signature set to 0. • MIC Key = Authenticator MS-MPPE-Send-Key (APEncKey) • MIC length varies by algorithm; MIC algorithm implicit in the Type field • HMAC-SHA1 is 160 bits, not 128 • RC4 cipher used to encrypt key • Key stream derivation not specified in IEEE 802.1X 7.6.8 • Recommendation • Define new key descriptor format for new types • Not required to reuse generic format for new types • Write specifications so that developers can interoperate based on the specification Bernard Aboba/Microsoft

  25. The Rest of the Story Bernard Aboba/Microsoft

  26. Some Questions to Ask • Describe the key hierarchy • How are ciphersuite-specific keys derived from the master session keys? • Are these mechanisms appropriate to the ciphersuites under consideration? (WEP, AES modes) • How are the master session keys used to encrypt and authenticate the multicast key within the multicast key descriptor? • Which of the master session keys are used? For what operations? • How are the master session keys used to encrypt and authenticate the nonce/unicast session key descriptors? • How are the master session keys used to derive the keys used to authenticate management frames? • Which management frames are authenticated? • Describe how vulnerabilities are addressed • How is cryptographic separation provided between the above keys? • How is replay prevention/liveness supported? • Describe rekey scenarios • If there are multiple key frames and some are not mandatory to implement, what happens if a STA does not support the key descriptor type sent by the AP? • What if the STA wants to rekey? Bernard Aboba/Microsoft

  27. Feedback? Bernard Aboba/Microsoft

More Related