あなたの英語学習方法ではネイティブに伝わらない。
ネイティブに間違えられてしまう方法。それは英語リズム
スポンサードリンク

ホットスポットでの認証の問題を解消した「HotSpot 2.0」、IEEE 802.11uやWISPr 1.0/2.0に欠けた要素を追加(Impress Watch)

スポンサーリンク
スポンサードリンク

ホットスポットでの認証の問題を解消した「HotSpot 2.0」、IEEE 802.11uやWISPr 1.0/2.0に欠けた要素を追加
[元記事]
 Wi-Fiにおける暗号化の方式は、当初用いられていた「WEP」から「WPA」「WPA2」へと変遷したが、2017年に公表されたWPA/WPA2の脆弱性“KRACKs”を受け、2018年後半には新機能「WPA3」が提供予定だ。【この記事に関する別の画像を見る】 一方、SSIDやパスワードが公開されて運用されることの多いフリーWi-Fiでは、これまでならVPNなどを使って通信を暗号化する必要があった。こうした環境で、アクセスポイントとクライアント間の通信を傍受されない仕組みを提供するのが、すでに解説した「Wi-Fi CERTIFIED Enhanced Open」である。
 さらに、SSIDによらない認証手段を提供することで、接続先のSSIDをシームレスに切り替えてフリーWi-Fiを利用できるのが「Wi-Fi CERTIFIED Passpoint」、そのベースとなった標準規格が「IEEE 802.11u」、ホットスポットの設置・提供にあたって技術指標が「WISPr」となる。
 今回は、ホットスポットにおけるウェブ認証の仕様において、IEEE 802.11uやWISPrにかけていた点を定めることで、問題を解消することを目的とした規格「HotSpot 2.0」について解説していく。(編集部)
