RFC 5930 - Using Advanced Encryption Standard Counter Mode (AES-CTR) with the Internet Key Exchange version 02 (IKEv2) Protocol 日本語訳

URL : https://tools.ietf.org/html/rfc5930
タイトル : RFC 5930 - インターネット鍵交換バージョン02（IKEv2の）プロトコルでのAdvanced Encryption Standardカウンタモード（AES-CTR）を使用して、
翻訳編集 : 自動生成

Internet Engineering Task Force (IETF)                           S. Shen
Request for Comments: 5930                                        Huawei
Category: Informational                                           Y. Mao
ISSN: 2070-1721                             Hangzhou H3C Tech. Co., Ltd.
                                                             NSS. Murthy
                                                 Freescale Semiconductor
                                                               July 2010

       Using Advanced Encryption Standard Counter Mode (AES-CTR)
       with the Internet Key Exchange version 02 (IKEv2) Protocol

Abstract

抽象

This document describes the usage of Advanced Encryption Standard Counter Mode (AES-CTR), with an explicit Initialization Vector, by the Internet Key Exchange version 2 (IKEv2) protocol, for encrypting the IKEv2 exchanges that follow the IKE_SA_INIT exchange.

この文書では、IKE_SA_INIT交換をたどるのIKEv2交換を暗号化するために、インターネットキー交換バージョン2（IKEv2）プロトコルによって、明示的な初期化ベクトルで、高度暗号化標準カウンタモード（AES-CTR）の使用方法について説明します。

Status of This Memo

このメモのステータス

This document is not an Internet Standards Track specification; it is published for informational purposes.

このドキュメントはインターネット標準化過程仕様ではありません。それは、情報提供の目的のために公開されています。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.

このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。 IESGによって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 RFC 5741のセクション2を参照してください。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5930.

このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc5930で取得することができます。

著作権表示

著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。

Table of Contents

   1. Introduction ....................................................2
      1.1. Conventions Used in This Document ..........................3
   2. IKEv2 Encrypted Payload .........................................3
   3. IKEv2 Conventions ...............................................4
   4. Security Considerations .........................................4
   5. IANA Considerations .............................................4
   6. Acknowledgments .................................................4
   7. References ......................................................5
      7.1. Normative References .......................................5
      7.2. Informative References .....................................5

1. Introduction

1. はじめに

The Internet Key Exchange version 2 (IKEv2) protocol [RFC4306] is a component of IPsec used for performing mutual authentication and establishing and maintaining security associations (SAs). [RFC4307] defines the set of algorithms that are mandatory to implement as part of IKEv2, as well as algorithms that should be implemented because they may be promoted to mandatory at some future time. [RFC4307] requires that an implementation "SHOULD" support Advanced Encryption Standard [AES] Counter Mode [MODES] (AES-CTR) as a Transform Type 1 algorithm (encryption).

インターネットキー交換バージョン2（IKEv2）プロトコル[RFC4306]は、セキュリティアソシエーション（SA）の相互認証を実行し、確立し、維持するために使用されるのIPsecの構成要素です。 [RFC4307]は、彼らが何らかの将来の時点で必須に昇格することができるので、実施されるべきであるのIKEv2の一部として実装することが必須であるアルゴリズム、ならびにアルゴリズムのセットを定義します。 [RFC4307]は実装が変換タイプ1アルゴリズム（暗号化）などのAdvanced Encryption Standard [AES]カウンタモード[MODES]（AES-CTR）をサポート "SHOULD" ことを必要とします。

Although [RFC4307] specifies that the AES-CTR encryption algorithm feature SHOULD be supported by IKEv2, no existing document specifies how IKEv2 can support the feature. This document provides the specification and usage of AES-CTR Counter Mode by IKEv2.

[RFC4307]はAES-CTR暗号化アルゴリズム機能はIKEv2のでサポートされるべきであることを規定していますが、既存の文書には、IKEv2のこの機能をサポートできる方法を指定しません。この文書では、IKEv2のでAES-CTRカウンタモードの仕様と使用方法を提供します。

Implementers need to carefully consider the use of AES-CTR over the mandatory-to-implement algorithms in [RFC4307], because the performance improvements of AES-CTR are minimal in the context of

AES-CTRのパフォーマンスの向上が文脈の中で最小であるので、実装者は、慎重に[RFC4307]で実装に必須のアルゴリズムオーバーAES-CTRの使用を検討する必要があります

