Tech-invite3GPPspecsSIPRFCs
Overview21222324252627282931323334353637384‑5x

Content for  TS 33.501  Word version:  16.3.0

Top   Top   Up   Prev   Next
1…   4…   5…   6…   6.2…   6.3…   6.5…   6.8…   6.9…   6.10…   6.12…   6.14   6.15   6.16   7…   7A…   7B…   8…   9…   10…   11…   13…   13.3…   13.4…   14…   15…   A…   B…   C…   D…   G…   K…   O…

 

6  Security procedures between UE and 5G network functions

6.0  General

When the UE is capable of connecting to 5GC and EPC and connected to an ng-eNB which is connected to both EPC and 5GC, the UE has the ability to select which core network to connect to as described in clause 4.8.4 in TS 24.501. If the UE selects the EPC, the UE shall use security procedure as in TS 33.401. Otherwise, if the UE selects 5GC, the UE shall use the security procedures as per this document.
For an ng-eNB which can connect to EPC and 5GC, the ng-eNB shall choose the corresponding security procedures based on the UE selected type of core netowrk, i.e., when EPC is selected, the ng-eNB shall use security procedures as described in TS 33.401. On the other hand, when 5GC is selected, the ng-eNB shall use security procedures as described in this document.
Up

6.1  Primary authentication and key agreement

6.1.1  Authentication framework

6.1.1.1  General

The purpose of the primary authentication and key agreement procedures is to enable mutual authentication between the UE and the network and provide keying material that can be used between the UE and the serving network in subsequent security procedures. The keying material generated by the primary authentication and key agreement procedure results in an anchor key called the K SEAF provided by the AUSF of the home network to the SEAF of the serving network.
Keys for more than one security context can be derived from the K SEAF without the need of a new authentication run. A concrete example of this is that an authentication run over a 3GPP access network can also provide keys to establish security between the UE and a N3IWF used in untrusted non-3GPP access.
The anchor key K SEAF is derived from an intermediate key called the K AUSF. The K AUSF may be securely stored in the AUSF based on the home operator's policy on using such key.
UE and serving network shall support EAP-AKA' and 5G AKA authentication methods.
The USIM shall reside on a UICC. The UICC may be removable or non-removable.
If the terminal supports 3GPP access capabilities, the credentials used with EAP-AKA' and 5G AKA for non-3GPP access networks shall reside on the UICC.
Up

6.1.1.2  EAP frameworkWord‑p. 38
The EAP framework is specified in RFC 3748. It defines the following roles: peer, pass-through authenticator and back-end authentication server. The back-end authentication server acts as the EAP server, which terminates the EAP authentication method with the peer. In the 5G system, the EAP framework is supported in the following way:
  • The UE takes the role of the peer.
  • The SEAF takes the role of pass-through authenticator.
  • The AUSF takes the role of the backend authentication server.
Up

6.1.1.3  Granularity of anchor key binding to serving network

The primary authentication and key agreement procedures shall bind the K SEAF to the serving network. The binding to the serving network prevents one serving network from claiming to be a different serving network, and thus provides implicit serving network authentication to the UE.
This implicit serving network authentication shall be provided to the UE irrespective of the access network technology, so it applies to both 3GPP and non-3GPP access networks.
Furthermore, the anchor key provided to the serving network shall also be specific to the authentication having taken place between the UE and a 5G core network, i.e. the K SEAF shall be cryptographically separate from the key K ASME delivered from the home network to the serving network in earlier mobile network generations.
The anchor key binding shall be achieved by including a parameter called "serving network name" into the chain of key derivations that leads from the long-term subscriber key to the anchor key.
The value of serving network name is defined in subclause 6.1.1.4 of the present document.
The chain of key derivations that leads from the long-term subscriber key to the anchor key is specified in subclause 6.1.3 of the present document for each (class) of authentication methods. The key derivation rules are specified in Annex A.
Up

6.1.1.4  Construction of the serving network name

