4.7.7 Authentication and ciphering procedure

24.0083GPPCore network protocolsMobile radio interface Layer 3 specificationRelease 18Stage 3TS

4.7.7a Authentication and ciphering procedure used for UMTS authentication challenge.

The purpose of the authentication and ciphering procedure is fivefold (see 3GPP TS 33.102 [5a] and 3GPP TS 43.020 [13]):

– to permit the network to check whether the identity provided by the MS is acceptable or not;

– to provide parameters enabling the MS to calculate a new GPRS UMTS ciphering key and a new GPRS UMTS integrity key;

– to let the network set the GSM ciphering mode (ciphering /no ciphering) and GSM ciphering algorithm;

– to permit the mobile station to authenticate the network; and

– to let the network set GSM integrity protection and GSM integrity algorithm (for control plane and optionally for user plane).

In Iu mode, and in the case of a UMTS authentication challenge, the authentication and ciphering procedure can be used for authentication only.

The cases in which the authentication and ciphering procedure shall be used are defined in 3GPP TS 33.102 [5a], 3GPP TS 43.020 [13] and 3GPP TS 42.009 [5].

The authentication and ciphering procedure is always initiated and controlled by the network. However, in the case of a UMTS authentication challenge, there is the possibility for the MS to reject the network.

The MS shall support the UMTS authentication challenge, if a USIM is inserted.

The authentication and ciphering procedure can be used for any combination of the following:

– authentication;

– setting of the GSM ciphering mode and the GSM ciphering algorithm; and

– setting of GSM integrity protection and the GSM integrity algorithm (for control plane and optionally for user plane).

NOTE: Setting of GSM integrity protection and the GSM integrity algorithm in the authentication and ciphering procedure is only applicable for an MS and a network supporting integrity protection in A/Gb mode.

In A/Gb mode, the network should not send any user data during the authentication and ciphering procedure.

A UMTS security context is established in the MS and the network when a UMTS authentication challenge is performed in A/Gb mode or in Iu mode. After a successful UMTS authentication, the GPRS UMTS ciphering key, the GPRS UMTS integrity key, the GPRS GSM ciphering key and the GPRS ciphering key sequence number, are stored both in the network and the MS. Furthermore, in A/Gb mode both the ME and the network may derive and store a GPRS GSM Kc128 as part of the UMTS security context as described in the subclause 4.7.7.3a. Furthermore, in A/Gb mode, if integrity protection is used, both the MS and the network shall derive and store a GPRS GSM Kint as part of the UMTS security context as described in the subclause 4.7.7.3b.

4.7.7b Authentication and ciphering procedure used for GSM authentication challenge

The purpose of the authentication and ciphering procedure is threefold (see 3GPP TS 43.020 [13]):

– to permit the network to check whether the identity provided by the MS is acceptable or not;

– to provide parameters enabling the MS to calculate a new GPRS GSM ciphering key; and

– to let the network set the GSM ciphering mode (ciphering/no ciphering) and GSM ciphering algorithm.

The authentication and ciphering procedure can be used for either:

– authentication only;

– setting of the GSM ciphering mode and the GSM ciphering algorithm only; or

– authentication and the setting of the GSM ciphering mode and the GSM ciphering algorithm.

The cases in which the authentication and ciphering procedure shall be used are defined in 3GPP TS 42.009 [5].

In A/Gb mode, the authentication and ciphering procedure is always initiated and controlled by the network. It shall be performed in a non ciphered mode because of the following reasons:

– the network cannot decipher a ciphered AUTHENTICATION_AND_CIPHERING RESPONSE from an unauthorised MS and put it on the prohibited list; and

– to be able to define a specific point in time from which on a new GPRS GSM ciphering key should be used instead of the old one.

GSM authentication challenge shall be supported by a ME supporting GERAN or UTRAN.

In A/Gb mode, the network should not send any user data during the authentication and ciphering procedure.

A GSM security context is established in the MS and the network when a GSM authentication challenge is performed in A/Gb mode or in Iu mode. However, in Iu mode the MS shall not accept a GSM authentication challenge, if a USIM is inserted. After a successful GSM authentication challenge, the GPRS GSM ciphering key and the GPRS ciphering key sequence number, are stored both in the network and the MS.

4.7.7c Change of the ciphering algorithm at PS Handover

For PS handover to A/Gb mode (see subclause 10.5.1.14 and 3GPP TS 44.060 [76]) the network shall either assign a GSM ciphering algorithm to be used in the target cell or deactivate ciphering in the target cell. The MS shall start to use the new GSM ciphering algorithm or deactivate ciphering upon an indication from the lower layers that the PS handover procedure has been successfully completed (see 3GPP TS 44.060 [76])

After PS handover to Iu mode (see 3GPP TS 25.331 [23c] and 3GPP TS 44.118 [111]) the network shall activate integrity protection and shall either assign a ciphering algorithm to be used in the target cell or deactivate ciphering in the target cell, using the security mode control procedure (3GPP TS 25.331 [23c] and 3GPP TS 44.118 [111]).

If the GSM ciphering algorithm is changed at PS handover and the routing area updating procedure triggered by the PS handover procedure is not accepted by the network, the MS shall delete any GPRS ciphering key sequence number and proceed as specified in subclauses 4.7.5.1.4 and 4.7.5.2.4. If the routing area updating procedure fails, because the radio resources assigned in the new cell are released before the MS receives a ROUTING AREA UPDATE ACCEPT message, the MS shall delete any GPRS ciphering key sequence number and proceed as specified in subclauses 4.7.5.1.5 item b and 4.7.5.2.5, respectively.

4.7.7.1 Authentication and ciphering initiation by the network

The network initiates the authentication and ciphering procedure by transferring an AUTHENTICATION_AND_CIPHERING REQUEST message across the radio interface and starts timer T3360. The AUTHENTICATION_AND_CIPHERING REQUEST message shall contain all parameters necessary to calculate the response parameters when authentication is performed (see 3GPP TS 43.020 [13] and 3GPP TS 33.102 [5a]).

If authentication is requested, then the AUTHENTICATION_AND_CIPHERING REQUEST message shall contain either:

– In a GSM authentication challenge, the GPRS ciphering key sequence number and the RAND, or

– In a UMTS authentication challenge, the GPRS ciphering key sequence number, the RAND and the AUTN.

In A/Gb mode, if authentication is not requested, then the AUTHENTICATION_AND_CIPHERING REQUEST message shall not contain neither the GPRS ciphering key sequence number, the RAND nor the AUTN.

In A/Gb mode, if ciphering is requested, in a GSM authentication challenge or in a UMTS authentication challenge, then the AUTHENTICATION_AND_CIPHERING REQUEST message shall indicate the GPRS GSM ciphering algorithm.

In A/Gb mode, an MS supporting integrity protection shall ignore a GSM authentication challenge from the network.

In A/Gb mode, in a UMTS authentication challenge, if the MS has indicated support for integrity protection in MS network capability IE included in the ATTACH REQUEST or ROUTING AREA UPDATE REQUEST message to the network, then if the network supports integrity protection then the network shall activate integrity protection in the MS (see subclause 4.7.3.1.3 and subclause 4.7.5.1.3). If the network does not activate integrity protection in the MS, then the MS shall detach from the network.

In A/Gb mode, if no UMTS security context is available in the network or if no common UMTS security context is available in the MS and the network, and if the MS has indicated support for integrity protection in MS network capability IE to the network, then an authentication and activation of integrity protection and setting of ciphering mode (enabled or disabled), shall take place in the same authentication and ciphering procedure. The network shall replay the MS network capability IE and the MS radio access capability IE received from the MS in the latest ATTACH REQUEST message or the latest ROUTING AREA UPDATE REQUEST message, by including the MS network capability IE and the MS radio access capability IE in the AUTHENTICATION AND CIPHERING REQUEST message to the MS. The network shall select one of the GPRS GSM integrity algorithms indicated in the MS network capability IE received from the MS in the latest ATTACH REQUEST message or ROUTING AREA UPDATE REQUEST message. The selected GPRS GSM integrity algorithm shall be included in the AUTHENTICATION AND CIPHERING REQUEST message. The network shall enable or disable ciphering and include the selected GPRS GSM ciphering algorithm if ciphering is enabled. If ciphering is enabled, then the network shall select one of the GPRS GSM ciphering algorithm indicated in the MS network capability IE received from the MS in the latest ATTACH REQUEST message or ROUTING AREA UPDATE REQUEST message.The network shall calculate a message authentication code for the AUTHENTICATION AND CIPHERING REQUEST message at the GMM layer with the new integrity key, GPRS GSM Kint key, indicated by the GPRS ciphering key sequence number included in the AUTHENTICATION AND CIPHERING REQUEST message. The new GPRS GSM Kint shall be calculated from the new UMTS security context established in the same procedure as described in the subclause 4.7.7.3b. The AUTHENTICATION AND CIPHERING REQUEST message shall include the calculated message authentication code for integrity protection.

In A/Gb mode, if an established UMTS security context is available in the network and if the MS has indicated support for integrity protection in the MS network capability IE, when authentication takes place in the authentication and ciphering procedure (regardless whether a change of the integrity algorithm, ciphering algorithm or a change of ciphering mode takes place in the same procedure), then the network shall replay the MS network capability IE and the MS Radio Access Capability IE received from the MS in the latest ATTACH REQUEST message or the latest ROUTING AREA UPDATE REQUEST message, by including the MS network capability IE and the MS Radio Access Capability IE into the AUTHENTICATION AND CIPHERING REQUEST message to the MS. If a change of the GPRS GSM integrity algorithm takes place in the same procedure, then the network shall select one of the GPRS GSMintegrity algorithms indicated in the MS network capability IE received from the MS in the latest ATTACH REQUEST message or ROUTING AREA UPDATE REQUEST message. The selected GPRS GSM integrity algorithm shall be included into the AUTHENTICATION AND CIPHERING REQUEST message. If the network decides to change the ciphering mode or the ciphering algorithm or both, then if ciphering is enabled the network shall select one of the GPRS GSM ciphering algorithms indicated in the MS network capability IE received from the MS in the latest ATTACH REQUEST message or ROUTING AREA UPDATE REQUEST message. The network shall also include the ciphering mode or the selected GPRS GSM ciphering algorithm or both, if ciphering is enabled (Ciphering algorithm IE) in the AUTHENTICATION AND CIPHERING REQUEST message. The network calculates a message authentication code over the parameters included in the AUTHENTICATION AND CIPHERING REQUEST message at the GMM layer with the new integrity key GPRS GSM Kint indicated by the GPRS ciphering key sequence number included by the AUTHENTICATION AND CIPHERING REQUEST message. The new GPRS GSM Kint shall be calculated from the new UMTS security context established in the same procedure as described in the subclause 4.7.7.3b. The AUTHENTICATION AND CIPHERING REQUEST message shall include the calculated message authentication code for integrity protection.

In A/Gb mode, if an established UMTS security context context is available in the network and if the MS has indicated support for integrity protection in the MS network capability IE to the network, and if integrity protection is in use, then if only a change of the integrity algorithm or ciphering algorithm or both, or a change of the ciphering mode, is requested in the authentication and ciphering procedure, then the AUTHENTICATION AND CIPHERING REQUEST message shall include the new GPRS GSM integrity algorithm or the new setting of the ciphering mode and the new GPRS GSM ciphering algorithm; that shall be taken into use.

NOTE: The AUTHENTICATION AND CIPHERING REQUEST message is protected by a message authentication code in the LLC layer when no authentication takes place in the authentication and ciphering procedure.Therefore, no message authentication code shall be calculated and included by the GMM layer into this message when only an algorithm change takes place. In addition, there is no need to replay the MS network capability IE and the MS Radio Access Capability IE in the AUTHENTICATION AND CIPHERING REQUEST message when no authentication takes place as a valid UMTS security context is already established between the MS and network.

The network includes the A&C reference number information element in the AUTHENTICATION AND CIPHERING REQUEST message. Its value is chosen in order to link an AUTHENTICATION AND CIPHERING REQUEST in a RA with its RESPONSE. The A&C reference number value might be based on the RA Colour Code value.

Additionally, the network may request the MS to include its IMEISV in the AUTHENTICATION AND CIPHERING RESPONSE message.

4.7.7.2 Authentication and ciphering response by the MS

In A/Gb mode, an MS shall be ready to respond upon an AUTHENTICATION_AND_CIPHERING REQUEST message at any time.

In UMTS, an MS shall be ready to respond upon an AUTHENTICATION_AND_CIPHERING REQUEST message at any time whilst a PS signalling connection exists.

If a SIM is inserted in the MS, the MS shall ignore the Authentication Parameter AUTN IE if included in the AUTHENTICATION_AND_CIPHERING REQUEST message and perform the GSM authentication challenge. It shall not perform the authentication of the network described in subclause 4.7.7.5.1.

In a GSM authentication challenge, if the AUTHENTICATION_AND_CIPHERING REQUEST message includes the authentication parameters RAND and GPRS CKSN, then upon receipt of the message, the MS processes the challenge information and sends an AUTHENTICATION_AND_CIPHERING RESPONSE message to the network. The value of the received A&C reference number information element shall be copied into the A&C reference number information element in the AUTHENTICATION_AND_CIPHERING RESPONSE message. A GSM authentication challenge will result in the SIM/USIM passing a SRES and a GPRS GSM ciphering key to the ME. The new GPRS GSM ciphering key calculated from the challenge information shall overwrite the previous one and any previously stored GPRS UMTS ciphering and GPRS UMTS integrity keys shall be deleted. The calculated GSM ciphering key shall be stored on the SIM/USIM together with the GPRS ciphering key sequence number before the AUTHENTICATION_AND_CIPHERING RESPONSE message is transmitted.

In a UMTS authentication challenge, if the AUTHENTICATION_AND_CIPHERING REQUEST message includes the UMTS authentication parameters GPRS CKSN, RAND and AUTN, then upon receipt of the message, the MS verifies the AUTN parameter and if this is accepted, the MS processes the challenge information and sends an AUTHENTICATION_AND_CIPHERING RESPONSE message to the network. The value of the received A&C reference number information element shall be copied into the A&C reference number information element in the AUTHENTICATION_AND_CIPHERING RESPONSE message. A UMTS authentication challenge will result in the USIM passing a RES, a GPRS UMTS ciphering key, a GPRS UMTS integrity key and a GPRS GSM ciphering key to the ME. The new GPRS UMTS ciphering key, GPRS UMTS integrity key and GPRS GSM ciphering key calculated from the challenge information shall overwrite the previous ones. The new GPRS UMTS ciphering key, GPRS UMTS integrity key and GPRS GSM ciphering key shall be stored on the USIM together with the GPRS ciphering key sequence number before the AUTHENTICATION_AND_CIPHERING RESPONSE message is transmitted. Furthermore, in A/Gb mode if a GEA ciphering algorithm that requires a 128-bit ciphering key is taken into use, then a new GPRS GSM Kc128 shall also be calculated as described in the subclause 4.7.7.3a.

In A/Gb mode, in a UMTS authentication challenge, if the MS supports integrity protection, then the MS shall ignore the GPRS GSM ciphering key received from the USIM and not store the GPRS GSM ciphering key in the ME or on the USIM.

In addition, in A/Gb mode, in a UMTS authentication challenge, if the MS has indicated support of integrity protection in the MS network capability IE to the network, and if an authentication takes place in the authentication and ciphering procedure, then a new GPRS GSM Kint shall also be calculated by the MS from the new UMTS security context derived from AKA as described in the subclause 4.7.7.3b. The new GPRS GSM Kint shall be used by the MS to check and verify the message authentication code recived in the AUTHENTICATION AND CIPHERING REQUEST message as described in Annex H in 3GPP TS 43.020 [13]. If the integrity is successfully verified in the MS, then the MS shall check if the replayed MS network capability IE and replayed MS Radio Access Capability IE received in the AUTHENTICATION AND CIPHERING REQUEST message has not been altered compared to the latest MS network capability IE and the latest MS Radio Access Capability IE that the MS sent to the network. If the replayed MS network capability IE and the replayed MS Radio Access Capability IE received in the AUTHENTICATION AND CIPHERING REQUEST message are not the same as the latest MS network capability IE and the MS Radio Access Capability IE that the MS sent to the network, then the MS shall ignore the authentication and ciphering procedure. The network may in addition indicate a GPRS GSM integrity algorithm and a new setting of the ciphering mode and GPRS GSM ciphering algorithm, to be taken into use by the MS. If the integrity of the AUTHENTICATION AND CIPHERING REQUEST message is not successfully verified in the GMM layer, then the MS shall ignore the AUTHENTICATION AND CIPHERING REQUEST message.

