ネットワーク WG
Request for Comments: 2407
分類: スタンダードトラック
D. Piper
Network Alchemy
1998年11月

English

IPsec における ISAKMP の解釈
(The Internet IP Security Domain of Interpretation for ISAKMP)

このメモの位置付け English

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

著作権表記 English

Copyright (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. 概要 English

Internet 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. はじめに English

ISAKMPを使ってSAをネゴシエイトする、関連しあったプロトコルをまとめるために、Domain of Interpretation (DOI) を使用する。DOIを共有するセキュリティプロトコルは、共通の名前空間からセキュリティプロトコルと暗号化変換方式を選び、鍵交換プロトコルIDを共有する。

最終的に、ISAMKP は、DOI 定義に加えて以下のものを要求する。

本文の残りの部分は、協調するホストシステムとファイアウォール間を流れるIPパケットに 認証、統一性、秘匿性を提供するために、IP Security(IPSEC) プロトコルを使用するための、先の要求項目の具体化についての詳細な解説である。

IPSEC 全体を通しての記述については、[ARCH]、[AH]、[ESP]を参照。

 

3. 用語と定義 English

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

 

4.1 IPSEC 名前付け規則 English

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進値は、ネットワークバイトオーダである。

4.2 IPSEC 状況定義 English

ISAKMPでは、Situation (状況) は、レスポンダ (着呼側) が 受け取ったSA要求をどう処理するかについての、ポリシーを定めるために使用できる情報を提供する。IPSEC DOI においては、Situation フィールドは、4オクテットのビットマスクであり、以下の値を取る。

Situation
SIT_IDENTITY_ONLY 0x01
SIT_SECRECY 0x02
SIT_INTEGRITY 0x04

4.2.1 SIT_IDENTITY_ONLY English

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 に含まれなければならない

4.2.2 SIT_SECRECY English

SIT_SECRECY は、ネゴシエーション中の SA が、ラベル付けされたセキュリティが必要な環境中にあることを示している。Situation ビットマップ中に SIT_SECRECY があった場合、Situation フィールドには、センシティブティレベルとコンパートメントビットマスクが入った可変長のデータが続く。SA ペイロード形式についての詳細な解説は、セクション4.6.1を参照。

イニシエータが SIT_SECRECY をサポートしない場合、SIT_SECRECY は Situtaion ビットマップ中に設定されてはならず、また秘密レベルやカテゴリビットマップも含まれないほうがよい。

レスポンダが SIT_SECRECY をサポートしない場合は、SITUATION-NOT-SUPPORTED 通知ペイロードを返すべきであり、SA の確立は中止されなければならない

4.2.3 SIT_INTEGRITY English

SIT_INTEGRITY は、ネゴシエーション中のSA が、ラベルが付いたインテグリティを必要とする環境中にあることを示している。Situation ビットマップ中に SIT_INTEGRITY があった場合、Situation フィールドには、インテグリティレベルとコンパートメントビットマスクが入った、可変長のデータが続く。SA ペイロード形式についての詳細な解説は、セクション4.6.1を参照。

イニシエータが SIT_INTEGRITY をサポートしない場合、SIT_INTEGRIRY は Situtaion ビットマップ中に設定されてはならず、またインテグリティレベルやカテゴリビットマップも含まれないほうがよい。

レスポンダが SIT_INTEGRIRY をサポートしない場合は、SITUATION-NOT-SUPPORTED 通知ペイロードを返すべきであり、SA の確立は中止されなければならない

4.3 IPSEC セキュリティポリシー要求 English

IPSEC DOI では、実装いて、特定のセキュリティポリシーは強要されない。 ホストシステムのポリシー問題は、本ドキュメントの範囲外のものである。

だが、続くセクションでは、IPSEC DOI のホスト実装の設計で考慮すべき、いくつかの問題について触れる。基本的に本セクションについては、概論であるものとして読むこと。

4.3.1 鍵管理問題 English

ISAKMPを実装することを選ぶ多くのシステムでは、統合されたIKE鍵管理デーモンを実行する保護ドメインを提供することが、目標となることが予測される。保護モードを持つマルチユーザOSの元では、鍵管理デーモンは、特権プロセスとして独立して存在することになるだろう。

そのような環境では、TCP/IPカーネルに鍵要素を組み込めるような API を構成することが望ましい。IPセキュリティアーキテクチャは、ホストTCP/IPカーネルと鍵管理機能との間に、特定のストラクチャ、流れを要求しない。

4.3.2 固定鍵問題 English

固定鍵を実装するホストシステムは、それがIPSECから直接使用されるものであっても、認証目的 ([IKE] セクション5.4参照) のためのものであっても、それが保護されたメモリ領域の外にあったり、TCP/IPカーネルで使用中である場合にも、固定鍵要素を保護するような手順を踏むべきである。 

例えば、ラップトップコンピュータ上で使用するならば、個人のパスワードで暗号化する設定ファイルに固定鍵を保存する人もいるだろう。

使用するOSとインストールされるユーティリティソフトによって変わるが、固定鍵をTCP/IPカーネルに渡してしまうと、もう保護することが出来ないということもあるだろう。だが、システムの起動時に、さらなる認証なしで簡単に再生できるようなことがあってはならない。

4.3.3 ホストポリシー問題 English

一晩でIPSECへの移行が済むと考えるのは現実的ではない。ホストシステムが どのシステムと安全に話す必要があり、どのシステムから安全に話される必要があるを記載した、融通のきくポリシーリストを用意しなければならない。プロキシ ファイアウォールのアドレスについての注意書きも必要だろう。

最小限、IPアドレス、ネットマスク、安全が必要かどうかのフラグについて確定したリストが必要だろう。

より融通が利く実装のためには、ワイルドカードを使ったDNS名 (例、'*.foo.bar')、 入/出のビットマスク、さらに必要ならファイアウォールのアドレスが 載ったリストが必要だ。ワイルドカードDNS名は、入/出のIPアドレスと一致させるために、ビットマスクはセキュリティを確保するかどうかとその方向を決めるために使われ、オプションのファイアウォールのアドレスは、中継ファイアウォールを通して対象システムとの接続するための、トンネルモードが必要がどうかを示す。

4.3.4 証明書管理 English

証明書を使った認証方式を実装するホストシステムには、証明書の取得、それのデータベースを管理する機構が必要になる。

セキュアDNSは証明書配送機構の一つであるが、短期的には、セキュアDNSを使用できるゾーンの広まりが期待できそうにない、さまざまな理由がある。 一番の理由は、ホストが安全な手段で証明書を手に入れる能力が必要になるだけでなく、他のシステムが使う自身の証明書を送り出せなければならないからだ。

動的な証明書発見機構やプロトコルが使用可能となった時に、その導入を阻むことになるため、手作業による証明書管理は行なうべきではない。

4.4 IPSEC 番号割り当て English

以下のセクションには、IPSEC DOIの Situation ID、プロトコル ID、Transform ID、AH、ESP、 IPCOMP Transform ID、SA 属性値、ラベル付ドメインID、IDペイロード値、Notifyメッセージ値 についての番号割り当てが載っている。

4.4.1 IPSEC セキュリティプロトコルID English

ISAKMPプロトコル文法は、複数のフェイズIIセキュリティプロトコルスートのネゴシエーションを 一度にまとめてに行なえるように、特別な設計となっている。その結果、以下に挙げるプロトコルスートを 同時にネゴシエートできる。どれとどれを同時にネゴシエートするかは、ホストのポリシーによって決まる。

以下のテーブルは、IPSEC DOI中の ISAKMP プロトコルペイロードから参照される、セキュリティプロトコルIDの値である。

プロトコルID
RESERVED 0
PROTO_ISAKMP 1
PROTO_IPSEC_AH 2
PROTO_IPSEC_ESP 3
PROTO_IPCOMP 4

4.4.1.1 PROTO_ISAKMP English

PROTO_ISAKMP波、ISAKMPプロトコルのフェイズ1の間、メッセージを保護する必要があることを示す。IPSEC DOI で使われる、ある保護メカニズムについては、[IKE]で解説されている。全ての IPSEC DOI の実装は、PROTO_ISAKMP をサポートしなくてはならない

ノート: ISAKMP の値1は、DOI定義全体を通して予約されている。

4.4.1.2 PROTO_IPSEC_AH English

PROTO_IPSEC_AH は、IPパケット認証を指定する。デフォルトのAH変換は、データ発信元による認証、完全性保護、replay検出を行なう。 輸出制限を考慮する場合、PROTO_IPSEC_AH 変換による秘匿性の提供は行なってはならない

 

4.4.1.3 PROTO_IPSEC_ESP English

PROTO_IPSEC_ESP は、IPパケットの秘匿性を指定する。認証が必要な場合は、それはESP変換の中で提供されなければならない。デフォルトのESP変換には、データ発信元認証、完全性保護、replay生検出、秘匿性が含まれる。

 

4.4.1.4 PROTO_IPCOMP English

PROTO_IPCOMP は、[IPCOMP] で定義されている IPペイロード圧縮を指定する。

 

4.4.2 IPSEC ISAKMP変換ID English

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 に追加できるようになっている。

4.4.2.1 KEY_IKE English

KEY_IKEは、[IKE] ドキュメントに定義されている、ハイブリッド ISAKMP/Oakley Diffie-Hellman 鍵交換 (IKE) を指定する。IPSEC DOI のすべての実装は、KEY_IKE をサポートしなければならない

4.4.3 IPSEC AH変換ID English

認証ヘッダ (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)となっている。それ以外のアルゴリズムの実装はオプションであり、 実装してもかまわない。

4.4.3.1 AH_MD5 English

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の仕様は、現在未定義である。

4.4.3.2 AH_SHA English

AH_SHAは、SHA-1を使用するAH変換全般を指定する。実際の保護スートは、これと関連するSA属性リストとともに決定される。汎用SHA変換は現在未定義である。

IPSEC DOI のすべての実装は、Auth (HMAC-SHA) 属性での AH_SHA をサポートしなければならない。このスートは、[HMACSHA]で、HMAC-SHA-1-96変換として定義されている。

その他の認証アルゴリズム属性値と共に使用するAH_SHAの仕様は、現在未定義である。

4.4.3.3 AH_DES English

AH_DESは、DESを使用するAH変換全般を指定する。実際の保護スートは、これと関連するSA属性リストとともに決定される。汎用DES変換は現在未定義である。

IPSEC DOIは、DES-MAC変換を行うための、Auth (DES-MAC) 属性と共に使用するAH_DESを定義している。このモードは、実装しなくてもかまわない。

その他の認証アルゴリズム属性値と共に使用するAH_DESの仕様は、現在未定義である。

4.4.4 IPSEC ESP変換ID English

カプセル化セキュリティペイロード (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) となっている。それ以外のアルゴリズムの実装はオプションであり、実装してもかまわない。

4.4.4.1 ESP_DES_IV64 English

ESP_DES_IV64 は、RFC-1827 と RFC-1829 で定義されている、64ビットIVを使用するDES-CBC変換を指定する。

4.4.4.2 ESP_DES English

ESP_DESは、DES-CBCを使用するDES変換全般を指定する。実際の保護スートは、これと関連するSA属性リストとともに決定される。汎用の変換は現在未定義である。

IPSEC DOIのすべての実装は、Auth (HMAC-MD5) 属性でのESP_DESをサポートしなければならない。このスートは、HMAC MD5[HMACMD5] が提供する認証と完全性のもとでの、[DES]変換として定義されている。

4.4.4.3 ESP_3DES English

ESP_DESは、トリプルDES変換全般を指定する。実際の保護スートは、これと関連するSA属性リストとともに決定される。汎用の変換は現在未定義である。

IPSEC DOIのすべての実装は、Auth (HMAC-MD5) 属性でのESP_3DESをサポートする様、強く要請されている。このスートは、HMAC MD5[HMACMD5] が提供する認証と完全性のもとでの、[ESPCBC]変換として定義されている。

4.4.4.4 ESP_RC5 English

ESP_RC5は、[ESPCBC]で定義されたRC5変換を指定する。

4.4.4.5 ESP_IDEA English

ESP_IDEAは、[ESPCBC]で定義されたIDEA変換を指定する。

4.4.4.6 ESP_CAST English

ESP_CASTは、[ESPCBC]で定義されたCAST変換を指定する。

4.4.4.7 ESP_BLOWFISH English

ESP_BLOWFISHは、[ESPCBC]で定義されたBLOWFISH変換を指定する。

4.4.4.8 ESP_3IDEA English

ESP_3IDEAは、トリプルIDEA変換のために予約されている。

4.4.4.9 ESP_IDEA_IV32 English

ESP_ESP_DES_IV32は、RFC-1827とRFC-1829で定義された、32ビットIVを使用するDES-CBC変換を指定する。

4.4.4.10 ESP_RC4 English

ESP_RC4は、RC4のために予約されている。

4.4.4.11 ESP_NULL English

ESP_NULLは、ESPが秘匿性を提供しない事を指定する。ESPが、認証、完全性保護、replay生検出しか必要としないトンネルリングで使われる時に、ESP_NULLが使われる。

IPSEC DOIのすべての実装は、ESP_NULLをサポートしなければならない。ESP_NULL変換は[ESPNULL]で定義されている。ESP_NULLの仕様に関連した追加の要求については、セクション4.5で解説されている、認証アルゴリズム属性を参照。

4.4.5 IPSEC IPCOMP変換ID English

IP圧縮 (IPCOMP) 変換は、オプションである、IPペイロードの圧縮を提供するためにネゴシエーションされる圧縮アルゴリズムを定義する ([IPCOMP])。以下の表に載っているものは、IPSEC DOI の ISAKMP Proposal ペイロードで定義済みのIPCOMP変換IDである。

変換ID
RESERVED 0
IPCOMP_OUI 1
IPCOMP_DEFLATE 2
IPCOM_LZS 3

4.4.5.1 IPCOMP_OUI English

IPCOMP_OUI は、実装独自の圧縮変換を指定する。IPCOMP_OUI を指定する時は、それに加えてベンダー独自アルゴリズムを指定する属性を使用しなければならない。

4.4.5.2 IPCOMP_DEFLATE English

IPCOMP_DEFLATEは、[DEFLATE] で規定される "zlib" deflate アルゴリズムの使用を指示する。

4.4.5.3 IPCOMP_LZS English

IPCOMP_LZSは、[LZS] で規定される Stac Electronics社のLZSアルゴリズムの使用を指示する。

4.5 IPSEC SA属性 English

以下は、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

クラス値

4.5.1 必須属性サポート English

基本相互運用性を確実にするために、すべての実装では以下の属性全てに対してのネゴシエーションを行えるようになっていなければならない

セマンティックスの自由度を高めるために、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の確立は中断されなければならない

4.5.3 属性ネゴシエーション English

実装は、定義されているがサポートしていないIPSEC DOI属性(もしくは属性値)を受け取った場合、その値が予約されている範囲に入っていないなら、ATTRIBUTES-NOT-SUPPORTED を送るべきであり、SAの確立は中断されなければならない

実装が予約範囲の属性値を受け取った場合、継続するかどうかを、ローカルポリシーに基づいて決めて良い

4.5.4 有効期間通知 English

レスポンダのポリシーに基づくものよりも、大きなSA有効期間がイニシエータから提案された場合、レスポンダには三つの選択肢がある。1)ネゴシエーションを失敗に終わらせる、2)提案されたものよりも少ない有効期間を使ってネゴシエーションを完了させる、3)ネゴシエーションを完了させ、それからレスポンダの真の有効期間を知らせる、アドバイザリ通知をイニシエータに送る。レスポンダがどれを選択するかは、実装やポリシーによる。

後者の場合の相互運用性を確実なものとするために、IPSEC DOI ではレスポンダがイニシエータに通知したい場合のみ、以下の事項が必須である。イニシエータから、レスポンダが受け入れるものよりも長い有効期間が提案された場合、レスポンダは、ISAKMP通知ペイロードを、レスポンダからのIPSEC SAペイロードの交換の中に含めなければならない。この場合に使わなければならない、RESPONDER-LIFETIME通知メッセージは セクション 4.6.3.1で定義されている。

4.6 IPSECペイロードの内容 English

続くセクションは、DOIによってデータ表現が変わる、ISAKMPペイロードについて解説する。

4.6.1 SAペイロード English

次は、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 Format

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

4.6.1.1 IPSECラベル付きドメインID English

次の表は、SAペイロードのSituation/状況フィールド中に含まれる、Labeled Domain/ラベル付きドメインIDフィールドに割り当てられた値の一覧である。

ドメイン
RESERVED 0

4.6.2 Identification/IDペイロードの内容 English

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 Format

IDペイロードの各フィールドは以下のように定義されている。

4.6.2.1 Identification Type値 English

次の表は、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はすべて、交換の認証に使われる証明書のなかに入っているべきである。

4.6.2.2 ID_IPV4_ADDR English

ID_IPV4_ADDRは、4オクテットのIPv4アドレスを示す。

