6 WLAN UE to 3GPP network protocols

24.2343GPP3GPP system to Wireless Local Area Network (WLAN) interworkingRelease 12Stage 3TSWLAN User Equipment (WLAN UE) to network protocols

6.1 WLAN UE to 3GPP AAA server protocols

6.1.1 WLAN access authentication and authorization protocols

6.1.1.1 General

6.1.1.1.1 Non-emergency case

WLAN authentication signalling shall be executed between WLAN UE and 3GPP AAA server for the purpose of authenticating the end-user and enabling the access to the WLAN or to the WLAN and the 3GPP network.

WLAN authentication signalling for 3GPP – WLAN interworking shall be based on extensible authentication protocol (EAP) as specified in IETF RFC 3748 [6]).

The WLAN UE and the 3GPP AAA server shall support EAP authentication procedures as specified in IETF RFC 4187 [9] and IETF RFC 4186 [10].

Other EAP authentication methods than those specified in IETF RFC 4187 [9] and IETF RFC 4186 [10] may also be supported by the WLAN UE, but are not part of 3GPP – WLAN interworking; therefore these other EAP authentication methods are out of the scope of the present document.

WLAN access authorization shall be performed upon successful user authentication in the 3GPP AAA server and it includes access rules as defined by the operator (see subclause 6.1.1.3.6).

6.1.1.1.2 WLAN access authentication and authorization in the emergency case

For the case of access for the purpose of using I-WLAN as the access network for IMS emergency calls the WLAN UE and the 3GPP AAA server shall support extensible authentication protocol (EAP) as specified in IETF RFC 3748 [6]. Two different cases can be identified:

a) The WLAN UE is equipped with a valid SIM or valid USIM: The requirements as specified in subclause 6.1.1.1.1 shall apply with the following modification:

WLAN access authorization shall not be performed.

b) The WLAN UE is not equipped with a valid SIM or valid USIM: The WLAN UE and the 3GPP AAA server shall use EAP-TLS based authentication as specified in IETF RFC 5216 [16A] in which client authentication is omitted (see 3GPP TS 33.234 [5]).

6.1.1.2 WLAN UE procedures

6.1.1.2.1 Identity management

In both EAP AKA and EAP SIM based authentications, the WLAN UE shall proceed as follows.

The WLAN UE shall always use the leading digits notation when building the username part of NAI from IMSI, as specified in 3GPP TS 23.003 [1A]. IETF RFC 4187 [9] and IETF RFC 4186 [10] each define the leading digits to identify their particular authentication mechanism.

In the first EAP-Response/Identity message the WLAN UE shall include a NAI which username is derived from IMSI. The format of such username is defined in 3GPP TS 23.003 [1A]. The WLAN UE shall include the root NAI or decorated NAI for authentication purposes. The WLAN UE shall include the alternative NAI for manual network selection procedure.

The WLAN UE shall support the mechanism for communicating its identity to the server using EAP/AKA and EAP/SIM messages as specified in EAP AKA and EAP SIM respectively.

If the WLAN UE receives an EAP-Request/AKA-Identity message or EAP-Request/SIM/Start message including an AT_PERMANENT_ID_REQ attribute after sending an identity response including the pseudonym, the WLAN UE shall respond to this new identification request by including a NAI in which username is derived from IMSI. This WLAN UE behaviour is defined in IETF RFC 4186 [10] and in IETF RFC 4187 [9].

6.1.1.2.2 User identity privacy

In both EAP AKA and EAP SIM based authentications, the support of user identity privacy is mandatory for the WLAN UE.

The reception of temporary identity(ies) (pseudonym and/or re-authentication identity) in any EAP authentication indicates to the WLAN UE that user identity privacy is enabled as described in subclause 6.1.1.3.2.

The WLAN UE shall not interpret the temporary identity(ies), but store the received identity(ies) and use it at the next EAP authentication.

If the WLAN UE receives temporary identity(ies) (pseudonym and/or re-authentication identity) during EAP authentication from the 3GPP AAA server (as specified in 3GPP TS 33.234 [5]), then the WLAN UE shall process the authentication challenge information (e.g. RAND, AUTN, MAC) received together with the temporary identity(ies). If the EAP authentication procedure is successful (i.e. EAP–Success message), the WLAN UE shall consider the new temporary identity(ies) as valid.

