D.2 Subscriber identity confidentiality

3GPP43.020Release 17Security related network functionsTS

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

D.2.1 Generality

The purpose of this function is to avoid the possibility for an intruder to identify which subscriber is using a given resource on the radio path by listening to the signalling exchanges or the user traffic on the radio path. This allows both a high level of confidentiality for user data and signalling and protection against the tracing of users location.

The provision of this function implies that the IMSI (International Mobile Subscriber Identity), or any information allowing a listener to derive the IMSI easily, should not normally be transmitted in clear text in any signalling message on the radio path.

Consequently, to obtain the required level of protection, it is necessary that:

– a protected identifying method is normally used instead of the IMSI on the radio path;

– the IMSI is not normally used as addressing means on the radio path (see 3GPP TS 42.009);

– when the signalling procedures permit it, signalling information elements that convey information about the mobile subscriber identity must be ciphered for transmission on the radio path.

The identifying method is specified in the following subclause. The ciphering of communication over the radio path is specified in clause D.4.

Furthermore, Anonymous Access allows a user to access the network without a subscriber identity (see 3GPP TS 23.060). Therefore, Anonymous Access always guarantees by its nature subscriber identity confidentiality. The following parts of the clause D.2 are not applicable for Anonymous Access.

D.2.2 Identifying method

The means used to identify a mobile subscriber on the radio path consists of a Temporary Logical Link Identity (TLLI). This TLLI is a local number, having a meaning only in a given RA (Routing Area); the TLLI must be accompanied by the Routing Area Identity (RAI) to avoid ambiguities. The maximum length and guidance for defining the format of a TLLI are specified in 3GPP TS 23.003.

The SGSN manages suitable data bases to keep the relation between TLLIs and IMSIs. When a TLLI is received with an RAI that does not correspond to the current SGSN, the IMSI of the MS must be requested from the SGSN in charge of the indicated routing area if its address is known; otherwise the IMSI is requested from the MS.

A new TLLI may be allocated in each routing area updating procedure. The allocation of a new TLLI corresponds implicitly for the MS to the de-allocation of the previous one. In the fixed part of the network, the cancellation of the record for an MS in a SGSN implies the de-allocation of the corresponding TLLI.

To cope with some malfunctioning, e.g. arising from a software failure, the fixed part of the network can require the identification of the MS in clear. This procedure is a breach in the provision of the service, and should be used only when necessary.

When a new TLLI is allocated to an MS, it is transmitted to the MS in a ciphered mode. This ciphered mode is the same as defined in clause D.4.

The MS must store its current TLLI in a non volatile memory, together with the RAI, so that these data are not lost when the MS is switched off.

D.2.3 Procedures

This subclause presents the procedures, or elements of procedures, pertaining to the management of TLLIs.

These security procedures may also be applied between two PLMNs of different operators for seamless service when the PLMN is changed.

D.2.3.1 Routing area updating in the same SGSN area

This procedure is part of the routing area updating procedure which takes place when the original routing area and the new routing area depend on the same SGSN. The part of this procedure relative to TLLI management is reduced to a TLLI re-allocation (from TLLIo with "o" for "old" to TLLIn with "n" for "new").

The MS sends TLLIo as an identifying field at the beginning of the routing area updating procedure.

The procedure is schematised in figure D.2.1.

SGSN

RAI, TLLIo

Allocation

of TLLIn

Ciphered(TLLIn)

Acknowledge

De-allocation

of TLLIo

Figure D.2.1: Routing area updating in the same SGSN area

D.2.3.2 Routing area updating in a new SGSN; old SGSN reachable

This procedure is part of the routing area updating procedure, using TLLI and RAI, when the original routing area and the new routing area depend on different SGSNs.

The MS is still registered in SGSNo ("o" for old or original) and requests registration in SGSNn ("n" for new). RAI and TLLIo are sent by the MS as identifying fields during the routing area updating procedure. The Routing Area Update Request is not ciphered to allow the new SGSN to read RAI and TLLIo.

The procedure is schematised in figure D.2.2.

SGSNn

SGSNo

HPLMN

RAI, TLLIo

RAI,TLLIo

IMSI

Sec.Rel.Inf

Allocation

of TLLIn

Ciphered(TLLIn) (note)

Update Loc. (note)

Acknowledge (note)

Cancellation

De-allocation

of TLLIo

NOTE: From a security point of view, the order of the procedures is irrelevant.

Figure D.2.2: Routing area updating in a new SGSN; old SGSN reachable

Signalling functionalities:

Update Loc. stands for Update Location

The new SGSN informs the HLR that it is now handling the MS.

Sec.Rel.Info.:

Stands for Security Related information

The SGSNn needs some information for authentication and ciphering; this information is obtained from SGSNo.

Cancellation:

The HLR indicates to SGSNo that the MS is now under control of another SGSN. The "old" TLLI is free for allocation.

D.2.3.3 Routing area updating in a new SGSN; old SGSN not reachable

