要約

  • RFC 9965のEAP Provisioning Identifierは、固有資格情報のないピアが望むプロビジョニング方式を示す公開NAIである。端末の身元、所有、最終的な接続権を証明しない。
  • 受け入れたピアも信頼してはならない。必要通信だけを許可し、ピア間を隔離し、時間、データ量、サービス、試行頻度、同時接続数を個別に制限する必要がある。
  • プロビジョニング経路の閉鎖レシートは、EPI要求、実際の制御、期限切れまたは削除を結ぶ。この名称と記録形式はDaniel Kadeの編集提案であり、IETFの要件ではない。

「発行済み」はネットワーク状態ではない

初回接続には循環がある。ネットワーク認証には資格情報が要るが、端末はネットワークを通じてその資格情報を取得することがある。RFC 9965は、この循環を恒久的な例外ではなく、用途を宣言する既知の識別子で扱う。

EAP Provisioning Identifier（EPI）はRFC 7542のNAI形式を使う。eap.arpa realm配下の文字列によって、ピアは求めるプロビジョニング方式を伝える。IANAの現行レジストリには、EAP-NOOB用の@noob.eap.arpaと、EAP-TLSで限定されたポータル接続を求めるportal@tls.eap.arpaがある。

この識別子は出荷前から実装できるように既知である。したがって、希少な秘密ではない。文字列を提示できても、購入者、所属組織、在庫番号、現在の所有者とは結び付かない。正しいEPIは、正しい形式の要求を示すだけだ。

RFC 9965は、その限界を運用要件に落としている。EPIを使うピアは、信頼できず、信頼に値しないものとして扱う。ネットワークはローカル方針や容量を理由に拒否できる。要求を受け入れる場合も、与えるのは無制限接続ではなく限定ネットワークである。

ここで二つの成功が混同されやすい。EAP側の成功は、限定経路を成立させる。プロビジョニング側の成功は、証明書や設定を作成する。しかしアクセス装置に残るACL、動的ロール、セグメントの寿命は別の状態だ。発行サービスが完了を表示しても、古い経路が消えたとは限らない。

プロビジョニングの完了条件に閉鎖を含めなければ、最も弱い入口が成果物より長生きする。

予約名は権限委任ではない

eap.arpaはドメイン名のように見えるが、RFC 9965はNAIのrealmと、末尾の点を持つDNS名eap.arpa.を区別する。IANAのSpecial-Use Domain Namesに登録されているものの、通常のDNSやEAP以外のプロトコルで使う名前ではない。問い合わせにはNXDOMAINを返すべきだとされる。

つまり、EPIからインターネット上の権威を動的発見する設計ではない。受信したネットワークが、その識別子を理解するか、対応方式を提供するか、どのサーバーだけに到達させるかを決める。公開realmは、遠隔組織から届いた承認状ではない。

方式の取り違えも制限される。形式不正のEPIはEAP Failureとなる。未知のEPI、非対応方式、またはEPIに対応しない方式には、方式ゼロだけを含むEAP Nakを返す。プロビジョニング資格情報を起点に一般的な方式交渉へ流れてはならない。

この厳密さが保証するのは相互運用である。IETFは意味を定義し、IANAは識別子と方式の対応を維持し、アクセス運用者は限定経路を制御し、端末を保有する組織は最終登録を判断する。レジストリの行を端末認証として扱えば、異なる権限が一つに潰れる。

記録すべき単位はEPIそのものではなく、あるアクセス点で、ある方針版が、ある時間だけ生成した暫定セッションである。

制限は否定語ではなく許可表で作る

管理画面に「quarantine」と表示されても、データ面の範囲は分からない。RFC 9965は、想定する通信だけを許し、それ以外を遮断する設計を求める。危険と分かっている宛先だけを拒否する方法では、DNSなど見落としたサービスがトンネルとして使われ得る。

証拠には、適用されたFilter-Id、VLAN、ACL、動的ロールまたはコントローラー方針の識別子と版を含める必要がある。どの装置が実施したか、どの宛先・プロトコル・ポートが許可されたか、証明書検証や時刻同期などの補助サービスをなぜ含めたかも残す。デフォルト拒否は推測ではなく明示されるべきだ。

規格が挙げる制約は多次元である。

  • 処理時間は通常、数秒から数十秒程度であり、長期化は問題の兆候になり得る。
  • プロビジョニングに大量転送は通常不要なので、データ量を制限する。
  • 利用できるサービスの種類を目的に合わせて絞る。
  • 試行をレート制限し、不適切なピアを一時的または恒久的に遮断できるようにする。
  • 同時に処理するピア総数を制限する。RADIUSサーバーは無限に受け入れる義務を持たない。
  • 限定ネットワーク内のピア同士を通信させない。

一つの制約で他を代用できない。短時間でも全宛先へ出られれば範囲は広い。厳格な許可表でも期限がなければ恒久経路になる。同時数の上限があっても、ピア間通信を許せば未知端末同士が攻撃面を共有する。

セッションを連続させる抜け道にも注意が要る。一回ごとのTTLだけを見ると、期限切れ直後の再試行によって実質的な滞在が延びる。試行回数とレートは、端末固有IDがまだない段階でも、ポートや無線関連情報など適切に短命化した接続文脈で束ねなければならない。

RFC 9965はRADIUSのFilter-Idを制限適用の一例として挙げる。唯一の方式ではない。重要なのは、名前から実際の内容と版を再現できることだ。同じ名称の方針が後日広がれば、名前だけのログは過去のアクセス範囲を証明できない。

未知なのはピアであって、サーバーではない

「unauthenticated provisioning」は対称的な匿名性を意味しない。eap.arpa配下で定義される各方式は、サーバーを認証する方法を持たなければならない。EAP層で行う場合も、限定接続後のHTTPSなどで行う場合もある。いずれでもピアはローカルネットワークを信頼してはならない。