In A/Gb mode, in a UMTS authentication challenge if the MS has no available UMTS security context and, if the MS has indicated support for integrity protection in MS network capability IE to the network, then if the network does not activate integrity protection by indicating a GPRS GSMintegrity algorithm or does not include a message authentication code to the MS in AUTHENTICATION AND CIPHERING REQUEST message, then the MS shall ignore the AUTHENTICATION AND CIPHERING REQUEST message.

In A/Gb mode, in a UMTS authentication challenge, if the MS has indicated support for integrity protection to the network and if the integrity of the AUTHENTICATION AND CIPHERING REQUEST message is successfully verified in the MS and the MS decides to reply by sending an AUTHENTICATION AND CIPHERING RESPONSE message to the network, then the MS shall integrity protect the AUTHENTICATION AND CIPHERING RESPONSE message by calculating an message authentication code at the GMM layer using the new integrity key GPRS GSM Kint calculated by the MS from the new UMTS security context derived from AKA as described in the subclause 4.7.7.3b and as described in Annex H in 3GPP TS 43.020 [13] and include the new message authentication code into the AUTHENTICATION AND CIPHERING RESPONSE message. When a successful authentication takes place on the USIM the GMM layer in the MS shall request the LLC layer to reset the IOV_updates counter to the value zero before sending the AUTHENTICATION AND CIPHERING RESPONSE message to the network.

In Iu mode, an MS not capable of A/Gb mode shall ignore the Ciphering Algorithm IE in the AUTHENTICATION_AND_CIPHERING REQUEST message. An MS capable of both Iu mode and A/Gb mode shall store the received value in the Ciphering Algorithm IE in the AUTHENTICATION_AND_CIPHERING REQUEST message until entering state GMM-DEREGISTERED, in order to use it at an inter system change to A/Gb mode. In A/Gb mode, an MS supporting integrity protection shall store the received value in the Ciphering Algorithm IE when entering GMM-DEREGISTERED and at MS power off as described in subclause 4.7.7.3a.

If the AUTHENTICATION_AND_CIPHERING REQUEST message does not include neither the GSM authentication parameters (RAND and GPRS CKSN) nor the UMTS authentication parameters (RAND, AUTN and GPRS CKSN), then upon receipt of the message, the MS replies by sending an AUTHENTICATION_AND_CIPHERING RESPONSE message to the network.

In A/Gb mode, in the case of an established UMTS security context, if the MS has indicated support for integrity protection to the network, the network may only indicate a GPRS GSM integrity algorithm or a GPRS GSM ciphering algorithm or a change of ciphering mode setting in the AUTHENTICATION AND CIPHERING REQUEST message without re-authentication to the MS. The AUTHENTICATION AND CIPHERING REQUEST message shall include the new GPRS GSM integrity algorithm or the new GPRS GSM ciphering algorithm; or both, that shall be taken into use. When the MS receives this AUTHENTICATION AND CIPHERING REQUEST message without requiring a new authentication, then a new GPRS GSM Kint shall be calculated using the GPRS UMTS ciphering key and the GPRS UMTS integrity key from the already established UMTS security context stored in the ME as described in the subclause 4.7.7.3b and a new GPRS GSM Kc128 shall be calculated using the GPRS UMTS ciphering key and the GPRS UMTS integrity key from the already established UMTS security context stored in the ME as described in the subclause 4.7.7.3a and the MS replies by sending an AUTHENTICATION AND CIPHERING RESPONSE message to the network.

NOTE: If only a change of GPRS GSM integrity algorithm or GPRS GSM encryption algorithm or a change of both algorithms is included in the AUTHENTICATION AND CIPHERING RESPONSE message without authentication, then the MS shall not integrity protect the AUTHENTICATION AND CIPHERING RESPONSE message at GMM layer. The MS does therefore not calculate and include a message authentication code into the AUTHENTICATION AND CIPHERING RESPONSE message at GMM layer. These GMM messages are instead integrity protected at the LLC layer with current UMTS security context.

In A/Gb mode, the GMM layer shall notify the LLC layer if ciphering shall be used or not and if yes which GSM ciphering algorithm and GPRS GSM ciphering key that shall be used (see 3GPP TS 44.064 [78a]).

In A/Gb mode, if an established UMTS security context context is available in the network, if the MS has indicated support of integrity protection to the network, then the GMM layer in the MS shall assign the GPRS GSM integrity algorithm and the GPRS GSM Kint integrity key to the LLC layer after it has sent off the AUTHENTICATION AND CIPHERING RESPONSE message to the network (see 3GPP TS 43.020 [13] and 3GPP TS 44.064 [78a]).

A ME supporting UMTS authentication challenge shall support the following procedure:

In order to avoid a synchronisation failure, when the mobile station receives an AUTHENTICATION AND CIPHERING REQUEST message, the mobile station shall store the received RAND together with the RES returned from the USIM in the volatile memory and associate it with the PS domain. When the MS receives a subsequent AUTHENTICATION AND CIPHERING REQUEST message, if the stored RAND value for the PS domain is equal to the new received value in the AUTHENTICATION AND CIPHERING REQUEST message, then the mobile station shall not pass the RAND to the USIM, but shall immediately send the AUTHENTICATION AND CIPHERING RESPONSE message with the stored RES for the PS domain. If, for the PS domain, there is no valid stored RAND in the mobile station or the stored RAND is different from the new received value in the AUTHENTICATION AND CIPHERING REQUEST message, the mobile station shall pass the RAND to the USIM, shall override any previously stored RAND and RES with the new ones and start, or reset and restart timer T3316.

The RAND and RES values stored in the mobile station shall be deleted and timer T3316, if running, shall be stopped:

– upon receipt of a SECURITY MODE COMMAND (Iu mode only),
SERVICE ACCEPT (Iu mode only),
SERVICE REJECT (Iu mode only),
ROUTING AREA UPDATE_ACCEPT
or AUTHENTICATION AND CIPHERING REJECT message;

– upon expiry of timer T3316;

– if the mobile station enters the GMM states GMM-DEREGISTERED or GMM-NULL; or

– if the mobile station enters PMM-IDLE mode (Iu mode only).

4.7.7.3 Authentication and ciphering completion by the network

Upon receipt of the AUTHENTICATION AND CIPHERING RESPONSE message, the network stops the timer T3360 and checks the validity of the response (see 3GPP TS 43.020 [13] and 3GPP TS 33.102 [5a]). For this, it may use the A&C reference number information element within the AUTHENTICATION AND CIPHERING RESPONSE message to determine whether the response is correlating to the last request that was sent.

In A/Gb mode, in a UMTS authentication challenge if the MS has indicated support of integrity protection to the network and if the AUTHENTICATION AND CIPHERING REQUEST message authentication, then the network shall check and verify the message authentication code received in the AUTHENTICATION AND CIPHERING RESPONSE message from the MS by using the new integrity key GPRS GSM Kint derived from the new UMTS security context as described in subclause 4.7.7.3b and annex H in 3GPP TS 43.020 [13]. When a successful authentication takes place after a successful verification of the RES and the message authentication code received in the AUTHENTICATION AND CIPHERING RESPONSE message from the MS, the GMM layer in the network shall indicate this successful authentication to the LLC layer. If the check and verification of the message authentication code included in the AUTHENTICATION AND CIPHERING RESPONSE message fails in the network, then the network shall ignore the GMM message. If the AUTHENTICATION AND CIPHERING RESPONSE message is received in the network without a message authentication code then the network shall silently discard the GMM message.

In A/Gb mode, in the case of an established GSM security context, the GMM layer shall notify the LLC sublayer if ciphering shall be used or not. Furthermore, if ciphering shall be used, then the GMM layer shall also notify the LLC sublayer which GEA algorithm and GPRS GSM ciphering key that shall be used (see 3GPP TS 44.064 [78a]).

In A/Gb mode, in the case of an established UMTS security context, the GMM layer shall notify the LLC sublayer if ciphering shall be used or not. Furthermore, if ciphering shall be used, then the GMM layer shall also notify the LLC sublayer which GEA algorithm and which ciphering key (i.e. GPRS GSM ciphering key or GPRS GSM Kc128) that shall be used (see 3GPP TS 44.064 [78a]). If the network has selected a GEA ciphering algorithm that requires a 128-bit ciphering key, then the ME shall derive a GPRS GSM Kc128 as described in the subclause 4.7.7.3a.

In A/Gb mode, if an established UMTS security context context is available in the network, if the MS has indicated support of integrity protection to the network, the GMM layer in the network shall assign the GPRS GSM integrity algorithm and the GPRS GSM Kint integrity key to the LLC layer, after it has received the AUTHENTICATION AND CIPHERING RESPONSE message from the MS (see 3GPP TS 43.020 [13] and 3GPP TS 44.064[78a]).

