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.

Before any of the detail, it is worth being clear about what this procedure actually establishes. The obvious answer is only half of it. Yes, the network satisfies itself that the device holds the right key. But the device is also satisfying itself that the network is genuine. That second half is easy to forget, and it is the reason AUTN exists. A UE that cannot verify AUTN walks away.

The other thing worth knowing up front is that the output is not a yes or a no. It is a key. The letters AKA in both method names stand for Authentication and Key Agreement, and the two happen together. A successful run leaves both ends holding K_SEAF, and everything the connection later uses to protect itself is derived from that.

One sentence covers the geography, and most of the page follows from it. The credential lives in the USIM and in the home network. The procedure runs wherever the UE happens to be. The home network stays in control by holding the key back until it is satisfied, rather than by being present.

• Core Network Compnents and Interfaces Involved in Authentication
• Signaling Among Core Network Services
• What changed from 4G
• Key hierarchy generation in 5GS
• Initiation of authentication and selection of authentication method
• Authentication procedure for EAP-AKA'
• Authentication procedure for 5G AKA
• Why the answer is checked twice
• 5G AKA or EAP-AKA' : what actually differs
• Signaling over N12/N13 interfaces
• Get the Test Procedure and Log / Amarisoft TechAcademy

Core Network Compnents and Interfaces Involved in Authentication

Three functions and two reference points do nearly all of the work, and they are worth naming before the diagram. The AMF is where the signalling from the UE arrives. The AUSF runs the authentication. The UDM holds the credential and decides how the authentication will be run. N12 joins the first two and N13 joins the second two, which is why those are the two interfaces this note follows.

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

The names in this section cause more confusion than anything else on the page. The reason is that they are not all the same kind of thing. AMF, AUSF and UDM are network functions. SEAF, ARPF and SIDF are not. Each of those three is a part of a network function, and none of them is a box anyone deploys.

SEAF lives inside the AMF. ARPF and SIDF live inside the UDM. They carry their own names because each one is the part that has to be trusted with something specific. Naming it makes it possible to say exactly what that something is. ARPF is the only thing that touches the long term key. SIDF is the only thing allowed to turn a SUCI back into a SUPI.

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.

What changed from 4G

The algorithms are largely inherited, which is why the introduction points at the LTE note for them. What changed is the arrangement around the algorithms. That is worth setting out before the procedures, because most of the odd looking steps later on exist for one of these reasons.

The second and fourth rows are the ones that shaped the message flows. Almost everything that looks like an extra step in the figures below has one purpose. It keeps the home network in control of a procedure that is physically happening somewhere else.

Key hierarchy generation in 5GS

Authentication and key agreement are one procedure, and this figure is the agreement half of it. Everything a 5G connection later protects itself with is derived, step by step, from the single long term key sitting on the USIM.

Nothing in that chain is ever transmitted. Both ends compute the same values independently, from things they already share. That is what makes it possible to establish a key over an interface with no protection on it yet. Registration begins in exactly that situation.

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

Read this figure as a grid rather than a flow. The left hand column names the network function that holds each key, and the right hand column names its counterpart inside the device. Every row is therefore a pair, and the pairing is the whole point. A key is only useful because both ends can arrive at it independently, without it ever being sent anywhere. The bracket down the left splits the diagram into the home network at the top and the serving network below.

Three things in that diagram are worth pulling out, because they answer questions that come up later on this page.

• The two methods differ only at the top : find the two dashed boxes. The left one is 5G AKA and the right one is EAP-AKA'. 5G AKA goes from CK and IK straight to K_AUSF. EAP-AKA' goes through CK' and IK' first. Below K_AUSF the two diagrams are identical. So the choice of method changes how you arrive at K_AUSF, and nothing else at all.
• The home network boundary sits between K_AUSF and K_SEAF : this is the single most important line in the picture. K_AUSF never leaves the home network. K_SEAF is the highest key a visited network is ever given, and everything the serving network uses is derived from it. If a visited network is compromised, what leaks is a branch, not the root.
• K never leaves the USIM : notice that the top right cell says USIM while every cell below it says ME. The long term key stays on the card. CK and IK are computed there and handed up to the modem, and everything after that is derived in the modem.

Follow the arrows downward and the shape of the rest is easy to read. K_SEAF gives K_AMF. K_AMF gives the NAS keys, and also gives K_gNB and K_N3IWF, which is where the two access types diverge. K_gNB then gives the RRC and user plane keys used on the radio.

One practical consequence is worth noting. Because each level is derived from the one above, a key can be refreshed at any level without redoing the level above it. A new K_gNB at handover does not need a new authentication. That is why full authentication is rare compared with the number of key changes a UE goes through.