4.6.2.3 ID_FQDN English

ID_FQDNは、省略無しのドメイン名(FQDN)文字列を示す。 "foo.bar.com" が ID_FQDN の例である。文字列には、終端文字を含むべきではない。

4.6.2.4 ID_USER_FQDN English

ID_USER_FQDNは、省略無しのユーザ名文字列を示す。 "piper@foo.bar.com" がID_USER_FQDNの例である。文字列には、終端文字を含むべきではない。

4.6.2.5 ID_IPV4_ADDR_SUBNET English

ID_IPV4_ADDR_SUBNET は、IPv4アドレスの範囲を示す、4オクテットの値2個からなる。最初の値は、IPv4アドレスである。二番目のものは、IPV4ネットマスクである。ネットマスク内で1となっているのは、アドレス中の対応するビットが固定されている事を示し、0となっているものは「ワイルドカード」である事を示すことに注意する事。

4.6.2.6 ID_IPV6_ADDR English

ID_IPV6_ADDRは、16オクテットのIPv6アドレス一個を示す。

4.6.2.7 ID_IPV6_ADDR_SUBNET English

ID_IPV6_ADDR_SUBNET は、IPv6アドレスの範囲を示す、16オクテットの値2個からなる。最初の値はIPv6アドレスである。二番目のものはIPv6ネットマスクである。ネットマスク内で1となっているのは、アドレス中の対応するビットが固定されている事を示し、0となっているものは「ワイルドカード」である事を示すことに注意する事。