The WLAN UE after successful EAP authentication takes the following actions if new temporary identity(ies) was received in AT_ENCR_DATA attribute:

– if the temporary identity is a pseudonym, the WLAN UE shall store it in the "Pseudonym" data file in the USIM. If the "Pseudonym" data file is not available in the USIM, the WLAN UE shall store the pseudonym in the ME; and

– if the temporary identity is a re-authentication identity, the WLAN UE shall store it in the "Re-authentication identity", data file in the USIM together with new master key, transient EAP keys and counter value. If the "Re-authentication identity" data file is not available in the USIM, the WLAN UE shall store the re-authentication identity in the ME together with new master key, transient EAP keys and counter value.

The WLAN UE after successful EAP authentication takes the following actions if no new temporary identity(ies) was received in AT_ENCR_DATA attribute:

– Temporary identities are one-time identities. If the WLAN UE does not receive a new temporary identity(ies), the WLAN UE shall delete the corresponding temporary identity(ies) from the USIM/ME (i.e. the WLAN UE shall set the username of the corresponding temporary identity(ies) field to the "deleted" value to indicate no valid temporary identity(ies) exists as specified in 3GPP TS 23.003 [1A]). When the temporary identity(ies) stored in the USIM/ME indicates the "deleted" value in the username part, the WLAN UE shall consider the corresponding temporary identity(ies) as invalid and shall not send that temporary identity(ies) at the next EAP authentication.

Upon reception of an EAP-Request/Identity message, the WLAN UE shall take one of the following actions depending on the presence of the temporary identity(ies):

– if valid re-authentication identity is available, the WLAN UE shall use the re-authentication identity at the next EAP authentication. If not, then

– if valid pseudonym is available, the WLAN UE shall use the pseudonym at the next EAP authentication. If not, then

– The WLAN UE shall use the permanent IMSI-based identity at the next EAP authentication.

6.1.1.2.3 EAP AKA based authentication

The WLAN UE with USIM inserted shall support EAP AKA based authentication, and it shall attempt to authenticate using EAP AKA authentication as the first EAP method. The WLAN UE shall be able to accept EAP AKA based authentication in the EAP method negotiation.

6.1.1.2.4 EAP SIM based authentication

If the WLAN UE supports the ME-SIM interface, and if SIM has been inserted, then the WLAN UE shall support EAP SIM based authentication. In this case, the WLAN UE shall be able to accept EAP SIM based authentication as EAP method negotiation.

The EAP SIM based authentication does not require the ME-SIM interface, and therefore EAP SIM based authentication could also be performed using the 2G authentication and key agreement (AKA) functions on the USIM application. However, if a UICC with USIM has been inserted, then the default EAP method policy of the WLAN UE shall not accept EAP SIM based authentication.

6.1.1.2.4.1 Interoperability cases

If the WLAN UE does not accept EAP SIM based authentication when USIM has been inserted, then interoperability problems may occur with pre-release 6 AAA servers that only support EAP SIM based authentication. Therefore, ME implementations may allow configuring an EAP method policy that allows EAP SIM based authentication even if a UICC with USIM has been inserted.

6.1.1.2.5 Re-authentication

In both EAP AKA and EAP SIM based authentication, the support of re-authentication is mandatory for the WLAN UE.

The reception of re-authentication identity in any EAP authentication indicates to the WLAN UE that fast re‑authentication is enabled as described in subclause 6.1.1.3.5.

If the WLAN UE receives a re-authentication identity from the 3GPP AAA server (as specified in 3GPP TS 33.234 [5]), then the WLAN UE shall process the authentication challenge information (e.g. Counter, NONCE, MAC) received together with the re-authentication identity. If the authentication challenge procedure is successful, the WLAN UE shall consider the new re-authentication identity as valid.

The WLAN UE after successful EAP authentication shall store the new re-authentication identity and associated security parameters and overwrite any previously stored re-authentication identity and associated security parameters as described in subclause 6.1.1.2.2.

