IEEE 802.11 Networks and Windows XP

Updated: December 4, 2001

On This Page

 Introduction
 Deployment Issues with IEEE 802.11
 Using IEEE 802.1X for Wireless Authentication
 Network Adapter Card Requirements
 Access Point Requirements

Introduction

Support for IEEE 802.11 has been added to Microsoft Windows XP as a solution for the security, configuration, and management issues that arise when an enterprise considers deploying a wireless network.

This article provides information for engineers and driver developers about the changes that need to be made to IEEE 802.11 Access Points (APs) and NDIS drivers for IEEE 802.11 network adapters to support the additions to Windows XP.

Note: To support security improvements discussed here, changes also need to be made to Remote Authentication Dial In User Service (RADIUS) servers.

 Top of page

Deployment Issues with IEEE 802.11

The issues that can arise when deploying an IEEE 802.11 wireless network can be broadly classified into three categories: user administration, key management, and security.

User administration issues Integration with existing user administration tools (such as those for RADIUS and LDAP based directories) is required for ease of administration during wireless network deployment. One example of this integration would be the ability to create a user group enabled for wireless access. Once this is done, any user who is a member of the group is granted wireless access.

Identification via user name is easier to administer in large network environments than the currently used MAC address identification mechanism. Identification by user name also provides a way to track data such as amount of use, accounting, and auditing through RADIUS.

Key management issues Static keys are difficult to manage on stations (STAs) and APs. Also, proprietary key management solutions require separate user databases.

Security issues with IEEE 802.11
The following security issues exist with IEEE 802.11:

• No per-packet authentication

• Vulnerability to disassociation attacks

• No user identification and authentication

• No central authentication, authorization, or accounting support

• RC4 stream cipher is vulnerable to known plain-text attack

• Some implementations derive Wired Equivalent Privacy (WEP) keys from passwords

• No support for extended authentication such as token cards, certificates/smart cards, one-time passwords, biometrics, etc.

• Key management issues such as re-key of global keys and no management of dynamic per-STA unicast session keys

Current IEEE 802.11 Security Options. Security options for IEEE 802.11 include authentication services and encryption services that are based on the WEP algorithm.

• Authentication. IEEE 802.11 supports two subtypes of authentication services: Open System and Shared Key. The type of authentication invoked is controlled by the AuthenticationType parameter while the type of authentication that may be accepted by a STA is controlled by the security-related Management Information Base (MIB) attribute dot11AuthenticationType. Open System is a default null authentication algorithm that involves a two-step process consisting of an identity assertion and request for authentication followed by authentication result. Shared Key authentication supports authentication of STAs as either a member of those who know a shared secret key or a member of those who do not. The standard currently presumes that the shared key is delivered to the participating STAs over a secure channel that is independent of the IEEE 802.11 wireless communications channel.

• Encryption. The WEP algorithm defines the use of 40-bit secret keys for authentication and encryption; many IEEE 802.11 implementations also allow 104-bit secret keys. IEEE 802.11 does not require that the same WEP keys be used by all STAs. It also allows a STA to maintain two sets of shared keys: a per-STA unicast session key and a multicast/global key. Current IEEE 802.11 implementations primarily support shared multicast/global keys but are expected to support per-STA unicast session keys in the near future.
  
  WEP provides encryption services to protect authorized users of a wireless LAN (WLAN) from eavesdropping and provides physical security attributes comparable to a wired medium. WEP is a symmetric algorithm in which the same key is used for cipher and decipher. The secret key is concatenated with an initialization vector (IV) resulting in a seed that is used as an input to a pseudorandom number generator (PRGN). PRNG is used to generate the key sequence that is mathematically combined with the message text concatenated with integrity check value (ICV). The {IV, message text, ICV} triplet forms the actual data sent in an IEEE 802.11 data frame.
  
  While the secret key remains constant over long duration, the IV is changed periodically and as frequently as every MAC protocol data unit (MPDU). The periodicity at which IV values are changed depends on the degree of privacy required of the WEP algorithm; changing IV after each MPDU is the ideal method of maintaining the effectiveness of WEP.

