2.7. アルゴリズムのネゴシエーション

実装がサポートする各暗号アルゴリズムは, 特定の SA 属性タイプ, 変換 ID 値, および必要なパラメータ (キー長など) で指定されなければなりません (MUST)。これらは [IKEV2IANA] にリストされています。

単一の SA 提案において, 実装はある提案と互換性のある複数の変換の組をリストできます。各組のメンバーはすべて互換性がなければなりません (MUST)。変換 ID "NONE" (値 0) がリストされている場合, その変換 ID はそのタイプでリストされている唯一の変換でなければなりません (MUST)。NONE は整合性 (integrity) アルゴリズムに対してのみ許可されます。NONE 整合性アルゴリズムは, 複合モード暗号アルゴリズムが使用されない限り (セクション 3.3.2 参照), 整合性保護が提供されないことを意味します。複合モード暗号アルゴリズムが選択された場合, 暗号アルゴリズム用に別個の整合性アルゴリズムを指定すべきではなく (SHOULD NOT), MUST は NONE でなければなりません (MUST) (セクション 3.3.2 参照)。NONE は他の状況では拒否されなければなりません (MUST)。

イニシエータは, その実装がサポートする少なくとも 1 つの提案を提示しなければならず (MUST), レスポンダはその実装がサポートする最初の提案を受け入れなければなりません (MUST)。複数の互換提案がある場合のレスポンダの動作は実装依存です。イニシエータは, その実装がサポートする提案のみを含めなければなりません (MUST)。レスポンダは, 以前の IKE 交換ですでにピアから受信しより好む提案を提示されている場合, 有効な提案を拒否してもかまいません (MAY)。

各プロトコル (IKE または AH または ESP) をネゴシエートするために, SA ペイロードには少なくとも 1 つの提案が含まれなければならず (MUST), 各提案には各タイプにつき少なくとも 1 つの変換を含まなければなりません (MUST): 各タイプ (暗号, 整合性, PRF, DH) につき最大 1 つの変換。ただし, 複数の変換を別個にネゴシエートできない場合 (例えば, 整合性保護を含むが別個の変換としては含まれない複合モード暗号アルゴリズム) は除きます。暗号スイート自体は複合であってかまいませんが, 複合アルゴリズムは SA ペイロード内では別個の変換として表されることに注意してください。

2.7.1. 暗号スイートの選択

各実装は以下の暗号スイートを実装しなければなりません (MUST):

暗号: ENCR_AES_CBC, および AEAD 暗号アルゴリズム ENCR_AES_GCM_16 (セクション 3.3.2 参照)。実装は代替の AES 変換として ENCR_AES_CTR を実装してもかまいません (MAY)。実装は ENCR_3DES, ENCR_DES, ENCR_CAST, ENCR_BLOWFISH を実装してもかまいません (MAY) が, これらは時代遅れであり, 新しい実装には推奨されません (SHOULD NOT)。
疑似乱数関数: PRF_HMAC_SHA1。実装は PRF_HMAC_SHA1 を実装しなければならず (MUST), また PRF_AES128_XCBC および PRF_HMAC_SHA2_256, PRF_HMAC_SHA2_384, PRF_HMAC_SHA2_512 を実装してもかまいません (MAY)。
整合性: AUTH_HMAC_SHA1_96。実装は AUTH_HMAC_SHA1_96 を実装しなければならず (MUST), また AUTH_AES_XCBC_96, AUTH_HMAC_SHA2_256_128, AUTH_HMAC_SHA2_384_192, AUTH_HMAC_SHA2_512_256 を実装してもかまいません (MAY)。
有限体 DH グループ: 1024 ビット MODP グループ 2 および EC グループ 19 を実装しなければなりません (MUST)。実装は代替として 2048 ビット MODP グループ 14 (および EC グループ 20, 21, 23, 24, 25) を実装してもかまいません (MAY)。EC グループとグループ 2 の相互運用性はまだ確立されていませんが, 標準化の利点は, より新しい実装が EC グループのみをサポートする場合でも, デプロイメントが特定のグループに標準化できるようにすることです。
実装は他の Diffie-Hellman グループを実装してもかまいません (MAY) が, 必須ではありません (REQUIRED)。