The WLAN UE shall send the re-authentication identity during the re-authentication attempt to the 3GPP AAA Server, only if re-authentication identity, whose value is not set to "deleted", exists.

6.1.1.2.6 Protected result indications

The WLAN UE shall support protected result indications (i.e. MAC protected) for both EAP AKA and EAP SIM as specified in 3GPP TS 33.234 [5].

The reception of the result indication (i.e. AT_RESULT_IND attribute) at any EAP authentication indicates to the WLAN UE that the 3GPP AAA server requests to use protected success result indications.

If the WLAN UE receives a result indication in the EAP-Request/AKA-Challenge or EAP-Request/SIM-Challenge message during the EAP authentication, the WLAN UE shall process the challenge information. Then, the WLAN UE takes the following actions depending on the result of the EAP authentication procedure:

– if the EAP authentication is successful, the WLAN UE shall include the result indication along with the authentication response (e.g. MAC and RES) in the EAP-Response/AKA-Challenge or EAP-Response/SIM-Challenge message. Then, if the EAP authentication is also successful on the 3GPP AAA server side, the WLAN UE receives an EAP-Request/AKA-Notification or EAP-Request/SIM-Notification message, which contains a success notification and is MAC protected, prior the EAP-Success message.

– if the EAP authentication is unsuccessful, the WLAN UE shall send an EAP-Response/AKA-Client-Error or EAP-Response/SIM-Client-Error message. Then, the WLAN UE shall wait for the reception of the EAP Failure message to conclude the EAP authentication procedure.

Upon receipt of an EAP-Request/AKA-Notification or EAP-Request/SIM-Notification message, the WLAN UE shall acknowledge it by sending an EAP-Reponse/AKA-Notification or EAP-Response/SIM-Notification message. Then, the WLAN UE shall wait for the reception of the EAP-Success or EAP-Failure message to conclude the EAP authentication procedure.

NOTE 1: The EAP-Request/AKA-Notification or EAP-Request/SIM-Notification message contains an indication of whether the EAP authentication procedure is successful or unsuccessful as specified in IETF RFC 4187 [9] and IETF RFC 4186 [10].

NOTE 2: The EAP AKA and EAP SIM signalling flows are described in 3GPP TS 33.234 [5].

6.1.1.2.7 UE procedures in the emergency case

For the purpose of using I-WLAN as the access network for IMS emergency calls two different cases can be identified:

a) The WLAN UE is equipped with a valid SIM or valid USIM: The requirements as specified in subclauses 6.1.1.2.1, 6.1.1.2.2, 6.1.1.2.3, 6.1.1.2.4, 6.1.1.2.5 and 6.1.1.2.6 shall apply with the following modification:

On building the NAI in the first EAP-Response/Identity message, the WLAN UE shall use the emergency realm, if it is available, for a selected PLMN (see 3GPP TS 23.003 [1A]).

b) The WLAN UE is not equipped with a valid SIM or valid USIM: The WLAN UE shall support protected result indications (i.e. MAC protected) for extensible authentication protocol (EAP) as specified in IETF RFC 3748 [6] (see subclause  6.1.1.2.6).

The WLAN UE shall include in the first EAP-Response/Identity message an emergency NAI.

If the WLAN UE receives an EAP-Request/TLS message, the WLAN UE shall respond with an EAP-Response/TLS message (see IETF RFC 5216 [16A]).

NOTE: The EAP-TLS signalling flow for a WLAN UE not equipped with a valid SIM or valid USIM is described in 3GPP TS 33.234 [5].

6.1.1.3 3GPP AAA server procedures

6.1.1.3.1 Identity management

In both EAP AKA and EAP SIM based authentications, the 3GPP AAA server shall proceed as follows.

The 3GPP AAA server shall always (re)request the user identity, using EAP-Request/AKA-Identity or EAP-Request/SIM/Start, in order to ensure that it has an unmodified copy of the identity, regardless of the identity the 3GPP AAA server received in EAP-Response/Identity (see IETF RFC 4187 [9] and IETF RFC 4186 [10] for details on this requirement).