IKEv2. Furthermore, these performance improvements may be offset by the Counter Mode specific risk of a minor, hard-to-detect implementation issue resulting in total security failure.

IKEv2の。さらに、これらの性能向上は、総合的なセキュリティ障害の原因となるマイナー、ハードツー検出実装の問題のカウンタモード、特定のリスクによって相殺することができます。

1.1. Conventions Used in This Document

1.1. このドキュメントの表記規則

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

この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。

2. IKEv2 Encrypted Payload

2. IKEv2の暗号化されたペイロード

Section 3.14 of IKEv2 [RFC4306] explains the IKEv2 Encrypted Payload. The Encrypted Payload, denoted SK{...}, contains other IKEv2 payloads in encrypted form.

IKEv2の[RFC4306]のセクション3.14は、IKEv2の暗号化されたペイロードを説明しています。 SK {...}で表される暗号化ペイロードは、暗号化された形式で他のIKEv2ペイロードを含んでいます。

The payload includes an Initialization Vector (IV) whose length is defined by the encryption algorithm negotiated. It also includes Integrity Checksum data. These two fields are not encrypted.

ペイロードは、その長さがネゴシエート暗号化アルゴリズムにより定義される初期化ベクトル（IV）を含みます。また、整合性チェックサムデータを含んでいます。これらの2つのフィールドは暗号化されていません。

The IV field MUST be 8 octets when the AES-CTR algorithm is used for IKEv2 encryption. The requirements for this IV are the same as what is specified for the Encapsulating Security Payload (ESP) in Section 3.1 of [RFC3686].

AES-CTRアルゴリズムはIKEv2の暗号化に使用されたときにIVフィールドは8つのオクテットでなければなりません。このIVの要件は[RFC3686]の3.1節でカプセル化セキュリティペイロード（ESP）に指定されているものと同じです。

IKEv2 requires Integrity Check Data for the Encrypted Payload as described in Section 3.14 of [RFC4306]. The choice of integrity algorithms in IKEv2 is defined in [RFC4307] or documents that update it in the future.

IKEv2のは、[RFC4306]のセクション3.14で説明したように整合性が暗号化されたペイロードのデータを確認が必要です。 IKEv2の中の整合性アルゴリズムの選択は、将来的にそれを更新[RFC4307]や文書で定義されています。

When AES-CTR is used in IKEv2, no padding is required. The Padding field of the Encrypted Payload SHOULD be empty, and the Pad Length field SHOULD be zero. However, according to [RFC4306], the recipient MUST accept any length that results in proper alignment. It should be noted that the ESP [RFC4303] Encrypted Payload requires alignment on a 4-byte boundary while the IKEv2 [RFC4306] Encrypted Payload does not have such a requirement.

AES-CTRがIKEv2の中で使用されている場合は、パディングは必要ありません。暗号化されたペイロードのパディングフィールドは空であるべきであり、パッド長フィールドはゼロであるべきです。しかし、【RFC4306]によれば、受信者は、適切な位置合わせをもたらす任意の長さを受け入れなければなりません。それのIKEv2 [RFC4306]暗号化されたペイロードは、そのような要件を持っていないながらESP [RFC4303]暗号化されたペイロードは、4バイト境界で位置合わせを必要とすることに留意すべきです。

The Encrypted Payload is the XOR of the plaintext and key stream. The key stream is generated by inputting counter blocks into the AES algorithm. The AES counter block is 128 bits, including a 4-octet Nonce, 8-octet Initialization Vector, and 4-octet Block Counter, in that order. The Block Counter begins with the value of one and increments by one to generate the next portion of the key stream. The detailed requirements for the counter block are the same as those specified in Section 4 of [RFC3686].

暗号化されたペイロードは、平文とキーストリームのXORです。キーストリームは、AESアルゴリズムにカウンタブロックを入力することによって生成されます。 AESカウンタブロックの順に、4オクテットノンス、8オクテットの初期化ベクトル、及び4オクテットブロックカウンタを含む128ビットです。ブロックカウンタは、キーストリームの次の部分を生成するために、一つ一つの値をインクリメントすることから始まります。カウンタブロックの詳細な要件は、[RFC3686]のセクション4で指定したものと同じです。

3. IKEv2 Conventions

3. IKEv2の規則

