5 Services offered by the AUSF

29.5093GPP5G SystemAuthentication Server ServicesRelease 18Stage 3TS

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

5.1 Introduction

The AUSF offers to NF Service Consumers (e.g. AMF) the following services:

– Nausf_UEAuthentication

– Nausf_SoRProtection

– Nausf_UPUProtection

Table 5.1-1 summarizes the corresponding APIs defined for this specification.

Table 5.1-1: API Descriptions

Service Name	Clause	Description	OpenAPI Specification File	apiName	Annex
Nausf_UEAuthentication	6.1	AUSF UE Authentication Service	TS29509_Nausf_UEAuthentication.yaml	nausf-auth	A.2
Nausf_SoRProtection	6.2	AUSF SoR Protection Service	TS29509_Nausf_SoRProtection.yaml	nausf-sorprotection	A.3
Nausf_UPUProtection	6.3	AUSF UPU Protection Service	TS29509_Nausf_UPUProtection.yaml	nausf-upuprotection	A.4

AUSF provides services to the following SNPN scenarios (see clauses 5.30.2 in 3GPP TS 23.501 [2]):

– In a SNPN where roaming is not supported;

– In the case of UE access to SNPN using credentials from Credentials Holder with AAA-S;

– In the case of UE access to SNPN using credentials from Credentials Holder with AUSF and UDM;

– In the case of Onboarding of UEs for SNPNs without using Default Credentials Server;

– In the case of Onboarding of UEs for SNPNs using Default Credentials Server with AAA-S;

– In the case of Onboarding of UEs for SNPNs using Default Credentials Server with AUSF and UDM.

5.2 Nausf_UEAuthentication Service

5.2.1 Service Description

The AUSF is acting as NF Service Producer. It provides UE authentication service to the requester NF. The NF Service Consumer is the AMF.

For this service, the following service operations are defined:

– Authenticate

This service permits to authenticate the UE and to provide one or more master keys which are used by the AMF to derived subsequent keys.

5.2.2 Service Operations

5.2.2.1 Introduction

The service operation defined for the Nausf_UEAuthentication is as follows:

– Authenticate: It allows the AMF to authenticate the UE and allows the AMF to inform AUSF to remove the UE authentication result in the UDM.

– Deregister: It allows UDM to request the AUSF to clear the Security Context.

– ProseAuthenticate: It allows the AUSF of the 5G ProSe Remote UE to support the authentication of a 5G ProSe Remote UE via the AMF of the 5G ProSe UE-to-Network Relay.

5.2.2.2 Authenticate

5.2.2.2.1 General

The service operation "Authenticate" permits the requester NF to initiate the Authentication of the UE by providing the following information to the AUSF:

– UE id (i.e. SUPI or SUCI)

– Serving Network Name

The AUSF retrieves the UE’s subscribed authentication method from the UDM and depending on the information provided by the UDM, the AUSF enters in one of the following procedures:

– 5G-AKA

– EAP-based authentication’

For those two different procedures a new resource is generated by the AUSF. The content of the resource will depend on the procedure and will be returned to the AMF.

This service operation "Authenticate" also permits the requester NF to initiate the Authentication of the FN-RG registration via W-AGF by providing the following information to the AUSF:

– UE id (i.e. SUCI)

– Indication that the W-AGF has authenticated the FN-RG

The AUSF retrieves the UE’s SUPI, indication that authentication is not required for the FN-RG from the UDM, and AUSF shall not perform the authentication.

The service operation "Authenticate" also permits the requester NF to inform the AUSF to remove the UE authentication result in the UDM.

5.2.2.2.2 5G AKA

In this procedure, the NF Service Consumer (AMF) requests the authentication of the UE by providing UE related information and the Serving Network Name to the NF Service Producer (AUSF), which retrieves UE related data and authentication method from the UDM. In this case the retrieved authentication method is 5G AKA. The NF Service Consumer (AMF) shall then return to the AUSF the result received from the UE:

Figure 5.2.2.2.2-1: 5G AKA

