Security Mechanisms of WLAN 3GPP IP Access

Both users with a SIM and users with a USIM may use WLAN 3GPP IP access. For the same reasons mentioned for direct IP access, we treat only the case of a successful USIM-based authentication for 3GPP IP access, which uses EAP-AKA. We also limit ourselves

to presenting the full authentication procedure as the fast re-authentication procedure is very similar.

USIM-Based Authentication for WLAN 3GPP IP Access

For WLAN 3GPP IP access, an IPsec tunnel is established between the UE and the PDG, spanning across the WLAN AN. Once established, the tunnel protects from any vulnerabilities in the AN, so that the strengths and weaknesses of WLAN security become irrelevant for WLAN 3GPP IP access. For protecting IP packets between the UE and the PDG, IPsec ESP [RFC4303] in tunnel mode is used. For setting up the corresponding security association, IKEv2 combined with EAP-AKA is used. The combined IKEv2 with EAP-AKA procedure using an EAP-AKA full authentication for 3GPP IP access can be seen in Figure 5.5.

PDG

Figure 5.5 USIM-based tunnel set-up, authentication and authorization for 3GPP IP access.

80 LTE Security

The role of the EAP server/backend authentication server is assumed by the 3GPP AAA server in conjunction with the HLR or HSS. The authenticator resides on the PDG.

The peer is again realized in the WLAN UE.

The numbering of the steps in Figure 5.5 is the same as that in Figure 7A of [TS33.234]

so as to make it easier for the reader to compare the text explaining the figure here with the somewhat more detailed text in [TS33.234].

1. The WLAN UE and the PDG exchange the first pair of messages, known as IKE_SA_INIT, in which the PDG and the WLAN UE negotiate cryptographic algorithms, exchange nonces and perform a Diffie–Hellman exchange.

2. The WLAN UE sends the user identity in the form required for EAP-AKA in this first message of an IKE_AUTH exchange. In accordance with [RFC5996], the WLAN UE omits the AUTH parameter in order to indicate to the PDG that it wants to use EAP over IKEv2.

3. The PDG sends an appropriate AAA message to the 3GPP AAA server, containing the user identity. The PDG includes a parameter indicating that the authentication is being performed for tunnel establishment. This will help the 3GPP AAA server to distinguish between authentications for direct IP access and authentications for 3GPP IP access. When Diameter is used, the messages between the PDG and the 3GPP AAA server are specified in [TS29.234], which in turn relies on the Diameter EAP application specified in [RFC4072].

4. The 3GPP AAA server fetches the user profile and authentication vectors from the HSS or HLR (if these parameters are not yet available in the 3GPP AAA server) and determines the EAP method (EAP-SIM or EAP-AKA) to be used.

5. The 3GPP AAA server initiates the authentication challenge by sending an EAP-Request/AKA-Challenge message, encapsulated in an AAA message, towards the PDG. The user identity is not requested again as the user identity received in step 3 could not have been modified or replaced by any intermediate node.

6. The PDG sends its identity, a certificate and an AUTH parameter to the WLAN UE. The PDG generates this AUTH parameter by computing a digital signature over parameters in the first message it sent to the WLAN UE (in step 1). The PDG also includes the EAP-Request/AKA-Challenge message received in step 5.

7. The WLAN UE verifies AUTH using the public key in the certificate received in step 6 and sends the EAP-Response/AKA-Challenge message towards the PDG.

8. The PDG forwards the EAP-Response/AKA-Challenge message to the 3GPP AAA server, encapsulated in an AAA message.

9. When all checks are successful, the 3GPP AAA server sends the EAP-Success, encap-sulated in an AAA message, which also contains the key MSK.

9a. The PDG sends an authorization request to the 3GPP AAA server.

9b. The 3GPP AAA server checks, based on the user’s subscription, if the user is autho-rized to establish the tunnel.

9c. The 3GPP AAA server sends the authorization answer to the PDG. The 3GPP AAA server includes the IMSI if it received only a pseudonym in step 9a. This provides the PDG with the means to identify the user by a permanent identity across all runs of this procedure with varying pseudonyms.

10. The PDG generates another two AUTH parameters by computing message authentication codes over parameters in the two messages exchanged in step 1 using the shared key MSK. Note that the PDG could defer the generation of these two AUTH parameters until receiving the message in step 12.

11. The PDG forwards an EAP-Success message to the WLAN UE over IKEv2.

12. The WLAN UE generates two AUTH parameters, using the locally derived MSK, in the same way as the PDG in step 10, and then sends the AUTH parameter protecting the first message from the UE to the PDG (sent in step 1).

13. The PDG verifies the AUTH parameter received in step 12 by comparing it with the corresponding value computed in step 10. The PDG then sends the other AUTH parameter computed in step 10 to the WLAN UE. The WLAN UE verifies the received AUTH parameter by comparing it with the corresponding value computed in step 12.