[要約] 要約：RFC 2410は、IPsecと共に使用されるNULL暗号化アルゴリズムについて説明しています。NULL暗号化アルゴリズムは、データの暗号化を行わずにIPsecのセキュリティサービスを提供します。目的：RFC 2410の目的は、NULL暗号化アルゴリズムの仕様と使用方法を提供し、IPsecのセキュリティサービスを実装する際の選択肢としてNULL暗号化を提供することです。
Network Working Group R. Glenn
Request for Comments: 2410 NIST
Category: Standards Track S. Kent
BBN Corp
November 1998
The NULL Encryption Algorithm and Its Use With IPsec
NULL暗号化アルゴリズムとIPsecでのその使用
Status of this Memo
本文書の状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
Abstract
概要
This memo defines the NULL encryption algorithm and its use with the IPsec Encapsulating Security Payload (ESP). NULL does nothing to alter plaintext data. In fact, NULL, by itself, does nothing. NULL provides the means for ESP to provide authentication and integrity without confidentiality.
このメモは、NULL暗号化アルゴリズムと、IPsecカプセル化セキュリティペイロード（ESP）でのその使用を定義しています。 NULLは平文データを変更するために何もしません。実際、NULL自体は何もしません。 NULLは、ESPが機密性なしで認証と整合性を提供する手段を提供します。
Further information on the other components necessary for ESP implementations is provided by [ESP] and [ROAD].
ESPの実装に必要なその他のコンポーネントに関する詳細情報は、[ESP]と[ROAD]によって提供されます。
This memo defines the NULL encryption algorithm and its use with the IPsec Encapsulating Security Payload [ESP] to provide authentication and integrity without confidentiality.
このメモは、NULL暗号化アルゴリズムと、IPsecカプセル化セキュリティペイロード[ESP]でのその使用を定義し、機密性なしで認証と整合性を提供します。
NULL is a block cipher the origins of which appear to be lost in antiquity. Despite rumors that the National Security Agency suppressed publication of this algorithm, there is no evidence of such action on their part. Rather, recent archaeological evidence suggests that the NULL algorithm was developed in Roman times, as an exportable alternative to Ceaser ciphers. However, because Roman numerals lack a symbol for zero, written records of the algorithm's development were lost to historians for over two millennia.
NULLは、その起源が古代に失われたように見えるブロック暗号です。国家安全保障局がこのアルゴリズムの公開を抑制したという噂にもかかわらず、そのような行動の証拠はありません。むしろ、最近の考古学的証拠は、NULLアルゴリズムがCeaser暗号のエクスポート可能な代替としてローマ時代に開発されたことを示唆しています。しかし、ローマ数字にはゼロを表す記号がないため、アルゴリズムの開発に関する書かれた記録は2千年以上にわたって歴史家たちに失われました。
[ESP] specifies the use of an optional encryption algorithm to provide confidentiality and the use of an optional authentication algorithm to provide authentication and integrity. The NULL encryption algorithm is a convenient way to represent the option of not applying encryption. This is referred to as ESP_NULL in [DOI].
[ESP]は、機密性を提供するオプションの暗号化アルゴリズムの使用と、認証と整合性を提供するオプションの認証アルゴリズムの使用を指定します。 NULL暗号化アルゴリズムは、暗号化を適用しないオプションを表す便利な方法です。これは、[DOI]ではESP_NULLと呼ばれています。
The IPsec Authentication Header [AH] specification provides a similar service, by computing authentication data which covers the data portion of a packet as well as the immutable in transit portions of the IP header. ESP_NULL does not include the IP header in calculating the authentication data. This can be useful in providing IPsec services through non-IP network devices. The discussion on how ESP_NULL might be used with non-IP network devices is outside the scope of this document.
IPsec認証ヘッダー[AH]仕様は、パケットのデータ部分とIPヘッダーのトランジット部分の不変をカバーする認証データを計算することにより、同様のサービスを提供します。 ESP_NULLは、認証データの計算にIPヘッダーを含みません。これは、非IPネットワークデバイスを介してIPsecサービスを提供する場合に役立ちます。 ESP_NULLが非IPネットワークデバイスでどのように使用されるかについての説明は、このドキュメントの範囲外です。
In this memo, NULL is used within the context of ESP. For further information on how the various pieces of ESP fit together to provide security services, refer to [ESP] and [ROAD].
このメモでは、NULLがESPのコンテキスト内で使用されています。 ESPのさまざまな部分を組み合わせてセキュリティサービスを提供する方法の詳細については、[ESP]および[ROAD]を参照してください。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC 2119]で説明されているように解釈されます。
NULL is defined mathematically by the use of the Identity function I applied to a block of data b such that:
NULLは、次のようなデータブロックbに適用したIdentity関数を使用して数学的に定義されます。
NULL(b) = I(b) = b
Like other modern ciphers, e.g., RC5 [RFC-2040], the NULL encryption algorithm can make use of keys of varying lengths. However, no measurable increase in security is afforded by the use of longer key lengths.
RC5 [RFC-2040]などの他の最新の暗号と同様に、NULL暗号化アルゴリズムでは、さまざまな長さの鍵を使用できます。ただし、より長いキーの長さを使用しても、セキュリティの測定可能な増加はありません。
Because of the stateless nature of the NULL encryption algorithm, it is not necessary to transmit an IV or similar cryptographic synchronization data on a per packet (or even a per SA) basis. The NULL encryption algorithm combines many of the best features of both block and stream ciphers, while still not requiring the transmission of an IV or analogous cryptographic synchronization data.
NULL暗号化アルゴリズムはステートレスであるため、パケットごと（またはSAごと）にIVまたは同様の暗号同期データを送信する必要はありません。 NULL暗号化アルゴリズムは、ブロック暗号とストリーム暗号の両方の優れた機能の多くを組み合わせていますが、IVまたは類似の暗号同期データの送信はまだ必要ありません。
NULL has a block size of 1 byte, thus padding is not necessary.
NULLのブロックサイズは1バイトであるため、パディングは不要です。
The NULL encryption algorithm is significantly faster than other commonly used symmetric encryption algorithms and implementations of the base algorithm are available for all commonly used hardware and OS platforms.
NULL暗号化アルゴリズムは、他の一般的に使用される対称暗号化アルゴリズムよりも大幅に高速であり、基本アルゴリズムの実装は、一般的に使用されるすべてのハードウェアおよびOSプラットフォームで利用できます。
The following is a set of test vectors to facilitate in the development of interoperable NULL implementations.
以下は、相互運用可能なNULL実装の開発を容易にするための一連のテストベクトルです。
test_case = 1 data = 0x123456789abcdef data_len = 8 NULL_data = 0x123456789abcdef
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"
test_case = 2 data = "ネットワークセキュリティの人々はユーモアの奇妙な感覚を持っています" data_len = 53 NULL_data = "ネットワークセキュリティの人々はユーモアの奇妙な感覚を持っています"
ESP_NULL is defined by using NULL within the context of ESP. This section further defines ESP_NULL by pointing out particular operational parameter requirements.
ESP_NULLは、ESPのコンテキスト内でNULLを使用して定義されます。このセクションでは、特定の運用パラメーター要件を指摘することにより、ESP_NULLをさらに定義します。
For purposes of IKE [IKE] key extraction, the key size for this algorithm MUST be zero (0) bits, to facilitate interoperability and to avoid any potential export control problems.
IKE [IKE]キー抽出の目的で、このアルゴリズムのキーサイズはゼロ（0）ビットである必要があり、相互運用性を促進し、潜在的な輸出規制問題を回避する必要があります。
To facilitate interoperability, the IV size for this algorithm MUST be zero (0) bits.
相互運用性を促進するために、このアルゴリズムのIVサイズはゼロ（0）ビットでなければなりません。
Padding MAY be included on outgoing packets as specified in [ESP].
[ESP]で指定されているように、パディングが発信パケットに含まれる場合があります。
The NULL encryption algorithm offers no confidentiality nor does it offer any other security service. It is simply a convenient way to represent the optional use of applying encryption within ESP. ESP can then be used to provide authentication and integrity without confidentiality. Unlike AH these services are not applied to any part of the IP header. At the time of this writing there is no evidence to support that ESP_NULL is any less secure than AH when using the same authentication algorithm (i.e. a packet secured using ESP_NULL with some authentication algorithm is as cryptographically secure as a packet secured using AH with the same authentication algorithm).
NULL暗号化アルゴリズムは機密性を提供せず、他のセキュリティサービスも提供しません。これは、ESP内で暗号化を適用するオプションの使用を表す便利な方法です。その後、ESPを使用して、機密性なしで認証と整合性を提供できます。 AHとは異なり、これらのサービスはIPヘッダーのどの部分にも適用されません。この記事の執筆時点では、同じ認証アルゴリズムを使用した場合、ESP_NULLがAHよりも安全性が低いことをサポートする証拠はありません（つまり、ESP_NULLを使用して保護されたパケットは、認証アルゴリズムによって、AHを使用して保護されたパケットと同じくらい暗号的に安全です。認証アルゴリズム）。
As stated in [ESP], while the use of encryption algorithms and authentication algorithms are optional in ESP, it is imperative that an ESP SA specifies the use of at least one cryptographically strong encryption algorithm or one cryptographically strong authentication algorithm or one of each.
[ESP]で述べたように、ESPでは暗号化アルゴリズムと認証アルゴリズムの使用はオプションですが、ESP SAは少なくとも1つの暗号学的に強力な暗号化アルゴリズムまたは1つの暗号学的に強力な認証アルゴリズムまたはそれぞれの使用を指定することが不可欠です。
At the time of this writing there are no known laws preventing the exportation of NULL with a zero (0) bit key length.
これを書いている時点では、キー長がゼロ（0）のNULLのエクスポートを禁止する既知の法律はありません。
Pursuant to the provisions of [RFC-2026], the authors represent that they have disclosed the existence of any proprietary or intellectual property rights in the contribution that are reasonably and personally known to the authors. The authors do not represent that they personally know of all potentially pertinent proprietary and intellectual property rights owned or claimed by the organizations they represent or third parties.
[RFC-2026]の規定に従い、著者は、著者に合理的かつ個人的に知られている貢献における所有権または知的財産権の存在を開示したことを表明します。著者は、彼らが代表する組織または第三者が所有または主張するすべての潜在的に適切な所有権および知的財産権を個人的に知っていることを表明しません。
Steve Bellovin suggested and provided the text for the Intellectual Property Rights section.
Steve Bellovinは、知的財産権セクションのテキストを提案して提供しました。
Credit also needs to be given to the participants of the Cisco/ICSA IPsec & IKE March 1998 Interoperability Workshop since it was there that the need for this document became apparent.
Cisco / ICSA IPsec＆IKE 1998年3月の相互運用性ワークショップの参加者にも、このドキュメントの必要性が明らかになったため、クレジットを与える必要があります。
[ESP] Kent, S., and R. Atkinson, "IP Encapsulating Security Payload", RFC 2406, November 1998.
[ESP]ケント、S。、およびR.アトキンソン、「IPカプセル化セキュリティペイロード」、RFC 2406、1998年11月。
[AH] Kent, S., and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[AH]ケント、S。、およびR.アトキンソン、「IP認証ヘッダー」、RFC 2402、1998年11月。
[ROAD] Thayer, R., Doraswamy, N., and R. Glenn, "IP Security Document Roadmap", RFC 2411, November 1998.
[ROAD] Thayer、R.、Doraswamy、N。、およびR. Glenn、「IP Security Document Roadmap」、RFC 2411、1998年11月。
[DOI] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2408, November 1998.
[DOI]パイパー、D。、「ISAKMPの解釈のインターネットIPセキュリティドメイン」、RFC 2408、1998年11月。
[IKE] Harkins, D., and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[IKE] Harkins、D。、およびD. Carrel、「The Internet Key Exchange（IKE）」、RFC 2409、1998年11月。
[RFC-2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC-2026] Bradner、S.、「インターネット標準プロセス-リビジョン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, October 1996
[RFC-2040] Baldwin、R。、およびR. Rivest、「RC5、RC5-CBC、RC5-CBC-Pad、およびRC5-CTSアルゴリズム」、RFC 2040、1996年10月
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC-2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
Rob Glenn NIST
ロブグレンNIST
EMail: rob.glenn@nist.gov
Stephen Kent BBN Corporation
スティーブンケントブバンコーポレーション
EMail: kent@bbn.com
The IPsec working group can be contacted through the chairs:
IPsecワーキンググループは、議長を通じて連絡を取ることができます。
Robert Moskowitz ICSA
ロバートモスコウィッツICSA
EMail: rgm@icsa.net
Ted T'so Massachusetts Institute of Technology
Ted T'soマサチューセッツ工科大学
EMail: tytso@mit.edu
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
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.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。