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）補遺（DOI）

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）の使用の交渉をサポートしています。

1. Introduction

1. はじめに

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].

キーワードは、このドキュメントに表示される場合、RFC 2119 [bra97]に記載されているように解釈される場合、必要な、必須、必要は、推奨、推奨、勧めてはいけません。

2. IPsec Security Association Attribute

2. IPSEC Security Association属性

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]で定義されています。基本として説明されている属性は、変数としてエンコードされてはなりません。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

予約された0 64ビットシーケンス番号1

3. Attribute Negotiation

3. 属性交渉

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属性（または属性値）を受信する場合、属性を送信する必要があり、セキュリティ協会のセットアップを中止する必要があります。

If an implementation receives any attribute value but the value for 64-bit sequence numbers, the security association setup MUST be aborted.

実装が属性値を受信し、64ビットシーケンス番号の値を受信する場合、セキュリティ協会のセットアップを中止する必要があります。

4. Security Considerations

4. セキュリティに関する考慮事項

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]を組み合わせたインターネットキーExchangeプロトコル[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の基礎となるセキュリティ特性を変更しません。ESNを使用してESNを使用する際には、非常に大量のデータが単一のキーの下で暗号化されている場合に安全な暗号化モードを使用することが重要です。したがって、たとえば、暗号ブロックチェーン（CBC）モードのデータ暗号化標準（DES）は、ESNでの使用には適していません。これは、そのモードの単一のDESキーの下で2^32ブロック以下を暗号化する必要があるためです。同様に、ESPまたはAHで使用される整合性アルゴリズムは、保護されているパケットの数に対して安全である必要があります。アルゴリズムの制限によって課される潜在的なセキュリティの問題を回避するために、SA寿命は、ESNによって課される2^64パケット制限に到達する前に、単一のキーで保護されたデータの量を制限するように設定される場合があります。

5. IANA Considerations

5. IANAの考慮事項

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の表の見出し「値」の下にリストされています。

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ワーキンググループのメンバーに感謝したいと思います。著者はまた、この仕様の編集における彼女の助けについてのカレン・ソの貢献を認めたいと思います。

Normative References

引用文献

[Bra97] Bradner, S., "Key words for use in RFCs to Indicate Requirement Level", BCP 14, RFC 2119, March 1997.

[Bra97] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。

[AH] Kent, S., "IP Authentication Header", RFC 4302, December 2005.

[AH] Kent、S。、「IP認証ヘッダー」、RFC 4302、2005年12月。

[DOI] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.

[doi] Piper、D。、「ISAKMPの解釈のインターネットIPセキュリティドメイン」、RFC 2407、1998年11月。

[ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.

[ESP] Kent、S。、「セキュリティペイロードをカプセル化するIP（ESP）」、RFC 4303、2005年12月。

[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月。

[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.、およびJ. Turner、「インターネットセキュリティ協会および主要管理プロトコル（ISAKMP）」、RFC 2408、1998年11月。

Informative References

参考引用

[OAKLEY] Orman, H., "The OAKLEY Key Determination Protocol", RFC 2412, November 1998.

[Oakley] Orman、H。、「The Oakley Key Deicination Protocol」、RFC 2412、1998年11月。

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エディター機能の資金は現在、インターネット協会によって提供されています。