6.1.1. EAPOL protocol

The EAPOL protocol is exchanged between the supplicant and the authenticator. It initiates the supplicant’s identity announcement and the capacities of each end. It ensures the transport of EAP/EAP-Method messages, which enable authentication of the supplicant, and possibly of the authentication server.

The structure of the EAPOL protocol is shown in Figure 6.3.

The EAP is made up of a four-byte header and a packet body.

Version: this field, coded on one byte, identifies the version of the protocol and has the value of 03 in hexadecimal for the latest standardized version.

Packet Type: this field, coded one byte, identifies the type of data encapsulated by the EAPOL header. The EAPOL header can encapsulate an EAPOL message or an EAP message.

Packet Body Length: this field, coded on two bytes, indicates the size of the data encapsulated by the EAPOL header.

6.1.2. EAP

The EAP is deployed for the access of a supplicant (network host) to the authenticator (switch or access point) and the authentication server. It enables the transport of authentication data and does not require Internet Protocol (IP) connectivity.

The structure of the EAP is shown in Figure 6.4.

The EAP is composed of a four-byte header and possibly an EAP-Method message.

Code: this field, coded on one byte, identifies the type of EAP message:

• – Request: this message enables the authentication server to communicate with the supplicant, for example, to transmit to it an EAP-Method message; the supplicant can also transmit this message to the authentication server to request its identity during mutual authentication;
• – Response: this message is sent in reply to the previous message; it can correspond, for example, to the supplicant’s authentication data contained in an EAP-Method message;
• – Success: this message is used by the authentication server to inform the supplicant that it has been successfully authenticated;
• – Failure: this message is used by the authentication server to inform the supplicant that authentication has failed.

Identifier: this field, coded on one byte, enables correlation of the messages exchanged between the supplicant and the authentication server or the authenticator.

Length: this field, coded on two bytes, indicates the size of the EAP message. This value is identical to the value of the Packet Body Length field in the EAPOL protocol header.

When the EAP message is a request or a reply, the header encapsulates an EAP-Method message that contains the Type field, coded on one byte, identifying the type of data in the EAP-Method message.

The first three values in the Type field are reserved for specific messages (Identity, Notification and NAK). The other values pertain to identification methods such as EAP-message digest 5 (MD5) (Type = 4), EAP-TLS (Transport Layer Security) (Type = 13) or EAP-TTLS (Tunneled TLS) (Type = 21).

6.1.3. RADIUS messages

The RADIUS protocol is used for transporting EAP-Method messages between the authentication server and the authenticator (switch or access point), used to identify the supplicant. RADIUS messages are encrypted and checked in their entirety using a secret shared between the two end points.

6.1.4. Authentication procedure

Prior to the 802.1x authentication procedure, the supplicant must connect to the authenticator:

• – if the supplicant is connected to an Ethernet switch, the 802.1x procedure starts when its interface is activated;
• – if the supplicant is connected to a Wi-Fi access point, the 802.1x procedure starts at the end of the association phase with the Wi-Fi access point.

Whatever the authentication method used, the procedure is initiated by the supplicant, which transmits the EAPOL-Start message (Figure 6.5).

The authenticator continues the procedure by sending the EAP-Request message containing the EAP-Method Identity message.

The supplicant provides its identity by replying with an EAP Response/EAP-Method Identity message. This message is transmitted by the authenticator to the authentication server in a RADIUS Access-Request message.

The next series of operations depend on the authentication method chosen.

After the authentication phase exchanges, the authentication server transmits to the supplicant:

• – the EAP Success message if it is authenticated, in which case the authenticator authorizes traffic from the supplicant;
• – the EAP Failure message in the opposite case, and access to the network remains prohibited.

The EAP Success (or EAP Failure) message is transmitted in a RADIUS Access-Accept (or Access-Reject) message at the interface between the authentication server and the authenticator.

6.2.1. Key hierarchy