The use of AES-CTR for the IKE SA is negotiated in the same way as AES-CTR for ESP. The Transform ID (ENCR_AES_CTR) is the same; the key length transform attribute is used in the same way; and the keying material (consisting of the actual key and the nonce) is derived in the same way. See Section 5 of [RFC3686] for detailed descriptions.

IKE SAのためのAES-CTRの使用はESPのためのAES-CTRと同じように交渉しています。変換ID（ENCR_AES_CTR）は同じです。属性を変換キーの長さは、同じように使用されています。及び鍵材料は、（実際のキーおよびナンスから成る）と同じ方法で導出されます。詳細な説明については、[RFC3686]のセクション5を参照してください。

4. Security Considerations

4.セキュリティについての考慮事項

Security considerations explained in Section 7 of [RFC3686] are entirely relevant to this document as well. The security considerations on fresh keys and integrity protection in Section 7 of [RFC3686] are totally applicable to using AES-CTR in IKEv2; see [RFC3686] for details. As static keys are never used in IKEv2 for IKE_SA and integrity protection is mandatory for IKE_SA, these issues are not applicable for AES-CTR in IKEv2 when protecting IKE_SA.

セキュリティの考慮事項は、[RFC3686]のセクション7で説明しただけでなく、この文書に完全に関連しています。 [RFC3686]のセクション7で新鮮な鍵と完全性保護に関するセキュリティの考慮事項は、IKEv2の中でAES-CTRを使用することには全く適用されます。詳細については、[RFC3686]を参照してください。静的キーがIKE_SAのためのIKEv2で使用されることはありませんし、完全性保護がIKE_SAのために必須であるためIKE_SAを保護する際に、これらの問題は、IKEv2の中にAES-CTRには適用されません。

Additionally, since AES has a 128-bit block size, regardless of the mode employed, the ciphertext generated by AES encryption becomes distinguishable from random values after 2^64 blocks are encrypted with a single key. Since IKEv2 SA cannot carry that much data (because of the size limit of the message ID of the IKEv2 message and the requirements for the message ID in Section 4 of [RFC4306]), this issue is not a concern here.

AESは、128ビットのブロックサイズを有するので、2 ^ 64ブロックは、単一の鍵で暗号化された後、さらに、関係なく、使用モードの、AES暗号化によって生成された暗号文は、ランダムな値から識別可能となります。 IKEv2 SAは（ためのIKEv2メッセージと[RFC4306]のセクション4におけるメッセージIDに対する要求のメッセージIDのサイズ制限の）その多くのデータを運ぶことができないので、この問題は、ここでは問題ではありません。

For generic attacks on AES, such as brute force or precalculations, the key-size requirements provide reasonable security [Recommendations].

このようブルートフォースや前計算などAESの一般的な攻撃については、キーサイズの要件は、合理的なセキュリティ[推奨]を提供しています。

5. IANA Considerations

5. IANAの考慮事項

IANA [IANA-Para] has assigned an Encryption Algorithm Transform ID for AES-CTR encryption with an explicit IV for IKEv2: 13 as the number, and ENCR_AES_CTR as the name. IANA has added a reference to this RFC in that entry.

名前として番号として13、及びENCR_AES_CTR：IANA [IANAパラ]は暗号化アルゴリズムは、IKEv2のための明示的なIVとAES-CTR暗号化のためのIDを変換割り当てました。 IANAは、そのエントリにこのRFCへの参照を追加しました。

6. Acknowledgments

6.謝辞

The authors thank Yaron Sheffer, Paul Hoffman, Tero Kivinen, and Alfred Hoenes for their direction and comments on this document.

著者は、彼らの方向と、この文書にコメントをヤロンシェファー、ポール・ホフマン、TERO Kivinen、とアルフレッドHoenesに感謝します。

This document specifies usage of AES-CTR with IKEv2, similar to usage of AES-CTR with ESP as specified in [RFC3686]. The reader is referred to [RFC3686] for the same descriptions and definitions. The authors thank Russ Housley for providing the document.

[RFC3686]で指定されるように、この文書では、ESPとAES-CTRの使用と同様のIKEv2とAES-CTRの使用を指定します。読者は同じ説明および定義については[RFC3686]と呼ばれます。作者は、ドキュメントを提供するためのラスHousleyに感謝します。

During the production and modification of this document, both Huawei and CNNIC supported one of the authors, Sean Shen. Both are appreciated as affiliations of the author.

