Wireless・のおと

サイレックスの無線LAN 開発者が語る、無線技術についてや製品開発の秘話、技術者向け情報、新しく興味深い話題、サイレックスが提供するサービスや現状などの話題などを配信していきます。

前の記事:「セキュリティのはなし」へ

EAPのはなし(1)

2013年9月18日 17:30
YS
「エンタープライズセキュリティ」は無線 LAN の魔境です。ある時は「EAP」と呼ばれ、またある時には「802.1X」とも呼ばれ、AP 側の設定には「RADIUS」という項目があったりもしますが、一体それらがどういう関係にあるのか正しく理解している人は少ないような気がします。今回は複数シリーズに分けてこれを解説してゆきたいと思います。

何故エンタープライズ・セキュリティ?

前回、PSK システムの問題は「設定更新が大変」であり、それゆえに「一度設定された鍵が使い続けられる傾向がある=セキュリティホールになる得る」と解説しました。しかしこの問題だけに関していえば、集中管理型の AP を使用すればある程度は緩和されます。「集中管理型」というのは子機の認証を個々の AP 独自で行うのではなく、ネットワークを経由して一箇所の認証サーバで行うというシステムです。子機側の鍵管理の問題は残りますが、AP 側の鍵管理はだいぶ楽になります。

しかし、PSK システムにはもう一つの問題があります。それは「認証がパスワードだけで行われる」ことです。すなわち PSK には「ユーザー名」に相当する要素がありません。「暗号化(盗聴防止)」「不正なユーザーの排除(認証)」という機能は PSK で実現できるのですが、PSK では全員が同じパスワードを使用するため、「誰がログインしているのか?」という情報は基本的にはわからないのです。唯一使えるのは MAC アドレスですが、無味乾燥な数字の羅列に過ぎない MAC アドレスはユーザー ID として管理しにくいものですし、PC や LAN アダプタを換えると変わってしまうので扱いづらいものでもあります。
無線 LAN におけるエンタープライズ・セキュリティというのは決して PSK よりも暗号強度が優れているわけではなく(最終的な暗号アルゴリズムは同じ AES-CCMP です)、「ユーザー情報を紐づけて管理できる」ところに最大の違いがあります。誰が・いつ・どこにログインしたのか追跡することも可能ですし、特定ユーザーのログインだけを禁止することも可能です。これに対し PSK システムで特定ユーザーを排除しようと思えば、そのユーザー以外の鍵を全員一斉に換えるか(面倒くさい)、MAC アドレスフィルタを設定して身元の判っている機器以外のログインを禁止する(管理の手間が増えて不便)しかありません。


EAPoL と 802.1X

ネットワークにおける機器認証問題は、無線 LAN 以前に有線 LAN の世界で既に取り上げられており、そのために IEEE802.1X 規格が作られていました。ときおり「802.11X」と誤記されることもありますが、「11X」ではなく「1X」です。エックスは小文字でも大文字でも構わないのですが、小文字の x で書くと「任意のアルファベット」と取られかねないため、大文字で表記するのが慣例です。
802.1X 規格において認証を担うプロトコルが EAPoL です。EAP というのは Extensive Authentication Protocol で、時代を更に遡って 1990 年代に電話回線モデムによるダイヤルアップ・インターネットのユーザー認証プロトコルとして作られた規格がもとになっています。「Extensive」というのは、もともとダイヤルアッププロトコル PPP (Point-to-Point Protocol) に認証シーケンスが組み込まれていたのですが、各社プロバイダや OS ベンダーが独自拡張の認証を実装しはじめたので、それらを包括して一つの枠組みに収めるため「拡張可能な」認証プロトコルとして EAP が制定された、という経緯に由来しています。
EAPoL というのは EAP over LAN を意味し、もともと電話回線用に作られた EAP を LAN 回線上で動作するように拡張したものです。

原型の EAP は通常はチャレンジ型認証(CHAP, Challenge Authentication Protocol)を使用します。EAP-CHAP という名前よりも、ハッシュアルゴリズムの名前を取った EAP-MD5 という名称のほうがよく使われています。これは EAP の前身 PPP が既に「CHAP」という認証プロトコルを持っていたため(※註)、混同を避けるためあえて異なる名称が付けられたのだと思います。

(※註)マイクロソフト社は WindowsNT 独自のパスワードハッシュを用いる MSCHAP、その改良型 MSCHAPv2 を PPP 上に実装して自社製品に搭載しました。EAP が制定されたのはこのような独自拡張を封じ込めるためでしたが、後述するように MSCHAP/MSCHAPv2 はその後も形を変えてしぶとく生き残ることになります。

