Captive Portal(CAPPORT) APIについて
ユーザーのデバイス(以下UE)とCaptive Portalが対話できる仕組み，CAPPORT APIというアイデアが現在インターネットドラフト段階でIETFのcapport WGで標準化されようとしています．これは現在ユーザーがCaptive Portalアクセス時に手動でメールアドレスなどの個人情報をブラウザから入力するのを自動化する取り組みです．今回はこちらについてまとめてみました．
実際の無線LANの認証・認可のフローから見ると，下記の部分で使われる予定です．
This figure is deprived from here.
CAPPORT APIを用いた際のフロー
前提: DHCP optionまたはIPv6 RAsが提供されなければならない．
- 第一段階: DHCP optionかIPv6 RAsを用いて，UEがIPアドレスの取得・ローカルのCAPPORT APIサーバーのURLを取得します．
- 第二段階: まず，UEがCaptive Portalでアクセス制御がされているネットワークにアクセスするために必要な条件を，第一段階で取得したURLを用いてCAPPORT APIサーバーに問い合わせます．そして，必要なプルーフをサーバーに送ります(自分の名前やメールアドレス等).
- 第三段階: UEがネットワークへのアクセスを許可され，CAPPORT APIサーバーにステータスを問い合わせることができます．
(各フェーズを下記に描いてみました)
UEとCAPPORT APIサーバーは，JSONのデータフォーマットでやりとりします．
上記の図の中の該当箇所で下記のようなやり取りが行われます．
{ “networks” : {},
“session-token” : “”
}
❹UEからの問い合わせに対し，CAPPORT APIサーバーは使えるネットワーク，条件，セッショントークンを返します．
{"networks" : {
"DEFAULT": {"conditions" : [ {"id" : "...”,"type" : "t&c”,"requirement_details" : {"text" : “I will do whatever you say”} } ],"state" : {"permitted" : false}} },"session-token" : "…“}
❼提示された条件をUEが満たす
{ “networks” : {“DEFAULT” : {“conditions” : [“id” : “...”,“satisfaction_details” : {“text” : “1e173b7bb0d114bb38438c15b9eb9736”}]}},“session-token” : “…”}
ここまでの一連の流れは繰り返されます．
❽CAPPORT APIサーバーがUEのインターネットへのアクセスを許可します
{"networks" : {"DEFAULT": {"state" : {"permitted" : true,“expires” : “2036-01-01T00:00:00Z”,“bytes_remaining” : 987654321},"session-token" : "…”}
インターネットアクセスを得るための条件
インターネットアクセスを得るために個人情報を入力したり，一定時間広告を見せられたり...いろんな条件があると思います．それぞれの条件は，個別に"type" string, requirement_details, its satisfaction_detailsの3つを定める必要があります．
最も一般的だと思われる，利用規約に同意するケースと，パスコードを入力するケースがドラフトの下の方に載っています．
補足
ユーザーが公衆無線LANでインターネットアクセスを得るために，Webブラウザを用いて必要な手順を入力するという手順がありますが，このやりとりを自動化する手法が CAPPORT APIです．このメカニズムは, ユーザーにHTMLフォームを提示するよりも安全性が高いという条件を満たします．ただ，やりとりに含まれる情報にはメールアドレスや名前などの個人情報が含まれる可能性があるため，暗号化されていないセッション上での，UEとCAPPORT APIサーバーの通信は危険だと言えるでしょう．
IETF98 Hackathonで実際に実装されたものがあるので興味のある方はこちらも．
