Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 

WLC version which supports EAP-Subscriber Identity Module (EAP-SIM)?


[toc:faq]

 

Introduction

Question - Which version of the software WLC starts to support EAP-Subscriber Identity Module (EAP-SIM)?

Answer

The WLC does any type of EAP (802.1x) and is only the authenticator so it just passes the info to a radius server which has to be able to process EAP-SIM. So it's not really what version, because it has been supported way back when (802.1x), but what radius supports it.

Details

To support EAP-SIM in WLC software version is not at all the point of concern.

As RADIUS server EAP-SIM support makes it possible for GSM subscribers to use a single SIM for both voice and data access. The RAD-Series RADIUS Server EAP-SIM Developer’s Kit empowers the GSM operator to create a compatible and reliable interface to his SS7 network. The need for a redundant subscriber database and the associated management costs are eliminated while guaranteeing a uniformly secure network for both voice and data services.

Several 802.1X authentication types exist, each providing a different approach to authentication while relying on the same framework and EAP for communication between a client and an access point. Cisco Aironet products support more 802.1X EAP authentication types than any other WLAN products. Supported types include:

EAP SIM Architecture

The EAP subscriber identity module (SIM) authentication algorithm is designed to provide per-user/per-session mutual authentication between a wireless LAN (WLAN) client and an AAA server. It also defines a method for generating the master key used by the client and AAA server for the derivation of WEP keys. The Cisco implementation of EAP SIM authentication is based on the most recent IEEE draft protocol. This section will take a closer look at EAP SIM, from protocol message exchanges to how to implement EAP SIM on the AAA servers, access points, and client devices.

Global System for Mobile Communications

EAP SIM authentication is based on the authentication and encryption algorithms stored on the Global System for Mobile Communications (GSM) SIM, which is a Smartcard designed according to the specific requirements detailed in the GSM standards. GSM authentication is based on a challenge-response mechanism and employs a shared secret key, Ki, which is stored on the SIM and otherwise known only to the GSM operator's Authentication Center (AuC). When a GSM SIM is given a 128-bit random number (RAND) as a challenge, it calculates a 32-bit response (SRES) and a 64-bit encryption key (Kc) using an operator-specific confidential algorithm. In GSM systems, Kc is used to encrypt mobile phone conversations over the air interface.

EAP SIM Authentication Process

EAP SIM authentication provides a hardware-based authentication method secure enough to implement in potentially hostile public wireless LAN deployments. It allows GSM mobile operators to reuse their existing authentication infrastructure for providing access to wireless networks, mainly in public access "hot spots." EAP SIM combines the data from several GSM "triplets" (RAND, SRES, Kc), obtained from an AuC, to generate a more secure session encryption key. EAP SIM also enhances the basic GSM authentication mechanism by providing for mutual authentication between the client and the AAA server.

On the client side, the EAP SIM protocol, as well as the code needed to interface with a Smartcard reader and the SIM, is implemented in the EAP SIM supplicant. The supplicant code is linked into the EAP framework provided by the operating system; currently, supplicants exist for Microsoft Windows XP and 2000. The EAP framework handles EAP protocol messages and communications between the supplicant and the AAA server; it also installs any encryption keys provided the supplicant in the client's WLAN radio card.

On the network side, the EAP SIM authenticator code resides on the service provider's AAA server. Besides handling the server side of the EAP SIM protocol, this code is also responsible for communicating with the service provider's AuC. In a Cisco implementation of EAP SIM, the AAA server communicates with a Cisco IP Transfer Point (ITP), which acts as a gateway between the IP and Signaling System 7 (SS7) networks. The Cisco ITP translates messages from the AAA server into standard GSM protocol messages, which are then sent to the AuC.

802.1X authentication using Cisco implementation of EAP SIM proceeds as follows (Figure):

1. An EAP-over-LAN (EAPOL) Start message from the client starts the authentication protocol and indicates to the access point that the client wants to authenticate using EAP.

2. In response, the access point sends an EAP Identity Request message to the client. At this point, the client has not yet been assigned an IP address, and the access point blocks all messages from the client except for those necessary for authentication (EAP and EAP SIM protocol messages).

3. The client responds to the access point's request with an EAP Identity Response message containing the user's network identity. This identity is read from the SIM card, using a card reader attached to (or incorporated into) the client. It is of the form 0<IMSI>@<realm>, where <IMSI> is the International Mobile Subscriber Identity (as used in GSM networks) and <realm> is the operator's domain name string (voicestream.com, for example). The network identity is stored on the SIM and determined by the service provider; it may differ from the user's login credentials and is used mainly to authenticate access to the WLAN.

