This tutorial is about Authentication process, but it is not much of Authentication algorithm in OTA(Over the air). I would mostly focus on what kind 5G core network components and which interfaces are involved in this process and the message details being exchanged via N12, N13. Regarding the details of Authentication parameters and algorithms you may refer to my notes on LTE Authentication.

• Core Network Compnents and Interfaces Involved in Authentication
• Signaling Among Core Network Services
• Key hierarchy generation in 5GS
• Initiation of authentication and selection of authentication method
• Authentication procedure for EAP-AKA'
• Authentication procedure for 5G AKA
• Signaling over N12/N13 interfaces
• Get the Test Procedure and Log / Amarisoft TechAcademy

Core Network Compnents and Interfaces Involved in Authentication

The entire signaling path for Authentication process is UE <-- N1--> AMF <--N12-->AUSF<--N13-->UDM, but the main focus on this note is the core network process along AMF <--N12-->AUSF<--N13-->UDM. This core network signaling path is highlighted in blue ellipse and red lines shown below.

Followings are the name of each network component.

AMF     Access and Mobility Management Function ==> Equivalent to MME in 4G

AUSF    Authentication Server Function

DN       Data Network

NEF      Network Exposure Function

NRF      Network Repository Function

NSSF    Network Slice Selection Function

PCF      Policy Control Function ==> Equivalent to PCRF in 5G

(R)AN   (Radio) Access Network

SMF     Session Management Function

UDM     Unified Data Management ==> Equivalent to HSS in 4G

UPF      User Plane Function ==> Equivalent to PGW in 4G

SMSF   SMS Function

SEAF    SEcurity Anchor Function ==> part of AMF function

ARPF    Authentication credential Repository and Processing Function

SIDF    Subscription Identifier De-concealing Function

Signaling Among Core Network Services

Authentication process happens in a couple of steps within core network involving many components (SEAF, AUSF, UDM, ARPF, SIDF).

NOTE : This note is only about Core Network process of Authentication. Regarding the NAS Signaling of Authentication(OTA : Over the Air), check out this note.

Followings are major functionalities of core network components that are involved in this process

• SEAF : SEcurity Anchor Function. The security anchor function (SEAF) provides the authentication functionality via the AMF in the serving network. The SEAF shall fulfil the following requirements: The SEAF shall support primary authentication using SUCI. (33.501-5.6)
• ARPF : Authentication credential Repository and Processing Function.
• SIDF : Subscription Identifier De-concealing Function.

Followings are major components of core network components that are involved in this process

• AMF (Access and Mobility Management Function):
• The AMF is responsible for managing user access to the 5G core network.
• It is the first point of contact for the User Equipment (UE) and initiates the authentication process.
• The AMF receives the initial authentication information from the UE and forwards it to the AUSF for verification.
• AUSF (Authentication Server Function):
• The AUSF verifies the credentials provided by the UE.
• It interacts with the UDM to obtain authentication vectors and to determine if the UE is authorized to access the network.
• After verification, the AUSF sends the authentication response back to the AMF.
• UDM (Unified Data Management):
• The UDM stores subscriber data and is responsible for providing authentication vectors to the AUSF.
• The authentication vectors include random numbers, expected response values, and other essential information required for the authentication process.
• The UDM generates these vectors based on the user's credentials (like the subscription key) and the current network challenges.
• Interfaces:
• N12 Interface: This interface is typically between the AMF and the AUSF. It's used to carry authentication request and response messages between these entities.
• N13 Interface: This interface connects the AUSF and the UDM. It's used for the AUSF to request authentication vectors from the UDM and for the UDM to provide these vectors to the AUSF.

Key hierarchy generation in 5GS

< 33.501 - Figure 6.2.1-1: Key hierarchy generation in 5GS >

Initiation of authentication and selection of authentication method

This is about how the authentication is initiated and how it is processed by various corenetwork components and functionalities.

< 33.501 - Figure 6.1.2-1: Initiation of authentication procedure and selection of authentication method >

Let's break down this process and look into details:

• Initiation by the SEAF (Security Anchor Function):
• The SEAF can initiate authentication with the UE during any procedure that establishes a signaling connection with the UE. This initiation is based on the SEAF's policy.
• During the Registration Request, the UE can use either the SUCI (Subscription Concealed Identifier) or the 5G-GUTI (5G Globally Unique Temporary Identifier).
• SEAF to AUSF Interaction:
• Whenever the SEAF wishes to initiate an authentication, it will use the Nausf_UEAuthentication service to send a Nausf_UEAuthentication_Authenticate Request message to the AUSF.
• This request can contain either:
• SUCI, as currently defined, or
• SUPI (Subscription Permanent Identifier)
• If the SEAF has a valid 5G-GUTI and wants to re-authenticate the UE, it will include the SUPI in the Nausf_UEAuthentication_Authenticate Request message. Otherwise, the SUCI is included.
• The message will also contain the serving network name.
• AUSF's Verification:
• Upon receiving the Nausf_UEAuthentication_Authenticate Request message, the AUSF will verify that the requesting SEAF in the serving network is entitled to use the given serving network name.
• The AUSF checks the serving network name against an expected serving network name and stores the received name temporarily.
• If there's an authorization issue, the AUSF will respond with "serving network not authorized" in the Nausf_UEAuthentication_Authenticate Response.
• AUSF to UDM Interaction:
• The AUSF sends a Nudm_UEAuthentication_Get Request to the UDM, which includes either the SUCI or SUPI and the serving network name.
• If the UDM receives a SUCI, it invokes the SIDF (Subscription Identifier De-concealing Function) to convert the SUCI to a SUPI before processing the request.
• The UDM (or ARPF - Authentication Credential Repository and Processing Function) then chooses the authentication method based on the SUPI.
• How to choose the authentication method ?
• UDM choose the method based on subscriber data stored in it. Once it select it, UDM notifies it to AUSF via request response 200 OK (Example)
• Then AUSF notifies it to AMF via 201 OK response (Example)
• It is eventually informed to UE via NAS message
• In NAS message AUTHENTICATION REQUEST:
• if the IE EAP message is absent --> authentication method is 5G-AKA
• if the IE EAP message is present, depending on the contents of the IE, the authentication method is EAP-TLS or EAP-AKA'
• Responses:
• The responses to the Nudm_UEAuthentication_Get Request and the Nausf_UEAuthentication_Authenticate Request messages are described as part of the authentication procedures.

The service methods and the detailed contents involved in this procedure is as follows.

< 29.509-Figure 5.2.2.2.2-1: 5G AKA >

1. The NF Service Consumer (AMF) sends a POST request to the AUSF with the UE Id and Serving Network Name. (Example)

2a. On success, a 201 response is returned with the resource URI and a link for the AMF to send confirmation.

2b. On failure, an error status code and ProblemDetails are returned.

3.The AMF sends a PUT to the AUSF with the UE's RES* or null if the UE could not be authenticated. (Example)

4a. On success, a 200 OK is returned. The AuthResult indicates if authentication failed.

4b. On failure, an error status code and ProblemDetails are returned.

< 29.503 - Figure 5.4.2.2.2-1: NF service consumer requesting authentication information >

1.The NF service consumer sends a POST request (custom method: generate-auth-data) to the UDM for the UE's security information.

2a. The UDM responds with a 200 OK containing the authentication data in the response body.

2b. If the request is unauthorized, a 403 Forbidden is returned with additional error details in ProblemDetails.

On failure, an appropriate error status code is returned with additional error information in the response body.

< 29.509 - Table 6.1.3.1-1: Resources and methods overview >

< 29.503-Table 6.3.3.1-1: Resources and methods overview >

Authentication procedure for EAP-AKA' 

EAP-AKA' is a new version of EAP-AKA that uses a more secure key derivation function and hash algorithm to protect against compromised access networks and attacks. (Check out RFC 5448 for the details of EAP-AKA' algorithm itself). This section is about how EAP-AKA' is utilized for 5G authentication process.

< 33.501 - Figure 6.1.3.1-1: Authentication procedure for EAP-AKA' >

Let's look into the details in step by step.