1. The NF Service Consumer (AMF) shall send a POST request to the AUSF. The payload of the body shall contain at least the UE Id and the Serving Network Name.

2a. On success, "201 Created" shall be returned. The payload body shall contain the representation of the resource created and the "Location" header shall contain the URI of the created resource (e.g. …/v1/ue_authentications/{authCtxId}). The AUSF generates a sub-resource "5g-aka-confirmation". There shall be only one sub-resource "5g-aka-confirmation" per UE per Serving Network identified by the supiOrSuci and servingNetworkName in AuthenticationInfo. The AUSF shall provide an hypermedia link towards this sub-resource in the payload to indicate to the AMF where it shall send a PUT for the confirmation.

2b. On failure or redirection, one of the HTTP status code listed in table 6.1.3.2.3.1-3 shall be returned. For a 4xx/5xx response, the message body may contain a ProblemDetails structure with the "cause" attribute set to one of the application error listed in Table 6.1.3.2.3.1-3. If the serving network is not authorized, the AUSF shall use the SERVING_NETWORK_NOT_AUTHORIZED "cause".

3. Based on the relation type, the NF Service Consumer (AMF) deduces that it shall send a PUT containing the "RES*" provided by the UE to the URI provided by the AUSF or derived by itself. The NF Service Consumer (AMF) shall also send a PUT containing null value in the RES* to indicate the failure to the AUSF for the following cases:

– if the UE is not reached, and the RES* is never received by the NF Service Consumer (AMF);

– the comparation of the HRES* and HXRES* is unsuccessful in the NF Service Consumer (AMF);

– the authentication failure is received from the UE, e.g. synchronization failure or MAC failure;

4a. On success, "200 OK" shall be returned. If the UE is not authenticated, e.g. the verification of the RES* was not successful in the AUSF, the AUSF shall set the value of AuthResult to AUTHENTICATION_FAILURE.

In SNPN onboarding scenarios, if the UE is authenticated successfully, the AUSF may include in the response the FQDN(s) and/or IP address(es) of an onboarding Provisioning Server (PVS) to the NF Service Consumer (AMF); see 3GPP TS 23.501 [2], clause 5.30.2.10.

4b. On failure or redirection, one of the HTTP status code listed in table 6.1.3.3.3.1-3 shall be returned. For a 4xx/5xx response, the message body may contain a ProblemDetails structure with the "cause" attribute set to one of the application error listed in Table 6.1.3.3.3.1-3.

5.2.2.2.3 EAP-based authentication method

5.2.2.2.3.1 General

In this procedure, the NF Service Consumer requests the authentication of the UE by providing UE related information and the serving network and the EAP-based authentication is selected (see IETF RFC 3748 [18]). EAP messages are exchanged between a UE acting as EAP peer, an NF Service Consumer (AMF/SEAF, NSWOF) acting as a pass-through authenticator and the AUSF acting as the EAP server.

5.2.2.2.3.2 EAP method: EAP-AKA’

EAP-AKA’ is the EAP method used in this procedure

Figure 5.2.2.2.3-1: EAP-based authentication with EAP-AKA’ method

1. The NF Service Consumer (AMF, NSWOF) shall send a POST request to the AUSF. The payload of the body shall contain at least the UE Id, Serving Network Name. If the consumer is an NSWOF the NSWO Indicator shall be present in the payload of the body.

2a. On success, "201 Created" shall be returned. The payload body shall contain the representation of the resource generated and the "Location" header shall contain the URI of the generated resource (e.g. …/v1/ue_authentications/{authCtxId}). The AUSF generates a sub-resource "eap-session". There shall be only one sub-resource "eap-session" per UE per Serving Network identified by the supiOrSuci and servingNetworkName in AuthenticationInfo. The AUSF shall provide a hypermedia link towards this sub-resource in the payload to indicate to the AMF or NSWOF where it shall send a POST containing the EAP packet response. The body payload shall also contain the EAP packet EAP-Request/AKA’-Challenge.