The lack of a WEP key-management protocol is a limitation to providing IEEE 802.11 security services, especially in a wireless infrastructure network mode with a large number of STAs. Lack of authentication and encryption services also impacts operation in a wireless ad hoc network mode. The current IEEE 802.11 security option for access control does not scale appropriately in large infrastructure network mode (corporate campuses and public places) and ad hoc network mode. In addition, lack of Inter Access Point Protocol (IAPP) further accentuates the key management issues when STAs roam from one to AP to another.

 Top of page

Using IEEE 802.1X for Wireless Authentication

This section provides background information about how IEEE 802.1X can be used for wireless authentication using a RADIUS server for authenticating client credentials.

IEEE 802.1X is a draft standard for port-based network access control, to provide authenticated network access for Ethernet networks. Port-based network access control utilizes the physical characteristics of the switched LAN infrastructure in order to provide a means of authenticating devices attached to a LAN port, and for preventing access to that port in cases where the authentication process fails.

A LAN port, also denoted as a Port Access Entity, can adopt one of two roles in an access control interaction: supplicant or authenticator:

• The supplicant is a port that requests access to services accessible via the authenticators port.

• An authenticator is a port that enforces authentication before allowing access to services accessible via that port.

In addition, the authentication server performs the authentication function to check the supplicant's credentials on behalf of the authenticator. It then responds to the authenticator, indicating whether the supplicant is authorized to access the authenticators services. The authentication server may be separate entity or its functions may be co-located with the authenticator.

The authenticators port-based access control defines two logical access points to the LAN via a single physical LAN port. The first logical access point, denoted as the uncontrolled port, allows uncontrolled exchange between the authenticator and other systems on the LAN regardless of the systems authorization state. The second logical access point, denoted as the controlled port, allows exchange between a system on the LAN and the authenticator services only if the system is authorized.

An extension to the basic IEEE 802.1X protocol is required to allow a wireless access point to securely identify traffic of particular clients. This is done by passing an authentication key to the client and to the wireless access point as part of the authentication procedure. Only authenticated clients know the authentication key and the authentication key encrypts all packets sent by a client.

Without a valid authentication key, an AP (authenticator) inhibits all traffic flow through it. When a wireless STA (supplicant) comes in range of a wireless AP, the following occurs:

1. The wireless AP issues a challenge to the wireless STA.

2. Upon receiving the challenge from AP, the STA sends its identity to the AP.

3. The AP forwards the STA's identity to the RADIUS server (authentication server) to initiate authentication services.

4. The RADIUS server then requests the credentials for the STA, specifying the type of credentials required, to confirm identity.
   
   Requests passing between the STA and the RADIUS server pass through the uncontrolled port on the AP; the STA cannot directly reach the RADIUS server. The AP does not allow communication via the controlled port because the STA does not possess an authentication key.

5. The STA sends the credentials to the RADIUS server.

6. Upon validating the credentials, the RADIUS server transmits an authentication key to the AP. The authentication key is encrypted so that only the AP can access it.

7. The AP uses the authentication key received from the RADIUS server to securely transmit a per-STA unicast session key and a multicast/global authentication key to the STA.
   
   The requirement to encrypt the global authentication key requires that the Extensible Authentication Protocol (EAP) authentication method used for wireless must be capable of generating an encryption key as part of the authentication process.
   
   Transport Level Security (TLS) provides for mutual authentication, integrity-protected cipher suite negotiation, and key exchange between the two endpoints. Therefore, EAP-TLS will be used to provide for the TLS mechanisms within EAP.

Following authentication, the IEEE 802.1X protocol should be configured to request the STA to re-authenticate periodically, at a configurable time interval. A detailed procedure for the authentication process is given below:

1. The wireless AP is configured to inhibit data traffic from being forwarded either to a wired network such as Ethernet or to another wireless STA without valid authentication keys. The wireless AP and wireless STA must support a multicast/global authentication key; it is also acceptable for them to support a per-STA unicast session key. The wireless AP has a process that listens for IEEE 802.1X traffic both with and without authentication keys.

2. If the AP observes a new STA associating with it, the IEEE 802.1X process in the AP transmits an EAP-Request (Identity) to the new STA. If the AP IEEE 802.1X process receives an EAP-Start message from a STA, the IEEE 802.1X process transmits an EAP-Request (Identity) to the particular STA. A STA transmits an EAP-Start on associating with a new AP.

3. A STA transmits an EAP-Response (Identity) containing the machine name in response to an EAP-Request (Identity) if there is no user logged on to the machine. A STA transmits an EAP-Response (Identity) containing the user name in response to an EAP-Request (Identity) if there is a user logged on to the machine.

4. The wireless AP forwards the EAP-Response (Identity) message to a RADIUS server. The RADIUS server sends an EAP-Request (either MD5 Challenge or TLS) in response to the EAP-Response (Identity) message from the STA. (TLS is required for wireless; the RADIUS server cannot enable the transmission of multicast/global, and if required, the per-STA unicast session authentication keys to STA in a secure manner.) The wireless AP forwards the EAP-Request from the RADIUS server to the STA.

5. The STA transmits an EAP-Response (containing its credentials) to the RADIUS server via the wireless AP. The wireless AP forwards the STAs credentials to the RADIUS server.

6. The RADIUS server validates the STAs credentials and generates a success message to STA. The RADIUS servers response to the wireless AP contains the STA message and the encryption key derived from the EAP-TLS session key. The wireless AP generates the multicast/global authentication key by generating a random number or by selecting it from an existing set value. On receiving the RADIUS server message, the wireless AP forwards the success message to the STA.

7. The wireless AP transmits an EAP-Key message to the STA containing the multicast/global authentication key encrypted using the per-session encryption key. If the wireless AP and STA support the per-STA unicast session key, the AP uses the encryption key sent from the radius server as the per-STA unicast session key.

8. When the wireless AP changes the multicast/global authentication key, it generates EAP-Key messages, where each message contains the new multicast/global authentication key encrypted with the particular STAs per-STA unicast session key. The wireless AP adds the per-STA unicast session key, if supported, to the per-STA list of unicast session keys.

9. The STA, on receiving the EAP-Key message, uses the per-STA unicast session encryption key to decrypt the multicast/global authentication key. If the wireless AP and STA support per-STA unicast session keys and a multicast/global authentication key has been received, the encryption key derived from the EAP-TLS session key is passed to the wireless STA as the per-STA unicast session key.

10. When the wireless network adapter driver receives the authentication keys, it must program the wireless STA network adapter. Once the authentication keys have been programmed, the STA calls Dynamic Host Configuration Protocol (DHCP) to restart the DHCP process.

 Top of page

Network Adapter Card Requirements

The adoption of IEEE 802.11 in both infrastructure and ad hoc network modes can be greatly enhanced by reducing the complexity in network adapter configuration. It would be preferred that network adapter configuration is automated and completed without extensive user intervention. The key configuration issues that require resolution are:

• Configuration of the client under different operating scenarios.

• Reconfiguration of the client when moving between operating scenarios.

• Configuration of the client to secure WLAN access.

In addition to the configuration issues listed above, the IEEE 802.11 network adapter will include the following enhancements:

• WEP authentication. In addition to the Open System and Shared Key authentication services, the IEEE 802.11 network adapter should support a third authentication method as the default setting. The default authentication algorithm first attempts to perform an IEEE 802.11 Shared Key authentication if the network adapter has been pre-configured with a WEP Shared Key. In the event the authentication fails or the network adapter is not pre-configured with a WEP Shared Key, the network adapter should revert to the Open System authentication.

