Recommendations for IEEE 802.11 Access Points

Updated: April 2, 2002

This article provides information about how to make available IEEE 802.11 wireless technology in diverse environments around the world. It provides guidelines for making wireless technology manageable by creating wireless access points that support specific functionality and are configured in several ways.

The Microsoft Windows XP operating system includes built-in support for 802.11 network adapter drivers and an 802.1X client.

On This Page

  Introduction
  Security Concerns with Wireless LANs
  802.1X and WEP Encryption
  RADIUS Support in Wireless APs
  The EAPOL-Logoff Message
  Using the EAP-Identity/Request String
  Un-Authenticated Access
  Guest Access Scenarios
  Multiple Service Provider Shared Wireless Infrastructure
  SNMP MIB Support
  Roaming Authentication Handoff between Access Points
  Dynamic Frequency Selection
  Country Information Element
  Future Directions
  Summary of Recommendations and Requirements for Various Scenarios
  Additional Reading
  References
  Resources and Call to Action

Introduction

IEEE 802.11, 802.11a, and 802.11b (also known as Wi-Fi) are wireless local area networking (LAN) standards that supply 1 megabit per second or higher bandwidth. Because these networks differ from wired LANs, several issues unique to wireless LAN deployment must be addressed. The major deployment issues for IEEE 802.11 wireless LANs include managing access to the network and privacy of the wireless traffic.

In a wireless deployment, there are a number of technologies that work together to make the wireless experience seamless from the end users point of view. Windows XP ships with support for 802.11 network adapter drivers and an 802.1X client. To implement 802.1X for an 802.11 network, components must be available in the network to implement three key roles: supplicant, authenticator, and authentication server.

• The supplicant the component that requests access to the network is provided by the 802.1X client that ships in Windows XP.

• The authenticator provides for authenticated access to the wired network, which must be provided by the wireless Access Point (AP).

• The authentication server is required to provide for authentication of the user or device. The Microsoft Windows 2000 Internet Authentication Service (IAS) server (a RADIUS Server) has been modified to support wireless endpoints for a secure 802.11, enterprise-ready network. Other requirements might include an account database such as Active Directory and at times a Certificate Authority.

To encourage the deployment of wireless technology, to make this technology usable in a number of interesting environments, and to make that technology manageable, wireless Access Points need to support a number of functions and be configurable in several ways. This article outlines these requirements.

 Top of page

Security Concerns with Wireless LANs

Although 802.11 wireless LANs have experienced a rapid growth, a number of security concerns have been raised for wireless networks in general.

The 802.11 wireless LAN standards define authentication and encryption services based on the Wired Equivalent Privacy (WEP) algorithm. The WEP algorithm defines the use of a 40-bit secret key for authentication and encryption. Many 802.11 implementations also allow 104-bit secret keys. However, the standard does not define a key management protocol, and presumes that the secret, shared keys are delivered to the 802.11 wireless stations (STA) using a secure channel independent of 802.11.

The lack of a WEP key management protocol is a principal limitation to providing 802.11 security, especially in a wireless infrastructure network with a large number of stations. Some examples of this type of network include corporate campuses, and public places such as airports and malls. When manually-configured shared keys are used, the keys tend to remain in place for long periods of time, enabling hackers more time to use various attacks to obtain the keys and decrypt the traffic.

The lack of rich authentication and encryption services also effect operation in a wireless ad hoc network (peer to peer wireless network) where users may wish to engage in peer-to-peer collaborative communication; for example, in areas such as conference rooms. In addition, lack of inter-access point protocol (IAPP) further accentuates the key management issues when STAs roam from one to AP to another.

As a result, the enhanced importance of authentication and encryption in a wireless environment proves the need for access control and security mechanisms that include a key management protocol for 802.11.

IEEE 802.1X

IEEE 802.1X is a standard for port-based network access control that provides authenticated network access for Ethernet networks. Port-based network access control utilizes the physical characteristics of the switched LAN infrastructure 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 called a Port Access Entity (PAE), can adopt one of two roles in the access control interaction: authenticator or supplicant. An authenticator is a port that enforces authentication before allowing access to services (usually the rest of the network) available using that port. The supplicant is a port that requests access to these services from the authenticator.

