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

原文URL : https://datatracker.ietf.org/doc/html/rfc5930
タイトル : RFC 5930 - インターネットキーエクスチェンジバージョン02（IKEV2）プロトコルを使用して、高度な暗号化標準カウンターモード（AES-CTR）の使用
翻訳編集 : 自動生成

[要約] RFC 5930は、インターネットキー交換バージョン2（IKEv2）プロトコルで高度暗号化標準カウンターモード（AES-CTR）を使用する方法について説明しています。この文書の目的は、IKEv2プロトコルにおけるデータの暗号化と認証のための追加的な方法としてAES-CTRモードを提供することです。これは、VPN接続やIPsecプロトコルでのセキュアなデータ転送を強化するために利用されます。関連するRFCには、RFC 7296（IKEv2の仕様を更新するもの）やRFC 5282（AES-XCBC-PRF-128アルゴリズムの使用に関するもの）などがあります。

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

インターネットキーエクスチェンジバージョン02（IKEV2）プロトコルを使用して、高度な暗号化標準カウンターモード（AES-CTR）の使用

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 Exchangeに続く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によって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。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.

このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc5930で取得できます。

著作権表示

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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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).

Internet Key Exchangeバージョン2（IKEV2）プロトコル[RFC4306]は、相互認証の実行とセキュリティ協会の確立と維持に使用されるIPSECのコンポーネントです（SAS）。[RFC4307]は、IKEV2の一部として実装することが必須のアルゴリズムのセットと、将来の時期に必須に促進される可能性があるため実装する必要があるアルゴリズムを定義します。[RFC4307]では、実装が「必要な」必要がある必要があります。[AS]タイプ1アルゴリズム（暗号化）として、[AS] Counter Mode [Modes]（AES-CTR）（AES-CTR）をサポートする必要があります。

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 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のコンテキストでは、AES-CTRのパフォーマンスの改善が最小限であるため、実装者は[RFC4307]の必須の実装アルゴリズムに対するAES-CTRの使用を慎重に検討する必要があります。さらに、これらのパフォーマンスの改善は、マイナーで検出されにくい実装の問題のカウンターモード固有のリスクによって相殺される可能性があり、セキュリティ障害をもたらします。

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

「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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.

IKEV2でAES-CTRを使用する場合、パディングは必要ありません。暗号化されたペイロードのパディングフィールドは空である必要があり、パッドの長さフィールドはゼロである必要があります。ただし、[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-OCTET初期化ベクトル、4オクテットのブロックカウンターを含む128ビットです。ブロックカウンターは、1つの値から始まり、キーストリームの次の部分を生成するために1つずつ増加します。カウンターブロックの詳細な要件は、[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のモードが使用されているモードに関係なく、AESのブロックサイズは128ビットサイズであるため、AES暗号化によって生成される暗号文は、2^64ブロックが単一のキーで暗号化された後、ランダム値と区別できます。IKEV2 SAはそれほど多くのデータを伝えることができないため（IKEV2メッセージのメッセージIDのサイズ制限と[RFC4306]セクション4のメッセージIDの要件があるため）、この問題はここでは懸念事項ではありません。

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

ブルートフォースや事前計算などのAEに対する一般的な攻撃の場合、キーサイズの要件は合理的なセキュリティを提供します[推奨]。

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.

IANA [IANA-PARA]は、IKEV2：13の明示的なIVを使用して、AES-CTR暗号化に暗号化アルゴリズムIDを割り当て、名前としてENCR_AES_CTRを割り当てました。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.

著者は、ヤロン・シェファー、ポール・ホフマン、テロ・キビネン、およびアルフレッド・ホーネスの方向性とこの文書に関するコメントに感謝します。

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]で指定されているように、AES-CTRを使用したAES-CTRの使用と同様に、IKEV2を使用したAES-CTRの使用法を指定します。読者は、同じ説明と定義について[RFC3686]に紹介されます。著者は、文書を提供してくれたRuss 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の両方が著者の1人であるSean Shenをサポートしました。どちらも著者の所属として感謝されています。

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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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。、「Advanced Encryption Standard（AES）カウンターモードを使用して、IPSECがセキュリティペイロードをカプセル化する（ESP）」、RFC 3686、2004年1月。

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

[RFC4306] Kaufman、C。、「Internet Key Exchange（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]国立標準技術研究所、「Advanced Encryption Standard（AES）」、Fips Pub 197、2001年11月、<http://csrc.nist.gov/ Publications/fips/fips197/fips-197.pdf>。

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

[IANA-PARA]インターネットに割り当てられた数字の権限、「インターネットキーエクスチェンジバージョン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] Kent、S。、「セキュリティペイロードのカプセル化（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>.

[推奨事項] Barker、E.、Barker、W.、Burr、W.、Polk、W。、およびM. Smid、「キー管理の推奨 - パート1：一般（改訂）」、NIST Special Publication 800-57、2007年3月、<http：// csrc.nist.gov/publications/nistpubs/800-57/ sp800-57-part1-revized2_mar08-2007.pdf>。

Authors' Addresses

著者のアドレス

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

ショーン・シェン・ホーウェイ4、サウス4th街、Zhongguancun Beijing 100190 China

   EMail: 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

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

   EMail: yumao9@gmail.com

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

n S Srinivasa Murthy Freescale Semiconductor Uma Plaza、Nagarjuna Circle、Punjagutta Hyderabad 500082 India

   EMail: ssmurthy.nittala@freescale.com