4.6.2.8 ID_IPV4_ADDR_RANGE English

ID_IPV4_ADDR_RANGEは、IPv4アドレスの範囲を示す、4オクテットの値2個からなる。最初の値は始まりのIPv4アドレス(範囲に含まれる)であり、二番目の値は終わりのもの(範囲に含まれる)である。指定された二つのアドレスの間のアドレスはすべてリスト中にあるものとして扱う。

4.6.2.9 ID_IPV6_ADDR_RANGE English

ID_IPV6_ADDR_RANGEは、IPv6アドレスの範囲を指定する、16オクテットの値2個からなる。 最初の値は始まりのIPv6アドレス(範囲に含まれる)であり、二番目の値は終わりのもの(範囲に含まれる)である。指定された二つのアドレスの間のアドレスはすべてリスト中にあるものとして扱う。

4.6.2.10 ID_DER_ASN1_DN English

ID_DER_ASN1_DNは、SAを確立するために交換される証明書の対象者の ASN.1 X.500 Distinguished Name [X.501] のバイナリDERエンコーディングを指定する。

4.6.2.11 ID_DER_ASN1_GN English

ID_DER_ASN1_GNは、SAを確立するために交換される証明書の対象者の ASN.1 X.500 General Name[X.509] のバイナリDERエンコーディングを指定する。