2b. On failure or redirection, one of the HTTP status code listed in table 6.1.3.2.3.1-3 shall be returned. For a 4xx/5xx response, the message body may contain a ProblemDetails structure with the "cause" attribute set to one of the application error listed in Table 6.1.3.2.3.1-3. In particular, if the serving network is not authorized, the AUSF shall use the "Cause" SERVING_NETWORK_NOT_AUTHORIZED.

3. Based on the relation type, the NF Service Consumer (AMF, NSOWF) shall send a POST request including the EAP-Response/AKA’ Challenge received from the UE. The POST request is sent to the URI provided by the AUSF or derived by the NF Service Consumer (AMF, NSWOF).

4a. On success, and if the AUSF and the UE have indicated the use of protected successful result indications as in IETF RFC 9048 [17], the AUSF shall reply with a "200 OK" HTTP message containing the EAP Request/AKA’ Notification and an hypermedia link towards the sub-resource "eap-session".

4b. On failure or redirection, one of the HTTP status code listed in table 6.1.3.4.3.1-3 shall be returned. For a 4xx/5xx response, the message body may contain a ProblemDetails structure with the "cause" attribute set to one of the application error listed in Table 6.1.3.4.3.1-3.

NOTE: Steps 4 to 5 are optional.

5. The NF Service Consumer (AMF, NSWOF) shall send a POST request including the EAP Response/AKA’ Notification received from the UE. The POST request is sent to the URI provided by the AUSF or derived by the NF Service Consumer (AMF, NSWOF).

6a. If the EAP authentication exchange is successfully completed (with or without the optional Notification Request/Response messages exchange), "200 OK" shall be returned to the NF Service Consumer (AMF, NSWOF). The payload shall contain the result of the authentication, an EAP success/failure and if the authentication is successful the Kseaf if the consumer is an AMF or the MSK if the consumer is a NSWOF (as indicated by the NSWO indicator received in step 1). If the UE is not authenticated, the AUSF shall set the authResult to AUTHENTICATION_FAILURE.

6b. On failure or redirection, one of the HTTP status code listed in table 6.1.3.4.3.1-3 shall be returned. For a 4xx/5xx response, the message body may contain a ProblemDetails structure with the "cause" attribute set to one of the application error listed in Table 6.1.3.4.3.1-3.

5.2.2.2.3.3 EAP method: EAP-TLS

The EAP-TLS method can be used in private networks as an EAP method (see 3GPP TS 33.501 [8] Annex B.1). The corresponding stage 3 implementation is described in Annex B.

The EAP-TLS method is applicable for N5GC devices behind Cable RGs in private networks or in deployment scenarios with wireline access; see 3GPP TS 33.501 [8] Annex O.

5.2.2.2.3.4 EAP method: EAP-TTLS

The EAP-TTLS method can be used as an EAP method (see 3GPP TS 33.501 [8] Annex U) in case of UE access to SNPN using credentials from Credential Holder with AAA Server.

5.2.2.2.4 Authentication for FN-RG

In this procedure, the NF Service Consumer (AMF) requests the authentication of the FN-RG registration via W-AGF by providing the SUCI of the FN-RG and the authenticated indication.

Figure 5.2.2.2.4-1: Authentication for FN-RG

1. The NF Service Consumer (AMF) shall send a POST request to the AUSF. The payload of the body shall contain at least the UE Id and the authenticated indication.

2b. On failure or redirection, one of the HTTP status code listed in table 6.1.3.4.3.1-3 shall be returned. For a 4xx/5xx response, the message body may contain a ProblemDetails structure with the "cause" attribute set to one of the application error listed in Table 6.1.3.4.3.1-3.

5.2.2.2.5 Authentication Result Removal with 5G AKA method

In the case that the Purge of subscriber data in AMF after the UE deregisters from the network or the NAS SMC fails following the successful authentication in the registration procedure, the NF Service Consumer (AMF) requests the AUSF to inform the UDM to remove the authentication result:

Figure 5.2.2.2.5-1: Authentication Result Removal with 5G AKA method

1. The NF Service Consumer (AMF) shall send a DELETE request to the resource URI representing the sub-resource "5g-aka-confirmation". The request body shall be empty.