6.1.1.4.1  Serving network name
The serving network name is used in the derivation of the anchor key. It serves a dual purpose, namely:
  • It binds the anchor key to the serving network by including the serving network identifier (SN Id).
  • It makes sure that the anchor key is specific for authentication between a 5G core network and a UE by including a service code set to "5G".
In 5G AKA, the serving network name has a similar purpose of binding the RES* and XRES* to the serving network.
The serving network name is the concatenation of a service code and the SN Id with a separation character ":" such that the service code prepends the SN Id.
The SN Id identifies the serving PLMN and, except for standalone non-public networks, is defined as SNN-network-identifier in TS 24.501.
Up
6.1.1.4.2  Construction of the serving network name by the UEWord‑p. 39
The UE shall construct the serving network name as follows:
  • It shall set the service code to "5G".
  • It shall set the network identifier to the SN Id of the network that it is authenticating to.
  • Concatenate the service code and the SN Id with the separation character ":".
6.1.1.4.3  Construction of the serving network name by the SEAF
The SEAF shall construct the serving network name as follows:
  • It shall set the service code to "5G".
  • It shall set the network identifier to the SN Id of the serving network to which the authentication data is sent by the AUSF.
  • It shall concatenate the service code and the SN Id with the separation character ":".

6.1.2  Initiation of authentication and selection of authentication method

The initiation of the primary authentication is shown in Figure 6.1.2-1.
Reproduction of 3GPP TS 33.501, Figure 6.1.2-1: Initiation of authentication procedure and selection of authentication method
Up
The SEAF may initiate an authentication with the UE during any procedure establishing a signalling connection with the UE, according to the SEAF's policy. The UE shall use SUCI or 5G-GUTI in the Registration Request.
The SEAF shall invoke the Nausf_UEAuthentication service by sending a Nausf_UEAuthentication_Authenticate Request message to the AUSF whenever the SEAF wishes to initiate an authentication.
The Nausf_UEAuthentication_Authenticate Request message shall contain either:
  • SUCI, as defined in the current specification, or
  • SUPI, as defined in TS 23.501.
The SEAF shall include the SUPI in the Nausf_UEAuthentication_Authenticate Request message in case the SEAF has a valid 5G-GUTI and re-authenticates the UE. Otherwise the SUCI is included in Nausf_UEAuthentication_Authenticate Request. SUPI/SUCI structure is part of stage 3 protocol design.
The Nausf_UEAuthentication_Authenticate Request shall furthermore contain:
Upon receiving the Nausf_UEAuthentication_Authenticate Request message, the AUSF shall check that the requesting SEAF in the serving network is entitled to use the serving network name in the Nausf_UEAuthentication_Authenticate Request by comparing the serving network name with the expected serving network name. The AUSF shall store the received serving network name temporarily. If the serving network is not authorized to use the serving network name, the AUSF shall respond with "serving network not authorized" in the Nausf_UEAuthentication_Authenticate Response.
The Nudm_UEAuthentication_Get Request sent from AUSF to UDM includes the following information:
  • SUCI or SUPI;
  • the serving network name;
Upon reception of the Nudm_UEAuthentication_Get Request, the UDM shall invoke SIDF if a SUCI is received. SIDF shall de-conceal SUCI to gain SUPI before UDM can process the request.
Based on SUPI, the UDM/ARPF shall choose the authentication method.
Up

6.1.3  Authentication proceduresWord‑p. 40

6.1.3.1  Authentication procedure for EAP-AKA'