4.6.2.12 ID_KEY_ID English

ID_KEY_IDは、Aggressive モードネゴシエーションの認証に、どの共有鍵を使用するかを指示するために必要な、ベンダ独自の情報を渡すために使用されうる、内容が不定のバイトストリームを指定する。

4.6.3 IPSEC通知メッセージ English

ISAKMPは、通知メッセージコードとして、エラーと状態それぞれのメッセージのために、二つのブロックを定義している。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 English

RESPONDER-LIFETIME 状態メッセージは、レスポンダが選んだ IPSEC SA 有効期間を知らせるために使用されることがある。

使用された場合、通知ペイロードの形式は以下の通りでなければならない

実装上の注意: Notification Data/通知データフィールドに属性リストが入っているということは、 通知データフィールドの長さが0で、 Notification Payload/通知ペイロードが対応する属性リストを持つということと 同値である。

4.6.3.2 REPLAY-STATUS English

REPLAY-STATUS 状態メッセージは、対replay生検出を行なうかどうかについての選択についての、レスポンダからの肯定的な確認のために使われる。

使われた時は、Notification Payload/通知ペイロードは以下の形式でなければならない

4.6.3.3 INITIAL-CONTACT English

INITIAL-CONTACT状態メッセージは、片側から他方へ、そことSAを確立するのが始めてである事を通知したい場合に使用される。この通知メッセージの受信側は、送信元が再起動したため、以前のSAとそのに関係する鍵情報にはアクセスできなくなったのだろうとみなして、そのシステムに対しての既存のSAを削除することができる。これが使われる場合、通知データフィールドの内容は空 (null) であるべきである (つまり Payload Length を通知ペイロードのある固定長になるはずである)。

