要約

  • RFC 9965 は、定義済みのプロビジョニング経路と限定的な未認証接続を求める NAI のために eap.arpa を確保した。
  • 要求、方式選択、サーバー認証、限定ネットワークの実施、資格情報の発行、通常利用の許可は、それぞれ別の記録であり別の判断である。

未知の端末が eap.arpa で終わる識別子を送る。ネットワークはこれを「資格情報を得るための支援を求める要求」と読めるが、資格情報そのものとしては読めない。そこに RFC 9965 The eap.arpa. Domain and Extensible Authentication Protocol Provisioning の静かな要点がある。

RFC が定義する EAP Provisioning Identifier（EPI）は、realm が eap.arpa. のサブドメインである NAI である。この realm は特定組織から独立するよう意図されている。既存 AAA への自動プロキシや、通常の動的ピア発見による解決を求めてはいない。一方で、組織がローカルにルーティングを決めることは禁じていない。共有された構文が示すのはピアの要求方法だけであり、受ける事業者が、受理するか、どこへ送るか、どんな証拠で扱うかを決める。

だから realm 文字列は弱い証拠である。EAP identity exchange で特定の要求が出たことは示せても、端末の所有者、責任組織、処理したバックエンド、認証方式が完了したかどうかは示さない。@method.eap.arpa を「信頼された端末」として記録するログは、一つの観測可能なメッセージを複数の未観測な判断にすり替えている。

RFC 9965 は判断前の状態も明確にする。EPI を使うピアは信頼できず、信頼してはならない。プロビジョニング方式が受理された後も、ピアは captive portal などの限定ネットワークに置かれなければならず、そのネットワークは無制限のアクセスを許してはならない。安全なプロビジョニングネットワークは期待される通信だけを許し、それ以外を遮断する。限られた悪性宛先だけを止める設計は、より大きく監査しにくい面を残す。

方式の境界も飛び越えられない。EPI は要求されたプロビジョニング方式を選ぶ。EAP サーバーが受理するなら、提供する方式は EPI に関連づく方式と一致し、その後に通常の EAP 状態機械が続く。RFC 3748 は EAP を複数方式の認証フレームワークとして定義し、認証されたピアであってもポリシーやセッション制限などでアクセスを拒まれ得ると述べる。方式選択は EAP 成功でも、一般的な認可でもない。

サーバー認証はさらに別の層である。RFC 9965 は eap.arpa. の各プロビジョニング方式にサーバー認証の方法を記すよう求め、サーバー認証、完全性、機密性を提供できるなら TLS ベースの EAP を推奨する。これは方式設計への要求であり、あるセッションが特定の証明書を検証した証明ではない。監査に必要なのは、EPI の要求、ローカルなルーティング判断、選択方式、サーバー認証の証拠、実施された限定ネットワーク規則、資格情報の判断、その後の利用判断を分けて残すことである。