2a. On success, "204 No Content" shall be returned. The AUSF shall send a DELETE request to the UDM for removing the authentication result of the UE after receiving the above DELETE request message.

2b. On failure or redirection, one of the HTTP status code listed in table 6.1.3.3.3.2-3 shall be returned. For a 4xx/5xx response, the message body may contain a ProblemDetails structure with the "cause" attribute set to one of the application error listed in Table 6.1.3.3.3.2-3..

5.2.2.2.6 Authentication Result Removal with EAP-AKA’ method

In the case that the Purge of subscriber data in AMF after the UE deregisters from the network or the NAS SMC fails following the successful authentication the registration procedure, the NF Service Consumer (AMF) requests the AUSF to inform the UDM to remove the authentication result:

Figure 5.2.2.2.6-1: Authentication Result Removal with EAP-AKA’ method

1. The NF Service Consumer (AMF) shall send a DELETE request to the resource URI representing the sub-resource "eap-session". The request body shall be empty.

2a. On success, "204 No Content" shall be returned. The AUSF shall send a DELETE request to the UDM for removing the authentication result of the UE after receiving the above DELETE request message.

2b. On failure or redirection, one of the HTTP status code listed in table 6.1.3.4.3.2-3 shall be returned. For a 4xx/5xx response, the message body may contain a ProblemDetails structure with the "cause" attribute set to one of the application error listed in Table 6.1.3.4.3.2-3.

5.2.2.3 Deregister

5.2.2.3.1 General

The Deregister service operation is used in the following scenario:

– Deletion of security context in AUSF

The NF Service Consumer (e.g. UDM) uses this service operation to request the AUSF to clear the stale security context, after the UE has been successfully (re)authenticated in same or different Serving Network via another AUSF Instance, e.g. due to registration via another access-type; so as to ensure only latest Kausf is maintained in the network. The service may also be used by UDM when the UE is no longer registered via any access-type or serving-network. It is responsibility of NF Service Consumers to ensure that security context being deleted does not hold the latest Kausf if UE is also connected via another Serving-Network.

Figure 5.2.2.3.1-1: UE Context Clean-up in AUSF

1. The NF Service Consumer (e.g. UDM) shall send a POST request to the AUSF that was used to authenticate the UE. The payload of the body shall contain the UE id (e.g. SUPI).

2a. On success, "204 No Content" shall be returned.

2b. On failure or redirection, one of the HTTP status code listed in table 6.1.3.2.4.2.2-2 shall be returned. For a 4xx/5xx response, the message body may contain a ProblemDetails structure with the "cause" attribute set to one of the application error listed in Table 6.1.3.2.4.2.2-2.

5.2.2.4 ProseAuthenticate

5.2.2.4.1 General

The ProseAuthenticate service operation is used in the following scenario:

– Authenticate the 5G ProSe Remote UE in AUSF

The NF Service Consumer (AMF) requests the authentication of the 5G ProSe Remote UE by providing 5G ProSe Remote UE related information (SUCI or CP-PRUK ID), the Relay Service Code and Nonce_1 to the NF Service Producer (AUSF) in the initial authentication request. When CP-PRUK ID is provided, the AUSF shall retrieve the CP-PRUK from PAnF; when SUCI is provided, the AUSF retrieves 5G ProSe Remote UE related data and authentication method from the UDM. In this case the retrieved authentication method is EAP-AKA. The NF Service Consumer (AMF) shall then return to the AUSF the result received from the 5G ProSe Remote UE to continue the authentication:

Figure 5.2.2.4.1-1: ProSe Authentication

1. The NF Service Consumer (AMF) shall send a POST request to the AUSF. The payload of the body shall contain the UE Id (SUCI) or CP-PRUK ID, Relay Service Code and Nonce_1.