あった場合は、通知ペイロードは以下の形式になっていなければならない

4.7 IPSEC 鍵交換要求事項 English

IPSEC DOI によって追加される鍵交換はない。

 

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

このメモ全体は、安全で認証された方法で暗号鍵情報の配布を行なうために、ISAKMP ([ISAKMP]) と Oakley ([OAKLEY]) を組み合わせた、Internet Key Exchange プロトコル ([IKE]) に付随している。本ドキュメントに載っている、様々なセキュリティプロトコルと変換についての詳しい解説は、関連する基礎ドキュメントや暗号参考文献に載っている。

 

6 IANA についての考慮 English

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

6.1 IPSEC Situation Definition/状況定義 English

Situation 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 English

IPSEC ISAKMP 変換ID は、ネゴシエーションで使われる鍵交換プロトコルを表わす8ビットの値である。新ISAKMP変換IDの割当の要求は、要求する鍵交換プロトコルを解説するRFCによらなければならない。[IKE] は、そのようなドキュメントの一つである。

標準化目的でない (つまり、Informatial/広報やexperimental/実験) RFCであるなら、RFCを出し変換IDが割り当てられる前に、IESGによって明確にレビューされ承認されなければならない。

249から255までの値は、内輪のシステムの間でのプライベート利用のために予約されている。

6.4 IPSEC AH 変換 ID English