EAP-AKA' is specified in RFC 5448. The 3GPP 5G profile for EAP-AKA' is specified in the normative Annex F.
Editor's Note: The reference to RFC 5448 will be superseded by the internet draft referred to in [67] when it becomes an RFC.
The selection of using EAP-AKA' is described in subclause 6.1.2 of the present document.
Reproduction of 3GPP TS 33.501, Figure 6.1.3.1-1: Authentication procedure for EAP-AKA'
Up
The authentication procedure for EAP-AKA' works as follows, cf. also Figure 6.1.3.1-1:
Step 1.
The UDM/ARPF shall first generate an authentication vector with Authentication Management Field (AMF) separation bit = 1 as defined in TS 33.102. The UDM/ARPF shall then compute CK' and IK' as per the normative Annex A and replace CK and IK by CK' and IK'.
Step 2.
The UDM shall subsequently send this transformed authentication vector AV' (RAND, AUTN, XRES, CK', IK') to the AUSF from which it received the Nudm_UEAuthentication_Get Request together with an indication that the AV' is to be used for EAP-AKA' using a Nudm_UEAuthentication_Get Response message.
In case SUCI was included in the Nudm_UEAuthentication_Get Request, UDM will include the SUPI in the Nudm_UEAuthentication_Get Response.
The AUSF and the UE shall then proceed as described in RFC 5448 [12] until the AUSF is ready to send the EAP-Success.
If a subscriber has an AKMA subscription, the UDM shall include the AKMA indication in the Nudm_UEAuthentication_Get Response.
Step 3.
The AUSF shall send the EAP-Request/AKA'-Challenge message to the SEAF in a Nausf_UEAuthentication_Authenticate Response message.
Step 4.
The SEAF shall transparently forward the EAP-Request/AKA'-Challenge message to the UE in a NAS message Authentication Request message. The ME shall forward the RAND and AUTN received in EAP-Request/AKA'-Challenge message to the USIM. This message shall include the ngKSI and ABBA parameter. In fact, SEAF shall include the ngKSI and ABBA parameter in all EAP-Authentication request message. ngKSI will be used by the UE and AMF to identify the partial native security context that is created if the authentication is successful. The SEAF shall set the ABBA parameter as defined in Annex A.7.1. During an EAP authentication, the value of the ngKSI and the ABBA parameter sent by the SEAF to the UE shall not be changed.
Step 5.
At receipt of the RAND and AUTN, the USIM shall verify the freshness of the AV' by checking whether AUTN can be accepted as described in TS 33.102. If so, the USIM computes a response RES. The USIM shall return RES, CK, IK to the ME. If the USIM computes a Kc (i.e. GPRS Kc) from CK and IK using conversion function c3 as described in TS 33.102, and sends it to the ME, then the ME shall ignore such GPRS Kc and not store the GPRS Kc on USIM or in ME. The ME shall derive CK' and IK' according to Annex A.3.
If the verification of the AUTN fails on the USIM, then the USIM and ME shall proceed as described in subclause 6.1.3. 3.
Step 6.
The UE shall send the EAP-Response/AKA'-Challenge message to the SEAF in a NAS message Auth-Resp message.
Step 7.
The SEAF shall transparently forward the EAP-Response/AKA'-Challenge message to the AUSF in Nausf_UEAuthentication_Authenticate Request message.
Step 8.
The AUSF shall verify the message, and if the AUSF has successfully verified this message it shall continue as follows, otherwise it shall return an error to the SEAF. AUSF shall inform UDM about the authentication result (see subclause 6.1.4 of the present document for details on linking authentication confirmation).
Step 9.
The AUSF and the UE may exchange EAP-Request/AKA'-Notification and EAP-Response /AKA'-Notification messages via the SEAF. The SEAF shall transparently forward these messages.
Step 10.
The AUSF derives EMSK from CK' and IK' as described in RFC 5448 [12] and Annex F. The AUSF uses the most significant 256 bits of EMSK as the K AUSF and then calculates K SEAF from K AUSF as described in clause A.6. The AUSF shall send an EAP Success message to the SEAF inside Nausf_UEAuthentication_Authenticate Response, which shall forward it transparently to the UE. Nausf_UEAuthentication_Authenticate Response message contains the K SEAF. If the AUSF received a SUCI from the SEAF when the authentication was initiated (see subclause 6.1.2 of the present document), then the AUSF shall also include the SUPI in the Nausf_UEAuthentication_Authenticate Response message.
Step 11.
The SEAF shall send the EAP Success message to the UE in the N1 message. This message shall also include the ngKSI and the ABBA parameter. The SEAF shall set the ABBA parameter as defined in Annex A.7.1.
The key received in the Nausf_UEAuthentication_Authenticate Response message shall become the anchor key, K SEAF in the sense of the key hierarchy in subclause 6.2 of the present document. The SEAF shall then derive the K AMF from the K SEAF, the ABBA parameter and the SUPI according to Annex A.7 and send it to the AMF. On receiving the EAP-Success message, the UE derives EMSK from CK' and IK' as described in RFC 5448 and Annex F. The ME uses the most significant 256 bits of the EMSK as the K AUSF and then calculates K SEAF in the same way as the AUSF. The UE shall derive the K AMF from the K SEAF, the ABBA parameter and the SUPI according to Annex A.7.
The further steps taken by the AUSF upon receiving a successfully verified EAP-Response/AKA'-Challenge message are described in subclause 6.1.4 of the present document.
If the EAP-Response/AKA'-Challenge message is not successfully verified, the subsequent AUSF behaviour is determined according to the home network's policy.
If AUSF and SEAF determine that the authentication was successful, then the SEAF provides the ngKSI and the K AMF to the AMF.
Up

