NULL 暗号化アルゴリズムと IPsec におけるその使用法
(The NULL Encryption Algorithm and Its Use With IPsec)

本書は、インターネットコミュニティに対してインターネットスタンダードトラックのプロトコルを定義するとともに、それを改良するための議論や提言を求めるものである。このプロトコルの標準化状態およびステータスについては、「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 はすべての保証を明示的にも暗黙的にもおこなわない。その中には、この情報がいかなる権利も侵害していないという保証や、商用利用および特定目的における適合性への保証が含まれる。