要約

  • 証明書パス、CertificateVerify、Finished は、EAP-TLS の暗号学的事実を示す。VLAN の存在、ACL の反映、制御ポートの開放までは示さない。
  • EAP の仕様は、認証後に許可が拒否される場合と、許可後に認証器がサービスを提供できない場合を明示的に分けている。
  • 証拠は、証明書、EAP、AAA、鍵配送、NAS のローカル実行、最初の実通信まで連結しなければならない。一つの緑色表示に全権限を持たせてはならない。

暗号処理は完了し、接続処理は止まった

構成された例の 08:14:02、端末は EAP サーバーの証明書パスと名前を確認し、サーバーは端末証明書を確認する。CertificateVerify は秘密鍵の所持を示し、Finished は保護された handshake transcript の一致を示す。認証画面には成功が記録される。

08:14:03、AAA は認証済みの証明書情報に NAS、物理ポート、要求サービスを組み合わせ、特定の role と VLAN を返す。ポリシー画面も成功になる。

08:14:04、アクセススイッチは、その VLAN を必要な forwarding context に作れないことを検出する。要求されたサービスを実行できないため、制御ポートは閉じたままである。DHCP も IPv6 設定もアプリケーション通信も始まらない。

これは実在組織の障害報告ではない。RFC 5216、RFC 3748、RFC 3579 が分けている状態を一つの時系列に置いた分析例である。各装置の記録は正しくても、「接続成功」という集約だけが誤り得る。

証明書の権限はどこまでか

RFC 5216 は TLS を利用し、証明書による相互認証、完全性を保護した暗号方式の交渉、鍵交換、EAP 鍵素材の導出を行う。パス検証は、採用した信頼方針の下で証明書が信頼 anchor に結び付くかを判断する。CertificateVerify は対応する秘密鍵の所持を、Finished は同じ保護済み transcript と secret に到達したことを検証する。

これらは強い証拠だが、スイッチポートの現在値、VLAN の容量、ACL の反映結果、アプリケーションの応答を含まない。証明書の SAN や subject は許可判断の入力になれるが、判断を実行する装置ではない。

現在の EAP-TLS は 2008 年の文書だけでは完結しない。RFC 8996 は TLS 1.0 と 1.1 を非推奨にし、RFC 9190 は TLS 1.3 の message flow と key schedule を定めた。RFC 9965 は eap.arpa provisioning を加えた。更新された規範は重要だが、文書の存在は実装や運用結果の測定ではない。

RFC 9190 の Authorization 節は、TLS 版にかかわらず EAP-TLS 一般に適用される。外側の EAP-Response/Identity は EAP-TLS によって認証されないため、許可や accounting は証明書、PSK identity、再開用の保存状態など、認証された情報に基づかなければならない。NAS、MAC、IP、ポート、SSID といった外部情報も判断材料になる。つまり、暗号認証は許可に入力を渡すのであって、許可全体ではない。

Success の後にも決定が残る

RFC 3748 は、認証結果が同期しても許可状態まで同期するとは限らないと説明する。AAA proxy が EAP サーバーの知らない決定を行うことがある。AAA サーバーは認証成功後に許可不可と判断できる。許可しても、認証器が一時的な資源不足でサービスを提供できない場合もある。

この三つは別の境界である。誰が決めたか、許可されたか、ローカルで実行可能かを一つの success counter では区別できない。

RFC 4137 の EAP state machine が下位層へ返す結果も、その state machine の結論である。eapSuccess は forwarding table や address assignment を読み取るセンサーではない。

同じ鍵を持つことと、持つ権限

RFC 5247 は EAP method、AAA key transport、secure association を段階に分ける。最初の段階は peer と server の間で MSK/EMSK を導出する。次に適切な材料が authenticator へ送られ、最後に所持確認と transient key の生成が行われる。

同文書は、鍵素材を所持している証明が、その鍵を所持する権限の証明とは限らないと明記する。ローカル handshake が正しい鍵の共有を示しても、backend がその NAS にその peer の鍵を渡すことを許可したかは別問題である。

RFC 4962 は peer と authenticator の authorization を要求する。RFC 4017 は相互認証、鍵強度、許可を別要件とする。RFC 5295 は EMSK 派生鍵の用途と範囲を制限する。秘密であることは、無制限に使ってよいことを意味しない。

Access-Accept を実行できない装置

RADIUS を使う一般的な構成では NAS が EAP を中継する。RFC 3579 の Access-Reject は拒否を要求し、Access-Accept は認証段階を終えて role、VLAN、filter などを渡せる。

しかし、要求されたサービスを NAS が提供できなければ、その Accept は Reject として扱わなければならない。RFC 3580 も、RADIUS packet type と内部の EAP Success/Failure が矛盾する場合を扱い、アクセス制御は isolated EAP message ではなく RADIUS decision に従うとする。

backend log は指示を送った証拠である。属性を理解したか、VLAN を解決したか、ACL を入れたか、secure association を終えたか、port を開いたかは NAS が証明する。その後の DHCP、Neighbor Discovery、DNS、application はさらに別の証拠である。

NAS が異なるネットワークを語るとき

RFC 6677 は lying NAS / lying provider 問題に対し、peer と server が保護された経路でネットワーク属性の見方を比較する channel binding を定義する。

この仕組みが必要なのは、端末証明書が SSID、port、visited provider、lower layer の性質を認証しないからである。context が一致しても、それは定義された属性の証拠であり、その後の packet delivery ではない。

RFC 7542 は NAI を整理し、RFC 9427 は TLS 1.3 を TLS-based EAP method に統合する。いずれも証拠の接合を正しくするもので、段階を飛ばすものではない。

再開 ticket は権限を凍結しない

RFC 9190 では、受理された TLS 1.3 resumption は以前の認証に安全に関連付けられた認証済み session と扱われる。同時に、元の session が意図した以上の権限を与えないよう注意を求める。

ticket が有効な間にも、証明書の revoke、所属変更、NAS 移動、SSID policy 更新、VLAN 廃止は起こる。certificate validity、revocation、ticket lifetime、authorization、port session、service health は別の時計である。

OCSP stapling などは、一般ネットワーク接続前の revoke check を助ける。それでも、認証後にサービスが届いたことは別途観測しなければならない。

失敗地点を保存する

PKI receipt は anchor、chain hash、検証名、有効期間、revoke verdict を持つ。TLS receipt は version、suite、CertificateVerify、Finished を秘密を漏らさず保存する。EAP receipt は method と protected result を保存する。

AAA receipt は peer identity、NAS、context、policy version、Accept/Reject、attributes を残す。key transport は受取人と scope を残す。NAS receipt は attribute 解釈、VLAN/role、ACL、association、port state を残す。service receipt は address、neighbor、DNS、route、最初の application success を残す。

「証明書は有効、許可は拒否」「Accept は到着、service は unavailable」「port は open、application は failure」は矛盾ではない。境界を保存するほど、修復は速くなる。

出典

  1. RFC 5216
  2. Datatracker の RFC 5216
  3. RFC 5216 status
  4. RFC 5216 history
  5. RFC 5216 errata
  6. RFC 9190
  7. RFC 3748
  8. RFC 5247
  9. RFC 4017
  10. RFC 6677
  11. RFC 8996
  12. RFC 9965
  13. RFC 7542
  14. RFC 3579
  15. RFC 3580
  16. RFC 4137
  17. RFC 4962
  18. RFC 5295
  19. RFC 9427
  20. Heng Lu — Running-Code Primacy
  21. Heng Lu — Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption