ネットワーク WG
Request for Comments: 2409
分類: スタンダードトラック
D. Harkins
D. Carrel
cisco Systems
1998年11月

English

IKE: インターネット鍵交換
(
The Internet Key Exchange (IKE))

このメモの位置付け

このドキュメントは、インターネットコミュニティにおけるインターネット標準化手順を規定するとともに、改善のための議論や提案を求めるものである。このプロトコルの標準化段階と状態については、最新の "Internet Official Protocol Standards" (STD 1) を参照してほしい。このメモの配布には制限を設けない。

著作権表記

Copyright (C) The Internet Society (1998). All Rights Reserved.

目次

1 概要

2 内容

3 単語とその定義

3.1 記法における要求
3.2 表記法
3.3 Perfect Forward Secrecy/PFS
3.4 Security Association/SA

4 紹介

5 交換

5.1 デジタル署名による認証
5.2 公開鍵暗号による認証
5.3 公開鍵暗号による認証の改定版
5.4 既共有鍵による認証
5.5 Quick モード
5.6 New Group モード
5.7 ISAKMP Informational  交換

6 Oakley グループ

6.1 第一 Oakley デフォルト・グループ
6.2 第二 Oakley グループ
6.3 第三 Oakley グループ
6.4 第四 Oakley グループ

7 完全な交換のペイロードの組立図

7.1 Main モードによるフェイズ1
7.2 Quick モードによるフェイズ2

8 PFS の例

9 実装上のヒント

10 セキュリティについての考慮事項

11 IANA についての考察

12 謝辞

13 参照

補遺 A

補遺 B

著者のアドレス

著者からの注意

著作権表記全文

 

1 概要 English

ISAKMP ( [MSST98] ) は、認証と鍵交換のフレームワークを提供するが、定義は行なわない。ISAKMP は鍵交換から独立するように設計されている。つまり、多種の鍵交換をサポートするように設計されている。

Oakley ( [Orm96] ) では、― モードと呼ばれる ― 一連の鍵交換と、それぞれが提供するサービス (例、PFS、ID 保護、認証) の詳細について解説している。

SKEME ( [SKEME] ) は、匿名性、否認可能性、高速鍵更新を提供する、鍵交換技術全般に渡って解説している。

本ドキュメントでは、ISAKMP や IETF IPsec DOI の AH や ESP などの Security Association (SA) で使用する認証された鍵関連のものを取得する、 Oakley の一部、SKEME の一部を、ISAKMP と共同で使用するプロトコルを解説している。

2 内容 English

このメモでは、ハイブリッド (統合) プロトコルを解説している。その目的は、保護された状態の SA のための、認証された鍵関連のものをネゴシエートし提供する事である。

このメモを実装した処理は、VPN のネゴシエートに使われたり、(IP アドレスが事前にはわかっていない) 遠隔地のユーザからの安全なホストやネットワークへの接続を提供するために使用する事ができる。

クライアント・ネゴシエーションがサポートされる。クライアント・モードでは、ネゴシエーションを行なうものが、SA ネゴシエーションが働くエンドポイント (終端) とは異なる。クライアント・モードが使用される場合、エンドポイントが何であるかは隠されたままである。

本ドキュメントでは、Oakley プロトコル全体を実装するためのものではなく、目標を満足するために必要なサブセットにすぎない。Oakley プロトコル全体に対して適合、準拠していると主張するものではないし、また Oakely プロトコルといかなる依存性があるものでもない。

同様に、SKEME プロトコル全体を実装するものでもなく、認証のための公開鍵暗号の手法と、nonce (その時だけ有効な情報)の交換による高速な再鍵化のコンセプトのためだけのものである。このプロトコルは SKEME プロトコルとは、何の関係もない。

3 用語と定義 English

3.1 記法における要求 English

「しなければならない」、「してはならない」、「要求されている」、「する必要がある」、「しないほうがよい」、「してもよい」、本文中のある、これらのキーワードは、[Bra97] に解説されているように解釈されなければならない。

3.2 記法 English

本メモを通して、以下の記法を使用する。

HDR は、そのモードでの交換タイプの ISAKMP ヘッダである。 HDR* と書かれている場合は、ペイロード暗号化を示す。

SA は、一つ以上のプロポーザルが入った SA ネゴシエーションペイロードである。 イニシエータは、ネゴシエーションにあたって複数の提案を行なってもよい: レスポンダは一つに対してだけリプライしなければならない

<P>_bは、ISAKMP 汎 vpayload を含まない、ペイロード <P> のボディを示す。

SAi_b は、SA ペイロードのボディ全体 (ISAKMP 汎ヘッダを除く) である ― 例を上げると、DOI での、イニシエータが送る、 situation、すべてのプロポーザル、すべての変換である。

CKY-I と CKY-R は、それぞれ、ISAKMP ヘッダ中のイニシエータとレスポンダのクッキーである。

g^xi と g^xr は、それぞれ、イニシエータとレスポンダの Diffie-Hellman ( [DH] ) 公開値である。

g^xy は、Diffie-Hellman 共通鍵である。

KE は、Diffie-Hellman 交換で交換される公開情報を含む、鍵交換ペイロードであ。KE ペイロードに対しては、特別のエンコード (例、TLV) は使用されない。

Nx は、nonce ペイロードであり、x の部分は、ISAKMP イニシエータとレスポンダに対して、それぞれ、i と r となる。

IDx は、"x" に対しての ID ペイロードである。x の部分は、ISAKMP イニシエータとレスポンダに対して、フェイズ 1 ネゴシエーション中は、それぞれ、"ii" と "ir"、フェイズ 2 ネゴシエーション中は、それぞれ、"ui" と "ur" となる。インターネット DOI での ID ペイロード形式は [Pip97] で定義されている。

SIG は、シグネチャ・ペイロードである。どのデータにたいしてサインするかは、交換ごとに変わる。

CERT は、証明書ペイロードである。

HASH (および派生するHASH (2) やHASH_I) は、ハッシュペイロードである。ハッシュの内容は、認証方式によって異なる。

prf (key,msg) は、暗号化された擬似乱数関数 ― しばしば暗号化されたハッシュ関数 ― であり、擬似乱数のように見える決定論的出力を生成するために使われる。prf は鍵の生成と認証の両方で使用される。

SKEYID は、交換に参加しているものだけが知っている、秘密鍵素材から生成される文字列である。

SKEYID_e は、ISAKMP SA が自分のメッセージの秘匿性を守るために使用する鍵素材である。

SKEYID_a は、ISAKMP SA が自分のメッセージを認証するために使用する鍵素材である。

SKEYID_d は、非 ISAKMP SA のための鍵を生成するために使用される鍵素材である。

-->は、"イニシエータからレスポンダ" への通信である (リクエスト)

<--は、"レスポンダからイニシエータ" への通信である (リプライ)

|は、情報の連結を示す ― 例えば、X | Y は、X に Y が続くという事である。

[x] は、x がオプションであり、なくても良い事を示す。

(ISAKMP ヘッダの後に '*' がついて表わされる) メッセージ暗号化は、ISAKMP ヘッダの直後から始まらなければならない。通信を保護する場合、ISAKMP ヘッダに続くすべてのペイロードは暗号化されなければならない。暗号化鍵は、各アルゴリズム毎に定義される方法にしたがって、SKEYID_e から生成される。

3.3 Perfect Forward Secrecy/PFS English

メモ中では、Perfect Forward Secrecy (PFS) は、一つの鍵からは、一つの鍵によって保護されたデータだけにしかアクセスを許さないための折り合いという概念を指す。PFS を成り立たせるためには、データの転送を保護するすめに使われる鍵を、更なる鍵の生成に使ってはならず、データ転送を保護するために使用される鍵が、別のある鍵素材から生成されたものであるならば、その情報からさらなる鍵を生成してはならない。

鍵と ID 両方に対しての PFS は、本プロトコルによって提供される ( セクション5.5セクション8 を参照)。

3.4 Security Association/SA English

SA は、情報を保護するために使用される、ポリシーと鍵のセットである。ISAKMP SA は、このプロトコルの元で、ピア間が通信を保護するために、ネゴシエーションで使用する、共有されているポリシーと鍵である。

4 紹介 English

Oakley と SKEME は、それぞれ、認証された鍵交換を確立するための方方を定義している。 これには、ペイロードの構成、それらに含まれる情報、それらを処理する順序と、それらをどう使用するかといったことが含まれる。

Oakley では「モード (mode)」を定義するが、ISAKMP では「フェイズ (phase)」が定義される。 これら二つの間の関係は、とてもはっきりしたもので、IKE は二つのフェイズの内のどちらか一つの元で、異なる交換をモードとして提供する。

フェイズ 1 は、二つの ISAKMP ピアが、安全で認証済みの通信するためのチャネルを確立するためのものである。これを ISAKMP SA と呼ぶ。フェイズ 1 交換を確立ものには、「Main モード」 と 「Aggressive モード」 がある。「Main モード」 と 「Aggressive モード」 はフェイズ 1 以外で使用してはならない

フェイズ 2 は、鍵素材やパラメータのネゴシエーションを必要とする、IPsec や他のサービスのためのネゴシエーションをするものである。「Quick モード」 がフェイズ 2 交換を確立する。 「Quick モード」 はフェイズ 2 以外で使用してはならない

