302リダイレクトを使わずにCaptive Portalの認証ページへユーザーを誘導できる？RFC7710
CAPPORT WGでは現在RFC7710 Captive-Portal Identification Using DHCP or Router Advertisements (RAs)の改変が行われそうな雰囲気なので、RFC7710について一旦このへんでまとめておく。
背景
現在のCaptive Portalはユーザーのセッションを横取りし、302リダイレクトを用いて強制的にユーザーを認証/同意ページに誘導する、いわば中間者攻撃のような挙動をとるものがほとんどです。この挙動がCaptive PortalにおいてUXを損なっているという背景から、認証/同意ポータルページへ誘導する別の手段が必要とされています。
The Captive-Portal Option
ユーザーのデバイスに「Captive Portalの存在」と「ポータルにコンタクトをとる方法」を知らせるために、DHCPオプションやRAの拡張を用いて、Captive PortalのURIをユーザーのデバイスに広告する方法が挙げられています。いずれも基本的にはCode, Length, URIを含む構成となります。(今のところ、URIは実際にユーザーがアクセスすることとなるポータルのURI、またはCAPPORT APIのURIということになっています。)
まとめ:
RFC7710は、DHCP/RAのオプションを用いて、デバイスにIPアドレスを割り振る際に、同時にCaptive PortalのURIも配ってしまおうというものです。それにより、以下を実現できます。
- ユーザーとCaptive Portal間の手続きの簡素化
- ハイジャックに代わる、よりクリーンな方法の提供(=セキュリティ向上にもなる?)
関連の最新の議論:
- CAPPORT WGでは他にも、ユーザーとCaptive Portal間の認証情報の手続きを自動化する、CAPPORT APIが策定されており、RFC7710で配るURIはそもそもAPIサーバーのURIなのか、またはポータルページのURIと定義すべきか？
- “there’s no captive portal to talk to”というシグナルを送る機構が必要
等複数議題が上がっており、本RFCのアップデートも含め、IETF101では議論されそうです。
