The Cable Guy認証済みインターネット プロトコル

Joseph Davies

このコラムには、Windows Server 2008 のプレリリース版に関する説明が含まれています。記載されている内容は変更されることがあります。

Windows Vista および Windows Server 2008 (現在ベータ テスト段階) は、いずれも、インターネット キー交換 (IKE) プロトコルの拡張版である認証済みインターネット プロトコル (AuthIP) をサポートしています。AuthIP も IKE も、キー マテリアルを特定するために使用されるプロトコルで、

インターネット プロトコル セキュリティ (IPsec) を使用して保護される通信のセキュリティ パラメータをネゴシエートします。AuthIP では、多くの構成で、IPsec ポリシー構成と保守が容易になり、IPsec ピア認証の柔軟性が高まります。この記事では、AuthIP のプロトコルの詳細と、AuthIP と IKE の両方をサポートするか IKE のみをサポートする IPsec ピア間の共存動作について説明します。

IKE の概要

ネゴシエーションの例

具体的な共存動作を確認するために、Windows Vista ベースと Windows XP ベースの IPsec ピア間で IPsec 保護をネゴシエートする際の処理を調べてみましょう。

例 1: 要求モードの 2 つの Windows Vista ベースの IPsec ピア

この例では、Windows Vista ベースの IPsec ピア (Peer 1) がイニシエータで、レスポンダ (Peer 2) でも Windows Vista を実行しています。どちらのピアも、着信と発信の両方に要求 (Request) モードが構成されています。要求モードでは、IPsec ピアが IPsec 保護を要求しますが、必須とはしません。交換されるメッセージを以下に示します。

  1. Peer 1 から TCP 同期 (SYN) セグメントをクリア テキストで送信し、Peer 2 との TCP 接続を開始します。
  2. Peer 2 から TCP SYN-Acknowledgment (ACK) セグメントを送信します。
  3. Peer 1 から TCP ACK セグメントを送信します。
  4. Peer 1 から AuthIP ベースの ISAKMP メッセージを送信し、AuthIP のメイン モード ネゴシエーションを開始します。
  5. Peer 1 から IKE ベースの ISAKMP メッセージを送信し、IKE のメイン モード ネゴシエーションを開始します。
  6. Peer 2 から AuthIP ベースの ISAKMP メッセージを応答として返し、AuthIP のメイン モード ネゴシエーションを続行します。
  7. Peer 1 と Peer 2 が AuthIP のメイン モード、クイック モード、および拡張モード (省略可) のネゴシエーションを完了します。
  8. この TCP 接続経由で送信されるこれ以降のセグメントが、IPsec により保護されます。

メッセージ 1 ~ 5 の正確な順序は、ネットワークの待ち時間によって異なります。この記事の例は、待ち時間が非常に短いネットワークを想定しています。このようなネットワークでは、Peer 1 が初期 ISAKMP メッセージ (メッセージ 4 と 5) を送信できるようになる前に、TCP ハンドシェイク (メッセージ 1 ~ 3) が完了します。待ち時間が長いネットワークでは、Peer 1 がクリア テキストの TCP SYN セグメント、AuthIP ベースの ISAKMP メッセージ、および IKE ベースの ISAKMP メッセージを、メッセージ交換の最初の 3 メッセージとして送信します。

例 2: 要求モードの Windows Vista ベースの IPsec ピアと要求モードの Windows XP ベースの IPsec ピア

この例では、Windows Vista ベースの IPsec ピア (Peer 1) がイニシエータで、レスポンダ (Peer 2) は Windows XP を実行しています。どちらのピアも、着信と発信の両方に要求モードが構成されています。交換されるメッセージを以下に示します。

  1. Peer 1 から TCP SYN セグメントをクリア テキストで送信し、Peer 2 との TCP 接続を開始します。
  2. Peer 2 から TCP SYN-ACK セグメントを送信します。
  3. Peer 1 から TCP ACK セグメントを送信します。
  4. Peer 1 から AuthIP ベースの ISAKMP メッセージを送信し、AuthIP のメイン モード ネゴシエーションを開始します。
  5. Peer 1 から IKE ベースの ISAKMP メッセージを送信し、IKE のメイン モード ネゴシエーションを開始します。
  6. Peer 2 から IKE ベースの ISAKMP メッセージを応答として返し、IKE のメイン モード ネゴシエーションを続行します。
  7. Peer 1 と Peer 2 が IKE のメイン モードとクイック モードのネゴシエーションを完了します。
  8. この TCP 接続経由で送信されるこれ以降のセグメントが、IPsec により保護されます。