■ホットスポット接続時のウェブベース認証が問題
 というわけで、IEEE 802.11uは標準化されたものの、実際にはこれだけでは十分ではなかった。第18回(https://internet.watch.impress.co.jp/docs/column/nettech/1153347.html)で紹介したが、「IEEE ComSoc SCV」においてQualcomm Athelos VP TechnologyのBill McFarland氏が発表した”Service Provider Wi-Fi”のスライドの続きに、この辺りが簡潔に説明されているので、これを用いて説明しよう。
 IEEE 802.11uにおける問題点というか、不満点が以下に示されている。まずはホットスポットに接続した際のウェブベースでの認証が面倒なことに加えて、そもそも問題があるというものだ。
 ホテルなどではお馴染みの方法ではあるが、アクセスポイントそのものがSSIDの一覧に表示され、特にパスワードを入力しなくとも接続はできるが、その先でウェブ認証が必要とされるタイプのものとなる。このとき、リダイレクト画面が強制的に表示されることになるわけだ。
 例えばINTERNET Watchを読んでいたのに、いきなりウェブ認証画面に移動するなど、それまでのウェブセッションが継続できなくなってしまう。ときとして履歴までが破壊されてしまい、戻るボタンを押しても認証画面に行き着いてしまうこともある。
 特定のブラウザーを前提にした作りになっている場合、それ以外のブラウザーでは、そもそも認証画面に行き着かないこともあり、例えば、普段自分の使っているブラウザーでは認証ができないような事態に陥るケースもある。
 筆者の場合、iOSは使っていないので不明だが、WindowsやAndroidでは、OSやブラウザーのバージョンアップによって、最近このあたりの挙動はだいぶ改善してきたと感じている。ただ、これは要するにウェブ認証に絡んで起こっていたさまざまな問題に、OSやアプリケーション側で対処したというものであり、正しい対処法とは言い難い。
■使う場所で変わる登録方法、IEEE 802.11uやWISPr 1.0/2.0では細かな仕様が未定義
 加えて、IEEE 802.11uにしてもWISPr 1.0/2.0にしても、基本的なウェブ認証についてはきちんと網羅されてはいるが、細かい仕様までは定められていない。例えばホテルの場合だと、以下のように使う場所によって登録の方法が変わるなんてことも珍しくはない。
・個々の部屋で利用する場合は部屋番号と宿泊者の氏名を入力
・大広間/レセプション会場では特定のIDコードを入力
・ロビーなどではメールアドレスなどを入力
 こうした差異は、結局認証ページ側で吸収する必要があり、この結果として認証ページの標準化などは、夢のまた夢でしかない。これは、ユーザーにとっても面倒な話なのだ。まず、チェックインして部屋に入り、部屋番号と名前を入力して接続する。その後、荷物を置いてロビーやレストランへ移動すると、今度はメールアドレスの入力である。翌日、ホテル内の会場でセミナーに参加する際には、今度はIDコードの入力が必要、といった具合だ。
 このように別々の認証が必要な場合は、幸いにもそれぞれ異なるSSIDと認証ページが用意されるのが通例なので、そうなれば認証ページごとに別のクッキーが生成されることになる。このため、一度登録すれば、クッキーの有効時間内は認証情報が保存されるから、長期滞在でもしない限り何度も認証を繰り返す必要はない“はず”である。
 ただし、共通の認証ページに、宿泊者用の部屋番号、イベント参加者用のイベントID、ロビーなどのパブリックエリア用と、それぞれ入力欄を用意するページ構成になっている例もたまにみられる。この場合、移動のたびに認証をやり直す羽目になるという、壮絶に使いにくい環境となってしまうことがある(というか、あった)。こうなると、OSなりブラウザーの側では、もう吸収しきれない。
■パケットの流れないSSID、接続時間の限られるホットスポットにも問題が
 こうした問題とは別に、ホットスポットへ繋がったからといって、その先でインターネットにちゃんと繋がるとは限らない、という経験のある方も多いだろう。どことは言わないが、某空港のフリーWi-Fiでは、認証ページを経て「Internet Connected」と表示されても、その先にパケットが全然流れないことがあった。
 よく見ると、SSIDが「xxxxx-FreeWi-Fi」のほかに「xxxxx-FreeWi-Fi(2.4G)」や「xxxxx-FreeWi-Fi(5G)」のものがあり、これらに繋ぎ直すと、きちんとインターネットに繋がるなんていうケースがある。であれば最初から「xxxxx-FreeWi-Fi(2.4G)」に繋げばいいかというと、逆にこちらには繋がらず「xxxxx-FreeWi-Fi」だと繋がったりするから始末に負えない。この例のように、SSIDへの接続を総当たりで試すしかないというのは、ホットスポット利用者にとって、とても便利とは言いがたい。
 さらに、空港であれば60分や120分、海外のホテルでも24時間などに接続時間が限られている例も、よくみるものだ。こういう環境では、やや大きめのファイルのダウンロードやアップロード(筆者の場合で言えば、資料のダウンロードとか原稿のアップロードがこれにあたる)を進めても、思ったよりも時間が掛かり、結局途中でセッションが切られてダウンロードやアップロードが失敗してしまうことは珍しくない。
 対処法としては、クラウドストレージサービスと、レジューム可能なアップロード/ダウンロードツールを組み合わせ、セッションが途中切られても再開可能なようにしておく(ダウンロードの場合は、まずクラウドストレージにファイルをコピーし、それをツールでダウンロードする。原稿のアップロードでは、まずクラウドストレージにアップロードした上で、その所在をURLの形で相手にメールする)といったユーザー側の対処が必要になる。
 ただし、ファイルを直接操作できるときは問題ないのだが、PCやスマートフォンのアプリの中から操作する場合には、手に負えないこともある。
■IEEE 802.11uやWISPr 1.0/2.0で欠けていた要素を追加し、問題を解消する「HotSpot 2.0」
 ここまでに記したような問題をどう解決するかということで、「HotSpot 2.0」では、「IEEE 802.11u」や「WISPr 1.0/2.0」で欠けていた要素を追加して標準化する作業が行われることになった。
 まず、認証そのものでは、要するにウェブ認証を用いずに、自動でセキュアなコネクションが利用できる環境を構築しようという話になった。これは、SIMなどの情報を用いて自動的に認証を行うことですぐ利用できる携帯電話などのような環境を、Wi-Fiにも提供しようというものだ。具体的にHotSpot 2.0で追加された要素が以下の右となる。
 HotSpot 2.0のベースは、あくまでIEEE 802.11uながら、「ANQP」を拡張するとともにサインオンに関わる部分を追加したかたちになる。なお、ANQPそのものは、IEEE 802.11uというか、そもそもIEEE 802.11で既に定義されている。実際に、IEEE 802.11uの要素と、HotSpot 2.0で追加された要素の一覧が以下だ。
 右の一番下の項目にあるように、拡張された部分についてはGASフレームを利用して情報交換を行うことになっている。実際、追加された要素をTechnical Specificationで確認すると以下のようになっていて、ANQPにSubtypeが追加され、これを利用するかたちとなる。
■HotSpot 2.0からPasspointへ名称変更Wi-Fi AllianceとWBAの協調がきっかけ
 少し話を戻そう。2011年2月25日にIEEE 802.11uの標準化が完了したが、これを受けて同年3月11日、Wi-Fi AllianceはHotspotプログラムの開発をアナウンスしている。この時にはまだ、HotSpot 2.0の名前がそのまま用いられる予定だったが、前回も紹介した通り、WBAとの協調がアナウンスされた時点で、HotSpot 2.0の名前のままでは、WBAが推進していた「NGH」とHotSpot 2.0が並べるとそぐわないと、WBA側が難色を示した模様で、いろいろ問題があるということで、名称を変更して翌2012年6月26日に発表されたのが「Passpoint」となる。
 ちなみに、このPassPointは、当初予定では2012年のRelease 1に続き、2013年にはRelease 2、2015年にはRelease 3がリリースされることになっていたのだが、現時点の2018年でも、Release 3はまだ登場していない。

スポンサードリンク
スポンサーリンク

シェアする

  • このエントリーをはてなブックマークに追加

フォローする

スポンサーリンク