このドキュメントの生産と修正時には、Huawei社とCNNICの両方は、著者の一人、ショーン・シェンを支持しました。双方は、著者の所属として理解されます。

7. References

7.参考

7.1. Normative References

7.1. 引用規格

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

[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。

[RFC3686] Housley, R., "Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP)", RFC 3686, January 2004.

[RFC3686] Housley氏、R.、RFC 3686 "IPsecのカプセル化セキュリティペイロード（ESP）でのAdvanced Encryption Standard（AES）カウンタモードの使用" を、2004年1月。

[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.

[RFC4306]カウフマン、C.、 "インターネットキーエクスチェンジ（IKEv2の）プロトコル"、RFC 4306、2005年12月。

[RFC4307] Schiller, J., "Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2)", RFC 4307, December 2005.

[RFC4307]シラー、J.、 "インターネット鍵交換バージョン2（IKEv2の）での使用のための暗号アルゴリズム"、RFC 4307、2005年12月。

[AES] National Institute of Standards and Technology, "Advanced Encryption Standard (AES)", FIPS PUB 197, November 2001, <http://csrc.nist.gov/ publications/fips/fips197/fips-197.pdf>.

[AES]米国国立標準技術研究所、 "高度暗号化標準（AES）"、FIPS PUBの197、2001年11月、<http://csrc.nist.gov/出版/ FIPS / FIPS197 / FIPS-197.pdf>。

[IANA-Para] Internet Assigned Numbers Authority, "Internet Key Exchange Version 2 (IKEv2) Parameters", <http://www.iana.org>.

[IANA-パラ]インターネット割り当て番号機関、 "インターネット鍵交換バージョン2（IKEv2の）パラメータ"、<http://www.iana.org>。

[MODES] Dworkin, M., "Recommendation for Block Cipher Modes of Operation -- Methods and Techniques", NIST Special Publication 800-38A, December 2001, <http://csrc.nist.gov/publications/nistpubs/ 800-38a/sp800-38a.pdf>.

[MODES] Dworkin、M.、 "操作のブロック暗号モードのための推薦 - の方法と技術"、は、NIST Special Publication 800-38A、2001年12月、<http://csrc.nist.gov/publications/nistpubs/ 800- 38A / sp800-38a.pdf>。

7.2. Informative References

7.2. 参考文献

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

[RFC4303]ケント、S.、 "IPカプセル化セキュリティペイロード（ESP）"、RFC 4303、2005年12月。

[Recommendations] Barker, E., Barker, W., Burr, W., Polk, W., and M. Smid, "Recommendation for Key Management - Part 1: General (Revised)", NIST Special Publication 800-57, March 2007, <http:// csrc.nist.gov/publications/nistpubs/800-57/ sp800-57-Part1-revised2_Mar08-2007.pdf>.

[推奨]バーカー、E.、バーカー、W.、バリ、W.、ポーク、W.、およびM. SMID、 "キー管理のための提言 - パート1：一般（改訂）"、は、NIST Special Publication 800-57、 2007年3月、<のhttp：// csrc.nist.gov/publications/nistpubs/800-57/ sp800-57 - パート1 - revised2_Mar08-2007.pdf>。

Authors' Addresses

著者のアドレス

Sean Shen Huawei 4, South 4th Street, Zhongguancun Beijing 100190 China

ショーンS 4、南4TH通り、Z巨視的インチ北京100190中国H UAであります

EMail: shenshuo@cnnic.cn

メールアドレス：shenshuo@cnnic.cn

Yu Mao Hangzhou H3C Tech. Co., Ltd. Oriental Electronic Bld., No. 2 Chuangye Road Shang-Di Information Industry Hai-Dian District Beijing 100085 China

AO杭州H3CハイテクYUM。CO。、株式会社東洋電子BLインチ、ない。2 C、黄色の道路シャン-DI、情報産業H愛-Dイアン地区北京100085中国

EMail: yumao9@gmail.com

メールアドレス：yumao9@gmail.com

N S Srinivasa Murthy Freescale Semiconductor UMA PLAZA, NAGARJUNA CIRCLE, PUNJAGUTTA HYDERABAD 500082 INDIA

N Sスリニヴァサ・マーシーフリースケール・セミコンダクタ・UMA PLAZA、龍樹CIRCLE、PUNJAGUTTAハイデラバード500082 INDIA

EMail: ssmurthy.nittala@freescale.com

メールアドレス：ssmurthy.nittala@freescale.com