例 3: 要求モードの Windows Vista ベースの IPsec ピアと必須モードの Windows XP ベースの IPsec ピア

この例では、Windows Vista ベースの IPsec ピア (Peer 1) がイニシエータで、レスポンダ (Peer 2) は Windows XP を実行しています。Peer 1 では発信に要求モードが構成され、Peer 2 では着信に必須 (Require) モードが構成されています。必須モードでは、IPsec ピアは IPsec 保護を必須とし、保護されていないパケットを確認なしで破棄します。交換されるメッセージを以下に示します。

  1. Peer 1 から TCP SYN セグメントをクリア テキストで送信して TCP 接続を開始しますが、Peer 2 ではこのメッセージを確認なしで破棄します。
  2. Peer 1 から AuthIP ベースの ISAKMP メッセージを送信して AuthIP のメイン モード ネゴシエーションを開始しますが、Peer 2 ではこのメッセージを確認なしで破棄します。
  3. Peer 1 から IKE ベースの ISAKMP メッセージを送信し、IKE のメイン モード ネゴシエーションを開始します。
  4. Peer 2 から IKE ベースの ISAKMP メッセージを応答として返し、IKE のメイン モード ネゴシエーションを続行します。
  5. Peer 1 と Peer 2 が IKE のメイン モードとクイック モードのネゴシエーションを完了します。
  6. Peer 1 から (IPsec で保護された) TCP SYN セグメントを再送信します。
  7. Peer 2 から (IPsec で保護された) TCP SYN-ACK セグメントを送信します。
  8. Peer 1 から (IPsec で保護された) TCP ACK セグメントを送信します。

IKE は、RFC 2409 (ietf.org/rfc/rfc2409.txt) で規定されているインターネット標準で、IPsec セキュリティ アソシエーション (SA) を確立するメカニズムを定義します。SA は、双方の IPsec ピアが相互に同意できるポリシーとキーを組み合わせたもので、ピア間の通信を保護するのに役立つセキュリティ サービスとメカニズムを定義します。具体的には、IKE は RFC 2408 で規定される Internet Security Association and Key Management Protocol (ISAKMP) と Oakley Key Determination Protocol (RFC 2412) との組み合わせです。IKE は Oakley Key Determination プロトコルを使用して、保護された通信のシークレット キー マテリアルを生成します。

IKE は ISAKMP を使用して SA をネゴシエートします。ISAKMP には、ピアの識別と認証、SA の管理、およびキー マテリアルの交換を行う機能があります。ISAKMP は、特定のキー交換プロトコル、暗号化や整合性のアルゴリズム、および認証方式に依存しない、保護された通信をネゴシエートするためのフレームワークです。

IPsec の各ピアは IKE を使用して、メイン モードとクイック モードのネゴシエーションを実行します。メイン モードのネゴシエーションでは、ISAKMP SA が作成され、これによりセキュリティ ネゴシエーションが保護されます。イニシエータとレスポンダは、メイン モードのネゴシエーション中に、ISAKMP SA の暗号化とハッシュのアルゴリズムのネゴシエート、キー決定マテリアルの交換、およびピア相互の識別と認証のために、一連の ISAKMP メッセージを交換します。

クイック モードのネゴシエーション フェーズでは、2 つの IPsec SA (着信データ用の SA と発信データ用の SA) が作成され、2 つの IPsec ピア間で送信されるデータを保護します。イニシエータとレスポンダは、クイック モードのネゴシエーション中に、着信と発信の両方の IPsec SA の暗号化とハッシュのアルゴリズムをネゴシエートするために、一連の暗号化された ISAKMP メッセージを交換します。

IKE ベースのメイン モードとクイック モードのネゴシエーションの詳細については、「IPsec セキュリティ アソシエーションの IKE ネゴシエーション」(microsoft.com/technet/community/columns/cableguy/cg0602.mspx) を参照してください。

AuthIP の概要

AuthIP は IKE の拡張版で、ユーザー ベースの認証、複数の資格情報での認証、強化された認証方式のネゴシエーション、および非同期認証をサポートする柔軟性の高いプロトコルです。IKE と同様、AuthIP はメイン モードとクイック モードのネゴシエーションをサポートしています。また、AuthIP は拡張モードもサポートします。これは、IPsec ピア ネゴシエーションの一部で、このモード中に 2 回目の認証を実行できます。拡張モードの使用は任意で、複数の認証に使用できます。たとえば、拡張モードでは、コンピュータ ベースの認証とユーザー ベースの認証を個別に実行することができます。

