| ネットワーク WG Request for Comments： 2407 分類： スタンダードトラック |
D. Piper Network Alchemy 1998年11月 |
IPsec における ISAKMP の解釈
(The Internet IP Security Domain of Interpretation for ISAKMP)
このメモの位置付け
Englishこのメモは、インターネットコミュニティにおけるインターネット標準化手順を規定するとともに、改善のための議論や提案を求めるものである。 このプロトコルの標準化段階と状態については、最新の "Internet Official Protocol Standards"(STD 1) を参照して欲しい。このメモの配布には制限を設けない。
著作権
表記 EnglishCopyright (C) The Internet Society (1988). All Rights Reserved.
IESG ノート
Englishセクション4.4.4.2では、 「IPSEC DOI の実装においては必ず ESP_DES をサポートしなければならない…」と なっている。最近の暗号学の分野における研究から、多くのアプリケーションにとって、DESの強度は十分ではないことが判ってきた。そのため、近い将来、IETFは、必須暗号としての ESP_DES の使用を停止する可能性が高い。プロトコルのオプションとしては残すことになるだろう。まだ、IPsecワーキンググループとIETFは、(セキュリティと性能について考慮された)置き換えるアルゴリズムを大筋としても決定していないが、実装者は、セクション4.4.4.3で勧めているESP_3DESを心に留めておくといいだろう。
1. 概要
EnglishInternet Security Association and Key Management Protocol (ISAKMP) は、インターネットにおける SA (Security Association) 管理と暗号化キー確立を定義している。このフレームワークは、定義済みの鍵交換、ペイロード、ある Domain Of Interpretation (DOI) 内で発生する処理についてのガイドラインからなっている。このドキュメントでは、Internet IP Security DOI (IPSEC DOI) を定義する。これは、IPがSAをネゴシエイトするためにISAKMPを使う場合において、IPとともに使用できるようISAKMPを具体化したものである。
IPSEC DOI の以前の版から変更点は、セクション7に まとめられている。
2. はじめに
EnglishISAKMPを使ってSAをネゴシエイトする、関連しあったプロトコルをまとめるために、Domain of Interpretation (DOI) を使用する。DOIを共有するセキュリティプロトコルは、共通の名前空間からセキュリティプロトコルと暗号化変換方式を選び、鍵交換プロトコルIDを共有する。
最終的に、ISAMKP は、DOI 定義に加えて以下のものを要求する。
- DOI 固有のプロトコルIDのネーミングスキームを定義する
- 状況 (Situation) フィールドの解釈を定義する
- 受け入れ可能なセキュリティポリシーの集合を定義する
- DOI 固有のSA属性 (Phase II) の文法を定義する
- DOI 固有のペイロードコンテンツの文法を定義する
- 必要なら、Key Excahnge の種類に追加し定義する。
- 必要なら、Notification Message の種類に追加し定義する。
本文の残りの部分は、協調するホストシステムとファイアウォール間を流れるIPパケットに 認証、統一性、秘匿性を提供するために、IP Security(IPSEC) プロトコルを使用するための、先の要求項目の具体化についての詳細な解説である。
IPSEC 全体を通しての記述については、[ARCH]、[AH]、[ESP]を参照。
「しなければならない」、「してはならない」、「要求されている」、「することになる」、「することはない」、「する必要がある」、「しないほうがよい」、「推奨される」、「してもよい」、「選択できる」、本文中のある、これらのキーワードの意味は[RFC 2119]に解説されている。
ISAKMPでは、全てのDOIは、"Assigned Number" RFC [STD-2] にある、IANAに登録されなければならない。Internet IP Security DOI (IPSEC DOI) の、IANA Assinged Number は1である。IPSEC DOIにおいても、全ての well-known (公知) なIDは、IPSEC DOI の下位情報として、IANAに登録されなければならない。IPSEC DOI の IANAレジストリに関連する情報については、セクション6を参照のこと。
全てのマルチオクテットな 2進値は、ネットワークバイトオーダである。
ISAKMPでは、Situation (状況) は、レスポンダ (着呼側) が 受け取ったSA要求をどう処理するかについての、ポリシーを定めるために使用できる情報を提供する。IPSEC DOI においては、Situation フィールドは、4オクテットのビットマスクであり、以下の値を取る。
Situation 値 SIT_IDENTITY_ONLY 0x01 SIT_SECRECY 0x02 SIT_INTEGRITY 0x04
SIT_IDENTITY_ONLY は、関連する Identification Payload 中にある発信元ID情報によって、SA を確認することを指定する。 各ID についての詳細な解説は、セクション4.6.2にある。 少なくともフェイズ1 Oakley 交換 ([IKE], セクション5) の Identification Payload の一つを含むようにすることによって、全てのIPSEC DOIの実装は、IT_IDENTITY_ONLYをサポートしなければならず、さらに Identification Payload を含まないすべてのアソシエーション確立を中断しなければならない。
イニシエータ(発呼側)が、SIT_SECRECY と SIT_INTEGRITY をともにサポートしない場合、Situation は、4オクテットちょうどの Situation ビットマップだけからなり、Labeled Domain IDフィールド (図1、セクション4.6.1) やそれに続くラベル情報を含まない。逆に、イニシエータが SIT_SECRECY か SIT_INTEGRIRY をサポートする場合は、Labeled Domain IDがSituation Payload に含まれなければならない。
SIT_SECRECY は、ネゴシエーション中の SA が、ラベル付けされたセキュリティが必要な環境中にあることを示している。Situation ビットマップ中に SIT_SECRECY があった場合、Situation フィールドには、センシティブティレベルとコンパートメントビットマスクが入った可変長のデータが続く。SA ペイロード形式についての詳細な解説は、セクション4.6.1を参照。
イニシエータが SIT_SECRECY をサポートしない場合、SIT_SECRECY は Situtaion ビットマップ中に設定されてはならず、また秘密レベルやカテゴリビットマップも含まれないほうがよい。
レスポンダが SIT_SECRECY をサポートしない場合は、SITUATION-NOT-SUPPORTED 通知ペイロードを返すべきであり、SA の確立は中止されなければならない。
SIT_INTEGRITY は、ネゴシエーション中のSA が、ラベルが付いたインテグリティを必要とする環境中にあることを示している。Situation ビットマップ中に SIT_INTEGRITY があった場合、Situation フィールドには、インテグリティレベルとコンパートメントビットマスクが入った、可変長のデータが続く。SA ペイロード形式についての詳細な解説は、セクション4.6.1を参照。
イニシエータが SIT_INTEGRITY をサポートしない場合、SIT_INTEGRIRY は Situtaion ビットマップ中に設定されてはならず、またインテグリティレベルやカテゴリビットマップも含まれないほうがよい。
レスポンダが SIT_INTEGRIRY をサポートしない場合は、SITUATION-NOT-SUPPORTED 通知ペイロードを返すべきであり、SA の確立は中止されなければならない。
IPSEC DOI では、実装いて、特定のセキュリティポリシーは強要されない。 ホストシステムのポリシー問題は、本ドキュメントの範囲外のものである。
だが、続くセクションでは、IPSEC DOI のホスト実装の設計で考慮すべき、いくつかの問題について触れる。基本的に本セクションについては、概論であるものとして読むこと。
ISAKMPを実装することを選ぶ多くのシステムでは、統合されたIKE鍵管理デーモンを実行する保護ドメインを提供することが、目標となることが予測される。保護モードを持つマルチユーザOSの元では、鍵管理デーモンは、特権プロセスとして独立して存在することになるだろう。
そのような環境では、TCP/IPカーネルに鍵要素を組み込めるような API を構成することが望ましい。IPセキュリティアーキテクチャは、ホストTCP/IPカーネルと鍵管理機能との間に、特定のストラクチャ、流れを要求しない。
固定鍵を実装するホストシステムは、それがIPSECから直接使用されるものであっても、認証目的 ([IKE] セクション5.4参照) のためのものであっても、それが保護されたメモリ領域の外にあったり、TCP/IPカーネルで使用中である場合にも、固定鍵要素を保護するような手順を踏むべきである。
例えば、ラップトップコンピュータ上で使用するならば、個人のパスワードで暗号化する設定ファイルに固定鍵を保存する人もいるだろう。
使用するOSとインストールされるユーティリティソフトによって変わるが、固定鍵をTCP/IPカーネルに渡してしまうと、もう保護することが出来ないということもあるだろう。だが、システムの起動時に、さらなる認証なしで簡単に再生できるようなことがあってはならない。
一晩でIPSECへの移行が済むと考えるのは現実的ではない。ホストシステムが どのシステムと安全に話す必要があり、どのシステムから安全に話される必要があるを記載した、融通のきくポリシーリストを用意しなければならない。プロキシ ファイアウォールのアドレスについての注意書きも必要だろう。
最小限、IPアドレス、ネットマスク、安全が必要かどうかのフラグについて確定したリストが必要だろう。
より融通が利く実装のためには、ワイルドカードを使ったDNS名 (例、'*.foo.bar')、 入/出のビットマスク、さらに必要ならファイアウォールのアドレスが 載ったリストが必要だ。ワイルドカードDNS名は、入/出のIPアドレスと一致させるために、ビットマスクはセキュリティを確保するかどうかとその方向を決めるために使われ、オプションのファイアウォールのアドレスは、中継ファイアウォールを通して対象システムとの接続するための、トンネルモードが必要がどうかを示す。
証明書を使った認証方式を実装するホストシステムには、証明書の取得、それのデータベースを管理する機構が必要になる。
セキュアDNSは証明書配送機構の一つであるが、短期的には、セキュアDNSを使用できるゾーンの広まりが期待できそうにない、さまざまな理由がある。 一番の理由は、ホストが安全な手段で証明書を手に入れる能力が必要になるだけでなく、他のシステムが使う自身の証明書を送り出せなければならないからだ。
動的な証明書発見機構やプロトコルが使用可能となった時に、その導入を阻むことになるため、手作業による証明書管理は行なうべきではない。
以下のセクションには、IPSEC DOIの Situation ID、プロトコル ID、Transform ID、AH、ESP、 IPCOMP Transform ID、SA 属性値、ラベル付ドメインID、IDペイロード値、Notifyメッセージ値 についての番号割り当てが載っている。
ISAKMPプロトコル文法は、複数のフェイズIIセキュリティプロトコルスートのネゴシエーションを 一度にまとめてに行なえるように、特別な設計となっている。その結果、以下に挙げるプロトコルスートを 同時にネゴシエートできる。どれとどれを同時にネゴシエートするかは、ホストのポリシーによって決まる。
以下のテーブルは、IPSEC DOI中の ISAKMP プロトコルペイロードから参照される、セキュリティプロトコルIDの値である。
プロトコルID 値 RESERVED 0 PROTO_ISAKMP 1 PROTO_IPSEC_AH 2 PROTO_IPSEC_ESP 3 PROTO_IPCOMP 4
PROTO_ISAKMP波、ISAKMPプロトコルのフェイズ1の間、メッセージを保護する必要があることを示す。IPSEC DOI で使われる、ある保護メカニズムについては、[IKE]で解説されている。全ての IPSEC DOI の実装は、PROTO_ISAKMP をサポートしなくてはならない。
ノート: ISAKMP の値1は、DOI定義全体を通して予約されている。
PROTO_IPSEC_AH は、IPパケット認証を指定する。デフォルトのAH変換は、データ発信元による認証、完全性保護、replay検出を行なう。 輸出制限を考慮する場合、PROTO_IPSEC_AH 変換による秘匿性の提供は行なってはならない。
PROTO_IPSEC_ESP は、IPパケットの秘匿性を指定する。認証が必要な場合は、それはESP変換の中で提供されなければならない。デフォルトのESP変換には、データ発信元認証、完全性保護、replay生検出、秘匿性が含まれる。
PROTO_IPCOMP は、[IPCOMP] で定義されている IPペイロード圧縮を指定する。
ISAKMPフェイズIネゴシエーションの一過程で行われる、Key Exchange 申し出の発信側での選択は、ホストシステムのポリシー記述によって決められる。Key Exchange メカニズムの実際の選定は、標準 ISAKMP Proposal ペイロードを使用して決定する。以下の表は、IPSEC DOI における Proposal ペイロードの ISAKMP フェイズI変換IDである。
変換 値 RESERVED 0 KEY_IKE 1 ISAKMP と IPSEC DOI のフレームワークでは、IKE(Oakley) 以外の鍵確立プロトコルを定義することも可能である。本ドキュメントの前の版では、手動的な鍵決定と、汎用の鍵配布センター(Key Distribution Center: KDC) の利用に基づくものの、二種類を定義していた。これらのIDは本ドキュメントから削除されている。
IPSEC DOI では、Kerberos[RFC-1510] や グループ鍵管理プロトコル (Group Key Management Protocol: GKMP) [RFC-2093] などの、非Oakley鍵確立プロトコルを後からISAKMPとIPSEC に追加できるようになっている。
KEY_IKEは、[IKE] ドキュメントに定義されている、ハイブリッド ISAKMP/Oakley Diffie-Hellman 鍵交換 (IKE) を指定する。IPSEC DOI のすべての実装は、KEY_IKE をサポートしなければならない。
認証ヘッダ (Authentication Header) プロトコルは、認証、完全性、replay生検出を提供するための変換として、必須のもの一つといくつかのオプションのものを定義している。以下の表に載っているものは、IPSEC DOI の ISAKMP Proposal ペイロードで定義済みのAH変換IDである。
注意: 正しいAH保護スートを見つけるために、認証アルゴリズム (Authentication Algorithm) 属性を指定しなければならない。例えば、MD5を使用するAH変換全般にたいしてAH_MD5は最適であろう。AHを使ってのHMAC構築を要求するためには、認証アルゴリズム属性にHMAC-MD5を指定するとともに、AH_MD5変換IDを指定する。続くセクションでは、これを "Auth(HMAC-MD5)" という記法で表現する。
変換ID 値 RESERVED 0,1 AH_MD5 2 AH_SHA 3 AH_DES 4 注意: 続くセクションでは、すべての実装義務のあるアルゴリズムについては、実装｢しなければならない」(例、AH_MD5)となっている。それ以外のアルゴリズムの実装はオプションであり、 実装してもかまわない。
AH_MD5は、MD5を使用するAH変換全般を指定する。実際の保護スートは、これと関連するSA属性リストとともに決定される。汎用MD5変換は現在未定義である。
IPSEC DOI のすべての実装は、Auth(HMAC-MD5) 属性でのAH_MD5をサポートしなければならない。このスートは、[HMACMD5]で、HMAC-MD5-96変換として定義されている。
AH変換 (Key/Pad/Data/Key) を指定する、Auth(KPDK) 属性と共に使われるAH_MD5は、RFC-1826に解説されている。
その他の認証アルゴリズム属性値と共に使用するAH_MD5の仕様は、現在未定義である。
AH_SHAは、SHA-1を使用するAH変換全般を指定する。実際の保護スートは、これと関連するSA属性リストとともに決定される。汎用SHA変換は現在未定義である。
IPSEC DOI のすべての実装は、Auth (HMAC-SHA) 属性での AH_SHA をサポートしなければならない。このスートは、[HMACSHA]で、HMAC-SHA-1-96変換として定義されている。
その他の認証アルゴリズム属性値と共に使用するAH_SHAの仕様は、現在未定義である。
AH_DESは、DESを使用するAH変換全般を指定する。実際の保護スートは、これと関連するSA属性リストとともに決定される。汎用DES変換は現在未定義である。
IPSEC DOIは、DES-MAC変換を行うための、Auth (DES-MAC) 属性と共に使用するAH_DESを定義している。このモードは、実装しなくてもかまわない。
その他の認証アルゴリズム属性値と共に使用するAH_DESの仕様は、現在未定義である。
カプセル化セキュリティペイロード (Encapsulating Security Payload: ESP) では、データの秘匿性を提供するための変換として、必須のもの一つといくつかのオプションのものを定義している。以下の表に載っているものは、IPSEC DOI の ISAKMP Proposal ペイロードで定義済みのESP変換IDである。
注意: 認証時、完全性保護、replay生検出は必要であり、適切なESP保護スートを特定できるよう、認証アルゴリズム属性を指定しなければならない。例を挙げれば、HMAC-MD5認証を3DESと共に使用したいならば、ESP_3DES変換IDを、HMAC-MD5に設定された認証アルゴリズム属性と共に指定する。さらなる処理が必要なら、セクション4.5(認証アルゴリズム)を参照。
変換ID 値 RESERVED 0 ESP_DES_IV64 1 ESP_DES 2 ESP_3DES 3 ESP_RC5 4 ESP_IDEA 5 ESP_CAST 6 ESP_BLOWFISH 7 ESP_3IDEA 8 ESP_DES_IV32 9 ESP_RC4 10 ESP_NULL 11 注意: 続くセクションでは、すべての実装義務のあるアルゴリズムについては、実装｢しなければならない」 (例、ESP_DES) となっている。それ以外のアルゴリズムの実装はオプションであり、実装してもかまわない。
ESP_DES_IV64 は、RFC-1827 と RFC-1829 で定義されている、64ビットIVを使用するDES-CBC変換を指定する。
ESP_DESは、DES-CBCを使用するDES変換全般を指定する。実際の保護スートは、これと関連するSA属性リストとともに決定される。汎用の変換は現在未定義である。
IPSEC DOIのすべての実装は、Auth (HMAC-MD5) 属性でのESP_DESをサポートしなければならない。このスートは、HMAC MD5[HMACMD5] が提供する認証と完全性のもとでの、[DES]変換として定義されている。
ESP_DESは、トリプルDES変換全般を指定する。実際の保護スートは、これと関連するSA属性リストとともに決定される。汎用の変換は現在未定義である。
IPSEC DOIのすべての実装は、Auth (HMAC-MD5) 属性でのESP_3DESをサポートする様、強く要請されている。このスートは、HMAC MD5[HMACMD5] が提供する認証と完全性のもとでの、[ESPCBC]変換として定義されている。
ESP_RC5は、[ESPCBC]で定義されたRC5変換を指定する。
ESP_IDEAは、[ESPCBC]で定義されたIDEA変換を指定する。
ESP_CASTは、[ESPCBC]で定義されたCAST変換を指定する。
ESP_BLOWFISHは、[ESPCBC]で定義されたBLOWFISH変換を指定する。
ESP_3IDEAは、トリプルIDEA変換のために予約されている。
ESP_ESP_DES_IV32は、RFC-1827とRFC-1829で定義された、32ビットIVを使用するDES-CBC変換を指定する。
ESP_RC4は、RC4のために予約されている。
ESP_NULLは、ESPが秘匿性を提供しない事を指定する。ESPが、認証、完全性保護、replay生検出しか必要としないトンネルリングで使われる時に、ESP_NULLが使われる。
IPSEC DOIのすべての実装は、ESP_NULLをサポートしなければならない。ESP_NULL変換は[ESPNULL]で定義されている。ESP_NULLの仕様に関連した追加の要求については、セクション4.5で解説されている、認証アルゴリズム属性を参照。
IP圧縮 (IPCOMP) 変換は、オプションである、IPペイロードの圧縮を提供するためにネゴシエーションされる圧縮アルゴリズムを定義する ([IPCOMP])。以下の表に載っているものは、IPSEC DOI の ISAKMP Proposal ペイロードで定義済みのIPCOMP変換IDである。
変換ID 値 RESERVED 0 IPCOMP_OUI 1 IPCOMP_DEFLATE 2 IPCOM_LZS 3
以下は、IKEネゴシエーションのフェイズIIで使用されるSA属性である。属性は、基本(B)または可変長 (V) のどちらかである。これらの属性のエンコーディングは基本 ISAKMP 指定で定義されている。
基本となっている属性を可変長エンコーディングしてはならない。可変長属性が2オクテットに収まるなら、基本属性エンコーディングしてもよい。IPSEC DOI における、属性エンコーディングのより詳しい情報については、[IKE]を参照の事。[IKE]に載っているすべての制限は、IPSEC DOI にも同様に当てはまる。
属性
クラス 値 種類 SA Life Type 1 B SA Life Duration 2 V Group Description 3 B Encapsulation Mode 4 B Authentication Algorithm 5 B Key Length 6 B Key Rounds 7 B Compression Dictionary Size 8 B Compression Private Algorithm 9 V クラス値
- SA Life Type (SA有効種類)
- SA Duration (SA有効期間)
SA全体の有効期間を指定する。 SAが有効期間を過ぎた時、 アソシエーション(AHまたはESP)の基でネゴシエーションされた すべての鍵は再ネゴシエーションされなければならない。 Life Typeの値は以下の通り。
RESERVED 0 seconds 1 kilobytes 2 3から61439までの間の値はIANAによって予約済みである。61440から65535までの値は、プライベートで使用できる。Life type それぞれに対して、SA Duration 属性の値が、 保護される秒数またはKバイト単位で、実際の有効期間を定義する
未指定の場合、デフォルトの値として28800秒 (8時間) が使用される。
SA Life Duration 属性は、必ず期間の単位を示す SA Life Type の後に続かなくてはならない。
有効期間の記法に関する追加の情報については、Appendix-A を参照。
- Encapsulation Mode (カプセル化モード)
RESERVED 0 Tunnel 1 Transport 2 3から61439までの値は、IANAによって予約済みである。61440から65535の値は、プライベートで使用できる。
指定されていない場合は、デフォルトで未指定(ホスト依存)として扱われる。
- Auth Algorithm (認証アルゴリズム)
RESERVED 0 HMAC-MD5 1 HMAC-SHA 2 DES-MAC 3 KPDK 4 5から61439までの値はIANAによって予約済みである。to 61440から65535の値はプライベートで使用できる。
認証アルゴリズムにはデフォルト値は存在しないので、以下の例を除いて、使用するAH/ESP変換が正しく判断できるように、アルゴリズムを指定しなくてはならない。
ESPで認証無しでネゴシエーションする場合、プロポーザルの中に認証アルゴリズム属性はあってはならない。
ESPで秘匿性無しでネゴシエーションする場合、プロポーザルの中に認証アルゴリズム属性はなくてはならず、ESP変換IDはESP_NULLでなければならない。
- Key Length (鍵長)
RESERVED 0 鍵長にはデフォルトの値は存在しないので、鍵長が可変の暗号を使う変換に対しては、 指定しなければならない。固定長の暗号に対して、鍵長属性を送ってはならない。
- Key Round (鍵ラウンド)
鍵ラウンドにはデフォルトの値は存在しないので、ラウンド数が変わる暗号を使う変換に対しては、指定しなければならない。
- compression Dictionary Size (圧縮辞書サイズ)
RESERVED 0 辞書の最大値のlog2を指定する。
辞書サイズのデフォルト値は存在しない。
- Compression Private algorithm (圧縮プライベートアルゴリズム)
ベンダにプライベートな圧縮アルゴリズムを指定する。最初の3オクテットは、IEEEから取得した company_ID (OUI) でなければならない。その次のオクテットにベンダー独自圧縮サブタイプ、さらに続けて0オクテット以上のベンダーデータを置く。
基本相互運用性を確実にするために、すべての実装では以下の属性全てに対してのネゴシエーションを行えるようになっていなければならない。
- SA Life Type
- SA Duration
- Auth Algorithm
セマンティックスの自由度を高めるために、IPSEC DOIは、ISAKMP を満足する実装は属性リストに、ある属性クラスのインスタンスが複数含まれていても、それらが衝突しない限り、正しくパースできなければならないことを要求する。現時点では、この扱いを必要とする属性は、Life TypeとDuration だけである。
これがなぜ重要なのかを見てみよう。次の例は、SA有効期間として100MBと24時間を指定する、4つの属性のバイナリエンコーディングである。(属性エンコーディング書式についての完全な解説については [ISAKMP] のセクション3.3を参照)。
Attribute #1: 0x80010001 (AF = 1, type = SA Life Type, value = seconds) Attribute #2: 0x00020004 (AF = 0, type = SA Duration, length = 4 bytes) 0x00015180 (value = 0x15180 = 86400 seconds = 24 hours) Attribute #3: 0x80010002 (AF = 1, type = SA Life type, value = KB) Attribute #4: 0x00020004 (AF = 0, type = SA Duration, length = 4 bytes) 0x000186A0 (value = 0x186A0 = 100000KB = 100MB)[訳注]
ここでは1MB=1000KBとなっており、通常のコンピュータのメモリでの換算 (1MB=1024KB) とは異なっているが、これはオクテット数は通常の10進数であり、2進数ではないためである。属性の衝突が見つかったら、ATTRIBUTES-NOT-SUPPORTED Notification ペイロードを送るべきであり、SAの確立は中断されなければならない。
実装は、定義されているがサポートしていないIPSEC DOI属性(もしくは属性値)を受け取った場合、その値が予約されている範囲に入っていないなら、ATTRIBUTES-NOT-SUPPORTED を送るべきであり、SAの確立は中断されなければならない。
実装が予約範囲の属性値を受け取った場合、継続するかどうかを、ローカルポリシーに基づいて決めて良い。
レスポンダのポリシーに基づくものよりも、大きなSA有効期間がイニシエータから提案された場合、レスポンダには三つの選択肢がある。1)ネゴシエーションを失敗に終わらせる、2)提案されたものよりも少ない有効期間を使ってネゴシエーションを完了させる、3)ネゴシエーションを完了させ、それからレスポンダの真の有効期間を知らせる、アドバイザリ通知をイニシエータに送る。レスポンダがどれを選択するかは、実装やポリシーによる。
後者の場合の相互運用性を確実なものとするために、IPSEC DOI ではレスポンダがイニシエータに通知したい場合のみ、以下の事項が必須である。イニシエータから、レスポンダが受け入れるものよりも長い有効期間が提案された場合、レスポンダは、ISAKMP通知ペイロードを、レスポンダからのIPSEC SAペイロードの交換の中に含めなければならない。この場合に使わなければならない、RESPONDER-LIFETIME通知メッセージは セクション 4.6.3.1で定義されている。
続くセクションは、DOIによってデータ表現が変わる、ISAKMPペイロードについて解説する。
次は、IPSEC DOI のSAペイロードの内容を図示したものである。Situation ビットマップについては、セクション4.2を参照。
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 (IPSEC) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Situation (bitmap) ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Labeled Domain Identifier ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Secrecy Length (in octets) ! RESERVED ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Secrecy Level ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Secrecy Cat. Length (in bits) ! RESERVED ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Secrecy Category Bitmap ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Integrity Length (in octets) ! RESERVED ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Integrity Level ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Integ. Cat. Length (in bits) ! RESERVED ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Integrity Category Bitmap ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Security Association Payload FormatSAペイロードの定義は以下の通りである。
- Next Payload (1オクテット) - 同じメッセージ中の次のペイロードの種類のIDである。このペイロードがメッセージ中の最後のものである場合、値は0となる。
- RESERVED (1オクテット) - 未使用。0でなければならない。
- Payload Length/ペイロード長 (2オクテット) - このペイロードの、ヘッダも含んだオクテット単位での長さ。
- Domain of Interpretation/解釈ドメイン (4オクテット) - IPSEC DOI を指定し、その値は1である。
- Situation/状況 (4オクテット) - 残りのSAペイロードを解釈するために使用される ビットマップ。その値すべての一覧については、セクション4.2を参照。
- Labled Domain Identifier/ラベル付きドメインID (4オクテット) - Secrecy/秘匿性とIntegrity/完全性の解釈に使われるIANA割当番号。
- Secrecy Length/秘匿性長 (2オクテット) - パッディングビットを除いて、秘匿性レベルIDの長さを、 オクテット単位で指定する。
- RESERVED (2オクテット) - 未使用。0でなければならない。
- Secrecy Level/秘匿性レベル (可変長) - 要求される必須秘匿性レベルを指定する。 秘匿性レベルは、32ビット境界に並ぶように、0でパディングされなければならない。
- Secrecy Category Length/秘匿性カテゴリ長 (2オクテット) - パディングビットを除いた、秘匿性カテゴリ(コンパートメント)ビットマップの長さを、ビット単位で指定する。
- RESERVED (2オクテット) - 未使用。0でなければならない。
- Secrecy Category Bitmap/秘匿性カテゴリビットマップ (可変長) - 要求される秘匿性カテゴリ(コンパートメント)を示すために使用される ビットマップ。ビットマップは、32ビット境界に並ぶように、0でパディングされなければならない。
- Integrity Level/完全性レベル (2オクテット) - パディングビットを除いた、完全性レベルIDの長さを、オクテット単位で指定する。
- RESERVED (2オクテット) - 未使用。0でなければならない。
- Integrity Level/完全性レベル (2オクテット) - 要求される必須完全性レベルを指定する。完全性レベルは、32ビット境界に並ぶように、0でパディングされなければならない。
- Integrity Category Length/完全性カテゴリ長 (2オクテット) - パディングビットを除いた、完全性カテゴリ(コンパートメント)ビットマップの長さを、ビット単位で指定する。
- RESERVED (2オクテット) - 未使用。0でなければならない。
- Integrity Category Bitmap/完全性カテゴリビットマップ (可変長) - 要求される完全性カテゴリ(コンパートメント)を示すために使われるビットマップ。ビットマップは、32ビット境界に並ぶように、0でパディングされなければならない。
次の表は、SAペイロードのSituation/状況フィールド中に含まれる、Labeled Domain/ラベル付きドメインIDフィールドに割り当てられた値の一覧である。
ドメイン 値 RESERVED 0
IDペイロードは、SAのイニシエータのイニシエータが本物である事を確認するために使用される。レスポンダは、アソシエーションに必要な 正しいホストシステムセキュリティポリシーを決定するために、イニシエータのIDを使用すべきである。例をあげると、ある一群のIPアドレスに対しては、秘匿性 (AH) なしの認証と完全性を要求し、他のIPアドレスの範囲に対しては、秘匿性 (ESP) を使った完全な認証を要求することを選びうる。IDペイロードは、レスポンダがこの決定を行なうための情報を提供する。
フェイズIネゴシエーション中、IDポートとプロトコルフィールドは0か、UDPポート500でなければならない。実装が他の値を受け取った時は、エラーとしなければならず、SAの確立は、中断しなければならない。このイベントは記録されるべきである。
次は、IDペイロードの内容を図示したものである。
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 ! Protocol ID ! Port ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Identification Data ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Identification Payload FormatIDペイロードの各フィールドは以下のように定義されている。
- Next Payload (1オクテット) - 同じメッセージ中の次のペイロードの種類のIDである。このペイロードがメッセージ中の最後のものである場合、値は0となる。
- RESERVED (1オクテット) - 未使用。0でなければならない。
- Payload Length/ペイロード長 (2オクテット) - このペイロードの、ヘッダも含んだオクテット単位での長さ。
- IDタイプ (1オクテット) - Identification Data(ID)フィールドにある情報の種類を決める値。
- Protocol ID/プロトコルID - 対応するIPのプロトコルID (例、UDP/TCP) を指定する値。 値が0の場合は、Protocol IDフィールドを無視しなければならない。
- Port/ポート (2オクテット) - 対応するポート番号を指定する値。値が0の場合は、Portフィールドを無視しなければならない。
- Identification Data/IDデータ (可変長) - Identification Type で指定される値。
次の表は、IDペイロード中の Identification Type フィールドに割り当てられた値の一覧である。
| IDタイプ | 値 |
|---|---|
| RESERVED | 0 |
| ID_IPV4_ADDR | 1 |
| ID_FQDN | 2 |
| ID_USER_FQDN | 3 |
| ID_IPV4_ADDR_SBUNET | 4 |
| ID_IPV6_ADDR | 5 |
| ID_IPV6_ADDR_SUBNET | 6 |
| ID_IPV4_ADDR_RANGE | 7 |
| ID_IPV6_ADDR_RANGE | 8 |
| ID_DER_ASN1_DN | 9 |
| ID_DER_ASN1_GN | 10 |
| ID_KEY_ID | 11 |
IDが可変長のものについては、その長さはIDペイロードヘッダから計算される。
(なんらかの)証明書を使ってIKE交換を認証する場合、ポリシーに基づく決定に使用されるIDはすべて、交換の認証に使われる証明書のなかに入っているべきである。
ID_IPV4_ADDRは、4オクテットのIPv4アドレスを示す。
ID_FQDNは、省略無しのドメイン名(FQDN)文字列を示す。 "foo.bar.com" が ID_FQDN の例である。文字列には、終端文字を含むべきではない。
ID_USER_FQDNは、省略無しのユーザ名文字列を示す。 "piper@foo.bar.com" がID_USER_FQDNの例である。文字列には、終端文字を含むべきではない。
ID_IPV4_ADDR_SUBNET は、IPv4アドレスの範囲を示す、4オクテットの値2個からなる。最初の値は、IPv4アドレスである。二番目のものは、IPV4ネットマスクである。ネットマスク内で1となっているのは、アドレス中の対応するビットが固定されている事を示し、0となっているものは「ワイルドカード」である事を示すことに注意する事。
ID_IPV6_ADDRは、16オクテットのIPv6アドレス一個を示す。
ID_IPV6_ADDR_SUBNET は、IPv6アドレスの範囲を示す、16オクテットの値2個からなる。最初の値はIPv6アドレスである。二番目のものはIPv6ネットマスクである。ネットマスク内で1となっているのは、アドレス中の対応するビットが固定されている事を示し、0となっているものは「ワイルドカード」である事を示すことに注意する事。
ID_IPV4_ADDR_RANGEは、IPv4アドレスの範囲を示す、4オクテットの値2個からなる。最初の値は始まりのIPv4アドレス(範囲に含まれる)であり、二番目の値は終わりのもの(範囲に含まれる)である。指定された二つのアドレスの間のアドレスはすべてリスト中にあるものとして扱う。
ID_IPV6_ADDR_RANGEは、IPv6アドレスの範囲を指定する、16オクテットの値2個からなる。 最初の値は始まりのIPv6アドレス(範囲に含まれる)であり、二番目の値は終わりのもの(範囲に含まれる)である。指定された二つのアドレスの間のアドレスはすべてリスト中にあるものとして扱う。
ID_DER_ASN1_DNは、SAを確立するために交換される証明書の対象者の ASN.1 X.500 Distinguished Name [X.501] のバイナリDERエンコーディングを指定する。
ID_DER_ASN1_GNは、SAを確立するために交換される証明書の対象者の ASN.1 X.500 General Name[X.509] のバイナリDERエンコーディングを指定する。
ID_KEY_IDは、Aggressive モードネゴシエーションの認証に、どの共有鍵を使用するかを指示するために必要な、ベンダ独自の情報を渡すために使用されうる、内容が不定のバイトストリームを指定する。
4.6.3 IPSEC通知メッセージ
EnglishISAKMPは、通知メッセージコードとして、エラーと状態それぞれのメッセージのために、二つのブロックを定義している。ISAKMPは、DOI内でのプライベートな使用のために、それぞれの一部を割り当てている。IPSEC DOIでは、自身のために、以下のプライベートメッセージを定義している。
通知 メッセージ - エラー Value RESERVED 8192
通知 メッセージ - 状態 Value RESPONDER-LIFETIME 24576 REPLAY-STATUS 24577 INITIAL-CONTACT 24578 Aggressiveモードでは、交換と状態通知メッセージをバインドするために必要な保護が提供されないので、状態通知メッセージは、最後のMainモード交換のペイロード、もしくは、MainモードまたはAggressiveモード処理の完了後の独立したInformational交換、またはQuickモード交換のペイロードとして、ISAKMP SA の保護のもので送られなければならない。
注意せよ: 通知ペイロードが完全に保護されるのは、ペイロード全体が HASH(n) ダイジェストに入っている、Quickモードにおいてのみである。Mainモードでは、通知ペイロードは暗号化されているが、HASH(n) ダイジェストには、今のところ入っていない。そのため、Mainモード暗号文に対して、アクティブ置き換えアタックが行なわれると、通知 Status メッセージが壊れることがありえる。(これは、一般にMainモード交換の最後のメッセージに当てはまる)。そのリスクは小さいが、壊れた通知メッセージのために、送信側で致命的なエラーが発生したものと、受信側が考えてネゴシエーション全体を中断することがある。
実装上の注意: ISAKMPプロトコルは、KSAKMP Informational 交換で起こられた場合、状態通知メッセージが配送される事を保証しない。メッセージが受信される事を確実にするには、再送タイマーで保護される、Mainモードか Quick モード交換に通知ペイロードを入れるべきである。
4.6.3.1 RESPONDER-LIFETIME
EnglishRESPONDER-LIFETIME 状態メッセージは、レスポンダが選んだ IPSEC SA 有効期間を知らせるために使用されることがある。
使用された場合、通知ペイロードの形式は以下の通りでなければならない。
- Payload Length - ペイロード長+データ長(可変)
- DOI - IPSEC DOI (1)に設定
- Protocol/プロトコル ID - 選んだSAのプロトコルIDに設定
- SPIサイズ - 16(2個の8オクテットISAKMPクッキー)もしくは4(IPSEC SPI一個)
- Notification Message Type/通知メッセージタイプ - RESPONDER-LIFETIME(セクション4.6.3)に設定
- SPI - 二個のISAKMPクッキーもしくは送信元の受信IPSEC SPI
- Notification Data/通知データ - レスポンダの実際のSA有効期間のISAKMP属性リスト
実装上の注意: Notification Data/通知データフィールドに属性リストが入っているということは、 通知データフィールドの長さが0で、 Notification Payload/通知ペイロードが対応する属性リストを持つということと 同値である。
4.6.3.2 REPLAY-STATUS
EnglishREPLAY-STATUS 状態メッセージは、対replay生検出を行なうかどうかについての選択についての、レスポンダからの肯定的な確認のために使われる。
使われた時は、Notification Payload/通知ペイロードは以下の形式でなければならない。
- Payload Length - ペイロード長+データ長(4)
- DOI - IPSEC DOI (1)に設定
- Protocol/プロトコル ID - 選んだSAのプロトコルIDに設定
- SPIサイズ - 16(2個の8オクテットISAKMPクッキー)もしくは4(IPSEC SPI一個)
- Notification Message Type/通知メッセージタイプ - REPLAY-STATUSに設定
- SPI - 二個のISAKMPクッキーもしくは送信元の受信用IPSEC SPI
- Notification Data/通知データ - 4オクテットの値:
- 0 = 再送検出非動作
- 1 = 再送検出動作
4.6.3.3 INITIAL-CONTACT
EnglishINITIAL-CONTACT状態メッセージは、片側から他方へ、そことSAを確立するのが始めてである事を通知したい場合に使用される。この通知メッセージの受信側は、送信元が再起動したため、以前のSAとそのに関係する鍵情報にはアクセスできなくなったのだろうとみなして、そのシステムに対しての既存のSAを削除することができる。これが使われる場合、通知データフィールドの内容は空 (null) であるべきである (つまり Payload Length を通知ペイロードのある固定長になるはずである)。
あった場合は、通知ペイロードは以下の形式になっていなければならない。
- Payload Length - ペイロード長+データ長(0)
- DOI - IPSEC DOI(1)に設定
- Protool ID - 選択したSAから選ばれた Protocol ID に設定
- SPI Size - 16(二つの8オクテットISAKMPクッキー)
- Notify Message Type - INITIAL-CONTACT に設定
- SPI - 2個のISAKMPクッキーに設定
Notification Data - なし
4.7 IPSEC 鍵交換要求事項
EnglishIPSEC DOI によって追加される鍵交換はない。
5 セキュリティについての考慮事項
Englishこのメモ全体は、安全で認証された方法で暗号鍵情報の配布を行なうために、ISAKMP ([ISAKMP]) と Oakley ([OAKLEY]) を組み合わせた、Internet Key Exchange プロトコル ([IKE]) に付随している。本ドキュメントに載っている、様々なセキュリティプロトコルと変換についての詳しい解説は、関連する基礎ドキュメントや暗号参考文献に載っている。
6 IANA についての考慮
English本ドキュメントには、IANAが管理している、たくさんの「魔法の (magic)」数値が出てくる。このセクションでは、これらの一覧それぞれに数値を追加割当するために IANAが使う分野について説明する。これまでのセクションで明示的に定義したもの以外のすべての値は、IANAで予約済みである。
6.1 IPSEC Situation Definition/状況定義
EnglishSituation Definition は、IPSEC SA 申し込みとネゴシエーションが動作する環境を表現する、 32ビットのビットマスクである。新しいSituationの割当の要求は、割り当てられるビットの解釈を解説するRFCによらなければならない。
標準化目的でない (つまり、Informatial/広報やexperimental/実験) RFCであるなら、RFCを出し変換IDが割り当てられる前に、IESGによって明確にレビューされ承認されなければならない。
上位2ビットは、内輪のシステムの間でのプライベート利用のために予約されている。
6.2 IPSEC セキュリティプロトコル ID
EnglishセキュリティプロトコルIDは、ネゴシエーションするセキュリティプロトコルスートを表わす、8ビットの値である。新セキュリティプロトコルIDの割当の要求は、要求するセキュリティプロトコルを解説するRFCによらなければならない。[AH] と [ESP] はセキュリティプロトコルドキュメントの例である。
標準化目的でない (つまり、Informatial/広報やexperimental/実験) RFCであるなら、RFCを出し変換IDが割り当てられる前に、IESGによって明確にレビューされ承認されなければならない。
249から255までの値は、内輪のシステムの間でのプライベート利用のために予約されている。
6.3 IPSEC ISAKMP 変換 ID
EnglishIPSEC ISAKMP 変換ID は、ネゴシエーションで使われる鍵交換プロトコルを表わす8ビットの値である。新ISAKMP変換IDの割当の要求は、要求する鍵交換プロトコルを解説するRFCによらなければならない。[IKE] は、そのようなドキュメントの一つである。
標準化目的でない (つまり、Informatial/広報やexperimental/実験) RFCであるなら、RFCを出し変換IDが割り当てられる前に、IESGによって明確にレビューされ承認されなければならない。
249から255までの値は、内輪のシステムの間でのプライベート利用のために予約されている。
6.4 IPSEC AH 変換 ID
EnglishIPSEC AH 変換IDは、AHに対して完全性保護を提供するために使われる、ある一つのアルゴリズムを表わす8ビットの値である。新 AH 変換 ID の割当の要求は、AHフレームワーク ([AH]) 内でのアルゴリズムの使用方法を解説するRFCによらなければならない。
標準化目的でない (つまり、Informatial/広報やexperimental/実験) RFCであるなら、RFCを出し変換IDが割り当てられる前に、IESGによって明確にレビューされ承認されなければならない。
249から255までの値は、内輪のシステムの間でのプライベート利用のために予約されている。
6.5 IPSEC ESP 変換 ID
EnglishIPSEC ESP変換IDは、ESPに対してセキュリティ保護を提供するために使われる、ある一つのアルゴリズムを表わす8ビットの値である。新ESP変換IDの割当の要求は、ESPフレームワーク ([ESP]) 内でのアルゴリズムの使用方法を解説するRFCによらなければならない。
標準化目的でない (つまり、Informatial/広報やexperimental/実験) RFCであるなら、RFCを出し変換IDが割り当てられる前に、IESGによって明確にレビューされ承認されなければならない。
249から255までの値は、内輪のシステムの間でのプライベート利用のために予約されている。
6.6 IPSEC IPCOMP 変換 ID
EnglishIPSEC IPCOMP 変換IDは、ESPの前にIPレベルでの圧縮を提供するために使われる、ある一つのアルゴリズムを表わす8ビットの値である。新IPCOMP変換IDの割当の要求は、IPCOMPフレームワーク ([IPCOMP]) 内でのアルゴリズムの使用方法を解説するRFCによらなければならない。付け加えて、要求されたアルゴリズムは公開され、かつパブリックドメイン(無償)でなければならない。
標準化目的でない (つまり、Informatial/広報やexperimental/実験) RFCであるなら、RFCを出し変換IDが割り当てられる前に、IESGによって明確にレビューされ承認されなければならない。
1から47までの値は、公開が承認されたRFCのアルゴリズムのために予約されている。48から63までの値は、内輪のシステムの間でのプライベート利用のために予約されている。64から255の値は将来の拡張のために予約済である。
6.7 IPSECSA 属性
EnglishIPSEC SA 属性は、16ビットの種類とその値からなっている。IPSEC SA 属性は、様々な値をISAKMP 端間で受け渡すために使用される。新IPSEC SA 属性の割当の要求は、属性のエンコーディング (基本/可変長) とそのリーガル値を解説した、Internet Draft によらなければならない。本ドキュメントのセクション4.5は、そのような解説の例である。
32001から32767の値は、内輪のシステムの間でのプライベート利用のために予約されている。
6.9 IPSEC ID
EnglishIPSEC IDは、可変長のIDペイロードの解釈を識別子として使用される8ビットの値である。新IPSEC IDの割当の要求は、IPSEC内でのIDの使用方法について解説するRFCによらなければならない。
標準化目的でない (つまり、Informatial/広報やexperimental/実験) RFCであるなら、RFCを出し変換IDが割り当てられる前に、IESGによって明確にレビューされ承認されなければならない。
249から255までの値は、内輪のシステムの間でのプライベート利用のために予約されている。
6.10 IPSEC通知メッセージ
EnglishIPSEC通知メッセージは、各DOIごとにISAKMPによって予約されている値の範囲から取られる16ビットの値である。エラーメッセージのために一つの範囲(8192から16383)、状態メッセージのために別の範囲(24576032767)がある。新通知メッセージの割当の要求は、IPSEC内でのそのIDの使用方法について解説する Internet Draft によらなければならない。
16001から16383と、32001から32767の値は、内輪のシステムの間でのプライベート利用のために予約されている。
7 変更履歴
English7.1 V9 からの変更
English
- [IPCOMP]、[DEFLATE]、[LZS] への明示的な参照を追加した
RESPONDER-LIFETIMEとREPLAY-STATUS が、ISAKMP "SPI" だけでなく IPSEC SPI に直接続けることを許した - Secrecy と Integrity Length テキストに、パディングを除くことを追加した
- セクション4.4.4にセクション4.5への前方参照を追加した
- ドキュメント参照を更新した
7.2 V8 からの変更
English
- IPCOMPドラフトをより反映するように、IPCOMP ID範囲を更新した
- Jeff/Tedからの提案テキストにしたがって、IANAについての考慮を更新した
- DES-MAC ID ([DESMAC]) への参照を削除した
- Notify/通知セクションでのバグを修正: ISAKMP通知値は16ビット
- IPCOMP (IP Payload Compression) の名前を修正した
- [ESPCBC] への参照を修正した
- 図1に入っていなかった Secrecy LevelとIntegrity Level を追加した
- PF_KEY と ARCFOUR へのID参照を削除した
- [IKE] に沿うよう基本/可変長テキストを更新
- 文書参照を更新し、[ARCH] への紹介ポインタを追加した
- Notification/通知要求事項を更新 : アレグレッシプへの参照を削除
- Notify/通知ペイロードの保護について明確にした
- ESP変換ID名前空間にRESERVEDを復活 : ESP_NULLとする
- ESP_NULLサポートの要求と [ESPNULL] 参照を追加した
- AH/ESPでの認証アルゴリズムの使用を明確にした
- AH/認証の組み合わせでの衝突に対しての制限を追加
以下の変更は、IPSEC DOI V6 に関連して行なわれた。
- IANAについての考慮セクションを追加
- ほとんどのIANA番号をIANA考慮セクションに移動
- (B)属性を(V)エンコーディングで送る事の禁止を追加
- 固定長暗号 (例、DES) に対して Key Length/ 鍵長属性を送る事の禁止を追加
- IKEでの ISAKMP/Oakley への参照を置き変え
- ESP_ARCFOUR をESP_RC4へ名前変更
- セキュリティについての考慮セクションを更新
- ドキュメント参照を更新
以下の変更は、IPSEC DOI V5 に関連して行なわれた。
- Lifetime Notifycation/有効期間通知テキスト中のSPIの大きさを変更
- REPLAY-ENABLED を REPLAY-STATUS に変更
- RESPONDER-LIFETIMEペイロード定義を、セクション4.5.4からセクション4.6.3.1に移動
- 4.6.3.3にペイロードのレイアウトを明示
- セクション4.6.3紹介に実装上の注意を追加
- MD5に加えてSHA-1も必要であるとAH_SHAテキストを変更
- ドキュメント参照を更新
以下の変更は、IETF ミュンヘン会合に先立って IPSEC メイリングリストに投稿された、IPSEC DOI V3 に関連して行われた。
- ESP変換IDにNULLとARCFOURを追加した
- ESPをDES-MACとオプションの認証/完全性に対応させるために、認証アルゴリズムにHMACアルゴリズムを追加したp
- AHとESP DES-MACアルゴリズムIDを追加した
- KEY_MANUAL と KEY_KDC ID 定義を追加
- 有効期間が有効種類属性に続かなくてはならないことを SA Life Type に追加し、SA Life Duration 属性定義を追加
- 有効期間通知と IPSEC DOI メッセージ表を追加
- MACアルゴリズム属性定義にオプションの認証と秘匿性制限を追加
- 属性パースの例を修正(無効属性を使っていた)
- いくつかの Internet Draft ドキュメントへの参照を修正
- IPSECリスト解説に ID_KEY_ID を追加
- PFS QM の Group Description デフォルトを削除([IKE]では必須)
[AH] Kent, S., and R. Atkinson,
"IP Authentication Header",
RFC 2402, 1998年 11月.
[ARCH] Kent, S., and R. Atkinson,
"Security Architecture for the Internet Protocol",
RFC 2401, 1998年 11月.
[DEFLATE] Pereira, R.,
"IP Payload Compression Using DEFLATE",
RFC 2394, 1998年 8月.
[ESP] Kent, S., and R. Atkinson,
"IP Encapsulating Security Payload (ESP)",
RFC 2406, 1998年 11月.
[ESPCBC] Pereira, R., and R. Adams,
"The ESP CBC-Mode Cipher
[ESPNULL] Glenn, R., and S. Kent,
"The NULL Encryption Algorithm and Its Use With IPsec",
RFC 2410, 1998年 11月.
[DES] Madson, C., and N. Doraswamy,
"The ESP DES-CBC Cipher Algorithm With Explicit IV",
RFC 2405, 1998年 11月.
[HMACMD5] Madson, C., and R. Glenn,
"The Use of HMAC-MD5 within ESP and AH",
RFC 2403, 1998年 11月.
[HMACSHA] Madson, C., and R. Glenn,
"The Use of HMAC-SHA-1-96 within ESP and AH",
RFC 2404, 1998年 11月.
[IKE] Harkins, D., and D. Carrel, D.,
"The Internet Key Exchange IKE)",
RFC 2409, 1998年 11月.
[IPCOMP] Shacham, A., Monsour, R., Pereira, R., and M. Thomas,
"IP Payload Compression Protocol (IPComp)",
RFC 2393, 1998年 8月.
[ISAKMP] Maughan, D., Schertler, M., Schneider, M., and J. Turner,
"Internet Security Association and Key Management Protocol ISAKMP)",
RFC 2408, 1998年 11月.
[LZS] Friend, R., and R. Monsour,
"IP Payload Compression Using LZS",
RFC 2395, 1998年 8月.
[OAKLEY] Orman, H.,
"The OAKLEY Key Determination Protocol",
RFC 2412, 1998年 11月.
[X.501] ISO/IEC 9594-2,
"Information Technology - Open Systems Interconnection - The Directory: Models", CCITT/ITU Recommendation X.501, 1993年.
[X.509] ISO/IEC 9594-8,
"Information Technology - Open Systems Interconnection - The Directory: Authentication Framework", CCITT/ITU Recommendation X.509, 1993年.
著作権表記全文
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.