4. The access point forwards the EAP Identity Response to the AAA server using a RADIUS protocol message with Cisco vendor-specific attributes.

5. The AAA server determines that the user intends to use EAP SIM authentication based on its configuration parameters or on the identity passed to it and invokes its EAP SIM extension code. This code then starts the EAP SIM extension protocol by sending an EAP SIM Start request back to the client. It may also generate a GetAuthInfo message to the AuC requesting a (configurable) number of GSM triplets; this step may be delayed until after a response to the EAP SIM Start message is received to ensure that the client indeed supports the EAP SIM protocol.

 

Note:    Depending on the realm (domain) contained in the identity string, the AAA request might need to be proxied from the local AAA server to the service provider's AAA server.

 

6. The GetAuthInfo message is routed to the Internet Transfer Point Mobile Application Part (ITP MAP) proxy, which acts as a gateway to the service provider's SS7 network. The ITP translates the request into a standard GSM MAP GetAuth request before sending it to the AuC.

7. On receiving the EAP SIM Start request, the client reads a 128-bit (16-byte) random number generated on the SIM and passes it back to the AAA server in the EAP SIM Start response.

8. Once the AAA server has received the client's EAP SIM Start response and the response from the AuC containing a sufficient number of GSM triplets (typically two to three), it then constructs an EAP SIM Challenge message that contains the random numbers (RAND) received from the AuC and a 160-bit (20-byte) message-authentication code (MAC_RAND).

9. The client passes the EAP SIM Challenge request to the SIM card, which first calculates its own MAC_RAND. The AAA server is validated if the result matches the MAC_RAND received from the server. Only in that case, the SIM also calculates the GSM result (SRES) and encryption key (Kc) for each of the RANDs it received, as well as a 160-bit (20-byte) message-authentication code (MAC_SRES) based on these results and the user identity. Only MAC_SRES is returned to the AAA server (and therefore exposed on the radio link) in the EAP SIM Challenge response. The SIM also calculates cryptographic keying material, using a secure hash function on the user identity and the GSM encryption keys, for the derivation of session encryption keys.

10. When the AAA server receives the client's EAP SIM Challenge response, it calculates its own MAC_SRES and compares it to the one received from the client. If both match, the client is authenticated and the AAA server also calculates the session encryption keys. It then sends a RADIUS ACCEPT message to the access point, which contains an encapsulated EAP Success message and the (encrypted) client session key.

11. The access point installs the session key for the client's association ID and forwards the EAP Success message to the client. It then sends its broadcast key, encrypted with the client's session key, in an EAP Key message to the client. It also unblocks the data path for the client so that IP traffic can flow between the client and the rest of the network.

12. Upon receiving the EAP Success message, the EAP SIM supplicant returns the session encryption key calculated by the SIM to the EAP framework, which installs it on the client's WLAN radio card.

13. The client is now able to securely send and receive network traffic.

 

Note:

The client's session key is never sent across the radio link and can therefore not be snooped by network attackers listening in on the message traffic. Similarly, the results of the GSM authentication algorithm (SRES, Kc) are never exposed to listeners over the radio link. EAP SIM, therefore, exposes even less information to network attackers than the standard GSM authentication for wireless phones.

All message authentication codes described above are calculated using a secure keyed hashing algorithm, HMAC-SHA1 (steps 4 and 5). A hash function is an algorithm that one-way encrypts data so that it cannot be decrypted to derive the original input data. The algorithm uses the user's identity, the random number generated by the SIM, the GSM encryption keys Kc, and other data to calculate the authentication codes and encryption keys used in EAP SIM.

The Cisco implementation of EAP SIM is particularly secure because the results of the GSM authentication algorithm (SRES, Kc) never leave the SIM and therefore remain inaccessible even if network attackers manage to compromise the EAPSIM supplicant code. This is made possible by a partnership between Cisco and Gemplus, a world leader in Smartcard technology and leading supplier of SIM chips to the GSM industry. Other implementations of EAP SIM, using standard GSM SIM chips or software-based SIM emulators, are possible but are inherently less secure than the Cisco solution.

Reference

Wireless LAN Security White Paper

This document was generated from the following discussion: Which version of the software WLC starts to support EAP-SIM?