基本となるEAP-TLS

　IEEE802.1xではAuthentication層のプロトコルとしてTLSを使うのが基本となっている。TLSはSSL（Secure Socket Layer）の後継として標準化が行われている。EAP上でTLS認証を使うことから，「EAP-TLS」とも呼ばれる。EAP-TLSは「PPP EAP TLS Authentication Protocol」としてRFC2716で制定されている。

　EAP-TLSでは，ディジタル証明書を用いたPKI（Public Key Infrastructure：公開鍵暗号）による相互認証，WEPキーの配布，各シーケンスにおけるパケットの暗号化などが実行される。

　他の手法としては，米Funk社が提案する「EAP-TTLS（EAP Tunneled TLS）」がある。これは，TLS認証の後，一般的なRADIUSでのユーザ認証を実行するものである。

　Microsoftは，「PEAP(Protected EAP)」と呼ぶプロトコルを提案している。こちらはTLS認証で認証の後，EAP自体をカプセル化して安全性を高めた上で認証する方法である。PEAPは，アクセス・ポイント間でのローミング機能があるという特徴もある。

　EAP-TTLSやPEAPは，EAP-TLSでは不可欠となるディジタル証明書をユーザに配布するわずらわしさがない。どちらも，ユーザIDとパスワードといった一般的な認証方法で，安全に認証できるようにしようというものである。

図3●IEEE802.1xの無線LANでの適用例

　認証技術そのものから見ると，EAP-TLSの最大の特徴はディジタル証明書を使うことにある。電子商取引などPKIを利用したビジネスの展開，ネットワークにおけるICカードの適用，電子政府などを考えると，ディジタル証明書による本人認証は近い将来，今以上に広く普及することが見込まれる。その観点に立てば，EAP-TLSを使うことは，比較的強度の弱いユーザID/パスワード方式からの脱却を促すいい機会となるかもしれない。

認証方式の拡張が容易

　EAP-TLSを無線LANに適用すると図3[拡大表示]のような構成になる。認証サーバにはRADIUSを利用する。認証サーバとアクセス・ポイントの間では，EAPOLではなくRADIUSを使ってEAPをやり取りする。アクセス・ポイントがEAPOLとRADIUSの変換を行う。つまり，EAPOLでのやり取りされるEAPリクエスト，EAPレスポンスが，そのままRADIUSのアクセス・チャレンジ，アクセス・リクエスト上に乗り，認証サーバまで運ばれ，認証が行われる。

　このようにEAPより上位の認証関連プロトコルは，端末と認証サーバの間でやり取りする。このため，認証方式を拡張しやすいという特徴がある。

図4●EAPのパケット・フォーマット

　EAPでやり取りするパケットはとても単純である（図4[拡大表示]）。パケットの種類としてはRequest，Response，Success，Failureの4種類があるだけ。このうちRequestとResponseのパケットは，認証方式を識別する情報を格納する「type」と呼ばれるフィールドをデータ・フィールドの中に持つ。typeに格納する数値によって，認証方式としてTLS（値は13）を使うか，あるいはMD5-Challenge（値は4）を使うかなどを指定できるようになっている。

　このtypeで識別する値を新しく定義すれば，新しい認証方式も簡単にEAPと組み合わせて使えるようになる。TTLS，PEAPを組み合わせる場合は，それぞれを指定する値を規定すればいいのである。

ディジタル署名で相互に認証

　EAP-TLSではディジタル証明書を使って認証する。そのため，EAP-TLSを実現する場合にはRADIUSなどの認証サーバとは別に，ディジタル証明書を発行するCA（Certificate Authority）局を構築し，運用する必要がある。

図5●証明書の配布。
あらかじめ配布しておく。証明書には所有者や暗号に関する情報が格納されている

　CA局の役割は，TLS認証に必要なディジタル証明書をクライアント端末とRADIUSサーバの両方に交付することである（図5[拡大表示]）。CA局は，PKIの基盤となるシステムであり，暗号技術としては公開鍵暗号方式が採用されている。公開鍵暗号化方式は，他人に閲覧されることを前提とする公開鍵と，そのペアとなる秘密鍵を使って暗号通信する技術である。どちらの鍵でも暗号化できるが，ペアとなるもう一つの鍵でなければ解読できないという特徴がある。

　公開鍵暗号を用いた相手認証の基本的なしくみは次のようになる。まず，本人しか持ち得ない秘密鍵を用いてあるデータを暗号化する。そして暗号化したデータと，暗号前のデータを相手に送信する。

　受信側はあらかじめ公開されている相手の公開鍵を用いて受信した暗号データを解読する。その解読結果が，一緒に送られてきた暗号前データと同じなら，送付してきた相手が公開鍵の持ち主であると判断できる。こうした相手認証の方法は，一般にディジタル署名と呼ばれる。

　EAP-TLSでは，この原理に基づいてクライアント側の認証とサーバ側の認証をそれぞれ独立に実行する。それぞれ自らのディジタル証明書も相手に送付し，そこに含まれている自らの公開鍵を相手に通知して，認証処理を実行してもらう構成になっている。

ルート証明書で正当性をチェック

図6●Windows XPにおけるIEEE802.1xの設定

　ただし，ここで問題がある。どこかのユーザが勝手に運用するCA局で，証明書と秘密鍵が払い出されてしまうケースだ。この場合，勝手に作成した証明書を添付して相手に認証依頼すると，本人と特定されてしまうことになる。

　これを回避するためには，証明書がどのCA局で払い出されたものかをチェックする必要がある。まず，送付されてきた証明書中にあるCA局の情報から，親（ルート）への証明書の情報を得る。これをあらかじめ配布されたCA局のルート証明書を比較することで，信頼されたCA局から発行されたかどうかが判断できる。

　RADIUSはサーバ用の証明書以外にルート証明書を必ず持つ。また，端末側でもCA局のチェックを行う仕組みを持っているのが一般的である。Windows XPもあらかじめ複数のルート証明書を持っている。

　なお，Windows XPは証明書をソフトウェアとしてだけでなく，ハードウェア（スマートカード）としても持つこともできる（図6[拡大表示]）。本人であることの証明を厳密に行うのであれば，ICカードやUSBキーといったハードウェアに，証明書や秘密鍵を格納すべきだろう。ソフトウェアの証明書，秘密鍵はコピーされ，パスワードを知られてしまったら他の端末に登録することもできるからだ。


森山　浩幹

東日本電信電話　研究開発センタ　担当部長。OSIの頃から，X.400（電子メール）などのプロトコルの標準化，実装に携わる。現在は，IP系システムの開発に従事している。