portal@tls.eap.arpaでは、ピア未認証のEAP-TLSでポータル用アクセスを求めるが、EAPサーバーは証明書などで認証される必要がある。誰でも知るPSKでは、この要件を満たす保証になりにくい。

この非対称性は合理的である。運用者は未知端末からの狭い通信を一時的に許す一方、端末は将来の長期資格情報を正しい提供元から受け取らなければならない。中間者に設定を渡されれば、その後の通常認証が正しく見えても信頼の起点は壊れている。

RFC 8952は、キャプティブポータルを一つの箱として扱わない。API URIを与えるProvisioning Service、状態を返すAPI、条件を扱うUser Portal、実際にパケットを制限するEnforcement Deviceがある。ポータル側の完了は、実施装置の状態変更を自動的には証明しない。

クライアントが保持する状態も古くなり得る。端末が認識する期限やバイト残量と、ネットワーク側の現状が一致しないことがある。最終的な閉鎖証拠は、パケットを止める装置またはそれを直接観測する仕組みから得る必要がある。

資格情報の生成と接続許可を分ける

プロビジョニングは、証明書、鍵参照、設定値、またはRFC 9140の帯域外手順の完了をもたらし得る。逆に、サーバー認証失敗、非対応方式、タイムアウト、容量超過、ローカル拒否で終わる場合もある。

すべてを「終了」にまとめると、次の判断が見えなくなる。資格情報が作られたことは、正しい資産レコードへの対応、失効状態、用途範囲、次回認証の成功を証明しない。

最も説明しやすい遷移では、限定EPIセッションを一度終了する。端末は新しい資格情報で通常認証を開始し、最新の認可方針が認証済みの主体に対して接続範囲を決める。通信が途切れなくても、権限判断は二つに分かれる。

同一接続内でロールを変更する実装でも、論理境界は保存できる。新しい資格情報の保護された参照、成立した認証ID、認可方針版、新ロールの適用、旧制限ロールの削除を別々に記録する。途中失敗時には、二つのロールを重ねるのではなく、狭い側へ戻す。

RFC 9966を扱った既存記事との違いもここにある。TLS-POKがBootstrap Keyに関する限定的な知識関係を証明しても、正当な保管経路までは分からない。本稿はその論点を繰り返さず、公開EPIの周囲に作られたネットワーク状態を対象にする。鍵の証明と経路の閉鎖は互いに代替できない。

閉鎖レシートに必要な七つの接合

ローカルなレシートは、次の項目を一つの短命セッションに結び付ける。

  1. 要求：EPI、EAP方式、到着時刻、AuthenticatorまたはNAS、インターフェース、短命な会話ID。
  2. 判断：受付・拒否、参照した方針版、容量状態、理由区分、責任を持つ判断サービス。
  3. 実施：フィルター、セグメント、ロールまたはACLの実版、全実施点、許可表、デフォルト拒否、ピア隔離。
  4. 予算：開始、強制期限、バイト、サービス範囲、試行数、レート状態、同時処理枠。
  5. サーバー保証：サーバーまたは配布データを認証した方式、証明書・トラストアンカー参照、検証結果、限定例外。
  6. 結果：成功、明示拒否、形式不正、方式不一致、認証失敗、期限・予算超過、手動終了。資格情報は秘密そのものではなく保護参照と寿命を記す。
  7. 閉鎖：期限切れまたは削除の時刻と理由、実施点からの観測、残存フロー処理、新しい認証セッション、孤児状態の照合。

公開用の説明に端末IDや証明書、精密な許可表を載せる必要はない。方針版、時間分布、失敗区分、例外件数、閉鎖遅延を集計し、非公開記録のハッシュと結ぶ方法がある。ただしハッシュは、元判断の正当性や装置の誠実さを証明しない。

「プロビジョニング経路の閉鎖レシート」はDaniel Kadeによる編集上の提案である。RFC 9965のフィールドでも、IETF適合証明でもない。標準は共通要求を定め、ローカル組織はその例外をどう終わらせたか説明する。

TTLの消失とルールの消失

コントローラーDBでTTLがゼロになっても、アクセス装置のルールが消えたとは限らない。削除命令が失われたり、旧世代に対して実行されたり、装置切断中に完了扱いになる可能性がある。逆に、装置側は削除済みでも中央表示が残る場合がある。

予定期限、制御面の削除、データ面の確認を分けて記録するべきだ。その時間差は運用不具合を示す資料であり、一つの成功時刻に丸めてはならない。自動失効と能動削除も違う出来事である。

失敗時こそ閉じる必要がある。ポータル停止を理由に一般接続へフォールバックしてはならない。証明書サービスの遅延を無記録で延長してはならない。設定受信に失敗した端末を無期限待機させてもならない。安全な障害は、狭い状態のまま予測可能に終わる。

レビューでは、意図した方針、実行中に観測した方針、終了後の残存状態を並べる。差異は緑色の総合評価に吸収せず、未解決事項として保持する。

Heng LuのPolicy Mirrorに従えば、文書は正規の権限を、動作中の設定は実効的な権力を示す。両者を比較でき、例外が自らの終了証拠を残すとき、暫定経路は初めて統治可能になる。

限界と出典

資料は規格、レジストリ、明示されたリスクを示すが、RFC 9965の普及率、特定運用者の導入、事故や費用効果を示さない。制御方式、時間、プライバシー境界は環境ごとに異なる。

提案レシートは端末ID、接続資格、法的承認、ディレクトリオブジェクトではない。主張は限定される。未知ピアに一時経路を与えたなら、その範囲と終了を、次の独立した認証判断と混同せずに証明するべきだ。