The 3GPP AAA Server shall use, if present, the leading digits part of IMSI based username to identify the proposed authentication mechanism, as specified in 3GPP TS 23.003 [1A].

6.1.1.3.2 User identity privacy

In both EAP AKA and EAP SIM based authentications, the support of user identity privacy is mandatory for the 3GPP AAA server. However, the usage of this feature is optional for the 3GPP AAA server.

The user identity privacy should be enabled in the 3GPP AAA server. If user identity privacy is enabled, the 3GPP AAA server shall send new encrypted temporary identity(ies) (pseudonym and/ or re-authentication identity) to the WLAN UE in every EAP authentication procedure. The description of temporary identity management is specified in 3GPP TS 33.234 [5].

When mapping a user temporary identity (pseudonym or re-authentication identity) to a permanent IMSI-based identity, the 3GPP AAA server shall only examine the username portion of the user temporary identity and ignore the realm portion of the identity.

NOTE: The realm portion of the temporary identity will always be the realm indicated by the 3GPP AAA server (see 3GPP TS 23.003 [1A]).

6.1.1.3.3 EAP SIM and EAP AKA based authentication

The 3GPP AAA server shall support both EAP SIM and EAP AKA based authentication as specified in IETF RFC 4187 [9] and IETF RFC 4186 [10].

6.1.1.3.4 3GPP AAA server operation in the beginning of authentication

The 3GPP AAA server shall support EAP method negotiation, as specified in EAP IETF RFC 3748 [6].

The EAP method policy of the 3GPP AAA server shall not accept EAP-SIM based authentication for USIM subscribers, and only accept EAP-SIM based authentication for SIM subscribers.

The procedure to select the EAP method to use for authentication is the following:

1) The format of the identity received in EAP-Response/Identity message may contain an indication of the EAP method to be used by the 3GPP AAA server as defined in 3GPP TS 23.003 [1A]. For example, if the identity format indicates EAP SIM, the leading character in the identity is "1" so, the identity might be a permanent IMSI-based identity for EAP SIM. The permanent identity format and the usage of leading digits for IMSI-based permanent identity are specified in IETF RFC 4187 [9] and IETF RFC 4186 [10]. The format of the pseudonyms and re-authentication identities are specified in 3GPP TS 33.234 [5].

2) If the 3GPP AAA server is not able to map the user identity received in EAP-Response/Identity message to a subscriber identity (e.g. an obsolete pseudonym), but it recognizes the EAP method, the 3GPP AAA server shall request a new identity using the EAP method indicated by the WLAN UE.

3) If the 3GPP AAA server is able to map the user identity received in EAP-Response/Identity message to a subscriber identity (IMSI), but the EAP method does not match with user’s subscription information, the 3GPP AAA server shall use the EAP method indicated by user’s subscription (with the exception specified in the subclause 6.1.1.3.4.1). For example, if the EAP method indicates EAP AKA, but the 3GPP AAA server has available information that subscriber’s UICC only supports SIM based authentication, (e.g. received authentication vectors are triplets rather than quintuplets), then user’s subscription shall prevail and the 3GPP AAA server shall propose EAP SIM as the first authentication method.

4) If the 3GPP AAA server is not able to recognize the user identity received in EAP-Response/Identity message and hence the EAP method, the EAP method to use is implementation dependent. If this EAP method does not match user’s subscription in the WLAN UE, the WLAN UE shall respond with a Nak to the 3GPP AAA server. Then, the 3GPP AAA server shall use the other EAP method until a recognized identity is received.

6.1.1.3.4.1 Interoperability cases

3GPP AAA servers may be configured to support an EAP method policy that accepts EAP-SIM based authentication for USIM subscribers. This configuration option may be used, if many USIM subscribers are expected to use pre-release 6 ME implementations that do not support EAP AKA.

NOTE: When the operator issues USIM cards to subscribers, it is strongly recommended to upgrade the AAA servers to 3GPP release 6 and to support EAP-AKA.

6.1.1.3.5 Re-authentication

The 3GPP AAA server shall support re-authentication as specified in the 3GPP TS 33.234 [5].