6.1.3.2  Authentication procedure for 5G AKAWord‑p. 43
6.1.3.2.0  5G AKA
5G AKA enhances EPS AKA [10] by providing the home network with proof of successful authentication of the UE from the visited network. The proof is sent by the visited network in an Authentication Confirmation message.
The selection of using 5G AKA is described in subclause 6.1.2 of the present document.
Reproduction of 3GPP TS 33.501, Figure 6.1.3.2-1: Authentication procedure for 5G AKA
Up
The authentication procedure for 5G AKA works as follows, cf. also Figure 6.1.3.2-1:
Step 1.
For each Nudm_Authenticate_Get Request, the UDM/ARPF shall create a 5G HE AV. The UDM/ARPF does this by generating an AV with the Authentication Management Field (AMF) separation bit set to "1" as defined in TS 33.102. The UDM/ARPF shall then derive K AUSF (as per Annex A.2) and calculate XRES* (as per Annex A.4). Finally, the UDM/ARPF shall create a 5G HE AV from RAND, AUTN, XRES*, and K AUSF.
Step 2.
The UDM shall then return the 5G HE AV to the AUSF together with an indication that the 5G HE AV is to be used for 5G-AKA in a Nudm_UEAuthentication_Get Response. In case SUCI was included in the Nudm_UEAuthentication_Get Request, UDM will include the SUPI in the Nudm_UEAuthentication_Get Response.
If a subscriber has an AKMA subscription, the UDM shall include the AKMA indication in the Nudm_UEAuthentication_Get Response.
Step 3.
The AUSF shall store the XRES* temporarily together with the received SUCI or SUPI. 4. The AUSF shall then generate the 5G AV from the 5G HE AV received from the UDM/ARPF by computing the HXRES* from XRES* (according to Annex A.5) and K SEAF from K AUSF(according to Annex A.6), and replacing the XRES* with the HXRES* and K AUSF with K SEAF in the 5G HE AV.
Step 5.
The AUSF shall then remove the K SEAF return the 5G SE AV (RAND, AUTN, HXRES*) to the SEAF in a Nausf_UEAuthentication_Authenticate Response.
Step 6.
The SEAF shall send RAND, AUTN to the UE in a NAS message Authentication -Request. This message shall also include the ngKSI that will be used by the UE and AMF to identify the K AMF and the partial native security context that is created if the authentication is successful. This message shall also include the ABBA parameter. The SEAF shall set the ABBA parameter as defined in Annex A.7.1. The ME shall forward the RAND and AUTN received in NAS message Authentication Request to the USIM.
Step 7.
At receipt of the RAND and AUTN, the USIM shall verify the freshness of the 5G AV by checking whether AUTN can be accepted as described in TS 33.102. If so, the USIM computes a response RES. The USIM shall return RES, CK, IK to the ME. If the USIM computes a Kc (i.e. GPRS Kc) from CK and IK using conversion function c3 as described in TS 33.102, and sends it to the ME, then the ME shall ignore such GPRS Kc and not store the GPRS Kc on USIM or in ME. The ME then shall compute RES* from RES according to Annex A.4. The ME shall calculate K AUSF from CK||IK according to clause A.2. The ME shall calculate K SEAF from K AUSF according to clause A.6. An ME accessing 5G shall check during authentication that the "separation bit" in the AMF field of AUTN is set to 1. The "separation bit" is bit 0 of the AMF field of AUTN.
Step 8.
The UE shall return RES* to the SEAF in a NAS message Authentication Response.
Step 9.
The SEAF shall then compute HRES* from RES* according to Annex A.5, and the SEAF shall compare HRES* and HXRES*. If they coincide, the SEAF shall consider the authentication successful from the serving network point of view. If not, the SEAF proceed as described in subclause 6.1.3.2.2. If the UE is not reached, and the RES* is never received by the SEAF, the SEAF shall consider authentication as failed, and indicate a failure to the AUSF.
Step 10.
The SEAF shall send RES*, as received from the UE, in a Nausf_UEAuthentication_Authenticate Request message to the AUSF.
Step 11.
When the AUSF receives as authentication confirmation the Nausf_UEAuthentication_Authenticate Request message including a RES* it may verify whether the AV has expired. If the AV has expired, the AUSF may consider the authentication as unsuccessful from the home network point of view. Upon successful authentication, the AUSF shall store the K AUSF. AUSF shall compare the received RES* with the stored XRES*. If the RES* and XRES* are equal, the AUSF shall consider the authentication as successful from the home network point of view.AUSF shall inform UDM about the authentication result (see subclause 6.1.4 of the present document for linking with the authentication confirmation).
Step 12.
The AUSF shall indicate to the SEAF in the Nausf_UEAuthentication_Authenticate Response whether the authentication was successful or not from the home network point of view. If the authentication was successful, the K SEAF shall be sent to the SEAF in the Nausf_UEAuthentication_Authenticate Response. In case the AUSF received a SUCI from the SEAF in the authentication request (see subclause 6.1.2 of the present document), and if the authentication was successful, then the AUSF shall also include the SUPI in the Nausf_UEAuthentication_Authenticate Response message.
If the authentication was successful, the key K SEAF received in the Nausf_UEAuthentication_Authenticate Response messageshall become the anchor key in the sense of the key hierarchy as specified in subclause 6.2 of the present document. Then the SEAF shall derive the K AMF from the K SEAF, the ABBA parameter and the SUPI according to Annex A.7. The SEAF shall provide the ngKSI and the K AMF to the AMF.
If a SUCI was used for this authentication, then the SEAF shall only provide ngKSI and K AMF to the AMF after it has received the Nausf_UEAuthentication_Authenticate Response message containing SUPI; no communication services will be provided to the UE until the SUPI is known to the serving network.
The further steps taken by the AUSF after the authentication procedure are described in subclause 6.1.4 of the present document.
Up
6.1.3.2.1Void
6.1.3.2.2  RES* verification failure in SEAF or AUSF or bothWord‑p. 45
This clause describes how RES* verification failure in the SEAF or in the AUSF shall be handled.
In step 9 in Figure 6.1.3.2-1, the SEAF shall compute HRES* from RES* according to Annex A.5, and the SEAF shall compare HRES* and HXRES*. If they don't coincide, then the SEAF shall consider the authentication as unsuccessful.
The SEAF shall proceed with step 10 in Figure 6.1.3.2-1 and after receiving the Nausf_UEAuthentication_Authenticate Response message from the AUSF in step 12in Figure 6.1.3.2-1, proceed as described below:
  • If the AUSF has indicated in the Nausf_UEAuthentication_Authenticate Response message to the SEAF that the verification of the RES* was not successful in the AUSF, or
  • if the verification of the RES* was not successful in the SEAF,