A third component of the solution, the authentication server, provides authentication by checking the credentials of the supplicant on behalf of the authenticator. The authentication server 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.

Figure 1: LAN with Two Logical Access Points

The authenticators port-based access control defines two logical access points to the LAN using a single physical LAN port as shown in Figure 1. The first logical access point, 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, the controlled port, allows access to the LAN only if the system is authorized.

Using IEEE 802.1x for Wireless Authentication
This section describes how IEEE 802.1X can be used for wireless authentication using a Remote Authentication Dial In User Service (RADIUS) server for authenticating client credentials. An extension to the basic IEEE 802.1X protocol is required to allow a wireless access point to identify and secure a particular clients traffic. This is accomplished 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 is used to encrypt all packets sent by a client.

In this model, 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 wireless AP issues a challenge to the wireless STA. When the STA receives the challenge from the AP, the STA sends its identity to the AP, which forwards it to the RADIUS server (authentication server) to initiate authentication services. The RADIUS server then sends a request to the STA for its credentials to confirm identity and specify the type of credentials required. Requests passing between the STA and the RADIUS server pass through the uncontrolled port on the AP because the STA cannot directly reach the RADIUS server.

The AP does not allow communication through the controlled port at this time because the STA does not posses an authentication key. The STA sends credentials to the RADIUS server. When the RADIUS server validates the credentials, it transmits an authentication key to the AP. The authentication key is encrypted so that only the AP can access the authentication key. AP uses the authentication key received from the RADIUS server to securely transmit per-STA unicast session and multicast/global authentication keys to the STA.

Because the global authentication key must be encrypted, the Extensible Authentication Protocol (EAP) authentication method used for wireless must be capable of generating an encryption key as part of the authentication process. The Transport Level Security (TLS) EAP type provides for mutual authentication, integrity-protected cipher suite negotiation and key exchange between the two endpoints. Therefore, EAP-TLS should be used to provide these capabilities.

Following the initial authentication, the IEEE 802.1X protocol should be configured to periodically request the STA to re-authenticate. The detailed authentication process is given below:

• 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 and should also support a per-STA unicast session key.

• The wireless AP implements a process that listens for IEEE 802.1X traffic both with and without authentication keys.

• Initiating authentication: 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 that STA. A STA transmits an EAP-Start on associating with a new AP.

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

• The wireless AP forwards the EAP-Response (Identity) message to a RADIUS server.

• The RADIUS server sends an EAP-Request, either an MD5 Challenge or a TLS in response to the EAP-Response (Identity) message from the STA. TLS is required for wireless, otherwise the RADIUS server cannot enable the transmission of multicast/global. TLS may also be required for 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.

• The STA transmits an EAP-Response containing its credentials to the RADIUS server using the wireless AP. The wireless AP forwards the STAs credentials to the RADIUS server.

• The RADIUS server validates the STAs credentials and generates a success message to the STA. The RADIUS servers response to the wireless AP contains the STA success 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 a priori set value. When the wireless AP receives the RADIUS server message, it forwards the success message to the STA.

• 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.

• 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.

• 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.

• On receiving the authentication keys the wireless network adapter driver must program the wireless STA network adapter. The 802.1x engine is responsible for triggering the DHCP process once authorization is successful.

 Top of page

802.1X and WEP Encryption

It is important to note that WEP Encryption should be turned on with 802.1X. Although it is possible to enable 802.1X without WEP, this type of configuration should not be allowed because of the security threat that it represents. Using 802.1X without WEP encryption means that while enforcing user authentication to an AP port, all traffic will be sent in the clear. Because this method is not secure, 802.1X should be used with WEP.

 Top of page

RADIUS Support in Wireless APs

For an 802.1X client to gain full network access, an Access Point must implement a RADIUS client. A RADIUS client sends user credentials and connection parameter information in the form of a RADIUS message to a RADIUS server. The RADIUS server authenticates and authorizes the RADIUS client request, and sends back a RADIUS message response. RADIUS messages are never sent between the access client (or STA) and the AP.