「New Group モード」 は、実際フェイズ 1 でもフェイズ 2 でもない。これはフェイズ 1 の次にくるが、先のネゴシエーションで使用されるかもしれない新しいグループを確立するために使用される。「New Group モード」 はフェイズ 1 の後以外で使用してはならない

ISAKMP SA は双方向である。それはつまり、一旦確立されれば、両端のどちらからでも、Quick モード、Informational、New Group モード交換を開始できる。基礎となる ISAKMP ドキュメントによれば、ISAKMP SA は、イニシエータのクッキーとそれに続くレスポンダのクッキーによって区別される。フェイズ 1 交換における両端の役割は、どのクッキーがイニシエータのものかを記録することである。フェイズ 1 交換で確立されたクッキーの並びが、Quick モード、Informational、New Gruop 交換の向きに関係なく、ISAKMP SA を区別する。別の言い方をすれば、ISAKMP SA の向きわ切り替えても、クッキーの順序を変えてはならないということである。

ISAKMP フェイズを使用する上で、必要なら非常に高速な鍵交換を実装することができる。 一つのフェイズ 1 ネゴシエーションから、一つ以上のフェイズ 2 ネゴシエーションを行なっても構わない。加えて、一つのフェイズ 2 ネゴシエーションで複数の SA を要求することも出来る。実装でこれらの最適化を行なう事で、SA 当たりのラウンドトリップが 1 未満に、同様に SA 当たりの DH 比率も 1 未満にすることができる。フェイズ 1 の 「Main モード」 は、ID 保護を提供する。ID 保護が必要でない時は、「Aggressive モード」 を使用することで、更なるラウンドトリップの削減が可能となる。続く文章に、これらの最適化行なう上での開発者へのヒントがある。Aggressive モード交換の認証に公開鍵暗号を使用すると、ID 保護も提供されることに注意すること。

本プロトコルでは、自身の DOI を定義しない。フェイズ 1 で確立した ISAKMP SA は、非 ISAKMP サービス (IETF IPSec DOI [Pip97] 等) の DOI と Situation を使用するかもしれないこのような場合は、実装として、同一 DOI のサービスに対しての SA の確立に、ISAKMP SA の使用を制限することを選択しても構わない。反対に、DOI と situation (これらのフィールドについての解説は [MSST98] 参照) の両者の値を 0 として、ISAKMP SA を確立しても構わない。この場合、この ISAKMP SA を使用して、どの定義済みの DOI に対してセキュリティサービスを確立するかは自由である。フェイズ 1 SA の確立に際して DOI が 0 の場合、フェイス 1 で使用される ID ペイロードの文法は、[MSST98] で定義されているものであり、ID の文法と意味をさらに拡張する [Pip97] などの DOI によるものではない。

以下の属性は、IKE で使用され、ISAKMP SA の一部分としてネゴシエーションされる。(これらの属性は ISAKMP SA にだけ関係し、ISAKMP が他のサービスとの関連でネゴシエーションを行なう他の SA とは無関係である。)

これらの属性全ては、必須項目であり、ネゴシエーションされねばならない。それに加えて、オプションで、擬似乱数関数 (pseudo-random function:prf) についてのネゴシエーションを行なう事も出来る。(ネゴシエーション可能な擬似乱数関数は、本ドキュメント中では定義されていない。交渉に参加しているものの間で、prf についてのネゴシエーションのために、プライベート使用属性値を使うことができる)。「prf」 についてネゴシエーションしなかった場合は、擬似乱数関数として、HMAC ([KBC96] 参照) 版のハッシュアルゴリズムがネゴシエーションされたものとして使用される。他の必須でない属性については、追補Aで解説する。選択されたハッシュアルゴリズムは、ネイティブと HMAC モードの両者をサポートしなければならない

Diffie-Hellman グループは、定義済みのグループ記述 (セクション 6) を使用して指定するか、グループの全ての属性値を定義するか (セクション 5.6) しなければならない。(group タイプや素数など ― 追補A 参照) グループ属性は、(予約済みグループ記述や New Group モード交換終了後に確立されるプライベート使用記述のいづれかの) 既に定義されているグループと関連してはならない

IKE 実装は、以下の属性値をサポートしなければならない。

さらに、IKE の実装は、暗号の 3DES、ハッシュの Tiger ( [TIGER] )、Digital Signature Standard (デジタルサイン標準)、RSA [RSA] サインと RSA 公開鍵暗号を使用する認証、MODP グループ番号 2 をサポートすべきである。IKE の実装は、追補A に定義されている、 追加の暗号アルゴリズムのどれをサポートしても構わないし、ECP と EC2N グループをサポートしても構わない

IETF IPsec DOI [Pip97] を実装する際には、ここで解説した IKE モードを実装しなければならない他の DOI でも、ここで解説したモードを使用することがありえる

5 交換 English

認証された鍵交換を確立するために使用される、二つの基本的な手法 : Main モードとAggressive モードがある。ともに、短時間だけ有効な Diffie-Hellman 交換から、認証された鍵素材を生成する。Main モードは実装しなければならず、Aggressive モードは実装すべきである。さらに、新規の鍵素材を生成し、非 ISAKMP セキュリティサービスをネゴシエーションするためのメカニズムとして、Quick モードは実装されなければならない。また、Diffie-Hellman 交換のプライベートグループを定義するためのメカニズムとして、New Group モードは実装されるべきである。実装は、交換の途中で交換の種類を切り替えてはならない

交換は、標準の ISAKMP ペイロード文法、属性、エンコーディング、タイムアウト、メッセージの再送、を満足しなければならず、例えば、プロポーザルを受け入れられない時や、サイン確認や復号に失敗した時など、通知レスポンスが送られる、Informational メッセージも満足しなければならない

フェイズ 1 交換の間、SA ペイロードは、他の全てのペイロードの前になければならない。特に注記しない限り、メッセージ中の ISAKMP ペイロードの順番には特別な指定はない。

フェイズ 1、フェイズ 2 交換に係わらず、KE ペイロードによって渡される Diffie-Hellman 公開値は、ネゴシエーション済みの Diffie-Hellman グループの長さで なければならない。必要な場合は、値 0 を指定する。

nonce ペイロードの長さは 8 バイト以上 256 バイト以下でなければならない

Main モードは、ISAKMP ID 保護交換を具体化したものである。最初の二つのメッセージでポリシーをネゴシエーションし、次の二つのメッセージで Diffie-Hellman 公開値と交換に必要な付随するデータ (例、nonce) を交換する。最後の二つのメッセージで Diffie-Hellman 交換の認証を行なう。認証方法は最初の ISAKMP 交換の一部でネゴシエーションされ、その後のペイロードの組み立てに影響するが、それは目的ではない。Main モードの XCHG は、ISAKMP ID 保護である。

同様に、Aggressive モードは、ISAKMP Aggrtessive 交換の具体化である。最初の二つのメッセージでポリシーをネゴシエーションし、Diffie-Hellman 交換値と交換に必要な付随するデータ、ID を交換する。続けて二番目のメッセージでレスポンダを認証する。三番目のメッセージは、イニシエータを認証し、交換への参加の保証を提供する。Aggressive モードの XCHG は、ISAKMP Aggressive である。最後のメッセージは、必要なら、この交換のネゴシエーションが完了するまで、延長することを許している ISAKMP SA による保護を受けない状態で送られることがある。Aggressive モードの図解を見れば、最後のペイロードでは、そうである必要が無いことははっきりわかる。

Aggressive モードでの SA ネゴシエーションには制限がある。メッセージ構築には、Diffie-Hellman 交換が行われるグループが必須であるが、それについてはネゴシエーション出来ないためである。さらに、異なる認証方式では、属性ネゴシエーションについての制約が厳しくなることもありうる。例えば、公開鍵暗号を用いた認証をネゴシエーションすることは出来ず、認証に使われる公開鍵暗号の改定された方式を使う際に、暗号とハッシュについてネゴシエーションすることが出来ない。IKE の豊富な属性ネゴシエーション機能が必要とされる状況では、Main モードが必要となるだろう。

ISAKMP のなかには、Quick モードと New Group モードの類似したものは存在しない。Quickモードと New Group モードの XCHG 値は 追補A で定義されている。

Main モード、Aggresive モード、Quick モードでは、 SA についてのネゴシエーションを行なう。 SA についてのオファーは、 SA ペイロード中に含まれる Proposal ペイロード中に入った Transform ペイロードという形式をとる。フェイズ 1 交換 (MainモードおよびAggressiveモード) で複数のオファーが行なわれる場合、一個の SA ペイロード中の一個の Proposal ペイロードに 複数の Transform ペイロードが入る形式を取らなければならない。他の形式を取るなら、一個の SA ペイロード中に複数の Proposal ペイロードがあってはならず、同時に複数の SA ペイロードが存在する事も許されない。本ドキュメントでは、フェイズ 2 のオファーにおけるその様な行動を禁止していない。

イニシエータがレスポンダへ送るオファーの数に制限はないが、仕様を満たす実装では、性能上の問題を考慮して、オファーの数を制限してもかまわない

SA ネゴシエーションの間、イニシエータはレスポンダに対し、これから確立する SA についてオファーする。レスポンダは、いかなるオファーについても、例外の属性エンコーディングを除いて、その属性を変更してはならない (追補A参照)。 交換のイニシエータが、オファーの属性値が変更されたり、追加/削除されたりしていることに気付いた場合は、そのレスポンスは拒絶しなければならない

