OmniAUSF Operations
OmniAUSF implements the Authentication Server Function (AUSF) of the 5G Core, executing 5G-AKA primary authentication between the AMF (N12) and the UDM (N13). It requests an authentication vector from the UDM, relays the RAND/AUTN challenge (and HXRES*) to the AMF, verifies the UE's response, derives the anchor key K_SEAF, and reports the authentication result back to the UDM.
3GPP Role and Specification References
| Specification | Relevance |
|---|---|
| TS 23.501 | System architecture - AUSF role in the 5G System |
| TS 33.501 | Security architecture - 5G-AKA authentication (6.1.3), K_AUSF/K_SEAF key hierarchy, HXRES*/HRES* (Annex A.5), K_SEAF derivation (Annex A.6) |
| TS 29.509 | Nausf_UEAuthentication service API (HTTP SBI) |
| TS 29.503 | Nudm_UEAuthentication service API - authentication vector generation and authentication result reporting |
| TS 29.510 | Nnrf_NFManagement and Nnrf_NFDiscovery service APIs - NF registration/heartbeat and UDM discovery |
| TS 24.501 | NAS - serving network name format (5G:mnc<MNC>.mcc<MCC>.3gppnetwork.org) |
Interfaces
| Interface | Peer | Direction | Transport | Purpose |
|---|---|---|---|---|
| N12 (Nausf_UEAuthentication) | AMF | Inbound | HTTP SBI | UE authentication initiation and 5G-AKA confirmation |
| N13 (Nudm_UEAuthentication) | UDM | Outbound | HTTP SBI | Authentication vector generation and authentication result reporting |
| Nnrf | NRF | Outbound | HTTP SBI | NF registration, heartbeat, and peer-NF (UDM) discovery (Nnrf_NFDiscovery, TS 29.510) |
SBI Endpoints
All SBI endpoints are served under the base URL {sbi_scheme}://{sbi_addr}:{sbi_port} and use Content-Type: application/json on request. The successful create response uses application/3gppHal+json per TS 29.509.
| Method | Path | Service | Description | Success |
|---|---|---|---|---|
| POST | /nausf-auth/v1/ue-authentications | Nausf_UEAuthentication | Initiate UE authentication (AMF → AUSF). Requires supiOrSuci and servingNetworkName | 201 Created (application/3gppHal+json, Location header) |
| PUT | /nausf-auth/v1/ue-authentications/{authCtxId}/5g-aka-confirmation | Nausf_UEAuthentication | Confirm 5G-AKA - AMF submits resStar | 200 OK |
| DELETE | /nausf-auth/v1/ue-authentications/{authCtxId}/5g-aka-confirmation | Nausf_UEAuthentication | Delete the 5G-AKA authentication result / context | 204 No Content |
| POST | /nausf-auth/v1/ue-authentications/deregister | Nausf_UEAuthentication | Remove UE security context(s) for a SUPI. Requires supi | 204 No Content |
Request / Response Summary
Initiate UE authentication - request body carries supiOrSuci (SUPI or SUCI; the field suci is also accepted) and servingNetworkName; an optional resynchronizationInfo object is passed through to the UDM for SQN resynchronisation. The AUSF requests a 5G-AKA vector from the UDM, then returns 201 Created with a UEAuthenticationCtx body:
authType: "5G_AKA"5gAuthData:{ rand, autn, hxresStar }(hex strings)_links.5g-aka.href: the absolute confirmation URL for this contextservingNetworkName
A Location header points at the created context resource (.../ue-authentications/{authCtxId}).
5G-AKA confirmation - request body carries resStar (hex). The AUSF compares the decoded resStar against the stored XRES* (TS 33.501 6.1.3.2; the AMF is responsible for the HRES*/HXRES* hash check). It records the outcome in the UDM (auth-events) and always returns 200 OK with a ConfirmationDataResponse:
- On success:
{ authResult: "AUTHENTICATION_SUCCESS", supi, kseaf }(K_SEAF as a hex string). - On failure:
{ authResult: "AUTHENTICATION_FAILURE", supi }. Note that an authentication failure is signalled in the body viaauthResult, not by an HTTP error status.
The authentication context is deleted after confirmation regardless of outcome.
Error Responses
Errors are returned as ProblemDetails bodies.
| HTTP Status | Cause | Condition |
|---|---|---|
| 400 | MANDATORY_IE_MISSING | A required field is missing (supiOrSuci/servingNetworkName on initiate; resStar on confirmation; supi on deregister) |
| 404 | USER_NOT_FOUND | The UDM returned 404 for the subscriber during vector generation |
| 404 | CONTEXT_NOT_FOUND | The authCtxId in a confirmation request matches no active context |
| 500 | SYSTEM_FAILURE | UDM unreachable, or the UDM returned a malformed authentication vector |
Key Procedures
5G-AKA Authentication (TS 33.501 Section 6.1.3)
Initiation. On POST .../ue-authentications the AUSF creates a context, then requests a 5G-AKA vector from the UDM at /nudm-ueau/v1/{supiOrSuci}/security-information/generate-auth-data, including the AUSF NF instance id and any resynchronizationInfo supplied by the AMF. The UDM returns an authentication vector (rand, autn, xresStar, kausf) and the resolved supi (de-concealed from the SUCI). The AUSF computes HXRES* from RAND and XRES*, derives K_SEAF from K_AUSF bound to the serving network name, stores the material, and returns the challenge to the AMF. The vector fields are hex-decoded defensively - a missing or malformed vector produces a clean 500 SYSTEM_FAILURE rather than a crash.
Confirmation. On PUT .../{authCtxId}/5g-aka-confirmation the AUSF looks up the context, decodes resStar, and compares it directly to the stored XRES*. It reports the result to the UDM via auth-events (best-effort; a failed report is logged but does not change the response to the AMF) and returns the outcome in the body. The context is then deleted. An unknown authCtxId returns 404 CONTEXT_NOT_FOUND.
Serving network name. Built from mcc/mnc as 5G:mnc<MNC>.mcc<MCC>.3gppnetwork.org per TS 24.501, with two-digit MNCs zero-padded to three digits. The serving network name binds K_SEAF to the serving network, so the AMF and AUSF must agree on the PLMN identity.
SQN resynchronisation. When the AMF includes resynchronizationInfo (the RAND and AUTS produced by the UE) in the initiation request, the AUSF detects the resync condition, validates that both rand and auts are well-formed hex, and relays the validated pair to the UDM/ARPF in the generate-auth-data request so the UDM can re-derive the sequence number (TS 33.501 6.1.3.3). Malformed resync input is dropped and not forwarded. The AUSF does not itself compute the sequence number, but it is not a blind pass-through: it inspects and validates the resync blob before relaying it.
Key Hierarchy and Derivation Split (TS 33.501 Annex A)
The 5G-AKA key hierarchy is split between the UDM and the AUSF. The AUSF never sees the long-term key (Ki) or CK/IK - it receives K_AUSF already derived by the UDM inside the authentication vector, and derives only the anchor key K_SEAF from it. The AMF (not the AUSF) continues the chain down to K_AMF and the access-stratum keys.
| Key / value | Where derived | Derivation | Purpose in the AUSF |
|---|---|---|---|
K_AUSF | UDM (ARPF) | KDF(CK‖IK, servingNetworkName, SQN⊕AK), FC 0x6A (A.2) | Received in the vector; the AUSF anchor key from which K_SEAF is derived. Held in context, never returned to the AMF |
K_SEAF | AUSF | KDF(K_AUSF, servingNetworkName), FC 0x6C (A.6) | The serving-network anchor key. Returned to the AMF only on AUTHENTICATION_SUCCESS; the AMF derives K_AMF from it |
HXRES* | AUSF | lower 128 bits of SHA-256(RAND ‖ XRES*) (A.5) | Returned to the AMF at initiation so the AMF can match the UE's HRES* before forwarding RES* |
XRES* | UDM (ARPF) | KDF(CK‖IK, SNN, RAND, XRES), FC 0x6B (A.4) | Received in the vector; the expected response the AUSF compares RES* against at confirmation |
Because K_SEAF is bound to the servingNetworkName (and K_AUSF upstream is bound to the same SN name and to SQN⊕AK), the AMF, AUSF and UDM must all agree on the PLMN identity for the derived keys to match the UE's. A serving-network-name mismatch surfaces as an AUTHENTICATION_FAILURE at confirmation, not as an explicit error.
Delete 5G-AKA Authentication Result (TS 29.509)
The AMF can explicitly delete an authentication result / context without a confirmation exchange. This maps to Delete5gAkaAuthenticationResult in TS 29.509.
The AUSF deletes the context unconditionally (an unknown authCtxId is a no-op) and always returns 204 No Content; no UDM call is made.
Deregister (TS 29.509)
Removes any UE security context(s) the AUSF holds for a given SUPI.
supi is mandatory (a missing/empty value returns 400 MANDATORY_IE_MISSING). The AUSF iterates its in-memory contexts and deletes any whose stored supi or suci equals the requested SUPI; the operation is local only and does not call the UDM. It always returns 204 No Content, even when no matching context exists.
UE Authentication Context
Each initiation creates one in-memory UE authentication context, keyed by a generated authCtxId (UUID). The context holds the material needed to complete the exchange and is the unit the OAM session endpoints (GET /api/ausf_sessions, DELETE /api/ausf_sessions/{id}) list and clear.
| Field | Set at | Meaning |
|---|---|---|
ctx_id | initiation | The authCtxId UUID; appears in the confirmation URL and OAM session list |
suci | initiation | The supiOrSuci originally presented by the AMF (SUCI or SUPI) |
supi | vector response | The plain SUPI resolved (de-concealed) by the UDM |
serving_network_name | initiation | The SN name the keys are bound to |
rand, xres_star, hxres_star, kausf, kseaf | vector response | The vector and derived keys held for the lifetime of the exchange |
auth_type | vector response | 5G_AKA |
auth_result | - | Populated for a settled session; a context still in flight has no result and is counted as pending in GET /api/statistics |
A context normally exists only between initiation and settlement. It is deleted on confirmation (success or failure), on explicit DELETE .../5g-aka-confirmation, on deregister for its SUPI, and on process restart. In addition, idle or abandoned contexts are garbage-collected by a supervised periodic reaper: a context the AMF initiates but never confirms is reaped once it exceeds context_ttl_seconds (default 3600 seconds), with the reaper sweeping every context_reap_interval_ms (default 60000 ms). This bounds the lifetime of abandoned contexts without operator intervention. See Growing active context count for how to inspect and clear contexts manually if needed.
NRF Registration
At startup the AUSF registers an AUSF NF profile with the NRF advertising the nausf-auth service (v1, 1.0.0), its SBI address/port/scheme, and the configured PLMN. It sends heartbeats every heartbeat_interval milliseconds. Registration can be forced again at runtime via POST /api/oam/nrf/reregister. The AUSF also uses the NRF to discover the UDM: before each Nudm call it queries Nnrf_NFDiscovery (TS 29.510) for a udm instance and targets the discovered UDM. Only when discovery yields no instance (or the NRF is unreachable) does it fall back to the statically configured udm_uri, so single-UDM and static deployments keep working.