• Authentication Vector Generation: The UDM/ARPF generates an authentication vector with a specific AMF separation bit. It then computes CK' and IK', replacing CK and IK with these new values.
• Sending the Transformed Vector: The UDM sends the transformed authentication vector (EAP-AKA' AV, [SUPI])  to the AUSF via  Nudm_UEAuthentication_Get Request
• SUCI Verification: If the SUCI was included in the Nudm_UEAuthentication_Get Request, the UDM will include the SUPI in its response.
• EAP-AKA' Challenge Initiation: The AUSF sends an EAP-Request/AKA'-Challenge message to the SEAF within a Nausf_UEAuthentication_Authenticate Response message.
• Message Forwarding to UE: The SEAF forwards the EAP-Request/AKA'-Challenge message to the UE in a NAS Authentication Request message, which also contains parameters like ngKSI and ABBA.
• USIM Verification: The USIM in the UE verifies the freshness of the AV' by checking the AUTN. If verified, it computes a response RES and provides RES, CK, and IK to the ME.
• Response to SEAF: The UE sends an EAP-Response/AKA'-Challenge message to the SEAF in a NAS Auth-Resp message.
• AUSF Verification: The SEAF forwards the EAP-Response/AKA'-Challenge message to the AUSF. The AUSF then verifies the message by comparing XRES with RES.
• EAP Notification Exchange: The AUSF and UE might exchange EAP-Request/AKA'-Notification and EAP-Response/AKA'-Notification messages, with the SEAF acting as an intermediary.
• Key Derivation and EAP Success Message: The AUSF derives the EMSK from CK and IK, calculates KSEAF, and sends an EAP Success message to the SEAF, which then forwards it to the UE. This message includes the derived KSEAF key.
• SEAF's EAP Success Message to UE: The SEAF sends the EAP Success message to the UE in an N1 message, which also contains the ngKSI and the ABBA parameter. Upon receiving this message, the UE derives its own set of encryption keys.

Authentication procedure for 5G AKA

5G AKA enhances EPS AKA by providing the home network with proof of successful authentication of the UE from the visited network.

< 33.501 - Figure 6.1.3.2-1: Authentication procedure for 5G AKA >

Let's look into the details in step by step.

• Authentication Vector Creation: The UDM/ARPF formulates a 5G HE AV, which incorporates calculations like KAUSF and XRES* based on given specifications.
• Transmission to AUSF: The UDM dispatches the 5G HE AV to the AUSF, signifying its use for 5G AKA. If the SUCI was part of the initial request, the UDM will add the SUPI to its response after processing the SUCI.
• AUSF Data Storage: AUSF retains the XRES* alongside the SUCI or SUPI it received.
• 5G AV Generation: AUSF molds the 5G AV from the 5G HE AV by calculating HXRES* from XRES* and KSEAF from KAUSF, then replacing specific values in the 5G HE AV.
• KSEAF Removal: AUSF extracts the KSEAF and dispatches the 5G SE AV to the SEAF.
• SEAF's Request to UE: SEAF sends RAND and AUTN values to the UE. This message carries the ngKSI and ABBA parameters. The UE's ME then transmits the RAND and AUTN to the USIM.
• USIM Authentication Check: The USIM validates the RAND and AUTN's freshness. If validated, it computes and returns RES, CK, and IK. The ME then calculates several values like RES*, KAUSF, and KSEAF.
• UE Response: The UE relays the RES* value to SEAF.
• SEAF(SEcurity Anchor Function)'s RES Verification: SEAF calculates HRES* from RES* and compares it to HXRES*. If they match, authentication is deemed successful. If not or if RES* isn't received, authentication is considered failed.
• SEAF's Communication with AUSF: SEAF forwards the received RES* to the AUSF.
• AUSF's Authentication Verification: AUSF checks the 5G AV's validity. It compares the received RES* with stored XRES*. If they match, authentication is successful. The AUSF then informs the UDM about the outcome.
• AUSF's Response to SEAF: AUSF informs SEAF about the authentication's success or failure. On successful authentication, the key KSEAF becomes the anchor key, and the SEAF derives the KAMF. The SEAF then sends the KAMF and ngKSI to the AMF.

Signaling over N12/N13 interfaces

Following is an example log captured with Amarisoft Callbox. For the entire log in Amarisoft WebGUI, check out this tutorial.

this is an authentication request from a UE to an AUSF server in a simulated 5G core network environment, likely for testing purposes. The UE provides its identifiers and the request is sent to port 5555 on the local machine to authenticate the UE on the specified 5G network. (Check here for the specification)

• It's sending a POST request to http://127.0.0.1:5555/nausf-auth/v1/ue-authentications on the local machine (127.0.0.1) port 5555. where apiName = nausf-auth, apiVersion = v1 (as per 29.509-6.1.1)
• The path /nausf-auth/v1/ue-authentications indicates this is intended for the AUSF (Authentication Server Function) in a 5G core network.
• It contains a JSON body with the SUPI or SUCI (identifiers for the UE) and the serving network name.
• The headers indicate it accepts JSON responses and uses HTTP/1.1.

Message: 127.0.1.100:5555 POST http://127.0.1.100:5555/nausf-auth/v1/ue-authentications (Check out this)

Data:

Stream id: 1

HEADERS:

  :method: POST

  :path: /nausf-auth/v1/ue-authentications

  :scheme: http

  :authority: 127.0.1.100:5555

  accept: application/3gppHal+json

  accept: application/problem+json

  content-type: application/json

DATA:

  {"supiOrSuci":"suci-0-001-01-0-0-0-0123456789","servingNetworkName":"5G:mnc001.mcc001.3gppnetwork.org"}

Message: Deciphered IMSI: 001010123456789

this is a request to the UDM to generate authentication data for the specified user, providing the 5G network name and AUSF instance ID as context. The UDM would use this information to lookup the user profile and generate fresh authentication data to return. (Check here for the specification)

• It sends a POST to http://127.0.0.1:5556/nudm-ueau/v1/imsi-001010123456789/security-information/generate-auth-data , where apiName = nudm-ueau, apiVersion = v1 (as per 29.509-6.1.1)
• The path indicates it is requesting authentication data from the UDM for the user with IMSI 001010123456789.
• It includes a JSON body with the serving network name "5G:mnc001.mcc001.3gppnetwork.org" and the AUSF instance ID "311730b4-5b0b-4451-a858-bae064887944".
• The headers indicate it expects a JSON response.

Message: 127.0.1.100:5556 POST http://127.0.1.100:5556/nudm-ueau/v1/imsi-001010123456789/security-information/generate-auth-data   (Check out this)

Data:

Stream id: 1

HEADERS:

  :method: POST

  :path: /nudm-ueau/v1/imsi-001010123456789/security-information/generate-auth-data

  :scheme: http

  :authority: 127.0.1.100:5556

  accept: application/json

  accept: application/problem+json

  content-type: application/json

DATA:

  {"servingNetworkName":"5G:mnc001.mcc001.3gppnetwork.org",

    "ausfInstanceId":"311730b4-5b0b-4451-a858-bae064887944"}

This is a 200 OK response to the previous POST request to generate authentication data. this is the UDM returning a successful 200 response containing the requested 5G authentication vector data for the IMSI provided in the previous request. The AUSF can use this information to authenticate the UE over the air interface.

• The status code 200 indicates the request succeeded.
• The content-type header specifies a JSON response.
• The JSON body contains the generated authentication vector with:
• authType: 5G_AKA - Authentication and key agreement protocol used
• avType: 5G_HE_AKA - Type of authentication vector
• rand: Random challenge used by UE and AUSF
• xresStar: Expected response to rand from UE
• autn: Authentication token sent from AUSF to UE
• kausf: Key derived from authentication process

Message: 127.0.1.100:5556 Status: 200  (Check out this)

Data:

Stream id: 1

HEADERS:

  :status: 200

  content-type: application/json

DATA:

  {"authType":"5G_AKA","authenticationVector":{"avType":"5G_HE_AKA",

    "rand":"87d3bc51f51f058c36057d088ce9fa72",

    "xresStar":"35e6b894eac81bcd3a6753a1ba8d3be9",

    "autn":"62b14a63fb9f900187c29e62b16bf3fa",

    "kausf":"fe6ad77e9341e377888a31682f86ac995d20b340049eba3a8e1082e11b95ed6b"}}

This is a 201 Created response from the AUSF after successfully authenticating the UE. The AUSF returns this 201 response to indicate successful authentication, providing a URL for the UE to send 5G-AKA confirmation, and the name of the serving 5G network. This continues the authentication signaling flow between the UE, AUSF, and UDM in a simulated 5G core test environment. In short, the AUSF has received the authentication vector data from the UDM, and sent the authentication request (rand, autn) to the UE. It received the expected response hxresStar back from the UE.

• The 201 status code indicates the authentication resource was created successfully.
• The JSON body contains:
• authType: 5G_AKA - Authentication method used
• 5gAuthData: Contains rand, hxresStar, autn returned by UDM
• _links: URL for UE to send confirmation
• servingNetworkName: Name of 5G network

Message: 127.0.1.100:5555 Status: 201  (Check out this)

Data:

Stream id: 1

HEADERS:

  :status: 201

  content-type: application/json

DATA:

  {"authType":"5G_AKA",

   "5gAuthData":{"rand":"87d3bc51f51f058c36057d088ce9fa72",

   "hxresStar":"40f1c1d2c15251492305922cdeb524fe",

   "autn":"62b14a63fb9f900187c29e62b16bf3fa"},

   "_links":{"5g-aka":{"href":"http://127.0.1.100:5555/nausf-auth/v1/ue-authentications

                                             /imsi-001010123456789/5g-aka-confirmation"}},

   "servingNetworkName":"5G:mnc001.mcc001.3gppnetwork.org"}

This is an authentication request message sent over the 5G NR radio interface (NAS : 5GMM). It is to perform initial authentication. It contains the RAND and AUTN provided by the AUSF to challenge the UE to authenticate itself.

Protocol discriminator indicates 5GS Mobility Management messaging (used for registration, authentication etc.)

• Security header indicates no security applied (initial authentication exchange)
• Message type is for Authentication Request
• ngKSI indicates the 5G NAS security context identifier
• ABBA is Anti-Bidding down Between Architectures
• RAND carries the random challenge from the AUSF
• AUTN carries the authentication token from the AUSF

Message: Authentication request    (Check out this)

Data:

Protocol discriminator = 0x7e (5GS Mobility Management)

Security header = 0x0 (Plain 5GS NAS message, not security protected)

Message type = 0x56 (Authentication request)

ngKSI:

  TSC = 0

  NAS key set identifier = 1

ABBA:

  Length = 2

  Data = 00 00

Authentication parameter RAND:

  Data = 87 d3 bc 51 f5 1f 05 8c 36 05 7d 08 8c e9 fa 72

Authentication parameter AUTN:

  Length = 16

  Data = 62 b1 4a 63 fb 9f 90 01 87 c2 9e 62 b1 6b f3 fa

This is an authentication response message sent over 5G NR from the UE back to the gNB/AUSF after processing the authentication request.

• Protocol discriminator and security header are the same, indicating 5GS mobility management and no security.
• Message type is Authentication Response.
• The authentication response parameter contains the RES (response) value generated by the UE after processing the RAND and AUTN from the request.

Message: Authentication response  (Check out this)

Data:                                ...;.

Protocol discriminator = 0x7e (5GS Mobility Management)

Security header = 0x0 (Plain 5GS NAS message, not security protected)

Message type = 0x57 (Authentication response)

Authentication response parameter:

  Length = 16

  Data = 35 e6 b8 94 ea c8 1b cd 3a 67 53 a1 ba 8d 3b e9

This is a PUT request sent from the AUSF to confirm the authentication result with the UDM after the UE has responded over the air. So after the UE sent the RES response over NR, the AUSF verified it matched the expected XRES from the UDM. The AUSF sends this PUT request to confirm the successful authentication result with the UDM. This completes the 5G authentication signaling flow between the UE, gNB, AUSF and UDM. The UE is now authenticated and subsequent NAS communications can be security protected. (Check here for the specification)

• It sends a PUT to the confirmation URL provided by the AUSF in its earlier 201 Created response.
• the url is http://127.0.1.100:5555/nausf-auth/v1/ue-authentications/imsi-001010123456789/5g-aka-confirmation , where apiName = nausf-auth, apiVersion = v1 (as per 29.509-6.1.1)
• The path contains the IMSI of the authenticated UE.
• The JSON body contains the RES* value (xresStar) originally provided by the UDM.

Message: 127.0.1.100:5555 PUT http://127.0.1.100:5555/nausf-auth/v1/ue-authentications/imsi-001010123456789/5g-aka-confirmation  (Check out this)

Data:

Stream id: 3

HEADERS:

  :method: PUT

  :path: /nausf-auth/v1/ue-authentications/imsi-001010123456789/5g-aka-confirmation

  :scheme: http

  :authority: 127.0.1.100:5555

  accept: application/json

  accept: application/problem+json

  content-type: application/json

DATA:

  {"resStar":"35e6b894eac81bcd3a6753a1ba8d3be9"}

This is a 200 OK response from the AUSF after the successful authentication confirmation with the UDM. The AUSF has confirmed the authentication result with the UDM and is returning a final 200 OK response to indicate the UE is now successfully authenticated. It provides the definitive user identifier (SUPI) and key material (KSEAF) that can be used to establish 5G security context between the UE and gNB for further signaling. This completes the 5G authentication procedure between the UE and the 5G core network functions AUSF/UDM over the radio and HTTP interfaces in this simulated environment. The UE is now ready for secure communications.

• The 200 status code indicates the confirmation request succeeded.
• The JSON body contains:
• authResult: Authentication was successful
• supi: The identifier of the authenticated UE
• kseaf: The key used to derive security keys for protecting future NAS signaling

Message: 127.0.1.100:5555 Status: 200

Data:

Stream id: 3

HEADERS:

  :status: 200

  content-type: application/json

DATA:

  {"authResult":"AUTHENTICATION_SUCCESS",

   "supi":"imsi-001010123456789",

   "kseaf":"a6cdd46b7e2efc93c39b4dde72002fde36f92a0a3af119628121fc7146a9a6e2"}

Message: AUSF_5G_AKA_CONFIRMATION

Message: UE auth OK