チャレンジ型認証は下記のようなアルゴリズムで、疑似乱数とハッシュ関数を組み合わせてパスワードとユーザー名をぐちゃぐちゃに潰します。潰した結果は 128bit の一見出鱈目なビット列になりますが、パスワードやユーザー名が1文字でも違っていれば大きく異なる結果になります。しかもユーザー名+パスワード→ハッシュの変換は簡単でも、逆にハッシュからユーザー名やパスワードを推定するのは極めて困難、という仕掛けになっています。

digest_s.jpgダイジェスト認証の仕組み(拡大表示)

802.1X と RADIUS

さて 802.1X にはもう一つ「RADIUS」というキーワードが絡みます。RADIUS とは Remote Access Dial In User Service の略で、かつてのダイヤルアップインターネットでユーザーのログイン管理に使われていた認証プロトコルでした。802.1X はこの仕組みを「ダイヤルアップ」から「イーサネット」に移して実装したようなもので、ハブと子機間の認証を EAPoL で行い、ハブと認証サーバ間の認証を RADIUS で行う仕組みです。

radius_s.jpgRADIUSの仕組み(拡大表示)

RADIUS は EAP とは異なる自身のフレームワークを持ち、基本仕様では非暗号化パスワードをそのまま流す PAP(Password Authentication Protocol)とチャレンジ型認証の CHAP を持ちます。RADIUS の CHAP は EAP-MD5 と似ていますが直接の互換性はありません(※註)。のちに RFC3579 で EAP over RADIUS のオプションが拡張され、EAP のパケットがそのまま RADIUS を通過できるようになりました。現在の 802.1X は基本的にこのモードで動作しています。いわば EAPoL ならぬ EAP on IP として RADIUS の枠組みが使われているようなもので、RADIUS 自身が持つ認証機能(PAP, CHAP)はほとんど使われていません。

(※註)この辺りの関係が少々こじれているのは、EAP(RFC2284)よりも RADIUS(RFC2059)のほうが先に制定されたため、EAP 拡張される前の PPP(RFC1661)の認証プロトコルをベースに RADIUS が設計された経緯に由来しています。

しかしこの「ほとんど」が曲者で、少なくとも RADIUS パスワード(シークレット)だけは正しく設定しなければなりません。RADIUS のパケット上には改竄防止用の認証ハッシュフィールド(Authentication)が残っており、クライアント側(AP)と認証サーバ側で持つシークレット情報が一致しなければ認証ハッシュの値が不一致となってパケットが廃棄されてしまうからです。RADIUS シークレットは 802.1X のユーザー個別に与えられたパスワードとはまた別のもので、基本的には認証サーバ毎に与えられるものですが、IP アドレスのレンジを分けて別々のシークレットを設定できたりもします(少なくとも FreeRADIUS にはその機能がある)。
また、EAP オプション拡張後も RADIUS 自身のユーザー名やパスワードのオプションが無くなったわけではなく、そこにどんな値を入れて送るのか、受け取った RADIUS ユーザー名を検証するのかしないのか、実装と設定によってバリエーションが分かれます。802.1X における ID やパスワードの混乱については後でも触れますが、同じ「802.1X 標準」なのに何故か「相性」があったりするのは、この辺の仕様が柔軟(もっと率直に言えば「いいかげん」)なところに理由があります。


EAP の魔境に向けて
有線 LAN における IEEE802.1X 規格は EAP-MD5 を標準アルゴリズムとしています。しかし、EAP-MD5 は片方向だけの認証です。つまりネットワークが端末を認証するだけで、端末がネットワークを認証することができません。これは有線 LAN でもセキュリティ上の懸念になりますが、無線 LAN では更に大きなリスクになります。というのは攻撃者が偽の AP を立ててユーザーに接続させ情報を盗み出そうとしたときに、片道の認証プロトコルでは「本物の AP」と「偽の AP」を見分けられない、ということを意味するからです。無線 LAN 用の認証プロトコルには双方向性(Mutual Authentication)が必要で、このために EAP はどんどん拡張されてゆくことになりました。いよいよ EAP の魔境に踏み込んでゆきますが、それは次回の話題とします。



「EAPのはなし」記事一覧

次の記事:「EAPのはなし(2)」へ

最新の記事

カテゴリ

バックナンバー