then the SEAF shall either reject the authentication by sending an Authentication Reject to the UE if the SUCI was used by the UE in the initial NAS message or the SEAF/AMF shall initiate an Identification procedure with the UE if the 5G-GUTI was used by the UE in the initial NAS message to retrieve the SUCI and an additional authentication attempt may be initiated.
Also, if the SEAF does not receive any Nausf_UEAuthentication_Authenticate Request message from the AUSF as expected, then the SEAF shall either reject the authentication to the UE or initiate an Identification procedure with the UE.
Up

6.1.3.3  Synchronization failure or MAC failure

6.1.3.3.1  Synchronization failure or MAC failure in USIM
This clause describes synchronisation failure or MAC failure in USIM.
In step 7 in Figure 6.1.3.2-1 when 5G AKA is used; or in step 5 in Figure 6.1.3.1-1 when EAP-AKA' is used, at the receipt of the RAND and AUTN, if the verification of the AUTN fails, then the USIM indicates to the ME the reason for failure and in the case of a synchronisation failure passes the AUTS parameter (see TS 33.102) to the ME.
If 5G AKA is used: The ME shall respond with NAS message Authentication Failure with a CAUSE value indicating the reason for failure. In case of a synchronisation failure of AUTN (as described in TS 33.102), the UE also includes AUTS that was provided by the USIM. Upon receipt of an authentication failure message, the AMF/SEAF may initiate new authentication towards the UE. (see TS 24.501).
If EAP-AKA' is used: The ME shall proceed as described in RFC 4187 and RFC 5448 for EAP-AKA'.
Up
6.1.3.3.2  Synchronization failure recovery in Home Network
Upon receiving an authentication failure message with synchronisation failure (AUTS) from the UE, the SEAF sends an Nausf_UEAuthentication_Authenticate Request message with a "synchronisation failure indication" to the AUSF and the AUSF sends an Nudm_UEAuthentication_Get Request message to the UDM/ARPF, together with the following parameters:
  • RAND sent to the UE in the preceding Authentication Request, and
  • AUTS received by the SEAF in the response from the UE to that request, as described in subsection 6.1.3.2.0 and 6.1.3.3.1.
