|
ネットワークワーキンググループ Request for Comments： 2410 分類： スタンダードトラック |
R.Glenn NIST S. Kent BBN Corp 1998年11月 |
本書は、 インターネットコミュニティに対してインターネットスタンダードトラックのプロトコルを定義するとともに、 それを改良するための議論や提言を求めるものである。 このプロトコルの標準化状態およびステータスについては、 「Internet Official Protocol Standards」(STD 1)の最新版を参照すること。 このメモの配布に制限はない。
Copyright (C) The Internet Society (1998). All Rights Reserved.
このメモでは、NULL暗号化アルゴリズムと、 このアルゴリズムのIPsec暗号ペイロード(ESP)での使用法について定義する。 NULLは平文データに対して全く変更を行わない。 実際、NULLそれ自体は何も行わない。 NULLは、 守秘性なしに認証とインテグリティを提供するための手段をESPに提供するものである。
ESP実装に必要なその他のコンポーネントに関しての詳細は、 [ESP] および [ROAD] にて提供される。
このメモでは、NULL暗号化アルゴリズムと、 IPsec暗号ペイロード [ESP] で守秘性なしに認証とインテグリティを提供するための、 その利用法について定義する。
NULLは、その起源が随分昔の古いブロック暗号である。 National Security Agencyがこのアルゴリズムの発表を禁止したという噂はあるが、 彼らが実際にそうしたという証拠はない。 むしろ、最近の考古学的発見によると、NULLアルゴリズムはローマ時代に、 シーザ暗号の代替として輸出できるアルゴリズムとして開発されたことが示されている。 しかし、ローマ時代の数字には0を現わす記号が存在しなかったため、 このアルゴリズムの開発に関する記録は、 2000年以上にわたって歴史家には不明であった。
[ESP] では、 守秘性を提供するためのオプションの暗号化アルゴリズムの利用法と、 認証およびインテグリティを提供するための、 オプションの認証アルゴリズムの利用法について指定されている。 NULL暗号化アルゴリズムは、 暗号化を適用しないというオプションを表すための便利な手段である。 これは、[DOI] では、 ESP_NULLと呼ばれている。
IPsec認証ヘッダ [AH] の仕様では、 認証データの計算によって、 パケットのデータ部分とIPヘッダの配送中に不変の部分をカバーする同様のサービスが提供されている。 ESP_NULLの認証データの計算では、IPヘッダは含まれない。 これは、非IPネットワーク装置にIPsecサービスを提供する場合に有用である。 ESP_NULLの非IPネットワーク装置での利用法についての議論は、 この文書の範囲外である。
このメモでは、NULLはESP内で使用される。 セキュリティサービスを提供するためにESPの各部分がどのように連携するかということについての詳細は、 [ESP] および [ROAD] を参照すること。
この文書において、しなければならない(MUST)、 してはならない(MUST NOT)、要求される(REQUIRED)、 することになる(SHALL)、することはない(SHALL NOT)、 する必要がある(SHOULD)、しないほうがよい(SHOULD NOT)、 推奨される(RECOMMENDED)、してもよい(MAY)、 選択できる(OPTIONAL)のキーワードが使用された場合は、 [RFC-2119] における定義に沿って解釈されるものとする。
NULLは、データブロックbに適用される恒等式関数Iを使用することによって、 数学的に以下のように定義される。
NULL(b) = I(b) = b
例えばRC5 [RFC-2040] のような他の最近の暗号と同じように、 NULL暗号化アルゴリズムでは様々な長さの鍵を使用することができる。 ただし、 より長い鍵を使用することによるセキュリティの強化に関しての測定値はない。
NULL暗号化アルゴリズムはステートレスであるため、 IVなどの暗号同期データをパケット単位で(SA単位でも)送信する必要はない。 NULL暗号化アルゴリズムは、 IVやそれに似た暗号同期データの送信を必要としない一方で、 ブロック暗号とストリーム暗号の双方の優れた特徴を持ち合わせている。
NULLは1バイトのブロックサイズを持つため、パディングは不要である。
NULL暗号化アルゴリズムは、 一般的に使用される他の対称鍵暗号化アルゴリズムよりはるかに高速であり、 その基本アルゴリズムの実装は、 一般的に使用されるすべてのハードウェアやOSプラットフォーム上で利用可能である。
相互運用可能なNULL実装の開発を促進するために、 以下にテストベクトルのセットを示す。
test_case = 1 data = 0x123456789abcdef data_len = 8 NULL_data = 0x123456789abcdef test_case = 2 data = "Network Security People Have A Strange Sense Of Humor" data_len = 53 NULL_data = "Network Security People Have A Strange Sense Of Humor"
ESP_NULLは、ESPでNULLを使用するために定義される。 この章では、 ある特定の運用パラメータについての要求条件を取り上げることにより、 ESP_NULLをさらに定義していく。
IKE [IKE] 鍵抽出を目的に、相互運用性を促進し、輸出規制の問題を回避するため、 このアルゴリズムの鍵長はゼロ(0)ビットでなければならない(MUST) とする。
相互運用性を促進するため、 このアルゴリズムのIVのサイズはゼロ(0)ビットでなければならない(MUST)とする。
[ESP] の指定に従って、パディングを出力パケットに含んでもよい(MAY)。
NULL暗号化アルゴリズムは、守秘性ばかりでなく、 他のどのようなセキュリティサービスも提供しない。 NULLは単に、 ESP内での暗号化の適用がオプションで使用されることを表す便利な手段である。 これにより、 ESPを守秘性なしで認証とインテグリティを提供するために使用することが可能となる。 AHと異なり、これらのサービスはIPヘッダのどの部分にも適用されない。 この文書の執筆時点では、AHと同じ認証アルゴリズムを使用する場合に、 ESP_NULLがAHより安全性が低いことを証明するような証拠は存在していない (すなわち、ESP_NULLと、 ある認証アルゴリズムを使用して保護されたパケットは、 AHに同じ認証アルゴリズムを使用して保護されたパケットと、 暗号的な安全性は同等である)。
[ESP] において説明されているように、 ESPでは暗号化アルゴリズムと認証アルゴリズムの使用がオプションであるが、 ESP SAでは最低、1つの暗号的に強力な暗号化アルゴリズム、 または1つの暗号的に強力な認証アルゴリズム、 またはそれぞれ1つずつの使用を指定することが必須である。
この文書の執筆時点では、 ゼロ(0)ビットの鍵長を持つNULLの輸出を禁止する法律は存在しない。
[RFC-2026] の規定に準じて、 著者はこのメモにおいて合理的および個人的に著者が知っている所有権および知的財産権の存在を開示することを表明する。 著者が所属する組織および第三者によって所有、要求される、 潜在的に関連するすべての所有権および知的財産権について著者が個人的に知っていることについては表明しない。
Steve Bellovinは知的財産権の章のための文章を提案し、提供してくれた。 Cisco/ICSA IPsec & IKE March 1998 Interoperability Workshopの参加者にも感謝する。 おかげでこの文書の必要性が明らかになった。
[ESP] Kent, S., and R. Atkinson,
「IP暗号ペイロード(ESP)(IP Encapsulating Security Payload)」,
RFC 2406, 1998年11月.
[AH] Kent, S., and R. Atkinson,
「IP 認証ヘッダ(IP Authentication Header)」,
RFC 2402, 1998年11月.
[ROAD] Thayer, R., Doraswamy, N., and R. Glenn,
「IPSEC文書ロードマップ(IP Security Document Roadmap)」,
RFC 2411, 1998年11月.
[DOI] Piper, D.,
「ISAKMP (Internet SAと鍵管理プロトコル)(The Internet IP Security
Domain of Interpretation for ISAKMP)」,
RFC 2408, 1998年11月.
[IKE] Harkins, D., and D. Carrel,
「IKE：インターネット鍵交換(The Internet Key Exchange (IKE))」,
RFC 2409, 1998年11月.
[RFC-2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, 1996年10月.
[RFC-2040] Baldwin, R., and R. Rivest, "The RC5, RC5-CBC, RC5-CBC-Pad, and RC5-CTS Algorithms", RFC 2040, 1996年10月
[RFC-2119] Bradner, S.,
「RFCにおいて要請の程度を示すために用いるキーワード(Key words for
use in RFCs to Indicate Requirement Levels)」,
BCP 14, RFC 2119, 1997年3月.
Rob Glenn
NIST
EMail： rob.glenn＠nist.gov
Stephen Kent
BBN Corporation
EMail： kent＠bbn.com
IPsec WGへは、 以下のチェアを通してコンタクトをとることが可能である。
Robert Moskowitz
ICSA
EMail： rgm＠icsa.net
Ted T'so
Massachusetts Institute of Technology
EMail： tytso＠mit.edu
株式会社 NTTデータ
開発本部
馬場 達也
EMail: baba＠rd.nttdata.co.jp
Copyright (C) The Internet Society (1998). All Rights Reserved.
本文書とその翻訳は、複製および他に提供することができる。 また、この文書に論評や説明を加えたり、その実装を補助するものは、 上記の著作権表示およびこの節を付加していれば、 全体あるいは一部であっても一切の制約を課されることなく作成、複製、 発表、配布できる。 ただし、この文書自体に対して、 著作権表示やインターネットソサエティもしくは他のインターネット関連団体への参照を取り除くなどの変更を加えてはならない。 インターネット標準化過程で定義されている著作権のための手続きに従って、 インターネット標準を開発するために必要な場合や、 RFCを英語以外の言語に翻訳する必要がある場合はそのかぎりでない。
上記の制限は永続的なものであり、 インターネットソサエティもしくはその継承者や譲渡者によって取り消されることはない。
本文書とここに含まれた情報は「無保証」で提供され、 インターネットソサエティおよびIETFはすべての保証を明示的にも暗黙的にもおこなわない。 その中には、この情報がいかなる権利も侵害していないという保証や、 商用利用および特定目的における適合性への保証が含まれる。