Main モードと Aggressive モードの両方で、4 つの異なる認証方式 ― デジタル署名、公開鍵暗号を用いる二つの形式、既知共有鍵が許されている。SKEYID の値が各認証方式毎に独立に計算されている。

デジタル署名 SKEYID = prf  (Ni_b | Nr_b, g^xy)
公開鍵暗号 SKEYID = prf  (hash (Ni_b | Nr_b), CKY-I | CKY-R)
既知共有鍵 SKEYID = prf  (既知共有鍵, Ni_b | Nr_b)

Main モードおよび Aggressive モードの結果は、認証済み鍵素材の三つのグループであり、

SKEYID_d = prf (SKEYID, g^xy | CKY-I | CKY-R | 0)
SKEYID_a = prf (SKEYID, SKEYID_d | g^xy | CKY-I | CKY-R | 1)
SKEYID_e = prf (SKEYID, SKEYID_a | g^xy | CKY-I | CKY-R | 2)


その後の通信の保護に関するポリシーについて同意する。上記の 0、1、2 の値は 1 オクテットで表現される。暗号化に使われる鍵は、アルゴリズム毎の方法で、SKEYID_e から生成される (追補B 参照)。

交換で、プロトコルのイニシエータが生成する HASH_I と、レスポンダが生成する HASH_R を認証するには、

HASH_I = prf (SKEYID, g^xi | g^xr | CKY-I | CKY-R | SAi_b | IDii_b )
HASH_R = prf (SKEYID, g^xr | g^xi | CKY-R | CKY-I | SAi_b | IDir_b )

デジタル署名で認証するには、HASH_I と HASH_R に署名し、それを確認する。公開鍵および既知共有鍵によって認証するには、HASH_I と HASH_R が交換を直接認証する。ID ペイロード全体 (ID タイプ、ポート、プロトコル以外のヘッダを除く) からハッシュ値 HASH_I と HASH_R が生成される。

上で述べたように、ネゴシエーションされた認証方式は、フェイズ 1 のモードのメッセージの内容と使用法に影響するが、それを目的としているわけではない。認証のために公開鍵を使用する場合、署名を使用しても、(アルゴリズムがサポートしている場合) 公開鍵暗号を使用しても、フェイズ 1 交換は成立する。以下は、異なる認証オプションを用いてのフェイズ 1 交換である。

5.1 署名による IKE フェイズ 1 認証 English

署名を用いた場合、二番目のラウンドトリップで交換される補助情報は nonce となり、お互いが入手可能なハッシュ値によって交換は認証される。署名認証による Main モードは以下のようになる。

Initiator
---------
Responder
---------
HDR, SA
HDR, SA
HDR, KE, Ni
HDR, KE, Nr
HDR*, IDii, [CERT,] SIG_I
HDR*, IDir, [CERT,] SIG_R

ISAKMP に関連する、署名による Aggressive モードは以下の通りである。

Initiator
---------
Responder
---------
HDR, SA, KE, Ni, IDii
HDR, SA, KE, Nr, IDir, [CERT,] SIG_R
HDR, [CERT,] SIG_I

両モードにおいて、署名されたデータ、SIG_I および SIG_R は、ネゴシエーションされたデジタル署名アルゴリズムを、HASH_I および HASH_R それぞれに適用した結果である。

一般に、ネゴシエーション済みの prf を上記のように用いた HASH_I や HASH_R、もしくは (prf をネゴシエーションしなかった場合) HMAC 版のネゴシエーション済みのハッシュ関数から署名が作られる。しかしながら、署名アルゴリズムが特定のハッシュアルゴリズムに結びついている場合は (例、DSS は SHA の 160 ビット出力との組み合わせでしか定義されていない)、この限りではない。その様な場合、署名の方式に関連するハッシュアルゴリズムの HMAC 版を使用する場合を 除いて、署名は上記の HASH_I と HASH_R から作られる。ネゴシエーションされた prf とハッシュ関数は、その他の規定済みの擬似乱数関数すべてで使用されつづける。

使用されているハッシュアルゴリズムは既知であるから、それの OID を署名の中にエンコードする必要はない。付け加えると、本ドキュメント中で使われている PKCS#1 の RSA 署名などの OID に対するバインディングは存在しない。それゆえ、RAS 署名は、(ハッシュアルゴリズムの OID を含む) PKCS#1 形式の署名ではなく、PKCS#1 形式のプライベートキー暗号としてエンコードされなければならない。DSS 署名は、r に s が続くようにエンコードしなければならない。

オプションとして、一個以上の証明書ペイロードを渡してもよい

5.2 公開鍵暗号によるフェイズ1認証 English

交換を認証するために公開鍵暗号を用いる場合、交換される補助情報は暗号化されたnonces となる。両端の (他端が nonce の復号ができるように) ハッシュを再構成する能力によって交換が認証される。

公開鍵暗号を使用するためには、イニシエータはレスポンダの公開鍵を持っている必要がある。レスポンダが複数の公開鍵を持っている状況では、イニシエータが付随情報を暗号化するために使用する、証明書のハッシュを三番目のメッセージの一部として渡す。これによって、レスポンダは、暗号化されたペイロードを復号し、ID 保護を保つために、どのプライベート鍵を使用するべきかを決定できる。

nonce に加え、両端の ID (IDii と IDir) も同様に他方の公開鍵によって暗号化される。認証手段が公開鍵暗号の場合、nonce と ID ペイロードは、他方の公開鍵で暗号化されなければならない。ペイロードのボディだけが暗号化され、ヘッダ部分は元のままである。

認証に暗号を用いる場合、Main モードはいかように定義されている。

Initiator Responder
HDR, SA
HDR, SA
HDR, KE, [HASH(1),] <IDii_b>PubKey_r,<Ni_b>PubKey_r
HDR, KE,<IDir_b>PubKey_i, <Nr_b>PubKey_i
HDR*, HASH_I, [CERT,] SIG_I
HDR*, HASH_R

Aggressive モードでの暗号化認証は以下の通り。

Initiator Responder
HDR, SA, [HASH(1),] <IDii_b>PubKey_r,<Ni_b>PubKey_r
HDR, SA,<IDir_b>PubKey_i, <Nr_b>PubKey_i, HASH_R
HDR, HASH_I, [CERT,] SIG_I

HASH (1) は、イニシエータが nonce と ID を暗号化するために使用する、証明書の (ネゴシエーション済みのハッシュ関数を使用した) ハッシュ値である。

RSA 暗号は PKCS#1 形式でなければならない。ID と nonce ペイロードのボディ部分だけが暗号化されるが、暗号化されたデータの前には正しい ISAKMP ヘッダがなければならない。ペイロード長は、暗号化されたペイロードとヘッダを合わせたものの長さとなる。PKCS#1 エンコーディングでは、復号化した結果の平分ペイロードの長さをあらかじめ知ることが出来る。

認証に暗号を使用することで、妥当性否認可能交換となる。両端が交換の両端が完全に再構成された後、(デジタル署名を使用しても) 一度でも通信が有ったかどうかを証明すする手だてはない。それに加えて、(通信への) 攻撃者は、Diffie-Hellman 交換を破るだけでは済まず、RSA 暗号も破る必要があるため、秘密性の安全性も高まる。この交換方式は [SKEME] で推奨されている。

他の認証方式とは異なり、公開鍵院号による認証を使うことで、Aggressive モードであっても ID 保護を行なうことが出来る点に注意すること。

5.3 改良公開鍵暗号によるフェイズ 1 認証 English

公開鍵暗号による認証は、署名によるものに比べてずっと優れている (先のセクション 5.2 を参照)。残念ながら、これには公開鍵処理 4 回分 ― 公開鍵暗号化 2 回と秘密鍵復号化 2 回ののコストがかかる。ここで解説する認証モードは、公開鍵暗号による認証の優位点は残したまま、公開鍵処理の回数を半分で済ますものである。

本モードでは、nonce は公開鍵で暗号化されつづけるが、ID (および送られる場合は証明書) は、(SA ペイロードによる) ネゴシエーション結果の対称暗号アルゴリズムと nonce から生成される鍵を使って暗号化される。この解決法によって、両端でのコストのかかる公開鍵処理が 2 回減り、それ結果加わる複雑性と状態は最小である。さらに、鍵交換ペイロードも生成された同じ鍵によって暗号化される。これによって、Diffie-Hellman 交換に対する暗号解析への保護が追加される。

認証の公開鍵暗号手法を使うことによって、(セクション 5.2 参照)、 レスポンダが利用可能な公開鍵を含む複数の証明書を持つ場合、証明書を確認するために HASH ペイロードが送られることがある (例、証明書の制限やアルゴリズムの制限のために、証明書が署名だけのためのものでない場合)。HASH ペイロードが送られる場合、それは二番目のメッセージ交換の一番目のペイロードで、かつそれには暗号化された nonce が続かなければならない。HASHペイロードか送られない時は、二番目のメッセージ交換の最初のペイロードは、暗号化された nonce で なければならない。さらに、イニシエータは、オプションとして、返答するための公開鍵をレスポンダに渡すために 証明書ペイロードを送ってもよい。

認証に改良型暗号化モードを使用する場合、Main モードは以下のように定義される。

