[要約] RFC 4304は、ISAKMP（IKEv1）でIPsecの拡張シーケンス番号（ESN）の交渉を可能にするための属性を定義する標準化トラック文書です。64ビットのシーケンス番号をサポートすることで、再鍵生成なしでの高速・大容量データ転送を実現し、シーケンス番号の枯渇問題を解消します。IPsec DOIに新たな属性タイプを追加し、IKEフェーズ2の交渉で32ビットと64ビットのどちらを使用するかを決定する手順を規定しています。
Network Working Group S. Kent
Request for Comments: 4304 BBN Technologies
Category: Standards Track December 2005
Extended Sequence Number (ESN) Addendum to IPsec Domain of Interpretation (DOI) for Internet Security Association and Key Management Protocol (ISAKMP)
インターネットセキュリティ協会および鍵管理プロトコル（ISAKMP）のためのIPsecドメイン解釈（DOI）への拡張シーケンス番号（ESN）補遺
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 (2005).
Copyright（c）The Internet Society（2005）。
Abstract
概要
The IP Security Authentication Header (AH) and Encapsulating Security Payload (ESP) protocols use a sequence number to detect replay. This document describes extensions to the Internet IP Security Domain of Interpretation (DOI) for the Internet Security Association and Key Management Protocol (ISAKMP). These extensions support negotiation of the use of traditional 32-bit sequence numbers or extended (64- bit) sequence numbers (ESNs) for a particular AH or ESP security association.
IPセキュリティ認証ヘッダー (AH) およびカプセル化セキュリティペイロード (ESP) プロトコルは、シーケンス番号を使用してリプレイを検出します。このドキュメントでは、インターネットセキュリティ協会および鍵管理プロトコル (ISAKMP) のためのインターネット IP セキュリティドメイン解釈 (DOI) の拡張について説明します。これらの拡張機能は、特定の AH または ESP セキュリティ協会に対する従来の 32 ビットシーケンス番号または拡張 (64 ビット) シーケンス番号 (ESN) の使用の交渉をサポートします。
The specifications for the IP Authentication Header (AH) [AH] and the IP Encapsulating Security Payload (ESP) [ESP] describe an option for use of extended (64-bit) sequence numbers. This option permits transmission of very large volumes of data at high speeds over an IPsec Security Association, without rekeying to avoid sequence number space exhaustion. This document describes the additions to the IPsec DOI for ISAKMP [DOI] that are needed to support negotiation of the extended sequence number (ESN) option.
IP認証ヘッダー (AH) [AH] および IP カプセル化セキュリティペイロード (ESP) [ESP] の仕様では、拡張 (64 ビット) シーケンス番号を使用するオプションについて説明されています。このオプションにより、シーケンス番号空間の枯渇を回避するための再鍵生成を行うことなく、IPsec セキュリティ協会を介して非常に大量のデータを高速で送信できるようになります。このドキュメントでは、拡張シーケンス番号 (ESN) オプションの交渉をサポートするために必要な、ISAKMP [DOI] のための IPsec DOI への追加事項について説明します。
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in RFC 2119 [Bra97].
このドキュメントに登場するキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、RFC 2119 [Bra97] に記載されているように解釈されるものとします。
The following SA attribute definition is used in Phase II of an Internet Key Exchange Protocol (IKE) negotiation. The attribute type is Basic (B). Encoding of this attribute is defined in the base ISAKMP specification [ISAKMP]. Attributes described as basic MUST NOT be encoded as variable. See [IKE] for further information on attribute encoding in the IPsec DOI. All restrictions listed in [IKE] also apply to the IPsec DOI and to this addendum.
以下の SA 属性定義は、インターネット鍵交換プロトコル (IKE) 交渉のフェーズ II で使用されます。属性タイプは基本 (B) です。この属性のエンコードは、基本 ISAKMP 仕様 [ISAKMP] で定義されています。基本として記述されている属性は、可変長としてエンコードしてはなりません (MUST NOT)。IPsec DOI における属性エンコードの詳細については、[IKE] を参照してください。[IKE] に記載されているすべての制限は、IPsec DOI およびこの補遺にも適用されます。
Attribute Type
属性タイプ
class value type
---------------------------------------------------------
Extended (64-bit) Sequence Number 11 B
Class Values
クラス値
This class specifies that the Security Association will be using 64-bit sequence numbers. (See [AH] and [ESP] for a description of extended (64-bit) sequence numbers.)
このクラスは、セキュリティ協会が64ビットシーケンス番号を使用することを指定しています。（拡張（64ビット）シーケンス番号の説明については、[AH]および[ESP]を参照してください。）
RESERVED 0 64-bit Sequence Number 1
RESERVED 0、64ビットシーケンス番号 1
If an implementation receives a defined IPsec DOI attribute (or attribute value) that it does not support, an ATTRIBUTES-NOT-SUPPORT SHOULD be sent and the security association setup MUST be aborted.
実装がサポートしていない定義済みの IPsec DOI 属性（または属性値）を受信した場合、ATTRIBUTES-NOT-SUPPORT を送信する必要があり (SHOULD)、セキュリティ協会のセットアップを中止しなければなりません (MUST)。
If an implementation receives any attribute value but the value for 64-bit sequence numbers, the security association setup MUST be aborted.
実装が 64 ビットシーケンス番号の値以外の属性値を受信した場合、セキュリティ協会のセットアップを中止しなければなりません (MUST)。
This memo pertains to the Internet Key Exchange protocol [IKE], which combines ISAKMP [ISAKMP] and Oakley [OAKLEY] to provide for the derivation of cryptographic keying material in a secure and authenticated manner. Specific discussion of the various security protocols and transforms identified in this document can be found in the associated base documents and in the cipher references.
このメモは、ISAKMP [ISAKMP] と Oakley [OAKLEY] を組み合わせて、安全かつ認証された方法で暗号鍵素材の導出を提供するインターネット鍵交換 (IKE) プロトコルに関係します。このドキュメントで特定されたさまざまなセキュリティプロトコルや変換に関する具体的な議論は、関連する基本ドキュメントおよび暗号の参考文献に記載されています。
The addition of the ESN attribute does not change the underlying security characteristics of IKE. In using ESNs with ESP, it is important to employ an encryption mode that is secure when very large volumes of data are encrypted under a single key. Thus, for example, Data Encryption Standard (DES) in Cipher Block Chaining (CBC) mode would NOT be suitable for use with the ESN, because no more than 2^32 blocks should be encrypted under a single DES key in that mode. Similarly, the integrity algorithm used with ESP or AH should be secure relative to the number of packets being protected. To avoid potential security problems imposed by algorithm limitations, the SA lifetime may be set to limit the volume of data protected with a single key, prior to reaching the 2^64 packet limit imposed by the ESN.
ESN 属性の追加は、IKE の基本的なセキュリティ特性を変更しません。ESP で ESN を使用する場合、単一の鍵の下で非常に大量のデータが暗号化される際に安全な暗号化モードを採用することが重要です。したがって、例えば、暗号ブロック連鎖 (CBC) モードのデータ暗号化標準 (DES) は ESN での使用には適していません (NOT be suitable)。なぜなら、そのモードでは単一の DES 鍵の下で 2^32 ブロックを超えて暗号化すべきではないからです。同様に、ESP または AH で使用される整合性アルゴリズムは、保護されるパケット数に対して安全である必要があります。アルゴリズムの制限によって課される潜在的なセキュリティ問題を回避するために、ESN によって課される 2^64 パケットの制限に達する前に、単一の鍵で保護されるデータ量を制限するように SA の有効期間を設定することもできます。
This document contains a "magic" number to be maintained by the IANA. No additional class values will be assigned for this attribute. The IANA has allocated an IPsec Security Attribute value for "Attribute Type". This value is listed under the heading "value" in the table in Section 2.
このドキュメントには、IANA によって管理される「マジックナンバー」が含まれています。この属性に追加のクラス値が割り当てられることはありません。IANA は、「属性タイプ」に対して IPsec セキュリティ属性値を割り当てました。この値は、セクション 2 の表の「value」という見出しの下に記載されています。
Acknowledgements
謝辞
The author would like to thank the members of the IPsec working group. The author would also like to acknowledge the contributions of Karen Seo for her help in the editing of this specification.
著者は IPsec ワーキンググループのメンバーに感謝します。また、この仕様の編集を支援してくれた Karen Seo の貢献に感謝します。
Normative References
引用文献
[Bra97] Bradner, S., "Key words for use in RFCs to Indicate Requirement Level", BCP 14, RFC 2119, March 1997.
[Bra97] Bradner, S., "Key words for use in RFCs to Indicate Requirement Level", BCP 14, RFC 2119, March 1997.
[AH] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[AH] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[DOI] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.
[DOI] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.
[ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[IKE] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[IKE] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[ISAKMP] Maughan, D., Schertler, M., Schneider, M., and J. Turner, "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, November 1998.
[ISAKMP] Maughan, D., Schertler, M., Schneider, M., and J. Turner, "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, November 1998.
Informative References
参考引用
[OAKLEY] Orman, H., "The OAKLEY Key Determination Protocol", RFC 2412, November 1998.
[OAKLEY] Orman, H., "The OAKLEY Key Determination Protocol", RFC 2412, November 1998.
Author's Address
著者の連絡先
Stephen Kent BBN Technologies 10 Moulton Street Cambridge, MA 02138 USA
Stephen Kent BBN Technologies 10 Moulton Street Cambridge、MA 02138 USA
Phone: +1 (617) 873-3988
EMail: kent@bbn.com
Full Copyright Statement
完全な著作権宣言
Copyright (C) The Internet Society (2005).
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントは BCP 78 に含まれる権利、ライセンス、および制限の対象となり、そこに規定されている場合を除き、著者はすべての権利を保持します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
このドキュメントおよびここに含まれる情報は「現状のまま」提供され、貢献者、その代表または後援組織（ある場合）、インターネット協会、およびインターネットエンジニアリングタスクフォースは、明示的か黙示的かを問わず、ここに含まれる情報の使用がいかなる権利も侵害しないという保証、または商品性や特定の目的への適合性に関する黙示の保証を含むがこれらに限定されない、すべての保証を否認します。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF は、このドキュメントに記載されている技術の実装または使用に関連すると主張される可能性のある知的財産権またはその他の権利の有効性や範囲、あるいはそのような権利に基づくライセンスが利用可能であるかどうかの程度に関して、いかなる立場も取りません。また、そのような権利を特定するための独立した調査を行ったことも表明しません。RFC ドキュメントの権利に関する手続きについての情報は、BCP 78 および BCP 79 に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF 事務局に対して行われた IPR 公開のコピー、および利用可能なライセンスの保証、または本仕様の実装者や利用者による当該所有権の使用のための一般的なライセンスや許可を得ようとした試みの結果は、http://www.ietf.org/ipr にある IETF のオンライン IPR リポジトリから入手できます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF は、本標準の実装に必要となる可能性のある技術をカバーする著作権、特許、特許出願、またはその他の所有権について、関係者が注意を喚起することを推奨します。情報は ietf-ipr@ietf.org の IETF 宛に送信してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC エディタ機能の資金は、現在はインターネット協会によって提供されています。