ネットワークワーキンググループ
Request for Comments: 2408
分類: スタンダードトラック
D. Maughan
National Security Agency
M. Schertler
Securify, Inc.
M. Schneider
National Security Agency
J. Turner
RABA Technologies, Inc.
1998年11月

English

ISAKMP ( Internet SA と 鍵管理プロトコル)
 Internet Security Association and Key Management Protocol ( ISAKMP )
 

このメモの位置付け

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

著作権表記

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

概要

このメモでは、Security Association (SA) の確立と Internet 環境での暗号化鍵のために必要となるセキュリティの概念を利用するプロトコルを解説している。数多くのセキュリティ機構、それらの機構ごとのいくつかのオプションが存在する、SA とその属性をネゴシエーションし、確立し、変更し削除する SA プロトコルが、Internet の発展のために必要である。Internet コミュニティ全体で使用される公開鍵生成と、それを必要とするプライベートネットワークでの秘密鍵を扱うために、鍵管理プロトコルは頑健でなければならない。ISAKMP (Internet SA and Key Management Protocol) は、通信する相手の認証、SA の生成と管理、鍵生成技法、(DOS やリプレイ攻撃などの) 危険からの防御などのための手順を定義する。これらすべては、Internet 環境での (IP Security Service などのセキュリティプロトコルによる) 安全な通信を確立し運用するために必要である。

目次

図目次

  1. ISAKMP 関係
  2. ISAKMP ヘッダ形式
  3. 共通ペイロードヘッダ
  4. データ属性
  5. SA ペイロード
  6. Proposal ペイロード形式
  7. 変換ペイロード形式
  8. 鍵交換ペイロード形式
  9. ID ペイロード形式
  10. 証明書ペイロード形式
  11. 証明書要求ペイロード形式
  12. ハッシュペイロード形式
  13. 署名ペイロード形式
  14. Nonce ペイロード形式
  15. 通知ペイロード形式
  16. 削除ペイロード形式
  17. ベンダ ID ペイロード形式

1. はじめに English

本ドキュメントでは、ISAKMP (Internet Security Association and Key Management Protocol) について解説する。ISAKMP は、Internet において行政、商業、プライベートで要求されるセキュリティを確立するための、認証、鍵管理、SA (security association) に関するセキュリティの概念をまとめたものである。

ISAKMP では、SA の確立、ネゴシエーション、変更、削除を行なうための手続きとパケット形式を定義する。SA には、IP 層サービス (ヘッダ認証やペイロード・カプセル化)、トランスポートやアプリケーション層でのものなど、様々なネットワークサービスを行なうために必要とされるすべての情報が含まれる。ISAKMP では、鍵生成と認証データを交換するためのペイロードを定義している。これらのフォーマットは、鍵と鍵生成技法、暗号化アルゴリズム、認証機構から独立した認証データを送信するための一貫したフレームワークを提供する。

SA 管理 (と鍵管理) を鍵交換の実際から完全に切り離すために、ISAKMP は鍵交換プロトコルとは区別される。それぞれに異なるセキュリティ特性を持つ、多くの鍵交換プロトコルが存在している。であるが、SA 属性の形式を一致させ、SA のネゴシエーション、変更、削除のために 共通のフレームワークが必要である。ISAKMP はこの共通フレームワークとして働く。

機能を三つに分けることで、完全な ISAKMP 実装に対するセキュリティ解析の複雑さが増す。 だが分離は、異なるセキュリティを必要とするシステム間での相互運用性のために必須であり、ISAKMP サーバのさらなる開発のための分析を簡単にするはずだ。

ISAKMP の目的は、ネットワークスタックのすべての層における (IPSEC、TLS、TLSP、OSPF、などなどの) セキュリティプロトコルのための SA のネゴシエーションをサポートすることである。SA の管理を一ヶ所にまとめることで、ISAKMP では各セキュリティプロトコルごとに機能を重複させることを防いでいる。同時に ISAKMP によって、サービススタック全体を一度にネゴシエーションすることで、接続を確立するための時間も短縮される。

セクション1の残りの部分は、セキュリティ・ネゴシエーションへの動機づけと、ISAKMP の主要な要素、例えば SA と管理、認証、公開鍵暗号、その他の要素についての概略である。セクション2は、ISAKMP で使用される用語と概念について説明する。セクション3では、異なるISAKMP ペイロード形式について解説する。セクション4では、ISAKMP ペイロードを、認証された状態でSAを確立し鍵を交換するための交換にどうまとめるかを解説する。また加えて、SA の変更、削除、エラー通知についても解説する。セクション5では、ISAKMP 交換のコンテキストにおける各ペイロードの処理について、エラー処理と関連する動作も含めて解説する。追保では、ISAKMP とその中で新しいDOI (Domain of Interpretation) を定義する ために必要となる属性値を紹介する。

1.1 記法における要求 English

「しなければならない」、「してはならない」、「要求されている」、「することになる」、「することはない」、「する必要がある」、「しないほうがよい」、「推奨される」、「してもよい」、「選択できる」、本文中のある、これらのキーワードの意味は [RFC 2119] に解説されている。

1.2 ネゴシエーションの必要性 English

ISAKMP は、よりすぐれたセキュリティのために、認証と鍵交換は一つにされなければならないという [DOW92] の表明を、SA 交換を含むよう拡張したものである。通信に必要とされるセキュリティ・サービスは、個々のネットワークの構成と環境によって変化する。Intranet とも呼ばれる VPN (Virtual Private Networks) を立ち上げている組織では、VPN 内での通信のために一個のセキュリティ機能を必要とし、さらに地理的に離れた組織要素、顧客、納品業者、(独自の VPN を持つ)下請け、行政、その他をサポートするために多くの相異なるセキュリティ機能を必要とするだろう。大きな組織内の各部門は、内部ネットワークでの(個人、社内秘、健康などの)データの分離と保護のために多数の SA を必要とするだろうし、一つの部門内での通信のためにさらに SA を必要とするだろう。『自宅への電話』を求めるモバイル・ユーザは別のセキュリティ要求を産み出す。これらの要求は帯域の広さの問題で抑えられる。少人数のグループであれば、『WEB of Trust』 を立ち上げることでセキュリティの要求を満たすことができるかもしれない。 ISAKMP 交換は、ユーザが、認証され保護されたやり方で相互運用性のある SA などのセキュリティ属性の共通集合に基づく同意をサポートするセキュリティ機能によって、接続を行う能力を、さまざまに組み合わされたネットワーク・コミュニティに提供する。

1.3 ネゴシエーションできるもの English

SA は、IPSec だけでなく、それとは異なるの暗号化アルゴリズムと鍵確立アルゴリズムをサポートしなければならない。SA はまた、低位層プロトコルのためのホストに基づく証明書と、高位層プロトコルのためのユーザに基づく証明書を共にサポートしなければならない。アルゴリズムと機構の独立性は、email、リモートログイン、ファイル転送などのアプリケーションに加えて、さらにセッション指向プロトコル、ルーティングプロトコル、リンク層プロトコルで必要とされる。ISAKMP は、広い範囲にわたるセキュリティプロトコル、アプリケーション、セキュリティ要求、ネットワーク環境に対して、共通の SA と鍵確立プロトコルを提供する。

ISAKMP は、特定の暗号アルゴリズム、鍵生成アルゴリズム、セキュリティ機構とは結びついていない。多くの理由からこの柔軟性には利点がある。最初に、先に説明したダイナミックな通信環境をサポートする。次に、特定のセキュリティ機構やアルゴリズムから独立していることによって、将来よりすぐれた機構やアルゴリズムへの移行が可能となる。よりすぐれたセキュリティ機構が開発されたり、現行の暗号化アルゴリズム、認証機構、鍵交換への新しい攻撃が発見された時に、ISAKMP では、まったく新規の KMP を開発したり現行のものにパッチを当てることなく、アルゴリズムと機構の更新を行なうことが出来る。

ISAKMP では、認証と鍵交換要素に対して基本的な要求がある。これらの要求は、DoS (Denial of Service)、リプレイ/リフレクション、man-in-the-middle、 コネクション・ハイジャックなどの攻撃を防ぐためのものである。このらはプロトコルを目標とする種類の攻撃なので重要である。機構とアルゴリズムの独立を提供する完全な SA サポートとプロトコルへの危険からの保護が、ISAKMP の強さである。

1.4 SA と管理 English

SA は、安全な通信を行なうためのセキュリティサービスをどのように利用するかを記述する、二つ以上のエンティティの関連である。関連は、エンティティ間での契約とみなせる情報の集まりで表わされる。この情報はすべてのエンティティ間で同意され共有されなければならない。SA が情報単体を指すこともあるが、既存の関連の物理的な実体化にすぎない。情報として表現されるこの関連の存在がセキュリティの相互運用のために必要とされるセキュリティ情報についての同意を提供する。すべてのエンティティは、安全な通信が可能となるように SA から離れてはならない。SA 属性にアクセスする際にエンティティは、SPI (Security Parameter Index) と呼ばれるポインタ/ ID を使用する。 [SEC-ARCH] に IP SA と SPI の定義の詳細が載っている。

1.4.1 SA と登録 English

IPSec (AH、ESP) で要求され推奨されるSA属性は [SEC-ARCH] で定義されている。IPSec SA のための属性には、認証機構、暗号化アルゴリズム、アルゴリズムモード、鍵長、IV (Initialization Vector: 初期化配列) が含まれるが、これらに限定されているわけではない。アルゴリズムと機構から独立したセキュリティを提供する他のプロトコルは、SA 属性に対する独自の要求を定義しなくてはならない。ISAKMP を特定の SA 定義から離して置くことは、すべてのセキュリティプロトコルとアプリケーションのための SA を ISAKMP によって確立できることを可能とするために重要である。

注意: セキュリティプロトコルおよびアプリケーションが考慮するべき SA 属性についての解説については [IPDOI] を参照すること。

異なるネットワーク・エンティティの間での (ある暗号化アルゴリズムなどの) 特定の属性の特定を簡単にするために、属性には ID を割り当てなければならないと同時に、それは中央機関に登録されなければならない。IANA (Internet Assigned Numbers Authority) は Internet におけるこの役割を果たしている。

1.4.2 ISAKMP での要求 English

SA 確立は、IP ベースのネットワークのために定義された鍵管理プロトコルの一部分でなければならない。多様でダイナミックなネットワーク環境においてセキュリティプロトコルをサポートするために SA の概念は必要となる。認証された相手との間で鍵が確立されたことを保証するためにも、認証と鍵交換だけでもリンクされなければならない [DOW92]。SA の確立は認証と鍵交換プロトコルとリンクされなければならない。

ISAKMP は、何らかのプロトコル (ESP/AH など) のための SA の確立が続く、エンティティ間でのプロトコル交換を提供する。最初に、初期プロトコル交換で同意できるセキュリティ属性の基本集合を認める。この基本集合は続く ISAKMP 交換への保護を提供する。同時にISAKMP プロトコルの一部分として実行される認証方式と鍵交換を指定する。ネゴシエーションするサーバ・エンティティ間でセキュリティ属性の基本集合があらかじめ決まっている場合は、最初の ISAKMP 交換を飛ばして直ちに SA の確立を行なう場合もある。セキュリティ属性の基本集合の同意、初期IDの認証、必要な鍵の生成が終われば、ISAKMP を起動したエンティティによる続く通信に確立された SA を使用できる。ISAKMP 相互運用性を成り立たせるための実装しなければならない SA 属性の基本集合は追保Aで定義されている。

1.5 認証 English

安全なネットワーク通信を確立する上で非常に大切なステップは、通信の相手のエンティティの認証である。多くの認証機構がある。認証機構は、その強度によって二種類、弱いものと強いものに分けられる。平文鍵のような保護されていない認証情報をネットワーク越しに送るものは、ネットワーク盗聴によって読まれてしまう危険があるため弱い。付け加えて、エントロピーが少ない、下手に選んだ鍵の一方向ハッシュを送るのも、盗聴したメッセージに対しての力任せの推測攻撃の危険性があるので同様に弱い。ID を確立するためにパスワードを使用出来るが、最近出た IAB (Internet Architecture Board) からの声明 [IAB] があるので、本文ではこれについては触れない。DSS (Digital Signature Standard) や RSA (Rivest-Shamir-Adleman) 署名などのデジタル署名は公開鍵ベースの強い認証機構である。公開鍵デジタル署名を使用するには、各エンティティには公開鍵と秘密鍵が必要となる。証明書はデジタル署名認証機構の基礎である。証明書は、あるエンティティの ID (ホスト、ネットワーク、ユーザ、アプリケーション) をその公開鍵、また場合によっては特権、クリアランス、構成要素など、その他のセキュリティに関連する情報とつなぐ。デジタル署名に基づく認証は、証明書を作り、署名し、正しく配布するための信頼できる第三者の証明書発行機関を必要とする。DSS や RSA などのデジタル署名と証明書についてのより詳しい情報については [Schneier] を参照すること。

1.5.1 証明書発行機関 English

証明書には、生成、確認、取り消し、管理、配布のためのインフラが必要である。IPRA (Internet Policy Registration Authority) [RFC-1422] は、IETF によってこのインフラに向けて設立された。IRPA は PCA (Policy Certification Authorities) を証明する。PCA は、利用者とその下のエンティティを証明する CA (Certificate Authorities : 証明局) をコントロールする。現行の証明に関連する成果には、DNS に署名を提供する DNS (Domain Name System)のセキュリティ拡張 [DNSSEC] がある。PKIX (Public Key Infrastructure : 公開鍵インフラ) ワーキンググループは、X.509 証明書の Internet プロフィールを指定している。X.509 証明を利用者に提供するための X.500 ディレクトリサービスの開発が産業界で進んでいる。合衆国郵政省は (CA) 階層を開発している。NIST 公開鍵インフラストラクチャ・ワーキンググループも同じ分野で活動している。DOD MISSI (Multi Level Information System Security Initiative)プログラムは合衆国政府のための証明インフラの開発を目的に開始された。インフラがない場合には、お互いを知っていて信頼している利用者の間での認証と通信のプライバシーについては PGP Web of Trust 証明を使用出来る。

1.5.2 エンティティの名前づけ English

エンティティの名前は ID であり、それによって証明書中の公開鍵と結び付けられている。CA は発行する証明書の名前のセマンティックスを定義しなければならない。CA がどう名前付けポリシーを定義しているかの例としては、UNINETT PCA ポリシー声明 [Berge] がある。証明書が確認されるということは、名前が確認され、その CA の元でその名前に意味があるということである。例として、DNS がそのゾーンとノードに対する CA となる DNS セキュリティ拡張がある。公開鍵とそれらの鍵の署名を提供するリソースレコード (RR) がある。鍵が付いた名前は IP アドレスとドメイン名は、それらの情報をアクセスするエンティティにとって意味を成す。Web of Trust は別の例である。それが設定されると、名前が公開鍵と結び付けられる。PGP での名前は通常エンティティの email アドレスであり、それは email を理解するもの、それらにだけ意味を持つ。まったく異なる名前スキームを使用することもできる。

1.5.3 ISAKMP での要求 English

ISAKMP 交換では強い認証を提供しなければならない。他方のエンティティを認証することが出来ないならば、確立された SA とセッション鍵は疑わしい。認証無しでは、エンティティの ID を信頼できず、アクセス制御は当てにならない。暗号 (例、ESP) と統合性 (例、AH) は続く通信を盗み聞きから保護する。認証無しでは、man-in-the-middle 攻撃を行なう的との間で SA と鍵を確立してしまい、あなたの個人的なデータを盗み取られることがありうる。