一見すると, この文書は特定のアルゴリズムの実装を要求すべきではないように思えます。なぜなら, 暗号解読の進歩によってそれらが時代遅れになる可能性があるからです。しかし, すべての実装が異なるオプションのアルゴリズムの集合を選択した場合, 相互運用性は達成不可能になります。したがって, この文書は強制アルゴリズムの最小集合を定義し, 新しいアルゴリズムがこれらのアルゴリズムとともにネゴシエートされることを要求します。したがって, ある実装に必要なすべてのアルゴリズムは, 強制であり標準化されている (上記のとおり), または上記にリストされた強制アルゴリズムのいずれかを実装しているべきです (SHOULD)。

実装は識別用の X.509 v3 証明書, および (AUTH ペイロード内の) 署名用の RSA と非可逆 ECDSA ([PKI] および [EAIKEv2] に記述) をサポートすべきです (SHOULD)。EAP をサポートするために, 実装は EAP 認証をサポートしなければなりません (MUST)。EAP をサポートする実装は EAP 方式 EAP-MSCHAPv2 をサポートすべきであり (SHOULD), 他の方式をサポートしてもかまいません (MAY)。事前共有鍵認証のサポートは強く推奨されます (RECOMMENDED)。

2.7.2. 再ネゴシエーション

IKE SA においては, 他の手配 (例えば "揮発性" の CREATE_CHILD_SA 交換, セクション 2.18 参照) がなされない限り, SA の存続期間中, ネゴシエートされた暗号アルゴリズムの暗号スイートは変更されるべきではありません (SHOULD NOT)。再ネゴシエーションは, 期限切れになりつつある SA を置き換えるため, または既存の IKE SA 用に新しい (証明書ベースの) 鍵または識別をネゴシエートするため, あるいは IKE SA の属性 (例えば, 事前共有鍵認証から証明書認証への切り替え) を変更するために開始されてもかまいません (MAY)。再ネゴシエーション中, メッセージ・フローのほとんどは繰り返されますが, それは平文ではなく, 既存の IKE SA の保護された部分内で完了します。

再ネゴシエーションは CREATE_CHILD_SA 交換を使用するため, 既存の IKE SA に対して新しい子 SA を作成する効果があります。イニシエータは CREATE_CHILD_SA 交換において SA ペイロード (プロトコル ID を含む) を指定せず, 既存の IKE SA 自体の再ネゴシエーションを望んでいることを示してもかまいません (MAY)。この場合, CREATE_CHILD_SA 交換が IKE SA の再ネゴシエーションに使用されるとき, それは同時に子 SA の作成には使用されてはならない (MUST NOT)。このタイプの交換は "タイプ 1" 再ネゴシエーションとも呼ばれます。

イニシエータが CREATE_CHILD_SA 交換に SA ペイロードを含める場合, その SA ペイロードは子 SA (または追加の子 SA) の作成に使用されなければならず (MUST), 同時に IKE SA を再ネゴシエートし, レスポンダはそれを受け入れなければなりません (MUST)。このタイプの交換は "タイプ 2" 再ネゴシエーションとも呼ばれます。タイプ 2 再ネゴシエーションのサポートは必須ではありません (REQUIRED)。

2.7.3. サポートされる認証方式

実装は以下の認証方式をサポートしなければなりません (MUST):

デジタル署名ベース (セクション 3.8 参照), [PKI] および [EAIKEv2] に記述された RSA または非可逆 ECDSA アルゴリズムを使用。
事前共有鍵 (セクション 2.15 および 3.8 参照)。
拡張認証プロトコル (EAP), [EAP] に記述されたもの。

実装は他の認証方式をサポートしてもかまいません (MAY) が, 必須ではありません (REQUIRED)。