AUSF

Overview

The AUSF — Authentication Server Function — is the home network function responsible for executing the mutual authentication procedure between the subscriber's USIM and the operator's core network. It is invoked by the AMF whenever a UE registers, and its output is the KAUSF — an anchor key from which all 5G NAS encryption, NAS integrity, and radio access stratum security keys are derived. If the AUSF is compromised or produces incorrect keys, no subsequent layer of 5G security is trustworthy.

The AUSF exists as a distinct function because 5G SA separates the authentication execution (AUSF) from the authentication credential store (UDM). The AUSF requests authentication vectors from the UDM via N13 — it receives either a 5G HE AV (Home Environment Authentication Vector) for 5G-AKA, or an EAP payload for EAP-AKA'. The AUSF runs the authentication confirmation step, derives KAUSF, and returns the result to the AMF. The UDM never exposes raw Ki values to the network — it computes vectors internally using the USIM's long-term key.

In the 4G EPC, this function was distributed differently. The HSS computed authentication vectors directly from the Ki and returned them to the MME in the Authentication Information Answer Diameter message. The MME then ran the AKA challenge with the UE. In 5G, the AUSF sits between the AMF and UDM, running the confirmation step that was previously performed by the MME. This structural change means the home network — not the visited network — now verifies authentication success, closing a 4G vulnerability where a rogue visited network could claim authentication succeeded without actually challenging the UE.

The AUSF is a home network function. In roaming scenarios, the visited network's AMF still invokes the home network's AUSF — the request traverses the inter-PLMN interface (via SEPP on N32) to reach the home AUSF. The visited network never has direct access to authentication vectors.

---

How it works

5G-AKA procedure

5G-AKA (Authentication and Key Agreement) is the primary authentication method for 5G SA and is mandatory for UICC-based subscribers.

1. The AMF sends Nausf_UEAuthentication_Authenticate Request to the AUSF on N12, providing the SUPI (resolved from SUCI by the UDM) and the SN-Name (Serving Network Name, composed of the PLMN identity).
2. The AUSF forwards a Nudm_UEAuthentication_Get Request to the UDM on N13, passing the SUPI and SN-Name.
3. The UDM generates a fresh 5G HE AV using the subscriber's Ki (never leaving the UDM), consisting of RAND, AUTN, HXRES*, and KAUSF. The AUTN carries the network's authentication token; HXRES* is the expected hashed response.
4. The UDM returns the 5G HE AV to the AUSF. The AUSF stores HXRES* and KAUSF, strips the vector to a 5G AV (RAND + AUTN + HXRES*), and returns it to the AMF.
5. The AMF derives HRES* and sends the Authentication Request (RAND + AUTN) to the UE via NAS on N1.
6. The USIM in the UE verifies the AUTN to authenticate the network, then computes RES* using the same Ki. The UE returns RES* in the Authentication Response.
7. The AMF hashes RES* to produce HRES*, compares it with the stored HXRES*, and sends Nausf_UEAuthentication_Authenticate Request to AUSF with RES*.
8. The AUSF compares RES* with the full XRES* (unhashed) — this is the confirmation step unique to 5G that the MME could not perform in 4G. If they match, the AUSF confirms authentication success and returns KAUSF to the AMF.
9. The AMF derives KAMF from KAUSF and uses it as the root key for NAS and AS security key derivation.

EAP-AKA' procedure

EAP-AKA' is an alternative method, typically used for non-3GPP access (e.g., Wi-Fi calling via N3IWF) or as specified by operator policy.

1. The AMF initiates Nausf_UEAuthentication_Authenticate with EAP-AKA' indicated.
2. The AUSF acts as an EAP server, running the EAP-AKA' challenge-response with the UE via the AMF as a pass-through.
3. The UDM provides the authentication material on N13 in EAP format.
4. On successful authentication, the AUSF derives KAUSF from the EAP Master Session Key (MSK) and returns it to the AMF.

Synchronisation failure handling

If the UE's USIM sequence number is out of sync with the UDM's stored value, the USIM returns a Synchronisation Failure (AUTS) instead of a RES*. The AMF forwards AUTS to the AUSF, which forwards it to the UDM. The UDM re-synchronises its sequence counter and generates a fresh AV. The authentication procedure then retries from step 3.

