にたまご。

よく寝てよく食べる

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 PortalURIをユーザーのデバイスに広告する方法が挙げられています。いずれも基本的にはCode, Length, URIを含む構成となります。(今のところ、URIは実際にユーザーがアクセスすることとなるポータルのURI、またはCAPPORT APIURIということになっています。)

f:id:ao0780:20180303163613p:plain

f:id:ao0780:20180303163605p:plain

  • IPv6 RA option: Type 37。このType code37は、RFC7710のためにIANAがアサインしてくれたものです。

f:id:ao0780:20180303163609p:plain

まとめ:

RFC7710は、DHCP/RAのオプションを用いて、デバイスIPアドレスを割り振る際に、同時にCaptive PortalURIも配ってしまおうというものです。それにより、以下を実現できます。

  • ユーザーとCaptive Portal間の手続きの簡素化
  • ハイジャックに代わる、よりクリーンな方法の提供(=セキュリティ向上にもなる?)

関連の最新の議論:

  • CAPPORT WGでは他にも、ユーザーとCaptive Portal間の認証情報の手続きを自動化する、CAPPORT APIが策定されており、RFC7710で配るURIはそもそもAPIサーバーのURIなのか、またはポータルページのURIと定義すべきか?
  • “there’s no captive portal to talk to”というシグナルを送る機構が必要

等複数議題が上がっており、本RFCのアップデートも含め、IETF101では議論されそうです。