• Power modes. An IEEE 802.11 network adapter should support two power settings: one for machines connected to Alternating Current (AC) and another for machines on battery. In the default mode, the AC setting should be configured to maximize the machine operation speed, while the battery setting should be configured to minimize the machine battery utilization.

• Client name. The client name will be passed to the IEEE 802.11 network adapter to use for various purposes. As a default setting, the client name will be set to the machine name.

• Media sense. The IEEE 802.11 network adapter must support media sense and indicate a media connect event when associating with a new access point. No disconnect event is required unless the network adapter has completely lost connectivity. The connect event indicates to the transport that it should look for a potential subnet transition.

NDIS Changes

This section outlines the changes made to Network Device Interface Specification (NDIS) support in Windows XP to support the network adapter requirements listed in the previous section. Complete information about NDIS changes is provided in the Windows DDK.

The machine name will be passed to network adapter driver during startup. Some network adapters and APs use this information for various management purposes.

The power mode state will be passed to network adapter driver during startup and whenever the state changes. At the minimum, a transition to AC setting or to battery setting will be indicated to the network adapter driver.

NDIS will call the miniports PnPEventNotifyHandler() initializing or setting the miniport to power state D0 and when the power profiles changes. The PnP Event will be NdisDevicePnPEventPowerProfileChanged and the InformationBuffer will point to an ULONG containing the following:

typedef enum _NDIS_POWER_PROFILE















{















    NdisPowerProfileBattery,















    NdisPowerProfileAcOnLine















} NDIS_POWER_PROFILE, *PNDIS_POWER_PROFILE;

NDIS OIDs

A number of new object identifiers (OIDs) are required from the IEEE 802.11 NDIS miniport driver to enable the new functionality described earlier. These OIDs will be available via Windows Management Instrumentation (WMI). The miniport is required to support these OIDs; however, the call may fail if the network adapter hardware does not support the associated functionality. The following table provides a summary of the WLAN-dependent wireless objects:

The NDIS types used with these WLAN OIDs are described in the Windows DDK.

SSID Association Requirement/Algorithm

The network adapter must install by default with no network name configured, following this algorithm:

• If not associated with a network, then associate with any network infrastructure that is beaconing its network name.

• If association fails, then retry with another network infrastructure if available.

• Repeat this behavior until no more infrastructures are available.

• If no associations have been made, switch into ad hoc network mode, if permitted, until a new infrastructure becomes available.

• If the Service Set Identifier (SSID) OID is called when associated with a network, continue as if association failed with this network.

Setting the SSID or a call to OID_802_11_INFRASTRUCTURE_MODE will reset this association requirement/algorithm.

 Top of page

Access Point Requirements

In order to incorporate security services into APs, additional requirements are needed for IEEE 802.1X, SSID to EAP-Identity text, and RADIUS support. These requirements are described in detail in this section.

SSID to EAP-Identity Text

The IEEE 802.11 SSID should be copied into the EAP-Identity/Request message field.

RADIUS Support

The RADIUS client in the AP should implement retransmission of lost packets. In a high loss or high interference environment, using EAP-TLS that goes through many rounds of data exchange, the RADIUS client should implement retransmissions based on a timeout that can be changed based on network characteristics. This also requires that the RADIUS server keeps state and is able to account for retransmissions. The RADIUS client in the AP should also implement fail-over protection to increase the robustness of RADIUS client access to the RADIUS server. This can be done by enabling the RADIUS client to direct its transactions to alternate RADIUS servers if the primary one should fail, which would eliminate a single point of failure.

The WEP key can be configured into the AP or can be generated by the AP using a random number generator. If the same WEP key is configured into multiple APs, the AP can authenticate an STA immediately after it performs IEEE 802.11 authentication.

IEEE 802.1X enables a more scalable and manageable access control mechanism. By adding a new IEEE 802.1X message, the EAP over LAN (EAPOL) key could be sent from the AP to the STA once IEEE 802.1X authentication has succeeded. This message contains a WEP key that can be used to generate the encryption key used by IEEE 802.11. However, the use of this message requires an EAP authentication method such as EAP-TLS.