Initiator
---------
Responder
---------
HDR, SA
HDR, SA
HDR, [HASH(1),] <Ni_b>PubKey_r,<KE_b>Ke_i, <IDii_b>Ke_i, [<Cert-I_b>Ke_i]
HDR, <Nr_b>PubKey_i, <Ke_b>Ke_r, <IDir_b>Ke_r
HDR*, HASH_I, [CERT,] SIG_I
HDR*, HASH_R


HASH (1) は、セクション 5.2 のものと同じである。Ke_i と Ke_r は、SA ペイロード交換でネゴシエーションされた対称暗号アルゴリズムの鍵である。(公開鍵と対称処理の両方において) ペイロードのボディだけが暗号化され、ペイロードヘッダはそのままの状態に残される。含まれるペイロードの長さは、暗号化の際に使用される。

対称暗号鍵は、複合化された nonce から以下のように派生される。最初に、Ne_i と Ne_r が計算される。

Ne_i = prf (Ni_b, CKY-I)
Ne_r = prf (Nr_b, CKY-R)

鍵Ke_i と Ke_r は、ネゴシエーションされた暗号アルゴリズムで使用する対称鍵を生成するために、Ne_i と Ne_r それぞれから、追補B で解説される方法にしたがって作られる。ネゴシエーションされた prf の出力の長さが、暗号が要求する鍵の長さ以上の場合、Ke_i と Ke_r は、Ne_i と Ne_r それぞれの上位ビットから作られる。Ke_i と Ke_r の要求される長さが prf の出力を超えている場合は、prf の結果を再び prf に与え、その結果を必要なビット数に達するまで、順に結合する。例えば、ネゴシエーションされた暗号アルゴリズムが 320 ビット長の鍵を要求し、prf の出力が 128 ビット長しかない場合、Ke_i は次の方法で得られる K の最上位 320 ビットとなる。

K = K1 | K2 | K3
かつ
K1 = prf (Ne_i, 0)
K2 = prf (Ne_i, K1)
K3 = prf (Ne_i, K2)

簡潔にするために、Ke_i の生成についてだけ示した。Ke_r についても同じである。K1 の計算での値 0 の長さは 1 オクテットである。Ne_i、Ne_r、Ke_i、Ke_r はすべてその場限りのもので、使用後廃棄しなければならない

オプションの HASH ペイロードと必須の nonce ペイロードの位置についての要求事項を保持すれば、それ以外にペイロードついて要求されることはない。暗号化された nonce に続くすべてのペイロードは、― いかなる順序であっても ― 方向に応じて Ke_i または Ke_r で暗号化されなければならない

対称暗号化において CBC モードが使用される場合、 初期ベクタの値は以下のように設定する。nonce に続く最初のペイロードの暗号化では、IV は 0 に設定される。その場限りの対称暗号鍵 Ke_i で暗号化される、続くペイロードに対しての IV は、直前のペイロードの最後の暗号化済みブロックになる。暗号済みペイロードは、一番近いブロックの大きさまでパッディングされる。すべてのパッディングは (バイト単位で)、最後のものを除いて、0 x 00 である。最後のバイトには、それ自身を除いて使用したパディングのバイト数が入る。つまり、常にパディングがあることになることに注意すること。

5.4 既知共有鍵を使用するフェイズ 1 認証 English

なんらかの方法で配布された鍵を使用して、交換を認証してもよい。具体的なこの鍵のやり取りは、本ドキュメントの範囲外である。

既知共有鍵認証を行なう場合の Main モードは以下のようになる。

Initiator
---------
Responder
---------
HDR, SA
HDR, SA
HDR, KE, Ni
HDR, KE, Nr
HDR*, IDii, HASH_I
HDR*, IDir, HASH_R

既知共有鍵を用いた Aggressive モードは次の通りである。

Initiator
---------
Responder
---------
HDR, SA, KE, Ni, IDii
HDR, SA, KE, Nr, IDir, HASH_R
HDR*, HASH_I

Mail モードで既知共有鍵認証を行なう場合、HASH_I を IDir を処理する前に計算しなくてはならないので、どの鍵を使用するかを判断する手だては、相手の IP アドレスしかない。Aggressive モードでは、使用する既知共有情報を決定する手だてとして、より広い範囲のものが用意されている。付け加えると、Aggressive モードでは、両端で、複数の相異なる既知共有鍵を準備しておき、ある交換の際に、これ用のものを一つ選び出すことが可能である。

5.5 フェイズ 2 - Quick モード English

Quick モードによって、交換そのものが完了するわけではないが (それはフェイズ 1 交換の役目である)、鍵素材を生成し、非 ISAKMP SA での共有ポリシーをネゴシエーションするために、SA ネゴシエーション処理の一部 (フェイズ 2) で使用される。Quick モードで交換される情報は、ISAKMP SA によって保護されなければならない ― つまり、ISAKMP ヘッダを除くすべてのペイロードは暗号化されなければならない。Quick モードでは、HASH ペイロードは、ISAKMP ヘッダの直後に、SA ペイロードは HASH ペイロードの直後になければならない。HASH は、メッセージを認証し、同時に生存確認も行なう。

ISAKMP ヘッダ中のメッセージ ID によって、ISAKMP ヘッダ中のクッキーで確認されるあるISAKMP SA に対して処理中の Quick モードを確定する。Quick モードの各インスタンスごとに、ユニークな初期化ベクタ (追補 B 参照) が使用されるので、一つの ISAKMP SA 上で、同時に複数の Quick モードをいつでも開始できる。

Quick モードは、基本的に SA ネゴシエーションであり、リプレイ攻撃からの保護を提供するための nonce の交換である。nonce は新しい鍵素材の生成と、でたらめの SA を生成してのリプレイ攻撃を防ぐために使用される。Quick モードにさらなる Diffie-Hellman 交換と指数関数を加えるために、オプションの鍵交換ペイロードを使用できる。Quick モードで鍵交換ペイロードはオプションであるが、サポートしなければならない

(KE ペイロードが無い) 基本 Quick モードは、フェイズ 1 の指数関数から生成された鍵素材を新しくする。これによって PFS は提供されない。オプションの KE ペイロードを使用すると、追加の指数関数が実行され、鍵素材のための PFS が提供される。

Quick モードでネゴシエーションされる SA の ID として、ISAKMP の相手の IP アドレスが仮定される。Quick モードでクライアント ID を指定した場合を除いて、プロトコルやポート番号に対しての制約は許されない。ISAKMP が、一方のクライアント・ネゴシエータである場合、両端の ID は、IDci と IDcr として渡さなくてはならない。指定された ID に対しての提案を受けてるかどうかは、ローカルポリシーが指示する。Quick モード・レスポンダが、(ポリシーや他の理由のために) クライアント ID を受け取らない場合、INVALID-ID-INFORMATION (18) という種類の Notify メッセージが入った Notify ペイロードを送らなければならない

クライアント ID は、確認し両端の間に複数のトンネルがある場合に通るべきトンネルに流すかを指示するために使われるだけでなく、一個の共有された SA に異なる粒度を持つことを許すためにも使われる。

Quick モードの間に行なわれたすべての提案は、論理的に関係しており、食い違いが有ってはならない。例を挙げれば、KE ペイロードを送る場合、Diffie-Hellman グループについて記述する属性 (セクション 6.1 と [Pip97] を参照) に、ネゴシエーション中のすべての SA のすべての提案のすべての変換を含まなければならない。同様に、クライアント ID を使用する場合、 ネゴシエーション中のすべての SA にたいして適用しなければならない

Quick モードの定義は以下の通り。

Initiator
---------
Responder
---------
HDR*, HASH (1), SA, Ni, [, KE] [, IDci, IDcr]
HDR*, HASH (2), SA, Nr, [, KE] [, IDci, IDcr]
HDR*, HASH (3)

これにおいて:
HASH (1) は、暗号化のために付け加えられたパディング以外の、すべてのペイロードヘッダを含むハッシュに続く、メッセージ全体をにつながった ISAKMP ヘッダにあるメッセージ ID に対して prf を実行したものである。HASH (2) は、Ni からペイロードヘッダを除いた、イニシエータの nonce が、M-ID の後かつメッセージ全体の前に付け加えられることを除いて、HASH (1) と同じ物である。HASH (2) で nonce が付け加えられるのは、生存確認のためである。生存確認のための HASH (3) は、1 オクテットの値 0、メッセージ ID、ペイロードヘッダを除いた、イニシエータとレスポンダのものを続けた二つの nonce、これら三つのものに prf を実行したものである。別の言い方をすると、先の交換でのハッシュは次の通り。

HASH(1) = prf (SKEYID_a, M-ID | SA | Ni [ | KE ] [ | IDci | IDcr ])
HASH(2) = prf (SKEYID_a, M-ID | Ni_b | SA | Nr [ | KE ] [ | IDci | IDcr ])
HASH(3) = prf (SKEYID_a, 0 | M-ID | Ni_b | Nr_b)

HASH、SA とオプションの ID ペイロードの例外を除いて、Quick モードでは、ペイロードの順序についての制限はない。メッセージ中のペイロードの順序が上のものと異なったり、通知などのオプションのペイロードがメッセージに連なっている場合、HASH (1) と HASH (2) は上の例とは異なることになる。

PFS が不要な場合、KE ペイロードは交換されず、新しい鍵が次の定義から作成される。

KEYMAT = prf (SKEYID_d, protocol | protocol | SPI | Ni_b | Nr_b)

