2.15. IKE SA の認証

拡張認証を使用しない場合 (セクション 2.16 参照), ピアは, 各側がデータ・ブロックに署名すること (または, このセクションの後半で説明するように, パディングされた共有鍵を鍵として使用した MAC 演算を行うこと) によって認証されます。これらの計算において, IDi' および IDr' は, 固定ヘッダを除いた ID ペイロード全体です。レスポンダにとって, 署名されるオクテットは, 2 番目のメッセージ (IKE_SA_INIT 応答) のヘッダ内の最初の SPI の最初のオクテットから始まり, 2 番目のメッセージの最後のペイロードの最後のオクテットで終わります。これに付加される (署名の計算のために) のは, イニシエータのナンス Ni (値のみ, それを含むペイロードではない), および値 prf(SK_pr, IDr') です。ナンス Ni も値 prf(SK_pr, IDr') も送信されないことに注意してください。同様に, イニシエータは最初のメッセージ (IKE_SA_INIT 要求) に署名し, ヘッダ内の最初の SPI の最初のオクテットから始まり, 最後のペイロードの最後のオクテットで終わります。これに付加される (署名の計算のために) のは, レスポンダのナンス Nr, および値 prf(SK_pi, IDi') です。交換のセキュリティにとって極めて重要なのは, 各側が相手側のナンスに署名することです。

イニシエータが署名するオクテットは次のように記述できます:

レスポンダが署名するオクテットは次のように記述できます:

すべてのペイロードは, この文書で定義されていないペイロード・タイプを含め, 署名の下に含まれることに注意してください。交換の最初のメッセージが複数回送信された場合 (レスポンダの cookie や別の Diffie-Hellman グループと共になど), 署名されるのはそのメッセージの最新バージョンです。

オプションとして, メッセージ 3 および 4 は, デジタル署名の計算に使用された鍵が ID ペイロード内の名前に属することを証明する証明書, または証明書チェーンを含んでもかまいません (MAY)。署名または MAC は, 署名者が使用する鍵のタイプによって決定され, 認証 (Authentication) ペイロード内の認証メソッド・フィールドで指定されるアルゴリズムを使用して計算されます。イニシエータとレスポンダが同じ暗号アルゴリズムで署名することが要求される (REQUIRED) わけではありません。暗号アルゴリズムの選択は, 各側が持つ鍵のタイプに依存します。特に, イニシエータは共有鍵を使用しているかもしれず, レスポンダは公開署名鍵と証明書を持っているかもしれません。共有鍵を認証に使用する場合, 両方向で同じ鍵が使用されることが一般的ですが (必須ではありません)。

ユーザーが選択したパスワードのみから派性された共有鍵を, 他のランダム性の源を組み込まずに持つことは, 一般的ですが典型的に安全でない慣行であることに注意してください。これは典型的に安全でない理由は, ユーザーが選択したパスワードは辞書攻撃に耐えるほどの予測不可能性を持つ可能性が低く, これらの攻撃はこの認証方式では防止されないからです。(ブートストラップおよび IKE SA にパスワードベースの認証を使用するアプリケーションは, オフライン辞書攻撃を防止するように設計されたセクション 2.16 の認証方式を使用すべきです。) 事前共有鍵は, ネゴシエートされる最強の鍵と同じ程度の予測不可能性を含む必要があります。事前共有鍵の場合, AUTH 値は次のように計算されます:

イニシエータの場合: AUTH = prf( prf(Shared Secret, "Key Pad for IKEv2"), ) レスポンダの場合: AUTH = prf( prf(Shared Secret, "Key Pad for IKEv2"), )

ここで文字列 "Key Pad for IKEv2" は, ヌル終端なしの 17 ASCII 文字です。共有鍵は可変長でかまいません。パッド文字列が追加されるのは, 共有鍵がパスワードから派生している場合, IKE 実装はパスワードを平文で保存する必要がなく, 代わりに値 prf(Shared Secret,"Key Pad for IKEv2") を保存できるようにするためです。この値は, IKEv2 以外のプロトコルのパスワード等価物として使用できません。上記のように, パスワードから共有鍵を派生させるのは安全ではありません。この構成が使用されるのは, 人々がいずれにせよそれを行うと予想されるためです。共有鍵が提供される管理インタフェースは, 少なくとも 64 オクテットの ASCII 文字列を受け入れなければならず (MUST), それらを共有鍵として使用する前にヌル終端を追加してはなりません (MUST)。また, 共有鍵の 16 進エンコーディングを受け入れなければなりません (MUST)。エンコーディングからバイナリ文字列への変換アルゴリズムが指定されている場合, 管理インタフェースは他のエンコーディングを受け入れてもかまいません (MAY)。

EAP 認証には 2 つのタイプがあり (セクション 2.16 で説明), 各タイプは上記の AUTH 計算で異なる値を使用します。EAP メソッドが鍵生成である場合, 計算では共有鍵の代わりにマスター・セッション鍵 (MSK) を使用します。鍵を生成しないメソッドの場合, 2 つの AUTH 計算でそれぞれ共有鍵の代わりに SK_pi および SK_pr を使用します。

2.15. IKE SA の認証​

2.15. IKE SA の認証