---

Architecture role

The AUSF occupies a narrow but critical position in the 5G NF mesh. It has exactly two interfaces: N12 to the AMF (inbound authentication requests) and N13 to the UDM (authentication vector retrieval). It produces one output of consequence — the KAUSF anchor key — and that output determines whether any subsequent NAS or AS security is valid.

In 5G SA: The AUSF is a home network function, always. The visited network's AMF invokes it — directly in the non-roaming case, or via the SEPP N32 interface in the roaming case. Authentication vectors never leave the home network.

Compared to 4G EPC: In 4G, the HSS both stored credentials and generated authentication vectors, returning them directly to the MME in the visited network. The 5G split separates storage (UDM) from execution (AUSF) and adds the confirmation step that moves home-network verification of RES* from the visited network (impossible in 4G) to the home network (mandatory in 5G).

The AUSF is typically a stateless function from a session perspective — it does not need to maintain long-lived state between authentication events. Each Nausf_UEAuthentication_Authenticate request is self-contained. This makes the AUSF relatively straightforward to scale horizontally, though its outputs must be consistent with a given SUPI's sequence state in the UDM.

---

Key interfaces

---

Security posture

The AUSF is the single point in the 5G core where the subscriber's identity is authenticated against the home network's credential store. Its compromise is categorically more severe than most other NF compromises: an attacker who controls the AUSF can cause authentication to succeed for invalid credentials, produce incorrect KAUSF values that break NAS security for legitimate subscribers, or silently log all authentication vectors as they pass through.

Unlike the AMF or SMF, the AUSF has no radio access exposure and no internet-facing interface. Its attack surface is limited to the N12 SBI from the AMF and the N13 SBI to the UDM. This narrow interface makes it more defensible than multi-interface nodes, but it also means that any vulnerability is highly targeted — anyone attacking the AUSF knows exactly what they are after.

The most realistic threat against a production AUSF is not cryptographic — the AKA algorithm (MILENAGE or TUAK) is well-analysed. The threat is implementation quality, access control failures on the N12 API, and the operational security of the N13 path to the UDM. If the AUSF accepts authentication requests from any NF claiming to be an AMF without validating NRF-issued tokens, the AUSF becomes an oracle for authentication vector retrieval.

---

Attack surface

Authentication vector theft via N13

The AUSF requests authentication vectors from the UDM on N13 and holds them transiently — XRES* and KAUSF are in memory between UDM response and AMF confirmation. If the N13 interface is not protected by TLS, or if the AUSF process can be debugged or memory-dumped, an attacker can extract authentication vectors before they are consumed. A stolen KAUSF can be used to derive all subsequent NAS keys for that UE's session.

Impact: Full NAS session key compromise for affected UEs. An attacker with KAUSF can decrypt NAS traffic and impersonate either the UE or the network.
Difficulty: High. Requires either physical access to the AUSF host or exploitation of a memory disclosure vulnerability in the AUSF process.

AUSF impersonation via rogue NRF registration

The AMF discovers AUSF instances via NRF query. If an attacker can register a rogue NF with the AUSF NF type in the NRF — by presenting a valid operator certificate — the AMF may route authentication requests to the rogue AUSF. The rogue AUSF can then return authentication success without actually verifying the UE's credentials, or return a fabricated KAUSF that it knows — enabling subsequent NAS traffic decryption.

Impact: Authentication bypass — any subscriber can authenticate without valid USIM credentials. NAS traffic decryptable by attacker holding the known KAUSF.
Difficulty: High. Requires a valid operator NF certificate and network access to the SBI fabric.

SUPI inference via synchronisation failure oracle

The synchronisation failure response (AUTS) reveals whether the AUSF received a valid SUPI for which a known sequence counter exists. An attacker who can send Nausf_UEAuthentication_Authenticate requests with candidate SUPIs can use the differential response behaviour — synchronisation failure vs. unknown SUPI error — to enumerate which SUPIs are provisioned in the network.