PFS が望ましく、KE ペイロードが交換された場合、新しい鍵は次のようになる。

KEYMAT = prf (SKEYID_d, g(qm)^xy | protocol | SPI | Ni_b | Nr_b)

g(qm)^xy は、Quick モードの短時間有効な Diffie-Hellman 交換から得た、共有鍵である。

どちらの場合でも、「protocol」 と 「SPI」 は、ネゴシエーション済みの変換を含む ISAKMP の Proposal ペイロードから得る。

1つの SA ネゴシエーションから、入りと出、1つの SA が得られる。(1つはイニシエータが、もう 1つはレスポンダが選択するため) それぞれの SA の SPI は異なり、方向によって鍵が異なることを保証する。SA の接続先によって選ばれた SPI よって、その SA のための KEYMAT を生成する。

要求される鍵素材の量が、prf によって得られるものよりも大きい場合、prf の出力を再びその入力とし、必要な大きさになるまでその結果をつなぎあわせることで、KEYMAT を拡大する。他の言い方をすると、

KEYMAT = K1 | K2 | &3 | …
ここで、
K1 = prf (SKEYID_d, [ g(qm)^xy | ] protocol | SPI | Ni_b | Nr_b)
K2 = prf (SKEYID_d, K1 | [ g(qm)^xy | ] protocol | SPI | Ni_b | Nr_b)
K3 = prf (SKEYID_d, K2 | [ g(qm)^xy | ] protocol | SPI | Ni_b | Nr_b)
等々

(PFS があるにしろないにしろ、直接生成されたものであっても、つなぎあわせたものであっても) この鍵素材は、ネゴシエーションした SA においてのみ使わなければならない。鍵素材からどのようにかぎを生成するかはサービスの責任である。

Quick モードにおける短時間有効な Diffie-Hellman 交換において、指数関数 (g (qm)^xy) は回復不可能なように現在の状態から取り除かれ、(フェイズ 1 ネゴシエーションから得られる) SKEYID_e と SKEYID_a によって ISAKMP SA を保護し認証しつづけ、SKEYID_d から鍵を生成しつづける。

Quick モードを使用することで、以下のようにして、複数の SA と鍵を一度の交換でネゴシエーションで切る。

Initiator
---------
Responder
---------
HDR*, HASH (1), SA0, SA1, Ni, [, KE] [, IDci, IDcr]
HDR*, HASH (2), SA0, SA1, Nr, [, KE] [, IDci, IDcr]
HDR*, HASH (3)

1つの SA の場合とまったく同じ方法で鍵素材を生成する。(2つの SA ペイロードをネゴシエーションする) この場合、各 SA の両方向に 4つの SA が得られる。

5.6 New Group モード English

ISAKMP SA が確立されるよりも前に、New Group モードを使用してはならない。新しいグループについての記述は、フェイズ 1 ネゴシエーション以外の後にあってはならない (であるが、フェイズ 2 交換ではない)。

Initiator
---------
Responder
---------
HDR*, HASH (1), SA
HDR*, HASH (2), SA

HASH (1) は SKEYID_a を鍵とし、ISAKMP ヘッダに SA 全体 (ボディとヘッダ) をつなげたもののメッセージ ID をデータとした、prf の出力である。HASH (2) は、SKEYI_a を鍵とし、SAKMP ヘッダにリプライをつなげたものをデータした、prf の出力である。上記の交換におけるハッシュを別の言い方をすると、

HASH (1) = prf (SKEYID_a, M-ID | SA)
HASH (2) = prf (SKEYID_a, M-ID | SA)

プロポーザルによってグループの特性を指定する (追補 A 参照)。 プライベートグループについてのグループ記述は、2^15 以上でなければならない。グループを受け入れられない場合、レスポンダは ATTRIBUTE-NOT-SUPPORTED (13) のメッセージ種類の Notify ペイロードで返答しなければならない

ISAKMP の実装は、確立した SA の有効期限を限るために、プライベートグループを要求してもよい

Main モードを使う SA プロポーザルで、 直接グループについてネゴシエーションしてもよい。 このためには、 MODP グループに対しては、タイプ、素数、ジェネレータ、EC2N グループには、タイプ、Irreducible Polynomial (既約多項式)、Group Generator 1、Group Generator 2、Group Curve A、Group Curve B、Group Order の要素を SA 属性として渡す (追補 A 参照)。 逆に、グループの特性は、New Group モードを使って隠すことが出来、フェイズ 1 ネゴシエーションにおいては、グループ ID だけが見えるようにすることが出来る。

5.7 ISAKMP Informational 交換 English

可能な場合には、このプロトコルによって ISAKMP Informational 交換は保護される。このプロトコルを使って ISAKMP SA が確立してしまえば (SKEYID_e と SKEYID_a が生成されれば)、 ISAKMP Informational 交換は以下のようになる。

Initiator
---------
Responder
---------
HDR*, HASH (1), N/D

N/D は、ISAKMP Notify ペイロードもしくは ISAKMP Delete ペイロードであり、HASH (1) は、SKEYID_a を鍵とし、この交換にユニークな M-ID と (Nofity もしくは Delete) 情報ペイロード全体をつなげたものをデータとした、prf の出力である。別の言い方をすると、上記の交換のハッシュは次のようになる。

HASH (1) = prf (SKEYID_a, M-ID | N/D)

先に注意したように、prf 計算で使用される ISAKMMP ヘッダ中のメッセージ ID は、交換ごとにユニークであり、この Informational 交換を行なわせるフェイズ 2 交換のどれとも同じであってはならない。このメッセージを暗号化するための SKEYID_e で使用される初期配列の生成については、追補 B で説明している。

ISAKMP SA は、Informational 交換の時点ではまだ確立されておらず、対応する HASH ペイロードなしで平分のまま行なわれる。

6 Oakley グループ English

IKE では、Diffie-Hellman 交換をどのグループで行なうかをネゴシエーションする。値 1 から 4 をとる、4つのグループを以下に定義する。これらのグループは、Oakley プロトコルを元にしたもので、それゆえ「Oakley グループ」と呼ばれている。「グループ」 の属性クラスについては 追補 A で定義されている。 2^15 を超えるすべての値はプライベートグループ ID で使用される。デフォルトの Oakley グループの強度についての説明は、続くセキュリティについての考察のセクションを 参照して欲しい。

これらのグループは、アリゾナ大学の Richard Schroeppel によって作成された。これらのグループの権利については [Orm96] を参照。

6.1 第一 Oakley デフォルト・グループ English 

Oakley の実装においては、以下の素数とジェネレータを持つ MODP グループをサポートしなければならない。このグループには ID として 1 が割り当てられている。

素数は、2^768 - 2^704-1 + 2^64 * { [2^638 pi] + 149686 } であり、それを 16 進数で表記すると、

FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
E485B576 625E7EC6 F44C42E9 A63A3620 FFFFFFFF FFFFFFFF

ジェネレータは 2 (10 進数)である。

6.2 第二 Oakley グループ English

IKE の実装においては、以下の素数とジェネレータを持つ MODP グループをサポートするべきである。このグループには ID として 2 が割り当てられている。

素数は、2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 } であり、それを 16 進数で表記すると、

FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381
FFFFFFFF FFFFFFFF

ジェネレータは 2 (10 進数)である。

6.3 第三 Oakley グループ English

IKE の実装においては、以下の特性を持つ EC2N グループをサポートするべきである。このグループには ID として 3 が割り当てられている。曲線は Galois Field GF [2^155] に基づいたものであり、そのフィールドの大きさは 155 である。フィールドの既約多項式は

u^155 + u^62 + 1

楕円曲線の式は次の通り。

y^2 + xy = x^3 + ax^2 + b
フィールドの大きさ 155
グループ素数/既約多項式 0x0800000000000000000000004000000000000001
Group Generator 1 0x7b
Group Curve A 0x0
Group Curve B 0x7338f
Group Order 0x0800000000000000000057db5698537193aef944

このグループを使用する場合の KE ペイロード中のデータは、ランダムに選んだ秘密鍵 Ka と、x 座標がジェネレータ 1 と等しく y 座標が定義の式から決まる曲線上の点 P に、グループの加算と倍化の演算「*」を行なうことにより得られる Ka*P の結果の曲線上の点 (x,y) の値 x である。曲線の式はグループタイプと係数 A、B から (事前に) 決定されている。y 座標が取りうる値は二つあるが無、どちらを持ちいても成功する (両端はどちらを使うかを協議する必要はない)。

6.4 第四 Oakley グループ English

IKE の実装においては、以下の特性を持つ EC2N グループをサポートするべきである。このグループには ID として 4 が割り当てられている。曲線は Galois Field GF [2^185] に基づいたものであり、そのフィールドの大きさは 185 である。フィールドの既約多項式は

u^185 + u^69 + 1

楕円曲線の式は次の通り。

y^2 + xy = x^3 + ax^2 + b
フィールドの大きさ 185
グループ素数/既約多項式 0x020000000000000000000000000000200000000000000001
Group Generator 1 0x18
Group Curve A 0x0
Group Curve B 0x1ee9
Group Order 0X01ffffffffffffffffffffffdbf2f889b73e484175f94ebc

このグループを使用する KE ペイロード中のデータは、第3 Oakley グループのものと同じである。

New Group モードを使用することで、他のグループを定義することが出来る。これらのデフォルトのグループは、アリゾナ大学の Richard Schroeppel が作り出した。これらの素数の権利については [Orm96] を参照。

