doc.: ieee 802.11-02/104r0 submission january 2002 bernard aboba/microsoft eap keying overview...

January 2002

Bernard Aboba/Microsoft

doc.: IEEE 802.11-02/104r0

Submission

EAP Keying Overview

Bernard Aboba

Microsoft

January 2002


doc.: IEEE 802.11-02/104r0

Submission

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?

January 2002


doc.: IEEE 802.11-02/104r0

Submission

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.

January 2002


doc.: IEEE 802.11-02/104r0

Submission

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

January 2002


doc.: IEEE 802.11-02/104r0

Submission

Allocated EAP Type#’sType Description Reference Implemented? Spec Available?---- ----------- --------- ------------ ---------------1 Identity [RFC2284] Yes RFC 22842 Notification [RFC2284] Yes RFC 22843 NAK (Response only) [RFC2284] Yes RFC 22844 MD5-Challenge [RFC2284] Yes RFC 22845 One Time Password (OTP) [RFC2284] No RFC 22846 Generic Token Card [RFC2284] No RFC 22847 No No8 No No9 RSA Public Key Authentication [Whelan] No Expired10 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 271614 Defender Token (AXENT) [Roselli] Yes No15 Windows 2000 EAP [Asnes] ? No16 Arcot Systems EAP [Jerdonek] ? No17 EAP-Cisco Wireless [Norman] Yes No18 Nokia IP smart card auth [Haverinen] ? No19 SRP-SHA1 Part 1 [Carlson] Yes I-D 20 SRP-SHA1 Part 2 [Carlson] No I-D21 EAP-TTLS [Funk] Yes I-D22 Remote Access Service [Fields] ? No23 UMTS Auth and Key agreement [Haverinen] ? ?24 EAP-3Com Wireless [Young] Yes No25 PEAP [Palekar] Yes I-D26 MS-EAP-Authentication [Palekar] Yes No27 Mutual auth w/key exchange (MAKE) [Berrendonner] ? No28 CRYPTOCard [Webb] Yes No29 EAP-MSCHAP-V2 [Potter] ? I-D30 DynamID [Merlin] ? No31 Rob EAP [Ullah] ? No

January 2002


doc.: IEEE 802.11-02/104r0

Submission

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”?

January 2002


doc.: IEEE 802.11-02/104r0

Submission

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

January 2002


doc.: IEEE 802.11-02/104r0

Submission

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

January 2002


doc.: IEEE 802.11-02/104r0

Submission

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

January 2002


doc.: IEEE 802.11-02/104r0

Submission

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!

January 2002


doc.: IEEE 802.11-02/104r0

Submission

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 APIAAA attributes

EAP Method(client and AAA server)

NAS/AP and client

January 2002


doc.: IEEE 802.11-02/104r0

Submission

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

January 2002


doc.: IEEE 802.11-02/104r0

Submission

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!

January 2002


doc.: IEEE 802.11-02/104r0

Submission

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

January 2002


doc.: IEEE 802.11-02/104r0

Submission

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

January 2002


doc.: IEEE 802.11-02/104r0

Submission

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

January 2002


doc.: IEEE 802.11-02/104r0

Submission

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

January 2002


doc.: IEEE 802.11-02/104r0

Submission

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

January 2002


doc.: IEEE 802.11-02/104r0

Submission

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 APIAAA attributes

EAP Method(client and AAA server)

NAS/AP and client

January 2002


doc.: IEEE 802.11-02/104r0

Submission

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

January 2002


doc.: IEEE 802.11-02/104r0

Submission

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

January 2002


doc.: IEEE 802.11-02/104r0

Submission

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?

January 2002


doc.: IEEE 802.11-02/104r0

Submission

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 NTPKeyIV = 128-bit random numberF = Key flag (0 for broadcast, 1 for unicast)Key index = 7 bitsKey Signature = HMAC-MD5(APEncKey, Entire EAPOL Packet w/Key Signature = 0)Key = Key of length = Key Length

January 2002


doc.: IEEE 802.11-02/104r0

Submission

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

January 2002


doc.: IEEE 802.11-02/104r0

Submission

The Rest of the StoryIBSS

Pre-Shared Key used as MasterKey

Derive Master Session Keys(Does Not Include Liveness)

Derive Transient Session Keys

Master Key Derived from EAPAuthentication Method

Derive Master Session Keys(Includes Liveness)

Derive Transient Session Keys

ESS

Iteration 1 Session Send Key from Iteration0 used as Master Key


Derive Session Keys

Iteration 0

Use Truncated Session SendKey from Iteration 1 as IEEE

802.11 per-STA Unicast SessionKey (WEP)

Iteration 2 Session Send Key from Iteration1 used as Master Key


Derive Session Keys

Iteration 3

Use Truncated Session SendKey from Iteration 2 as IEEE

802.11 per-STA Unicast SessionKey (WEP)

Use TruncatedSession Send Keyfrom Iteration 1 asIEEE 802.11 per-

STA UnicastSession Key (WEP)

January 2002


doc.: IEEE 802.11-02/104r0

Submission

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?

January 2002


doc.: IEEE 802.11-02/104r0

Submission

Feedback?

doc.: ieee 802.11-02/104r0 submission january 2002 bernard aboba/microsoft eap keying overview...

Documents