Retransmission

The RADIUS client in the AP should implement retransmission of lost packets. EAP-TLS goes through many rounds of data exchange. In a high loss or high interference environment, the RADIUS client should implement retransmissions based on a timeout that can be adjusted based on network characteristics. This also requires that the RADIUS server keep state and is able to account for retransmissions.

Failover Protection

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.

IEEE 802.1X Key Message

IEEE 802.1X enables a more scalable and manageable access control mechanism. By adding a new IEEE 802.1X message (the EAPOL-Key message), the EAP over LAN (EAPOL) key can be sent from the AP to the STA once IEEE 802.1X authentication has succeeded. APs are allowed to send an EAPOL-Key message at any time after authentication to update the WEP keys at the STAs. The message contains a WEP key that can be used to generate the encryption key used by IEEE 802.11. The use of this message requires an EAP authentication method such as EAP-TLS.

The RADIUS server will generate a per-session encryption key between station and RADIUS server. The RADIUS server passes this per-session encryption key to the AP in the RADIUS Access-Accept message. This per-session encryption key is used to encrypt the WEP key which has been generated by the AP. The encrypted WEP key will then be transmitted from the AP to the STA.

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.

Radius Key Attributes

The MS-MPPE-Send-Key and the MS-MPPE-Recv-Key attributes contain session keys intended for encrypting packets sent between NAS and STAs. These attributes are only included in Access-Accept packets.

For further details on these attributes, please see RFC 2548. Section 2.4.2 details the MS-MPPE-Send-Key attribute. Section 2.4.3 describes the MS-MPPE-Recv-Key Attribute.

Accounting

Additionally, the RADIUS client should be capable of sending accounting records, in addition to authentication messages.

 Top of page

The EAPOL-Logoff Message

This message is only for IEEE 802.11 networks and allows the wireless STA to logoff its session with the AP. However this message contains no means of validating that the client sending the Logoff message is the actual client on that connection. Because of this, Microsoft clients do not send EAPOL-Logoff Messages and instead send EAPOL-Start Messages at time of logoff. Therefore APs should ignore all EAPOL-Logoff Messages.

 Top of page

Using the EAP-Identity/Request String

Ethernet and IEEE 802.11 networks should be able to indicate their current location to the client/STA by adding an attribute to the EAP-Identity message that contains the service supplied by the network. For the IEEE 802.11 networks, if this attribute is not available, then the SSID should be used instead as a default.

The following format is proposed for the null-terminated displayable string and the comma-separated portion of the EAP-Identity message string:

This is a display string\0networkid=<network name>,nasid=<nas name>,portid=<port id>

Where:

network name: SSID for IEEE 802.11 but can be any string for Ethernet.

nas name: name of the IEEE 802.11 AP or Ethernet switch, or if no name, the MAC address of the AP or Ethernet switch.

port id: port ID that this particular IEEE 802.1X session is on.

The IEEE 802.1X STA should display the string before the null termination (\0) to enable administrators to display network identification messages.

 Top of page

Un-Authenticated Access

For Un-authenticated access, an IEEE 802.1X client should transmit a null string for identity in the EAP-Response/Identity message for an unauthenticated user. An unauthenticated user is defined as a user that lacks required credentials for accessing the network, for example, in the case of EAP-TLS, user certificates, this would be for the particular network the user is attempting to access.

Access Point Requirements

The access point receiving an EAP-Response/Identity message from an unauthenticated user will not include the User-Name RADIUS attribute (number 1) in the Access-Request RADIUS packet.

 Top of page

Guest Access Scenarios

This section includes information about the use of IEEE 802.1X in public places such as airports, malls, convention centers, and private places that require some level of network access, such as corporate conference centers.

An AP can provide three levels of network access to the client dependent on the authentication response from the RADIUS server:

• Complete network access, where the client has complete access to all the network resources provided to an authenticated user.

• Limited network access, where the client has limited access to network resources, for example, client transmissions may be redirected to a different logical or physical network.

• Restricted network access, where the client does not have access to any of the network resources.