Data protection on the radio interface is based mainly on secret keys. When a security association is established after successful authentication, temporary keys are created:

• – pairwise transient key (PTK) is derived from the pairwise master key (PMK) for the unicast data;
• – group transient key (GTK) is derived from the group master key (GMK) for the multicast and broadcast data.

These derived keys are regularly updated until the context is closed.

The derivation of the PMK uses the HMAC-SHA1 function, the result of which is 384 bits in size for the CCMP (Counter-mode/Cipher block chaining MAC (Message Authentication Code) Protocol) and 512 bits in size for the TKIP (Temporal Key Integrity Protocol).

The PTK, derived from the PMK, is obtained using the MAC addresses of the authenticator (AA) and the supplicant (SPA), and random numbers (Anonce and Snonce) exchanged during the four-way handshake procedure.

• PTK = HMAC-SHA1(PMK, “Pairwise key expansion”, Min(AA, SPA) ∥ Max(AA, SPA) ∥ Min(ANonce,SNonce) ∥ Max(ANonce,SNonce))

The PTK is cut up in order to provide the following keys:

• – 128-bit key confirmation key (KCK). This key is used to authenticate messages during the four-way handshake procedure;
• – 128-bit key encryption key (KEK). This key is used to encrypt messages during the four-way handshake and group key handshake procedures;
• – 128-bit temporary key (TK). This key, used for TKIP and CCMP, serves to encrypt unicast data;
• – 64-bit TMK1 (temporary message integrity code (MIC)) and TMK2. These keys, used for TKIP, check the integrity of the data. Each direction of transmission uses a specific key: TMK1 is used by the AP, and TMK2 is used by the station to generate the seal.

The derivation of the GMK also uses the HMAC-SHA1 function, with a result 128 bits in size for the CCMP and 256 bits in size for the TKIP.

The GTK, derived from the GMK master key, is obtained from the MAC address (AA) of the authenticator and from the random number (Gnonce):

• GTK = HMAC-SHA1(GMK, “Group key expansion” ∥ AA ∥ GNonce)

The GTK is cut up in order to provide the following keys:

• – 128-bit group encryption key (GEK). This key, used for TKIP and CCMP, encrypts broadcast and multicast data;
• – 128-bit group integrity key (GIK). This key, used for TKIP, checks the integrity of broadcast and multicast data.

6.2.2. Four-way handshake procedure

The four-way handshake procedure defines four EAPOL-Key messages exchanged between the authenticator and the supplicant (Figure 6.6).

This procedure enables the two end points to derive the PTK from the PMK and the distribution of the GTK by the authenticator.

The authenticator sends the first message to the supplicant if 802.1x authentication has been successful. This message contains the ANonce random number.

Upon reception of the first message, the supplicant generates a random number (SNonce), derives the PTK and constructs the second message containing the message integrity code (MIC) calculated from the KCK.

Upon reception of the second message, the authenticator derives the PTK, extracts the KCK from it and checks the MIC seal.

The third message is sent by the authenticator to the supplicant. It contains the GTK encrypted with the KEK and an MIC seal calculated using the KCK.

Upon reception of the third message, the supplicant checks that the MIC seal value is correct.

The fourth message is sent by the supplicant to complete the four-way handshake procedure.

Upon reception of the fourth message, the authenticator checks the MIC seal.

6.2.3. Group Key Handshake procedure

The group key handshake procedure (Figure 6.7) defines two EAPOL-Key messages exchanged between the authenticator and the supplicant. It takes place when the authenticator transmits a new GTK to the supplicant. The supplicant can start the procedure by sending an EAPOL-Key message.

The first message is initialized by the authenticator. It sends the new GTK encrypted with the KEK and the MIC seal calculated using the KCK.

Upon reception of the first message, the supplicant checks the MIC seal. It responds to the authenticator with the second message to acknowledge the first message.

Upon reception of the second message, the authenticator checks the MIC seal.