7 完全な IKE 交換のペイロードの組立図 English

本セクションでは、IKE プロトコルの使用法について図示する。

7.1 Main モードを使用するフェイズ 1 English

次は両端の間での最初の交換でのペイロードを図示したものである。 イニシエータは複数のプロポーザルを提案してもよい。 レスポンダは 1つに対してしか返答してはならない。

 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~             ISAKMP Header with XCHG of Main Mode,             ~
~                  and Next Payload of ISA_SA                   ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!       0       !    RESERVED   !        Payload Length         !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!                  Domain of Interpretation                     !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!                          Situation                            !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!       0       !    RESERVED   !        Payload Length         !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!  Proposal #1  ! PROTO_ISAKMP  ! SPI size = 0  | # Transforms  !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!    ISA_TRANS  !    RESERVED   !        Payload Length         !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!  Transform #1 !  KEY_OAKLEY   |          RESERVED2            !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                   prefered SA attributes                      ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!       0       !    RESERVED   !        Payload Length         !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!  Transform #2 !  KEY_OAKLEY   |          RESERVED2            !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                   alternate SA attributes                     ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

レスポンダは同様に、ただし一つの変換プロポーザル (ISAKMP SA 属性) を選び、返さなくてはならない。

二番目の交換は以下のペイロードからなる。

 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~             ISAKMP Header with XCHG of Main Mode,             ~
~                  and Next Payload of ISA_KE                   ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!    ISA_NONCE  !    RESERVED   !        Payload Length         !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~   D-H Public Value  (g^xi from initiator g^xr from responder) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!       0       !    RESERVED   !        Payload Length         !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~         Ni (from initiator) or  Nr (from responder)           ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

この時点で、それ以降の通信を保護しと認証するために、共有鍵、SKEYID_e と SKEYID_a が使用される。SKEYID_e と SKEYID_a は共に認証されていないことに注意すること。

 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~            ISAKMP Header with XCHG of Main Mode,              ~
~     and Next Payload of ISA_ID and the encryption bit set     ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!    ISA_SIG    !    RESERVED   !        Payload Length         !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~        Identification Data of the ISAKMP negotiator           ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!       0       !    RESERVED   !        Payload Length         !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~       signature verified by the public key of the ID above    ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

セクション 5.1 で説明した署名付ハッシュによって、 鍵交換は認証される。 いったん、ISAKMP SA の一部でネゴシエーションされた、認証アルゴリズムを用いて署名が確認されれば、共有鍵、SKEYID_e と SKEYID_a は認証済みとしてよい (簡潔に言うと、証明書ペイロードは交換されない)。

7.2 Quick モードを使用するフェイズ 2 English

Quick モードの最初には、ISAKMP SA ネゴシエーションと共に次のペイロードが交換される。この仮想の交換において、ISAKMP ネゴシエータは、認証を要求した他方に対しての代理者となる。

 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~            ISAKMP Header with XCHG of Quick Mode,             ~
~   Next Payload of ISA_HASH and the encryption bit set         ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!     ISA_SA    !    RESERVED   !        Payload Length         !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                 keyed hash of message                         ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!   ISA_NONCE   !    RESERVED   !         Payload Length        !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!                 Domain Of Interpretation                      !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!                          Situation                            !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!       0       !    RESERVED   !        Payload Length         !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!  Proposal #1  ! PROTO_IPSEC_AH! SPI size = 4  | # Transforms  !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                        SPI (4 octets)                         ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!    ISA_TRANS  !    RESERVED   !        Payload Length         !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!  Transform #1 !     AH_SHA    |          RESERVED2            !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!                       other SA attributes                     !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!       0       !    RESERVED   !        Payload Length         !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!  Transform #2 !     AH_MD5    |          RESERVED2            !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!                       other SA attributes                     !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!    ISA_ID     !    RESERVED   !        Payload Length         !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                            nonce                              ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!    ISA_ID     !    RESERVED   !        Payload Length         !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~              ID of source for which ISAKMP is a client        ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!      0        !    RESERVED   !        Payload Length         !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~           ID of destination for which ISAKMP is a client      ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

ハッシュの内容はすでにセクション 5.5 で述べた。レスポンダは、選択した一つの AH 変換だけを含む、同様のメッセージを返す。それを受け取とると、イニシエータは、ネゴシエーション下 SA と鍵素材に基づく鍵エンジンを提供できる。リプレイ攻撃を調べるため、レスポンダは次のメッセージを受け取るまで待つ。

 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~          ISAKMP Header with XCHG of Quick Mode,               ~
~   Next Payload of ISA_HASH and the encryption bit set         ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!       0       !    RESERVED   !        Payload Length         !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                         hash data                             ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

ハッシュの内容はすでにセクション 5.5 で述べた。

8 PFS の例 English

本プロトコルによって、鍵と ID 両方に対して PFS を提供できる。ISAKMP ネゴシエーションを行なう両端の ID と、可能である場合には、ネゴシエーションしている反対側の ID を PFS で保護することが出来る。

鍵とすべての ID 両方に対して Perfect Forrward Secrecy/PFS を提供するには、ネゴシエーションへの参加者は以下の手順に従うことになる。

非 ISAKMP SA で使用される鍵は一個の短時間有効な Diffie-Hellman 交換から生成されるので、PFS は保たれる。

非 ISAKMP SA の鍵だけにのみ PFS を提供するためであれば、両端の間に ISAKMP SA がすでにある場合はフェイズ 1 交換を行なう必要はない。オプションの KE ペイロードを渡し、追加の Diffie-Hellman 交換を行なう、Quick モードを 1回必要とするだけである。セクション 5.5 で説明したように、この Quick モードから派生された状態は、ISAKMP SA から取り除かなければならない。

9 実装上のヒント English

一回の ISAKMP フェイズ 1 ネゴシエーションから、それに続くフェイズ 2 ネゴシエーションを生成することはとても簡単である。フェイズ 1 の状態がキャッシュされ、PFS が不要ならば、フェイズ 2 は指数計算なしで進めることが出来る。一回のフェイズ 1 ネゴシエーションに対して何回フェイズ 2 ネゴシエーションを行なえるかは、それぞれのポリシーの問題である。その決定は、使用しているアルゴリズムの強度と対向のシステムの信用度に依存する。

Quick モードを実行する際に、SA の範囲をネゴシエーションするように実装しても構わない。そうすることで、「再鍵決定」の速度が向上する。ある範囲の SA にたいしての KEYMAT がどう定義されているかは、Quick モードによって定義されている。片端が SA を変更すべき時間に達したと判断した場合、単に決められた SA の範囲の中で次のものを使用する。一回のQuick モードで、複数の SA (ID 属性、異なる SPI) をネゴシエーションすることで、SA の範囲を確立できる。

しばしば有効になる最適化に、SA が必要になった時にすぐ使えるように、あらかじめ確立しておくというものがある。こうすることで、最初のデータ送信の前に鍵管理のために時間を取られることがなくなる。SA を要求されるたびに一個以上の SA を設定しておき、すぐには使われないものをキャッシュする方法で簡単に実装出来る。

また、実装を変更することで、(有効期限切れが近い既存の SA を置き換えるなどのために) SA が必要となる場合、新 SA が必要となる前にそれを確立することもできる。

基礎となる ISAKMP 仕様では、プロトコルをやり取りする片側から他方に状態を知らせても構わない状況が解説されている。その状態には、SA の削除や認証失敗およびペイロード複合失敗などのプロトコルのエラーへの反応がある。これらの Informational 交換にたいしては、どんな環境に於いても、レスポンスを送らないよう強く勧める。そのような状況は、メッセージを理解できないことによる他端への通知が発生したとき、それを受け取った側がその通知を理解できないので、再び相手が理解できない通知を発生し、と繰り返す 「通知戦争」 を引き起こすことになりかねない。

10 セキュリティについての考慮事項 English

本文は、安全で認証された方法による SA のための鍵素材をネゴシエーションし生成するための、Oakley と ISAKMP による SKEME を組み合わせた、ハイブリッド・プロトコルについて説明している。

ネゴシエーションされた暗号アルゴリズムを使用することで、秘匿性が保たれる。デジタル署名アルゴリズム、暗号をサポートする公開鍵アルゴリズム、既知共有鍵などの、ネゴシエーションされた手法を使用することで、認証を行なう。交換における秘匿性と認証は、ISAKMP SA の一部としてネゴシエーションされる属性に於いてのみ有効である。

Quick モードを使用しての鍵変更の繰り返しによって、Diffie-Hellman 共有鍵のエントロピーが減少する。実装者はこの事実に注意し、新たな指数計算を行なわずに繰り返せる Quick モードの回数を制限するべきである。本文では、その制限については触れない。

鍵素材と ID 両方に対しての PFS は、本プロトコルによって達成できる。KE ペイロードで、Diffie-Hellman グループを指定し公開値を渡すことで、ISAKMP 両端は鍵の PFS を確立でき、ID は ISAKMP SA の SKEYID_e によって保護され、それゆえ PFS によっては保護されない。鍵素材と ID 両方に対しての PFS を望む場合は、ISAKMP 端は、(IPsec SA などの) 非ISAKMP SA を ISAKMP SA ごとに一つだけ確立しなければならない。鍵と ID に対する PFS は、非 ISAKMP SA 一個が確立した後、ISAKMP SA を削除 (場合によっては DELETE メッセージを発行する) ことで達成される。この方法では、一つのフェイズ 1 ネゴシエーションは、一つのフェイズ 2 ネゴシエーションとユニークに結びつけられ、フェイズ 1 ネゴシエーションで確立した ISAKMP SA は二度と使用されることはない。

