N13 — AUSF ⇔ UDM (Nudm_UEAuthentication reference point)¶

Learning objectives¶

After reading this page, you will be able to:

• Explain that N13 is an SBI (Service Based Interface), and that its substance is the service Nudm_UEAuthentication (TS 29.503) provided by UDM.
• Explain the flow in which the AUSF retrieves the authentication-method instruction and the authentication vector from the ARPF (Authentication credential Repository and Processing Function) inside the UDM.
• Explain that the SUCI→SUPI de-concealment by the SIDF (Subscription Identifier De-concealing Function) is a UDM-side function.
• Explain that "reference point N13" and "service Nudm_UEAuthentication" are two views of the same thing.
• Explain the correspondence with 4G (EPC) S6a's Authentication Information Retrieval (HSS→MME, Diameter).

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 N13 → AUSF / UDM
• The overall picture of the authentication procedure (5G-AKA / EAP-AKA') → Authentication
• The reference point that connects AMF(SEAF) and AUSF ahead of N13 → N12

Why — why it is needed¶

To authenticate a UE, you need an authentication vector (matching material) based on the subscriber's long-term key K. But this long-term key K is the most secret original, and on the network side only the ARPF inside UDM may hold and process it. The command center of authentication, AUSF, does not hold K itself but drives authentication by receiving the derived data generated by the ARPF (the authentication vector) and the instruction of "which method to authenticate with."

This "path by which the AUSF fetches the authentication method and authentication vector from UDM/ARPF" is N13. Without N13, the AUSF cannot obtain per-subscriber authentication material and cannot make authentication by 5G-AKA or EAP-AKA' hold. Together with this, the de-concealment (SIDF) that turns the SUCI (concealed permanent ID) back into the SUPI is also done on the UDM side, and its request also passes through this N13 path.

An analogy: N13 is the hotline by which the screening department (AUSF) queries the head-office identity ledger (UDM/ARPF). The screening department requests, "give me this customer's matching material (authentication vector) and screening method." The ledger never lets the secret original (the long-term key K) out, handing over only the derived data processed for matching. The point is that the original stays shut inside the head-office safe (ARPF).

Overview¶

N13 is the reference point connecting AUSF ⇔ UDM. What matters is that N13 is an SBI (Service Based Interface); in accordance with the mechanism where NFs call each other's services via Web APIs (HTTP), it uses HTTP/2 + JSON (RESTful) over TLS as the common transport.

The substance of N13 is the service Nudm_UEAuthentication (TS 29.503) provided by UDM. The AUSF calls this service (authentication-information retrieval: Get), and the UDM, in its internal ARPF, decides the authentication method (5G-AKA / EAP-AKA') from the long-term key K, generates the authentication vector (5G HE AV, etc.), and returns it to the AUSF. Also, the SUCI→SUPI de-concealment by SIDF is executed on the UDM side.

Basic Concept — explanation for beginners¶

We liken N13 to a Web API by which the screening department fetches matching material from the identity ledger.

When your phone tries to register with the network, the command center of authentication, the AUSF, goes to work. The AUSF cannot itself create "which method should I screen this customer with? what is the matching material?" That is because only the head-office identity ledger — the ARPF inside the UDM — holds the subscriber's secret original (the long-term key K).

So the AUSF requests the ledger's Web API (Nudm_UEAuthentication), "give me the authentication information for this customer (SUCI/SUPI)." The ledger side first de-conceals (SIDF) the concealed ID SUCI into the original SUPI, decides the authentication method (5G-AKA / EAP-AKA') in the ARPF, generates the authentication vector, and returns it to the AUSF. It never lets the original key K itself out — what it hands over is only the derived data for matching.

This query is not over a dedicated telephone line (a dedicated protocol like N2/N4), but rather like throwing a request over an internal Web system (HTTP) and getting a reply, with both requests and responses exchanged in human-readable JSON. This is SBI (Service Based Interface) = the mechanism where NFs converse via Web APIs (HTTP/2).

Protocol / Transport¶

Architecture¶

This shows the retrieval path of authentication data, in which N13 connects AUSF and UDM, and ahead of it N12 connects AMF(SEAF) and AUSF.

flowchart LR
  AMF["AMF (SEAF)"]
  AUSF["AUSF"]
  UDM["UDM (ARPF/SIDF)"]
  UDR[("UDR (subscription & authentication data)")]

  AMF == "N12 (Nausf_UEAuthentication)" ==> AUSF
  AUSF == "N13 (Nudm_UEAuthentication)" ==> UDM
  UDM -.-> UDR

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

How to read the diagram: the thick line (==>), N13, is the AUSF⇔UDM authentication-information retrieval (SBI/HTTP2). The AUSF retrieves the authentication-method instruction and the authentication vector from UDM/ARPF over N13, and the SUCI→SUPI de-concealment by SIDF is also done on the UDM side. Using the retrieved vector, the AUSF drives the actual authentication procedure with the SEAF (inside the AMF) over the preceding N12 (Nausf_UEAuthentication). The UDM internally references subscription and authentication data from the UDR (dashed line). Note the division of roles: N13 is "the path to fetch the authentication material," and N12 is "the path to exchange authentication with the UE using the fetched material."

Procedures used¶

N13 is used within the authentication procedure during Registration, when the AUSF queries the UDM for authentication information.

• Authentication-information retrieval (Get): the AUSF queries the UDM with Nudm_UEAuthentication_Get (specifying SUCI or SUPI).
• UDM-side processing: the UDM de-conceals SUCI into SUPI with SIDF, decides the authentication method (5G-AKA / EAP-AKA') in the ARPF, generates the authentication vector, and returns it to the AUSF.
• Authentication progress: using the received vector, the AUSF executes the authentication procedure with the SEAF (inside the AMF) over N12.
• Result confirmation: after authentication completes, the AUSF notifies/confirms the authentication result to the UDM (the ResultConfirmation described below).

The detailed procedure flow (message sequences, the 5G-AKA/EAP-AKA' branch, the elements and derivation of the authentication vector) is consolidated in Authentication. Refer there for the procedure details and the AV element/derivation details (derivation details are to be confirmed).

Main Messages¶

Since N13 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 "HTTP operation" column above is a mapping for understanding; the exact method, resource URI, and invocation direction of each operation follow the OpenAPI definitions of TS 29.503. Strict method assignments are to be confirmed. For the details of each message, see the Message dictionary.

Packet Analysis (Wireshark)¶

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

Decode highlights:

• N13 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 .../nudm-ueau/...).
• The body is JSON (the authentication-method instruction, authentication-vector elements, etc.), but the authentication vector is especially sensitive information and is strictly protected by TLS. Its contents cannot be seen without a decryption key.
• Unlike N2's NGAP (binary, over SCTP), the key point of observing N13 is that it is Web-like (HTTP/JSON). Do not use SCTP-specific filters (e.g., sctp.port).

Comparison with EPC¶

• In 4G: at authentication time the MME retrieved authentication vectors (AV) from the HSS. This is the Authentication Information Retrieval procedure of S6a (Diameter-based, TS 29.272). The long-term key K and authentication-vector generation were on the HSS side.
• In 5G: the AUSF retrieves the authentication-method instruction and authentication vector from UDM/ARPF over N13 (Nudm_UEAuthentication). Diameter was replaced by HTTP/2 + JSON (SBI) (TS 29.503), and additionally SIDF (SUCI→SUPI de-concealment) for permanent-ID concealment was added on the UDM side.

While 4G and 5G share the idea of "fetching the authentication vector from the network-side subscriber-data function," a major difference in 5G is the permanent-ID concealment by SUCI and that the SIDF de-concealment turning it back into SUPI was added on the UDM side.

3GPP Specification¶

• 3GPP TS 29.503 — Nudm_UEAuthentication service (authentication-information retrieval, the substance of N13). Individual clause numbers are to be confirmed
• 3GPP TS 33.501 — 5G security (the authentication methods 5G-AKA / EAP-AKA', authentication vectors, SIDF, ARPF, long-term key K · AV derivation). Individual clause numbers are to be confirmed
• 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 N13)
• 3GPP TS 23.502 — procedures (use of N13 in the registration and authentication procedures)

Note (to be confirmed): that the substance of N13 is Nudm_UEAuthentication (TS 29.503), that the specifications of the authentication methods, authentication vectors, SIDF, and ARPF are in TS 33.501, and that the common SBI framework is the TS 29.500/29.501 family are the general 3GPP-architecture organization. The detailed clause numbers, exact resource URIs, and element composition of the authentication vector of each service operation differ by Release, so each is individually to be confirmed. For the details of the long-term key K · AV derivation, see TS 33.501.

Summary¶

• N13 is the reference point connecting AUSF ⇔ UDM(ARPF), is an SBI (Service Based Interface), and its Protocol is HTTP/2 + JSON over TLS.
• Its substance is the service Nudm_UEAuthentication (TS 29.503) provided by UDM.
• The AUSF retrieves the authentication-method instruction (5G-AKA / EAP-AKA') and the authentication vector over N13. The vector generation from the long-term key K is done by the ARPF, and SUCI→SUPI de-concealment (SIDF) is also a UDM-side function.
• Reference point N13 = service Nudm_UEAuthentication are two views of the same AUSF⇔UDM interaction.
• It corresponds to 4G S6a Authentication Information Retrieval (HSS→MME, Diameter, TS 29.272), and in 5G it was turned into SBI (TS 29.503) plus the addition of permanent-ID concealment via SUCI/SIDF.

Next Step¶

• UDM — the peer side of N13. Embeds the ARPF (K · AV generation) / SIDF (SUCI de-concealment)
• AUSF — the command center of authentication that retrieves authentication material from the UDM over N13 and drives authentication with the SEAF over N12
• Authentication — the details of the 5G-AKA / EAP-AKA' authentication procedure
• N12 — the AMF(SEAF)⇔AUSF reference point (ahead of N13)
• N8 — the AMF⇔UDM reference point (subscriber-data management)
• Interface dictionary — checking each reference point