IPSEC AH 変換IDは、AHに対して完全性保護を提供するために使われる、ある一つのアルゴリズムを表わす8ビットの値である。新 AH 変換 ID の割当の要求は、AHフレームワーク ([AH]) 内でのアルゴリズムの使用方法を解説するRFCによらなければならない。

標準化目的でない (つまり、Informatial/広報やexperimental/実験) RFCであるなら、RFCを出し変換IDが割り当てられる前に、IESGによって明確にレビューされ承認されなければならない。

249から255までの値は、内輪のシステムの間でのプライベート利用のために予約されている。

6.5 IPSEC ESP 変換 ID English

IPSEC ESP変換IDは、ESPに対してセキュリティ保護を提供するために使われる、ある一つのアルゴリズムを表わす8ビットの値である。新ESP変換IDの割当の要求は、ESPフレームワーク ([ESP]) 内でのアルゴリズムの使用方法を解説するRFCによらなければならない。

標準化目的でない (つまり、Informatial/広報やexperimental/実験) RFCであるなら、RFCを出し変換IDが割り当てられる前に、IESGによって明確にレビューされ承認されなければならない。

249から255までの値は、内輪のシステムの間でのプライベート利用のために予約されている。

6.6 IPSEC IPCOMP 変換 ID English

IPSEC 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 属性 English

IPSEC SA 属性は、16ビットの種類とその値からなっている。IPSEC SA 属性は、様々な値をISAKMP 端間で受け渡すために使用される。新IPSEC SA 属性の割当の要求は、属性のエンコーディング (基本/可変長) とそのリーガル値を解説した、Internet Draft によらなければならない。本ドキュメントのセクション4.5は、そのような解説の例である。

32001から32767の値は、内輪のシステムの間でのプライベート利用のために予約されている。

6.9 IPSEC ID English

IPSEC IDは、可変長のIDペイロードの解釈を識別子として使用される8ビットの値である。新IPSEC IDの割当の要求は、IPSEC内でのIDの使用方法について解説するRFCによらなければならない。

標準化目的でない (つまり、Informatial/広報やexperimental/実験) RFCであるなら、RFCを出し変換IDが割り当てられる前に、IESGによって明確にレビューされ承認されなければならない。

249から255までの値は、内輪のシステムの間でのプライベート利用のために予約されている。

6.10 IPSEC通知メッセージ English

IPSEC通知メッセージは、各DOIごとにISAKMPによって予約されている値の範囲から取られる16ビットの値である。エラーメッセージのために一つの範囲(8192から16383)、状態メッセージのために別の範囲(24576032767)がある。新通知メッセージの割当の要求は、IPSEC内でのそのIDの使用方法について解説する Internet Draft によらなければならない。

16001から16383と、32001から32767の値は、内輪のシステムの間でのプライベート利用のために予約されている。

 

7 変更履歴 English

7.1 V9 からの変更 English

7.2 V8 からの変更 English

7.3 V7 からの変更 English

7.4 V6 からの変更 English

以下の変更は、IPSEC DOI V6 に関連して行なわれた。

7.5 V5 からの変更 English

以下の変更は、IPSEC DOI V5 に関連して行なわれた。

7.6 V4 からの変更 English

以下の変更は、IETF ミュンヘン会合に先立って IPSEC メイリングリストに投稿された、IPSEC DOI V3 に関連して行われた。

 

謝辞 English

本書は、その一部を Douglas Maughan、mark Schertler、Mark Schneider、Jeff Turner、Dan Harkins、Dave Carrel による、先の成果によっている。Matt Thomas、Roy Pereira、Greg Carter、Ran Atkinson は、提言と、多くの場合、テキストを与えてくれた。

 

参考文献

[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年.

著者のアドレス

Derrell Piper
Network Alchemy
1521.5 Pacific Ave
Santa Cruz, California, 95060
United States of America
電話: +1 408 460-3822
EMail: ddp@network-alchemy.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.