This variant of the procedure in subclause D.2.3.2 arises when the SGSN receiving the RAI and TLLIo cannot identify the SGSNo. In that case the relation between TLLIo and IMSI is lost, and the identification of the MS in clear is necessary.

The procedure is schematised in figure D.2.3.

SGSNn

SGSNo

HPLMN

RAI, TLLIo

old SGSN not

reachable

TLLI unknown (note 1)

IMSI (note 1)

Management of means for new

ciphering (see clause D4)

Allocation

of TLLIn

Ciphered(TLLIn) (note 2)

Update Loc. (note 2)

Acknowledge (note 2)

Cancellation

De-allocation

of TLLIo

NOTE 1: From a security point of view, the exact signalling messages (described in 3GPP TS 23.060) used to indicate that the TLLI is unknown, or to send the IMSI are irrelevant.

NOTE 2: From a security point of view, the order of the procedures is irrelevant.

Figure D.2.3: Routing area updating in a new SGSN; old SGSN not reachable

D.2.3.4 Reallocation of a TLLI

This function may be initiated by the network at any time for a GPRS attached MS. The procedure can be included in other procedures, e.g. through the means of optional parameters. The execution of this function is left to the network operator.

When a new TLLI is allocated to an MS the network must prevent the old TLLI from being allocated again until the MS has acknowledged the allocation of the new TLLI.

If an MM context of an MS is deleted in the SGSN by O&M action, the network must prevent any TLLI associated with the deleted MM context from being allocated again until a new TLLI is successfully allocated to that IMSI.

If an IMSI record is deleted in the HLR by O&M action, it is not possible to prevent any TLLI associated with the IMSI record from being allocated again. However, if the MS whose IMSI record was deleted should attempt to access the network using the TLLI after the TLLI has been allocated to a different IMSI, then authentication or ciphering of the MS whose IMSI was deleted will fail, which will cause the TLLI to be deleted from the MS.

The case where allocation of a new TLLI is unsuccessful is described in subclause D.2.3.7.

This procedure is schematised in figure D.2.4.

SGSN

Allocation

of TLLIn

Ciphered(TLLIn)

Acknowledge

De-allocation

of TLLIo

Figure D.2.4: Reallocation of a new TLLI

D.2.3.5 Local TLLI unknown

This procedure is a variant of the procedure described in subclauses D.2.3.1 and happens when a data loss has occurred in a SGSN and when a MS uses an unknown TLLI, e.g. for a communication request or for a routing area updating request in a routing area managed by the same SGSN. The SGSN indicates to the MS that the TLLI is unknown and and the identification of the MS in clear is necessary.

This procedure is schematised in figure D.2.5.

SGSN

HPLMN

RAI, TLLIo (note 1)

TLLIo is

unknown

TLLI unknown (note 2)

IMSI (note 2)

Management of means for new

ciphering (see clause D4)

Allocation

of TLLIn

Ciphered(TLLIn)

Acknowledge

NOTE 1: Any message in which TLLIo is used as an identifying means in a routing area managed by the same SGSN.

NOTE 2: From a security point of view, the exact signalling messages (described in 3GPP TS 23.060) used to indicate that the TLLI is unknown, or to send the IMSI are irrelevant.

Figure D.2.5: Routing area updating in the same SGSN area; local TLLI unknown

D.2.3.6 Routing area updating in a new SGSN in case of a loss of information

This variant of the procedure described in D.2.3.2 arises when the SGSN in charge of the MS has suffered a loss of data. In that case the relation between TLLIo and IMSI is lost, and the identification of the MS in clear is necessary.

The procedure is schematised in figure D.2.6.

SGSNn

SGSNo

HPLMN

RAI, TLLIo

RAI,TLLIo

Unknown

TLLI Unknown(note 1)

IMSI(note 1)

Management of means for new

ciphering (see clause D4)

Allocation

of TLLIn

Ciphered(TLLIn) (note 2)

Update location (note 2)

Acknowledge (note 2)

Cancellation

De-allocation

of TLLIo

NOTE 1: From a security point of view, the exact signalling messages (described in 3GPP TS 23.060) used to indicate that the TLLI is unknown, or to send the IMSI are irrelevant.

NOTE 2: From a security point of view, the order of the procedures is irrelevant.

Figure D.2.6: Routing area updating in a new SGSN in case of a loss of information

D.2.3.7 Unsuccessful TLLI allocation

If the MS does not acknowledge the allocation of a new TLLI, the network shall maintain the association between the old TLLI and the IMSI and between the new TLLI and the IMSI.

For an MS-originated transaction, the network shall allow the MS to identify itself by either the old TLLI or the new TLLI. This will allow the network to determine the TLLI stored in the MS; the association between the other TLLI and the IMSI shall then be deleted.

For a network-originated transaction, the network shall identify the MS by its IMSI. When radio contact has been established, the network shall instruct the MS to delete any stored TLLI. When the MS has acknowledged this instruction, the network shall delete the association between the IMSI of the MS and any TLLI.

In either of the cases above, the network may initiate the normal TLLI reallocation procedure.

Repeated failure of TLLI reallocation (passing a limit set by the operator) may be reported for O&M action.