Wireless・のおと
サイレックスの無線LAN 開発者が語る、無線技術についてや製品開発の秘話、技術者向け情報、新しく興味深い話題、サイレックスが提供するサービスや現状などの話題などを配信していきます。
EAPのはなし(2)
前回は PSK(WPA パーソナル) と EAP(WPA エンタープライズ) が何故・どう違うのかという話、EAP/802.1X/RADIUS の簡単な紹介、そして無線 LAN では片道認証の EAP-MD5 では不十分という話を解説しました。今回はいよいよ各種の EAP 認証プロトコルについて紹介してゆきます。
EAP-TLS
オープンスタンダードな双方向認証プロトコルとして最初に提案されたのが EAP-TLS でした。EAP-TLS の仕様は RFC2716(1999) として公開され、現時点での最新版は RFC5216(2008) となっています。
TLS というのは Transport Security Layer の略ですが、商用 WEB サイトで使われている HTTP の暗号化プロトコル(※註)と同じものです。WEB サイトの場合はほとんどが片道認証(ユーザー／ブラウザがサーバの正当性を認証するだけ)ですが、EAP-TLS は双方向認証を用いるため、AP 側(認証サーバ側)だけでなく子機側(PC など)にも証明書をインストールする必要があります。
(※註)HTTP の暗号化プロトコルはよく SSL(Secure Socket Layer) と呼ばれています。SSL はもともと Netscape 社が自社ブラウザ(Navigator)用に開発した技術で、同社はその仕様を公開し RFC ドラフトとして提案したのですが、様々な(主に政治的な)シガラミがあってそのままの名称・仕様では採用されず、仕様を若干変更したうえで名前も「SSL」から「TLS」に変えて採用された、という経緯があります。
EAP-TLS においてもはや EAP はただの「運び屋」で、EAP 自身が持っているユーザー名やパスワードなどの情報は原則として使われません(例によってこの「原則として」が曲者ですが)。TLS のトランザクションパケットがブツ切りにされて EAP パケットにカプセリングされて送受信され、認証は TLS の持つ証明書交換によって行われます。
TLS の認証は前回も解説した X.509 PKI デジタル証明書を採用していますから、非常に強力です。しかし EAP-TLS の欠点は「面倒くさい」の一言に尽きます。なんせ全てのユーザー１人１人に対応するクライアント証明書をいちいち CA から発行して、それを適切にインストールしなければならないのです。ユーザー登録を削除する場合は逆に、その証明書の無効化手続きを行わなければなりません。
EAP-TLS は WiFi エンタープライズ・ロゴ認証でも実装必須とされており、名目上の標準仕様です。しかし実際に使われているかと言われると「うーん？」という微妙なところです。よほどユーザー数が少ない(≒証明書の管理負担が軽い)か、あるいは本格的に証明書の発行・無効化を運用できる CA システムを備えた高セキュリティ環境の両極端でしか使われていないと思います。
LEAP
EAP-TLS と前後する時期にネットワーク装置の大手 Cisco 社が自社製品用に開発した、独自仕様の双方向認証プロトコルが LEAP(Lightweight EAP)でした。LEAP はデジタル証明書を使用せず、チャレンジ方式のパスワード認証を双方向で行うというシンプルなアイデアで実装されています。
LEAP は運用管理の面倒くさい TLS と異なり、CA サーバにおける証明書の発行・インストール・無効化などの操作が不要です。とかく難しい X.509 証明書を使う必要もなく「ユーザー名」「パスワード」という単位でユーザーを管理できます。数キロビット長の整数を何度も剰除算する公開鍵暗号も必要ないため実装・実行負荷も軽く、「Lightweight」の名はこの特長から名づけられたものでしょう。
しかし LEAP には２つの大きな欠点がありました。
(1) Cisco 社の独自技術であり、公式な仕様が公開されていない。
(2) セキュリティが弱い。
(1) も実装技術者にとって困ったことでしたが、(2) は致命的でした。技術的詳細は割愛しますが、LEAP のハッシュアルゴリズムは不十分で原情報に近い情報が漏れる部分があり、そこを突破口として既知文辞書攻撃を仕掛ければ容易に解読できる、という脆弱性が 2003 年頃に指摘されたのです。
LEAP の脆弱性は既知文辞書攻撃に対するものなので、パスワードを長く複雑なもの...「Az#pZ%7sy9gtk@Z」のような文字列にすればある程度緩和することはできます。しかし、このように複雑怪奇なパスワードをユーザーに強制した場合、多くのユーザーは暗記できないため(そりゃそうだ)付箋に書き込んで PC の横に貼り付けたり、テキストファイルに書き込んでデスクトップに置くなど、かえって運用上のセキュリティを下げることが指摘されています。
Cisco 社は LEAP に代わる PEAP, FAST (後述)を開発し、ユーザーに対しても LEAP の脆弱性を伝えて「なるべく使わないように」と呼びかけています。技術者としても LEAP にはさっさと消え去って欲しいのですが、製品仕様比較表に「LEAP」の項目がある限り、そこにマルを付けるためだけのために LEAP は残り続けるのでしょう...アドホックモードや WEP や TKIP や WPA がなかなか消えないのと同様に。
TTLS
さて、EAP-TLS で使われる TLS は「WEB で使われる HTTP の暗号プロトコルと同じ」「WEB サイトの場合はほとんどが片道認証」と既に述べました。片道認証というのは、たとえば商用サイトに接続して何かをネット購入するときブラウザはそのサイトの正当性を証明書を用いて検証しますが、ユーザー側のログイン情報として証明書をインストールする必要はありません。認証されたサーバ相手に暗号回線が確立され、暗号化された HTTP の上でユーザー名・パスワードが入力されて認証が成立します。
この原理と基本的に同じ考え方...非対称の双方向認証(※註)を取り入れたのが TTLS (Tunnel mode TLS)で、Funk Software 社と SafeNet 社によって開発されました。TTLS の仕様は RFC5281(2008) として公開されています。
(※註)ただし TTLS の仕様では、セキュリティを特に重視する場合はクライアント証明書とユーザー名・パスワードを併用する双方向認証のオプションも定めています。
TTLS では子機が証明書を用いて AP 側の正当性を確認したあと、確立された暗号化回線(しばしば「暗号トンネル(secure tunnel)」と呼ばれる)の上で子機からユーザー名・パスワードが AP 側に送られて認証されます。暗号トンネル確立までをフェーズ１、確立後をフェーズ２と呼ぶ場合が多いです。
暗号トンネル上の通信は認証・暗号化済みなので、その上で流れる認証プロトコル(Inner Authentication)は非暗号化でも構いません。TTLS では認証プロトコル RADIUS の拡張版である Diameter のフレームワークを取り入れており、RFC5281 では Inner Authentication プロトコルとして PAP, CHAP, MSCHAP, MSCHAPv2 あるいは EAP が列挙されています。しかし「非暗号化でも構わない」なら一番単純な PAP だけにしておけば良さそうなものですが、何故あえて自由度を残してあるのかは判りません。
双方向認証がオプションとして残されていたり、Inner Authentication に選択肢がある辺りが TTLS のちょっと嫌らしいところで、実装によっては設定選択肢が多くなってしまいます。ただし設定さえ合っていれば素直に動くことが多く、設定項目以外のところでバリエーションがある PEAP(後述)よりマシだと感じることもあります。
TTLS の普及度合いも微妙なところです。後述の PEAP(v0) がほとんど同じ動作原理ながらもマイクロソフトという巨大な力を得て普及してしまったため、似て非なる TTLS はあまり使われていないのではないかと思います。しかし PEAPv0 を実装するなら TTLS の実装も「ついで」程度にできるので、やはり仕様比較表にマルを付けるために実装だけは広まっていると感じます。
PEAP
PEAP(Protected EAP) はネットワーク界・PC 界・セキュリティ界の３大企業である Cisco・マイクロソフト・RSA Security 社によって共同開発されたプロトコルです。錚々たる大手が名を並べただけあって強い影響力を持つデファクトスタンダードではあるのですが、その開発と標準化には紆余曲折があって若干の混乱を残しています。
PEAP の動作原理は EAP-TTLS と全く同じです。証明書を用いた片道認証のあと暗号トンネルを確立し、暗号トンネル上でユーザー名・パスワードによる認証を行います。PEAP と TTLS の違いは、暗号トンネル上のプロトコルとして TTLS が RADIUS/Diameter の枠組みを使っているのに対し、PEAP は EAP を使っている程度でしかありません。
PEAP には公式な標準仕様書が存在しません。PEAP の標準化作業は 2001 年から 2004 年まで続けられたようですが、結局 RFC として確立することなく打ち切られてしまいました。その過程で少なくとも 10 以上のドラフトが上梓され、しかも逐次マイナーチェンジが行われて PEAPv0, PEAPv1, PEAPv2 と呼ばれるバリエーションが存在します。このうち世間で「PEAP」と言えばほぼ PEAPv0 を指し、PEAPv1 はたまに話題に上がるくらいで、PEAPv2 はほとんど無視されています。
「標準仕様書が存在しない」「バリエーションが３種類ある」だけでも十分頭が痛いのに、PEAP には「暗号パイプ上で EAP を用いて認証する」ことしか定めていないという問題もあります。EAP 自身が何十種類もの認証プロトコルを扱える規格ですから、一体どの EAP を使うのか(内部認証プロトコル:Inner Authentication)で更に実装バリエーションが増えることになります。一応 PEAPv0 では EAP-MSCHAPv2 を、PEAPv1 では EAP-GTC を用いるのがデファクトスタンダードになってはいますが、必ずそうなるとは限りません(なんせ公式な標準仕様書の無い規格ですし)。
３大企業による共同規格だったはずの PEAP がこんな体たらくになったのは「船頭多くして船山に登る」ような事情があったようです。PEAP が RFC 標準化されなかったのには大手企業に仕様を牛耳られたくない IETF との相克があったようですし(SSL/TLS のときも同じような話がありましたね)、PEAP 陣営側にもいろいろあったようです。マイクロソフト社は Windows 製品に PEAPv0 しか実装しておらず、Cisco 社の WEB サイトでは PEAPv0 のことを「Microsoft PEAP/MS-CHAPv2」、PEAPv1 のことを「Cisco PEAP(EAP-GTC)」と表記しているなど、PEAP 制定における両社の相克が垣間見えるようです。
このように仕様的な問題を抱えている PEAP ですが、TLS 系の EAP プロトコルとしては広く使われています。何といっても PEAPv0+MSCHAPv2 が Microsoft Windows(XP 以降)の無線認証プロトコルとして標準実装されている影響が大きいです。
Windows XPにおけるPEAP設定画面
EAP-FAST
EAP-FAST(Flexible Authentication via Secure Tunneling) はこれまた Cisco 社による EAP 認証プロトコルですが、LEAP や PEAP と異なり RFC4851 として公式仕様書が公開されています。したがって一応「オープンスタンダード」を名乗っていますが、後述するような事情によって「Cisco 社の独自プロトコル」として扱われる場合も少なくありません。
FAST は LEAP の簡便性...「デジタル証明書が要らない」という特長を残しつつ、TLS, PEAP に匹敵するセキュリティを備えることを目標に開発されました。とはいえその動作原理はこれまた TTLS と基本的に同じ...TLS を用いて暗号トンネルを確立し、暗号トンネル上でユーザー認証を行うというもので、内部認証プロトコルの枠組みも PEAP と同じ EAP ベースです。
FAST と TTLS/PEAP が異なるのは、FAST では証明書を用いない TLS セッション(匿名鍵交換, Anonymous DH)を用いる無認証モード(Server-Unauthenticated Provisioning Mode)を認めていること、PAC(Protected Access Credential)と呼ばれる独自のフォーマットを使用することです。
公開鍵暗号を用いた認証方式については前々回に解説していますが、CA 証明書を用いない匿名鍵交換では中間介在者攻撃に対して脆弱になります。EAP-FAST の無認証モードでは証明書のかわりに LEAP と似た双方向のチャレンジ認証(EAP-FAST-MSCHAPv2)で相互認証をかけるとしていますが、FAST の補足仕様 RFC5422 の中でも「CA 証明書を用いたほうがセキュリティが高い(much better protection)」「なるべく証明書を用いるべきだ(SHOULD be used whenever possible)」とされています(※註)。
(※註)にも関わらず Cisco 社 WEB サイトでは「証明書が要らない」かつ「強力なセキュリティが実現できる」と大々的に喧伝されており、Cisco 社のダブルスタンダード的な態度を「胡散臭いマーケティング」と批判するネット上の声もあります。
PAC は FAST 特有のフォーマットで、X.509 証明書に代わるセキュリティ情報を格納したファイル構造です。Cisco 社のサイトでは「PAC さえ用いれば証明書は必要ない」「公開鍵証明書よりも簡単でしかも高速」というニュアンスで書かれていますが、前述したように RFC5422 のなかでは「可能な限り証明書を使え」と書かれているのが「胡散臭い」と言われる理由でしょう。
PAC は A-ID という 16 バイト長の疑似乱数からなるサーバ ID、I-ID という可変長文字列のクライアント ID、PAC-KEY という秘密鍵情報、PAC-OPAQUE というサーバ側管理情報(暗号化されていてクライアント側では読めない)から構成されます。PAC-OPAQUE の中身は認証サーバの実装依存であり、そして Cisco 社の認証サーバである ACS が生成する PAC-OPAQUE のフォーマットは公開されていません。この辺がオープンスタンダードという看板を持ちながら「実質的には Cisco の独自仕様」と批判される理由の一つになっています。
通常の TLS ではセッション毎に暗号鍵を乱数生成して公開鍵で交換しますが、EAP-FAST では PAC に含まれる共有秘密鍵(PAC-KEY)から生成するため、通常の TLS より計算量が少ないうえ鍵交換手順も１段少なく済むので速いのだ、と Cisco 社は主張しています(FAST という名前の由来？)。もちろん盗聴者に PAC-KEY が知られてしまうと EAP-FAST は筒抜けになってしまいまうため、PAC ファイルは「安全な手段」で設定される必要がありますが、これでは鍵交換成立前にどうやって暗号鍵を安全に交換するのか？というニワトリタマゴ問題が再発してしまいますね。
Cisco 社はこれに対し「手動プロビジョニング」「自動プロビジョニング」という２つのオプションを用意しています。前者は「何らかの安全な手段を用いて」「事前に」PAC ファイルをインストールする方法、後者は「認証のない匿名 DH 鍵交換による暗号化トンネルの上で PAC ファイルを送信する」という方法です。
しかし「安全な手段を用いて」「事前に何かを設定する」というのは PSK 方式の一大欠点と同じで、それが簡単にできるなら大規模ネットワーク管理で苦労なんかしません。一方、認証のない暗号化は中間介在者攻撃によるセキュリティホールとなる危険があります。前述のように無認証モードでも双方向のチャレンジ認証が行われるため、中間介在者攻撃に対して無防備という訳ではないのですが、本当に「TLS や PEAP と同等の安全性」なのか？という評価はまだ固まっていないように思います。
EAP-FASTは最後発だけあって、あれもこれもと機能を全部詰めこんだ気配がありますが、前述したように批判もあってTLS や PEAP を押しのけデファクトスタンダードになる勢いは感じられません。Cisco 社(およびその互換)製品だけでがっちり固めたシステムならば FAST の採用も検討されるけれど、マルチベンダーならば TLS や PEAP で稼動しているシステムのほうが多いように感じます。
まとめ
無線 LAN 規格で使用される各種 EAP プロトコルについてざっと紹介しました。EAP/802.1X については誰もが「何でこんなに沢山種類があるんだろう？」と疑問を持つと思いますが、必ずしも技術的・用途的必然性からそうなったわけではなく、過去の互換性・ベンダー間の合同計画あるいはその破綻・ベンダーと標規格団体の意地の張り合いなど、意外に「くだらない」理由でそうなっていることを感じて頂けたかと思います。「標準規格」なのに何とも不合理なことですが、規格といっても所詮は神ならぬ人間の決めていることですから。
EAPのバリエーションはこの後も増え続け、EAP-PSK, EAP-PWD, EAP-POTP, EAP-EKE, EAP-AKA, EAP-AKA', EAP-SIM などが発表されています。前の４つは証明書を用いないパスワード系の EAP、後の３つは携帯電話の利用者カード(SIM)を認証に応用するものですが、また例によって例のごとく同じ目的を実現するのに違う方法が幾つも提案されるのは、自由競争原理として健全なことだと解釈すべきなのか、またメーカー間の意地の張り合いなのか...。個人的にはもう、いい加減にして欲しいと思っています。
オープンスタンダードな双方向認証プロトコルとして最初に提案されたのが EAP-TLS でした。EAP-TLS の仕様は RFC2716(1999) として公開され、現時点での最新版は RFC5216(2008) となっています。
TLS というのは Transport Security Layer の略ですが、商用 WEB サイトで使われている HTTP の暗号化プロトコル(※註)と同じものです。WEB サイトの場合はほとんどが片道認証(ユーザー／ブラウザがサーバの正当性を認証するだけ)ですが、EAP-TLS は双方向認証を用いるため、AP 側(認証サーバ側)だけでなく子機側(PC など)にも証明書をインストールする必要があります。
(※註)HTTP の暗号化プロトコルはよく SSL(Secure Socket Layer) と呼ばれています。SSL はもともと Netscape 社が自社ブラウザ(Navigator)用に開発した技術で、同社はその仕様を公開し RFC ドラフトとして提案したのですが、様々な(主に政治的な)シガラミがあってそのままの名称・仕様では採用されず、仕様を若干変更したうえで名前も「SSL」から「TLS」に変えて採用された、という経緯があります。
EAP-TLSによる双方向認証(EAP-TLS においてもはや EAP はただの「運び屋」で、EAP 自身が持っているユーザー名やパスワードなどの情報は原則として使われません(例によってこの「原則として」が曲者ですが)。TLS のトランザクションパケットがブツ切りにされて EAP パケットにカプセリングされて送受信され、認証は TLS の持つ証明書交換によって行われます。
TLS の認証は前回も解説した X.509 PKI デジタル証明書を採用していますから、非常に強力です。しかし EAP-TLS の欠点は「面倒くさい」の一言に尽きます。なんせ全てのユーザー１人１人に対応するクライアント証明書をいちいち CA から発行して、それを適切にインストールしなければならないのです。ユーザー登録を削除する場合は逆に、その証明書の無効化手続きを行わなければなりません。
EAP-TLS は WiFi エンタープライズ・ロゴ認証でも実装必須とされており、名目上の標準仕様です。しかし実際に使われているかと言われると「うーん？」という微妙なところです。よほどユーザー数が少ない(≒証明書の管理負担が軽い)か、あるいは本格的に証明書の発行・無効化を運用できる CA システムを備えた高セキュリティ環境の両極端でしか使われていないと思います。
LEAP
EAP-TLS と前後する時期にネットワーク装置の大手 Cisco 社が自社製品用に開発した、独自仕様の双方向認証プロトコルが LEAP(Lightweight EAP)でした。LEAP はデジタル証明書を使用せず、チャレンジ方式のパスワード認証を双方向で行うというシンプルなアイデアで実装されています。
LEAPによる双方向認証(LEAP は運用管理の面倒くさい TLS と異なり、CA サーバにおける証明書の発行・インストール・無効化などの操作が不要です。とかく難しい X.509 証明書を使う必要もなく「ユーザー名」「パスワード」という単位でユーザーを管理できます。数キロビット長の整数を何度も剰除算する公開鍵暗号も必要ないため実装・実行負荷も軽く、「Lightweight」の名はこの特長から名づけられたものでしょう。
しかし LEAP には２つの大きな欠点がありました。
(1) Cisco 社の独自技術であり、公式な仕様が公開されていない。
(2) セキュリティが弱い。
(1) も実装技術者にとって困ったことでしたが、(2) は致命的でした。技術的詳細は割愛しますが、LEAP のハッシュアルゴリズムは不十分で原情報に近い情報が漏れる部分があり、そこを突破口として既知文辞書攻撃を仕掛ければ容易に解読できる、という脆弱性が 2003 年頃に指摘されたのです。
LEAP の脆弱性は既知文辞書攻撃に対するものなので、パスワードを長く複雑なもの...「Az#pZ%7sy9gtk@Z」のような文字列にすればある程度緩和することはできます。しかし、このように複雑怪奇なパスワードをユーザーに強制した場合、多くのユーザーは暗記できないため(そりゃそうだ)付箋に書き込んで PC の横に貼り付けたり、テキストファイルに書き込んでデスクトップに置くなど、かえって運用上のセキュリティを下げることが指摘されています。
Cisco 社は LEAP に代わる PEAP, FAST (後述)を開発し、ユーザーに対しても LEAP の脆弱性を伝えて「なるべく使わないように」と呼びかけています。技術者としても LEAP にはさっさと消え去って欲しいのですが、製品仕様比較表に「LEAP」の項目がある限り、そこにマルを付けるためだけのために LEAP は残り続けるのでしょう...アドホックモードや WEP や TKIP や WPA がなかなか消えないのと同様に。
TTLS
さて、EAP-TLS で使われる TLS は「WEB で使われる HTTP の暗号プロトコルと同じ」「WEB サイトの場合はほとんどが片道認証」と既に述べました。片道認証というのは、たとえば商用サイトに接続して何かをネット購入するときブラウザはそのサイトの正当性を証明書を用いて検証しますが、ユーザー側のログイン情報として証明書をインストールする必要はありません。認証されたサーバ相手に暗号回線が確立され、暗号化された HTTP の上でユーザー名・パスワードが入力されて認証が成立します。
この原理と基本的に同じ考え方...非対称の双方向認証(※註)を取り入れたのが TTLS (Tunnel mode TLS)で、Funk Software 社と SafeNet 社によって開発されました。TTLS の仕様は RFC5281(2008) として公開されています。
(※註)ただし TTLS の仕様では、セキュリティを特に重視する場合はクライアント証明書とユーザー名・パスワードを併用する双方向認証のオプションも定めています。
TTLS では子機が証明書を用いて AP 側の正当性を確認したあと、確立された暗号化回線(しばしば「暗号トンネル(secure tunnel)」と呼ばれる)の上で子機からユーザー名・パスワードが AP 側に送られて認証されます。暗号トンネル確立までをフェーズ１、確立後をフェーズ２と呼ぶ場合が多いです。
EAP-TTLSによる２段階の双方向認証(暗号トンネル上の通信は認証・暗号化済みなので、その上で流れる認証プロトコル(Inner Authentication)は非暗号化でも構いません。TTLS では認証プロトコル RADIUS の拡張版である Diameter のフレームワークを取り入れており、RFC5281 では Inner Authentication プロトコルとして PAP, CHAP, MSCHAP, MSCHAPv2 あるいは EAP が列挙されています。しかし「非暗号化でも構わない」なら一番単純な PAP だけにしておけば良さそうなものですが、何故あえて自由度を残してあるのかは判りません。
双方向認証がオプションとして残されていたり、Inner Authentication に選択肢がある辺りが TTLS のちょっと嫌らしいところで、実装によっては設定選択肢が多くなってしまいます。ただし設定さえ合っていれば素直に動くことが多く、設定項目以外のところでバリエーションがある PEAP(後述)よりマシだと感じることもあります。
TTLS の普及度合いも微妙なところです。後述の PEAP(v0) がほとんど同じ動作原理ながらもマイクロソフトという巨大な力を得て普及してしまったため、似て非なる TTLS はあまり使われていないのではないかと思います。しかし PEAPv0 を実装するなら TTLS の実装も「ついで」程度にできるので、やはり仕様比較表にマルを付けるために実装だけは広まっていると感じます。
PEAP
PEAP(Protected EAP) はネットワーク界・PC 界・セキュリティ界の３大企業である Cisco・マイクロソフト・RSA Security 社によって共同開発されたプロトコルです。錚々たる大手が名を並べただけあって強い影響力を持つデファクトスタンダードではあるのですが、その開発と標準化には紆余曲折があって若干の混乱を残しています。
PEAP の動作原理は EAP-TTLS と全く同じです。証明書を用いた片道認証のあと暗号トンネルを確立し、暗号トンネル上でユーザー名・パスワードによる認証を行います。PEAP と TTLS の違いは、暗号トンネル上のプロトコルとして TTLS が RADIUS/Diameter の枠組みを使っているのに対し、PEAP は EAP を使っている程度でしかありません。
PEAP には公式な標準仕様書が存在しません。PEAP の標準化作業は 2001 年から 2004 年まで続けられたようですが、結局 RFC として確立することなく打ち切られてしまいました。その過程で少なくとも 10 以上のドラフトが上梓され、しかも逐次マイナーチェンジが行われて PEAPv0, PEAPv1, PEAPv2 と呼ばれるバリエーションが存在します。このうち世間で「PEAP」と言えばほぼ PEAPv0 を指し、PEAPv1 はたまに話題に上がるくらいで、PEAPv2 はほとんど無視されています。
「標準仕様書が存在しない」「バリエーションが３種類ある」だけでも十分頭が痛いのに、PEAP には「暗号パイプ上で EAP を用いて認証する」ことしか定めていないという問題もあります。EAP 自身が何十種類もの認証プロトコルを扱える規格ですから、一体どの EAP を使うのか(内部認証プロトコル:Inner Authentication)で更に実装バリエーションが増えることになります。一応 PEAPv0 では EAP-MSCHAPv2 を、PEAPv1 では EAP-GTC を用いるのがデファクトスタンダードになってはいますが、必ずそうなるとは限りません(なんせ公式な標準仕様書の無い規格ですし)。
３大企業による共同規格だったはずの PEAP がこんな体たらくになったのは「船頭多くして船山に登る」ような事情があったようです。PEAP が RFC 標準化されなかったのには大手企業に仕様を牛耳られたくない IETF との相克があったようですし(SSL/TLS のときも同じような話がありましたね)、PEAP 陣営側にもいろいろあったようです。マイクロソフト社は Windows 製品に PEAPv0 しか実装しておらず、Cisco 社の WEB サイトでは PEAPv0 のことを「Microsoft PEAP/MS-CHAPv2」、PEAPv1 のことを「Cisco PEAP(EAP-GTC)」と表記しているなど、PEAP 制定における両社の相克が垣間見えるようです。
このように仕様的な問題を抱えている PEAP ですが、TLS 系の EAP プロトコルとしては広く使われています。何といっても PEAPv0+MSCHAPv2 が Microsoft Windows(XP 以降)の無線認証プロトコルとして標準実装されている影響が大きいです。
Windows XPにおけるPEAP設定画面EAP-FAST
EAP-FAST(Flexible Authentication via Secure Tunneling) はこれまた Cisco 社による EAP 認証プロトコルですが、LEAP や PEAP と異なり RFC4851 として公式仕様書が公開されています。したがって一応「オープンスタンダード」を名乗っていますが、後述するような事情によって「Cisco 社の独自プロトコル」として扱われる場合も少なくありません。
FAST は LEAP の簡便性...「デジタル証明書が要らない」という特長を残しつつ、TLS, PEAP に匹敵するセキュリティを備えることを目標に開発されました。とはいえその動作原理はこれまた TTLS と基本的に同じ...TLS を用いて暗号トンネルを確立し、暗号トンネル上でユーザー認証を行うというもので、内部認証プロトコルの枠組みも PEAP と同じ EAP ベースです。
FAST と TTLS/PEAP が異なるのは、FAST では証明書を用いない TLS セッション(匿名鍵交換, Anonymous DH)を用いる無認証モード(Server-Unauthenticated Provisioning Mode)を認めていること、PAC(Protected Access Credential)と呼ばれる独自のフォーマットを使用することです。
EAP-FASTによる１＋２段階の双方向認証(公開鍵暗号を用いた認証方式については前々回に解説していますが、CA 証明書を用いない匿名鍵交換では中間介在者攻撃に対して脆弱になります。EAP-FAST の無認証モードでは証明書のかわりに LEAP と似た双方向のチャレンジ認証(EAP-FAST-MSCHAPv2)で相互認証をかけるとしていますが、FAST の補足仕様 RFC5422 の中でも「CA 証明書を用いたほうがセキュリティが高い(much better protection)」「なるべく証明書を用いるべきだ(SHOULD be used whenever possible)」とされています(※註)。
(※註)にも関わらず Cisco 社 WEB サイトでは「証明書が要らない」かつ「強力なセキュリティが実現できる」と大々的に喧伝されており、Cisco 社のダブルスタンダード的な態度を「胡散臭いマーケティング」と批判するネット上の声もあります。
PAC は FAST 特有のフォーマットで、X.509 証明書に代わるセキュリティ情報を格納したファイル構造です。Cisco 社のサイトでは「PAC さえ用いれば証明書は必要ない」「公開鍵証明書よりも簡単でしかも高速」というニュアンスで書かれていますが、前述したように RFC5422 のなかでは「可能な限り証明書を使え」と書かれているのが「胡散臭い」と言われる理由でしょう。
PAC は A-ID という 16 バイト長の疑似乱数からなるサーバ ID、I-ID という可変長文字列のクライアント ID、PAC-KEY という秘密鍵情報、PAC-OPAQUE というサーバ側管理情報(暗号化されていてクライアント側では読めない)から構成されます。PAC-OPAQUE の中身は認証サーバの実装依存であり、そして Cisco 社の認証サーバである ACS が生成する PAC-OPAQUE のフォーマットは公開されていません。この辺がオープンスタンダードという看板を持ちながら「実質的には Cisco の独自仕様」と批判される理由の一つになっています。
通常の TLS ではセッション毎に暗号鍵を乱数生成して公開鍵で交換しますが、EAP-FAST では PAC に含まれる共有秘密鍵(PAC-KEY)から生成するため、通常の TLS より計算量が少ないうえ鍵交換手順も１段少なく済むので速いのだ、と Cisco 社は主張しています(FAST という名前の由来？)。もちろん盗聴者に PAC-KEY が知られてしまうと EAP-FAST は筒抜けになってしまいまうため、PAC ファイルは「安全な手段」で設定される必要がありますが、これでは鍵交換成立前にどうやって暗号鍵を安全に交換するのか？というニワトリタマゴ問題が再発してしまいますね。
PACファイルの構造(Cisco 社はこれに対し「手動プロビジョニング」「自動プロビジョニング」という２つのオプションを用意しています。前者は「何らかの安全な手段を用いて」「事前に」PAC ファイルをインストールする方法、後者は「認証のない匿名 DH 鍵交換による暗号化トンネルの上で PAC ファイルを送信する」という方法です。
しかし「安全な手段を用いて」「事前に何かを設定する」というのは PSK 方式の一大欠点と同じで、それが簡単にできるなら大規模ネットワーク管理で苦労なんかしません。一方、認証のない暗号化は中間介在者攻撃によるセキュリティホールとなる危険があります。前述のように無認証モードでも双方向のチャレンジ認証が行われるため、中間介在者攻撃に対して無防備という訳ではないのですが、本当に「TLS や PEAP と同等の安全性」なのか？という評価はまだ固まっていないように思います。
EAP-FASTは最後発だけあって、あれもこれもと機能を全部詰めこんだ気配がありますが、前述したように批判もあってTLS や PEAP を押しのけデファクトスタンダードになる勢いは感じられません。Cisco 社(およびその互換)製品だけでがっちり固めたシステムならば FAST の採用も検討されるけれど、マルチベンダーならば TLS や PEAP で稼動しているシステムのほうが多いように感じます。
まとめ
無線 LAN 規格で使用される各種 EAP プロトコルについてざっと紹介しました。EAP/802.1X については誰もが「何でこんなに沢山種類があるんだろう？」と疑問を持つと思いますが、必ずしも技術的・用途的必然性からそうなったわけではなく、過去の互換性・ベンダー間の合同計画あるいはその破綻・ベンダーと標規格団体の意地の張り合いなど、意外に「くだらない」理由でそうなっていることを感じて頂けたかと思います。「標準規格」なのに何とも不合理なことですが、規格といっても所詮は神ならぬ人間の決めていることですから。
EAPのバリエーションはこの後も増え続け、EAP-PSK, EAP-PWD, EAP-POTP, EAP-EKE, EAP-AKA, EAP-AKA', EAP-SIM などが発表されています。前の４つは証明書を用いないパスワード系の EAP、後の３つは携帯電話の利用者カード(SIM)を認証に応用するものですが、また例によって例のごとく同じ目的を実現するのに違う方法が幾つも提案されるのは、自由競争原理として健全なことだと解釈すべきなのか、またメーカー間の意地の張り合いなのか...。個人的にはもう、いい加減にして欲しいと思っています。