The RADIUS server will generate a per-session encryption key. This per-session encryption key is used to encrypt the WEP key. The RADIUS server passes the per-session encryption key to the AP in the success message. The encrypted WEP key will be transmitted from the AP to the STA. STAs and APs, when using IEEE 802.1X and WEP, allow encrypted and non-encrypted traffic to be received as specified in the IEEE 802.11 standard.

If WEP key distribution is enabled, then AP should perform a further check; the AP should drop all unencrypted non-IEEE 802.1X traffic. It is recommended that APs perform this additional filtering to enhance the security level beyond MAC address filtering.

WEP Authentication

If multiple APs are configured with the same WEP key, then the AP can implement an additional optimization. The network adapter should attempt to perform an IEEE 802.11 authentication using the WEP key obtained from the old AP as the shared key. If this succeeds, then the AP should immediately add the STA to the authenticated list.

If the authentication fails, the network adapter will use open system authentication to the AP, and a complete IEEE 802.1X authentication will occur. The AP is required to be able to discern whether a STA used open system authentication or performed a shared key authentication.

In the event the STA gains access to the new AP via the shared key authentication, the IEEE 802.1X authentication will still be initiated by the new AP to update accounting records.

Enabling the STA network connectivity via shared key authentication while the new AP executes IEEE 802.1X ensures that the STA does not experience network connectivity interruption. However, if the STA does not successfully complete IEEE 802.1X authentication with the new AP, the network connectivity to the STA via the controller port on the AP will be terminated, ensuring network security.

EAPOL-Key

This message is only for IEEE 802.11 networks and allows the wireless AP to send one or more WEP keys from the AP to the STA. A single global WEP is required for each AP to support privacy; this can be generated at random by the access point, or it can be configured in some manner and passed to an STA via the EAPOL-Key message.

The AP should use two global keys, alternating between them as the global key is changed. APs are allowed to send an EAPOL-Key message at any time after authentication to update the WEP keys at the STAs.

The per-STA unicast session key is derived by reusing the keys used for user authentication per RFC 2548, which defines the Microsoft vendor attributes the RADIUS server sends to the RADIUS client in the AP. Note that the Microsoft vendor ID is 311. The AP might send the WEP key for data transmissions from the STA to the AP. However, the AP might not send the WEP key. In such a scenario, the STA will use the MS-MPPE-Send-Key as the WEP key for data transmissions from the STA to the AP.

Moving between Access Points

When moving between APs, the previous AP address is passed to the new AP by the STA. If the APs do not offer inter-AP interaction support, then the STA will be re-authenticated to the new AP by an EAP-Start message from the AP.

However, an IAPP can be defined to allow the new AP to obtain the authentication information from the old AP and send a new EAPOL-Key message to the STA with a new set of WEP keys. IAPP should also transfer to the new AP enough of the RADIUS server account information for the new AP to continue the same account records rather than start a new account record.

Call to Action

• Support the new NDIS Object Identifiers in NDIS miniports. Add support for IEEE 802.1X in your access points, including RADIUS client support as identified in this article.

• Develop driver support based on the Windows DDK.
  The final DDK for Windows XP will be made available on the Web at http://www.microsoft.com/whdc/devtools/ddk/default.mspx.

• The Windows Logo Program for hardware includes the wireless networking requirements that apply for IEEE 802.11 support, including: "IEEE 802.11 wireless networking adapters support 11 Mb/s signaling using Direct Sequence Spread Spectrum."
  For complete information, download and review Microsoft Windows Logo Program System and Device Requirements at http://www.microsoft.com/whdc/winlogo/default.mspx.

• For more information about IEEE 802.11 and other wireless technologies, see Wireless Technologies.
  
  For additional information or to send queries, please contact ndisfb@microsoft.com

 Top of page