6.3.1. EAP-AKA method

The authentication and key agreement (AKA) mechanism has been defined for the attachment of the mobile to the 4G mobile network, and it allows mutual authentication of third parties and the distribution of keys.

Authentication is based on AUTN (Authentication Network) and RES (Result) seals generated by the home subscriber server (HSS) and the mobile from a RAND sequence and the secret key Ki.

The RAND sequence is generated by the HSS entity and then transmitted to the mobile. The secret key Ki is generated during the creation of the subscription and stored in the universal subscriber identity module (USIM) of the universal integrated circuit card (UICC) of the mobile.

Integrity key (IK) and cipher key (CK) are generated by the HSS entity and the mobile from a derivation of the Ki key using the RAND sequence. The master key PMK is derived from the keys CK and IK.

The EAP-AKA method is applied in the case of untrusted Wi-Fi access when establishing the SWu tunnel described in Chapter 7.

In the case of trusted Wi-Fi access, the EAP-AKA’ method replaces the EAP-AKA method. The modification concerns the derivation of the keys CK and IK, which takes account of the identity of the access network, and the derivation algorithm.

The three components involved in the authentication procedure are integrated into the following entities:

• – the supplicant is represented by the mobile which wishes to access the 4G mobile network;
• – the authenticator is represented by the trusted Wi-Fi access that controls the access of the supplicant to the 4G mobile network;
• – the authentication server is represented by the AAA (Authentication, Authorization and Accounting) server, which authenticates the supplicant and authorizes access to the 4G mobile network.

EAP-AKA’ messages are carried between the trusted Wi-Fi access and the AAA server in DIAMETER messages:

• – DER (Diameter-EAP-Request) message is transmitted by the trusted Wi-Fi access;
• – DEA (Diameter-EAP-Answer) is transmitted by the AAA server.

6.3.2. Mutual authentication procedure

The procedure of mutual authentication, in the case of a trusted Wi-Fi access, is part of the procedure of attachment of the mobile.

At the end of the association phase with the trusted Wi-Fi access, the mobile transmits the EAPOL-Start message, which triggers the mutual authentication procedure based on the EAP-AKA’ method (Figure 6.8).

1. 1) Trusted Wi-Fi access sends the EAP Request message containing the EAP-Method Identity message.
2. 2) The mobile transmits the EAP Response/EAP-Method Identity message containing, at the first authentication, the network access identifier (NAI) constructed from the international mobile subscriber identity (IMSI) of the mobile.
3. 3) Wi-Fi access completes the EAP Response/EAP-Method Identity message, including the access network parameters (type, identity) and transfers it to the AAA server in a DER DIAMETER message.
4. 4) The AAA server asks the HSS entity the cryptographic data of the mobile in the AIR (Authentication-Information-Request) DIAMETER message.

   The HSS entity generates the RAND sequence and creates the RES, AUTN, CK’ and IK’ parameters from the key Ki and the RAND sequence.

5. 5) The HSS entity transmits the authentication vectors to the AAA server in the AIA (Authentication-Information-Answer) DIAMETER message.
6. 6) The AAA server derives the two keys CK’ and IK’ to generate the master key PMK and generates a pseudonym and possibly an identifier for the rapid renewal of the authentication.

   The pseudonym and the identifier are temporary identities constructed from encryption of the private identity IMSI, using the advanced encryption standard (AES) algorithm. The same secret key is used by all AAA servers.

   The AAA server transmits to the trusted Wi-Fi access the EAP Request/EAP-Method AKA’ Challenge message containing the identity of the access network, the RAND sequence, the AUTN seal, the pseudonym and possibly the identifier for the renewal of the authentication.

   This message is transmitted in a DEA DIAMETER message and contains a message authentication code (MAC) for the integrity check.