Initiation of authentication and selection of authentication method

Two decisions get made at the start of this procedure, and neither is made where you might expect. The first is whether to authenticate at all. That one belongs to the SEAF, in the visited network. The second is which method to use. That one belongs to the UDM, in the home network.

The UE has no say in either. It discovers the answer to the second only when the Authentication Request arrives. It works out which method it is by looking at whether an EAP message is present.

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 >

This figure covers only the opening of the procedure, and it stops deliberately. Three messages travel outward, from UE to SEAF to AUSF to UDM. Then the diagram ends in a box at the far right. Everything that decides how the authentication will run happens inside that box, at the UDM. The SUCI is turned back into a SUPI, and the method is chosen. Nothing earlier in the chain knows which method it will be.

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' 

This is the first of the two procedures. One thing is worth holding on to while reading it. The AUSF is talking to the UE, and the SEAF is only a courier between them. EAP was designed for exactly that shape. There is an authentication server at one end, a supplicant at the other, and whatever sits in between simply passes messages along without understanding them.

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' >

The EAP-AKA' flow. What makes it look different from the 5G AKA flow further down is the AUSF running an EAP conversation directly with the UE. The SEAF is only carrying messages between them. Read the message names and you will see EAP-Request and EAP-Response passing straight through the serving network without being interpreted there.

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

This is the one you will meet most often in a public network. Read it alongside the EAP-AKA' flow above and the difference shows up in the shape of the diagram. Here the serving network is a participant rather than a courier, and the extra step at the SEAF is what that participation looks like.

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 >

The 5G AKA flow, numbered one to twelve. Two steps are worth finding before reading the rest. Step 9 is a comparison made by the SEAF. Step 11 is a comparison made by the AUSF. They are checking the same authentication, and why there are two of them is the subject of a later section on this page.

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.

Why the answer is checked twice

The step list above mentions two comparisons and treats them as ordinary steps. They are worth separating out. The pair of them is the mechanism behind the claim made earlier, that the home network is given proof.

Step 9 is a comparison made by the SEAF, in the visited network. Step 11 is a comparison made by the AUSF, in the home network. Both are checking the same authentication attempt. Neither is redundant, and the reason becomes clear once you look at what each one is actually given.

The UDM produces a home environment vector, the 5G HE AV, and it contains XRES* and K_AUSF. The AUSF keeps both of those. It then builds a reduced vector for the serving network, the 5G SE AV. It replaces XRES* with a hash of it, and takes K_SEAF out.

So what the SEAF receives is deliberately incomplete. It can hash the response it gets from the UE and compare it with HXRES*. That catches a wrong answer immediately, without a round trip to the home network. What it cannot do is prove the answer is right, because a hash comparison is not the real check. And it has no key, so even a SEAF that decided to lie would have nothing to hand to the AMF.

The real check happens at the AUSF, against the XRES* it kept. Only when that passes does the AUSF release K_SEAF, and only then does the serving network get anything it can use. That ordering is the point of the whole design.

• The fast check is for speed : a wrong response is rejected in the visited network, without waiting for the home network to answer.
• The slow check is for authority : the home network makes the decision, and because it makes it, it also knows the outcome. That is the proof that 4G never had.
• The key is the enforcement : withholding K_SEAF until the second check passes is what makes the first check non-binding. The serving network cannot proceed on its own opinion.

NOTE : EAP-AKA' arranges this differently but reaches the same place. There the AUSF runs the EAP exchange with the UE and the SEAF only relays, so there is no local check to make. The serving network still receives K_SEAF only at the end, carried with the EAP Success.

5G AKA or EAP-AKA' : what actually differs

Both procedures are described above in their own sections, which makes it easy to miss how much they have in common. This is a comparison of the parts that are genuinely different.

Two things are the same in both, and they are the things that matter most. The credential is the same, because both start from K in the USIM. And the outcome is the same, because both end at K_SEAF and everything below it is identical, exactly as the key hierarchy figure showed.

The choice is not made by the UE and not made by the serving network. The UDM makes it, per subscriber, based on subscription data, and the UE finds out only when the Authentication Request arrives.

Signaling over N12/N13 interfaces

One thing is worth saying before the logs, because it catches people arriving from 4G. There is no Diameter here, and no GTP. The 5G core is service based, so these interfaces are HTTP/2 carrying JSON, and what follows looks like ordinary calls to a web API.

N12 and N13 are the reference point names, and they are useful for talking about the architecture. What you actually see on the wire is a POST to a URL. Keep both names in mind while reading, because the logs never mention N12 or N13 at all.

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