In response to authentication responses from the RADIUS server, the AP should implement the network authorization as follows:

On receipt of an Access-Accept: Provision according to the default AP Virtual LAN (VLAN) setting, or according to the VLAN ID sent in Access Accept.

On receipt of Access-Reject: No access should be provided.

VLAN Support for Guest Access Scenarios

In order to implement these scenarios, the Access Point must allow configuration of VLAN Tagging. Listed below is the suggest default configuration for these VLAN settings:

The No-Guest Scenario:
You configure only Authenticated access. All Authentication failures are dropped. This should be the default behavior. All Authenticated traffic is placed on VLANID0.

The Enterprise Conference Room:
You configure the Access Point so that all Successful Authentications are Tagged with a VLANID that directs traffic to the corporate network (VLANID0). All Authentication failures are tagged with a VLANID that directs their traffic to the public internet (for example, VLANID7). At this point, the visiting user can either access publicly accessible resources and VPN to their respective corporate networks.

The Enterprise Partnership:
Configure the Access Point so that all Successful Authentications are tagged with a VLANID that directs traffic to the corporate network (VLANID0). Additionally, all Authentication for partnered credentials are forwarded to a RADIUS proxy that redirects the Authentication to the partners Authentication database. The return message supplies a VLANID (VLANID3) that can take their traffic directly to the partner network.

The Public ISP Scenario:
Users in public places can be classified into two categories:

• Those who have valid credentials for full network access.

• Those who do not have valid credentials for full network access. This group includes users who would like to subscribe to the valid credentials.

In public spaces, users intending to subscribe for Internet access would be required to register and enroll for the network access service prior to authentication. Therefore, IEEE 802.1X should be designed to permit access to enrollment and registration servers by directing user communication to the appropriate VLAN. EAP-Notification message can be used to inform the user of the location of the server to enroll and register the user for accounting and billing purposes prior to obtaining network access.

Configure the Access Point so that all Successful Authentications are tagged with the VLANID3 returned in the Access Accept packet or with VLANID3 as defined by ISP at the RADIUS Proxy. All non-Authenticated users are given access to a registration site that will allow them to sign-up for public access service (VLANID0).

It is also possible to combine some of these scenarios together. For example, the "Enterprise Conference" and "Enterprise Partnership" can be configured simultaneously.

Figure 2: Configuration for Guest Access Scenarios

Radius Tunnel Attributes

RFC 2868 defines RADIUS tunnel attributes used for authentication and authorization, and RFC 2867 defines tunnel attributes used for accounting. Where the IEEE 802.1X Authenticator supports tunneling, a compulsory tunnel may be set up for the Supplicant as a result of the authentication.

In particular, it may be desirable to allow a port to be placed into a particular VLAN based on the result of the authentication.

The RADIUS server typically indicates the desired VLAN by including tunnel attributes within the Access-Accept message. However, the IEEE 802.1X Authenticator may also provide a hint as to the VLAN to be assigned to the Supplicant by including Tunnel attributes within the Access-Request.

For use in VLAN assignment, the following tunnel attributes are sent:

Tunnel-Type=VLAN (13)

Tunnel-Medium-Type=802

Tunnel-Private-Group-ID=VLANID

See draft-congdon-radius-8021x-17.txt section 3.30 for a more complete description. Additionally, the format of the attributes can be found in RFC 2868.

 Top of page

Multiple Service Provider Shared Wireless Infrastructure

When two or more service providers install a wireless network infrastructure in the same location, such as an airport, there are potential RF issues. In the U.S. and most of Europe, Wi-Fi (IEEE 802.11b) networks can support only 3 non-overlapping channels. In some countries, such as France and Japan, only one channel is available. Once the available channels are used, no further non-overlapping spectrum is available for other providers. If a new wireless network infrastructure is added in the same area, it will generate interference with one of the existing networks that will result in reduced performance for both the incumbent network and the newcomer.

To support this scenario, Access Points need to support the use and configuration of multiple Extended Service Set ID (ESSID)s. Each ESSID needs to be able to support their own specific VLAN tag ID, RADIUS server, SNMP community string, and IP Address.

 Top of page

