3GPP43.020Release 16Security related network functionsTS
The definition and operational requirements of subscriber identity authentication are given in 3GPP TS 42.009.
The authentication procedure will also be used to set the ciphering key (see clause 4). Therefore, it is performed after the subscriber identity (TMSI/IMSI) is known by the network and before the channel is encrypted.
Two network functions are necessary: the authentication procedure itself, and the key management inside the fixed subsystem.
3.2 The authentication procedure
The authentication procedure consists of the following exchange between the fixed subsystem and the MS.
– The fixed subsystem transmits a non-predictable number RAND to the MS.
– The MS computes the signature of RAND, say SRES, using algorithm A3 and some secret information: the Individual Subscriber Authentication Key, denoted below by Ki.
– The MS transmits the signature SRES to the fixed subsystem.
– The fixed subsystem tests SRES for validity.
The general procedure is schematized in figure 3.1.
NOTE: IMSI is used to retrieve Ki in the network.
Figure 3.1: The authentication procedure
Authentication algorithm A3 is specified in annex C.
3.3 Subscriber Authentication Key management
The Subscriber Authentication Key Ki is allocated, together with the IMSI, at subscription time.
Ki is stored on the network side in the Home Public Land Mobile Network (HPLMN), in an Authentication Centre (AuC). A PLMN may contain one or more AuC. An AuC can be physically integrated with other functions, e.g. in a Home Location Register (HLR).
3.3.1 General authentication procedure
When needed for each MS, the BSS/MSC/VLR requests security related information from the HLR/AuC corresponding to 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 VLR as part of the security related information.
The procedure used for updating the vectors RAND/SRES is schematized in figure 3.2.
NOTE: The Authentication Vector Response contains also Kc(1..n) which is not shown in this and the following figures. For discussion of Kc see clause 4.
Figure 3.2: Procedure for updating the vectors RAND/SRES
When an MSC/VLR performs an authentication, including the case of a location updating within the same VLR 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 schematized in figure 3.3.
Figure 3.3: General authentication procedure
3.3.2 Authentication at location updating in a new VLR, using TMSI
During location updating in a new VLR (VLRn), 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 TMSI, pairs for authentication as part of security related information are given by the old VLR (VLRo). The old VLR shall send to the new VLR only those pairs which have not been used.
The procedure is schematized in figure 3.4.
Figure 3.4: Authentication at location updating in a new VLR, using TMSI
3.3.3 Authentication at location updating in a new VLR, using IMSI
When the IMSI is used for identification, or more generally when the old VLR is not reachable, the procedure described in subclause 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 schematized in figure 3.5.
Figure 3.5: Authentication at location updating in a new VLR, using IMSI
3.3.4 Authentication at location updating in a new VLR, using TMSI, TMSI unknown in "old" VLR
This case is an abnormal one, when a data loss has occurred in the "old" VLR.
The procedure is schematized in figure 3.6.
Figure 3.6: Authentication at location updating in a new VLR, using TMSI,
TMSI unknown in "old" VLR
3.3.5 Authentication at location updating in a new VLR, using TMSI, old VLR not reachable
The case occurs when an old VLR cannot be reached by the new VLR.
The procedure is schematized in figure 3.7
Figure 3.7: Authentication at location updating in a new VLR, using TMSI, old VLR not reachable
3.3.6 Authentication with IMSI if authentication with TMSI fails
If authentication of an MS which identifies itself with a TMSI is unsuccessful, the network requests the IMSI from the MS, and repeats the authentication using the IMSI. Optionally, if authentication using the TMSI fails the network may reject the access request or location registration request which triggered the authentication.
3.3.7 Re-use of security related information in failure situations
Security related information consisting of sets of RAND, SRES and Kc is stored in the VLR and in the HLR.
When a VLR 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 VLR 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 VLR 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 VLR may re-use a set which is marked as used.
“System failure” in this context means that the VLR 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 VLR 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 VLR; 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 VLR successfully requests security related information from the HLR, it shall discard any security related information which is marked as used in the VLR.
If a VLR receives from another VLR 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.