Upon receipt of the AUTHENTICATION AND CIPHERING FAILURE message, the network stops the timer T3360. In Synch failure case, the core network may renegotiate with the HLR/AuC and provide the MS with new authentication parameters.

4.7.7.3a 128-bit packet-switched GSM ciphering key

The ME and the network may derive and store a 128-bit packet-switched GSM key or GPRS GSM Kc128 from an established UMTS security context. If the GPRS GSM Kc128 exits, then it is also part of the UMTS security context.

The ME with a USIM in use shall compute a new GPRS GSM Kc128 using the GPRS UMTS ciphering key and the GPRS UMTS integrity key from an established UMTS security context as specified in 3GPP TS 33.102 [5a]. The new GPRS GSM Kc128 shall be stored only in the ME. The ME shall overwrite the existing GPRS GSM Kc128 with the new GPRS GSM Kc128. The ME shall delete the GPRS GSM Kc128 at switch off, when the USIM is disabled as well as under the conditions identified in the subclause 4.1.3.2 and 4.7.7.4. The ME with a USIM in use shall apply the GPRS GSM Kc128 when in A/Gb mode a GEA ciphering algorithm that requires a 128-bit ciphering key is taken into use.

The network shall compute the GPRS GSM Kc128 using the GPRS UMTS integrity key and the GPRS UMTS ciphering key from an established UMTS security context as specified in 3GPP TS 33.102 [5a] only when in A/Gb mode a GEA ciphering algorithm that requires a 128-bit ciphering key is to be used.

In A/Gb mode, if the MS supports integrity protection, the information in the Ciphering Algorithm IE together with the IMSI from the USIM shall be stored in a non-volatile memory in the ME at MS power off. The information stored in the Ciphering Algorithm IE can only be used if the IMSI from the USIM matches the IMSI stored in the ME non-volatile memory at MS power on; otherwise the MS shall delete the Ciphering Algorithm IE.

4.7.7.3b 128-bit packet-switched GSM integrity key (in A/Gb mode and only if MS supports integrity protection)

The ME and the network may derive and store a 128-bit packet-switched GPRS GSM Kint from an established UMTS security context. If the GPRS GSM Kint exits, then it is also part of the UMTS security context.

The ME with a USIM in use shall compute a new GPRS GSM Kint using the GPRS UMTS ciphering key and the GPRS UMTS integrity key from an established UMTS security context as specified in 3GPP TS 43.020 [13]. The new GPRS GSM Kint shall be stored only in the ME. The ME shall overwrite the existing GPRS GSM Kint with the new GPRS GSM Kint. The ME shall delete the GPRS GSM Kint at MS switch off, when the USIM is disabled as well as under the conditions identified in the subclause 4.1.3.2 and 4.7.7.4. The ME with a USIM in use shall apply the GPRS GSM Kint when in A/Gb mode a GIA integrityg algorithm that requires a 128-bit integrity key is taken into use.

The network shall compute the GPRS GSM Kint using the GPRS UMTS integrity key and the GPRS UMTS ciphering key from an established UMTS security context as specified in 3GPP TS 43.020 [13]only when in A/Gb mode a GIA integrity algorithm that requires a 128-bit integrity key is to be used.

At MS power off, the information in the Integrity Algorithm IE shall be stored in a non-volatile memory in the ME together with the IMSI from the USIM. The information stored in the Integrity Algorithm IE can only be used if the IMSI from the USIM matches the IMSI stored in the ME non-volatile memory at MS power on; otherwise the MS shall delete the Integrity Algorithm IE.

4.7.7.4 GPRS ciphering key sequence number

The security parameters for authentication and ciphering are tied together in sets.

In a GSM authentication challenge, from a challenge parameter RAND both the authentication response parameter SRES and the GPRS GSM ciphering key can be computed given the secret key associated to the IMSI.

In a UMTS authentication challenge, from a challenge parameter RAND, the authentication response parameter RES and the GPRS UMTS ciphering key and the GPRS UMTS integrity key can be computed given the secret key associated to the IMSI. Furthermore, in the USIM a GPRS GSM ciphering key can be computed from the GPRS UMTS integrity key and the GPRS UMTS ciphering key by means of an unkeyed conversion function. Furthermore, in A/Gb mode if a GEA ciphering algorithm that requires a 128-bit ciphering key is taken into use, then a GPRS GSM Kc128 shall also be calculated as described in the subclause 4.7.7.3a. Furthermore, in A/Gb mode, if the MS and the network support integrity protection, when a GIA integrity algorithm that requires a 128-bit integrity key is taken into use, then a GPRS GSM Kint shall also be calculated as described in the subclause 4.7.7.3b.

In order to allow start of ciphering on a logical link without authentication, GPRS ciphering key sequence numbers are introduced.

The GPRS ciphering key sequence number is managed by the network such that the AUTHENTICATION AND CIPHERING REQUEST message contains the GPRS ciphering key sequence number allocated to the GPRS GSM ciphering key (in case of a GSM authentication challenge) or the GPRS UMTS ciphering key and the GPRS UMTS integrity key (in case of a UMTS authentication challenge) which may be computed from the RAND parameter carried in that message.

If an authentication and ciphering procedure has been completed successfully and a GPRS ciphering key sequence number is stored in the network, the network shall include a different GPRS ciphering key sequence number in the AUTHENTICATION AND CIPHERING REQUEST message when it intiates a new authentication and ciphering procedure.

If a GPRS ciphering key sequence number is contained in the first message during a GMM procedure, the network shall include a different GPRS ciphering key sequence number in the AUTHENTICATION_AND_CIPHERING REQUEST message when it initiates an authentication and ciphering procedure.

The MS stores the GPRS ciphering key sequence number with the GPRS GSM ciphering key (in case of a GSM authentication challenge) and the GPRS UMTS ciphering key and the GPRS UMTS integrity key (in case of a UMTS authentication challenge), and includes the corresponding GPRS ciphering key sequence number in the ROUTING AREA UPDATE REQUEST, SERVICE REQUEST and ATTACH REQUEST messages.

If the GPRS ciphering key sequence number is deleted, the associated GPRS GSM ciphering key, GPRS UMTS ciphering key, GPRS UMTS integrity key, GPRS GSM Kc128 and GPRS GSM Kint shall be deleted if any (i.e. the established GSM security context or the UMTS security context is no longer valid).

In Iu mode, the network may choose to start ciphering and integrity checking with the stored GPRS UMTS ciphering key and the stored GPRS UMTS integrity key (under the restrictions given in 3GPP TS 42.009 [5] and 3GPP TS 33.102 [5a]) if the stored GPRS ciphering key sequence number and the one given from the MS are equal.

In A/Gb mode, the network may choose to start ciphering with the stored GPRS GSM ciphering key or GPRS GSM Kc128 (under the restrictions given in 3GPP TS 42.009 [5]) if the stored GPRS ciphering key sequence number and the one given from the MS are equal and the previously negotiated ciphering algorithm is known and supported in the network. When ciphering is requested at GPRS attach, the authentication and ciphering procedure shall be performed since the MS does not store the ciphering algorithm after entering state GMM-DEREGISTERED.

NOTE 1: The decision of starting ciphering with the GPRS GSM ciphering key or the GPRS GSM Kc128 depends on whether the network indicates in the AUTHENTICATION AND CIPHERING REQUEST message a GEA ciphering algorithm which requires a 64 or 128-bit ciphering key as specified in 3GPP TS 33.102 [5a].

In A/Gb mode, if MS indicates support of integrity protection in the MS network capability IE to the network, if the ME has a Integrity Algorithm IE and a Ciphering Algorithm IE stored in the ME non-volatile memory at MS power on, then the GMM layer shall calculate a GPRS GSM Kint key as described in subclause 4.7.7.3b and a GPRS GSM Kc128 key as described in subclause 4.7.7.3a and indicate to the LLC layer before sending the ATTACH REQUEST message that LLC layer shall start integrity protection with the indicated GPRS GSM Kint key and the integrity algorithm (indicated in the stored Integrity Algorithm IE). The GMM layer shall also assign the GPRS GSM Kc128 key and the ciphering algorithm (indicated in the stored Ciphering Algorithm IE) to the LLC layer. The network shall start integrity protection in the LLC layer after reception of the ATTACH REQUEST message with the stored GPRS GSM Kint and the integrity algorithm identified by the stored GPRS GSMintegrity algorithm used when UE was previously attached if the GPRS GSMintegrity algorithm is known and supported in the network, and if the stored GPRS ciphering key sequence number and the one given from the MS are equal.

