2.16. 拡張認証プロトコル・メソッド
2.16. 拡張認証プロトコル・メソッド
公開鍵署名および共有鍵を使用した認証に加えて, IKE は RFC 3748 [EAP] で定義されたメソッドを使用した認証をサポートします。典型的には, これらのメソッドは非対称 (ユーザーがサーバーに対して認証するように設計) であり, 相互的ではないかもしれません。この理由から, これらのプロトコルは典型的にはイニシエータをレスポンダに対して認証するために使用され, イニシエータに対するレスポンダの公開鍵署名ベースの認証と組み合わせて使用されなければなりません (MUST)。これらのメソッドは, 多くの場合 "レガシー認証" (Legacy Authentication) メカニズムと呼ばれるものに関連付けられています。
この文書は, 本仕様を更新せずに将来新しいメソッドを追加できるようにする意図で [EAP] を参照していますが, ここではいくつかの単純なバリエーションを文書化しています。 [EAP] は, 可変数のメッセージを必要とする認証プロトコルを定義しています。拡張認証は, IKE において, IKE SA を初期化するために完了されなければならない (MUST) 追加の IKE_AUTH 交換として実装されます。
イニシエータは, IKE_AUTH 交換の最初のメッセージから AUTH ペイロードを省略することで, EAP を使用したいことを示します。 (非 EAP 認証の場合, AUTH ペイロードは必須であるため, この文書の残りの部分ではオプションとしてマークされていないことに注意してください。) IDi ペイロードを含めるが AUTH ペイロードを含めないことにより, イニシエータはアイデンティティを宣言したがまだそれを証明していません。レスポンダが EAP メソッドを使用する意思がある場合, それは IKE_AUTH 交換の応答に拡張認証プロトコル (EAP) ペイロードを配置し, イニシエータ認証が後続の IKE_AUTH 交換で完了するまで SAr2, TSi, TSr の送信を遅延させます。最小 EAP メソッドの場合, 初期 SA 確立は次のように現れます:
Initiator Responder
HDR, SAi1, KEi, Ni --> <-- HDR, SAr1, KEr, Nr, [CERTREQ] HDR, SK {IDi, [CERTREQ,] [IDr,] SAi2, TSi, TSr} --> <-- HDR, SK {IDr, [CERT,] AUTH, EAP } HDR, SK {EAP} --> <-- HDR, SK {EAP (success)} HDR, SK {AUTH} --> <-- HDR, SK {AUTH, SAr2, TSi, TSr }
セクション 2.2 で説明したように, EAP が使用される場合, IKE SA 初期セットアップ・メッセージの各ペアのメッセージ番号はインクリメントされます。最初の AUTH メッセージ・ペアの ID は 1, 2 番目は 2, 以下同様です。
認証の副作用として共有鍵を作成する EAP メソッドの場合, その共有鍵は, メッセージ 7 および 8 でセクション 2.15 で指定された共有鍵の構文を使用して AUTH ペイロードを生成するために, イニシエータとレスポンダの両方によって使用されなければなりません (MUST)。EAP からの共有鍵は, EAP 仕様で MSK と名付けられたフィールドです。IKE 交換中に生成されたこの共有鍵は, いかなる他の目的にも使用されてはならない (MUST NOT)。
共有鍵を確立しない EAP メソッドは使用されるべきではありません (SHOULD NOT)。なぜなら, これらの EAP メソッドが, サーバー認証トンネルを使用しない他のプロトコルで使用された場合, いくつかの中間者攻撃 (man-in-the-middle attacks) [EAPMITM] を受けるためです。詳細についてはセキュリティ考慮事項のセクションを参照してください。共有鍵を生成しない EAP メソッドが使用される場合, メッセージ 7 および 8 の AUTH ペイロードは, それぞれ SK_pi および SK_pr を使用して生成されなければなりません (MUST)。
EAP を使用する IKE SA のイニシエータは, レスポンダが通知メッセージを送信したり認証プロンプトを再試行したりする場合に備えて, 初期プロトコル交換を少なくとも 10 の IKE_AUTH 交換に拡張できる必要があります。選択された EAP 認証メソッドによって定義されたプロトコル交換が正常に終了すると, レスポンダは Success メッセージを含む EAP ペイロードを送信しなければなりません (MUST)。同様に, 認証メソッドが失敗した場合, レスポンダは Failure メッセージを含む EAP ペイロードを送信しなければなりません (MUST)。レスポンダは, Failure メッセージを含む EAP ペイロードを送信することで, いつでも IKE 交換を終了してもかまいません (MAY)。
そのような拡張交換に続いて, EAP AUTH ペイロードは, EAP Success メッセージを含むメッセージに続く 2 つのメッセージに含まれなければならません (MUST)。
イニシエータ認証が EAP を使用する場合, IDi ペイロードの内容は, 認証, 認可, およびアカウンティング (AAA) ルーティング目的およびどの EAP メソッドを使用するかの選択のためのみに使用される可能性があります。この値は, EAP メソッドによって認証されたアイデンティティと異なる場合があります。ポリシー検索およびアクセス制御決定は, 実際に認証されたアイデンティティを使用することが重要です。多くの場合, EAP サーバーは, IKEv2 レスポンダと通信する別個の AAA サーバーに実装されています。この場合, 認証されたアイデンティティは, IDi ペイロード内のものと異なる場合, AAA サーバーから IKEv2 レスポンダに送信されなければなりません。