Re-authentication should be enabled in the 3GPP AAA server. If re-authentication is enabled, the re-authentication may be full or fast, as follows:

– Full re-authentication means that a new full authentication procedure shall take place as the initial authentication procedure, where all keys are generated afresh in both the (U)SIM and network. Full re-authentication requires that the WLAN UE sends pseudonym or permanent IMSI-based identity.

– Fast re-authentication means that a new authentication procedure takes place in which Master Key and Transient EAP Keys are not generated in both the (U)SIM and network, but reused from the previous authentication process to generate the remaining keys necessary for this procedure. Fast re-authentication requires that the WLAN UE sends re-authentication identity.

The decision of using fast re-authentication is taken in the 3GPP AAA server depending on operator’s policies. Operator’s policies regarding fast re-authentication may contain for example, a timer to control start of fast re‑authentication, a counter to control the maximum number of allowed fast re-authentications before a full EAP authentication shall be initiated towards the WLAN UE or a restriction on whether fast re-authentication is allowed to visiting subscribers.

The 3GPP AAA server indicates to the WLAN UE the decision of using fast re-authentication by means of sending the re-authentication identity in the EAP authentication procedure (i.e. in EAP-Request/AKA/Challenge or EAP‑Request/AKA-re-authentication or EAP-Request/SIM/Challenge or EAP-Request/SIM/re-authentication messages). On each fast re-authentication procedure the 3GPP AAA server has the ultimate point of decision of whether to continue with the ongoing fast re-authentication procedure or to defer to a full re-authentication. Therefore, whenever the 3GPP AAA server sends a re-authentication identity to the WLAN UE, the 3GPP AAA server shall also include a pseudonym when allowed by the IETF RFC 4186 [10] and IETF RFC 4187 [9]. In this way, the WLAN UE retains a pseudonym if the 3GPP AAA server defers to full authentication.

NOTE 1: The use of fast re-authentication implies to save power consumption in the WLAN UE and processing time in both the WLAN UE and the 3GPP AAA server. However, when the fast re-authentication is used through a low trusted I-WLAN, it is strongly recommended to refresh the keys using full re‑authentication. The use of fast re-authentication should be left for situations in which the user is accessing a high trusted I-WLAN.

The full and fast re-authentication signalling flows are described in 3GPP TS 33.234 [5].

6.1.1.3.6 WLAN access authorization

WLAN access authorization between the WLAN UE and the 3GPP AAA server shall be combined with the WLAN access authentication and performed before service authorization and transport IP address allocation.

The 3GPP AAA server shall perform access authorization once user authentication succeeds but before sending EAP‑Success message to the WLAN UE.

The 3GPP AAA server shall check whether the user is allowed to use WLAN service based on the user’s subscription and optionally, information about the I-WLAN (e.g. I-WLAN operator name, location and throughput). If the check is successful the 3GPP AAA server shall complete the authentication procedure by sending a positive response to the WLAN UE that is, an EAP-Success message.

Additionally, the 3GPP AAA server may apply certain access control rules (such as access scope limitation, time limitation, bandwidth control values, and/or user priority) based on user’s subscription, the account status, O&M rules (e.g. blacklist, access limitation list), and local agreements or information about the I-WLAN.

6.1.1.3.7 Protected result indications

The 3GPP AAA server should support protected result indications (i.e. MAC protected) for both EAP AKA and EAP SIM as specified in 3GPP TS 33.234 [5]. If the 3GPP AAA server supports protected result indications, the usage of this feature is optional and depends on operator’s policies.

If the 3GPP AAA server wishes to protect the success result of the EAP authentication, the 3GPP AAA server shall send the result indication (i.e. AT_RESULT_IND attribute) to the WLAN UE along with authentication challenge information (e.g. RAND, AUTN, MAC) and possibly temporary identity(ies) in the EAP-Request/AKA-Challenge or EAP-Request/SIM-Challenge message.

Upon receipt of the EAP-Response/AKA-Challenge or EAP-Response/SIM-Challenge message, the 3GPP AAA server checks the validity of the response. Then, the 3GPP AAA server takes the following actions depending on the result of the EAP authentication procedure:

– if the EAP authentication is successful and the 3GPP AAA server has previously requested to use protected success result indications, the 3GPP AAA server shall send the EAP-Request/AKA-Notification or EAP-Request/SIM-Notification message, which contains the success notification (i.e. AT_NOTIFICATION code 32768 as specified in IETF RFC 4187 [9] and IETF RFC 4186 [10]) and is MAC protected, prior the EAP-Success message.

– if the EAP authentication is unsuccessful, the 3GPP AAA server shall send the EAP-Request/AKA-Notification or EAP-Request/SIM-Notification message, which contains the failure notification (i.e. AT_NOTIFICATION with a code range from 0 to 32767 as specified in IETF RFC 4187 [9] and IETF RFC 4186 [10]) and is MAC protected, prior the EAP-Failure message.

NOTE 1: Prior the EAP authentication challenge round takes place (as specified in IETF RFC 4187 [9] subclause 4.3 and IETF RFC 4186 [10] subclause 6.10) the 3GPP AAA server may send an EAP-Request/AKA-Notification or EAP-Request/SIM-Notification message, which contains the failure notification (i.e. AT_NOTIFICATION with the Phase bit (P bit) set to 1 as specified in IETF RFC 4187 [9] and IETF RFC 4186 [10]) and is not MAC protected.

Upon receipt of the EAP-Response/AKA-Notification or EAP-Response/SIM-Notification message, the 3GPP AAA server shall send the EAP-Success or EAP-Failure message to conclude the EAP authentication procedure.

The 3GPP AAA server shall ignore the contents of the EAP-Response/AKA-Notification or EAP-Response/SIM-Notification message as an acknowledgement of a protected success result indication.

If the EAP authentication procedure is successful and the 3GPP AAA server has not requested to use protected success result indications (i.e. the AT_RESULT_IND attribute was not included in the EAP-Request/AKA-Challenge or EAP-Request/SIM-Challenge message), the 3GPP AAA server shall send an EAP-Success message to conclude the EAP authentication (i.e. the EAP-Request/AKA-Notification or EAP-Request/SIM-Notification message is not sent to the WLAN UE prior the EAP-Success).

Upon receipt of the EAP-Response/AKA-Client-Error or EAP-Response/SIM-Client-Error message, the 3GPP AAA server shall send the EAP-Failure message to conclude the EAP authentication procedure.

NOTE 2: The EAP AKA and EAP SIM signalling flows are described in 3GPP TS 33.234 [5].

6.1.1.3.8 3GPP AAA server procedures in the emergency case

For the case of using I-WLAN as the access network for IMS emergency calls two different cases can be identified:

a) The WLAN UE is equipped with a valid SIM or valid USIM: The requirements as specified in subclauses 6.1.1.3.1, 6.1.1.3.2, 6.1.1.3.3, 6.1.1.3.4, 6.1.1.3.5 and 6.1.1.3.7 shall apply.

NOTE 1: WLAN access authorization is not performed.

b) The WLAN UE is not equipped with a valid SIM or valid USIM: The 3GPP AAA server should support protected result indications (i.e. MAC protected) for extensible authentication protocol (EAP) as specified in IETF RFC 3748 [6]. If the 3GPP AAA server supports protected result indications, the usage of this feature is optional and depends on operator’s policies (see subclause 6.1.1.3.7).

If the user identity received in an EAP-Response/Identity message indicates the emergency NAI, the 3GPP AAA server shall send an EAP-Request/TLS message in order to initiate EAP-TLS based authentication (see 3GPP TS 29.234 [3]).

NOTE 2: The EAP-TLS signalling flow for a WLAN UE not equipped with a valid SIM or valid USIM is described in 3GPP TS 33.234 [5].

NOTE 3: The format of the NAI received in the EAP-Response/Identity message indicates whether the WLAN UE is using I-WLAN as the access network for IMS emergency calls and whether the WLAN UE accessing the network with IMSI or not as described in 3GPP TS 23.003 [1A], and 3GPP TS 29.234 [3].