An SEAF will not react to unsolicited "synchronisation failure indication" messages from the UE.
The SEAF does not send new authentication requests to the UE before having received the response to its Nausf_UEAuthentication_Authenticate Request message with a "synchronisation failure indication" from the AUSF (or before it is timed out).
When the UDM/ARPF receives an Nudm_UEAuthentication_Get Request message with a "synchronisation failure indication" it acts as described in TS 33.102, clause 6.3.5 where ARPF is mapped to HE/AuC. The UDM/ARPF sends an Nudm_UEAuthentication_Get Response message with a new authentication vector for either EAP-AKA' or 5G-AKA depending on the authentication method applicable for the user to the AUSF. The AUSF runs a new authentication procedure with the UE according to clauses 6.1.3.1 or 6.1.3.2 depending on the authentication method applicable for the user.
Up

6.1.4  Linking increased home control to subsequent proceduresWord‑p. 46

6.1.4.1  Introduction

The 5G authentication and key agreement protocols provide increased home control. Compared to EPS AKA in EPS, this provides better security useful in preventing certain types of fraud as explained in more detail below.
This increased home control comes in the following forms in 5GS:
  • In the case of EAP-AKA', the AUSF in the home network obtains confirmation that the UE has been successfully authenticated when the EAP-Response/AKA'-Challenge received by the AUSF has been successfully verified, cf. subclause 6.1.3.1 of the present document.
  • In the case of 5G AKA, the AUSF in the home network obtains confirmation that the UE has been successfully authenticated when the authentication confirmation received by the AUSF in Nausf_UEAuthentication_Authenticate Request message has been successfully verified, cf. subclause 6.1.3.2 of the present document.