ここで定義したいづれのグループのものであっても、Diffie-Hellman 交換から生成される鍵の強さは、グループの強さ、使用する指数の大きさ、使用する乱数発生器が提供するエントロピーを引き継ぐ。これらの入力のために、定義済みのグループのいづれに置いても鍵の強度を決定することは難しい。デフォルトの Diffie-Hellman グループ (数値 1) を、強力な乱数発生器と 160 ビットより小さくない指数とともに使用すれば、DES に大しては十分な強度がある。グループ 2 から 4 は、より強度なセキュリティを提供する。実装者は、ポリシーの確立とセキュリティ・パラメータのネゴシエーションにおいて、これらの控えめな評価に注意すること。

Diffie-Hellman グループ自身における限界に注意すること。IKE にはより強力なグループの使用を禁ずるものは何もなく、そのグループから得られる強さを弱めるものもない。事実、IKE の拡張可能なフレームワークによって、より多くのグループを定義することが奨励されている。楕円関数グループの使用によって、ずっと小さい数を使ってもさらなる強度を得ることが出来るだろう。

定義されているグループが十分な強度を持たない状況下では、十分な強度を持つ Diffie-Hellman グループを交換するために、New Group モードを使用することができる。提案されているグループの素数性のチェックと、それとは独立に強度を評価することは、実装の責任である。

この交換における Diffie-Hellman 指数は、使用後メモリから消し去られるはずである。とりわけ、これらの指数を、議事乱数発生器の種 (seed) の様な、長時間にわたって使われる秘密情報から生成してはならない。

IKE 交換は、使用中の初期化配列 (Initialization vectors:IV) を管理する。最後のメッセージの最後の暗号文ブロックが次のメッセージの IV となる。交換の同期をずらすことになる再送 (もしくは正しいクッキーをもつ偽のメッセージ) を防ぐために、IKE の実装は、複合化したメッセージが基本的な正当性チェックをパスし、IKE ステートマシンが進む先を実際に決定する ― これは再送ではない、まで 現行の IV を更新してはならない

Main モードの最後の交換 (場合よっては Aggressive モードの最後のメッセージ) は、暗号化されているかどうかに関わらず、厳密に認証されている。暗号文に対する置き換え攻撃があると、ペイロードが壊れることがある。そのような攻撃の結果、必須ペイロードが壊れると認証エラーとして検出されるが、オプションのペイロード (例えば、Main モード交換の最後のメッセージにつながれた Notify ペイロード) が壊れた分については検出不能なことがある。

11 IANA についての考察 English

本文には、IANA によって管理されている「魔法の数」が含まれている。本セクションでは、これらのリストに新たな数を追加割り当てする際において、IANA が使用する分類について説明する。

11.1 属性クラス English

本プロトコルでネゴシエーションされる属性は、そのクラスによって確認される。新しいクラスの割り当てを求めるには、その属性の使用を解説した標準化トラック (standards-track) RFC によらなければならない。

11.2 暗号アルゴリズムクラス English

暗号アルゴリズムクラスの値は、本文で説明した暗号アルゴリズムを定義する。新しい暗号アルゴリズム値の割り当てを求めるには、標準化トラックもしくは情報提供 (Informational) の RFC への参照、またはそれを解説する公開されている暗号についての著作物への参照によらなければならない。

11.3 ハッシュアルゴリズム English

ハッシュアルゴリズムクラスの値は、本文で説明したハッシュアルゴリズムを定義する。新しいハッシュアルゴリズム値の割り当てを求めるには、標準化トラックもしくは情報の RFC への参照、またはそれを解説する公開されている暗号についての著作物への参照によらなければならない。鍵派生と鍵拡張が IKE のハッシュアルゴリズムの HMAC 形式を使用するため、新しいハッシュアルゴリズム値の割り当て要求は、衝突を防ぐために、ハッシュアルゴリズム自体の暗号の権利を考慮しなければならない。

11.4 Group 記述子と Group タイプ English

Group 記述子クラスの値によって、Diffie-Hellman 交換で使われるグループを指定する。Group タイプクラスの値は、グループの種類を定義する。新しいグループの割り当てを求めるには、グループについて解説する標準化トラックもしくは情報の RFC への参照によらなければならない。新しい Group タイプの割り当てを求めるには、グループについて解説する標準化トラックもしくは情報の RFC への参照、またはそれを解説する公開されている暗号もしくは数学についての著作物によらなければならない。

11.5 Life タイプ English

Life タイプの値は、ISAKMP SA が当てはまる有効期間の種類を定義する。新しい Life タイプの割り当てを求めるには、そのタイプの単位とその有効期限切れについての詳細な解説によらなければならない。

12 謝辞 English

本ドキュメントは、Hugo Krawczyk、Douglas Maughan、Hilarie Orman、Mark Schertler、Mark Schneider、Jeff Turner の緊密な協議の結果である。これは彼等が書き上げたプロトコルに依存している。彼等の関心と貢献無しには、本ドキュメントは書かれなかった。

Rob Adams、Cheryl Madson、Derrell Piper、Harry Varnis、Elfed Weaver には、その技術提供、励まし、書いていく上でのさまざまな正当性チェックに対して特別に感謝したい。

過去一年間にわたってこのプロトコルの開発に協力してくれた、IPSec ワーキンググループのメンバーに対しても感謝する。

13 参考文献

[CAST] Adams, C.,
"The CAST-128 Encryption Algorithm", RFC 2144, 1997年 5月.
 
[BLOW] Schneier, B.,
"The Blowfish Encryption Algorithm", Dr. Dobb's Journal, v. 19, n. 4, 1994年 4月.
 
[Bra97] Bradner, S.,
「RFC において要請の程度を示すために用いるキーワード(Key Words for use in RFCs to indicate Requirement Levels)」,
BCP 14, RFC 2119, 1997年 3月.
 
[DES] ANSI X3.106,
"American National Standard for Information Systems-Data Link Encryption", American National Standards Institute, 1983年.
 
[DH] Diffie, W., and Hellman M.,
"New Directions in Cryptography", IEEE Transactions on Information Theory, V. IT-22, n. 1977年 6月 6日.
 
[DSS] NIST,
"Digital Signature Standard", FIPS 186, National Institute of Standards and Technology, U.S. Department of Commerce, 1994年 5月.
 
[IDEA] Lai, X.,
"On the Design and Security of Block Ciphers," ETH Series in Information Processing, v. 1, Konstanz: Hartung-Gorre Verlag, 1992年
 
[KBC96] Krawczyk, H., Bellare, M., and R. Canetti,
「HMAC: メッセージ認証のための鍵付ハッシング(HMAC: Keyed-Hashing for Message Authentication)」, 
RFC 2104
, 1997年 2月.
 
[SKEME] Krawczyk, H., "SKEME: A Versatile Secure Key Exchange Mechanism for Internet", from IEEE Proceedings of the 1996年 Symposium on Network and Distributed Systems Security.
 
[MD5] Rivest, R.,
「MD5 メッセージダイジェストアルゴリズム(The MD5 Message Digest Algorithm)」, 
RFC 1321
, 1992年 4月.
 
[MSST98] Maughhan, D., Schertler, M., Schneider, M., and J. Turner 
「ISAKMP ( Internet SA と 鍵管理プロトコル)(Internet Security Association and Key Management Protocol ISAKMP))」,
  RFC 2408, 1998年 11月.
 
[Orm96] Orman, H.,
"The Oakley Key Determination Protocol", RFC2412, 1998年 11月.
 
[PKCS1] RSA Laboratories,
"PKCS #1: RSA Encryption Standard", 1993年 11月.
 
[Pip98] Piper, D.,
「IPSEC における ISAKMP の解釈(The Internet IP Security Domain Of Interpretation for ISAKMP)」, 
RFC 2407
, 1998年 11月.
 
[RC5] Rivest, R.,
"The RC5 Encryption Algorithm", Dr. Dobb's Journal, v. 20, n. 1995年 1月 1日.
 
[RSA] Rivest, R., Shamir, A., and Adleman, L.,
"A Method for Obtaining Digital Signatures and Public-Key Cryptosystems", Communications of the ACM, v. 21, n. 1978年 2月 2日.
 
[Sch96] Schneier, B.,
"Applied Cryptography, Protocols, Algorithms, and Source Code in C", 2nd edition.
 
[SHA] NIST,
"Secure Hash Standard", FIPS 180-1, National Institue of Standards and Technology, U.S. Department of Commerce, 1994年 5月.
 
[TIGER] Anderson, R., and Biham, E.,
"Fast Software Encryption", Springer LNCS v. 1039, 1996年.

補遺 A English

以下は、DES の弱い、およびやや弱い鍵のリストである。これらの鍵は [Sch96] によったものである。すべての鍵は 16 進数で表現されている。

属性割り当て番号

