N13 — AUSF ⇔ UDM（Nudm_UEAuthentication 参照点）¶

難易度: 中級／想定学習時間: 18分／接続点: AUSF ⇔ UDM(ARPF) ／ Protocol: HTTP/2 + JSON (SBI) ／関連Interface: N12, N8, N10

学習目標¶

このページを読み終えると、次のことができるようになります。

N13が SBI（Service Based Interface） であり、その実体がUDMの提供するサービス Nudm_UEAuthentication（TS 29.503） であることを説明できる。
AUSFがUDM内部の ARPF（Authentication credential Repository and Processing Function） から、認証方式の指示と認証ベクトルを取得する流れを説明できる。
SIDF（Subscription Identifier De-concealing Function） による SUCI→SUPI の復号がUDM側の機能であることを説明できる。
「参照点N13」と「サービスNudm_UEAuthentication」が同じものの2つの見方であることを説明できる。
4G(EPC)の S6a の Authentication Information Retrieval（HSS→MME, Diameter） との対応関係を説明できる。

前提知識¶

先に以下を理解しておくとスムーズです。

SBA / SBI と HTTP/2・TLS の位置づけ → Protocol辞典
N13の両端のNF → AUSF / UDM
認証手続き（5G-AKA / EAP-AKA'）の全体像 → Authentication
N13の手前でAMF(SEAF)とAUSFを結ぶ参照点 → N12

Why — なぜ必要なのか¶

UEを認証するには、加入者の長期鍵Kに基づく認証ベクトル（照合材料）が必要です。しかしこの長期鍵Kは最も秘匿すべき原本であり、これを保持・処理してよいのはネットワーク側では UDM 内部の ARPF だけです。認証の司令塔である AUSF は、Kそのものは持たず、ARPFが生成した派生データ（認証ベクトル）と「どの方式で認証するか」の指示を受け取って認証を進めます。

この「AUSFがUDM/ARPFへ認証方式と認証ベクトルを取り寄せる道」がN13です。N13が無ければ、AUSFは加入者ごとの認証材料を得られず、5G-AKAやEAP-AKA'による認証を成立させられません。あわせて、SUCI（秘匿された恒久ID）を SUPI に戻す復号（SIDF）もUDM側で行われ、その要求もこのN13経路を通ります。

例え話: N13は、審査部門（AUSF）が本社の身元台帳（UDM/ARPF）に問い合わせるホットラインです。審査部門は「この客の照合材料（認証ベクトル）と審査方式を出して」と依頼します。台帳は秘密の原本（長期鍵K）は決して外に出さず、照合用に加工した派生データだけを渡します。原本は本社の金庫（ARPF）に閉じたまま、というのが要点です。

Overview — 概要¶

N13は AUSF ⇔ UDM を結ぶ参照点です。N13はSBI（Service Based Interface）である点が重要で、NF同士がWeb API（HTTP）でサービスを呼び合う仕組みに則り、共通の転送として HTTP/2 + JSON（RESTful）over TLS を用います。

N13の実体は、UDMが提供するサービス Nudm_UEAuthentication（TS 29.503） です。AUSFはこのサービスを呼び出し（認証情報の取得: Get）、UDMは内部の ARPF で長期鍵Kから認証方式（5G-AKA / EAP-AKA'）を決定し、認証ベクトル（5G HE AV 等） を生成してAUSFへ返します。また SIDF による SUCI→SUPI の復号もUDM側で実行されます。

参照点N13とサービスNudm_UEAuthenticationは同じものの2つの見方

3GPPのアーキテクチャ図では 参照点として N13（AUSF⇔UDM） が示されますが、SBA（サービス化）ではこれが実体として UDMのサービス Nudm_UEAuthentication として実装されます。つまり「N13」と「Nudm_UEAuthentication」は、同じAUSF⇔UDM間の連携を、参照点の視点／サービスの視点で見たものです。どちらも指しているものは同一で、呼び方（視点）が違うだけ、と捉えてください。

Basic Concept — 初心者向け説明¶

N13を、審査部門が身元台帳から照合材料を取り寄せるWeb APIに例えます。

あなたのスマホがネットワークに登録しようとすると、認証の司令塔であるAUSFが動きます。AUSFは「この客をどの方式で審査すればいい? 照合材料は?」を自分では作れません。加入者の秘密の原本（長期鍵K）を持っているのは本社の身元台帳、すなわちUDM内部のARPFだけだからです。

そこでAUSFは、身元台帳のWeb API（Nudm_UEAuthentication）へ「この客（SUCI/SUPI）の認証情報をください」とリクエストします。台帳側は、まず秘匿IDのSUCIを本来のSUPIへ復号（SIDF）し、ARPFで認証方式（5G-AKA / EAP-AKA'）を決めて認証ベクトルを生成し、それをAUSFへ返します。原本の鍵Kそのものは決して外に出しません——出すのは照合用の派生データだけです。