When 3GPP credentials are used in above cases, the result is reported to the UDM. Details are described in clause 6.1.4.1a.
The feature of increased home control is useful in preventing certain types of fraud, e.g. fraudulent Nudm_UECM_Registration Request for registering the subscriber's serving AMF in UDM that are not actually present in the visited network. But an authentication protocol by itself cannot provide protection against such fraud. The authentication result needs to be linked to subsequent procedures, e.g. the Nudm_UECM_Registration procedure from the AMF in some way to achieve the desired protection.
The actions taken by the home network to link authentication confirmation (or the lack thereof) to subsequent procedures are subject to operator policy and are not standardized.
But informative guidance is given in subclause 6.1.4.2 as to what measures an operator could usefully take. Such guidance may help avoiding a proliferation of different solutions.
Up

6.1.4.1a  Linking authentication confirmation to Nudm_UECM_Registration procedure from AMF

The information sent from the AUSF to the UDM that a successful or unsuccessful authentication of a subscriber has occurred, shall be used to link authentication confirmation to subsequent procedures. The AUSF shall send the Nudm_UEAuthentication_ResultConfirmation service operation for this purpose as shown in figure6.1.4.1a-1.
Reproduction of 3GPP TS 33.501, Figure 6.1.4.1a-1: Linking increased Home control to subsequent procedures
Up
1)
The AUSF shall inform UDM about the result and time of an authentication procedure with a UE using a Nudm_UEAuthentication_ResultConfirmation Request. This shall include the SUPI, a timestamp of the authentication, the authentication type (e.g. EAP method or 5G-AKA), and the serving network name.
2)
The UDM shall store the authentication status of the UE (SUPI, authentication result, timestamp, and the serving network name).
3)
UDM shall reply to AUSF with a Nudm_UEAuthentication_ResultConfirmation Response.
4)
Upon reception of subsequent UE related procedures (e.g. Nudm_UECM_Registration_Request from AMF) UDM may apply actions according to home operator's policy to detect and achieve protection against certain types of fraud (e.g. as proposed in section 6.1.4.2).
Up

6.1.4.2  Guidance on linking authentication confirmation to Nudm_UECM_Registration procedure from AMFWord‑p. 47
This subclause gives informative guidance on how a home operator could link authentication confirmation (or the lack thereof) to subsequent Nudm_UECM_Registration procedures from AMF to achieve protection against certain types of fraud, as mentioned in the preceding subclause.
step
Approach 1:
The home network records the time of the most recent successfully verified authentication confirmation of the subscriber together with the identity of the 5G visited network that was involved in the authentication. When a new Nudm_UECM_Registration Request arrives from a visited network, the home network checks whether there is a sufficiently recent authentication of the subscriber by this visited network. If not, the Nudm_UECM_Registration Request is rejected. The rejection message may include, according to the home networks policy, an indication that the visited network should send a new Nausf_UEAuthentication_Authenticate Request (cf. subclause 6.1.2 of the present document) for fetching a new authentication vector before repeating the Nudm_UECM_Registration Request.
step
Approach 2:
As a variant of the above Approach 1, Approach 2 is based on a more fine-grained policy applied by the home network; the home network could classify roaming partners into different categories, depending on the trust - e.g. derived from previous experience placed in them, for example as follows:
  • For a visited network in the first category, the home network would require a successful authentication 'immediately preceding' the Nudm_UECM_Registration Request from an AMF.
  • For a visited network in the second category, the home network would only check that an authentication in a network visited by the subscriber was sufficiently recent (taking into account that there may have been a security context transfer between the visited networks).
  • For a visited network in the third category, the home network would perform no checks regarding Nudm_UECM_Registration Requests and authentication at all.
Further approaches are possible, depending on the home operator's policy.
Up


Up   Top   ToC