D.3 Subscriber identity authentication

3GPP43.020Release 17Security related network functionsTS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

D.3.1 Generality

The definition and operational requirements of subscriber identity authentication are given in 3GPP TS 42.009.

The authentication procedure may be performed at any time by the network.

The authentication procedure will also be used to set the ciphering key (see clause D.4). Therefore, it is performed after the subscriber identity (TLLI/IMSI) is known by the network for the management of new ciphering.

Two network functions are necessary: the authentication procedure itself, and the key management.

D.3.2 The authentication procedure

The authentication procedure is described in subclause 3.2.

D.3.3 Subscriber Authentication Key management

The management of Subscriber Authentication Key (Ki) is described in subclause 3.3.

D.3.3.1 General authentication procedure

When needed, the SGSN requests security related information for a MS from the HLR/AuC corresponding to the IMSI of the MS. This includes an array of pairs of corresponding RAND and SRES. These pairs are obtained by applying Algorithm A3 to each RAND and the key Ki as shown in figure 3.1. The pairs are stored in the SGSN as part of the security related information.

The procedure used for updating the vectors RAND/SRES is schematised in figure D.3.2.

NOTE: The Authentication Vector Response contains also GPRS-Kc(1..n) which is not shown in this and the following figures. For discussion of GPRS-Kc see clause D.4.

SGSN

HLR/AuC

Security Related Information Req(IMSI)

generate

RAND(1..n)

Authentication Vector Response

(SRES(1..n), RAND(1..n))

Store RAND/SRES

vectors

Figure D.3.2: Procedure for updating the vectors RAND/SRES

When an SGSN performs an authentication, including the case of a routing area updating within the same SGSN area, it chooses a RAND value in the array corresponding to the MS. It then tests the answer from the MS by comparing it with the corresponding SRES, as schematised in figure D.3.3.

SGSN

RAND(j)

SRES(j)

RAND(j)

SRES(j)

yes/no

Figure D.3.3: General authentication procedure

D.3.3.2 Authentication at routing area updating in a new SGSN, using TLLI

During routing area updating in a new SGSN (SGSNn), the procedure to get pairs for subsequent authentication may differ from that described in the previous subclause. In the case when identification is done using TLLI, pairs for authentication as part of security related information are given by the old SGSN (SGSNo). The old SGSN shall send to the new SGSN only those pairs which have not been used. SGSNn may also request the triplets directly from HLR.

The procedure is schematised in figure D.3.4.

SGSNn

SGSNo

HPLMN

RAI, TLLIo

TLLIo, RAI

IMSI

RAND(1..n)

SRES(1..n)

RAND

V V

SRES

yes/no

Update Location

Figure D.3.4: Authentication at routing area updating in a new SGSN, using TLLI

D.3.3.3 Authentication at routing area updating in a new SGSN, using IMSI

When the IMSI is used for identification, or more generally when the old SGSN is not reachable, the procedure described in subclause D.3.3.2 cannot be used. Instead, pairs of RAND/SRES contained in the security related information are requested directly from the HPLMN.

The procedure is schematised in figure D.3.5.

SGSNn

HPLMN

IMSI

Sec. Rel. Info Req.

(IMSI)

RAND(1,..n)

RAND

SRES(1..n)

V V

SRES

yes/no

Update Location

Figure D.3.5: Authentication at routing area updating in a new SGSN, using IMSI

D.3.3.4 Authentication at routing area updating in a new SGSN, using TLLI, TLLI unknown in ‘old’ SGSN

This case is an abnormal one, when a data loss has occurred in the ‘old’ SGSN.

The procedure is schematised in figure D.3.6.

SGSNn

SGSNo

HPLMN

RAI, TLLIo

Unknown

TLLI Unknown

IMSI

Sec. Rel. Info Req.

(IMSI)

RAND(1..n) SRES(1..n)

RAND

V V

SRES

yes/no

Update Location

Figure D.3.6: Authentication at routing area updating in a new SGSN, using TLLI, TLLI unknown in ‘old’ SGSN

D.3.3.5 Authentication at routing area updating in a new SGSN, using TLLI, old SGSN not reachable

The case occurs when an old SGSN cannot be reached by the new SGSN.

The procedure is schematised in figure D.3.7

SGSNn

SGSNo

HPLMN

RAI, TLLIo

SGSNo not

reachable

TLLI Unknown

IMSI

Sec. Rel. Info Req.

(IMSI)

RAND(1..n) SRES(1..n)

RAND

V V

SRES

yes/no

Update Location

Figure D.3.7: Authentication at routing area updating in a new SGSN, using TLLI, old SGSN not reachable

D.3.3.6 Authentication with IMSI if authentication with TLLI fails

If authentication of an MS which identifies itself with a TLLI is unsuccessful, the network requests the IMSI from the MS, and repeats the authentication using the IMSI. Optionally, if authentication using the TLLI fails the network may reject the access request or location registration request which triggered the authentication.

D.3.3.7 Re-use of security related information in failure situations

Security related information consisting of sets of RAND, SRES and a ciphering key (GPRS-Kc) is stored in the SGSN and in the HLR.

When a SGSN has used a set of security related information to authenticate an MS, it shall delete the set of security related information or mark it as used. When a SGSN needs to use security related information, it shall use a set which is not marked as used in preference to a set which is marked as used; if there are no sets which are not marked as used then the SGSN shall request fresh security related information from the HLR. If a set of fresh security related information cannot be obtained in this case because of a system failure, the SGSN may re-use a set which is marked as used.

“System failure” in this context means that the SGSN was unable to establish contact with the HLR, or the HLR returned a positive acknowledgement containing no sets of security related information, or the HLR returned an error indicating that there was a system failure or that the request was badly formatted.

If the HLR responds to a request for security related information with an indication that the subscriber is unknown or barred in the HLR, the SGSN shall not re-use security information which has been marked as used.

It is an operator option to define how many times a set of security related information may be re-used in the SGSN; when a set of security related information has been re-used as many times as is permitted by the operator, it shall be deleted.

If a SGSN successfully requests security related information from the HLR, it shall discard any security related information which is marked as used in the SGSN.

If a SGSN receives from another SGSN a request for security related information, it shall send only the sets which are not marked as used.

If an HLR receives a request for security related information, it shall send any sets which are not marked as used; those sets shall then be deleted or marked as used. If there are no sets which are not marked as used, the HLR may as an operator option send sets which are marked as used. It is an operator option to define how many times a set of security related information may be re-sent by the HLR; when a set of security related information has been sent as many times as is permitted by the operator, it shall be deleted.