メインコンテンツまでスキップ

2.16. Extensible Authentication Protocol Methods (拡張認証プロトコル方式)

2.16. Extensible Authentication Protocol Methods (拡張認証プロトコル方式)​

公開鍵署名と共有秘密に加え, IKE は RFC 3748 [EAP] で定義された方式をサポートする. 多くは非対称 (ユーザーがサーバに認証) で, 相互でない場合がある. したがって通常, イニシエータをレスポンダに認証させるために用い, レスポンダをイニシエータに認証させる公開鍵署名ベースの認証と組み合わせなければならない.

本書は [EAP] を参照し将来の方式追加を本仕様の更新なしに可能にするが, 単純な変種もここに記す. [EAP] は可変メッセージ数の認証プロトコルを定義する. IKE での拡張認証は追加の IKE_AUTH 交換として実装され, IKE SA を初期化するにはこれらを完了しなければならない.

イニシエータは IKE_AUTH 交換の最初のメッセージで AUTH ペイロードを省略することで EAP の利用を示す. (非 EAP では AUTH が必須のため, 本書の他では任意とマークされていない.) IDi を含み AUTH を含まないことで, 身元を宣言したが証明していない状態になる. レスポンダが EAP を受け入れる場合, IKE_AUTH 応答に EAP ペイロードを置き, 後続 IKE_AUTH でイニシエータ認証が完了するまで SAr2, TSi, TSr の送信を遅延する. 最小 EAP の例:

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 初期設定の各メッセージ対はメッセージ番号が増える.

認証の副作用として共有鍵を生成する EAP 方式では, その共有鍵をイニシエータとレスポンダの双方がメッセージ 7 と 8 の AUTH 生成に 2.15 節の共有秘密構文で用いなければならない. EAP からの共有鍵は EAP 仕様の MSK フィールドである. IKE 交換中に生成したこの共有鍵は他の目的に用いてはならない.

共有鍵を確立しない EAP 方式は, サーバ認証トンネルを用いない他プロトコルで用いると中間者攻撃 [EAPMITM] の対象となるため, 用いるべきではない. 詳細はセキュリティ考慮を参照. 鍵を生成しない EAP を用いる場合, メッセージ 7 と 8 の AUTH はそれぞれ SK_pi と SK_pr で生成しなければならない.

EAP を用いる IKE SA のイニシエータは, レスポンダが通知や認証プロンプト再試行を送る場合に備え, 少なくとも 10 回の IKE_AUTH 交換まで拡張できなければならない. 選択した EAP 方式の交換が正常終了したら, レスポンダは Success を含む EAP ペイロードを送らなければならない. 失敗時は Failure を含む EAP ペイロードを送らなければならない. レスポンダはいつでも Failure を含む EAP で IKE を終了してよい.

そのような拡張交換の後, EAP Success を含むメッセージの直後 2 メッセージに EAP の AUTH ペイロードを含めなければならない.

イニシエータ認証に EAP を用いる場合, IDi の内容は AAA ルーティングや EAP 方式選択にのみ用いられることがある. EAP で認証された実際の身元と異なってよい. ポリシー参照とアクセス制御は実際に認証された身元を用いることが重要である. EAP サーバは IKEv2 レスポンダと別の AAA サーバに実装されることが多い. その場合, 認証された身元が IDi と異なれば AAA から IKEv2 レスポンダに送る必要がある.

に最終更新