この問い合わせは、専用の電話回線（N2/N4のような専用プロトコル）ではなく、社内Webシステム（HTTP）でリクエストを投げて回答をもらうイメージで、要求も応答も人間に読みやすい JSON でやり取りされます。これが SBI（Service Based Interface） ＝NF同士がWeb API（HTTP/2）で会話する仕組みです。

Protocol / Transport¶

項目	内容
Protocol	HTTP/2 + JSON（RESTful）— SBI（Service Based Interface）の共通スタック
サービス	Nudm_UEAuthentication（UDMが提供）— TS 29.503
SBI framework	TS 29.500 / TS 29.501 系（SBIの共通規約・OpenAPI定義）
下位Transport	TCP、TLS で保護（機密性・完全性・認証）— TS 33.501
ポート	SBIの待受ポートは実装依存（NRF登録のエンドポイントで解決）。特定番号は断定しない
特徴	専用L4プロトコルではなくWeb技術ベース。HTTPメソッド＋リソースURIで操作。RESTful

N2/N4のような専用L4ではなくWeb技術ベース

N2は NGAP over SCTP:38412、N4は PFCP over UDP という専用の下位プロトコルを持ちますが、N13にはそれらは一切当てはまりません。N13はSBIなので、他のSBI（N8/N10/N12 等）と同じく HTTP/2 over TLS を共通の土台として使います。したがってN13の解析にSCTP固有のフィルタやPFCPのポート番号を流用してはいけません。

Architecture¶

N13がAUSFとUDMを結び、その手前でN12がAMF(SEAF)とAUSFを結ぶ、認証データの取得経路を示します。

flowchart LR
  AMF["AMF (SEAF)"]
  AUSF["AUSF"]
  UDM["UDM (ARPF/SIDF)"]
  UDR[("UDR (加入・認証データ)")]

  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;

図の読み方: 太い線(==>)のN13が、AUSF⇔UDMの認証情報取得（SBI/HTTP2）です。AUSFはN13でUDM/ARPFから認証方式の指示と認証ベクトルを取得し、SIDFによるSUCI→SUPI復号もUDM側で行われます。取得したベクトルを使い、AUSFは手前の N12（Nausf_UEAuthentication） でSEAF（AMF内）と実際の認証手続きを進めます。UDMは加入・認証データを内部的にUDRから参照します（点線）。N13は「認証材料を取り寄せる道」、N12は「取り寄せた材料でUEと認証をやり取りする道」という役割分担に注目してください。

利用Procedure¶

N13は Registration 中の認証手続きの中で、AUSFがUDMへ認証情報を問い合わせる際に使われます。

認証情報の取得（Get）: AUSFが Nudm_UEAuthentication_Get（SUCI または SUPI を指定）でUDMへ問い合わせる。
UDM側の処理: UDMは SIDF でSUCIをSUPIへ復号し、ARPF で認証方式（5G-AKA / EAP-AKA'）を決定して認証ベクトルを生成し、AUSFへ返却する。
認証の進行: AUSFは受け取ったベクトルを用い、N12 でSEAF（AMF内）と認証手続きを実行する。
結果の確認: 認証完了後、AUSFが認証結果をUDMへ通知・確認する（後述の ResultConfirmation）。

手順の詳細な流れ（メッセージシーケンス、5G-AKA/EAP-AKA'の分岐、認証ベクトルの要素・導出）は Authentication に集約されています。手順の細部・AV要素/導出の細部はそちらを参照してください（導出細部は要確認）。

主なMessage¶

N13はSBIなので、メッセージはHTTPメソッド + リソース操作の形を取ります（NGAPのようなprocedureCodeではなくRESTful操作）。代表的なサービスオペレーションは次のとおりです。

サービスオペレーション	HTTP操作(概念例)	用途
Nudm_UEAuthentication_Get	POST（認証情報の取得要求）	認証方式の指示＋認証ベクトルの取得（SUCI復号を含む）
Nudm_UEAuthentication_ResultConfirmation	POST（結果通知）	認証結果のUDMへの確認・通知

HTTP操作の対応は概念整理です: 上表の「HTTP操作」は理解のための対応づけであり、各オペレーションの正確なメソッド・リソースURI・呼び出し方向はTS 29.503のOpenAPI定義に従います。厳密なメソッド割り当ては要確認とします。各メッセージの詳細は Message辞典を参照してください。

Packet Analysis (Wireshark)¶

N13はSBIなので、キャプチャ上は HTTP/2 として観測されます（NGAP/SCTPのようなL4専用プロトコルは現れません）。