SNMP MIB Support

With a multitude of 802.11 devices scattered across a network infrastructure, common management and troubleshooting capabilities become necessary.

802.11 MIB
Management Objects for 802.11 are defined in part 11.4 of the IEEE 802.11 specification.

802.1X MIB
802.1X Management Objects for the Authenticator PAE are defined in section 9 of the IEEE 802.1X specification.

 Top of page

Roaming Authentication Handoff 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. An 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.

An IAPP standard is currently being worked on in the IEEE 802.11f Task Group.

 Top of page

Dynamic Frequency Selection

The various 802.11 standards operate two different frequency ranges. 802.11b products operate within the 2.4 GHz range, while 802.11a products operate within the 5 GHz range. Because of concerns that various countries around the world have allocated portions of the 2.4 and 5 GHz range to other applications, it is necessary that wireless LAN devices select the frequency range it uses based on its location. The 802.11 standard is being modified so that an AP can inform a wireless client of the appropriate frequency for local usage.

Dynamic Frequency Selection for the 5 GHz range is currently being worked on within the IEEE 802.11h Task Group.

 Top of page

Country Information Element

Countries across the globe are allocating portions of their wireless spectrum for various purposes. The Country Information Element in an AP Beacon frame contains the information required to allow a station to identify the regulatory domain in which the station is located, and to configure the frequency range it is allowed to operate on accordingly.

Further information on this can be found in the IEEE 802.11d standard.

 Top of page

Future Directions

Microsoft is actively engaged with the IETF and IEEE standard bodies, and with hardware vendors. Current initiatives focus on acceptance and support of the Advanced Encryption Standard (AES) for wireless encryption, TKIP (Temporal Key Integrity Protocol), rapid re-keying, the charter of the IEEE Task Group I (TGi) working group, EAP-Notification, and so on.

 Top of page

Summary of Recommendations and Requirements for Various Scenarios

 Top of page

Additional Reading

Wireless 802.11 Security with Windows XP, available at:
http://www.microsoft.com/ WINDOWSXP/ pro/ techinfo/ administration/ wirelesssecurity/ default.asp

Wireless Network Security with IEEE 802.1X, available at:
http://www.microsoft.com/ WINDOWSXP/ pro/ evaluation/ overviews/ 8021x.asp

Enterprise Deployment of IEEE 802.11 Using Windows XP and Windows 2000 Internet Authentication Service, available at:
http://www.microsoft.com/ windowsxp/ pro/ techinfo/ deployment/ wireless/ default.asp

 Top of page

References

1. Part 11: Wireless LAN Media Access Control (MAC) and Physical Layer (PHY) Specifications, International Standard ISO/IEC 8802-11:1999, ANSI/IEEE Std 802.11, 20 August 1999.

2. Standards for Local and Metropolitan Area Networks: Port based Network Access Control, IEEE Std 802.1X-2001, 14 June 2001.

3. L. Blunk, J. Vollbrecht, "PPP Extensible Authentication Protocol (EAP)," IETF RFC 2284, March 1998.

4. B. Aboba, D. Simon, "PPP EAP TLS Authentication Protocol," IETF RFC 2716, October 1999.

5. C. Rigney, A. Rubens, W. A. Simpson, S. Willens, "Remote Authentication Dial In User Service (RADIUS)," IETF RFC 2138, April 1997.

6. C. Rigney, "RADIUS Accounting," IETF RFC 2139, April 1997.

7. G. Zorn, "Microsoft Vendor-specific RADIUS Attributes," IETF RFC 2548, March 1999.

 Top of page

Resources and Call to Action

Call to Action:

• 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 current Windows DDK is available 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

Contact:
For additional information or to send queries, please contact ndisfb@microsoft.com

Resources:

• Windows Platform Development white papers and resources:
  IEEE 802.11 Technology
  Networking and Wireless Technologies

• Windows Driver Development Kit:
  http://www.microsoft.com/whdc/devtools/ddk/default.mspx

• Windows Logo Program for Hardware:
  http://www.microsoft.com/whdc/winlogo/default.mspx

 Top of page