デジタル署名アルゴリズムは ISAKMP の認証構成要素の中で使用されなければならない。 しかしながら ISAKMP は、特定の署名アルゴリズムや認証局 (CA) にその機能を任せない。 ISAKMP は、エンティティがサポートする CA を示す通信を行なうことを許している。CA の選択後、プロトコルは実際の認証交換をサポートするために必要なメッセージを提供する。プロトコルは、異なる CA と認証タイプ (X.509、PKCS #7、PGP、DNS SIG/Key レコードなど) の ID のための機能と証明書 ID の交換を提供する。

ISAKMP は、公開鍵暗号に基づくデジタル署名を認証に使用する。他にも強い認証システムが存在するので、それを ISAKMP の追加オプション認証機構として指定することも出来るだろう。それらの認証システムは、信頼できる第三者、秘密セッション鍵を配布する鍵配布センター (KDC) に依存している。その例として、そのネットワークドメイン内のすべてのクライアントサーバの秘密鍵をサーバが保持する、Kerberos がある。それ自身の秘密鍵を保持していることの証明によってサーバへの認証を行なう。

ISAKMP 仕様は、信頼できる第三者機関 (TTP) や証明書ディレクトリサービスとの間の通信プロトコルについては規定していない。TTP やディレクトリサービスが規定するプロトコルは本仕様の範囲を外れている。追加のサービスとプロトコルの使用は、鍵交換ごとのドキュメントで解説される。

1.6 公開鍵暗号 English

公開鍵暗号は、Internet の利用者が相互運用する多数の方法をサポートする上で必要となる、共有秘密とセッション鍵を得る方法の中で、もっとも自由度が高く、スケーラビリティがあり、効率が高い。それぞれに異なるプロパティを持つ、多くの鍵生成アルゴリズムが使用可能である ( [DOW92]、[ANSI]、[Oakley] 参照 )。鍵交換プロトコルの機能には、鍵確立手法、認証、対称性、PFS (Perfect Forward Security)、BTP (Back Traffic Protection) が含まれる。

注意: 暗号鍵はある期間の間情報を保護できる。だがこれは、通信の保護に使用される鍵が使用後破棄され、いかなる理由があっても保持されないという前提に基づいている。

1.6.1 鍵交換プロパティ English

鍵確立 (鍵生成/鍵転送) : 公開鍵暗号を鍵確立に使用する二つの一般的な手法は、鍵配送と鍵生成である。鍵配送の一例に、乱数で生成された (続く通信を暗号化する) セッション鍵を受信側の公開鍵で暗号化するための RSA アルゴリズムの使用がある。暗号化された乱数鍵は受信側に送られ、受け取った側は自分の秘密鍵で復号する。この時点で両端は同じセッション鍵を持つが、一方向の通信だけから生成されている。この鍵配送手法の利点は、この後に説明するものよりも計算のオーバーヘッドが少ないことである。Diffie-Hellman (D-H) アルゴリズムは、公開鍵暗号を使用して鍵を生成する。D-H アルゴリズムは、二人の利用者の間で公開鍵を交換することから始まる。各ユーザは、続いて他方の公開鍵と自分の秘密鍵を共通秘密値を計算するために数学的にまとめる。この秘密値をセッション鍵や乱数から作られたセッション鍵を暗号化する鍵暗号化鍵として使用出来る。この方式は、両利用者が持つ公開と秘密情報セッション鍵に基づくセッション鍵を生成する。D-H アルゴリズムの利点は、メッセージを暗号化するための鍵が両利用者が保持する情報に基づいていて、両方向の鍵交換が独立しているため、PFS が得られる点である。これらのアルゴリズムについての詳細な解説は [Scheneier] に載っている。これら二つの鍵生成手法にはおおくの変形があり、それらの間では相互運用性がある必要はない。

鍵交換認証: 鍵交換は、プロトコル確立の中もしくはそれが完了した後で認証されうる。プロトコル確立中の鍵交換の認証は、それが完了する前に、両端が自分が秘密セッション鍵を持っていることを証明することによって得られる。証明は、プロトコル交換において、既知のデータを秘密セッション鍵で暗号化することで行なえる。プロトコル確立後の認証は、それに引き続く通信で行なわなければならない。プロトコル確立中の認証の方が望ましく、もし秘密セッション鍵が相手との間で確立されなかった場合には、続く通信は実行されない。

鍵交換対称性: どちらの端からも交換を開始でき、交換されたメッセージを、生成される鍵に影響することなく送信できることを鍵交換の対称性という。どちらから交換を開始したかに関係なく鍵を計算できるので、対称性があることが望ましい。鍵交換での対称性は望ましいが、鍵管理プロトコル全体で対称性があると、リフレクション攻撃への耐性が低くなることがある。

PFS (Perfect Forward Secrecy) : [DOW92] で解説されているように、認証された鍵交換プロトコルは、以前の通信による長期間の秘密鍵情報の開示が鍵交換の秘密性の危機を高めない場合には、PFS を提供する。PFS のプロパティは認証なしの鍵交換には当てはまらない。

1.6.2 ISAKMP からの要求 English

ISAKMP は認証された鍵交換をサポートしなければならない。利用者は必要に応じてさらなる鍵確立アルゴリズムを選ぶべきである。ISAKMP は、特定の鍵交換を指定しない。であるが、Oakley 鍵交換 [Oakley] と ISAKMP との組み合わせる提案を [IKE] において解説している。鍵確立アルゴリズムの選択の際に評価されるべき要求項目には、確立手法 (生成 vs. 配送)、PFS、鍵証明書計算のオーバーヘッド、鍵長がある。ISAKMP は、利用者の要求に応じてエンティティがそれがサポートする鍵交換を示すための通信を開始することを許している。鍵交換の選択終了後、プロトコルは実際の鍵確立をサポートするメッセージを提供する。

1.7 ISAKMP 保護 English

1.7.1 対妨害 (Anti-Clogging - DoS) English

多数のセキュリティサービスがあるが、DoS 攻撃からの保護はもっとも解決が難しいものの一つである。「Cookie」などの対妨害トークン (Anti-Clogging Token:ACT) の目的は、正当性の確認に多くの CPU 資源を使用することなく、コンピュータ資源を攻撃から保護することにある。CPU を必要とする公開鍵操作に先立って交換することにより、ある種の DoS の試みの裏をかくことが出来る。DoS 攻撃への完全な保護は不可能であるが、この ACT を使用することで扱いやすくなる。ACT の使用は、Karn と Simpson が [Karn] で紹介した。

セクション4で紹介する交換において、対妨害機構は状態ガベレッジコレクタ機構と共に使用されるべきであることに注意しなければならない。攻撃者は、それでもでたらめな IP アドレスを持つパケットでサーバをあふれさせ、状態を作ることができる。最初に対妨害のみのフェイズを通らない ISAKMP を使用するプロトコルでは、[Karn] にあるように、そのような積極的なメモリ管理技法を使用すべきである

1.7.2 接続ハイジャック English

ISAKMP は、認証、鍵交換、SA 交換をリンクすることにより、接続ハイジャックを防ぐ。このリンクによって、攻撃者が認証が終了した後で割り込み、鍵と SA の交換の間、片方のエンティティの振りをすることを防ぐ。

1.7.3 Man-in-the-Middle 攻撃 English

Man-in-the-Middle 攻撃には、メッセージの横取り、挿入、削除、変更やメッセージの送信元に送り返し、古いメッセージのリプレイ、メッセージの転送が含まれる。ISAKMP の機能は、これらの種類の攻撃を成功させない。ISAKMP 交換のリンクのため、プロトコル交換にメッセージを挿入することは出来ない。ISAKMP プロトコル状態機械は、メッセージが削除された場合、状態が消去されアイドルに戻ることによって、完全でないSAが生成されることを防ぐように定義されている。また状態機械はメッセージの送り返しによって害を受けない。新しい SA 確立ごとに時間によって変化する情報を持つ Cookie を新たに要求するため、古いメッセージをリプレイする攻撃から守ることが出来る。ISAKMP の強い認証要求のため、対称となる相手以外の誰とも SA を確立することがない。目的地と異なる場所へメッセージを転送したり変更したりされても、それは検出され、SA は確立されることはない。ISAKMP の仕様は普通でない処理が行なわれたなら、それについて適切な通知を行なうように定義されている。

1.8 マルチキャスト通信 English

マルチキャスト通信においてもユニキャスト通信と同様のセキュリティサービスを要求するだろうこと、そして他のセキュリティサービスが必要となるだろうことが予測される。マルチキャストトラフィックでの SPI の配布の問題は、[SEC-ARCH] で公開された。マルチキャストセキュリティ問題は [RFC-1949] と [BC] でも解説されている。ISAKMP は、将来の拡張によってマルチキャスト鍵配布をサポートするだろう。マルチキャストセキュリティに関連する問題についての入門としては、この領域における Sparta の研究を解説した、Internet Draft の [RFC-2094] と [RFC-2093] を読むとよい。

2 用語とコンセプト English

2.1 ISAKMP 用語 English

セキュリティプロトコル (Security Protocol) : セキュリティプロトコルは、ネットワークスタックのある一点においてネットワーク通信に対してセキュリティサービスを実行するエンティティからなる。例えば、IPSEC ESP と IPSEC AH は二つの異なるセキュリティプロトコルである。TLSは別の例である。セキュリティプロトコルは、例えば統一性と秘匿性を一つのモジュールで提供するように、一つ以上のサービスを実行することもある。

保護スート (Protection Suite) : 保護スートは、多くのセキュリティプロトコルによって用いられなければならないセキュリティサービスの一覧である。例えば、保護スートが DES 暗号の IP ESP と鍵付き MD5 の IP AH からなっている場合がある。スート内のすべての保護は一つのまとまりとして扱われなければならない。異なるセキュリティプロトコルのセキュリティサービスが、微妙な相互作用を行なうことがあるので、スートの効果は全体で分析、確認されなければならないので、これが必要となる。

SA (Security Association) : SAはセキュリティプロトコル特有の、そのセキュリティプロトコルの位置でトラフィックを保護するために必要となるサービスと機構を完璧に定義するパラメータの集合である。パラメータには、アルゴリズム ID、モード、暗号鍵、その他が含まれうる。SA はそれが関連するセキュリティプロトコルによって参照される(例えば、『ISAKMP SA』、『ESP SA』、『TLS SA』)。

ISAKMP SA : ISAKMP サービスによって自分自身のトラフィックを保護するために使用される SA である。セクション2.3とセクション2.4で ISAKMP SA の詳細について解説する。

セキュリティ・パラメータ・インデックス (Security Parameter Index) : SA の ID であり、セキュリティプロトコルからの相対値である。各セキュリティプロトコルは独自の『SPI 空間』がある。(セキュリティプロトコル、SPI) 組によって SA を特定しうる。SPI が重ならないかどうかは実装に依存するが、システム、プロトコル、その他のオプション当たりでは重ならないようにすることが可能だろう。DOI によるが、追加の情報 (例、ホストアドレス)が SA を特定するために必要なこともある。また DOI は、どの SPI (例、発信側、受信側) が通信中に送られるかを決定する。

DOI (Domain of Interpretation : 解釈ドメイン) : DOI はペイロード形式、交換タイプ、セキュリティポリシーや暗号アルゴリズムやモードなどのセキュリティ関連情報の名前付けの方式を定義する。DOI ID は、ISAKMP ペイロードを解釈する為に使用される。システムは複数の DOI を同時にサポートしなければならない。DOI のコンセプトは、TSIG CIPSO ワーキンググループによるこれまでの作業に基づいているが、セキュリティサービスの名前付けと解釈を含むために、セキュリティラベル解釈を超えて拡張されている。DOI は以下の項目を定義する。

IETF IPSec DOI のためのルールは [IPDOI] に載っている。カスタマイズされたルールの仕様は別のドキュメントに載るだろう。

Situation (状況) : ネゴシエーションされているセッションを保護するために必要となるセキュリティサービスを決定するために必要とシステムが考える、セキュリティ関連情報すべてがSituation に含まれる。Situation には、アドレス、セキュリティ・クラス、 操作のモード(通常 vs. 緊急)、その他が含まれることになる。

Proposal (提案) : システムが、ある Situation 下でトラフィックを保護するために受け入れられると考える保護スートを、望ましい順に並べたリストである。

ペイロード: ISAKMP では、SA データ、鍵交換データなどを DOI 定義の形式で送るために使われる、複数の種類のペイロードが定義されている。ペイロードは、汎用ペイロードヘッダと ISAKMP に理解されないオクテットの並びから成っている。ISAKMP は、ペイロードの動機と解釈に DOI 特有の機能を使用する。複数のペイロードを一個の ISAKMP メッセージで送信できる。より詳しいペイロードのタイプについてはセクション3を、IETF IPSec DOI ペイロードについては [IPDOI] を参照すること。

交換タイプ:交換タイプは、ISAKMP 交換でのメッセージの、ペイロードタイプはそれらのメッセージ個々に含まれるものの番号の仕様である。各交換タイプは、参加者の匿名性、鍵情報の PFS、参加者の認証、その他のようなあるセキュリティサービスの集合を提供するようにデザインされている。セクション4.1で、ISAKMP 交換タイプのデフォルトの集合が定義されている。 他の交換タイプを、追加の鍵交換をサポートするために必要なら追加してもよい。

2.2 ISAKMP の位置 English

図1は、ネットワークアーキテクチャのシステム・コンテクストから見た、ISAKMP の大まかな位置付けである。セキュリティサービスのネゴシエーションにおいて重要な部分は、各 SA の『スタック』全体を一まとめに考えることである。これを『保護スート』と呼ぶ。

     +------------+        +--------+                +--------------+
     !     DOI    !        !        !                !  Application !
     ! Definition ! <----> ! ISAKMP !                !    Process   !
     +------------+    --> !        !                !--------------!
    +--------------+   !   +--------+                ! Appl Protocol!
    ! Key Exchange !   !     ^  ^                    +--------------+
    !  Definition  !<--      !  !                           ^
    +--------------+         !  !                           !
                             !  !                           !
            !----------------!  !                           !
            v                   !                           !
        +-------+               v                           v
        !  API  !        +---------------------------------------------+
        +-------+        !                Socket Layer                 !
            !            !---------------------------------------------!
            v            !        Transport Protocol (TCP / UDP)       !
     +----------+        !---------------------------------------------!
     ! Security ! <----> !                     IP                      !
     ! Protocol !        !---------------------------------------------!
     +----------+        !             Link Layer Protocol             !
                         +---------------------------------------------+
    

図1: ISAKMP 関係図

2.3 ネゴシエーション・フェイズ English

ISAKMP はネゴシエーションとして二つの『フェイズ』を提供する。最初のフェイズで、二つのエンティティ(例、ISAKMP サーバ)は、それらの間でその先行なわれるネゴシエーションのトラフィックをどう保護するかについて同意し、ISAKMP SA を確立する。この ISAKMP SA をそれ以降使用して、要求されるプロトコル SA についてのネゴシエーションを保護する。二つのエンティティ (例、ISAKMP サーバ) は、複数の ISAKMP SA をネゴシエーション (同時にアクティブに) することができる。

ネゴシエーションの二番目のフェイズは、その他のセキュリティプロトコルの SA を確立するために使用される。この二番目のフェイズで多数の SA を確立することが出来る。このフェイズで ISAKMP によって確立された SA は、多数のメッセージ/データ交換を保護するためのセキュリティプロトコルによって使用できる。

ほとんどの場合の単純な使用において2フェイズ方式は立ち上がりのコストが高すぎるが、ほとんどの場合にたいして利点があると言えるいくつかの理由がある。

まず、エンティティ (例、ISAKMP サーバ) は、複数の二番目のフェイズのネゴシエーションを行なうことで、最初のフェイズのコストは消すことが出来る。つまり両端の間で、通信ごとに最初からやり直すことなく、複数の SA を確立することが出来るということである。

二番目に、最初のフェイズでネゴシエーションされたセキュリティサービスによって、二番目のフェイズのネゴシエーションのセキュリティプロパティを得ることが出来る。例えば、最初のネゴシエーション後、ISAKMP SA が提供する暗号化によって、ID 保護を行なうことができるので、より簡便な二番目のフェイズの交換を使用することが出来る。他方、最初のフェイスで確立したチャネルが、ID 保護に向かない場合、二番目のフェイズでは適切なセキュリティ機構をネゴシエーションしなければならない。

三番目に、ISAKMP SA が与えてくれる『信頼できる経路』無し、つまりエンティティ (例、ISAKMP サーバ) はエラー通知や SA の削除の際に毎回完全な再認証を行なわなければならないことになっても、ISAKMP SA を使用することで、ISAKMP 管理アクティビティのコストをかなり削減できる。

各フェイズに行なわれるネゴシエーションは、ISAKMP の定義 (セクション4参照) か、鍵交換のための DOI 内で定義による交換によって達成される。

セキュリティサービスは、書くネゴシエーション・フェイズごとに違うふうに適応されるかもしれないことに注意。例えば、ネゴシエーションのそれぞれのフェイズで異なる参加者が認証される。最初のフェイズでは、認証される参加者は ISAKMP サーバ/ホストかもしれないが、二番目のフェイズでは、ユーザかアプリケーションレベルのプログラムが認証される。

2.4 SA の特定 English

システム間での安全なチャネルの立ち上げの間、ISAKMP はすでにセキュリティサービスが存在していることを前提にはできないので、自分自身で何らかの保護を作り出さなければならない。それゆえ、ISAKMP は、ISAKMP SA を他のものとは別のものと考え、それ自身の名前空間の中で自分自身で ISAKMP SA を管理する。ISAKMP は、ISAKMP SA を特定するために ISAKMP ヘッダ中の二つの Cookie フィールドを使用する。SA 確立の間、他のセキュリティプロトコルのための SA を特定するために、ISAKMP ヘッダ中の Message ID とプロトコルペイロード中の SPI フィールドが 使用される。これら四つのフィールドの解釈は、実行される操作によって変化する。

次の表には、SA 確立の間、いくつかのフィールドが使われるか使われないかを載せてある。以下のフィールドは、SA 確立に関係する様々な操作にとって必要である。それらは、ISAKMP ヘッダ中の Cookie、ISAKMP ヘッダ Message-ID フィールド、プロトコルペイロード中の SPI フィールドである。表中の『×』は値が存在しなければならないことを、『 NA 』は、その操作に対しては使用されないことを示す。

# 操作 I-Cookie R-Cookie Message ID SPI
(1) ISAKMP SA ネゴシエーション開始 × 0 0 0
(2) ISAKMP SA ネゴシエーション応答 × × 0 0
(3) 他の SA ネゴシエーションの開始 × × × ×
(4) 他の SA ネゴシエーションの応答 × × × ×
(5) その他 ( KE、ID、etc.) × × ×/0 NA
(6) セキュリティプロトコル ( ESP、AH ) NA NA NA ×

表中の最初の行(1)で、開始側は Initiator-Cookie フィールドを、セクション2.5.3とセクション3.1で概略を述べた方法を使って、ISAKMP ヘッダに含める。

表の二行目の(2)で反応側は、ISAKMP ヘッダ中に Initiator-Cookie と Responder-Cookie フィールドを、セクション2.5.3とセクション3.1で概略を述べた方法を使って、含める。フェイズ1ネゴシエーション中に使われる交換タイプによっては、更なるメッセージが ISAKMP 両端の間で交換されることもある。一旦フェイズ1交換が完了したら、それ以降のすべての ISAKMP 両端の間の通信の ISAKMP ヘッダに Initiator-Cookie と Responder-Cookie が含まれる。

フェイズ1ネゴシエーションの間、開始側と反応側の Cookie によって ISAKMP SA を決定する。それゆえ、プロトコルペイロード中の SPI フィールドは冗長であり、0 に設定しても送信されるエンティティの Cookie を含んでも構わない

表中の三行目の(3)で開始側は、Message-ID と SA Proposal 中に含まれるプロトコルを関連付ける。Proposal 中の各プロトコルと関連付けられる、この Message-ID と開始側の SPI は反応側へ送られる。SPI は、フェイズ2ネゴシエーションが完了した時に、セキュリティプロトコルによって一度使用される。

表中の四行目の(4)で反応側は、受け取った Proposal 中の各プロトコルと関連付けられる、同じ Message-ID と反応側の SPI を含める。この情報は開始側に送り返される。

表中の5行目の(5)で開始側と反応側は、処理中のプロトコルネゴシエーションを追跡するために ISAKMP ヘッダ中の Message-ID フィールドを使う。これはフェイズ 2 交換にだけ当てはまり、フェイズ1交換では組み合わされた Cookie が ISAKMP SA を識別するので、値は 0 でなければならない。プロトコルペイロードが SA ネゴシエーションメッセージ交換でのみ使用されるので、プロトコルペイロード中の SPI フィールドは使用されない (ステップ 3 と 4)。

表中の六行目の(6)でフェイズ 2 ネゴシエーションは完了する。セキュリティプロトコルは SPI を使って、通信に適応されるセキュリティサービスと機構がどれかを決定する。六行目(6)の SPI 値はプロトコルペイロード中の SPI フィールドではなく、セキュリティプロトコルヘッダ中にある SPI フィールドである。

SA 確立の間に SPI は生成されなければならない。ISAKMP は可変長の SPI を扱えるように設計されている。SA 確立の間、プロトコルペイロード中にある SPI Size フィールドを使用することでこれを行なっている。SPI の取り扱いは DOI 仕様によって概要が解説される(例、[IPDOI] )。

SA が最初に確立した時、片側は開始側の役割を果たし他方は反応側の役割を果たす。一旦 SA が確立されると、元々の開始側も反応側のどちらもエンティティとしてフェイズ2ネゴシエーションの開始できる。それゆえ ISAKMP SA はまさに両方向である。

付け加えて、ISAKMP では、ネゴシエーション処理中に開始側、反応側の両方がある程度制御することが許されている。SA ネゴシエーション中に複数の Proposal を含められるように ISAKMP は設計されているが、開始側はそれのローカルセキュリティポリシーにしたがって、一個だけ Proposal を作ることである程度の制御が可能となる。開始側が二個以上の Proposal を含むものを (希望する順に並べて) 送ると、開始側は制御件を反応側に受け渡すことになる。反応側が SA 確立を制御すると、開始側が提供する複数のオプションの中でではあるが、反応側はそのポリシーを開始側のものより郵船することができる。反応側のローカルセキュリティポリシーに一番合致する Proposal を選び、それを開始側に返すことで達成される。

2.5その他 English

2.5.1 トランスポートプロトコル English

ISAKMP はどんなトランスポート上でも IP 自体上でも実装できる。実装には UDP ポート500番を使って ISAKMP の機能を送受信する機能を持たなければならない。UDP ポート500番は IANA (Internet Assigned Numbers Authority) によって ISAKMP に割り当てられている。実装はその外のトランスポートプロトコルや IP 自身の上での ISAKMP をサポートしてもよい

2.5.2 予約済みフィールド English

ISAKMP ペイロード中にある RESERVED (予約済み) フィールドの存在はバイト境界に合わせるために使用される。パケットを発行する際に、ISAKMP プロトコル中のすべての RESERVED フィールドは0に設定しなければならない。受信側は RESERVED フィールドが0であるかどうかを調べるべきであり、そうでない場合にはパケットを廃棄すべきである

2.5.3 対妨害トークン (Anti-Cloggin Token:ACT) 生成 English

Cookie生成の詳細は実装に依存するが、( [Karn]で初めて Phil Karn が言ったように) 以下の基本的な要求を満たさなければならない
  1. Cookie は参加者に特有のものでなければならない。これによって攻撃者が本物の IP アドレスと UDP ポートを使ってクッキーを取得し、それを使って適当に選んだ IP アドレスやポートからの Diffie-Hellman 要求によって犠牲者をはめること防ぐ。
  2. 発行元のエンティティが受け入れる Cookie を生成することがそのエンティティ以外の誰かに可能であってはならない。これは、発行元のエンティティはローカルの秘密情報を、Cookie の生成とその確認に使用しなければならないということである。この秘密情報をどの Cookie からであっても導き出せてはならない。
  3. Cookie 生成機能は、CPU 資源を食いつぶそうとする攻撃を防ぐために高速でなければならない。

Karn が提案した Cookie 生成手法は、IP のソースとデスティネーションアドレス、UDP のソースとデスティネーションポート、ローカルで生成した秘密の乱数値に対して高速なハッシュ (例、MD 5) を実行することである。ISAKMP は、リプライ攻撃を防ぐ手助けとなるように、各 SA の確立ごとに相異なる Cookie を要求するので、ハッシュされる情報には日付と時刻を追加しなければならない。生成された Cookie は (セクション3.1で解説するように) ISAKMP ヘッダ中の Initiator-Cookie と Responder-Cookie フィールドに置かれる。これらのフィールドは 8 オクテット長あり、そのため生成される Cookie も 8 オクテットでなければならない。通知と削除のメッセージ(セクション3.143.154.8参照)は一方向送信であり、既存の ISAKM SA の保護下で行なわれるので、新しい Cookie 生成を要求しない。これの一つの例外が、SA の確立が完了する前のフェイズ1交換中の通知メッセージである。セクション3.144.8でより詳しく扱う。

3 ISAKMP ペイロード English

ISAKMP ペイロードは、ISAKMP メッセージを構成するためのモジュール化された組み立てブロックを提供する。ISAKMP 中のペイロードの存在とその順序は、ISAKMP ヘッダ (セクション図2参照) 中の Exchange Type フィールドで定義されそれに依存する。ISAKMP ペイロードタイプについては、セクション3.4から3.15で解説する。ISAKMP ペイロード、メッセージ、交換はネットワークオクテットオーダで記述する。

3.1 ISAKMP ヘッダ形式 English

ISAKMP メッセージは、図2のような固定のヘッダに、任意の数のペイロードが続く形式を持つ。固定ヘッダによって、その解釈が単純になり、プロトコルソフトウェアがより複雑でなくなり 実装もやさしくなるという利点がある。固定ヘッダには状態、ペイロード処理を管理しさらには DoS やリプレイ攻撃を防ぐためにプロトコルが必要とする情報を含んでいる。

ISAKMP ヘッダのフィールドの定義は以下の通りである。

                         1                   2                   3
     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    !                          Initiator                            !
    !                            Cookie                             !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    !                          Responder                            !
    !                            Cookie                             !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    !  Next Payload ! MjVer ! MnVer ! Exchange Type !     Flags     !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    !                          Message ID                           !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    !                            Length                             !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       図 2:  ISAKMP ヘッダ形式

3.2 共通ペイロードヘッダ English

セクション3.4から3.16にかけて定義されている各 ISAKMP ペイロードの先頭には、図3のような、ペイロードを『つなぐ』機能を提供しペイロードの境界を明確に定義する、共通ペイロードヘッダがある。
                            1                   2                   3
        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       ! Next Payload  !   RESERVED    !         Payload Length        !
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                        図 3:  共通ペイロードへヘッダ

共通ペイロードヘッダの各フィールドは次のように定義されている。

3.3 データ属性 English

ISAQKMP 中のデータ属性を表わす必要がある場所には、いくつかのインスタンスがある。これの例としては、(セクション3.6で解説される) Transform ペイロード中にある SA 属性がある。DATA 属性は ISAKMP ペイロードではなく、ISAKMP ペイロード中に含まれるものである。データ属性の形式は多くの異なる種類の情報を表現出来るように柔軟性に富んでいる。ペイロード中には複数のデータ属性があってかまわない。データ属性の長さは4オクテットか属性長フィールドで定義される長さである。これは次に解説する属性形式を用いて得られる。各ドメインの属性についてのある情報は、例えば IPSec DOI [IPDOI] などの DOI のドキュメントで解説される。
                          1                   2                   3
      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     !A!       Attribute Type        !    AF=0  Attribute Length     !
     !F!                             !    AF=1  Attribute Value      !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     .                       AF=0  Attribute Value                   .
     .                       AF=1  未使用                            .
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                            図 4:  データ属性

データ属性の各フィールドは次のように定義される。

3.4 SA ペイロード English

SA ペイロードは SA をネゴシエーションとするためと、ネゴシエーションを行なう DOI と Situation を指示するために使われる。図5は、SA ペイロードの形式を示したものである。
                          1                   2                   3
      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ! Next Payload  !   RESERVED    !         Payload Length        !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     !              Domain of Interpretation  (DOI)                  !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     !                                                               !
     ~                           Situation                           ~
     !                                                               !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                            図 5:  SAペイロード

3.5 Proposal ペイロード English

Proposal ペイロードには、SA ネゴシエーションの間に使用される情報が含まれる。Proposal はセキュリティ機構つまり Transform からなり、通信チャネルを安全にするために使われる。図6は Proposal ペイロードの形式を示している。その使用法についてはセクション4.2で解説する。
                          1                   2                   3
      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ! Next Payload  !   RESERVED    !         Payload Length        !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     !  Proposal #   !  Protocol-Id  !    SPI Size   !# of Transforms!
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     !                        SPI (variable)                         !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                     図 6:  Proposalペイロード形式

Proposal ペイロードのフィールドは次のように定義される。

Proposal ペイロードの Payload Type の値は2である。

3.6 Transform ペイロード English

Tranform ペイロードは SA ネゴシエーションの間に使用される情報を含んでいる。Transform ペイロードは、特定のセキュリティ機構つまり Transform からなっており、通信チャネルを安全にするために使用される。Transform ペイロードには、特定の Transform に関連する SA 属性も含まれている。この SA 属性は DOI によって変わる。図7は Transform ペイロードを図示したものである。その使用法についてはセクション4.2で解説する。
                          1                   2                   3
      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ! Next Payload  !   RESERVED    !         Payload Length        !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     !  Transform #  !  Transform-Id !           RESERVED2           !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     !                                                               !
     ~                        SA Attributes                          ~
     !                                                               !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     図 7:  Transformペイロード形式

Transform ペイロードのペイロードタイプは3である。

3.7 鍵交換ペイロード English

鍵交換ペイロードは、様々な鍵交換技法をサポートしている。Oakley [Oakley]、Diffie-Hellman、X9.42 [ANSI] で解説される拡張 Diffie-Hellman 鍵交換、PGP で使用される RSA を元にした鍵交換などがその例である。図8は鍵交換ペイロードを図示したものである。
                          1                   2                   3
      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ! Next Payload  !   RESERVED    !         Payload Length        !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     !                                                               !
     ~                       Key Exchange Data                       ~
     !                                                               !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   図8:  鍵交換ペイロード形式

鍵交換ペイロードのペイローダタイプは4である。

3.8 ID ペイロード English

ID ペイロードには、ID データを交換するために使われる DOI 毎に異なるデータが含まれる。この情報は通信端点の ID の決定に使われ、さらに情報の素性の確認にも使われることがある。 図9は、ID ペイロードの形式を図示したものである。
                          1                   2                   3
      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ! Next Payload  !   RESERVED    !         Payload Length        !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     !   ID Type     !             DOI Specific ID Data              !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     !                                                               !
     ~                   Identification Data                         ~
     !                                                               !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       図9: IDペイロード形式

ID ペイロードのペイロードタイプは5である。

3.9 証明書ペイロード English

証明書ペイロードは、証明書やそれに付随する情報を ISAKMP 経由で転送し、ISAKMP メッセージ中に表れるようにするための手段を提供する。適切なディレクトリサービス (例えばSecure DNS [DNSSEC] ) を証明書の配送に使用出来ない場合、証明書ペイロードを含むべきである。証明書ペイロードは交換の間のいかなる時点でも受け入れなければならない図10は証明書ペイロードを図示したものである。

注意: 少数の証明書タイプしか存在しないだろうし、大抵の DOI はそれらすべてを受け入れるだろうと予測されるので、証明書タイプと形式は一般的に DOI と結びついてはない。

証明書ペイロードのフィールドは次のように定義される。

                          1                   2                   3
      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ! Next Payload  !   RESERVED    !         Payload Length        !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ! Cert Encoding !                                               !
     +-+-+-+-+-+-+-+-+                                               !
     ~                       Certificate Data                        ~
     !                                                               !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure 10:  Certificate Payload Format

証明書ペイロードのペイロードタイプは6である。

3.10 証明書要求ペイロード English

証明書要求ペイロードは ISAKMP のよって証明書を要求する手段を提供し、また任意のメッセージ中に表れることができる。証明書要求ペイロードには、適切なディレクトリサービスが (例えば Secure DNS [DNSSEC] ) を証明書の配送に使用出来ない場合、証明書要求ペイロードを含むべきである。証明書要求ペイロードは交換の間のいかなる時点でも受け入れなければならない。証明書要求ペイロードを受け取ったら自身の証明書を送らなければならない。複数の証明書を要求する場合には、複数の証明書要求ペイロードを送信すべきである図11は証明書要求ペイロードを図示したものである。
                          1                   2                   3
      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ! Next Payload  !   RESERVED    !         Payload Length        !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     !  Cert. Type   !                                               !
     +-+-+-+-+-+-+-+-+                                               !
     ~                    Certificate Authority                      ~
     !                                                               !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               図 11: 証明書要求ペイロード形式

証明書要求ペイロードのペイロードタイプは7である。

3.11 ハッシュペイロード English

ハッシュペイロードは、(SA 確立交換の間に選択される) ハッシュ関数を メッセージや ISAKMP 状態に適用して生成されたデータを含む。このペイロードは、ISAKMP メッセージ中のデータの統一性の検証やネゴシエーションするエンティティの認証に使用されうる。図12はハッシュペイロードを図示したものである。
                          1                   2                   3
      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ! Next Payload  !   RESERVED    !         Payload Length        !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     !                                                               !
     ~                           Hash Data                           ~
     !                                                               !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                      図 12:  ハッシュペイロード形式

訳注:原文ではここに次の一行があるべきであるがない。

証明書要求ペイロードのペイロードタイプは8である。

3.12 署名ペイロード English

署名ペイロードには、(SA 確立交換の間に選択された) デジタル署名関数によって生成されたデータが含まれる。ISAKMP メッセージ中のデータの統一性の検証に使われ、非拒否サービスでも使用されることがある。図13は署名ペイロードを図示したものである。
                          1                   2                   3
      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ! Next Payload  !   RESERVED    !         Payload Length        !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     !                                                               !
     ~                         Signature Data                        ~
     !                                                               !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    図 13:  署名ペイロード形式

署名ペイロードのペイロードタイプは9である。

3.13 Nonce ペイロード English

Nonce ペイロードには、交換の間に接続が生きていることを保証しリプレイ攻撃を防ぐために使われる、でたらめなデータが入っている。図14は Nonce ペイロードを図示したものである。ある鍵交換で Nonce が使用されると、その Nonce ペイロードの使用は鍵交換の指示によるものである。Nonce は鍵交換データの一部として送信される。しかしながら、これは ISAKMP ではなく鍵交換によって定義される。
                         1                   2                   3
      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ! Next Payload  !   RESERVED    !         Payload Length        !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     !                                                               !
     ~                            Nonce Data                         ~
     !                                                               !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                      図 14:  Nonceペイロード形式

Nonce ペイロードのペイロードタイプは10である。

3.14 通知ペイロード English

通知ペイロードには、ISAKMP と DOI 依存のデータの療法が含まれることがあり、ISAKMP の通信端へエラー状況などの告知データを送信するために使用される。一個の ISAKMP メッセージで複数の通知ペイロードを送ることが出来る。図15は通知ペイロードを図示したものである。

フェイズ1ネゴシエーションの間に起こった、もしくはそれに関連した通知は、ISAKMP ヘッダ中の開示側と反応側の Cookie 組で特定される。この場合、SAKMP ヘッダ中の Cookie 組がISAKMP SA を特定するので、プロトコルIDは ISAKMP であり、SPI は0となる。鍵情報の交換が完了する前に通知が発生した場合、通知は保護されない。

フェイズ2ネゴシエーションの間に起こった、もしくはそれに関連した通知は、ISAKMP ヘッダ中の開示側と反応側の Cookie 組と行なっているネゴシエーションに関連するメッセージ ID と SPI で特定される。この種の通知の例として、Proposal が拒絶された理由を通知するというものがある。

                          1                   2                   3
      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ! Next Payload  !   RESERVED    !         Payload Length        !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     !              Domain of Interpretation  (DOI)                  !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     !  Protocol-ID  !   SPI Size    !      Notify Message Type      !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     !                                                               !
     ~                Security Parameter Index (SPI)                 ~
     !                                                               !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     !                                                               !
     ~                       Notification Data                       ~
     !                                                               !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  図 15:  通知ペイロード形式

Nonce ペイロードのペイロードタイプは11である。

3.14.1 通知ペイロードタイプ English

通知される情報は、SA が確立出来なかったのはなぜかを示すエラーメッセージであることがある。SA データベースを管理するプロセスがが端点のプロセスに送ろうとする状態データの場合もある。例えば、安全なフロンとエンドつまりセキュリティゲートウェイが通知メッセージを SA 通信の同期をとるために使用することがある。次の表には通知メッセージとそれに対応する値が載っている。Private Use の範囲の値は、DOI に依存した値であることが期待されている。
通知メッセージ - エラータイプ
エラー
INVALID-PAYLOAD-TYPE 1
DOI-NOT-SUPPORTED 2
SITUATION-NOT-SUPPORTED 3
INVALID-COOKIE 4
INVALID-MAJOR-VERSION 5
INVALID-MINOR-VERSION 6
INVALID-EXCHANGE-TYPE 7
INVALID-FLAGS 8
INVALID-MESSAGE-ID 9
INVALID-PROTOCOL-ID 10
INVALID-SPI 11
INVALID-TRANSFORM-ID 12
ATTRIBUTES-NOT-SUPPORTED 13
NO-PROPOSAL-CHOSEN 14
BAD-PROPOSAL-SYNTAX 15
PAYLOAD-MALFORMED 16
INVALID-KEY-INFORMATION 17
INVALID-ID-INFORMATION 18
INVALID-CERT-ENCODING 19
INVALID-CERTIFICATE 20
CERT-TYPE-UNSUPPORTED 21
INVALID-CERT-AUTHORITY 22
INVALID-HASH-INFORMATION 23
AUTHENTICATION-FAILED 24
INVALID-SIGNATURE 25
ADDRESS-NOTIFICATION 26
NOTIFY-SA-LIFETIME 27
CERTIFICATE-UNAVAILABLE 28
UNSUPPORTED-EXCHANGE-TYPE 29
UNEQUAL-PAYLOAD-LENGTHS 30
RESERVED (Future Use) 31 - 8191
Private Use 8192 - 16383
通知メッセージ - 状態タイプK/TH>
状態
CONNECTED 16384
RESERVED (Future Use) 16385 - 24575
DOI-specific codes 24576 - 32767
Private Use 32768 - 40959
RESERVED (Future Use) 40960 - 65535

3.15 削除ペイロード English

削除ペイロードには、送信側が SA データベースから削除した、その結果もはや有効ではないプロトコル特有の SA ID が含まれる。図16は削除ペイロードを図示したものである。一つの削除ペイロードで複数の SPI を送ることも可能であるが、それらの SPI は同じプロトコルに対するものでなければならない。削除ペイロードにおいて複数のプロトコルを混在させてはならない。ISAKMP SA における削除には、ISAKMP の Protocol-ID を含み、SPI は、開始側と反応側の Cookie となる。ESP や AH などのプロトコル SA に関する削除では、そのプロトコルの Protocol-ID を含み(例、ESP、AH)、SPI は送信エンティティの SPI となる。

注意: 削除ペイロードは、反応側での SA の削除を要求するものではなく、開始側から反応側へのアドバイスである。飯能川が無視することにした場合、次回その SA を使用して飯能川から開始側への通信は失敗する。反応側は削除ペイロードに対して受け取り確認を行なうことが期待されている。

                          1                   2                   3
      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ! Next Payload  !   RESERVED    !         Payload Length        !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     !              Domain of Interpretation  (DOI)                  !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     !  Protocol-Id  !   SPI Size    !           # of SPIs           !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     !                                                               !
     ~               Security Parameter Index(es) (SPI)              ~
     !                                                               !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     図 16:  削除ペイロード形式

削除ペイロードの定義は以下の通りである。

削除ペイロードのペイロードタイプは 12 である。

3.16 ベンダ ID ペイロード English

ベンダ ID ペイロードには、ベンダが定義した定数が入る。ベンダがリモートにある彼等の実装を確認し認識するために、その定数は使用される。この機能によって、ベンダは互換性を保ったまま新しい機能を実験することが出来る。これは ISAKMP で一般に使われる拡張機能ではない。図17はベンダ ID ペイロードを図示したものである。

ベンダ ID ペイロードは、送信者が独自のペイロードタイプを送信すると告知するものではない。 Vendor ID を送信するベンダは、同様に ID を受け取るまで独自ペイロードについてなんらの仮定も持ってはならない。複数の Vendor ID ペイロードを送ってもよい。実装が Vendor ID を理解する必要はない。実装が Vendor ID を送る必要はまったくない。あらかじめそれを送ることについて同意せずに独自ペイロードを送った場合、規格を満足する実装は、INVALID-PAYLOAD-TYPE の通知メッセージとともに Proposal を拒絶すべきである。

ベンダ ID ペイロードが送られるなら、フェイズ1ネゴシエーションの間に送られるべきである。フェイズ1ネゴシエーションで理解出来るベンダ ID ペイロードを受け取った場合、実装は? セクション3.1のフェイズ 2 ネゴシエーションにおけるベンダ独自拡張で解説した、ライベート使用のペイロード (番号 128-255) を使用してもよい。標準化される前に、他社の拡張を実装したいベンダもあるだろう。だが、この実験は広く行なわれるべきではなく、代わりにベンダは標準化に向けて作業すべきである。

ベンダが定義する定数は他と異なるものでなければならない。ハッシュとハッシュするテキストの選択はベンタに任されている。例えば、製品名と製品のバージョンを含む文字列の平分の (暗号化されていない)ハッシュを取ることで Vendor ID を生成することも出来る。『推奨される』製品の一覧を持つことによるローカルの暗号ポリシー問題を避け、ベンダの一覧を管理せずにすまし、特定分野向けの製品がすべてのリストに載らずに済むようにするために、ハッシュをベンダレジストリの代わりに使用する。具体的には:
"Example Company IPsec. Version 97.1"
(引用符は含まない)の MD5file を使った場合の MD5 ハッシュは:
48544f9b1fe662af98b9b39e50c01a5aである。ベンダが使用するのはハッシュすべてでも、その一部でも構わない。ペイロードの大きさがデータの大きさを決める。このハッシュに対しては何のセキュリティも仮定されていないので、選択は自由である。

                          1                   2                   3
      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ! Next Payload  !   RESERVED    !         Payload Length        !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     !                                                               !
     ~                        Vendor ID (VID)                        ~
     !                                                               !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    図 17:  ベンダIDペイロード形式

ベンダIDペイロードの定義は以下の通りである。

ベンダ ID ペイロードのペイロードタイプは 13 である。

4 ISAKMP 交換 English

ISAKMP は、メッセージ交換の基礎文法を提供する。ISAKMP メッセージの基礎ブロックはセクション3で解説したペイロードタイプである。本セクションでは SA 確立と SA 変更の手続きについて、続けて初期相互運用性のために使用してもよい交換のデフォルトセットについて解説する。他の交換は DOI と鍵交換によって定義される。[IPDOI] と [IKE] はこれを行なうためにどうすればいいかの例である。追保 Bこれらの追加を達成するための手続きを声明している。

4.1 ISAKMP 交換タイプ English

ISAKMP は、SA と鍵情報の確立のための交換の作成を許している。ISAKMP では五種類のデフォルトの交換タイプが定義されている。セクションセクション4.4から4.8まではこれらの公開を解説する。交換は両端の間の通信における ISAKMP メッセージの内容と順序を定義する。ほとんどの交換はすべての基本ペイロードタイプ、SA、KE、ID、SIG を含み、他のものを含むこともある。交換タイプの一番違いはメッセージの並びと、各メッセージの中のペイロードの並びである。メッセージ中のペイロードの並びが決まったものでないとしても、処理の効率の点から SA ペイロードが交換の中で最初のペイロードであることが望ましい。交換内の各ペイロードの処理についてはセクション5で解説する。

セクション4.4から4.8に於いて、ISAKMP 交換のデフォルトセットを示す。これらの交換は交換それ自体と交換される情報に対して異なるセキュリティ保護を提供する。それぞれのセクションでの図は、各交換タイプ毎のメッセージだけでなく各メッセージ中のペイロードの順序を示し、書くメッセージ交換の後何が起こるかについて解説する基本ノートを提供する。例の中には証明書や証明書要求のような『オプション・ペイロード』を含んだものはない。付け加えて、妨害から保護する (開始側と反応側の Cookie を含む) ISAKMP ヘッダの初期交換を含んだものもない (セクション2.5.3参照)。定義された交換は、すべての DOI と鍵交換を満足するものではない。定義された交換が DOI の要求を満たすなら、説明の通りに使用出来る。定義された交換が DOI が定義するセキュリティ要求を満足しない場合は、DOI は新しい交換タイプと交換を成功させるペイロードの並び、そらにそのペイロードをどう組み立て解釈するかを指定しなければならない。すべての ISAKMP 実装は、Informational 交換を実装せねばならず、他の四つの交換を実装すべきである。しかしながら、これは DOI と関連する鍵交換プロトコルの定義に依存する。

ここまで解説してきたように、これらの交換タイプはネゴシエーションのどちらのフェイズにおいても使用出来る。しかしながら、それぞれのフェイズにおいて異なるセキュリティプロパティを提供することもある。これらの交換それぞれにおいて、Cookie と SPI フィールドの組み合わせが、交換がネゴシエーションの最初と二番目のフェイズで使用されるかを特定する。

4.1.1 表記法 English

意かの表記法を用い、次セクションからメッセージ形式および関連するペイロードを使って ISAKMP 交換タイプを説明する。

4.2 SA 交換確立 English

SA、Proposal、Transform ペイロードは、SA についてネゴシエーションし確立するための ISAKMP メッセージを組み立てるために使用される。SA 構築メッセージは、SA ペイロード一個の後ろに少なくとも一つ場合によっては何個でも Proposal ペイロードと、少なくとも一つ場合によっては何個でも Proposal ペイロードに関連する Transform ペイロードが続いたものである。これらのペイロードは一つのものと考えられるので、SA ペイロードは他の続くペイロードを指し、Proposal ペイロードは SA ペイロードの一部とみなす。SA ペイロードには、提示されるSA の DOI と Situation が含まれる。各 Proposal ペイロードには SPI を含み、SPI がInternet Security Architecture [SEC-ARCH] に従った Protocol-ID に関連することを保証する。Proposal ペイロードは同じ SPI を持っても持たなくてもよく、それは実装依存である。各Transform ペイロードには、目的のプロトコルのために使用される特定のセキュリティ機構を含む。Proposal と Transform ペイロードは、SA 確立ネゴシエーションの間だけ使用されることが期待されている。本セクションで解説する SA ネゴシエーションと確立のためのペイロードの作成は、この後のセクション4.4から4.8にあるすべての ISAKMP 交換に当てはまる。4.2.1にある例には、SA、Proposal、Transformペイロードだけしか載っており、ISAKMP 交換にあり得る他のペイロードは含んでいない。

Proposal ペイロードによって開始側エンティティは、反応側エンティティへネゴシエーションしている SA と共に使用されるセキュリティプロトコルと関連するセキュリティ機構を提示することが出来る。SA 確立ネゴシエーションが、複数のプロトコルをまとめた保護スートのためのものなら、それぞれが同じプロトコル番号を持つ複数の Proposal ペイロードがなければならない。それらの Proposal は一つのものとして扱わなければならず、異なるプロトコル番号を持つ Proposal で分断されてはならない。複数の Proposal ペイロードで同じプロトコル番号を使用することは、「プロトコル1かつプロトコル2」 というような論理 AND 演算となる。次の最初の例は、「 ESP AND AH 保護スート」 である。SA 確立ネゴシエーションが異なる保護スートへのものの場合、複数の Proposal ペイロードそれぞれが単調増加するプロトコル番号を持たなければならない。異なる Proposal は、開始側のパケットの中に 望ましい順に並ばなければならない。複数の Proposal ペイロードで異なるプロトコル番号を使うことは、「プロトコル1またはプロトコル2」 というような論理 OR 演算となる。このとき各 Proposal には二つ以上のプロトコルがあり得る。二番目の例は、「AH AND ESP 保護スート OR ESP 保護スート」である。Proposal ペイロード中の Next Payload フィールドは、(もしあれば)他の Proposal ペイロードを指すことに注意すること。Proposal ペイロードが存在することは、一つ以上の Transform ペイロードが存在することを意味する。

Transform ペイロードによって発信側エンティティは、反応側エンティティへあるプロトコルへの複数の機構つまり Transform を提示することが出来る。Proposal ペイロードは、どのプロトコルについてのサービスと機構がネゴシエーションされているのかを特定する。Transform ペイロードによって開始側エンティティは、そのプロトコルにおいてサポート可能な複数の Transform を提案出来る。ある Proposal ペイロードに関連する複数の Transform が、それぞれが別々の Transform ペイロード中で特定されることがあり得る。受け取り側のエンティティは Proposal 中の各プロトコル毎に一つの Transform を選ぶか、Proposal 全体を拒絶しなければならない。複数の Transform ペイロードにおいて Transform 番号を使用することで、 Transform1 OR Transform2 OR Transform3 のような、二番目のレベルでの OR 演算が得られる。次の例1は、ESP には二つの、AH には一つの使用可能な Transform が載っている。例2では、AH の Transform 一つ AND ESP の Transform 一つ、OR ESP に対してだけ Transform が二つである。Transform ペイロード中の Next Payload フィールドには、他の Transform か0が入ることに注意。Proposal ペイロードは異なる Proposal を記述する。

SA ペイロードへ反応する場合、反応側は複数の Proposal ペイロードとそれに関連する Transform ペイロードからなる、選んだ Proposal を持つ SA ペイロード送らなければならない。Proposal ペイロードそれぞれにはプロトコルに関連する一つの Transform ペイロードが含まれなければならない。反応側は、洗濯したプロトコルの Proposal ペイロード中の Proposal #フィールドと各 Transform ペイロード中の Transform #フィールドを保持すべきである。 Proposal と Transform 番号の保持によって、申し出たすべてのオプションについて反応側の選択と比較する必要がなくなるので、開始側のプロトコル処理が高速化されはずだ。これらの値によって、開始側は比較を直接すばやく行なうことが出来る。開始側は、反応側から受け取った SA ペイロードが先に送った Proposal の一つと一致することを確認すべきである

4.2.1 SA 確立例 English

この例では、異なる二つのプロトコルを組み合わせた保護の Proposal を示す。最初のプロトコルは提案側がサポートする二つの Transform からなっている。二番目のプロトコルは一つの Transform からなる。この Proposal の例は、3DES の Transform 1 と DES の Transform 2 を使う ESP からなるプロトコル1 AND SHA のTransform 1 を用いる AH のプロトコル2といった所だろう。反応側は ESP で提示された二つの Transform から 一つを選択しなければならない。その結果の保護スートは、反応側がどちらの ESP Transform を選んだかによって、(1) 3DES AND SHA か (2) DES AND SHA のいづれかになる。この交換は Base 交換を使っていることに注意。
                            1                   2                   3
        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
     /+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    / ! NP = Nonce    !   RESERVED    !         Payload Length        !
   /  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
SA Pay !                 Domain of Interpretation (DOI)                !
   \  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    \ !                           Situation                           !
      >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    / ! NP = Proposal !   RESERVED    !         Payload Length        !
   /  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Prop 1 ! Proposal # = 1!  Protocol-Id  !    SPI Size   !# of Trans. = 2!
Prot 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    \ !                         SPI (variable)                        !
      >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    / ! NP = Transform!   RESERVED    !         Payload Length        !
   /  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Tran 1 ! Transform # 1 ! Transform ID  !           RESERVED2           !
   \  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    \ !                         SA Attributes                         !
      >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    / ! NP = 0        !   RESERVED    !         Payload Length        !
   /  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Tran 2 ! Transform # 2 ! Transform ID  !           RESERVED2           !
   \  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    \ !                         SA Attributes                         !
      >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    / ! NP = 0        !   RESERVED    !         Payload Length        !
   /  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Prop 1 ! Proposal # = 1!  Protocol ID  !    SPI Size   !# of Trans. = 1!
Prot 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    \ !                         SPI (variable)                        !
      >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    / ! NP = 0        !   RESERVED    !         Payload Length        !
   /  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Tran 1 ! Transform # 1 ! Transform ID  !           RESERVED2           !
   \  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    \ !                         SA Attributes                         !
     \+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

選ばなければならない。二番目の Proposal を選ぶ場合、反応側は、ESP に対する Transform も二つから選ばなければならない。結果の保護スートは、(1) MD5 AND 3DES か、(2) DES または (3) 3DES のどちらかになる。

                            1                   2                   3
        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
     /+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    / ! NP = Proposal !   RESERVED    !         Payload Length        !
  /  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Prop 1 ! Proposal # = 1!  Protocol ID  !    SPI Size   !# of Trans. = 1!
Prot 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    \ !                         SPI (variable)                        !
      >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    / ! NP = 0        !   RESERVED    !         Payload Length        !
   /  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Tran 1 ! Transform # 1 ! Transform ID  !           RESERVED2           !
   \  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    \ !                         SA Attributes                         !
      >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    / ! NP = Proposal !   RESERVED    !         Payload Length        !
   /  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Prop 1 ! Proposal # = 1! Protocol ID   !    SPI Size   !# of Trans. = 1!
Prot 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    \ !                         SPI (variable)                        !
      >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    / ! NP = 0        !   RESERVED    !         Payload Length        !
   /  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Tran 1 ! Transform # 1 ! Transform ID  !           RESERVED2           !
   \  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    \ !                         SA Attributes                         !
      >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    / ! NP = 0        !   RESERVED    !         Payload Length        !
   /  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Prop 2 ! Proposal # = 2! Protocol ID   !    SPI Size   !# of Trans. = 2!
Prot 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    \ !                         SPI (variable)                        !
      >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    / ! NP = Transform!   RESERVED    !         Payload Length        !
   /  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Tran 1 ! Transform # 1 ! Transform ID  !           RESERVED2           !
   \  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    \ !                         SA Attributes                         !
      >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    / ! NP = 0        !   RESERVED    !         Payload Length        !
   /  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Tran 2 ! Transform # 2 ! Transform ID  !           RESERVED2           !
   \  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    \ !                         SA Attributes                         !
     \+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

4.3 SA変更 English

ISAKMP における SA 変更は、新しい SA を作成しその新しい SA で通信を開始することで達せられる。古い SA の削除は、新 SA が確立した後ならいつでも行なうことが出来る。古い SA を削除するかどうかは、ローカルのセキュリティポリシーによる。SA の変更を『新 SA の作成とそれに続く旧 SA の削除』なる手法で行なうのは、既存の SA 属性の修正の同期をとる際にあり得る脆さを避けるためである。新 SA 作成における保護については、セクション4.2に概説してある。SA 削除における保護については、セクション5.15に概説する。

ISAKMP SA (フェイズ1ネゴシエーション) の変更は、ISAKMP SA の作成と同じ手順によって行なう。二つの SA の間には何の関係もなく、セクション2.5.3で概説したように開始側と反応側の Cookie の組は異なるべきである

プロトコル SA (フェイズ2ネゴシエーション) の変更は、プロトコル SA の作成と同じ手順によって行なう。新 SA の作成は既存の ISAKMP SA によって保護される。二つのプロトコル SA の間には何の関係はない。プロトコルの実装では、新しく作られた SA は送り出しのトラフィックに使用開始すべきであり、入ってくるトラフィックに付いては古い SA が削除されるか新たに作られた SA の保護下でデータが送られてくるまでは、古い SA をサポートし続けるべきである。本セクションですでに述べたように、古い SA の削除はローカルのセキュリティポリシーによる。

4.4 SA 変更 English

Base 交換は、鍵交換と認証関連情報をお互いに送りあうことを目的に設計されている。鍵交換と認証関連情報を一つのメッセージにまとめることで、ID 保護が提供されない危険を冒すやり取りの数を減らす。ID は共有鍵が確立される前に前に ID は交換され、そしてそれゆえ ID の暗号化は不可能であるから、ID 保護は提供されない。次の図には Base 交換の例として、それで送られ得るペイロードを持つメッセージとそれぞれについての注意が載っている。
BASE交換
# 開始側 方向 反応側 注意
(1) HDR; SA; NONCE Begin ISAKMP-SA or Proxy negotiation
(2) HDR; SA; NONCE Basic SA agreed upon
(3) HDR; KE;
IDii; AUTH
Key Generated (by responder). Initiator Identity Verified by Responder
(4) HDR; KE;
IDir; AUTH
Responder Identity Verified by Initiator Key Generated (by initiator) SA established

最初のメッセージ(1)で、開始側はその状況下でトラフィックを保護するのに適していると考える Proposal を生成する。SA、Proposal、Transform ペイロードは (表記上) まとめられて SA ペイロードに入っている。生存確認とリプライ攻撃からの保護のための乱数情報も送られる。両者が提供する乱数情報は、交換の参加者の共有される証拠を提供する認証機構によって使用されるべきである。

二番目のメッセージ(2)で、反応側はそれが受け入れる保護スートを SA、roposal、Transform ペイロードによって指示する。再び、生存確認とリプライ攻撃からの保護のための乱数情報も送られる。両者が提供する乱数情報は、交換の参加者の共有される証拠を提供する認証機構によって使用されるべきである。受け入れられる保護スートがない場合の反応側の動作はローカルセキュリティポリシーによって決定される。可能性のある動作の一つは、Informational 交換に通知ペイロードを入れて送ることである。

三番目と四番目のメッセージで、発信側と反応側はそれぞれ、共有秘密と ID 情報として使用される鍵情報を交換する。この情報は同意された認証機能の保護の下に送信される。これらのメッセージで起こったエラーに対する動作はローカルセキュリティポリシーが決定する。可能性のある動作の一つは、Informational 交換に通知ペイロードを入れて送ることである。

4.5 ID 保護交換 English

ID 保護交換は、ID と認証関連情報から鍵交換情報を分離するために設計された。ID と認証関連情報から鍵交換を分離することで、追加の二つのメッセージを代償に ID の通信に保護を提供する。すでに確立されている共有秘密の保護の下で ID が交換される。次の図には、ID 保護交換の例として、それで送られ得るペイロードを持つメッセージとそれぞれについての注意が載っている。
ID保護交換
# 開始側 方向 反応側 注意
(1) HDR; SA Begin ISAKMP-SA or Proxy negotiation
(2) HDR; SA Basic SA agreed upon
(3) HDR; KE; NONCE
(4) HDR; KE; NONCE Key Generated (by Initiator and Responder)
(5) HDR*; IDii; AUTH Initiator Identity Verified by Responder
(6) HDR*; IDir; AUTH Responder Identity Verified by Initiator SA established

最初のメッセージ(1)で、開始側はその状況下でトラフィックを保護するのに適していると考える Proposal を生成する。SA、Proposal、Transformペイロードは (表記上) まとめられて SA ペイロードに入っている。

二番目のメッセージ(2)で、反応側はそれが受け入れる保護スートを SA、roposal、Transformペイロードによって指示する。受け入れられる保護スートがない場合の反応側の動作はローカルセキュリティポリシーによって決定される。可能性のある動作の一つは、Informational 交換に通知ペイロードを入れて送ることである。

三番目と四番目のメッセージで、発信側と反応側はそれぞれ、共有秘密として使用される鍵情報と生存確認とリプライ攻撃からの保護のために使われる乱数情報を交換する。両者が提供する乱数情報は、交換の参加者の共有される証拠を提供する認証機構によって使用されるべきである。これらのメッセージで起こったエラーに対する動作はローカルセキュリティポリシーが決定する。可能性のある動作の一つは、Informational 交換に通知ペイロードを入れて送ることである。

五番目(5)と六番目(6)のメッセージで、開始側と反応側はそれぞれ、ID 情報と同意した認証機能の結果を交換する。この情報は共有秘密の保護の下で送信される。これらのメッセージで起こったエラーに対する動作はローカルセキュリティポリシーが決定する。可能性のある動作の一つは、Informational 交換に通知ペイロードを入れて送ることである。

4.6 認証単独交換 English

認証単独交換は、認証に関連する情報のみを送信するために設計された。この交換の利点は、鍵計算というコストなしで認証だけを実行することが出来ることである。ネゴシエーション中にこの交換使う場合、送信される情報は一切暗号化されない。しかしながら、それ以外の場所では情報が暗号化される場合もある。例えば、ネゴシエーションの最初のフェーズで暗号化が決まっおり、認証単独交換がネゴシエーションの二番目のフェイズで実行される場合、最初のフェイズでネゴシエーションされた ISAKMP SA によってによって認証単独交換は暗号化される。次の図には、認証単独交換の例として、それで送られ得るペイロードを持つメッセージとそれぞれについての注意が載っている。
認証単独交換
# 開始側 方向 反応側 注意
(1) HDR; SA; NONCE Begin ISAKMP-SA or Proxy negotiation
(2) HDR; SA; NONCE;
IDir; AUTH
Basic SA agreed upon Responder Identity Verified by Initiator
(3) HDR; IDii; AUTH Initiator Identity Verified by Responder SA established

最初のメッセージ(1)で、開始側はその状況下でトラフィックを保護するのに適していると考える Proposal を生成する。SA、Proposal、Transform ペイロードは (表記上) まとめられて SA ペイロードに入っている。生存確認とリプライ攻撃からの保護のための乱数情報も送られる。両者が提供する乱数情報は、交換の参加者の共有される証拠を提供する認証機構によって使用されるべきである。

二番目のメッセージ(2)で、反応側はそれが受け入れる保護スートを SA、roposal、Transform ペイロードによって指示する。再び、生存確認とリプライ攻撃からの保護のための乱数情報も送られる。両者が提供する乱数情報は、交換の参加者の共有される証拠を提供する認証機構によって使用されるべきである。それに加えて、反応側は ID 情報も送信する。これらの情報のすべては同意した認証機能の保護の下で送信される。受け入れられる保護スートがない場合の反応側の動作はローカルセキュリティポリシーによって決定される。可能性のある動作の一つは、Informational 交換に通知ペイロードを入れて送ることである。

三番目のメッセージ(3)で、開始側は ID 情報を送信する。この情報のすべては同意した認証機能の保護の下で送信される。これらのメッセージで起こったエラーに対する動作はローカルセキュリティポリシーが決定する。可能性のある動作の一つは、Informational 交換に通知ペイロードを入れて送ることである。

4.7 Aggressive 交換 English

Aggressive 交換は、SA、鍵交換、認証関連ペイロードをまとめて送るために設計された。SA、鍵交換、認証慣例情報を一つのメッセージにまとめることで、ID 保護が提供されないやり取りの回数を減らす。ID 保護が提供されない危険を冒すやり取りの数を減らす。ID は共有鍵が確立される前に前に ID は交換され、そしてそれゆえ ID の暗号化は不可能であるから、ID 保護は提供されない。次の図には Aggressive 交換の例として、それで送られ得るペイロードを持つメッセージとそれぞれについての注意が載っている。
Aggressive交換
# 開始側 方向 反応側 注意
(1) HDR; SA; KE;
NONCE; IDii
Begin ISAKMP-SA or Proxy negotiation and Key Exchange
(2) HDR; SA; KE;
NONCE; IDir; AUTH
Initiator Identity Verified by Responder Key Generated Basic SA agreed upon
(3) HDR*; AUTH Responder Identity Verified by Initiator SA established

最初のメッセージ(1)で、開始側はその状況下でトラフィックを保護するのに適していると考える Proposal を生成する。SA、Proposal、Transform ペイロードは (表記上) まとめられて SA ペイロードに入っている。Aggressive 交換が動作するためには、Proposal と Transform はどちらもただ一つだけしか (選択の余地無く) 置くことが出来ない。共有秘密となる鍵関連情報と、生存確認とリプライ攻撃からの保護のための乱数情報も送られる。両者が提供する乱数情報は、交換の参加者の共有される証拠を提供する認証機構によって使用されるべきである。加えて、開始側は ID 情報も送信する。

二番目のメッセージ(2)で、反応側はそれが受け入れる保護スートを SA、roposal、Transform ペイロードによって指示する。共有秘密としか使われる鍵関連情報と、生存確認とリプライ攻撃からの保護のための乱数情報も送られる。両者が提供する乱数情報は、交換の参加者の共有される証拠を提供する認証機構によって使用されるべきである。それに加えて、反応側は ID 情報も送信する。これらの情報のすべては同意した認証機能の保護の下で送信される。受け入れられる保護スートがない場合の反応側の動作はローカルセキュリティポリシーによって決定される。可能性のある動作の一つは、Informational 交換に通知ペイロードを入れて送ることである。

三番目のメッセージ(3)で、開始側は同意した認証機能の結果を送信する。この情報のすべては同意した認証機能の保護の下で送信される。これらのメッセージで起こったエラーに対する動作はローカルセキュリティポリシーが決定する。可能性のある動作の一つは、Informational 交換に通知ペイロードを入れて送ることである。

4.8 Informational 交換 English

Informational 交換は、SA 管理に使用出来る情報の一方向送信のために設計されている。次の図には Informational 交換の例として、それで送られ得るペイロードを持つメッセージとそれぞれについての注意が載っている。
Informational交換
# 開始側 方向 反応側 注意
(1) HDR*; N/D Error Notification or Deletion

最初のメッセージ(1)で、開始側/反応側は ISAKMP 通知もしくは削除ペイロードを送信する。

ISAKMP フェイズ1ネゴシエーションにおける鍵関連情報の交換の前に Infomational 交換が発生した時は、Infomational 交換に対しては何の保護も提供されない。鍵関連情報が交換または ISAKMP SA が確立されたなら、Infomational 交換は鍵関連情報か ISAKMP SA の保護の下で保護されなければならない

すべての交換は、その始まりにおいて暗号同期が起こらねばならない点でよく似ている。Infomational 交換は交換であって ISAKMP メッセージではない。つまり、Infomational 交換に対する Message ID (MID) の生成は、他の継続している通信の IV とは独立に行なうべきである。これによって、既存の通信に対しての暗号同期が管理されることが確実になり、Infomational 交換が正しく処理されることになる。これの唯一の例外は、ISAKMP ヘッダ中のCommit Bit がセットされた場合である。Commit Bit がセットされると、Infomational 交換のMessage ID フィールドには新しい Message ID (MID) ではなく、元々の ISAKMP フェイズ2 SA ネゴシエーションの Message ID が入らなければならない。これは、CONNECTED 通知メッセージが入った Informational 交換が正しいフェイズ2 SA と関連付けられることを保証するためである。Commit Bit についての解説については、セクション3.1を参照。

 

5 ISAKMP ペイロード処理 English

セクション3では ISAKMP ペイロードについて説明した。これらのペイロードはセクション4で解説した交換で使用され、また DOI で定義された交換でも使用される。本セクションでは各ペイロードの処理について解説する。またイベントのシステム監査ログへの記録についても提案する。この動作はシステムセキュリティポリシーによって制御され、つまりは提案の範疇を出るものではない。

5.1 共通メッセージ処理 English

すべての ISAKMP メッセージにたいして、プロトコルの信頼性を確認し、DoS やリプレイ攻撃などの危険を最小限にするための基本的な処理を行なう。すべての処理には、受け取ったパケットが少なくとも ISAKMP ヘッダにあるものと同じかどうかのパケット長の確認をするべきである。ISAKMP メッセージ長と ISAKMP ヘッダの Payload Length フィールドの値が一致しない場合は、ISAKMP メッセージは拒絶しなければならない。(開始側、反応側問わず) 受信側エンティティは以下の動作を行なわなければならない
  1. UNEQUALE-PAYLOAD-LENGTHS (ペイロード長不一致) のイベントは 適切なシステム監査ファイルに記録してもよい
  2. UNEQUAL-PAYLOAD-LENGTHS メッセージメッセージタイプを含む通知ペイロードを持つ Informational 交換を送信元エンティティに送ってもよい。この動作はシステムセキュリティポリシーで記述する。

ISAKMP メッセージを送る際に、(開始側、反応側問わず) 送信側エンティティは以下を行なわなければならない

  1. タイマをセットしリトライ・カウンタを初期化する。

    注意: 実装は固定タイマを使用してはならない。そうではなく、ラウンドとリップ・タイムを計測し、それに基づいてタイマの値を動的に調整するべきである。付け加えて、同一パケットの再送が続く場合は、タイマの値を増加して間隔を取るべきである(例、指数的速度低下)。

  2. タイマがきれたら、ISAKMP メッセージを再送し、リトライ・カウンタを減らす。
  3. リトライ・カウンタが0になったら、RETRY LIMIT REACHED イベントを、適切なシステム監査ファイルに記録してもよい
  4. ISAKMP プロトコル機械のすべての状態を消去し、IDLEに戻す。

5.2 ISAKMP ヘッダ処理 English

ISAKMP メッセージを作成する時、(開始側、反応側問わず) 送信側エンティティは以下の手順で行なわなければならない
  1. 正しい Cookie を作成する。詳細についてはセクション2.5.3を参照。
  2. セッションに関連するセキュリティ特性を決定する (例、DOI と Situation)。
  3. セクション3.1で解説したフィールドから ISAKMP ヘッダを構築する。
  4. 交換のタイプに応じて他のペイロードを構築する。
  5. セクション5.1で解説したように、目的のホストにメッセージを送信する。

ISAKMP メッセージを受け取った時、(開始側、反応側問わず) 受信側エンティティは以下の手順にしたがわなければならない

  1. 開始側と反応側の Cookie を確認する。Cookie 確認が失敗したら、メッセージを廃棄し次の行動を取る。
    1. INVALID COOKIE イベントを適切なシステム監査ファイルに記録してもよい
    2. INVALID-COOKIE メッセージメッセージタイプを含む通知ペイロードを持つ Informational 交換を送信元エンティティに送ってもよい。この動作はシステムセキュリティポリシーで記述する。
  2. 正しいことを確認するために Next Payload フィールドを調べるもし Next Payload フィールドが正しくなかったなら、メッセージを廃棄し次のの行動を取る。
    1. INVALID NEXT PAYLOAD イベントを適切なシステム監査ファイルに記録してもよい
    2. INVALID-PAYLOAD-TYPE メッセージメッセージタイプを含む通知ペイロードを持つ Informational 交換を送信元エンティティに送ってもよい。この動作はシステムセキュリティポリシーで記述する。
  3. Major VersionとMinor Version フィールドを調べ正しいことを確認する (A HREf="#3.1">3.1参照。Version フィールドが正しくなかったなら、メッセージを廃棄し次のの行動を取る。
    1. INVALID ISAKMP VERSION イベントを適切なシステム監査ファイルに記録してもよい
    2. INVALID-MAJOR-VERSION もしくは INVALID-MINOR-VERSION メッセージメッセージタイプを含む通知ペイロードを持つ Informational 交換を送信元エンティティに送ってもよい。この動作はシステムセキュリティポリシーで記述する。
  4. Exchange Type フィールドを調べ正しいことを確認する。 Excahnge Type フィールドが正しくなかったなら、 メッセージを廃棄し次のの行動を取る。
    1. INVALID EXCHANGE TYPE イベントを適切なシステム監査ファイルに記録してもよい
    2. INVALID-EXCHANGE-TYPE メッセージタイプを含む通知ペイロードを持つ Informational 交換を送信元エンティティに送ってもよい。この動作はシステムセキュリティポリシーで記述する。
  5. Flags フィールドを調べ正しいことを確認する。Flags フィールドが正しくなかったなら、メッセージを廃棄し次のの行動を取る。
    1. INVALID FLAGS イベントを適切なシステム監査ファイルに記録してもよい
    2. INVALID-FLAGS 含む通知ペイロードを持つ Informational 交換を送信元エンティティに送ってもよい。この動作はシステムセキュリティポリシーで記述する。
  6. Message ID フィールドを調べ正しいことを確認する。Message ID フィールドが正しくなかったなら、メッセージを廃棄し次のの行動を取る。
    1. INVALID MESSAGE ID イベントを適切なシステム監査ファイルに記録してもよい
    2. INVALID-MESSAGE-ID 含む通知ペイロードを持つ Informational 交換を送信元エンティティに送ってもよい。この動作はシステムセキュリティポリシーで記述する。
  7. Next Payload フィールドの値を用いて、ISAKMP メッセージの処理を継続する。

5.3 共通ペイロードヘッダ処理 English

セクション3.4から3.15で解説した ISAKMP ペイロードのどれかを作成する時、それらのペイロードの先頭には共通ペイロードヘッダが置かれる。共通ペイロードヘッダを作成する時、(開始側、反応側問わず)送信側エンティティは以下の手順で行なわなければならない
  1. 次のペイロードの値を Next Payload フィールドに置く。その値についてはセクション3.1で解説している。
  2. RESERVED フィールドには 0 を置く。
  3. ペイロードの長さを Payload Length フィールドに置く。
  4. 本セクションの残りの解説にしたがってペイロードを構築する。

ISAKMP メッセージを受け取った時、(開始側、反応側問わず) 受信側エンティティは以下の手順に従わなければならない。

  1. Next Payload フィールドを調べ正しいことを確認する。Next Payload フィールドが正しくなかったなら、メッセージを廃棄し次のの行動を取る。
    1. INVALID NEXT PAYLOAD イベントを適切なシステム監査ファイルに記録してもよい
    2. INVALID-PAYLOAD-TYPE メッセージタイプを含む通知ペイロードを持つ Informational 交換を送信元エンティティに送ってもよい。この動作はシステムセキュリティポリシーで記述する。
  2. RESERVED フィールドを調べ正しいことを確認する。RESERVED フィールドが正しくなかったなら、メッセージを廃棄し次のの行動を取る。
    1. INVALID RESERVED FIELD イベントを適切なシステム監査ファイルに記録してもよい
    2. BAD-PROPOSAL-SYNTAN か PAYLOAD-MALFORMED メッセージタイプを含む通知ペイロードを持つ Informational 交換を送信元エンティティに送ってもよい。 この動作はシステムセキュリティポリシーで記述する。
  3. Next Payload フィールドの値を用いて、ペイロードの処理を継続する。

5.4 SA ペイロード処理 English

SA ペイロードを作成する時、(開始側、反応側問わず) 送信側エンティティは以下の手順に従わなければならない。
  1. ネゴシエーションを実行する DOI (Domain Of Interpretation) を決定する。
  2. 決定した DOI でネゴシエーションを実行する Situation を決定する。
  3. Situation での Proposal と Transform を決定する。これらについてはそれぞれセクション3.53.6で解説している。
  4. SA ペイロードを構築する。
  5. セクション5.1で解説した、受信側エンティティにメッセージを送信する。

SA ペイロードを受信した時、(開始側、反応側問わず) 受信側エンティティは以下の手順に従わなければならない。

  1. 受け取った DOI をサポートしているかどうかを調べる。DOI をサポートしていなかったなら メッセージを廃棄し次のの行動を取る。
    1. INVALID DOI イベントを適切なシステム監査ファイルに記録してもよい
    2. DOI-NOT-SUPPORTED メッセージタイプを含む通知ペイロードを持つ Informational 交換を送信元エンティティに送ってもよい。この動作はシステムセキュリティポリシーで記述する。
  2. 与えられた Situation が保護可能かどうかを調べる。もし Situation が保護不可能であったなら、メッセージを廃棄し次のの行動を取る。
    1. INVALID SITUATION イベントを適切なシステム監査ファイルに記録してもよい
    2. SITUATION-NOT-SUPPORTED メッセージタイプを含む通知ペイロードを持つ Informational 交換を送信元エンティティに送ってもよい。この動作はシステムセキュリティポリシーで記述する。
  3. SA ペイロードの残りのペイロード (例、Proposal、Transform) を処理する。(セクション5.55.6で解説する) SA Proposal を受け入れられない場合は、以下の行動を取る。
    1. INVALID PROPOSAL イベントを適切なシステム監査ファイルに記録してもよい
    2. NO-PROPOSAL-CHOOSEN メッセージタイプを含む通知ペイロードを持つ Informational 交換を送信元エンティティに送ってもよい。この動作はシステムセキュリティポリシーで記述する。

5.5 Proposal ペイロード処理 English

Proposal ペイロードを作成する場合、(開始側、反応側問わず) 送信側エンティティは以下の手順に従わなければならない。
  1. この Proposal のプロトコルを調べる。
  2. このプロトコルに対して提示するProposal の個数と各 Proposal に対する Transform の個数を調べる。Transform についてはセクション3.6で解説した。
  3. ユニークな擬似乱数 SPI を生成する。
  4. Proposal ペイロードを構築する。

Proposal ペイロードを受信した時、(開始側、反応側問わず) 受信側エンティティは以下の手順に従わなければならない。

  1. プロトコルをサポートしているかどうか調べる。 プロトコルをサポートしていなかったなら ペイロードを廃棄し次のの行動を取る。
    1. INVALID PROTOCOL イベントを適切なシステム監査ファイルに記録してもよい
    2. DOI-PROTOCOL-ID メッセージタイプを含む通知ペイロードを持つ Informational 交換を送信元エンティティに送ってもよい。この動作はシステムセキュリティポリシーで記述する。
  2. SPI が正しいかを調べる。SPI が正しくなかったなら、ペイロードを廃棄し次のの行動を取る。
    1. INVALID SPI イベントを適切なシステム監査ファイルに記録してもよい
    2. INVALID-SPI メッセージタイプを含む通知ペイロードを持つ Informational 交換を送信元エンティティに送ってもよい。この動作はシステムセキュリティポリシーで記述する。
  3. Proposal が セクション3.54.2で解説されているとおりになっていることを確認する。 Proposal が正しく構成されていない時は、以下の行動を取る。
    1. BAD PROPOSAL SYNTAX や INVALID PROPOSAL などありえるイベントを適切なシステム監査ファイルに記録してもよい
    2. BAD-PROPOSAL-SYNTAX や PAYLOAD-MALFORMED メッセージタイプを含む 通知ペイロードを持つ Informational 交換を送信元エンティティに送ってもよい。この動作はシステムセキュリティポリシーで記述する。
  4. Next Payload フィールドの値に従って、Proposal と Transform ペイロードを処理する。これらのペイロードの処理の例がセクション4.2.1にある。

5.6 Transform ペイロード処理 English

Transform ペイロードを作成する時、(開始側、反応側問わず) 送信側エンティティは以下の手順に従わなければならない。
  1. この Transform の Transform # を調べる。
  2. この Proposal に提示する Transform の数を調べる。Transform についてはセクション3.6で解説してある。
  3. Transform ペイロードを構築する。

Transform ペイロードを受信した時、(開始側、反応側問わず) 受信側エンティティは以下の手順に従わなければならない。

  1. その Transform をサポートしているかを調べる。Transform-ID フィールドに含まれる値が未知のものであった時は、その Transform ペイロードを無視しなければならず、INVALID TRANSFORM イベントを発生してはならない。Transform-ID が正しくない時は、メッセージを廃棄し以下の行動を取る。
    1. INVALID TRANSFORM  イベントを適切なシステム監査ファイルに記録してもよい
    2. INVALID-TRANSFORM-ID メッセージタイプを含む通知ペイロードを持つ Informational 交換を送信元エンティティに送ってもよい。この動作はシステムセキュリティポリシーで記述する。
  2. Transform がセクション3.64.2で解説されているとおりになっていることを確認する。 Transform が正しく構成されていない時は、以下の行動を取る。
    1. BAD PROPOSAL SYNTAX や INVALID TRANSFORM などありえるイベントを適切なシステム監査ファイルに記録してもよい
    2. BAD-PROPOSAL-SYNTAX や PAYLOAD-MALFORMED や  ATTRIBUTES-NOT-SUPPORTED メッセージタイプを含む通知ペイロードを持つ Informational 交換を送信元エンティティに送ってもよい。この動作はシステムセキュリティポリシーで記述する。
  3. 続く Transform と Proposal を、Next Payload フィールドの定義にしたがって処理する。これらのペイロードの処理の例がセクション4.2.1にある。

5.7 鍵交換ペイロード処理 English

鍵交換ペイロードを作成する時、(開始側、反応側問わず) 送信側エンティティは以下の手順に従わなければならない。
  1. DOI で定義される通りに、使用される鍵交換ペイロードを調べる。
  2. DOI で定義されている鍵交換データフィールドの使用法を調べる。
  3. 鍵交換ペイロードを構築する。
  4. セクション5.1で解説したように、受信エンティティへメッセージを送信する。

鍵交換ペイロードを受信した時、(開始側、反応側問わず) 受信側エンティティは以下の手順に従わなければならない。

  1. 受け取った鍵交換をサポートしているかを調べる。その鍵交換をサポートしていなかったならメッセージを廃棄し次のの行動を取る。
    1. INVALID KEY INFORMATION イベントを適切なシステム監査ファイルに記録してもよい
    2. INVALID-KEY-INFORMATION メッセージタイプを含む通知ペイロードを持つ Informational 交換を送信元エンティティに送ってもよい。この動作はシステムセキュリティポリシーで記述する。

5.8 ID ペイロード処理 English

ID ペイロードを作成する時、(開始側、反応側問わず) 送信側エンティティは以下の手順に従わなければならない。
  1. DOI (場合によっては Situation) で定義される、使用されるID情報を調べる。
  2. DOI で定義される、ID データフィールドの使用法を調べる。
  3. ID ペイロードを構築する。
  4. セクション5.1で解説したように、受信エンティティへメッセージを送信する。

ID ペイロードを受信した時、(開始側、反応側問わず) 受信側エンティティは以下の手順に従わなければならない。

  1. ID タイプをサポートしているかどうかを調べる。DOI と Situation に基づくことになるだろう。 ID をサポートしていないならメッセージを廃棄し次のの行動を取る。
    1. INVALID ID INFORMATION イベントを適切なシステム監査ファイルに記録してもよい
    2. INVALID-ID-INFORMATION メッセージタイプを含む通知ペイロードを持つ Informational 交換を送信元エンティティに送ってもよい。この動作はシステムセキュリティポリシーで記述する。

5.9 証明書ペイロード処理 English

証明書ペイロードを作成する時、(開始側、反応側問わず) 送信側エンティティは以下の手順に従わなければならない。
  1. 使用する証明書エンコードを調べる。これは DOI で指定されている場合もある。
  2. 既存の証明書が、証明書エンコーディングで定義される形式になっていることを確認する。
  3. 証明書ペイロードを構築する。
  4. セクション5.1で解説したように、受信エンティティへメッセージを送信する。

証明書ペイロードを受信した時、(開始側、反応側問わず) 受信側エンティティは 以下の手順に従わなければならない。

  1. 証明書のエンコーディングをサポートしているかどうか調べる。証明書エンコーディングをサポートしていないならメッセージを廃棄し次のの行動を取る。
    1. INVALID CERTIFICATE TYPE イベントを適切なシステム監査ファイルに記録してもよい
    2. INVALID-CERT-ENCODING メッセージタイプを含む通知ペイロードを持つ Informational 交換を送信元エンティティに送ってもよい。この動作はシステムセキュリティポリシーで記述する。
  2. 証明書データを処理する。証明書の内容や形式がが正しくない場合、ペイロードを廃棄し次のの行動を取る。
    1. INVALID CERTIFICATE イベントを 適切なシステム監査ファイルに記録してもよい
    2. INVALID-CERTIFICATE メッセージタイプを含む通知ペイロードを持つ Informational 交換を送信元エンティティに送ってもよい。 この動作はシステムセキュリティポリシーで記述する。

5.10 証明書要求ペイロード処理 English

証明書要求ペイロードを作成する時、(開始側、反応側問わず) 送信側エンティティは以下の手順に従わなければならない。
  1. 使用する証明書エンコードを調べる。これは DOI で指定されている場合もある。
  2. (そうしたいなら)認証を要求する認証局で受け入れ可能なものの名前を調べる。
  3. 証明書要求ペイロードを構築する。
  4. セクション5.1で解説したように、受信エンティティへメッセージを送信する。

証明書要求ペイロードを受信した時、(開始側、反応側問わず) 受信側エンティティは以下の手順に従わなければならない。

  1. 証明書のエンコーディングをサポートしているかどうか調べる。証明書エンコーディングが正しくないならペイロードを廃棄し次のの行動を取る。
    1. INVALID CERTIFICATE TYPE イベントを適切なシステム監査ファイルに記録してもよい
    2. INVALID-CERT-ENCODING メッセージタイプを含む通知ペイロードを持つ Informational 交換を送信元エンティティに送ってもよい。この動作はシステムセキュリティポリシーで記述する。

    証明書エンコーディングをサポートしていないならペイロードを廃棄し次のの行動を取る。

    1. CERTIFICATE TYPE UNSUPPORTED イベントを適切なシステム監査ファイルに記録してもよい
    2. CER-TYPE-UNSUPPORTED メッセージタイプを含む通知ペイロードを持つ Informational 交換を送信元エンティティに送ってもよい。この動作はシステムセキュリティポリシーで記述する。
  2. 指定された証明書エンコーディングに対して、証明局をサポートしているかどうかを調べる。証明局が正しくないか軽視が間違っているならペイロードを廃棄し次のの行動を取る。
    1. CERTIFICATE UNAVAILABLE イベントを適切なシステム監査ファイルに記録してもよい
    2. CER-UNAVAILABLE メッセージタイプを含む通知ペイロードを持つ Informational交換を送信元エンティティに送ってもよい。この動作はシステムセキュリティポリシーで記述する。

5.11 ハッシュペイロード処理 English

ハッシュペイロードを作成する時、(開始側、反応側問わず) 送信側エンティティは以下の手順に従わなければならない。
  1. SA ネゴシエーションで定義された、ハッシュ関数を調べる。
  2. DOI で定義されている、ash Data フィールドの使用法を調べる。
  3. ハッシュペイロードを構築する。
  4. セクション5.1で解説したように、受信エンティティへメッセージを送信する。

ハッシュペイロードを受信した時、(開始側、反応側問わず) 受信側エンティティは以下の手順に従わなければならない。

  1. 指定されたハッシュをサポートしているか調べる。ハッシュをサポートしていない場合、 メッセージを廃棄し次のの行動を取る。
    1. INVALID HASH INFORMATION イベントを適切なシステム監査ファイルに記録してもよい
    2. INVALID-HASH-INFORMATION メッセージタイプを含む通知ペイロードを持つ Informational 交換を送信元エンティティに送ってもよい。この動作はシステムセキュリティポリシーで記述する。
  2. DOI と鍵交換プロトコル文書で定義されている通りにハッシュ関数を実行する。ハッシュが失敗した場合、メッセージを廃棄し次のの行動を取る。
    1. INVALID HASH VALUE イベントを適切なシステム監査ファイルに記録してもよい
    2. AUTHENTICATION-FAILED メッセージタイプを含む通知ペイロードを持つ Informational 交換を送信元エンティティに送ってもよい。この動作はシステムセキュリティポリシーで記述する。

5.12 署名ペイロード処理 English

署名ペイロードを作成する時、(開始側、反応側問わず) 送信側エンティティは以下の手順に従わなければならない。
  1. SA ネゴシエーションで定義された使用する署名関数を調べる。
  2. DOI で定義されている Signature Dataフィールドの使用法を調べる。
  3. 署名ペイロードを構築する。
  4. セクション5.1で解説したように、受信エンティティへメッセージを送信する。

署名ペイロードを受信した時、(開始側、反応側問わず) 受信側エンティティは以下の手順に従わなければならない。

  1. 署名をサポートしているか調べる。署名をサポートしていない場合は、メッセージを廃棄し次のの行動を取る。
    1. INVALID SIGNATURE INFORMATION イベントを適切なシステム監査ファイルに記録してもよい
    2. INVALID-SIGNATURE メッセージタイプを含む通知ペイロードを持つ Informational 交換を送信元エンティティに送ってもよい。この動作はシステムセキュリティポリシーで記述する。
  2. DOI と鍵交換プロトコル文書で定義されている通りに署名関数を実行する。関数が失敗した場合、メッセージを廃棄し次のの行動を取る。
    1. INVALID SIGNATURE VALUE イベントを適切なシステム監査ファイルに記録してもよい
    2. AUTHENTICATION-FAILED メッセージタイプを含む通知ペイロードを持つ Informational 交換を送信元エンティティに送ってもよい。この動作はシステムセキュリティポリシーで記述する。

5.13 Nonce ペイロード処理 English

Nonce ペイロードを作成する時、(開始側、反応側問わず) 送信側エンティティは以下の手順に従わなければならない。
  1. Nonce として使用するユニークな乱数値を生成する。
  2. Nonce ペイロードを構築する。
  3. セクション5.1で解説したように、受信エンティティへメッセージを送信する。

Nonce ペイロードを受信した時、(開始側、反応側問わず) 受信側エンティティは以下の手順に従わなければならない。

  1. 特に決められた Nonce ペイロードを扱う手順はない。交換タイプ (そして DOI と鍵交換の記述) によって手順は定義される。

5.14 通知ペイロード処理 English

通信の間にエラーが起こることはあり得ることである。通知ペイロードを持つ Informational 交換によって、プロトコル処理中にエラーが発生したことを他端に知らせる制御された方法が得られる。通知ペイロードを既存の交換に追加するのではなく、独立した Informational 交換で送ることを強く勧める

通知ペイロードを作成する時、(開始側、反応側問わず) 送信側エンティティは以下の手順に従わなければならない。

  1. 通知する DOI を調べる。
  2. 通知するプロトコル ID を調べる。
  3. プロトコル ID フィールドに基づいて SI Size を調べる。異なるプロトコルは異なる SPI Size を持つので、このフィールドは必要である。例えば、ISAKMP は開始側と反応側の Cookie をまとめて SPI とするが、ESP と AH では SPI の大きさは4オクテットである。
  4. 伝えたいエラーや状態メッセージにしたがって通知メッセージタイプを調べる。
  5. この通知に関連する SPI を調べる。
  6. 追加の Notification Data を含めるかどうか調べる。この追加情報は DOI によって決められている。
  7. 通知ペイロードを構築する。
  8. セクション5.1で解説したように、受信エンティティへメッセージを送信する。

通知ペイロードを持つ Informational 交換は片方向通信であるので再送は行なわれない。継続するための手続きについてはローカルセキュリティポリシーで記述する。しかしながら、受信エンティティによって NOTIFICATION PAYLOAD ERROR イベントを適切なシステム監査ファイルに記録するよう勧める

ISAKMP フェイズ1ネゴシエーションにおける鍵関連情報の交換の前に Infomational 交換が発生した時は、Infomational 交換に対しては何の保護も提供されない。鍵関連情報が交換または ISAKMP SA が確立されたなら、Infomational 交換は鍵関連情報か ISAKMP SA の保護の下で保護されなければならない

通知ペイロードを受信した時、(開始側、反応側問わず) 受信側エンティティは以下の手順に従わなければならない。

  1. Informational 交換に何か保護が行なわれているかを ISAKMP ヘッダの Encryption Bit と Authentication Only Bit を調べて確認する。Encryption Bit がセットされていたら、つまり Informational 交換は暗号化されていたら、メッセージを (確立中または後の) ISAKMP SA を使って復号しなければならない。復号がすんだら、以下に説明するように処理を継続出来る。Authentication Only Bit がセットされていたら、メッセージは (処理中または後の) ISAKMP SA を使用して認証しなければならない。認証がすめば、以下に説明するように処理を継続出来る。Informational 交換が暗号化も認証もされていないなら、ペイロード処理は以下に説明するように継続出来る。
  2. DOI をサポートしているか調べる。DOI をサポートしていない場合は、ペイロードを廃棄し以下の行動を取る。
    1. INVALID DOI イベントを適切なシステム監査ファイルに記録してもよい
  3. Protocol-ID をサポートしているか調べる。もし Protocl-ID をサポートしていないなら、 ペイロードを廃棄し以下の行動を取る。
    1. INVALID PROTOCOL-ID イベントを適切なシステム監査ファイルに記録してもよい
  4. SPI が正しいかを調べる。SPI が正しくなかったなら、ペイロードを廃棄し次のの行動を取る。
    1. INVALID SPI イベントを適切なシステム監査ファイルに記録してもよい
  5. 通知メッセージタイプが正しいか調べる。通知メッセージ対が正しくなかったら、ペイロードを廃棄し次のの行動を取る。
    1. INVALID MESSAGE TYPE イベントを適切なシステム監査ファイルに記録してもよい
  6. 通知ペイロードを、追加 Notification Data も含めて処理し、ローカルセキュリティポリシーにしたがって適切な動作を行なう。

5.15 削除ペイロード処理 English

通信中にホストが脅かされたり送信中に情報を横取りされる可能性がある。これが起こったかどうかを確認することは簡単なことではなく、本文の範疇を外れる。しかしながら、脅かされている通信ことが判ったら、新しい SA を確立し現在の SA を削除する必要がある。

削除ペイロードを持つ Informational 交換によって、送信エンティティが SA を削除したことを他端に知らせる制御された方法が得られる。SA の削除は常に ISAKMP SA の保護の下で実行されなければならない。受信エンティティはローカルSA データベースをきれいにしなければならない。しかしながら、削除メッセージを受信したら、削除ペイロードの SPI フィールドに並ぶ SA を送信エンティティとの間で使用することは出来ない。安全な通信を再確立するためにSA確立手続きを起動しなければならない。

削除ペイロードを作成する時、(開始側、反応側問わず) 送信側エンティティは以下の手順に従わなければならない。

  1. 削除の DOI を調べる。
  2. 削除の Protocol-ID を調べる。
  3. プロトコル ID フィールドに基づいてSI Size を調べる。異なるプロトコルは異なる SPI Size を持つので、このフィールドは必要である。例えば、ISAKMP は開始側と反応側の Cookie をまとめて SPI とするが、ESP と AH では SPI の大きさは4オクテットである。
  4. このプロトコルで削除する SPI の個数を調べる。
  5. 削除に関係する SPI を調べる。
  6. 削除ペイロードを構築する。
  7. セクション5.1で解説したように、受信エンティティへメッセージを送信する。

削除ペイロードを持つ Informational 交換は片方向通信であるので再送は行なわれない。継続するための手続きについてはローカルセキュリティポリシーで記述する。しかしながら、受信エンティティによって NOTIFICATION PAYLOAD ERROR イベントを適切なシステム監査ファイルに記録するよう勧める

先に述べたように、削除ペイロードを持つ Informational 交換は ISAKMP SA の保護の下で送信されなければならない

証明書ペイロードを受信した時、(開始側、反応側問わず) 受信側エンティティは以下の手順に従わなければならない。

  1. Informational 交換は何らかのセキュリティサービス (例、Auth-Only SA による認証、他の交換での暗号化) によって 保護されているので、メッセージには ISAKMP SA を使って、これらのセキュリティサービスを適用しなければならない。セキュリティサービスの処理が終わったら、以下に説明するように処理を継続出来る。削除ペイロード中の情報をチェックしてセキュリティサービス処理で起こるエラーは明白である。セキュリティサービス処理でのエラーの結果に対してとる動作はローカルセキュリティポリシーに記述すべきである
  2. DOI がサポートされているか調べる。DOI が差ボーとされていなかったら、ペイロードを廃棄し次のの行動を取る。
    1. INVALID DOI イベントを適切なシステム監査ファイルに記録してもよい
  3. Protocol-ID をサポートしているか調べる。 もし Protocl-ID をサポートしていないなら、 ペイロードを廃棄し以下の行動を取る。
    1. INVALID PROTOCOL-ID イベントを適切なシステム監査ファイルに記録してもよい
  4. 削除ペイロード中にある各 SPI ごとに正しいかを調べる。SPI が正しくなかったなら、ペイロードを廃棄し次のの行動を取る。
    1. INVALID SPI イベントを適切なシステム監査ファイルに記録してもよい
  5. 削除ペイロードを処理しローカルセキュリティポリシーにしたがって適切な動作を行なう。 先に述べたように、適切な動作の一つはローカル SA データベースの片づけを含むべきである

 

6 まとめ English

ISAKMP (Internet Security Association and Key Management Protocol) は、将来の Internet を対象に注意深く設計されている。Internet の量的成長はネットワーク使用率、通信、セキュリティ要求、セキュリティ機構に大きな変化をもたらすだろう。ISAKMP にはこの動的で拡大しつつある通信環境で必要となるすべての特徴が含まれる。

ISAKMP の SA 機能は認証と鍵確立と組になって、将来の成長と変化に必要となる安全性と柔軟性を提供する。複数の鍵交換技法、暗号アルゴリズム、認証機構、セキュリティサービス、 セキュリティ属性によって、利用者は自分のネットワーク、通信、セキュリティの必要性に見合った安全性を選ぶことが出来る。SA 特徴により利用者は他の利用者との間でセキュリティ要求について指定しネゴシエーションすることが出来る。一つのプロトコルで複数の技法をサポートすることにより追加される利点として、新しい技法が開発されたらそれを簡単にプロトコルに追加出来る点がある。これによって、Internet セキュリティサービスの成長の道が開かれる。ISAKMP は、SA を公開と非公開療法で定義することをサポートしているため、行政、商業、個人的な通信にとって理想的なものとなっている。

ISAKMP には、複数のセキュリティプロトコルとアプリケーションで SA を確立する能力がある。プロトコルとアプリケーションは、セッション指向であってもそうでなくてもよい。複数のセキュリティプロトコルをサポートする SA 確立プロトコルがあることで、二つ以上のセキュリティプロトコルが使用されたり必要だったりする時でも 、複数の大変よく似た認証、鍵交換 SA 確立プロトコルを不要にした。Internet にとって安全性が現実のものとなるなら、Internet のネットワーク層を提供してきた IP とまったく同じように、共通のセキュリティ確立プロトコルが必要となる。ISAKMP は、すべてのセキュリティプロトコルが相互運用するための共通の基礎を提供する。

ISAKMP は良いセキュリティ設計原理に基づいてる。他の非安全なトランスポートプロトコルと対になっておらず、それゆえそれは他のプロトコルへの攻撃によって使用不可になったり弱められたりしない。またより安全なトランスポートプロトコルが開発されれば、ISAKMP は簡単にそれに統合出来る。ISAKMP はまたプロトコルへの攻撃からの保護も提供する。保護によって、攻撃者との間ではなく望む相手との SA と鍵を確立することが保証される。

また ISAKMP は良いプロトコル設計原理に基づいている。IPv6 の設計原理を真似て、プロトコル特有の情報はプロトコルヘッダだけである。プロトコルが運ぶデータは機能ペイロードに分離される。Internet の成長と発展に従って、プロトコル全体を変更することなく新しいセキュリティ機能をサポートする新しいペイロードを追加縁o来る


A ISAKMP SA属性 English

A.1 背景/理論 English

前のセクションで詳しく述べたように、ISAKMP は、SA と暗号鍵の確立と管理のための柔軟で拡張出来るフレームワークを提供するように設計されている。ISAKMP 似よって得られるフレームワークは、ヘッダとペイロード定義、メッセージとペイロード交換を方向づける交換タイプ、基本処理ガイドラインからなる。認証され秘匿性のある方法で ISAKMP は SA と暗号鍵を確立するために使用される機構については定義しない。機構の定義とそのアプリケーションは DOI の役割である。

本セクションでは、Internet IP Security DOI (IPsec DOI) での ISAKMP 値、サポートするプロトコル、ISAKMP フェイズ1ネゴシエーションでの ID 値について解説する。IPsec DOI は IP Security の実装する上で必須である。[Oakley] と [IKE] が、詳細に IP Security のためのSAと暗号鍵の確立と管理の 機構とその上のアプリケーションについて解説している。

A.2 IPsec DOI 割り当て値 English

[IPDOI] で解説されているように、IPsec DOI に割り当てられた値は1である。

A.3 サポートするセキュリティプロトコル English

サポートするセキュリティプロトコルの値は、最新の『割り当て番号』 RFC [STD-2] で指定されている。次の表に載っているのは、Internet IPsec DOI のために ISAKMP がサポートするセキュリティプロトコルの値である。
プロトコル割り当て値
RESERVED 0
ISAKMP 1

すべての DOI は Protocol-ID 1 を ISAKMP の為に予約しなければならない。DOI 中の他のセキュリティプロトコルに対しては順に番号を振る。

セキュリティプロトコルの 2 から 15359 の値は、将来の使用のために IANA によって予約済みである。値 15360 から 16383 は、相互に同意している実装間でのプライベートな使用のために、永続的に予約されている。このプライベートな値は異なる実装間では相互運用性がないことになる。

A.4 ISAKMP ID タイプ値 English

次の表に載っているのは基本フェイズ 1 交換中の ID ペイロードで使用されるIDタイプに割り当てられた値であり、特定のプロトコルのためのものではない。
IDタイプ
ID_IPV4_ADDR 0
ID_IPV4_ADDR_SUBNET 1
ID_IPV6_ADDR 2
ID_IPV6_ADDR_SUBNET 3

A.4.1 ID_IPV4_ADDR English

ID_IPV4_ADDR タイプは 4 オクテットの IPv4ア ドレス一個を指定する。

A.4.2 ID_IPV4_ADDR_SUBNET English

ID_IPV4_ADDR_SUBNET タイプは、二つの 4 オクテットの値からなり、IPv4 アドレスの範囲を指定する。最初の値は IPv4 アドレスである。二番目の値は IPv4 ネットワークマスクである。ネットワークマスクの中の 1 の部分は、対応するアドレスのビットが固定されていることを示し、0 は『任意』ビットであることを示す。

A.4.3 ID_IPV6_ADDR English

ID_IPV6_ADDR タイプは 16 オクテットの IPv6 アドレス一個を指定する。

A.4.4 ID_IPV6_ADDR_SUBNET English

ID_IPV6_ADDR_SUBNET タイプは、二つの 16 オクテットの値からなり、IPv6 アドレスの範囲を指定する。最初の値は IPv6 アドレスである。二番目の値は IPv6 ネットワークマスクである。ネットワークマスクの中の 1 の部分は、対応するアドレスのビットが固定されていることを示し、0 は『任意』ビットであることを示す。

B 新 DOI の定義 English

Internet DOI は、Internet コミュニティの大部分で必要とされるセキュリティ要求を満足させるかもしれない。がしかし、あるグループでは、多分異なる暗号アルゴリズムの追加するためとか、ホスト ID やユーザ ID とは異なるものに基づいてセキュリティ関連の決定を下したいとかの理由で、DOI のある部分、についてカスタマイズを必要とするかもしれない。また、特定グループが、マルチキャストグループでの鍵管理をサポートするような、新しい交換タイプを必要とするかもしれない。

本セクションでは、新しく DOI を定義するうえでのガイドラインについて解説する。Internet DOI の完全な仕様は [IPDOI] にある。

新しく DOI を定義することは時間のかかる作業である。可能であるならばであるが、設計者が既存の DOI から始めて、受け入れられない部分だけをカスタマイズすることを勧める。

設計者が一から始めるつもりなら、以下のことは定義しなければならない


B.1 Situation English

Situation は通信チャネルをどう保護するかを決定するための基礎となる。SA で適応される保護の種類と強度を調べるために使用されるすべてのデータ含まなければならない。例えば、合衆国国防省 DOI では、非公開アルゴリズムを使用し、ネゴシエーションする特別な属性を持つだろう。これらの追加のセキュリティ属性は Situation に含まれる。

B.2 セキュリティポリシー English

セキュリティポリシーは、どの種類の情報を分類し保護しなければならないかを定義する。ネゴシエーションする両者は他方が Situation を理解し送信と蓄積両方で正しく情報を保護することを信頼しなければならないので、DOI はサポートするセキュリティポリシーの集合について定義しなければならない。例えば、ネゴシエーションする両者は、『独自情報』成る用語について、それをどう保護するかネゴシエーションする前にその意味について同意しなければならない。

要求されるセキュリティポリシーを DOI に含めることは、策化するホストがそれらのポリシーを全システムにおいて理解し実装するよう指示するだけである。

B.3 名前付け体系 English

DOI は、暗号アルゴリズム、認証局などについての一貫した方法を定義しなければならない。 通常、これは IANA 名前付け規則に幾分かの独自拡張を加えたものを使用して行なわれる。

B.4 セキュリティサービス指定の文法 English

エンティティの名前付け方法を簡単に指定することに加えて、DOI はその Situation でどうトラフィックを保護するかについての完全な Proposal の形式を指定しなければならない。

B.5ペイロード仕様 English

DOI は、各ペイロードタイプの形式を指定しなければならない。ISAKMP には、いくつかのペイロードタイプにおいて(認証ペイロード中の認証局や鍵交換ペイロード中の鍵交換IDなど)すべての DOI で存在しなければならないフィールドが存在する。

B.6 新交換タイプの定義 English

基本交換タイプが DOI での要求を満たすには十分ではないなら、設計者は DOI ごとにさらに30個の交換タイプを定義することが出来る。設計者は未使用の交換タイプ値を選び、ISAKMP ペイロードタイプの連なりを構成するメッセージの並びを定義することで新交換タイプを作成出来る。

新交換タイプは使用不可能性について厳格に分析しなければならないことに注意。これは高価なうえにその保証は心もとないので、絶対に必要な時以外、新交換タイプは作成するべきではない。


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

暗号分析技術は、着実なペースで進歩している。絶え間ない処理速度の向上によって、計算不能性暗号攻撃はより現実のものとなっている。新暗合アルゴリズムと公開鍵生成技法の開発も同様に着実に進んでいる。新しいセキュリティサービスと機構の開発は加速している。多くのセキュリティサービスと機構から選択し、機構が要求する属性を交換する首尾一貫した手法は、Internet の複雑な構造で安全を守るためには重要である。しかしながら、一つの暗号化アルゴリズム、鍵交換技法、セキュリティ機構に固執するシステムは、時が経るにつれて仕様不可能となる危険性が増していく。

UDP は信頼性のないデータグラムプロトコルであり、そのゆえ ISAKMP でのその使用はいくつかのセキュリティについての考慮点をもたらしている。UDP は信頼性が無いが、鍵管理プロトコルは信頼できなければならないので、信頼性は ISAKMP に組み込まれている。ISAKMP はそのトランスポート機構として UDP を使用するが、その処理において UDP 情報 (例、チェックサム、長さ) にはまったく頼らない。

ISAKMP の開発において考慮すべき別の問題は、プロトコルに対するファイアウォールの効果である。多くのファイアウォールはすべての UDP パケットを遮断するので、ある種の環境では UDP はあてに出来ない。

数多くの非常に重要なセキュリティ上の考慮点が [SEC-ARCH] に載っている。その一つをここでも取り上げよう。一旦プライベートセッション鍵を作成したら、それは安全に保存しなければならない。内部と外部からののアクセスからプライベート鍵を正しく保護出来ないと、IP セキュリティサービスが提供するどんな保護も完全に無力と化す。

IANA についての考慮 English

本ドキュメントには、IANA が管理している、たくさんの 「魔法の (magic)」 数値が出てくる。このセクションでは、これらの一覧それぞれに数値を追加割当するために IANA が使う分野について説明する。 これまでのセクションで明示的に定義したもの以外のすべての値は、IANA で予約済みである。

Domain of Interpretation : DOI English

DOI は、SAネゴシエーションが行なわれる Domain (領域) を特定する 32 ビットのフィールドである。新しい DOI の割り当ての要求は、その Domain の使用を解説した標準化トラック (standards-track) RFC によらなければならない。

サポートするセキュリティプロトコル English

ISAKMP は、SA ネゴシエーションと鍵管理を 多くのセキュリティプロトコルに提供するよう設計されている。追加するセキュリティプロトコルの ID の要求は、そのセキュリティプロトコルについてと ISAKMP との関係を説明した 標準化トラック (standards-track) RFC によらなければならない。

 

謝辞 English

CISCO Systems の Dan Harkins、Dave Carrel、Derrell Piper は、[IKE] と [IPDOI] ドキュメントのプロトコルとの設計補助とコーディネートを行なってくれた。Oakley 鍵交換プロトコルを通じて、Hilarie Orman は ISAKMP の設計にとても大きな影響を与えた。Marsha Gross、Bill Kutz、Milke Oehler、Pete Sell、Ruth Taylor は、本ドキュメントに対してとても大きな提供とレビューを行なった。Scott Carlson は、ISAKMP プロトコルと共に使用するための TIS DNSSEC プロトコルを FreeBSD 上に移植した。Jeff Turner と Steve Smalley は、ESP と AH のプロトタイプ開発と統合に貢献した。Mike Oehler と Pete Sell は他の ISAKMP 実装との間での相互運用性試験を行なった。SPARTA, Inc. の Carl Muckenhirn の LaTeX の補助に対して感謝する。

 

参考文献

[ANSI] ANSI, X9.42: Public Key Cryptography for the Financial Services Industry -- Establishment of Symmetric Algorithm Keys Using Diffie-Hellman, Working Draft, 1996年 4月 19日.
 
[BC] Ballardie, A., and J. Crowcroft, Multicast-specific Security Threats and Countermeasures, Proceedings of 1995 ISOC Symposium on Networks & Distributed Systems Security, pp. 17-30, Internet Society, San Diego, CA, 1995年 2月.
 
[Berge] Berge, N.,
"UNINETT PCA Policy Statements",
RFC 1875, 1995年 12月.
 
[CW87] Clark, D.D. and D.R. Wilson, A Comparison of Commercial and Military Computer Security Policies, Proceedings of the IEEE Symposium on Security & Privacy, Oakland, CA, 1987年, pp. 184-193.
 
[DNSSEC] D. Eastlake III, Domain Name System Protocol Security Extensions, Work in Progress.
 
[DOW92] Diffie, W., M.Wiener, P. Van Oorschot, Authentication and Authenticated Key Exchanges, Designs, Codes, and Cryptography, 2, 107-125, Kluwer Academic Publishers, 1992年.
 
[IAB] Bellovin, S.,
"Report of the IAB Security Architecture Workshop",
RFC 2316, 1998年 4月.
 
[IKE] Harkins, D., and D. Carrel,
"The Internet Key Exchange (IKE)",
RFC 2409, 1998年 11月.
 
[IPDOI] Piper, D.,
"The Internet IP Security Domain of Interpretation for ISAKMP",
RFC 2407, 1998年 11月.
 
[Karn] Karn, P., and B. Simpson, Photuris: Session Key Management Protocol,
Work in Progress.
 
[Kent94] Steve Kent,
IPSEC SMIB, e-mail to ipsec@ans.net, 1994年 8月 10日.
 
[Oakley] Orman, H.,
"The Oakley Key Determination Protocol",
RFC 2412, 1998年 11月.
 
[RFC-1422] Kent, S.,
"Privacy Enhancement for Internet Electronic Mail: Part II: Certificate-Based Key Management",
RFC 1422, 1993年 2月.
 
[RFC-1949] Ballardie, A.,
"Scalable Multicast Key Distribution",
RFC 1949, 1996年 5月.
 
[RFC-2093] Harney, H., and C. Muckenhirn,
"Group Key Management Protocol (GKMP) Specification",
RFC 2093, 1997年 7月.
 
[RFC-2094] Harney, H., and C. Muckenhirn,
"Group Key Management Protocol (GKMP) Architecture",
RFC 2094, 1997年 7月.
 
[RFC-2119] Bradner, S., "Key Words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, 1997年 3月.
 
[Schneier] Bruce Schneier, Applied Cryptography - Protocols, Algorithms, and Source Code in C (Second Edition), John Wiley & Sons, Inc., 1996年.
 
[SEC-ARCH] Atkinson, R., and S. Kent,
"Security Architecture for the Internet Protocol",
RFC 2401, 1998年 11月.
 
[STD-2] Reynolds, J., and J. Postel,
"Assigned Numbers",
STD 2, RFC 1700, 1994年 10月.
下記も参照。:
http://www.iana.org/numbers.html

 

著者のアドレス

Douglas Maughan
National Security Agency
ATTN: R23
9800 Savage Road
Ft. Meade, MD. 20755-6000
電話: 301-688-0847
EMail: wdm@tycho.ncsc.mil

Mark Schneider
National Security Agency
ATTN: R23
9800 Savage Road
Ft. Meade, MD. 20755-6000
電話: 301-688-0851
EMail: mss@tycho.ncsc.mil

Mark Schertler
Securify, Inc.
2415-B Charleston Road
Mountain View, CA 94043
電話: 650-934-9303
EMail: mjs@securify.com

Jeff Turner
RABA Technologies, Inc.
10500 Little Patuxent Parkway
Columbia, MD. 21044
電話: 410-715-9399
EMail: jeff.turner@raba.com

 

著作権表記全文

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.