目的	Display Filter
HTTP/2メッセージを抽出	`http2`
ヘッダのパスで絞る（概念）	`http2.headers.path`（`:path` に `nudm-ueau` を含む）
JSONボディを見る	`json`（復号後）

Decodeの見どころ:

N13は TLSで暗号化されます。中身（HTTP/2ヘッダやJSONボディ）を見るには復号鍵（TLSセッションキー等）が必要です。鍵が無ければ tls の暗号化ペイロードとしてしか見えません。
復号できれば、HTTP/2の ヘッダ（:path に .../nudm-ueau/... を含むリソースパス）でオペレーションを識別できます。
ボディは JSON（認証方式の指示、認証ベクトル要素等）ですが、認証ベクトルは特に機微な情報であり、TLSで厳重に保護されます。復号鍵が無い限り中身は見えません。
N2のNGAP（バイナリ、SCTP上）と違い、N13はWeb的（HTTP/JSON）である点が観察の要です。SCTP固有のフィルタ（sctp.port 等）は使いません。

EPCとの比較¶

4Gでは: MMEは認証時、HSS から認証ベクトル(AV)を取得していました。これが S6a の Authentication Information Retrieval 手続き（Diameterベース、TS 29.272）です。長期鍵Kと認証ベクトル生成はHSS側にありました。
5Gでは: AUSFが N13（Nudm_UEAuthentication） で UDM/ARPF から認証方式の指示と認証ベクトルを取得します。Diameterから HTTP/2 + JSON（SBI） へ置き換わり（TS 29.503）、さらに恒久ID秘匿のための SIDF（SUCI→SUPI復号） がUDM側に加わりました。

4G (EPC)	5G (5GC)
S6a の Authentication Information Retrieval（AV取得部, HSS→MME）	N13（AUSF ⇔ UDM）
Diameter（専用L4上）	SBI: HTTP/2 + JSON over TLS
TS 29.272（S6a）	TS 29.503（Nudm_UEAuthentication）
HSS（長期鍵K・AV生成）	UDM（ARPF: K・AV生成、SIDF: SUCI復号）

4Gと5Gで「認証ベクトルをネットワーク側の加入者データ機能から取り寄せる」思想は共通ですが、5Gでは SUCIによる恒久ID秘匿と、それをSUPIへ戻す SIDF復号がUDM側に増えた点が大きな違いです。

3GPP Specification¶

3GPP TS 29.503 — Nudm_UEAuthentication サービス（認証情報取得, N13の実体）。個別章番号は要確認
3GPP TS 33.501 — 5Gセキュリティ（認証方式 5G-AKA / EAP-AKA'、認証ベクトル、SIDF、ARPF、長期鍵K・AV導出）。個別章番号は要確認
3GPP TS 29.500 / TS 29.501 — SBI framework（技術規約 / 設計原則・OpenAPI）。個別章番号は要確認
3GPP TS 23.501 §4 — システムアーキテクチャと参照点（N13の定義）
3GPP TS 23.502 — 手続き（登録・認証手続きにおけるN13の利用）

注記（要確認）: N13の実体が Nudm_UEAuthentication（TS 29.503）であること、認証方式・認証ベクトル・SIDF・ARPFの規定が TS 33.501 にあること、SBI共通framework が TS 29.500/29.501 系であることは、3GPPアーキテクチャの一般的整理です。各サービスオペレーションの細目章番号・正確なリソースURI・認証ベクトルの要素構成は Release により差異があるため個別には要確認とします。長期鍵K・AV導出の細部は TS 33.501 を参照してください。

Summary¶

N13は AUSF ⇔ UDM(ARPF) を結ぶ参照点で、SBI（Service Based Interface）であり、Protocolは HTTP/2 + JSON over TLS。
実体はUDMが提供するサービス Nudm_UEAuthentication（TS 29.503）。
AUSFはN13で 認証方式の指示（5G-AKA / EAP-AKA'） と 認証ベクトル を取得する。長期鍵Kからのベクトル生成は ARPF、SUCI→SUPI 復号（SIDF） もUDM側の機能。
参照点N13 = サービスNudm_UEAuthentication は同じAUSF⇔UDM連携の2つの見方。
4Gの S6a Authentication Information Retrieval（HSS→MME, Diameter, TS 29.272） に相当し、5Gでは SBI化（TS 29.503）＋ SUCI/SIDF による恒久ID秘匿が追加された。

Next Step¶

UDM — N13の相手側。ARPF（K・AV生成）/SIDF（SUCI復号）を内包
AUSF — N13でUDMから認証材料を取得し、N12でSEAFと認証を進める認証の司令塔
Authentication — 5G-AKA / EAP-AKA' 認証手続きの詳細
N12 — AMF(SEAF)⇔AUSF の参照点（N13の手前）
N8 — AMF⇔UDM の参照点（加入者データ管理）
Interface辞典 — 各参照点の確認