再びお会いしましたね？
GMOコネクトの名もなきエンジニアです。
よろしくお願いします！
日刊IETFは、I-D AnnounceやIETF Announceに投稿されたメールをサマリーし続けるという修行的な活動です！！
今回は、2026-01-06（UTC基準）に公開されたInternet-DraftとRFCをまとめました。Part 2では残りの12件をご紹介します。
- Internet-Draft: 31件（全体）
- RFC: 1件（全体）
- Part 2掲載分: 12件
Part 1では、ゼロポート・アーキテクチャ（UZPIF）、PQC、AIエージェント認証という三大トレンドをご紹介しました。Part 2では、これらの具体的な実装層に踏み込みます。
Part 2で特に注目すべき提案：
- UZP（Universal Zero-Port Transport Protocol）：UZPIFの具体的なトランスポート仕様で、アイデンティティアドレス指定と暗号化デフォルトを実現
- TLS-DPA：ゼロポートトランスポート上で動作するアイデンティティバインド型セキュリティプロトコル
- OAuth 2.0 Extension for AI Model Access：AIモデルAPIへのアクセス制御を標準化する拡張仕様
- RFC 9908（EST CSR属性の明確化）：証明書管理の自動化における長年の曖昧さを解消
参照先:
Part 2のハイライト：理論から実装へ
Part 1でUZPIF（ゼロポート・アーキテクチャのフレームワーク）を紹介しましたが、**「で、実際どう実装するの？」**という疑問を持った方も多いはずです。Part 2では、その答えが明らかになります。
UZP + TLS-DPA：ゼロポートの実装仕様が固まった
UZP（Universal Zero-Port Transport Protocol） は、UZPIFの具体的なトランスポート層実装です。両エンドポイントがRendezvous Nodeへアウトバウンドセッションを確立し、RNがフロースティッチングを行いながらもエンドツーエンド暗号化は終端しません。信頼性もTCPのようなセグメント単位ではなくブロック単位で表現され、選択的再送信が可能です。
さらに、TLS-DPA はUZP上で動作するアイデンティティバインド型セキュリティプロトコルで、TLS 1.3の設計思想を受け継ぎつつ、サーバー側リスナーに依存しない仕組みを実現しています。認証がネットワーク座標（IP:port）ではなくサービスアイデンティティにバインドされる点が革新的です。
この2つの仕様を読むと、「ゼロポートって本当に実装できるんだ」という確信が持てます。3年後には実際に稼働するサービスが出てくるかもしれません。
OAuth 2.0がAIモデルAPIに対応：AIエージェント時代の標準が動き出す
OAuth 2.0 Extension for AI Model Access は、AIモデルAPIへのスコープ付きアクセス委任を標準化する提案です。支出制限やモデル制限といったAIワークロード特有のトークン制約が定義されており、「GPT-4へのアクセスは月100ドルまで」といった制御が標準的な方法で実現できるようになります。
AIエージェントが自律的にAPIを呼び出す時代において、アクセス制御の標準化は必須です。この提案がRFC化されれば、OpenAI、Anthropic、Googleなどの主要AIプロバイダーが統一的なアクセス制御フレームワークを採用する可能性があります。
その他の注目提案
- Composite ML-DSA in TLS 1.3：PQC署名と従来暗号を複合化し、どちらか一方が破られても安全性を保つハイブリッドアプローチ
- Kerberos SPAKE with 2FA：TOTPを第二要素として統合し、Kerberos環境のセキュリティを大幅強化
- RFC 9908（EST CSR属性の明確化）：RFC 7030の曖昧さを解消し、証明書管理自動化の実装間互換性を向上
- CBOR::Core：決定論的エンコーディングを義務化し、署名・ハッシュ可能な厳密なCBORプロファイル
Part 2は全体的に「実装者向け」の内容が多く、プロトコル仕様を読み込むのが好きな方にはたまらない内容だと思います。
投稿されたInternet-Draft
Distributed Remote Attestation
多くの展開では、リモートアテステーションが独立した管理・信頼ドメイン内で実行されます。各ドメインは独自の管理プレーンとRemote Attestation Service（RAS）を運用し、検証者入力（エンドースメント素材、参照値）を取得して検証結果を生成します。大規模なクロスドメインシナリオでは、(1) ポリシー管理された透明性により、あるドメインの検証者や依拠当事者が他ドメインから選択されたアテステーション成果物を発見・取得できるようにすること、(2) 検証者入力と検証者出力を多対多で配布・再利用し、ポイントツーポイント統合を不要にすることが課題です。本文書は、来歴とアクセス制御を考慮した共有公開チャネルを使用する分散リモートアテステーション（DRA）パターンを説明します。具体例として分散台帳（DL）を取り上げ、DL上で検証ロジックをホストするオプションも議論されています。
Use of Composite ML-DSA in TLS 1.3
PQC署名ML-DSAと従来の署名アルゴリズムを複合化することで、ML-DSAまたはその実装における潜在的な脆弱性や重大なバグから保護できます。本文書では、ML-DSAをRSA-PKCS#1 v1.5、RSA-PSS、ECDSA、Ed25519、Ed448と組み合わせて複合署名を形成し、TLS 1.3で認証に使用する方法を規定します。量子耐性と従来暗号の安全性を同時に活用する実用的なハイブリッドアプローチとして、TLS通信の長期的なセキュリティ確保に貢献します。
Automatic Peering for SIP Trunks
エンタープライズテレフォニーSession Initiation Protocol（SIP）ネットワークが、SIPサービスプロバイダーから機能セット文書を要請・取得できるフレームワークが規定されました。機能セット文書は、エンタープライズとサービスプロバイダーのSIPネットワーク間での容易なピアリングを可能にする一連の特性をエンコードします。SIPトランク接続の設定自動化と相互運用性向上により、企業の通信インフラ導入が効率化されます。
Kerberos SPAKE with Two-Factor Authentication
Kerberos SPAKE事前認証に対応する新しい二要素認証メカニズムが定義されました。Time-based One-Time Password（TOTP）を第二要素として使用し、パスワード要素とより安全な方法で組み合わせます。いずれかの要素が漏洩した場合でも、Kerberosクライアントのなりすましとチケット発行チケット（TGT）のセッション鍵取得の両方を防ぐことができる設計となっています。Kerberos環境におけるセキュリティ強度の向上とフィッシング耐性の実現に寄与します。
CBOR : : Core - CBOR Cross Platform Profile
インターネットブラウザ、携帯電話、Webサーバーなど計算能力の高いシステムでJSONの代替として機能するよう設計された、プラットフォーム非依存のCBORプロファイル「CBOR::Core」が定義されました。厳密性を高め、署名やハッシュなどの暗号手法を「生の（非ラップ）」CBORデータに適用できるようにするため、決定論的エンコーディングが義務付けられています。安全な方法でCBORデータを操作するためのAPI機能も概説されており、主にCBORツール開発者を対象としています。
New requirements for Authentication and Authorization in the AI Agents era
AIエージェントは学術的概念から次世代アプリケーションの中核エンジンへと急速に進化していますが、その自律性、動的な性質、複雑な委任関係は、人間のユーザーと従来のソフトウェアを想定して設計された既存の認証・認可フレームワークに根本的な課題をもたらします。本文書では、AIエージェントの新しい特性を分析し、静的なアイデンティティ検証ではなく動的な振る舞いを管理できる認証・認可の新要件を概説します。AIエージェント時代のセキュリティモデル構築に向けた重要な問題提起となっています。
Secret Key Agreement for DNS: The TKEY Resource Record
RFC 8945は共有秘密鍵とTransaction Signature（TSIG）リソースレコード（RR）を使用してDNSプロトコルメッセージの効率的な認証を提供しますが、設定以外での鍵セットアップメカニズムは規定していません。本文書では、DNSリゾルバとサーバー間で共有秘密鍵を確立するために使用できるTransaction Key（TKEY）RRを規定します。RFC 2930を廃止する更新版として、DNSの動的な鍵管理と認証基盤の強化を実現します。
UZP: Universal Zero-Port Transport Protocol
Universal Zero-Port Interconnect Framework（UZPIF）向けに設計された、アイデンティティアドレス指定と暗号化デフォルトのトランスポートプロトコル「UZP」が定義されました。IP:portリスナーを公開する代わりに、両エンドポイントがRendezvous Node（RN）へのアウトバウンド、アイデンティティバインドセッションを確立します。RNはフロースティッチングを実行しますが、エンドツーエンド暗号化を終端せず、長期秘密も保持しません。すべてのアプリケーションデータは、最新のPQC対応プリミティブに基づくハンドシェイクで鍵付けされた認証暗号化 (AEAD) チャネル上で伝送されます。信頼性はセグメント単位ではなくブロック単位で表現され、選択的再送信と決定論的なペーシングが可能です。ワイヤフォーマット、ハンドシェイク、暗号ネゴシエーション、エクスポーターインタフェース、0-RTTルール、リプレイモデル、RN動作、およびQUIC、HIP、TLS 1.3との関係が規定されています。
TLS-DPA: An Identity-Bound Security Protocol for Traditional, Overlay, and Zero-Port Transports
TLS 1.3の設計に触発された実験的なアイデンティティバインドセキュリティプロトコル「TLS-DPA」が提案されました。従来のIPアドレスとポートのセマンティクスが弱い、不安定、または意図的に欠如している環境（UZPなどのゼロポートトランスポート）で一貫して動作するよう設計されています。TLS-DPAはハンドシェイクをサーバー側リスナーに依存しないように一般化し、認証をネットワーク座標ではなくサービスアイデンティティにバインドし、中間者（UZPファブリックのランデブーノードを含む）へのメタデータ露出を削減し、統一されたハイブリッドKEM PQC移行モデルを提供し、オーバーレイパス変更（QUICのConnection IDなど）を越えたセッション継続をサポートします。
OAuth 2.0 Extension for AI Model Access
AIモデルAPIへのスコープ付きアクセスを委任するためのOAuth 2.0拡張が定義されました。標準化されたスコープ構文、AIプロバイダー向けリソースインディケーター、支出制限やモデル制限を含むAIワークロードに適したトークン制約が導入されます。AIサービスのアクセス制御と利用管理を標準化し、AIエージェントやアプリケーションが安全かつ制御された方法でAIモデルを活用できる環境を整備します。
発行されたRFC
Clarification and Enhancement of the CSR Attributes Definition in RFC 7030
RFC 7030「Enrollment over Secure Transport（EST）」が更新され、Certificate Signing Request（CSR）Attributes Responseの使用方法が明確化されました。ESTサーバーがCSR属性Object Identifier（OID）とCSR属性値（特にX.509拡張値）の両方を指定し、クライアントが後続のCSRリクエストに含めることを期待する値を明示できるようになります。RFC 9148も更新対象です。RFC 7030ではCSR Attributes Responseの仕様が曖昧で、実装上の課題と理解の不一致を招いていました。本文書はエンコーディングルールを明確化するとともに、サーバーが部分的に埋められる可能性のあるCSR内容のテンプレートを使用する新しい直接的なアプローチも提供します。これにより、ESTサーバーがSubject Distinguished Name（DN）を指定することも可能になります。
編集後記
Part 2では、Part 1で紹介したUZPIFの具体的な実装層であるUZPとTLS-DPAが登場し、ゼロポートネットワーキングのビジョンが技術的に具体化されました。
個人的に、UZPのワイヤフォーマットやRN動作の仕様を読んでいて「これ、本当に動くな」と確信しました。Part 1では「公開ポートを廃止するなんて夢物語じゃないか」と思った方もいるかもしれませんが、Part 2の詳細仕様を読むと、実装可能性が見えてきます。もちろん、既存インフラとの相互運用性や移行パスの設計は簡単ではありませんが、10年スパンで考えれば現実的なロードマップです。
PQCの実装は今やTLS 1.3、OpenPGP、UZPと多様なプロトコルに浸透しつつあり、量子コンピュータ時代への備えが本格化していることを実感します。Composite ML-DSA のアプローチは、「量子耐性暗号だけに賭ける」のではなく、「従来暗号と組み合わせて二重に保護する」という堅実な戦略で、実務的な安心感があります。
AIエージェント認証認可やAIモデルAPI向けOAuth拡張など、AI時代のセキュリティフレームワークの標準化も始まっており、技術の進化スピードに圧倒されますね。特にOAuth 2.0のAI拡張は、「GPT-4への月100ドルまでのアクセス権限」のような細かい制御を標準的な方法で実現できる点が実用的です。OpenAI、Anthropic、Googleなどが将来的にこの標準を採用してくれることを期待しています。
RFC 9908（EST CSR属性の明確化） も地味ですが重要な更新です。RFC 7030の曖昧さに悩まされていた実装者にとっては「やっと！」という感じでしょう。証明書管理自動化の相互運用性が向上することで、PKI運用の負担が軽減されます。
📌 次にやるべきこと
今日の記事で興味を持った提案があれば、ぜひdatatracker.ietf.orgで原文のInternet-Draftを読んでみてください。特に以下は実装を検討する価値があります：
- UZP + TLS-DPA：概念実証（PoC）を作って動作を確認してみる
- OAuth 2.0 AI Extension：自社のAI APIアクセス制御に適用できるか検討
- Composite ML-DSA：TLS 1.3の実装に組み込む準備を始める
皆さんはPart 1とPart 2を通して、どの提案が一番「これは実装したい」と思いましたか？Xやコメントでぜひ教えてください！また、実際に実装を試してみた方がいたら、知見を共有していただけると嬉しいです。
Part 1はこちら：
日刊IETF (2026-01-06) Part 1 - ゼロポート革命×PQC実装×AIエージェント認証の最前線
最後に、GMOコネクトでは研究開発や国際標準化に関する支援や技術検証をはじめ、幅広い支援を行っておりますので、何かありましたらお気軽にお問合せください。