複数認証のサポートは、ネットワーク アクセス保護 (NAP) プラットフォームの IPsec 実施に採用されています。IPsec 実施では IPsec ピアがコンピュータ資格情報を使用して認証を行うだけでなく、正常性証明書を使用してシステムの正常性要件に準じていることを証明します。ネットワーク アクセス保護の詳細については、microsoft.com/nap を参照してください。また、AuthIP の機能の詳細については、「Windows Vista の AuthIP」(microsoft.com/technet/community/columns/cableguy/cg0806.mspx) を参照してください。

AuthIP メッセージ

IKE でも AuthIP でも、キー交換と SA ネゴシエーションのプロトコルとして ISAKMP を使用します。ISAKMP メッセージは、ユーザー データグラム プロトコル (UDP) 経由で送信され、ISAKMP ヘッダーと 1 つまたは複数の ISAKMP ペイロードで構成されます。ISAKMP ヘッダーには、メッセージの種類など、メッセージについての情報が含まれます。図 1 に、ISAKMP ヘッダーのフォーマットを示します。

図 1 ISAKMP ヘッダーのフォーマット

図 1** ISAKMP ヘッダーのフォーマット **

ISAKMP ヘッダーの Initiator Cookie と Responder Cookie には、IPsec ピアによって選択されたゼロ (0) 以外の乱数が設定されます。Next Payload フィールドは、ISAKMP ヘッダーの直後に続く ISAKMP メッセージの最初のペイロードを示します。RFC 2408 では、Next Payload フィールドの値が定義されています。ペイロードの種類 128 ~ 255 は、プライベートで使用するために予約されています。Major Version フィールドと Minor Version フィールドは、ISAKMP メッセージを送信している IPsec ピアの ISAKMP のバージョンを示します。IKE と AuthIP では、メジャー バージョンは 1、マイナー バージョンは 0 です。

Exchange Type フィールドは、実行される ISAKMP 交換の種類を示します。交換の種類により、ISAKMP ペイロードの構造と順序が示されます。RFC 2408 では、Exchange Type フィールドの値が定義されています。交換の種類 128 ~ 255 は、プライベートで使用するために予約されています。

Flags フィールドには RFC 2408 で定義されている 3 つのフラグが設定されます。最下位ビット (ビット 0) は "暗号化" ビットで、ISAKMP ペイロードが暗号化されているか (1 に設定されている場合)、暗号化されていないか (0 に設定されている場合) を示します。暗号化は、ISAKMP SA 用にネゴシエートされたアルゴリズムを使用して行われます。これは、Initiator Cookie フィールドと Responder Cookie フィールドの組み合わせにより特定されます。次のビット (ビット 1) は "コミット" ビットで、キー交換が同期されるか (1 に設定されている場合)、同期されないか (0 に設定されている場合) を示します。コミット ビットは、SA がネゴシエーションを完了してから暗号化データが送信されるようにするために使用されます。次のビット (ビット 2) は "認証のみ" ビットで、メッセージに情報提供の交換の種類である Notify ペイロード全体が含まれるか (1 に設定されている場合)、含まれないか (0 に設定されている場合)、および認証はされていても暗号化はされていないことを示します。

Message ID フィールドには、メッセージの一意の識別子が設定されます。Message ID は、両方の IPsec ピアが同時に IPsec SA の確立を試みた場合に、競合を防ぐために使用されます。Length フィールドは、ISAKMP メッセージ全体の長さを示します。

IKE の場合、ISAKMP メッセージには、一連の ISAKMP ペイロードが含まれます。最初のペイロードは、ISAKMP ヘッダーの Next Payload フィールドにより示されます。各 ISAKMP ペイロードには、それぞれ次のペイロードを示す Next Payload フィールドがあります。最後のペイロードの Next Payload フィールドは 0 に設定されます。図 2 に、IKE メッセージのフォーマットを示します。

図 2 IKE メッセージのフォーマット

図 2** IKE メッセージのフォーマット **