2a. On success, "201 Created" shall be returned if UE Id (SUCI) is received. The payload body shall contain the representation of the resource generated and the "Location" header shall contain the URI of the generated resource (e.g. …/v1/prose_authentications/{authCtxId}). The AUSF generates a sub-resource "prose-auth". There shall be only one sub-resource "prose-auth" per UE identified by the supiOrSuci in ProSeAuthenticationInfo. The AUSF shall provide a hypermedia link towards this sub-resource in the payload to indicate to the AMF where it shall send a POST containing the EAP packet response. The body payload shall also contain the EAP packet EAP-Request/AKA’-Challenge.

2b. On success, "200 OK" shall be returned if CP-PRUK ID is received. The payload body shall contain the K_{NR_ProSe}and Nonce_2. Step 3 to 6 are skipped.

2c. On failure or redirection, one of the HTTP status code listed in table 6.1.3.2.3.1-3 shall be returned. For a 4xx/5xx response, the message body may contain a ProblemDetails structure with the "cause" attribute set to one of the application error listed in Table 6.1.3.2.3.1-3.

3. Based on the relation type, the NF Service Consumer (AMF) shall send a POST request including the EAP-Response/AKA’ Challenge received from the 5G ProSe Remote UE. The POST request is sent to the URI provided by the AUSF or derived by the NF Service Consumer (AMF).

4a. On success, and if the AUSF and the UE have indicated the use of protected successful result indications as in IETF RFC 5448 [9] (to be superseded by draft-ietf-emu-rfc5448bis [17]), the AUSF shall reply with a "200 OK" HTTP message containing the EAP Request/AKA’ Notification and an hypermedia link towards the sub-resource "prose-auth".

NOTE: Steps 4 to 5 are optional.

5. The NF Service Consumer (AMF) shall send a POST request including the EAP Response/AKA’ Notification received from the UE. The POST request is sent to the URI provided by the AUSF or derived by the NF Service Consumer (AMF).

6a. If the ProSe authentication exchange is successfully completed (with or without the optional Notification Request/Response messages exchange), "200 OK" shall be returned to the NF Service Consumer (AMF). The payload shall contain the result of the authentication, an EAP success/failure. The payload shall also contain the K_{NR_ProSe}, Nonce_2 and CP-PRUK ID if the authentication is successful. If the 5G ProSe Remote UE is not authenticated, the AUSF shall set the authResult to AUTHENTICATION_FAILURE.

5.2.2.4.2 ProSe Authentication Result Removal with EAP-AKA’ method

In the case that the authentication of a 5G ProSe Remote UE failure, the NF Service Consumer (AMF) requests the AUSF to inform the UDM to remove the authentication result:

Figure 5.2.2.4.2-1: ProSe Authentication Result Removal with EAP-AKA’ method

1. The NF Service Consumer (AMF) shall send a DELETE request to the resource URI representing the sub-resource "prose-auth". The request body shall be empty.

2a. On success, "204 No Content" shall be returned. The AUSF shall send a DELETE request to the UDM for removing the authentication result of the UE after receiving the above DELETE request message.

5.3 Nausf_SoRProtection Service

5.3.1 Service Description

The AUSF is acting as NF Service Producer. It provides SoRProtection service to the NF Service Consumer.

This service permits to provide the NF Service Consumer (e.g. UDM) with the SoR-MAC-IAUSFand CounterSoR to protect the Steering Information from being tampered with or removed by the VPLMN.

NOTE: If the Steering Information is not available or HPLMN determines that no steering of the UE is required, a SOR transparent container information element with an HPLMN indication that ‘no change of the "Operator Controlled PLMN Selector with Access Technology" list stored in the UE protected by SoR-MAC-IAUSF and CounterSoR is still sent to the UE during registration. The Steering Information in such a case, the NF Service Consumer shall send an empty list to the AUSF when consuming the Nausf_SoRProtection Service.

In option this service also allows to provide the NF Service Consumer (e.g. UDM) with the SoR-XMAC-IUE that allows the NF Service Consumer (e.g. UDM) to verify that the UE received the Steering Information List.

5.3.2 Service Operations

5.3.2.1 Introduction

The service operation defined for the Nausf_SoRProtection is as follows:

– Protect

5.3.2.2 Protect

5.3.2.2.1 General

The Protect service operation is used in the following procedures:

– Procedure for steering of UE in VPLMN during registration (see clause 6.14.2.1 of 3GPP TS 33.501 [8]);

– Procedure for steering of UE in VPLMN after registration (see clause 6.14.2.2 of 3GPP TS 33.501 [8]).

The NF Service Consumer (e.g. UDM) uses this service operation to request the AUSF to compute the SoR-MAC-IAUSF and the CounterSoR by providing Steering Information. The NF Service Consumer (e.g. UDM) may also request the AUSF to compute the SoR-XMAC-IUE by providing the indication that an acknowledgement is requested from the UE.

Figure 5.3.2.2.1-1: Steering of UE in VPLMN

1. The NF Service Consumer (e.g. UDM) shall send a POST request to the AUSF that was used to authenticate the UE. The payload of the body shall contain the Steering Information and the acknowledge indication.

2a. On success, "200 OK" shall be returned. The payload body shall contain the requested security material (e.g. SoR-MAC-I_AUSF,Counter_SoR,SoR-XMAC-I_UE) necessary to protect the Steering of Roaming procedure.

SoR Header shall be used to form the input as one of multiple parameters to calculate the SoR-MAC-I_AUSF. If SoRHeader attribute is not provided by NF Service Consumer (e.g. UDM) as part of SorInfo, SoR Header shall be constructed by AUSF based on the information received in the request and encoded as specified in clause 9.11.3.51 of 3GPP TS 24.501[20].

2b. On failure or redirection, one of the HTTP status code listed in table 6.2.3.2.4.2.2-2 shall be returned. For a 4xx/5xx response, the message body may contain a ProblemDetails structure with the "cause" attribute set to one of the application error listed in Table 6.2.3.2.4.2.2-21. If the Counter_SoR associated with the K_AUSF of the UE, is about to wrap around, the AUSF shall use the "COUNTER-WRAP" cause.

5.4 Nausf_UPUProtection Service

5.4.1 Service Description

The AUSF is acting as NF Service Producer. It provides UPUProtection service to the NF Service Consumer.

This service permits to provide the NF Service Consumer (e.g. UDM) with the UPU-MAC-I_AUSF and Counter_UPU to protect the UE Parameters Update Data from being tampered with or removed.

In option this service also allows to provide the NF Service Consumer (e.g. UDM) with the UPU-XMAC-I_UE that allows the NF Service Consumer (e.g. UDM) to verify that the UE received UE Parameters Update Data correctly.

5.4.2 Service Operations

5.4.2.1 Introduction

The service operation defined for the Nausf_UPUProtection is as follows:

– Protect

5.4.2.2 Protect

5.4.2.2.1 General

The Protect service operation is used in the following procedures:

– Procedure for UE Parameters Update (see clause 6.15.2.1 of 3GPP TS 33.501 [8]).

The NF Service Consumer (e.g. UDM) uses this service operation to request the AUSF to compute the UPU-MAC-I_AUSF and Counter_UPU by providing the UE Parameters Update Data (UPU Data). The NF Service Consumer (e.g. UDM) may also request the AUSF to compute the UPU-XMAC-I_UE by providing the indication that an acknowledgement is requested from the UE.

Figure 5.4.2.2-1: UE Parameters Update in VPLMN

1. The NF Service Consumer (e.g. UDM) shall send a POST request to the AUSF that was used to authenticate the UE and stores the latest K_AUSF for the UE. The payload of the body shall contain the UE Parameters Update Data (UPU Data), the UPU Header and the acknowledge indication.

2a. On success, "200 OK" shall be returned. The payload body shall contain the requested security material necessary to protect the UE Parameters Update procedure.

2b. On failure or redirection, one of the HTTP status code listed in table 6.3.3.2.4.2.2-2 shall be returned. For a 4xx/5xx response, the message body may contain a ProblemDetails structure with the "cause" attribute set to one of the application error listed in Table 6.3.3.2.4.2.2-2. If the Counter_UPU associated with the K_AUSF of the UE, is about to wrap around, the AUSF shall use the "COUNTER-WRAP" cause.