Upon GPRS attach, if ciphering is to be used, an AUTHENTICATION AND CIPHERING REQUEST message shall be sent to the MS to start ciphering. In A/Gb mode, upon GPRS attach, if the MS and network supports integrity protection, then the network may choose to start ciphering with the stored GPRS GSM ciphering key or GPRS GSM Kc128 (under the restrictions given in 3GPP TS 42.009 [5]) if the stored GPRS ciphering key sequence number and the one given from the MS in the ATTACH REQUEST message or ROUTING AREA UPDATE REQUEST message are equal and the previously negotiated ciphering algorithm is known and supported in the network, without initiating a authentication and ciphering procedure.

If the GPRS ciphering key sequence number stored in the network does not match the GPRS ciphering key sequence number received from the MS in the ATTACH REQUEST message, then the network should authenticate the MS.

In A/Gb mode, the MS starts ciphering after sending the AUTHENTICATION AND CIPHERING RESPONSE message. The network starts ciphering when a valid AUTHENTICATION AND CIPHERING RESPONSE is received from the MS.

In Iu mode, the MS starts ciphering and integrity checking according to the conditions specified in specification 3GPP TS 25.331 [23c].

In A/Gb mode, as an option, the network may decide to continue ciphering without sending an AUTHENTICATION AND CIPHERING REQUEST message after receiving a ROUTING AREA UPDATE REQUEST message with a valid GPRS ciphering key sequence number. Both the MS and the network shall use the latest ciphering parameters. The network starts ciphering when sending the ciphered ROUTING AREA UPDATE ACCEPT message to the MS. The MS starts ciphering after receiving a valid ciphered ROUTING AREA UPDATE ACCEPT message from the network.

NOTE 2: In some specifications the term KSI (Key Set Identifier) is used instead of the term GPRS ciphering key sequence number.

4.7.7.5 Authentication not accepted by the network

If the authentication response (RES or SRES) is not valid, the network response depends upon the type of identity used by the MS in the first message:

– If the P-TMSI has been used, the network may decide to initiate the identification procedure. If the IMSI given by the MS differs from the one the network had associated with the P-TMSI, the authentication should be restarted with the correct parameters. If the IMSI provided by the MS is the expected one (i.e. authentication has really failed), the network should send an AUTHENTICATION AND CIPHERING REJECT message to the mobile station.

– If the IMSI has been used, or the network decides not to try the identification procedure, an AUTHENTICATION AND CIPHERING REJECT message should be transferred to the MS.

Upon receipt of an AUTHENTICATION AND CIPHERING REJECT message,

a) if the message has been successfully integrity checked by the lower layers, the MS shall set the GPRS update status to GU3 ROAMING NOT ALLOWED and shall delete the P-TMSI, P-TMSI signature, RAI and GPRS ciphering key sequence number stored. If available, also the TMSI, LAI and ciphering key sequence number shall be deleted and the update status shall be set to U3 ROAMING NOT ALLOWED. The SIM/USIM shall be considered as invalid until switching off or the SIM/USIM is removed. If the MS maintains a counter for "SIM/USIM considered invalid for GPRS services", then the MS shall set this counter to MS implementation-specific maximum value. If the MS maintains a counter for "SIM/USIM considered invalid for non-GPRS services", then the MS shall set this counter to MS implementation-specific maximum value.

If S1 mode is supported by the MS, the MS shall in addition handle the EMM parameters EMM state, EPS update status, last visited registered TAI, TAI list, GUTI and KSIASME as specified in 3GPP TS 24.301 [120] for the case when an EPS authentication is not accepted by the network.

b) if the message is received without integrity protection, then the MS shall start timer T3247 with a random value uniformly drawn from the range between 30 minutes and 60 minutes, if the timer is not running (see subclause 4.1.1.6A). Additionally, the MS shall:

– if the MS maintains a counter for "SIM/USIM considered invalid for GPRS services" events and the counter has a value less than an MS implementation-specific maximum value, proceed as specified in subclause 4.1.1.6A, list item 6.a) for the case an ATTACH REJECT or ROUTING AREA UPDATE REJECT message is received without integrity protection; and

– otherwise proceed as specified under list item a) above for the case that the message has been successfully checked by the lower layers.

List item b) above is also applicable, if the message is received in A/Gb mode.

If the AUTHENTICATION AND CIPHERING REJECT message is received, the MS shall abort any GMM procedure, shall stop any of the retransmission timers that are running (e.g. T3310, T3317, T3330, T3321, T3318 or T3320 and shall enter state GMM-DEREGISTERED.

In UTRAN Iu mode, depending on local regulations or operator preference for emergency bearer services, if the MS has a PDN connection for emergency bearer services established or is establishing a PDN connection for emergency bearer services, the SGSN need not follow the procedures specified for the authentication failure in the present subclause, the SGSN can continue with the ongoing GMM specific procedure or Session Management procedure. Upon completion of the GMM procedure or Session management procedure, the SGSN shall deactivate all non-emergency PDP contexts, if any, by initiating a PDP context deactivation procedure. The network shall consider the MS to be attached for emergency bearer services only.

4.7.7.5.1 Authentication not accepted by the MS

In a UMTS authentication challenge, the authentication procedure is extended to allow the MS to check the authenticity of the core network. Thus allowing, for instance, detection of false base station.

Following a UMTS authentication challenge, the MS may reject the core network, on the grounds of an incorrect AUTN parameter (see 3GPP TS 33.102 [5a]). This parameter contains two possible causes for authentication failure:

a) MAC code failure

If the MS considers the MAC code (supplied by the core network in the AUTN parameter) to be invalid, it shall send a AUTHENTICATION AND CIPHERING FAILURE message to the network, with the GMM cause ‘MAC failure’. The MS shall then follow the procedure described in subclause 4.7.7.6 (f).

b) SQN failure

If the MS considers the SQN (supplied by the core network in the AUTN parameter) to be out of range, it shall send a AUTHENTICATION AND CIPHERING FAILURE message to the network, with the GMM cause ‘Synch failure’ and the re-synchronization token AUTS provided by the USIM (see 3GPP TS 33.102 [5a]). The MS shall then follow the procedure described in subclause 4.7.7.6 (g).

In Iu mode, an MSwith a USIM inserted shall reject the authentication challenge if no Authentication Parameter AUTN IE was present in the AUTHENTICATION REQUEST message (i.e. a GSM authentication challenge has been received when the MS expects a UMTS authentication challenge). In such a case, the MS shall send the AUTHENTICATION AND CIPHERING FAILURE message to the network, with the GMM cause ‘GSM authentication unacceptable’. The MS shall then follow the procedure described in subclause 4.7.7.6 (f).

If the MS returns an AUTHENTICATION_AND_CIPHERING_FAILURE message to the network, the MS shall delete any previously stored RAND and RES and shall stop timer T3316, if running.

If the MS has a PDN connection for emergency bearer services established or is establishing such a PDN connection, additional MS requirements are specified in subclause 4.7.7.6, under "for items f and g".

4.7.7.6 Abnormal cases

The following abnormal cases can be identified:

a) Lower layer failure

Upon detection of a lower layer failure before the AUTHENTICATION AND CIPHERING RESPONSE message is received, the network shall abort the procedure.

b) Expiry of timer T3360

The network shall, on the first expiry of the timer T3360, retransmit the AUTHENTICATION AND CIPHERING REQUEST message and shall reset and start timer T3360. This retransmission is repeated four times, i.e. on the fifth expiry of timer T3360, the procedure shall be aborted.

c) Collision of an authentication and ciphering procedure with a GPRS attach procedure

If the network receives an ATTACH REQUEST message before the ongoing authentication procedure has been completed and no GPRS attach procedure is pending on the network (i.e. no ATTACH ACCEPT/REJECT message has to be sent as an answer to an ATTACH REQUEST message), the network shall abort the authentication and ciphering procedure and proceed with the new GPRS attach procedure.

d) Collision of an authentication and ciphering procedure with a GPRS attach procedure when the authentication and ciphering procedure has been caused by a previous GPRS attach procedure

If the network receives an ATTACH REQUEST message before the ongoing authentication procedure has been completed and a GPRS attach procedure is pending (i.e. an ATTACH ACCEPT/REJECT message has still to be sent as an answer to an earlier ATTACH REQUEST message), then:

– If one or more of the information elements in the ATTACH REQUEST message differs from the ones received within the previous ATTACH REQUEST message, the network shall not treat the authentication any further and proceed with the GPRS attach procedure; or

– If the information elements do not differ, then the network shall not treat any further this new ATTACH REQUEST message.

d1) Collision of an authentication and ciphering procedure with a GPRS detach procedure

GPRS detach containing cause "power off":

If the network receives a DETACH REQUEST message before the ongoing authentication and ciphering procedure has been completed, the network shall abort the authentication and ciphering procedure and shall progress the GPRS detach procedure.

GPRS detach containing other causes than "power off":

If the network receives a DETACH REQUEST message before the ongoing authentication and ciphering procedure has been completed, the network shall complete the authentication and ciphering procedure and shall respond to the GPRS detach procedure as described in subclause 4.7.4.

e) Collision of an authentication and ciphering procedure with a routing area updating procedure

If the network receives a ROUTING AREA UPDATE REQUEST message before the ongoing authentication procedure has been completed, the network shall progress both procedures.

Figure 4.7.7/1 3GPP TS 24.008: Authentication and ciphering procedure

(f) Authentication failure (GMM cause #18 "MAC failure" or #21 "GSM authentication unacceptable")

The MS shall send an AUTHENTICATION AND CIPHERING FAILURE message, with GMM cause ‘MAC failure’ or ‘GSM authentication unacceptable’ according to subclause 4.7.7.5.1, to the network and start timer T3318. Furthermore, the MS shall stop any of the retransmission timers that are running (e.g. T3310, T3321, T3330 or T3317). Upon the first receipt of an AUTHENTICATION AND CIPHERING FAILURE message from the MS with GMM cause ‘MAC failure’ or ‘GSM authentication unacceptable’ the network may initiate the identification procedure described in subclause 4.7.8. This is to allow the network to obtain the IMSI from the MS. The network may then check that the P-TMSI originally used in the authentication challenge corresponded to the correct IMSI. Upon receipt of the IDENTITY REQUEST message from the network, the MS shall send the IDENTITY RESPONSE message.

NOTE: Upon receipt of an AUTHENTICATION AND CIPHERING FAILURE message from the MS with reject cause "MAC failure" or "GSM authentication unacceptable", the network may also terminate the authentication procedure (see subclause 4.7.7.5).

If the P-TMSI/IMSI mapping in the network was incorrect, the network should respond by sending a new AUTHENTICATION AND CIPHERING REQUEST message to the MS. Upon receiving the new AUTHENTICATION AND CIPHERING REQUEST message from the network, the MS shall stop timer T3318, if running, and then process the challenge information as normal. If the P-TMSI/IMSI mapping in the network was correct, the network should terminate the authentication and ciphering procedure by sending an AUTHENTICATION AND CIPHERING REJECT message.

If the network is validated successfully (an AUTHENTICATION AND CIPHERING REQUEST message that contains a valid SQN and MAC is received), the MS shall send the AUTHENTICATION AND CIPHERING RESPONSE message to the network and shall start any retransmission timers (e.g. T3310, T3321, T3330 or T3317), if they were running and stopped when the MS received the first failed AUTHENTICATION AND CIPHERING REQUEST message.

If the MS receives the second AUTHENTICATION AND CIPHERING REQUEST message while T3318 is running and

– the MAC value cannot be resolved; or

– the message was received in UMTS and contains a GSM authentication challenge,

the MS shall follow the procedure specified in this subclause (f), starting again from the beginning. If the SQN is invalid, the MS shall proceed as specified in (g).

It can be assumed that the source of the authentication challenge is not genuine (authentication not accepted by the MS) if any of the following occurs:

– the timer T3318 expires;

– the MS detects any combination of the authentication failures: "MAC failure", "invalid SQN", and "GSM authentication unacceptable", during three consecutive authentication challenges. The authentication challenges shall be considered as consecutive only, if the authentication challenges causing the second and third authentication failure are received by the MS, while the timer T3318 or T3320 started after the previous authentication failure is running.

The MS shall stop timer T3318, if the timer is running and the MS detects a lower layer failure, the network releases the PS signalling connection, the MS performs inter-system change to S1 mode, or the MS initiates a GPRS suspension procedure (see 3GPP TS 44.018 [84]).

When it has been deemed by the MS that the source of the authentication challenge is not genuine (authentication not accepted by the MS), the MS shall behave as described in subclause 4.7.7.6.1.

Figure 4.7.7a/1 3GPP TS 24.008: Authentication failure cause "MAC failure" or "GSM authentication unacceptable"

(g) Authentication failure (GMM cause #19 "Synch failure"):

The MS shall send an AUTHENTICATION AND CIPHERING FAILURE message, with the GMM cause "Synch failure", to the network and start the timer T3320. Furthermore, the MS shall stop any of the retransmission timers that are running (e.g. T3310, T3321, T3330 or T3317). Upon the first receipt of an AUTHENTICATION AND CIPHERING message from the MS with the GMM cause "synch failure", the network shall use the returned AUTS parameter from the authentication & ciphering failure parameter IE in the AUTHENTICATION AND CIPHERING FAILURE message, to re-synchronise. The re-synchronisation procedure requires the SGSN to delete all unused authentication vectors for that IMSI and obtain new vectors from the HLR. When re-synchronisation is complete, the network shall initiate the authentication & ciphering procedure. Upon receipt of the AUTHENTICATION AND CIPHERING REQUEST message, the MS shall stop timer T3320, if running.

NOTE: Upon receipt of two consecutive AUTHENTICATION AND CIPHERING FAILURE messages from the MS with reject cause "synch failure", the network may terminate the authentication procedure by sending an AUTHENTICATION AND CIPHERING REJECT message.

If the network is validated successfully (a new AUTHENTICATION AND CIPHERING REQUEST message is received which contains a valid SQN and MAC) while T3320 is running, the MS shall send the AUTHENTICATION AND CIPHERING RESPONSE message to the network and shall start any retransmission timers (i.e. T3310, T3321, T3330 or T3317), if they were running and stopped when the MS received the first failed AUTHENTICATION AND CIPHERING REQUEST message.

If the MS receives the second AUTHENTICATION AND CIPHERING REQUEST message while T3320 is running and

– the MAC value cannot be resolved; or

– the message was received in Iu mode and contains a GSM authentication challenge,

the MS shall proceed as specified in (f). If the SQN is invalid, the MS shall follow the procedure specified in this subclause (g), starting again from the beginning.

The MS shall deem that the network has failed the authentication check and behave as described in subclause 4.7.7.6.1, if any of the following occurs:

– the timer T3320 expires;

– the MS detects any combination of the authentication failures: "MAC failure", "invalid SQN", and "GSM authentication unacceptable", during three consecutive authentication challenges. The authentication challenges shall be considered as consecutive only, if the authentication challenges causing the second and third authentication failure are received by the MS, while the timer T3318 or T3320 started after the previous authentication failure is running.

The MS shall stop timer T3320, if the timer is running and the MS detects a lower layer failure, the network releases the PS signalling connection, the MS performs inter-system change to S1 mode, or the MS initiates a GPRS suspension procedure (see 3GPP TS 44.018 [84]).

When it has been deemed by the MS that the source of the authentication challenge is not genuine (authentication not accepted by the MS), the MS shall behave as described in subclause 4.7.7.6.1.

Figure 4.7.7b/1 3GPP TS 24.008: Authentication failure cause ‘Synch failure’

Upon receipt of an AUTHENTICATION AND CIPHERING REJECT message, the UE shall perform the actions as specified in subclause 4.7.7.5.

For items f and g:

Depending on local requirements or operator preference for emergency bearer services, if the MS has a PDN connection for emergency bearer services established or is establishing such a PDN connection, the SGSN need not follow the procedures specified for the authentication failure specified in the present subclause and shall continue using the current security context, if any. The SGSN shall deactivate all non-emergency PDP contexts, if any, by initiating a PDP context deactivation procedure. If there is an ongoing session management procedure, the SGSN shall deactivate all non-emergency PDP contexts upon completion of the session management procedure. The network shall consider the MS to be attached for emergency bearer services only.

If an MS has a PDN connection for emergency bearer services established or is establishing such a PDN connection when timer T3318 or T3320 expires, the MS shall not deem that the network has failed the authentication check and not behave as described in subclause 4.7.7.6.1. Instead the MS shall continue using the current security context, if any. The MS shall deactivate all non-emergency PDP contexts, if any, by initiating a PDP context deactivation procedure. If there is an ongoing session management procedure, the MS shall deactivate all non-emergency PDP contexts upon completion of the session management procedure. The MS shall start any retransmission timers (e.g. T3310, T3317, T3321 or T3330) if:

– they were running and stopped when the MS received the AUTHENTICATION AND CIPHERING REJECT message and detected an authentication failure; and

– the procedures associated with these timers have not yet been completed.

The MS shall consider itself to be attached for emergency bearer services only.

4.7.7.6.1 MS behaviour towards a network that has failed the authentication procedure

If the MS deems that the network has failed the authentication check, then it shall request RR or RRC to release the RR connection and the PS signalling connection, if any, and bar the active cell or cells (see 3GPP TS 25.331 [23c] and 3GPP TS 44.018 [84]). The MS shall start any retransmission timers (i.e. T3310, T3321, T3330 or T3317), if they were running and stopped when the MS received the first AUTHENTICATION AND CIPHERING REQUEST message containing an invalid MAC or invalid SQN, or no AUTN when a UMTS authentication challenge was expected.

4.7.7.7 Use of established security contexts

In A/Gb mode, in the case of an established GSM security context, the GPRS GSM ciphering key shall be taken into use by the MS before the AUTHENTICATION AND CIPHERING RESPONSE message is transmitted.

In A/Gb mode, in the case of an established UMTS security context, and if the network indicates in the AUTHENTICATION AND CIPHERING REQUEST message to the MS that a GEA ciphering algorithm that requires a 64-bit ciphering key shall be taken into use, then the GPRS GSM ciphering key shall be taken into use by the MS before the AUTHENTICATION AND CIPHERING RESPONSE message is transmitted. The network shall derive a GPRS GSM ciphering key from the GPRS UMTS ciphering key and the GPRS UMTS integrity key, by using the conversion function named "c3" defined in 3GPP TS 33.102 [5a].

In A/Gb mode, in the case of an established UMTS security context, and if the network indicates in the AUTHENTICATION AND CIPHERING REQUEST message to the MS that a GEA ciphering algorithm that requires a 128-bit ciphering key shall be taken into use, then the MS shall take the following actions:

– if authentication is not requested and a GEA ciphering algorithm that requires 64-bit ciphering key is in use, the MS shall take into use the GPRS GSM Kc128 derived by the ME from the GPRS UMTS ciphering key and GPRS UMTS integrity key of the established UMTS security context in use (see 3GPP TS 33.102 [5a]) before the AUTHENTICATION AND CIPHERING RESPONSE message is transmitted;.

– if authentication is not requested and a GEA ciphering algorithm that requires 128-bit ciphering key is in use, the GPRS GSM Kc128 of the established UMTS security context in use still applies;

otherwise, the MS shall take into use the GPRS GSM Kc128 derived by the ME from the GPRS UMTS ciphering key and the GPRS UMTS integrity key provided by the USIM during the latest successful authentication procedure (see subclause 4.7.7.3a) before the AUTHENTICATION AND CIPHERING RESPONSE message is transmitted.

In A/Gb mode, in the case of an established UMTS security context, and if the network indicates in the AUTHENTICATION AND CIPHERING REQUEST message to the MS that a GEA ciphering algorithm that requires a 128-bit ciphering key shall be taken into use, then the network shall derive a GPRS GSM Kc128 (see subclause 4.7.7.3a).

In A/Gb mode, if an established UMTS security context context is available in the network, if the MS indicates support of integrity protection to the network and the network supports integrity protection, if the network indicates in the AUTHENTICATION AND CIPHERING REQUEST message to the MS that a new GPRS GSM integrity algorithm shall be taken into use but no authentication is requested, then the GPRS GSM Kint of the established UMTS security context in use still applies in the MS and network.

In A/Gb mode, in the case of an established UMTS security context, and if the network indicates in the AUTHENTICATION AND CIPHERING REQUEST message to the MS that a GIA integrity protection algorithm that requires a 128-bit integrity key shall be taken into use but no authentication is requested, then the GPRS GSM Kint of the established UMTS security context in use still applies in the MS.

In A/Gb mode, if during an ongoing, already ciphering protected RR connection, the network initiates a new Authentication and ciphering procedure, the new GPRS GSM ciphering key or GPRS GSM Kc128 shall be taken into use by the MS before the AUTHENTICATION AND CIPHERING RESPONSE message is transmitted. In case of inter-system change to Iu mode after receipt of the AUTHENTICATION AND CIPHERING REQUEST message, the MS and the network shall take the new keys into use immediately after the inter-system change.

In Iu mode, in the case of an established GSM security context, the ME shall derive a GPRS UMTS ciphering key and a GPRS UMTS integrity key from the GPRS GSM ciphering key by using the conversion functions named "c4" and "c5" defined in 3GPP TS 33.102 [5a]. The derived GPRS UMTS ciphering key and GPRS UMTS integrity key shall be taken into use by the MS when a valid SECURITY MODE COMMAND message indicating PS domain is received during an RR connection (the definition of a valid SECURITY MODE COMMAND message is given in 3GPP TS 25.331 [23c]). The network shall derive a GPRS UMTS ciphering key and a GPRS UMTS integrity key from the GPRS GSM ciphering key by using the conversion functions named "c4" and "c5" defined in 3GPP TS 33.102 [5a].

In Iu mode, in the case of an established UMTS security context, the GPRS UMTS ciphering key and the GPRS UMTS integrity key shall be taken into use by the MS when a valid SECURITY MODE COMMAND message indicating PS domain is received during a PS signalling connection (the definition of a valid SECURITY MODE COMMAND message is given in 3GPP TS 25.331 [23c]).

In Iu mode, if the MS received a valid SECURITY MODE COMMAND message indicating PS domain in Iu mode or a valid AUTHENTICATION AND CIPHERING REQUEST message in A/Gb mode before the network initiates a new authentication and ciphering procedure and establishes a new GSM/UMTS security context, the new GPRS UMTS ciphering key and GPRS UMTS integrity key are taken into use by the MS, when a new valid SECURITY MODE COMMAND message indicating PS domain is received during the PS signalling connection. In case of inter-system change to A/Gb mode, the MS and the network shall take the new keys into use immediately after the inter-system change.

4.7.7.8 Handling of keys at intersystem change from Iu mode to A/Gb mode

At an inter-system change from Iu mode to A/Gb mode, ciphering may be started (see 3GPP TS 44.064 [78a]) without any new authentication and ciphering procedure. Deduction of the appropriate security key for ciphering in A/Gb mode, depends on the current GSM/UMTS security context stored in the MS and the network.

The ME shall handle the GPRS GSM ciphering key and a potential GPRS GSM Kc128 according to table 4.7.7.8.1.

In the case of an established GSM security context, before any initial GMM message is sent in the new cell in A/Gb mode, the GMM layer in the MS shall notify the LLC layer if ciphering shall be used or not. If ciphering shall be used, then the GPRS GSM ciphering key and the applicable GEA ciphering algorithm according to the stored Ciphering Algorithm IE in the MS shall also be indicated to the LLC layer (see 3GPP TS 44.064 [78a]).

In the case of an established UMTS security context, before any initial GMM message is sent in the new cell in A/Gb mode, the GMM layer in the MS shall notify the LLC layer if ciphering shall be used or not. If ciphering shall be used, then the GPRS GSM ciphering key or GPRS GSM Kc128 and the applicable GEA ciphering algorithm according to the stored Ciphering Algorithm IE in the MS shall also be indicated to the LLC layer (see 3GPP TS 44.064 [78a]). If the network has selected a GEA-algorithm that requires a 128-bit ciphering key, then the ME shall apply a GPRS GSM Kc128 derived from the GPRS UMTS ciphering key and the GPRS UMTS integrity key of the established UTMS security context as specified in 3GPP TS 33.102 [5a].

Table 4.7.7.8.1/3GPP TS 24.008: Inter-system change from Iu mode to A/Gb mode

Security context established in MS and network in Iu mode

At inter-system change to A/Gb mode:

GSM security context

An ME shall apply the GPRS GSM ciphering key that was received from the GSM security context created in the SIM/USIM during the latest successful authentication procedure.

UMTS security context

If a GEA algorithm is taken into use that requires a 64-bit long ciphering key, then an ME shall apply the GPRS GSM ciphering key that was derived by the USIM from the GPRS UMTS ciphering key and the GPRS UMTS integrity key during the latest successful authentication procedure.

If a GEA algorithm is taken into use that requires a 128-bit ciphering key, then an ME shall apply the GPRS GSM Kc128 derived by the ME from the GPRS UMTS ciphering key and the GPRS UMTS integrity key (see 3GPP TS 33.102 [5a]) provided by the USIM during the lastest successful authentication procedure (see subclause 4.7.7.3a).

NOTE: A USIM with UMTS security context, passes the GPRS UMTS ciphering key, the GPRS UMTS integrity key and the derived GPRS GSM ciphering key to the ME independent on the current radio access being UTRAN or GERAN.

4.7.7.9 Handling of keys at intersystem change from A/Gb mode to Iu mode

At an inter-system change from A/Gb mode to Iu mode, ciphering and integrity may be started (see 3GPP TS 25.331 [23c]) without any new authentication and ciphering procedure. Deduction of the appropriate security keys for ciphering and integrity check in Iu mode, depends on the current GSM/UMTS security context stored in the MS and the network.

The ME shall handle the GPRS UMTS ciphering key and the GPRS UMTS integrity key according to table 4.7.7.9.1.

Table 4.7.7.9.1/3GPP TS 24.008: Inter-system change from A/Gb mode to Iu mode

Security context established in MS and network in A/Gb mode

At inter-system change to Iu mode:

GSM security context

An ME shall derive the GPRS UMTS ciphering key and the GPRS UMTS integrity key from the GPRS GSM ciphering key that was provided by the SIM/USIM during the latest successful authentication procedure. The conversion functions named "c4" and "c5" in 3GPP TS 33.102 [5a] are used for this purpose.

UMTS security context

An ME shall apply the GPRS UMTS ciphering key and the GPRS UMTS integrity key that were received from the UMTS security context created in the USIM during the latest successful authentication procedure.

NOTE: A USIM with UMTS security context, passes the GPRS UMTS ciphering key, the GPRS UMTS integrity key and the derived GPRS GSM ciphering key to the ME independent on the current radio access being UTRAN or GERAN.

4.7.7.10 Handling of keys at intersystem change from S1 mode to Iu mode or A/Gb mode

At an inter-system change from S1 mode to Iu mode, ciphering and integrity may be started (see 3GPP TS 25.331 [23c]) without any new authentication and ciphering procedure. At an inter-system change from S1 mode to A/Gb mode, ciphering may be started (see 3GPP TS 44.064 [78a]) without any new authentication and ciphering procedure. Deduction of the appropriate security keys for ciphering and integrity check in Iu mode or for ciphering in A/Gb mode, depends on the current EPS security context or the UMTS security context for the PS domain stored in the MS and the network.

The ME shall handle the GPRS UMTS ciphering key, the GPRS UMTS integrity key, the GPRS GSM ciphering key and a potential GPRS GSM Kc128 according to table 4.7.7.10.1, table 4.7.7.10.2 and table 4.7.7.10.3.

Table 4.7.7.10.1/3GPP TS 24.008: Inter-system change from S1 mode to Iu mode or A/Gb mode in connected mode.

Security context established in MS and network

At inter-system change to Iu mode or A/Gb mode in connected mode

EPS security context

An ME shall derive the UMTS security keys GPRS UMTS ciphering key (CK’) and GPRS UMTS integrity key (IK’) from KASME and the NAS downlink COUNT value as specified in 3GPP TS 33.401 [123]. The ME shall use the derived UMTS security keys to derive the GPRS GSM ciphering key using the "c3" conversion function as specified in 3GPP TS 33.102 [5a].

At inter-system change from S1 mode to Iu mode, the ME shall apply the new derived GPRS UMTS integrity key and GPRS UMTS ciphering key.

At inter-system change from S1 mode to A/Gb mode, the ME shall apply the new derived GPRS GSM ciphering key.

Furthermore, the ME shall replace an already established UMTS security context for the PS domain, if any, in the USIM. The MS shall in addition handle the STARTPS value as specified in 3GPP TS 25.331 [23c].

At inter-system change from S1 mode to A/Gb mode, if a GEA algorithm is taken into use that requires a 64-bit long ciphering key, then an ME shall apply the derived GPRS GSM ciphering key.

At inter-system change from S1 mode to A/Gb mode, if a GEA algorithm is taken into use that requires a 128-bit long ciphering key, then an ME shall apply the derived GPRS GSM Kc128 that was derived by the ME from the derived UMTS security keys (see subclause 4.7.7.3a).

NOTE 1: For the case in table 4.7.7.10.1, because of deriving a new UMTS security context for the PS domain, a new GPRS GSM ciphering key needs to be derived from the new derived UMTS security keys (i.e. CK’ and IK’). Note that the new GPRS GSM ciphering key is also part of the new UMTS security context for the PS domain, and therefore any old GPRS GSM ciphering key stored in the USIM and in the ME belongs to an old UMTS security context for the PS domain and can no longer be taken into use.

Table 4.7.7.10.2/3GPP TS 24.008: Inter-system change from S1 mode to Iu mode or A/Gb mode in idle mode when the TIN indicates "GUTI".

Security context established in MS and network

At inter-system change to Iu mode or A/Gb mode in idle mode when the TIN indicates "GUTI"

EPS security context

An ME shall derive the UMTS security keys GPRS UMTS ciphering key (CK’) and GPRS UMTS integrity key (IK’) from KASME and the NAS uplink COUNT value as specified in 3GPP TS 33.401 [123]. The ME shall use the derived UMTS security keys to derive the GPRS GSM ciphering key using the "c3" conversion function as specified in 3GPP TS 33.102 [5a].

At inter-system change from S1 mode to Iu mode, the ME shall apply the new derived GPRS UMTS integrity key and GPRS UMTS ciphering key.

At inter-system change from S1 mode to A/Gb mode, the ME shall apply the new derived GPRS GSM ciphering key.

Furthermore, the ME shall replace an already established UMTS security context for the PS domain, if any, in the USIM. The MS shall in addition handle the STARTPS value as specified in 3GPP TS 25.331 [23c].

At inter-system change from S1 mode to A/Gb mode, if a GEA algorithm is taken into use that requires a 64-bit long ciphering key, then an ME shall apply the derived GPRS GSM ciphering key.

At inter-system change from S1 mode to A/Gb mode, if a GEA algorithm is taken into use that requires a 128-bit long ciphering key, then an ME shall apply the derived GPRS GSM Kc128 that was derived by the ME from the derived UMTS security keys (see subclause 4.7.7.3a).

NOTE 2: For the case in table 4.7.7.10.2, because of deriving a new UMTS security context for the PS domain, a new GPRS GSM ciphering key needs to be derived from the new derived UMTS security keys (i.e. CK’ and IK’). The new GPRS GSM ciphering key is also part of the new UMTS security context for the PS domain, and therefore any old GPRS GSM ciphering key stored in the USIM and in the ME belongs to an old UMTS security context for the PS domain and can no longer be taken into use.

Table 4.7.7.10.3/3GPP TS 24.008: Inter-system change from S1 mode to Iu mode or A/Gb mode in idle mode when the TIN indicates "RAT‑related TMSI"

Security context established in MS and network

At inter-system change to Iu mode or A/Gb mode in idle mode when the TIN indicates "RAT‑related TMSI"

UMTS security context

At inter-system change from S1 mode to Iu mode, the ME shall apply the GPRS UMTS ciphering key and the GPRS UMTS integrity key that were received from the UMTS security context for the PS domain created in the USIM during the latest successful authentication procedure.

At inter-system change from S1 mode to A/Gb mode, if a GEA algorithm is taken into use that requires a 64-bit long ciphering key, then an ME shall apply the GPRS GSM ciphering key that was received from the GSM security context created in the SIM/USIM during the latest successful authentication procedure.

At inter-system change from S1 mode to A/Gb mode, if a GEA algorithm is taken into use that requires a 128-bit long ciphering key, then an ME shall apply the GPRS GSM Kc128 derived by the ME from the GPRS UMTS ciphering key and the GPRS UMTS integrity key (see 3GPP TS 33.102 [5a]) provided by the USIM during the lastest successful authentication procedure (see subclause 4.7.7.3a).

The network shall replace an already established UMTS security context for the PS domain, if any, when a handover from S1mode to Iu mode or from S1mode to A/Gb mode has been completed successfully.

If the handover from S1mode to Iu mode or S1mode to A/Gb mode has not been completed successfully, the ME and the network shall delete the new derived UMTS security context for the PS domain. Additionally, the network shall delete the already established UMTS security context for the PS domain, if the CKSN of the already established UMTS security context is equal to the CKSN of the new derived security context for the PS domain.