N12 — AMF ⇔ AUSF（Nausf_UEAuthentication 参照点）¶

学習目標¶

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

• N12が SBI（Service Based Interface） であり、実体がAUSFの提供するサービス Nausf_UEAuthentication（TS 29.509） であることを説明できる。
• AMF内の SEAF（Security Anchor Function） がAUSFへ認証を委ね、5G-AKA / EAP-AKA' の認証手続きを進める流れを説明できる。
• 認証が成功すると、鍵階層の根である KSEAF が AUSF → SEAF へ渡されることを説明できる。
• 「参照点N12」と「サービスNausf_UEAuthentication」が同じものの2つの見方であることを説明できる。
• 4G(EPC)では認証が MME内（HSSから認証ベクトルを取得しMMEがAKAを実行）だった点との対比を説明できる。

前提知識¶

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

• SBA / SBI と HTTP/2・TLS の位置づけ → Protocol辞典
• N12の両端のNF → AMF / AUSF
• 認証手続き（5G-AKA / EAP-AKA'）の使われ方 → Authentication
• 鍵階層（KSEAF等）の考え方 → Security

Why — なぜ必要なのか¶

UEを網に入れる前には、まず「本当に正当な加入者か」を確かめる本人確認（認証）が必要です。もし誰でも接続できてしまえば、なりすましや不正利用を防げません。しかし、この認証機能をアクセス管理のNFが丸ごと抱えると、認証ロジックの変更がアクセス管理側に波及してしまいます。

そこで5Gでは、認証機能を独立したNF＝ AUSF（Authentication Server Function）に分離しました。一方、アクセス管理を担う AMF の内部には SEAF（Security Anchor Function） が置かれ、認証の錨（anchor）として認証手続きを仲介します。SEAFがAUSFへ「この加入者を認証してほしい」と依頼する道が N12 です。N12が無ければ、AMF(SEAF)はAUSFに認証を委ねられず、5Gの分離された認証アーキテクチャが成立しません。

例え話: N12は、受付（AMF/SEAF）が本人確認を専門審査部門（AUSF）に依頼するホットラインです。受付は本人確認を自前で完結せず、この専用回線で審査を依頼します。審査部門は本社名簿（UDM/ARPF）の照合結果（認証ベクトル）で審査し、合格したら合格の証（KSEAF）を受付へ渡します。

Overview — 概要¶

N12は AMF(SEAF) ⇔ AUSF を結ぶ参照点です。ただしN12はSBI（Service Based Interface）である点が、N2(NGAP/SCTP)やN4(PFCP/UDP)と決定的に異なります。SBIとはNF同士がWeb API（HTTP）でサービスを呼び合う仕組みで、共通の転送として HTTP/2 + JSON（RESTful）over TLS を用います。

N12の実体は、AUSFが提供するサービス Nausf_UEAuthentication（TS 29.509） です。AMF内のSEAFがこのサービスを Authenticate で呼び出して認証を開始し、5G-AKA / EAP-AKA' の認証手続きを進めます。認証が成功すると、鍵階層の根である KSEAF が AUSF → SEAF へ渡されます。なお、認証の判断材料となる認証ベクトルの元はUDM/ARPFにあり、AUSFはそれを N13（Nudm_UEAuthentication）経由で取得します（N12ではなくN13側）。

Basic Concept — 初心者向け説明¶

N12を、本人確認を審査部門に依頼するWeb APIに例えます。

あなたのスマホが網に接続しようとすると、アクセス管理のAMFが動きます。AMF内のSEAF（本人確認の錨）は、「この加入者は正当か」を自前で完結させず、専門の審査部門AUSFに問い合わせます（Authenticateで認証開始）。審査部門AUSFは本社名簿（UDM/ARPFの認証ベクトル）を照らし合わせ、5G-AKAやEAP-AKA'という手順で本人確認を進めます。合格すれば、AUSFは合格の証＝KSEAF（以降の鍵の根）をSEAFへ渡します。

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

Protocol / Transport¶

Architecture¶

N12がAMF(SEAF)とAUSFを結び、AUSFがN13でUDM(ARPF/認証ベクトル)と連携する文脈を示します。UEとはN1(NAS)上で認証メッセージをやり取りします。

flowchart LR
  UE["UE"]
  AMF["AMF (SEAF内包)"]
  AUSF["AUSF"]
  UDM["UDM (ARPF/認証ベクトル)"]

  UE -. "N1 (NAS認証メッセージ)" .- AMF
  AMF == "N12 (Nausf_UEAuthentication)" ==> AUSF
  AUSF == "N13 (Nudm_UEAuthentication)" ==> UDM

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

図の読み方: 太い線(==>)のN12がAMF(SEAF)⇔AUSFの認証依頼（SBI/HTTP2）です。SEAFがAUSFへ認証を委ね、AUSFはさらに N13 でUDM(ARPF)へ問い合わせて認証ベクトルを取得します。認証ベクトルはUDM→AUSFへ逆流し、AUSFが本人確認を進め、成功すればKSEAFがAUSF→SEAFへ渡ります。UEとの実際の認証メッセージ（RAND/AUTN、RES等）は、AMFを介して N1(NAS)* 上でやり取りされます。

利用Procedure¶

N12は Registration（登録） の中の認証手続きで登場します。SEAFがAUSFへ認証を委ね、UEとの間で認証チャレンジを交わす流れです。

