1. doc.: IEEE 802.11-02/104r0 Submission January 2002 Bernard Aboba/Microsoft EAP Keying Overview Bernard Aboba Microsoft

2. doc.: IEEE 802.11-02/104r0 Submission January 2002 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?

3. doc.: IEEE 802.11-02/104r0 Submission January 2002 Bernard Aboba/Microsoft 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.

4. doc.: IEEE 802.11-02/104r0 Submission January 2002 Bernard Aboba/Microsoft 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

5. doc.: IEEE 802.11-02/104r0 Submission January 2002 Bernard Aboba/Microsoft 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

6. doc.: IEEE 802.11-02/104r0 Submission January 2002 Bernard Aboba/Microsoft 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”?

7. doc.: IEEE 802.11-02/104r0 Submission January 2002 Bernard Aboba/Microsoft 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

8. doc.: IEEE 802.11-02/104r0 Submission January 2002 Bernard Aboba/Microsoft 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

9. doc.: IEEE 802.11-02/104r0 Submission January 2002 Bernard Aboba/Microsoft 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

10. doc.: IEEE 802.11-02/104r0 Submission January 2002 Bernard Aboba/Microsoft 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!

11. doc.: IEEE 802.11-02/104r0 Submission January 2002 Bernard Aboba/Microsoft 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 API AAA attributes EAP Method (client and AAA server) NAS/AP and client

12. doc.: IEEE 802.11-02/104r0 Submission January 2002 Bernard Aboba/Microsoft 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

13. doc.: IEEE 802.11-02/104r0 Submission January 2002 Bernard Aboba/Microsoft 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!

14. doc.: IEEE 802.11-02/104r0 Submission January 2002 Bernard Aboba/Microsoft 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

15. doc.: IEEE 802.11-02/104r0 Submission January 2002 Bernard Aboba/Microsoft 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

16. doc.: IEEE 802.11-02/104r0 Submission January 2002 Bernard Aboba/Microsoft 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

17. doc.: IEEE 802.11-02/104r0 Submission January 2002 Bernard Aboba/Microsoft 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

18. doc.: IEEE 802.11-02/104r0 Submission January 2002 Bernard Aboba/Microsoft 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

19. doc.: IEEE 802.11-02/104r0 Submission January 2002 Bernard Aboba/Microsoft 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 | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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 API AAA attributes EAP Method (client and AAA server) NAS/AP and client

20. doc.: IEEE 802.11-02/104r0 Submission January 2002 Bernard Aboba/Microsoft 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

21. doc.: IEEE 802.11-02/104r0 Submission January 2002 Bernard Aboba/Microsoft 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

22. doc.: IEEE 802.11-02/104r0 Submission January 2002 Bernard Aboba/Microsoft 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?

23. doc.: IEEE 802.11-02/104r0 Submission January 2002 Bernard Aboba/Microsoft 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

24. doc.: IEEE 802.11-02/104r0 Submission January 2002 Bernard Aboba/Microsoft 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

25. doc.: IEEE 802.11-02/104r0 Submission January 2002 Bernard Aboba/Microsoft The Rest of the Story

26. doc.: IEEE 802.11-02/104r0 Submission January 2002 Bernard Aboba/Microsoft 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?

27. doc.: IEEE 802.11-02/104r0 Submission January 2002 Bernard Aboba/Microsoft Feedback?