7. 7) Trusted Wi-Fi access transfers the EAP Response/EAP-Method AKA’ Challenge message to the mobile.
8. 8) The mobile locally calculates, from its key Ki and the received RAND number, the key PMK, its seal RES and that of the AUTN network. The mobile compares the received AUTN with the calculated value. If both values are the same, the network is authenticated. The mobile also controls the integrity of the received message.

   The mobile transmits the EAP Response/EAP-Method AKA’ Challenge message containing the RES seal and the MAC seal for the integrity check of the message to the trusted Wi-Fi access.

9. 9) Trusted Wi-Fi access transfers the EAP Response/EAP-Method AKA’ Challenge message to the AAA server in a DER DIAMETER message.
10. 10) The AAA server checks the integrity of the received message and compares the RES seal received from the mobile to that received from the HSS entity. If the two values are identical, the mobile is authenticated.

    The AAA server transmits the DEA DIAMETER message containing the EAP Success message and the PMK to the trusted Wi-Fi access.

11. 11) Trusted Wi-Fi access stores the PMK and transfers the EAP Success message to the mobile.

6.3.3. Procedure for rapid renewal of authentication

The rapid renewal of authentication makes it possible to avoid repeating the procedure from the authentication vector (RAND, AUTN, RES, CK’, IK’).

The implementation of the procedure for rapid renewal of authentication is indicated by the AAA server, during the initial authentication procedure, when it supplies the corresponding identifier.

The identity of the access network must not change during the procedure for rapid renewal of authentication. If this happens, the normal authentication procedure must be carried out.

The procedure for rapid renewal of the authentication is described in Figure 6.9.

Steps 1 to 3 are identical to those described for initial authentication in Figure 6.8. The private identity used by the mobile is the identifier for rapid renewal of authentication.

1. 4) The AAA server transmits to the trusted Wi-Fi access the EAP Request/EAP-Method AKA’ Reauthentication message containing a random number NOUNCE for the generation of a new PMK and a new identifier for the next authentication.

   This message is transmitted in a DER DIAMETER message and contains a MAC seal for the integrity check.

2. 5) Trusted Wi-Fi access transfers the EAP Response/EAP-Method AKA’ Reauthentication message to the mobile.
3. 6) The mobile checks the integrity of the received message and acknowledges it in the EAP Response/EAP-Method AKA’ Reauthentication message containing a MAC seal.
4. 7) Trusted Wi-Fi access transfers the EAP Response/EAP-Method AKA’ Reauthentication message to the AAA server in a DER DIAMETER message.

Steps 8 and 9 are identical to those described for initial authentication in Figure 6.8.

6.3.4. Application to the MIPv4 FA mechanism

The MIPv4 FA (Mobile IP version 4 Foreign Agent) mechanism is an alternative for building the S2a tunnel containing the mobile stream.

The MIPv4 FA mechanism defines the following three components:

• – the mobile node (MN) component integrated in the mobile;
• – the home agent (HA) component integrated in the PDN Gateway (PGW);
• – the foreign agent (FA) component integrated into an entity (e.g. a router) of the Wi-Fi access network, which is not necessarily the trusted Wi-Fi access.

During the mutual authentication procedure, the AAA server and the mobile also generate the extended master session key (EMSK) from the two keys CK’ and IK’.

Two keys, MN-HA and MN-FA, are generated from the EMSK to protect the MIPv4 messages exchanged between, on the one hand, the component MN and, on the other hand, the components HA and FA.

1. 1) The AAA server and the mobile derive the EMSK to generate the MIP-RK.
2. 2) The AAA server and the mobile derive the MIP-RK to generate the FA-RK. The AAA server transfers the FA-RK to the trusted Wi-Fi access.
3. 3) The AAA server and the mobile derive the key MIP-RK to generate the key MN-HA. The AAA server transfers the MN-HA key to the PGW entity.
4. 4) The mobile and the trusted Wi-Fi access derive the FA-RK to generate the MN-FA key. Trusted Wi-Fi access transfers the MN-FA key to the FA component.