• 認証開始: Registration中、SEAFが Nausf_UEAuthentication_Authenticate（SUCI/SUPIを提示）でAUSFへ認証を要求する。
• 認証方式決定/ベクトル取得: AUSFが N13（Nudm_UEAuthentication） でUDM/ARPFへ問い合わせ、認証方式（5G-AKA / EAP-AKA'）の決定と認証ベクトルの取得を行う。
• 認証チャレンジ: AMF ⇔ UE 間で N1(NAS) 上の認証メッセージ（5G-AKAならRAND/AUTNの提示、UEからのRES* 応答等）をやり取りする。
• 検証と鍵授受: AUSFで応答を検証し、成功すると KSEAF をSEAFへ渡す。以降の鍵はSEAFがKSEAFから導出する。

細部は要確認: RESの検証主体（AUSF側／SEAF側の分担）や、各メッセージの正確な搬送方向・IE構成は Release により差異があり、個別には要確認*とします。

手順の詳細な流れ（メッセージシーケンス、条件、鍵導出の細部等）は Authentication に集約されています。手順の細部はそちらを参照してください。

主なMessage¶

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

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

Packet Analysis (Wireshark)¶

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

Decodeの見どころ:

• N12は TLSで暗号化されます。中身（HTTP/2ヘッダやJSONボディ）を見るには復号鍵（TLSセッションキー等）が必要です。鍵が無ければ tls の暗号化ペイロードとしてしか見えません。
• 復号できれば、HTTP/2の ヘッダ（:path に .../nausf-auth/... を含むリソースパス）でオペレーションを識別できます。
• ボディは JSON（認証方式、認証チャレンジ関連の情報等）で構造化されています。
• N2のNGAP（バイナリ、SCTP上）と違い、N12はWeb的（HTTP/JSON）である点が観察の要です。SCTP不使用であり、SCTP固有のフィルタは使いません。

EPCとの比較¶

• 4Gでは: 加入者認証は MMEが主体でした。MMEが HSS から S6a（Authentication Information Retrieval） で認証ベクトル（AV）を取得し、EPS-AKA を MME ⇔ UE 間で実行していました（認証機能はMMEに内在）。
• 5Gでは: 認証機能を AUSF に分離し、AMF内の SEAF が仲介する構成になりました。AMF ⇔ AUSF が N12（SBI） で結ばれ、認証の実体は Nausf_UEAuthentication です。認証ベクトルの根はUDM/ARPFにあり、AUSFがそれを取得する道は N13側です。

認証主体がMMEからAUSFへ移ったのが5Gの核心です。5Gでは認証機能を独立NF(AUSF)に分離し、AMF内のSEAFが錨として仲介します。認証ベクトルの根がUDM/ARPFにある点は継続で、その取得は N13側の連携です。

3GPP Specification¶

• 3GPP TS 29.509 — Nausf_UEAuthentication サービス（AUSF提供、N12の実体）。個別章番号は要確認
• 3GPP TS 33.501 — 5Gセキュリティ（5G-AKA / EAP-AKA' の認証、KSEAF を含む鍵階層・鍵導出）。KSEAF導出式等の細部はこの規格に従い、本ページでは断定しない
• 3GPP TS 29.500 / TS 29.501 — SBI framework（技術規約 / 設計原則・OpenAPI）。個別章番号は要確認
• 3GPP TS 23.501 §4 — システムアーキテクチャと参照点（N12の定義）
• 3GPP TS 23.502 — 手続き（登録手続き中でのN12（認証）の利用）

注記（要確認）: N12の実体が Nausf_UEAuthentication（TS 29.509）であること、認証方式・鍵階層（KSEAF等）が TS 33.501 に規定されること、参照点N12とサービスNausfが同じ連携の2つの見方であることは、3GPPアーキテクチャの一般的整理です。各サービスオペレーションの細目章番号・正確なリソースURI・鍵導出の詳細は Release により差異があるため個別には要確認とします（鍵導出式はTS 33.501参照）。

Summary¶

• N12は AMF(SEAF) ⇔ AUSF を結ぶ参照点だが、SBI（Service Based Interface）である点がN2(NGAP/SCTP)・N4(PFCP/UDP)と根本的に異なる。
• Protocolは HTTP/2 + JSON（RESTful）over TLS、実体はAUSFのサービス Nausf_UEAuthentication（TS 29.509）。
• AMF内の SEAF がAUSFへ認証を委ね、5G-AKA / EAP-AKA' を進めて、成功すると鍵階層の根 KSEAF が AUSF → SEAF へ渡される。
• 参照点N12 = サービスNausf_UEAuthentication は同じAMF⇔AUSF連携の2つの見方（AUSF）。
• 4Gでは認証が MME内（HSSから認証ベクトル取得しMMEがAKA実行）だったが、5Gでは 認証主体がAUSFへ移り、AMF⇔AUSFが SBI化（N12） された。

Next Step¶

• AUSF — N12の相手側。認証サーバ機能（Nausf_UEAuthentication提供）
• AMF — 内部にSEAFを持ち、N12で認証をAUSFへ委ねるNF
• Authentication — 認証手続き（5G-AKA / EAP-AKA'）の詳細
• Security — KSEAFを根とする鍵階層の考え方
• N13 — AUSFがUDM/ARPFから認証ベクトルを取得する参照点
• Interface辞典 — 参照点・SBIの確認