Wireless Internet Service Providers (WISPs) currently offering public Wi-Fi hotspot service use access points (APs) configured for no encryption. WISPs currently don’t have an easy way of distributing encryption keys and other security settings to their customers. As lack of security is a growing concern, the wireless industry in general is in agreement that public Wi-Fi hotspots need to be secured as well, using technologies such as 802.1x and Wireless Provisioning Services.

WISPs who want to enable security in their hotspots while supporting their existing customers need 2 separate SSIDs with different security contexts to address both sets of customers. Some access points today provide this functionality but owing to hardware limitations, require that the second SSID is hidden. This presents a usability problem as one of the key requirements for wireless ISPs is that their hotspot service is easily discoverable or else users will not know how to connect to it.

Note that the virtual AP proposal solves this issue by allowing a single physical AP to support multiple BSSIDs with different security contexts. These BSSIDs can broadcast different SSIDs if required. However, the APs in the existing deployments do not yet implement the Virtual AP proposal so the WISPs cannot support both sets of customers with existing infrastructure without deploying dual infrastructure which is not feasible and is too expensive. More information about the Virtual AP proposal, see The Unofficial 802.11 Security Web Page.

The solution described below addresses the hidden SSID problem by leveraging the new Provisioning Information Element to advertise the hidden SSID.

Provisioning Information Element

The Provisioning information element (Provisioning IE) is a new 802.11 information element. Provisioning IE indicates in the 802.11 beacon from the Access Point whether a connection to this wireless network requires 802.1x, and if the network can provide provisioning information to the client.

The main goals of the new Provisioning IE are the following:

• Improve the end-user experience and decrease the amount of time needed to get connected. This can be done by allowing client systems to discover from the beacon if 802.1x is required to connect to the network, and if the network can provide provisioning information to the client. This approach will reduce the number of trials and timeouts the client system would have to go through when trying to connect and determine what the required network configuration and security settings are.
• Enable easy and cost effective migration from unsecured Public Wi-Fi hotspots to secured networks using 802.1x and Wireless Provisioning Services (WPS) on the same network infrastructure. This is done by leveraging existing capabilities in Access Points to use hidden SSIDs. This new information element advertises a hidden SSID in the beacon or probe response message indicating to the client that there is another network in addition to the visible one that the client can try to connect to.

The Provisioning IE is shown in the following table:

Since the WPS Information Element is limited by a 256 octet length, several IEs may be required to advertise all of the supported SSIDs on a radio interface; however, SSID capabilities shall be allocated to the Hidden SSID elements in a manner to minimize the total number of Hidden SSID elements required. The length field reports the length of the WPS IE excluding the Element ID and length fields; that is it specifies the length of the IE in octets commencing with the OUI.

The WPS IE may occur with zero occurrences of the Hidden SSID elements, for single SSID systems wanting to convey support for WPS and/or legacy 802.1X. If the SSID-Count field is zero, it may be omitted from the IE. For systems with multiple Hidden SSIDs, each hidden SSID may generate an entry in the information element.

For systems with multiple Hidden SSIDs which span more than one IE, multiple IEs should be used and the SSID-count field should reflect the number of Hidden SSIDs specified in that particular IE.

The SSID Extended Capability field also included for the primary SSID as the Primary SSID Extended Capability provides an indication of whether legacy 802.1X or WPS is supported by the SSID indicated in the SSID IE (e.g. Element ID 0).

The field is a single octet mask in which the bit representation is as shown in the following table:

The SSID capability field shall consist of the subfields shown in the following table:

The Capability.MCcipher shall have one of the CIPHER_ENUM_XXX values defined in the following table:

Note that if an SSID has both WPA1 and WPA2 enabled, then the multicast cipher must be the same for both WPA1 and WPA2; therefore, each cipher type appears only once in the multicast cipher list.

Note  If the multicast cipher is set to CIPHER_ENUM_NONE, then no encryption is utilized for that SSID.

The Capability.UCcipher shall be a sum of one or more CIPHER_BIT_XXX values defined in the following table:

Note that the unicast cipher CIPHER_BIT_NONE denotes either unencrypted unicast traffic, or that pairwise encryption keys are not supported. If the multicast cipher is CIPHER_ENUM_NONE, then CIPHER_BIT_NONE denotes unencrypted unicast traffic; otherwise, CIPHER_BIT_NONE denotes that pairwise encryption keys are not supported (that is, UNICAST NONE).

The Capability.AKMlist shall be a sum of one or more AKM_BIT_XXX values as defined in the following table:

Note  If all AKM_BIT_XXX values are set to zero, then neither 802.1x nor PSK modes are used and is a valid assignment.

The Capability field shall be built as shown below.

 CapabilityLong =  ((Capability.MCcipher << 0) |
(Capability.UCcipher<<4)|
(Capability.AKMlist<<24)
	// the four bytes of the capability field are then as follows:
	Capability[0] = ( (CapabilityLong >> 0)& 0xFF);
	Capability[1] = ( (CapabilityLong >> 8)& 0xFF);
	Capability[2] = ( (CapabilityLong >> 16)& 0xFF);
Capability[3] = ( (CapabilityLong >> 24)& 0xFF);

See Also

PEAP-TLV Packets, WPS Packet Sequence, WPS Authentication Renewal, WPS Authentication and Certificates, XML Schema