Impact: Subscriber identity enumeration — attacker learns which phone numbers or IMSIs have valid subscriber records.
Difficulty: Medium. Requires a valid NF credential to invoke the N12 API and knowledge of SUPI format ranges.

Cross-network KAUSF linkability in roaming

In roaming scenarios, the home AUSF returns KAUSF to the visited AMF via the SEPP N32 interface. If the N32 transport is not end-to-end encrypted between home and visited SEPP (relying only on hop-by-hop TLS), an intermediate IPX provider may observe KAUSF values in transit. While the IPX provider cannot use KAUSF directly without also capturing the NAS traffic, logging KAUSF across multiple authentication events allows correlation of subscriber sessions across different visited networks.

Impact: Cross-network subscriber tracking via KAUSF correlation.
Difficulty: Medium. Requires access at an IPX/GRX transit point and knowledge of the N32 message format (JOSE-protected JOSE/JSON).

---

Mitigations

The AUSF's defences are concentrated on access control, interface security, and rate limiting — the cryptographic core (AKA itself) is not the weak point in practice.

• NRF token validation on N12: The AUSF must validate the OAuth2 access token on every incoming Nausf request. The token must be issued by the operator's NRF, the NF type must be AMF, and the NF instance ID must correspond to a registered AMF. Reject requests from any NF type other than AMF.

• TLS 1.3 on N12 and N13: Mutual TLS with operator-issued X.509 certificates is mandatory on both interfaces. Do not accept connections from unverified peers. Validate the certificate chain against the operator CA, not just certificate presence.

• Synchronisation failure rate limiting: Apply rate limits per SUPI on synchronisation failure processing. A legitimate sync failure is rare — more than a handful per SUPI per day is anomalous and should trigger an alert. Rate limiting prevents the sync failure oracle from being used for SUPI enumeration at scale.

• N32 JOSE encryption for roaming: When the AUSF's outputs traverse the N32 interface in a roaming scenario, verify that the SEPP is applying JSON Object Signing and Encryption (JOSE) protection to the message body, not just hop-by-hop TLS. This prevents IPX-level observation of KAUSF.

• AUSF audit logging: Log all authentication requests by SUPI, requesting AMF instance ID, and result. Monitor for: authentication request volumes exceeding per-SUPI norms, requests arriving from unregistered AMF instances, and repeated sync failures for the same SUPI without a subsequent success.

---

Spec references

• 3GPP TS 33.501 — The normative 5G security specification. Section 6.1 defines the authentication framework; Section 6.3 defines 5G-AKA in detail including the KAUSF derivation procedure. Annex A covers EAP-AKA'. This is the primary reference.

• 3GPP TS 29.509 — The Nausf service specification. Defines the N12 API endpoints, OpenAPI schemas, and both the 5G-AKA and EAP-AKA' service operations. Essential for AUSF integration testing.

• 3GPP TS 33.102 — 3G security architecture. Section 6.3 defines the AKA procedure that 5G-AKA evolved from. Useful for understanding the differences between 3G/4G and 5G authentication, particularly the addition of the home-network confirmation step.

• RFC 5448 — EAP-AKA' specification. Defines the improvements to EAP-AKA that 3GPP adopted for non-3GPP access authentication in 5G, including the binding to the network name to prevent cross-network key reuse.

---

Related topics

The AUSF works in a tight triangle with the AMF and UDM. The AMF drives authentication by invoking the AUSF on N12. The AUSF retrieves authentication material from the UDM on N13. The UDM never exposes Ki — it returns computed vectors. This separation is deliberate: the AUSF can be replaced or scaled independently of the credential store.

The SEPP is the AUSF's border guardian in roaming. When a roaming subscriber's visited AMF invokes the home AUSF, the request crosses the inter-PLMN N32 interface through the SEPP pair. The home SEPP terminates the roaming authentication path before the AUSF ever sees the request.

The NRF enables the AMF to discover which AUSF instances are available. In a properly configured deployment, the AMF should only invoke AUSF instances registered in the NRF with valid certificates — preventing the rogue AUSF substitution attack.

For the full authentication architecture and how KAUSF relates to KAMF, KgNB, and KNASenc, see 5G SA.