RFC4304 日本語訳
4304 Extended Sequence Number (ESN) Addendum to IPsec Domain of Interpretation (DOI) for Internet Security Association and KeyManagement Protocol (ISAKMP). S. Kent. December 2005. (Format: TXT=9243 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group S. Kent Request for Comments: 4304 BBN Technologies Category: Standards Track December 2005
コメントを求めるワーキンググループS.ケント要求をネットワークでつないでください: 4304年のBBN技術カテゴリ: 標準化過程2005年12月
Extended Sequence Number (ESN) Addendum to
IPsec Domain of Interpretation (DOI)
for Internet Security Association
and Key Management Protocol (ISAKMP)
インターネットセキュリティ協会とKey Managementプロトコルのための解釈(DOI)のIPsecドメインへの拡張配列番号(ESN)付加物(ISAKMP)
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(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 Security Authentication Header(AH)とEncapsulating Security有効搭載量(超能力)プロトコルは、再生を検出するのに一連番号を使用します。 このドキュメントはインターネットSecurity AssociationとKey Managementプロトコル(ISAKMP)のためにInterpretation(DOI)のインターネットIP Security Domainに拡大について説明します。 これらの拡大は伝統的な32ビットの一連番号か拡張している(64ビット)一連番号(ESNs)の特定のAHか超能力セキュリティ協会の使用の交渉をサポートします。
Kent Standards Track [Page 1] RFC 4304 ESN Addendum to ISAKMP DOI December 2005
ケント規格は2005年12月にRFC4304ESN付加物をISAKMP DOIに追跡します[1ページ]。
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 Authentication Header(AH)[AH]とIP Encapsulating Security有効搭載量(超能力)[超能力]のための仕様は(64ビット)の拡張一連番号の使用のためのオプションについて説明します。 このオプションはIPsec Security Associationの上で高速でデータの非常に大きいボリュームの送信を可能にします、一連番号宇宙疲労困憊を避けるために「再-合わせ」ないで。 このドキュメントは拡張配列番号(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].
キーワードが解釈しなければならない、本書では現れるとき、RFC2119[Bra97]で説明されるようにNOT、REQUIRED、SHALL、SHALL NOT、SHOULD、SHOULD NOT、RECOMMENDED、5月、およびOPTIONALを解釈することになっていなければなりませんか?
2. IPsec Security Association Attribute
2. IPsecセキュリティ協会属性
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)交渉のPhase IIで使用されます。 属性タイプはBasic(B)です。 この属性のコード化はベースISAKMP仕様[ISAKMP]に基づき定義されます。 同じくらい可変な状態で基本的であると記述された属性をコード化してはいけません。 IPsec DOIでの属性コード化の詳細に関して[IKE]を見てください。 また、[IKE]に記載されたすべての制限がIPsec DOIと、そして、この付加物に適用されます。
Attribute Type
属性タイプ
class value type
---------------------------------------------------------
Extended (64-bit) Sequence Number 11 B
階級値タイプ--------------------------------------------------------- (64ビット)の拡張一連番号11B
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.)
このクラスは、Security Associationが64ビットの一連番号を使用すると指定します。 ((64ビット)の拡張一連番号の記述に関して[AH]と[超能力]を見てください。)
RESERVED 0
64-bit Sequence Number 1
予約された0 64ビットの一連番号1
Kent Standards Track [Page 2] RFC 4304 ESN Addendum to ISAKMP DOI December 2005
ケント規格は2005年12月にRFC4304ESN付加物をISAKMP DOIに追跡します[2ページ]。
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.
実装が受信されるなら、aはそれがサポートしないIPsec DOI属性(または、属性値)を定義しました、送られて、ATTRIBUTES NOT SUPPORT SHOULD。セキュリティ協会セットアップを中止しなければなりません。
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.
このメモはインターネット・キー・エクスチェンジプロトコル[IKE]に関係します。(それは、安全で認証された方法における、暗号の合わせることの材料の派生に備えるために、ISAKMP[ISAKMP]とオークリー[オークリー]を結合します)。 関連元にした文書と暗号参照で本書では特定された様々なセキュリティプロトコルと変換の特定の議論を見つけることができます。
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の基本的なセキュリティの特性を変えません。 超能力を伴うESNsを使用するのにおいて、データの非常に大きいボリュームが単一のキーの下で暗号化されるとき安全な暗号化モードを使うのは重要です。 このようにして、例えば、Cipher Block Chaining(CBC)モードによるデータ暗号化規格(DES)はESNとの使用に適していないでしょう、2^32ブロックだけがそのモードで主要な独身のDESの下で暗号化されるべきであるので。 同様に、超能力か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 Security Attribute値を割り当てました。 この値はテーブルの「値」の見出しでセクション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ワーキンググループのメンバーに感謝したがっています。 また、作者は、彼女のためのカレンSeoの貢献がこの仕様の編集で助けると認めたがっています。
Kent Standards Track [Page 3] RFC 4304 ESN Addendum to ISAKMP DOI December 2005
ケント規格は2005年12月にRFC4304ESN付加物をISAKMP DOIに追跡します[3ページ]。
Normative References
引用規格
[Bra97] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Level", BCP 14, RFC 2119, March 1997.
[Bra97] ブラドナー、S.、「Indicate Requirement LevelへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[AH] Kent, S., "IP Authentication Header", RFC 4302, December
2005.
[ああ] ケント、S.、「IP認証ヘッダー」、RFC4302、2005年12月。
[DOI] Piper, D., "The Internet IP Security Domain of
Interpretation for ISAKMP", RFC 2407, November 1998.
[DOI]パイパー、D.、「ISAKMPのための解釈のインターネットIPセキュリティー領域」、RFC2407、1998年11月。
[ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
4303, December 2005.
[超能力] ケント、S.、「セキュリティが有効搭載量(超能力)であるとカプセル化するIP」、RFC4303、2005年12月。
[IKE] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[IKE]ハーキンとD.とD.個人閲覧室、「インターネット・キー・エクスチェンジ(IKE)」、RFC2409 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.、シュナイダー、M.、およびJ.ターナー、「インターネットセキュリティ協会とKey Managementは(ISAKMP)について議定書の中で述べます」、RFC2408、1998年11月。
Informative References
有益な参照
[OAKLEY] Orman, H., "The OAKLEY Key Determination Protocol", RFC
2412, November 1998.
[オークリー] Orman、H.、「オークリーの主要な決断プロトコル」、RFC2412、1998年11月。
Author's Address
作者のアドレス
Stephen Kent BBN Technologies 10 Moulton Street Cambridge, MA 02138 USA
スティーブンケントBBN技術10モールトン・通りMA02138ケンブリッジ(米国)
Phone: +1 (617) 873-3988 EMail: kent@bbn.com
以下に電話をしてください。 +1 (617) 873-3988 メールしてください: kent@bbn.com
Kent Standards Track [Page 4] RFC 4304 ESN Addendum to ISAKMP DOI December 2005
ケント規格は2005年12月にRFC4304ESN付加物をISAKMP DOIに追跡します[4ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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 Editor機能のための基金は現在、インターネット協会によって提供されます。
Kent Standards Track [Page 5]
ケント標準化過程[5ページ]
一覧
スポンサーリンク