フェイズ 1 の間にネゴシエーションされる属性は、以下の定義によっている。フェイズ 2 属性は、DOI 仕様書の中で定義される (例えば、IPsec 属性は IPsec DOI の中で定義される)。が、Quick モードに短時間有効な Diffie-Hellman 交換が含まれる時のグループ記述子は例外である。属性タイプは、基本 (B) もしくは可変長 (V) のいづれかである。これらの属性のエンコーディングは、基礎となる ISAKMP 仕様書の中で、タイプ/値 (基本) とタイプ/長さ/値 (可変長) として定義されている。

基本として解説されている属性を、可変長でエンコードしてはならない。可変長属性は、その長さが 2 オクテットに入るなら、基本属性としてエンコードして構わない。この場合、本プロトコルのイニシエータから可変長 (もしくは基本) として送られてきた属性が、基本 (もしくは可変長) としてイニシエータに返されることがありうる

属性クラス

class
-------
value
-------
type
------
Encryption Algorithm 1 B
Hash Algorithm 2 B
Authentication Method 3 B
Group Description 4 B
Group Type 5 B
Group Prime/Irreducible Polynomial 6 V
Group Generator One 7 V
Group Generator Two 8 V
Group Curve A 9 V
Group Curve B 10 V
Life Type 11 B
Life Duration 12 V
PRF 13 B
Key Length 14 B
Field Size 15 B
Group Order 16 V


17 から 16383 までの値は IANA によって予約されている。16384 から 32767 までの値は、お互いにその使用を同意しているグループ内でのプライベートな使用のためのものである。

クラス値

追加の定義された交換 ― XCHG 値

Quick モード 32
New Group モード 33

補遺 B English

この追保では、ISAKMP メッセージを暗号化するさいにだけ使われる、暗号の詳細を解説する。(IPSEC 変換のような) サービスが、鍵素材を発生させるために ISAKMP を利用する場合、すべての暗号アルゴリズム特有の詳細 (鍵、IV 生成、パディング、などなど) は、そのサービスによって定義されなければならない。ISAKMP は、どんな暗号アルゴリズムにも適切な鍵を生成するとは主張していない。ISAKMP は、サービスがそれから適切な鍵を生成しなくてはならない鍵素材を要求された量だけ生成する。鍵の弱さのチェックなどの詳細な点は、サービスの責任である。

ネゴシエーションされた PRF の使用する上で、本ドキュメントで説明した PRF フィードバック機能のために PRF 出力を拡張する必要が場合がある。例えば、(架空の) OORAK-MAC が 24 バイトの鍵を要求するにもかかわらず 8 バイトしか出力しない場合、鍵が使用出来るように成る前に出力を三回にわたって拡張しなくてはならない。続くブロックを発生するために PRF の結果を自分自身にフィードバックすることで、PRF の出力は拡張される。これらのブロックは、必要なバイト数が得られるまで結合される。例えば、ネゴシエーションの結果、DOORAK-MAC を PRF として使用する既知共有鍵認証の場合、

BLOCK1-8 = prf (共有鍵, Ni_b | Nr_b)
BLOCK9-16 = prf (共有鍵, BLOCK1-8 | Ni_b | Nr_b)
BLOCK17-24 = prf (共有鍵, BLOCK9-16 | Ni_b | Nr_b)

となり、

SKEYID = BLOCK1-8 | BLOCK9-16 | BLOCK17-24

SKEYID_d を生成するためには、

BLOCK1-8 = prf (SKEYID, g^ | CKY-I | CKY-R | 0)
BLOCK9-16 = prf (SKEYID, BLOCK1-8 | g^ | CKY-I | CKY-R | 0)
BLOCK17-24 = prf (SKEYID, BLOCK9-16 | g^ | CKY-I | CKY-R | 0)

から

SKEYID_d = BLOCK1-8 | BLOCK9-16 | BLOCK17-24

同様にして続く PRF 生成を行なう。

ISAKMP SA を保護するために使用される暗号鍵は、SKEYID_e からアルゴリズムに特有の方法で生成される。SKEYID_e の長さが、アルゴリズムが要求するすべての必要な鍵素材を提供するには十分でない時、擬似乱数関数 (PRF) の結果を自身にフィードバックし、結果を結合し、上位から必要なビット数を得ることで鍵を生成する。

例えば、(架空の) アルゴリズム AKULA には 320 ビットの鍵が必要で (そして鍵の弱さのチェックはなく)、また SKEYID_e を発生するために使用される prf が 120 ビットの鍵素材しか発生しない場合、AKULA の鍵は、次の Ka の最初の 320 ビットになる。

Ka = K1 | K2 | K3

ここで

K1 = prf (SKEYID_e, 0)
K2 = prf (SKEYID_e, K1)
K3 = prf (SKEYID_e, K2)

ここで prf はネゴシエーションされたものか、(prf がネゴシエーションされなかった場合) ネゴシエーションされたハッシュ関数の HMAC 版であり、0 は 1 オクテットで表現される。prf の各結果は 120 ビットの情報を、結果として 360 ビットを提供する。AKULA はその 360 ビットの最初の 320 ビットを使用することになる。

フェイズ 1 では、CBC モード暗号アルゴリズムの初期化配列のための素材 (IV 素材) は、イニシエータの公開 Diffie-Hellman 値と、レスポンダの公開 Diffie-Hellman 値を結合したものにネゴシエーションの結果のハッシュアルゴリズムを適用した結果から生成したものである。これは最初のメッセージでのみ使用される。各メッセージは、値 0x00 のバイトで一番近いブロックの大きさまでパディングされる。ヘッダ中のメッセージ長は、暗号文の大きさを反映するので、パディングの長さを含まなければならない。続くメッセージは、直前のメッセージを初期化配列として使用しなければならない

フェイズ 2 では、Quick モード交換の最初のメッセージの CBC モード暗号の初期化配列の素材は、フェイズ 1 の最後の CBC 出力ブロックとフェイズ 2 メッセージ ID を結合したものに、ネゴシエーションしたハッシュアルゴリズムを適用したものから生成される。Quick モード交換での続くメッセージの IV は、直前のメッセージの CBC 出力ブロックである。続くメッセージのパディングと IV は、フェイズ 1 のところで述べたのと同様である。

ISAKMP SA が認証された後、すべての Informational 交換は SEYID_e を使用して暗号化される。これらの交換での初期化配列は Quick モードでのものとまったく同じ方法で生成される。つまり、最後のフェイズ 1 CBC 出力ブロックと Informational 交換の ISAKMP ヘッダの ID を結合したもののハッシュから生成される (Informational 交換を要求したメッセージの ID ではない)。

最後のフェイズ 1 CBC 出力ブロック、つまり最後のフェイズ 1 メッセージの暗号化/復号化の結果は、各 Quick モードごとに異なる IV を発生させるために、ISAKMP SA 状態の中に残しておかなければならない。フェイズ 1 後の各交換 (Quick モードと Informational 交換) は、同時に異なる交換が開始された時に同期を失わないようにするために、独立に IV を発生する。

すべての場合において、両方向の暗号/IV コンテクストは一つ存在する。各 Quick モードと Informational 交換は、それ自身のコンテクストを保持することで IV が同期を失うことを防いでいる。

DES-CBC の鍵は、SKEYID_e の弱くもやや弱くもない最初の 8 バイトから生成される。IV は上記のように生成された IV 素材の最初の 8 バイトである。

IDEA-CBC の鍵は、SKEYID_e の最初の 16 バイトから生成される。IV は上記のように生成された IV 素材の最初の 8 バイトである。

Blowfish-CBC の鍵は、必要な場合は前述の擬似関数乱数フィードバック手法を用いて生成される鍵のネゴシエーションされた大きさか、(ネゴシエーションされなかった時は) 最初の 56 バイトである。IV は上記のように生成された IV 素材の最初の 8 バイトである。

RC5-R16-B64-CBC の鍵は、必要な場合は前述の擬似関数乱数フィードバック手法を用いて生成される鍵のネゴシエーションされた大きさか、(ネゴシエーションされなかった時は) 最初の 16 バイトである。IV は上記のように生成された IV 素材の最初の 8 バイトである。ラウンド数は 16 でなければならず、ブロック長は 64 でなければならない

3DES-CBC の鍵は、前述の擬似関数乱数フィードバック手法を用いて生成される鍵の最初の 24 バイトである。3DES-CBC は、3DES-CBC 鍵の、最初、真ん中、最後それぞれの 8 バイトを使用して、暗号-復号-暗号を行なう。IV は上記のように生成された IV 素材の最初の 8 バイトである。

CAST-CBC の鍵は、必要な場合は前述の擬似関数乱数フィードバック手法を用いて生成される鍵のネゴシエーションされた大きさか、(ネゴシエーションされなかった時は) 最初の 16 バイトである。IV は上記のように生成された IV 素材の最初の 8 バイトである。

DES-CBC 以外のアルゴリズムは純粋にオプションである。いくつかのオプションのアルゴリズムは知的所有権の主張に抵触しうる。


著者のアドレス

Dan Harkins
cisco Systems
170 W. Tasman Dr.
San Jose, California, 95134-1706
United States of America

電話: +1 408 526 4000
EMail: dharkins@cisco.com

Dave Carrel
76 Lippard Ave.
San Francisco, CA 94131-2947
United States of America

電話: +1 415 337 8469
EMail: carrel@ipsec.org

 

著者からの注意 English

著者は、このハイブリッドプロトコルの個々に独立した実装を行なうことと、それらの相互運用性の試験を行なうことを推奨する。

 

著作権表記全文

Copyright (C) The Internet Society (1998). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.