N12 — AMF ⇔ AUSF (Nausf_UEAuthentication reference point)¶

Learning objectives¶

After reading this page, you will be able to:

• Explain that N12 is an SBI (Service Based Interface), and that its substance is the service Nausf_UEAuthentication (TS 29.509) provided by AUSF.
• Explain the flow in which the SEAF (Security Anchor Function) inside the AMF entrusts authentication to the AUSF and drives the 5G-AKA / EAP-AKA' authentication procedure.
• Explain that, on authentication success, the KSEAF, the root of the key hierarchy, is passed from AUSF → SEAF.
• Explain that "reference point N12" and "service Nausf_UEAuthentication" are two views of the same thing.
• Explain the contrast with 4G (EPC), where authentication was inside the MME (the MME retrieved authentication vectors from the HSS and ran AKA).

Prerequisites¶

Understanding the following first will make things smoother.

• The positioning of SBA / SBI and HTTP/2 · TLS → Protocol dictionary
• The NFs at both ends of N12 → AMF / AUSF
• How the authentication procedure (5G-AKA / EAP-AKA') is used → Authentication
• The concept of the key hierarchy (KSEAF, etc.) → Security

Why — why it is needed¶

Before admitting a UE to the network, you must first verify "is this really a legitimate subscriber?" — an identity check (authentication). If anyone could connect, you could not prevent impersonation or fraudulent use. However, if an access-management NF wholly held this authentication function, changes to the authentication logic would ripple into the access-management side.

So in 5G, the authentication function was separated into an independent NF, AUSF (Authentication Server Function). Meanwhile, inside AMF, which handles access management, the SEAF (Security Anchor Function) is placed, mediating the authentication procedure as the anchor of authentication. The path by which the SEAF requests the AUSF, "please authenticate this subscriber," is N12. Without N12, the AMF(SEAF) cannot entrust authentication to the AUSF, and 5G's separated authentication architecture cannot hold.

An analogy: N12 is the hotline by which reception (AMF/SEAF) requests identity verification from the specialist screening department (AUSF). Reception does not complete identity verification on its own but requests screening over this dedicated line. The screening department screens using the matching result (the authentication vector) from the head-office registry (UDM/ARPF), and on passing hands the proof of passing (KSEAF) to reception.

Overview¶

N12 is the reference point connecting AMF(SEAF) ⇔ AUSF. However, the key point is that N12 is an SBI (Service Based Interface), which is decisively different from N2 (NGAP/SCTP) and N4 (PFCP/UDP). An SBI is a mechanism where NFs call each other's services via Web APIs (HTTP), using HTTP/2 + JSON (RESTful) over TLS as the common transport.

The substance of N12 is the service Nausf_UEAuthentication (TS 29.509) provided by AUSF. The SEAF inside the AMF calls this service with Authenticate to start authentication and drives the 5G-AKA / EAP-AKA' authentication procedure. On authentication success, the KSEAF, the root of the key hierarchy, is passed from AUSF → SEAF. Note that the origin of the authentication vector, which is the basis of the authentication decision, is in UDM/ARPF, and the AUSF retrieves it via N13 (Nudm_UEAuthentication) (the N13 side, not N12).

Basic Concept — explanation for beginners¶

We liken N12 to a Web API that requests identity verification from the screening department.

When your phone tries to connect to the network, the access-management AMF goes to work. The SEAF inside the AMF (the anchor of identity verification) does not complete "is this subscriber legitimate?" on its own but queries the specialist screening department, the AUSF (starting authentication with Authenticate). The screening department AUSF cross-checks against the head-office registry (the authentication vector from UDM/ARPF) and drives the identity check with a procedure called 5G-AKA or EAP-AKA'. On passing, the AUSF hands the proof of passing = KSEAF (the root of subsequent keys) to the SEAF.

This request to the screening department is not over a dedicated telephone line (a dedicated protocol like N2 or N4), but rather like throwing a request over an internal Web system (HTTP) and getting a reply. This is SBI (Service Based Interface) = the mechanism where NFs converse via Web APIs (HTTP/2). Both requests and responses are exchanged in the human-readable format called JSON (a RESTful convention).

Protocol / Transport¶

Architecture¶

This shows the context in which N12 connects AMF(SEAF) and AUSF, and the AUSF works with UDM (ARPF/authentication vector) over N13. Authentication messages are exchanged with the UE over N1 (NAS).

flowchart LR
  UE["UE"]
  AMF["AMF (embeds SEAF)"]
  AUSF["AUSF"]
  UDM["UDM (ARPF/authentication vector)"]

  UE -. "N1 (NAS authentication messages)" .- AMF
  AMF == "N12 (Nausf_UEAuthentication)" ==> AUSF
  AUSF == "N13 (Nudm_UEAuthentication)" ==> UDM

  classDef sec fill:#efe,stroke:#3a3,stroke-width:2px;
  class AMF,AUSF sec;

How to read the diagram: the thick line (==>), N12, is the AMF(SEAF)⇔AUSF authentication request (SBI/HTTP2). The SEAF entrusts authentication to the AUSF, and the AUSF further queries UDM (ARPF) over N13 to retrieve the authentication vector. The authentication vector flows back UDM→AUSF, the AUSF drives the identity check, and on success the KSEAF is passed AUSF→SEAF. The actual authentication messages with the UE (RAND/AUTN, RES, etc.) are exchanged over N1 (NAS)* via the AMF.

Procedures used¶

N12 appears in the authentication procedure within Registration. It is the flow in which the SEAF entrusts authentication to the AUSF and an authentication challenge is exchanged with the UE.

• Authentication start: during Registration, the SEAF requests authentication from the AUSF with Nausf_UEAuthentication_Authenticate (presenting SUCI/SUPI).
• Authentication-method decision / vector retrieval: the AUSF queries UDM/ARPF over N13 (Nudm_UEAuthentication) and performs the decision of the authentication method (5G-AKA / EAP-AKA') and the retrieval of the authentication vector.
• Authentication challenge: authentication messages over N1 (NAS) are exchanged between AMF ⇔ UE (for 5G-AKA, presenting RAND/AUTN, the RES* response from the UE, etc.).
• Verification and key handover: the AUSF verifies the response, and on success passes the KSEAF to the SEAF. Subsequent keys are derived by the SEAF from the KSEAF.

Details are to be confirmed: the entity that verifies RES (the division between the AUSF side / the SEAF side), and the exact carriage direction and IE composition of each message, differ by Release and are individually to be confirmed*.

The detailed procedure flow (message sequences, conditions, key-derivation details, etc.) is consolidated in Authentication. Refer there for the procedure details.

Main Messages¶

Since N12 is an SBI, messages take the form of HTTP method + resource operation (RESTful operations, not a procedureCode like NGAP). Representative service operations are as follows.

The HTTP-operation mapping is a conceptual organization: the table above is an organization for understanding; the exact HTTP method, resource URI, and invocation direction of each operation follow the OpenAPI definitions of TS 29.509. Strict method assignments and procedural details are to be confirmed. For the details of each message, see the Message dictionary.

Packet Analysis (Wireshark)¶

Since N12 is an SBI, it is observed on the capture as HTTP/2 (no L4-dedicated protocols such as NGAP/SCTP or PFCP appear).

Decode highlights:

• N12 is encrypted with TLS. To see the contents (HTTP/2 headers and JSON body) you need decryption keys (TLS session keys, etc.). Without keys, it appears only as an encrypted tls payload.
• Once decrypted, you can identify operations by the HTTP/2 headers (resource paths whose :path contains .../nausf-auth/...).
• The body is JSON (authentication method, information related to the authentication challenge, etc.), structured.
• Unlike N2's NGAP (binary, over SCTP), the key point of observing N12 is that it is Web-like (HTTP/JSON). It is SCTP-free, and SCTP-specific filters are not used.

Comparison with EPC¶

• In 4G: subscriber authentication was led by the MME. The MME retrieved authentication vectors (AV) from the HSS over S6a (Authentication Information Retrieval) and ran EPS-AKA between MME ⇔ UE (the authentication function was inherent in the MME).
• In 5G: the authentication function was separated into the AUSF, in a configuration where the SEAF inside the AMF mediates. AMF ⇔ AUSF is connected by N12 (SBI), and the substance of authentication is Nausf_UEAuthentication. The root of the authentication vector is in UDM/ARPF, and the path by which the AUSF retrieves it is the N13 side.

The authentication master moving from the MME to the AUSF is the core of 5G. In 5G the authentication function is separated into an independent NF (AUSF), and the SEAF inside the AMF mediates as the anchor. The point that the root of the authentication vector is in UDM/ARPF continues, and its retrieval is the interaction on the N13 side.

3GPP Specification¶

• 3GPP TS 29.509 — Nausf_UEAuthentication service (provided by AUSF, the substance of N12). Individual clause numbers are to be confirmed
• 3GPP TS 33.501 — 5G security (the 5G-AKA / EAP-AKA' authentication, the key hierarchy and key derivation including KSEAF). Details such as the KSEAF derivation formula follow this spec; this page does not assert them
• 3GPP TS 29.500 / TS 29.501 — SBI framework (technical spec / design principles · OpenAPI). Individual clause numbers are to be confirmed
• 3GPP TS 23.501 §4 — system architecture and reference points (the definition of N12)
• 3GPP TS 23.502 — procedures (use of N12 (authentication) during the registration procedure)

Note (to be confirmed): that the substance of N12 is Nausf_UEAuthentication (TS 29.509), that the authentication methods and key hierarchy (KSEAF, etc.) are specified in TS 33.501, and that reference point N12 and service Nausf are two views of the same interaction are the general 3GPP-architecture organization. The detailed clause numbers, exact resource URIs, and key-derivation details of each service operation differ by Release, so each is individually to be confirmed (key-derivation formulas: see TS 33.501).

Summary¶

• N12 is the reference point connecting AMF(SEAF) ⇔ AUSF, but the fact that it is an SBI (Service Based Interface) is fundamentally different from N2 (NGAP/SCTP) and N4 (PFCP/UDP).
• The Protocol is HTTP/2 + JSON (RESTful) over TLS, and its substance is the AUSF service Nausf_UEAuthentication (TS 29.509).
• The SEAF inside the AMF entrusts authentication to the AUSF, drives 5G-AKA / EAP-AKA', and on success the root of the key hierarchy, KSEAF, is passed from AUSF → SEAF.
• Reference point N12 = service Nausf_UEAuthentication are two views of the same AMF⇔AUSF interaction (AUSF).
• In 4G authentication was inside the MME (retrieving authentication vectors from the HSS and running AKA), but in 5G the authentication master moved to the AUSF, and AMF⇔AUSF was turned into SBI (N12).

Next Step¶

• AUSF — the peer side of N12. The authentication server function (provides Nausf_UEAuthentication)
• AMF — the NF that holds the SEAF internally and entrusts authentication to the AUSF over N12
• Authentication — the details of the authentication procedure (5G-AKA / EAP-AKA')
• Security — the concept of the key hierarchy rooted in KSEAF
• N13 — the reference point by which the AUSF retrieves authentication vectors from UDM/ARPF
• Interface dictionary — checking reference points and SBI