第2回 認証技術の複合化を目指すOATHのロードマップ

相原　敬雄
日本ベリサイン株式会社
マーケティング部　課長
2006/2/18

---

　認証プロトコルフレームワーク

　多くの場合、要求される認証プロトコルはアプリケーションごとに異なります。例えば、WebアプリケーションではしばしばSSL／TLSが主要プロトコルとなります。VPNの場合はIPSec IKEが標準であり、Wi-Fi（802.1X）にはEAP-TLSやEAP-PEAPなどのEAP方式が一般的です。用途ごとにOATHが提案するプロトコルを見ていきましょう。

ネットワークアプリケーション用802.1X

　ネットワークアクセスアプリケーション用の認証プロトコルのフレームワークとして、OATHは802.1Xを提案しています。これは、有線・無線の両ネットワークに適用できます（認証を行うのは、無線ネットワークではアクセスポイント、有線ネットワークではレイヤ2スイッチになります）。

　802.1Xでは、基礎認証方法案それぞれにEAP方式（SIMベース認証にはEAP-SIM、PKIベース認証にはEAP-TLS、OTPベース認証にはEAP-PEAP）がすでに定義されているので、これが候補に挙げられるのは自然な流れになっています。

デバイス認証用802.1X

　各メーカーやOSベンダに対して、デバイス認証のための一貫した導入プロファイルを推進するには、802.1Xフレームワークが不可欠です。OATHが描いているビジョンでは、組み込み型802.1Xクライアントの採用によって、各種デバイス（VoIP電話、アクセスポイント、スイッチ、サーバなど）は、ネットワークに対して透過的に認証された後、IPアドレスを渡され、ネットワークへのアクセスを許可されるようになります。

デバイス認証フレームワークとしての802.1X

製造時組み込みデバイスクレデンシャル

　OATHの予想では、TPMや802.1X認証プロトコルフレームワークなどの新規台頭しているセキュアコンピューティング技術にデバイス証明書が組み合わされるようになります。この収束によって、共通のテクノロジースタックや導入プロファイルが育成され、デバイスメーカーはターンキー方式の強固な認証ソリューションを構築できるようになります。

ビジネスアプリケーション統合用Webサービスプロトコル

　OATHでは、ネットワークアクセスアプリケーション（ダイヤルアップ、VPN、Wi-Fi）とビジネスアプリケーション（Webやエンタープライズポータル、Webアプリケーション、ERPシステム、Webサービス）間のプロトコル二分問題を解決する必要があります。802.1Xフレームワークは特に前者には適しますが、後者には適しません。一方、Webサービスインターフェイスは、今日のビジネスアプリケーションに適します。

　認証プロトコルは、主要なアプリケーション統合メカニズムの構成要素なので、OATHでは両タイプのアプリケーションをサポートできるプロトコルパレットが必要です。これにより、すでにカバーされている802.1X EAP方式と並んでWebサービスAPIの定義が必要になります。

　OATHが提案しているSOAP APIは、基本的セキュリティトークン（OTP、X.509証明書）エンコード用のプライマリメカニズムとしてWSセキュリティ仕様を活用し、SIMベースの認証のためのチャレンジ−レスポンスメカニズムも定義しています。

　要約すれば、OATHはネットワークアクセスの要件と、ハイレベルビジネスアプリケーションのニーズの双方に対応したデュアルインターフェイスモデルを支持しています。

アプリケーションコネクタと認証クライアント

　認証プロトコルの標準化と、認証クライアント開発推進の主な動機付けは、アプリケーション“コネクタ”の作成を促進することです。アプリケーションコネクタ、すなわちエージェントは、強固な認証を実装しているクライアントライブラリです。これらは、主なOS間で移植が可能で、一般的なプログラミング言語上のAPIを提供するものです。このような柔軟性によって、アプリケーション開発者は、カスタムアプリケーション内に強固な認証を簡単に統合できるようになります。

　携帯電話やPDA、プリンタ、Wi-Fiアクセスポイント、スイッチに至るまで、さまざまなデバイスに対して、OSに関係なくEAP-SIM、EAP-TLS、EAP-PEAPをサポートする802.1Xクライアントの作成を目指し、OATHではオープンソースプロジェクトの創設を支援しています。

　クレデンシャルのプロビジョニングと検証

　ユニバーサルな強固な認証の実現が主目的なので、あらゆる種類のシークレット（共通鍵やRSA鍵ペア）間で、クレデンシャルの発行機能とそのほかのライフサイクル管理機能の調和を取る方式が必要となります。OATHでは、SIMとOTPのどちらのシークレットも、RSA鍵ペアに付随するものになります。共有シークレットは、暗号化され、クレデンシャルに属性として埋め込まれます。クレデンシャルは、共有シークレットのプライベートストアの機能を果たし、セキュリティデバイスは、“ルート”クレデンシャルのセキュアなハードウェア金庫の機能を果たします。

　この方法により、メーカーおよびユーザーはさまざまなシークレット管理機能やセキュリティ措置（鍵エスクロー、セキュアローミング、ディレクトリサービスなど）を既存のPKIプラットフォームから活用できます。この方法により、セキュアデバイスの初期化およびユーザークレデンシャルのセキュアなプロビジョニングの両方に適用されます。この統合化されたライフサイクル管理フレームワークでは、既存の公開鍵暗号標準と、XKMSなどの近代的なプロトコルを活用していきます。

　検証プロファイルは、すでに述べたように、どの認証プロトコルを選択するかによって、おのずと定義が明確になります。また、検証サービスでは、証明書失効リスト（CRL）や、Online Certificate Status Protocol（OCSP）やXKMSなどの標準を使用して、X.509証明書を検証できるようになります。

　OATHでは、802.1Xと標準的なEAP方式を活用するため、検証サーバはRADIUSサーバと同じ特性があります。RADIUSサーバはすでにISPやエンタープライズネットワークインフラで活用されているので意識的に選択されています。また、高度なRADIUSサーバは、多数のベンダやオープンソースプロジェクトから広く入手することができます。すでに構築済みの多数のRADIUSサーバを活用することにより、OATHでは強固な認証ソリューションの導入に関する複雑性とコストオーバーヘッドの削減を実現しています。

　Webサービスインターフェイスを必要とするアプリケーションについては、SOAP検証プロトコルを検証サーバに実装する必要があります。ネットワークの世界では、強固な認証の検証サーバといえばRADIUSサーバになり、Webサービス指向アーキテクチャでは、検証サーバはWebサービスの1インスタンスとして実装されます。クレデンシャルの検証はクレデンシャルのマッピングとの相互補完性が極めて高いので、検証WebサービスとWeb Services Trust Language（WS-Trust）により定義されたSecurity Token Service（STS）の概念との連結がロードマップの不可欠な要素であるとOATHは考えています。

　次回はHOTPに関して詳しく解説します。

2/2

Index
認証技術の複合化を目指すOATHのロードマップ
	Page1 クレデンシャルおよびセキュリティデバイス オールインワンセキュリティデバイス
	Page2 認証プロトコルフレームワーク クレデンシャルのプロビジョニングと検証

Security&Trust記事一覧

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）