| ネットワーク WG Request for Comments： 2411 分類： 情報提供 |
R. Thayer Sable Technology Corporation N. Doraswamy Bay Networks, Inc R.Glenn NIST 1998年11月 |
IPsec 文書ロードマップ
(IP Security Document Roadmap)
このメモは、インターネットコミュニティに対して情報提供を行うものです。いかなる種類のインターネット標準も、このメモでは指定していません。このメモの配布に制限はありません。
著作権表記
Copyright (C) The Internet Society (1998). All Rights Reserved.
IPsec プロトコル群は、IP 層においてプライバシーと認証サービスを提供するために使用されます。このプロトコル群を定義するために、いくつかの文書が使用されています。ここでは、IPsec プロトコルをカバーする様々な文書の構成と相互の関連について述べることにします。この文書には、各文書の内容、および新しく記述される暗号化アルゴリズムと認証アルゴリズムに関する文書の内容が記載されています。
1. はじめに
4.1 暗号化および認証アルゴリズム
4.2 暗号化アルゴリズム
4.3 認証アルゴリズム5. セキュリティについての考慮事項
この文書では、[ESP] で定義される ESP プロトコルでの新しい暗号化アルゴリズムと認証アルゴリズムの使用法、および [AH] で定義される AH プロトコルでの新しい認証アルゴリズムの使用法についての付帯的な仕様書を記述するためのガイドラインを提供することを目的としています。ESP と AH は [Arch] で定義される IP セキュリティアーキテクチャの一部です。最初の文書セットの開発途中だけでなく、基本文書が RFC の状態となった後においても、ESP と AH に新しい暗号化アルゴリズムや認証アルゴリズムを追加するための広く知られた手順が必要とされています。以下のガイドラインに従うことにより、新しいアルゴリズムの追加が簡素化され、冗長な文書を削減することができます。
新しく暗号化アルゴリズム文書や認証アルゴリズム文書を書く際に念頭に置くことは、ESP および AH での特定のアルゴリズムの適用に集中した内容にすることです。一般的な ESP と AH の概念、定義、および問題については、ESP と AH の文書でカバーされています。アルゴリズム自体は、これらの文書では定義されません。これにより、新しいアルゴリズムを追加し、また、所定のアルゴリズムと他のアルゴリズムの相互関係について指定することができます。情報の重複と、大量の文書の発行（いわゆる、「ドラフトの急増」の影響）を避けるという目標を達成することを意図しています。
IPsec プロトコルのセットを定義する文書は、7 つのグループに分けられます。これを図 1 に示します。一般的な概念、セキュリティに関する要求条件、定義、IPsec 技術を定義する仕組みについて幅広くカバーするのが、メインのアーキテクチャ文書です。
ESP プロトコル文書と AH プロトコル文書は、それぞれのプロトコルのパケットフォーマットと一般的な問題についてカバーします。これらのプロトコル文書には、必要に応じて、デフォルトのパディング内容や、実装に必須のアルゴリズムのデフォルト値なども含まれます。これらの文書では、Domain Of Interpretation 文書 [DOI] での一部の値が指示されます。ここで、DOI 文書自体は、IANA の Assignd Numbers メカニズムの一部であり、DOI で定義される値は広く知られていることに注意してください。この仕組みに関する詳細については、[DOI] を参照してください。
左側の「暗号化アルゴリズム」文書群は、ESP で使用される様々な暗号化アルゴリズムを定義する文書群です。これらの文書は、この体系に適合することが意図されており、ESP プロトコル文書や認証アルゴリズム文書との内容の重複を避けるようにする必要があります。この文書の例として、[DES-Detroit] 文書や [CBC] 文書があります。これらの暗号化アルゴリズムまたはその他のアルゴリズムが ESP に使用される場合、DOI 文書では、暗号化アルゴリズム識別子などのある特定の値を示さなければならないため、これらの文書では DOI への入力が提供されます。
右側の「認証アルゴリズム」文書群は、ESP と AH の両方で使用される様々な認証アルゴリズムを定義する文書群です。これらの文書は、この体系に適合することが意図されており、AH プロトコル文書や暗号化アルゴリズム文書との内容の重複を避けるようにする必要があります。この文書の例として、[HMAC-MD5] 文書や [HMAC-SHA-1] 文書があります。これらのアルゴリズムまたはその他のアルゴリズムが ESP または AH のどちらかで使用される場合、DOI 文書は、アルゴリズム番号などのある特定の値を示さなければならないため、これらの文書では DOI への入力が提供されます。
最下部の「鍵管理文書」は、IETF スタンダードトラックの鍵管理規則を定義する文書です。これらの文書も DOI に対してある特定の値を提供します。鍵管理の問題についてはこの文書で指示されるべきであり、例えば ESP および AH プロトコル文書では指示されないことに注意してください。現在、これには [ISAKMP]、[Oakley]、[Resolution] が相当します。
中間にある DOI 文書には、文書を相互に関係付けるために他の文書に必要な値が含まれます。例えば、暗号化アルゴリズム、認証アルゴリズム、および鍵の有効期間のような運用上のパラメータがこの文書に含まれる値となります。
+--------------+ | Architecture | +--------------+ v v +<-<-<-<-+ +->->->->+ v v +----------+ +----------+ | ESP | | AH | | Protocol | | Protocol | +----------+ +----------+ v v v v v +->->->->->->->->+ v v v v v v v v v v v v v +------------+ +----------------+ v v | +------------+ | +----------------+ v v | | Encryption | | | Authentication | v v +-| Algorithm | +-| Algorithm | v v +------------+ +----------------+ v v v v v v v +-----+ v v +>->->->-+->->->->| DOI |<-<-<-<-+-<-<-<-<-+ +-----+ ^ ^ +------------+ | KEY | | MANAGEMENT | +------------+ 図 1. IPsec 文書体系
暗号化アルゴリズムと認証アルゴリズムを異なる文書で定義することにより、ESP と共に使用する場合、要求されたアルゴリズムに必要な鍵素材の長さを鍵管理プロトコルがいかにして知るのかという問題が起きます。さらに、鍵素材をどのように分割するのかという問題もあります。これは、「スライシングとダイシング」情報として知られるものです。
暗号化アルゴリズム文書と認証アルゴリズム文書では、それぞれの鍵属性（例えば、パディング方法、パリティ ビットの位置、複数鍵アルゴリズムでの鍵の順序、そして長さなど）を指定する必要があります。鍵管理プロトコルは、必要な長さの鍵素材を生成するために、各アルゴリズム文書で指定される鍵長を使用する必要があります。
鍵管理プロトコルは、個々のアルゴリズム用の鍵を生成するために十分な強度と長さを持つ鍵素材を生成します。IPsec アーキテクチャ文書では、複数鍵が要求される場合（例えば、認証を伴う ESP など）の、ひとかたまりの鍵素材からの鍵の抽出方法が指定されています。暗号化アルゴリズム文書および認証アルゴリズム文書では、各アルゴリズム用の鍵長と強度を指定する必要があります。ただし、スライシングやダイシングを行うために鍵素材全体をカーネルに渡すのかどうか、そして、鍵が鍵管理プロトコルによってスライシングやダイシングされるかどうかは、実装の問題です。AH プロトコル文書には、このような要求条件は存在しません。
特定の暗号化アルゴリズムおよび認証アルゴリズムの使用法を定義する文書には、その暗号化アルゴリズムや認証アルゴリズムに特有の情報が含まれる必要があります。この章では、提供される必要のある情報について列挙することにします。この文書体系では以下のことを意図しています。
- 一般的なプロトコル情報は、ESP および AH プロトコルのそれぞれの文書に記載
- 鍵管理情報は、鍵管理文書に記載
- 調整可能な項目で割り当てられる値および定数は DOI 文書に記載
暗号化アルゴリズムおよび認証アルゴリズムは、オプションのパラメータを要求したり、オプションの動作モードを持ったりします（例えば、IV、認証データ長、鍵長）。大量のアルゴリズム特有のパラメータを調整しなければならない鍵管理の複雑さをなくすために、技術的に妥当かつ実現可能である場合には、暗号化アルゴリズムおよび認証アルゴリズム文書では、これらのパラメータに固定値が選択されます。
以下の情報は一般的なガイドラインとなることのみを意図していることに注意してください。
この章では、暗号化アルゴリズム文書および認証アルゴリズム文書の両方に含まれる必要のある情報について説明します。
鍵素材
- （最小値、最大値、推奨値、要求値を含む）鍵長。
注釈：「セキュリティに関する考慮事項」の章では、ある特定の鍵長における脆弱性について説明する必要があります。- 推奨または要求される疑似乱数発生器の技術、および十分に強力な鍵を提供するための属性。
[RANDOM] では、セキュリティでの使用で推奨する強力な乱数の生成法について記述されています。- 鍵素材のフォーマット
- 既知の脆弱鍵、または既知の脆弱鍵に関する文書への参照。
- 推奨または要求される、パリティの生成やチェックのような鍵素材の処理。
- 鍵素材の更新頻度に関する要求条件または推奨条件。
性能に関する考慮事項
- 当該アルゴリズムの性能に関する、有用な見積り。
- 有用な比較値（例えば、DES または MD5 との比較）。
- 性能の改善または劣化をもたらす入力サイズなどに関する考慮事項。
ESP 環境での考慮事項
- ある認証規則の使用のような、当該アルゴリズムと他の ESP 機能との間の相互動作に関して知られている問題。
注釈：新しい暗号化アルゴリズムや認証アルゴリズムが ESP に適用される度に、後の文書では、以前に定義されたアルゴリズムとの相互動作の説明が必要となります。ペイロード内容およびフォーマット定義
- ESP および AH プロトコル文書で定義されていない、アルゴリズム特有のフィールドのサイズ、配置、内容に関する仕様（例えば、IV）。
セキュリティに関する考慮事項
- 既知の攻撃に関する議論。
- 脆弱な乱数発生器の使用のような、既知の実装時の落とし穴に関する共通的な議論。
- テストベクトルのような、適切な検証の手続きに関する議論。
[RFC-2202] は、認証アルゴリズムのためのテストベクトルを含む文書の例です。
この章では、暗号化アルゴリズム文書に含まれる必要のある情報について説明します。
暗号化アルゴリズム定義
- 当該アルゴリズムの ESP における使用法に関する一般的な情報。
- 背景資料および正式なアルゴリズムの定義に関する記述。
- 暗号化や認証を含む、ESP が使用する当該暗号化アルゴリズムの機能。
- 知的財産権に関する考慮事項のような、利用に関する問題についての記述。
- FIPS 文書のような背景資料への、IETF 形式での参照。
アルゴリズムの動作モード
- アルゴリズムの動作方法や、ブロックモード、ストリームモード、その他のモードの定義。
- 入力および出力ブロックフォーマットの要求条件。
- 当該アルゴリズムのパディングの要求条件。
注釈：基本となる ESP 文書では、デフォルトのパディングが指定されるため、デフォルトが使用できない場合のみこれが要求されます。- ラウンド数のような、アルゴリズム特有の動作パラメータ。
- オプションパラメータおよびオプション動作方法の確認と、明確な技術的説明のある、合理的な決められた値および方法の抽出。
- 決められた値および方法を使用すべきでない理由についての明確な技術的説明のある、値および方法をオプションとしておく必要のあるオプションパラメータの確認。
- 固定にできないアルゴリズム特有のオプションパラメータのデフォルトと必須の範囲。
この章では、認証アルゴリズム文書に含まれる必要のある情報について説明します。多くの場合、認証アルゴリズムは、ESP および AH のどちらでも同じように動作します。これは、1 つの認証アルゴリズム文書で記述される必要があります。
認証アルゴリズム定義
- 当該認証アルゴリズムの ESP および AH における使用法に関する一般的な情報。
- 背景資料および正式なアルゴリズムの定義に関する記述。
- 当該認証アルゴリズムの機能
- 知的財産権に関する考慮事項のような、利用に関する問題についての記述。
- FIPS 文書や基本となるアルゴリズムの最終定義書のような背景資料への、IETF 形式での参照。
アルゴリズムの動作モード
- アルゴリズムの動作方法の定義。
- ラウンド数や入出力ブロックフォーマットのような、アルゴリズム特有の動作パラメータ。
- 当該アルゴリズムの暗黙的および明示的パディングの要求条件。
注釈：AH プロトコル文書では、デフォルトの認証データフィールドのパディング方式が指定されます。
これは、デフォルトが使用できない場合のみ要求されます。- オプションパラメータおよびオプション動作方法の確認と、明確な技術的説明のある、合理的な決められた値および方法の抽出。
- 決められた値および方法を使用すべきでない理由についての明確な技術的説明のある、値および方法をオプションとしておく必要のあるオプションパラメータの確認。
- 固定にできないアルゴリズム特有のオプションパラメータのデフォルトと必須の範囲。
- 当該アルゴリズムのための認証データの比較規則。
注釈：AH プロトコル文書では、デフォルトの認証データの検証方式が指定されます。
これは、デフォルトが使用できない場合のみ要求されます（例えば、署名付きハッシュを使用する場合）。
この文書は、暗号化アルゴリズム文書および認証アルゴリズム文書を執筆するための、文書体系とガイドラインを提供するものです。読者は、IPsec アーキテクチャ、ESP プロトコル、AH プロトコル、暗号化アルゴリズム、認証アルゴリズムの各文書で説明される、すべてのセキュリティ手続きとガイドラインに従う必要があります。多くの暗号化アルゴリズムは、ある種の認証の仕組みとともに使用されない場合には、その暗号化アルゴリズムは安全であると見なされないことに注意してください。
この文書を執筆するにあたって、いくつかのインターネットドラフトを参照しました。それらの文書は、IETF スタンダードトラック上にあるかどうかによって、IETF RFC レポジトリを通して入手できない場合があります。ある場合に、どのバージョンの文書が参照されたかを知りたいと思う読者がいるかも知れません。参照した文書は以下の通りです。
- DES-Detroit：これは ESP の ANX Workshop スタイルであり、Hughes のドラフトをもとに Cheryl Madson が更新したものが ANX メーリングリスト上で公開されたものです。
- DOI：draft-ietf-ipsec-ipsec-doi-02.txt です。
- 3DES：これは、<the Triple-DES shim document> です。
- CAST：この文書は、draft-ietf-ipsec-esp-cast-128-cbc-00.txt であり、この文書に対応するために更新されたものです。
- ESP：draft-ietf-ipsec-esp-04.txt であり、1997年の5月/6月に IETF メーリングリストにメールされました。
- AH：draft-ietf-ipsec-auth-05.txt であり、1997年の5月/6月に IETF メーリングリストにメールされました。
- HUGHES：これは、draft-ietf-ipsec-esp-des-md5-03.txt です。
- ISAKMP: ISAKMP を説明する文書は次の 3 つです。draft-ietf-ipsec-isakmp-07.txt、draft-ietf-ipsec-isakmp-oakley-03.txt、draft-ietf-ipsec-ipsec-doi-02.txt 。
[CBC] Periera, R., and R. Adams,
「ESP CBC モード暗号アルゴリズム（The ESP CBC-Mode Cipher Algorithms）」,
RFC 2451, 1998年 11月.[Arch] Kent, S., and R. Atkinson,
「インターネットプロトコルのためのセキュリティアーキテクチャ（Security Architecture for the Internet Protocol）」,
RFC 2401, 1998年 11月.[DES-Detroit] Madson, C., and N. Doraswamy,
「明示的 IV を伴う ESP DES-CBC 暗号アルゴリズム（The ESP DES-CBC Cipher Algorithm With Explicit IV）」,
RFC 2405, 1998年 11月.[DOI] Piper, D.,
「IPSEC における ISAKMP の解釈（The Internet IP Security Domain of Interpretation for ISAKMP）」,
RFC 2407, 1998年 11月.[AH] Kent, S., and R. Atkinson,
「IP 認証ヘッダ（IP Authentication Header）」,
RFC 2402, 1998年 11月.[ESP] Kent, S., and R. Atkinson,
「IP 暗号ペイロード（ESP）（IP Encapsulating Security Payload (ESP)）」,
RFC 2406, 1998年 11月.[HMAC] Krawczyk, K., Bellare, M., and R. Canetti,
「HMAC： メッセージ認証のための鍵付ハッシング（HMAC: Keyed-Hashing for Message Authentication）」,
RFC 2104, 1997年 2月.[HMAC-MD5] Madson, C., and R. Glenn,
「ESP および AH における HMAC-MD5-96 の使用法（The Use of HMAC-MD5 within ESP and AH）」,
RFC 2403, 1998年 11月.[HMAC-SHA-1] Madson, C., and R. Glenn,
「ESP および AH における HMAC-SHA-1-96 の使用法（The Use of HMAC-SHA-1 within ESP and AH）」,
RFC 2404, 1998年 11月.[RANDOM] Eastlake, D., Crocker, S., and J. Schiller, "Randomness Recommendations for Security", RFC 1750, 1994年 12月.
[RFC-2202] Cheng, P., and R. Glenn,
「HMAC-MD5 と HMAC-SHA-1 のためのテストケース（Test Cases for HMAC-MD5 and HMAC-SHA-1）」,
RFC 2202, 1997年 3月.
Rodney Thayer
Sable Technology Corporation
246 Walnut Street
Newton, Massachusetts 02160EMail: mailto:rodney＠sabletech.com
Naganand Doraswamy
Bay NetworksEMail: naganand＠baynetworks.com
Rob Glenn
NISTEMail: rob.glenn＠nist.gov
翻訳者のアドレス
株式会社 NTTデータ
開発本部
馬場 達也EMail: baba＠rd.nttdata.co.jp
Copyright (C) The Internet Society (1998). All Rights Reserved.
本文書とその翻訳は、複製および他に提供することができる。また、この文書に論評や説明を加えたり、その実装を補助するものは、上記の著作権表示およびこの節を付加していれば、全体あるいは一部であっても一切の制約を課されることなく作成、複製、発表、配布できる。ただし、この文書自体に対して、著作権表示やインターネットソサエティもしくは他のインターネット関連団体への参照を取り除くなどの変更を加えてはならない。インターネット標準化過程で定義されている著作権のための手続きに従って、インターネット標準を開発するために必要な場合や、RFC を英語以外の言語に翻訳する必要がある場合はそのかぎりでない。
上記の制限は永続的なものであり、インターネットソサエティもしくはその継承者や譲渡者によって取り消されることはない。
本文書とここに含まれた情報は「無保証」で提供され、インターネットソサエティおよび IETF はすべての保証を明示的にも暗黙的にもおこなわない。その中には、この情報がいかなる権利も侵害していないという保証や、商用利用および特定目的における適合性への保証が含まれる。