AuthIP は、ISAKMP ヘッダーの Exchange Type フィールド内の交換の種類が 243 (メイン モード)、244 (クイック モード)、245 (拡張モード)、および 246 (通知) である ISAKMP メッセージを使用します。AuthIP ベースの ISAKMP メッセージとの重要な違いは、ISAKMP ペイロードが 1 つしか含まれないことです。これは、Crypto ペイロードまたは Notify ペイロードのいずれかになります。Crypto ペイロードには、メイン モード、クイック モード、または拡張モードのネゴシエーションで使用される埋め込みペイロードが含まれます。Crypto ペイロードには、ISAKMP ヘッダーの Flags フィールドに設定された "暗号化" ビットの値に応じて、プレーン テキストまたは暗号化された一連のペイロードが含まれます。図 3 に、Crypto ペイロードを含む AuthIP メッセージのフォーマットを示します。

図 3 Crypto ペイロードを含む AuthIP メッセージのフォーマット

図 3** Crypto ペイロードを含む AuthIP メッセージのフォーマット **

AuthIP と IKE の共存

Windows Vista® と Windows Server® 2008 は、IKE と AuthIP の両方をサポートします。しかし、Windows® XP と Windows Server 2003 がサポートしているのは、IKE のみです。開始側の IPsec ピアが AuthIP と IKE 両方をサポートしていて、AuthIP と IKE の両方を使用する接続セキュリティ ポリシーがある場合、このピアでは応答側の IPsec ピアが AuthIP または IKE のどちらをサポートしているかを特定する必要があります。その上で、IPsec 保護のネゴシエーションに最適なプロトコルを使用する必要があります (AuthIP の方が IKE よりも優先的に使用されます)。

応答側の IPsec ピアのネゴシエーション プロトコルを判断するため、AuthIP と IKE の両方を使用する開始側 IPsec ピアは、次のメッセージを同時に送信します。

  • メッセージ 1 - メイン モードのネゴシエーションを開始する AuthIP メッセージ
  • メッセージ 2 - メイン モードのネゴシエーションを開始する IKE メッセージ

応答側ノードが AuthIP をサポートしている場合は、メッセージ 1 に応答してメイン モードのネゴシエーションを続行する AuthIP メッセージを返し、メッセージ 2 は確認なしに破棄する必要があります。AuthIP をサポートしていない応答側ノードでは、メッセージ 1 の Exchange Type フィールドに応答側ノードがサポートする値が含まれていないため、メッセージ 1 を確認なしに破棄し、メッセージ 2 に応答します。

メッセージ 1 がネットワーク上で失われたり、メッセージ 2 の後に受信された場合に、Windows Vista または Windows Server 2008 を実行する IPsec ピア間で IKE ベースのネゴシエーションが行われないようにするため、Windows Vista または Windows Server 2008 を実行する IPsec ピアはメッセージ 2 に AuthIP Supported vendor ID ISAKMP ペイロードを設定してメッセージ 2 を送信します。AuthIP Supported vendor ID ペイロードは、IPsec ピアが AuthIP をサポートしていることを示します。

したがって、Windows Vista または Windows Server 2008 を実行する IPsec ピアが AuthIP supported vendor ID ペイロードを含むメッセージ 2 を受信した場合、開始側の IPsec ピアがメッセージ 1 と 2 を再送するのを待って、メッセージ 1 に応答します。

開始側 IPsec ピアは、応答を受信するかタイムアウトになるまで、メッセージ 1 と 2 の再送を続けます。イニシエータは応答を受信すると、この応答の ISAKMP ヘッダーを基にレスポンダの機能を判断します。Exchange Type が 243 (AuthIP ベースのメイン モードのネゴシエーションを示す交換の種類) に設定されている場合、レスポンダは AuthIP に対応しています。Exchange Type が 2 (ID 保護および IKE ベースのメイン モードのネゴシエーションを示す交換の種類) に設定されている場合、レスポンダは IKE に対応しています。

イニシエータはこの応答を基に、AuthIP メイン モードのネゴシエーションの次の AuthIP メッセージか、IKE メイン モードのネゴシエーションの次の IKE メッセージを応答として返します。IPsec ピアは、ISAKMP SA のネゴシエーションに使用されたものと同じプロトコルを、この SA の有効期間を通じて使用する必要があります。

Joseph Davies は、マイクロソフトのテクニカル ライターであり、月刊の TechNet Cable Guy コラム (Microsoft.com/technet/community/columns/cableguy) の執筆者でもあります。

© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; 許可なしに一部または全体を複製することは禁止されています.