Network Working Group R. Housley
Request for Comments: 4309 Vigil Security
Category: Standards Track December 2005
Using Advanced Encryption Standard (AES) CCM Mode
with IPsec Encapsulating Security Payload (ESP)
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).
著作権（C）インターネット協会（2005）。
Abstract
抽象
This document describes the use of Advanced Encryption Standard (AES) in Counter with CBC-MAC (CCM) Mode, with an explicit initialization vector (IV), as an IPsec Encapsulating Security Payload (ESP) mechanism to provide confidentiality, data origin authentication, and connectionless integrity.
この文書は、機密性を提供するためにIPsecカプセル化セキュリティペイロード（ESP）のメカニズム、データ発信元認証として、明示的な初期化ベクトル（IV）と、CBC-MAC（CCM）モードとカウンターでのAdvanced Encryption Standard（AES）の使用が記載されていますそして、コネクションレスの整合性。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................2
2. AES CCM Mode ....................................................2
3. ESP Payload .....................................................4
3.1. Initialization Vector (IV) .................................4
3.2. Encrypted Payload ..........................................4
3.3. Authentication Data ........................................5
4. Nonce Format ....................................................5
5. AAD Construction ................................................6
6. Packet Expansion ................................................7
7. IKE Conventions .................................................7
7.1. Keying Material and Salt Values ............................7
7.2. Phase 1 Identifier .........................................8
7.3. Phase 2 Identifier .........................................8
7.4. Key Length Attribute .......................................8
8. Test Vectors ....................................................8
9. Security Considerations .........................................8
10. Design Rationale ...............................................9
11. IANA Considerations ...........................................11
12. Acknowledgements ..............................................11
13. References ....................................................11
13.1. Normative References .....................................11
13.2. Informative References ...................................12
The Advanced Encryption Standard (AES) [AES] is a block cipher, and it can be used in many different modes. This document describes the use of AES in CCM (Counter with CBC-MAC) mode (AES CCM), with an explicit initialization vector (IV), as an IPsec Encapsulating Security Payload (ESP) [ESP] mechanism to provide confidentiality, data origin authentication, and connectionless integrity.
高度暗号化標準（AES）[AES]はブロック暗号であり、それは多くの異なるモードで使用することができます。この文書では、機密性、データの起源を提供するために、IPsecのカプセル化セキュリティペイロード（ESP）[ESP]のメカニズムとして、明示的な初期化ベクトル（IV）と、（CBC-MACとカウンタ）モード（AES CCM）CCMでのAESの使用を記載します認証、およびコネクションレスの整合性。
This document does not provide an overview of IPsec. However, information about how the various components of IPsec and the way in which they collectively provide security services is available in [ARCH] and [ROAD].
この文書では、IPsecの概要を提供していません。しかし、どのようにIPsecのさまざまなコンポーネントと、それらをまとめたセキュリティサービスを提供する方法についての情報は、[ARCH]と[ROAD]で利用可能です。
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 [STDWORDS].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります【STDWORDS]に記載されているように解釈されます。
CCM is a generic authenticate-and-encrypt block cipher mode [CCM]. In this specification, CCM is used with the AES [AES] block cipher.
CCMは、一般的な認証-および暗号化ブロック暗号モード[CCM]です。本明細書では、CCMは、AES [AESブロック暗号で使用されます。
AES CCM has two parameters:
AES CCMは、2つのパラメータがあります。
M M indicates the size of the integrity check value (ICV). CCM defines values of 4, 6, 8, 10, 12, 14, and 16 octets; However, to maintain alignment and provide adequate security, only the values that are a multiple of four and are at least eight are permitted. Implementations MUST support M values of 8 octets and 16 octets, and implementations MAY support an M value of 12 octets.
M Mは、整合性チェック値（ICV）の大きさを示しています。 CCMは、4、6、8、10、12、14、及び16オクテットの値を定義します。しかし、アライメントを維持し、十分なセキュリティを提供するために、唯一の4の倍数である値とは少なくとも8は許可されています。実装は8つのオクテットと16オクテットのM値をサポートしなければならない、および実装が12オクテットのM値をサポートするかもしれません。
L L indicates the size of the length field in octets. CCM defines values of L between 2 octets and 8 octets. This specification only supports L = 4. Implementations MUST support an L value of 4 octets, which accommodates a full Jumbogram [JUMBO]; however, the length includes all of the encrypted data, which also includes the ESP Padding, Pad Length, and Next Header fields.
LのLはオクテットの長さフィールドのサイズを示します。 CCMは、2つのオクテットと8つのオクテットの間にLの値を定義します。この仕様は、L = 4の実装は完全ジャンボグラム[JUMBO]を収容する4つのオクテットのL値を、サポートしなければならないサポート。ただし、長さはまたESPパディングパッド長、次ヘッダフィールドを含む暗号化されたデータのすべてを含みます。
There are four inputs to CCM originator processing:
CCMの発信元の処理に4つの入力があります。
key A single key is used to calculate the ICV using CBC-MAC and to perform payload encryption using counter mode. AES supports key sizes of 128 bits, 192 bits, and 256 bits. The default key
キー単一のキーはCBC-MACを使用して、ICVを算出すると、カウンタモードを使用してペイロード暗号化を実行するために使用されます。 AESは、128ビット、192ビット、256ビットのキーサイズをサポートしています。デフォルトのキー
size is 128 bits, and implementations MUST support this key size. Implementations MAY also support key sizes of 192 bits and 256 bits.
サイズは128ビットであり、実装は、このキーサイズをサポートしなければなりません。また、実装は192ビット、256ビットのキーサイズをサポートするかもしれません。
nonce The size of the nonce depends on the value selected for the parameter L. It is 15-L octets. Implementations MUST support a nonce of 11 octets. The construction of the nonce is described in Section 4.
ノンスノンスのサイズは、Lは、それが15-Lオクテットであるパラメータの選択された値に依存します。実装は、11オクテットのナンスをサポートしなければなりません。ナンスの構築はセクション4に記載されています。
payload The payload of the ESP packet. The payload MUST NOT be longer than 4,294,967,295 octets, which is the maximum size of a Jumbogram [JUMBO]; however, the ESP Padding, Pad Length, and Next Header fields are also part of the payload.
ESPパケットのペイロードをペイロード。ペイロードはジャンボグラム[JUMBO]の最大サイズである4,294,967,295オクテットよりも長くてはいけません。しかしながら、ESPパディングパッド長、次ヘッダフィールドはまた、ペイロードの一部です。
AAD CCM provides data integrity and data origin authentication for some data outside the payload. CCM does not allow additional authenticated data (AAD) to be longer than 18,446,744,073,709,551,615 octets. The ICV is computed from the ESP header, Payload, and ESP trailer fields, which is significantly smaller than the CCM-imposed limit. The construction of the AAD described in Section 5.
AAD CCMは、ペイロード外の一部のデータのためのデータの整合性とデータ発信元認証を提供します。 CCMは、追加の認証されたデータ（AAD）が18,446,744,073,709,551,615オクテットより長くすることはできません。 ICVは、ESPヘッダ、ペイロード、およびCCM-課される限界よりも著しく小さいESPトレーラ・フィールドから計算されます。 AADの建設は、第5節で説明しました。
AES CCM requires the encryptor to generate a unique per-packet value and to communicate this value to the decryptor. This per-packet value is one of the component parts of the nonce, and it is referred to as the initialization vector (IV). The same IV and key combination MUST NOT be used more than once. The encryptor can generate the IV in any manner that ensures uniqueness. Common approaches to IV generation include incrementing a counter for each packet and linear feedback shift registers (LFSRs).
AES CCMは、ユニークなパケットごとの値を生成し、暗号解読にこの値を通信するために暗号化が必要です。このパケット単位の値は、ノンスの構成部品の一つであり、それは初期化ベクトル（IV）と呼ばれます。同じIVとキーの組み合わせを複数回使用してはいけません。暗号化には、一意性を保証し、いかなる方法でIVを生成することができます。 IV世代の一般的なアプローチは、各パケットのためのカウンタをインクリメントし、線形フィードバックシフトレジスタ（LFSR）を含みます。
AES CCM employs counter mode for encryption. As with any stream cipher, reuse of the same IV value with the same key is catastrophic. An IV collision immediately leaks information about the plaintext in both packets. For this reason, it is inappropriate to use this CCM with statically configured keys. Extraordinary measures would be needed to prevent reuse of an IV value with the static key across power cycles. To be safe, implementations MUST use fresh keys with AES CCM. The Internet Key Exchange (IKE) [IKE] protocol or IKEv2 [IKEv2] can be used to establish fresh keys.
AES CCMは、暗号化のためのカウンタモードを採用しています。任意のストリーム暗号のように、同じキーを持つ同じIV値の再利用は壊滅的です。 IVの衝突がすぐに両方のパケットで平文に関する情報をリークします。このため、静的に設定されたキーで、このCCMを使用することは不適切です。臨時措置はパワーサイクル全体で静的キーとIV値の再使用を防止するために必要とされるであろう。安全のために、実装はAES CCM新鮮なキーを使用する必要があります。インターネット鍵交換（IKE）[IKE]プロトコルまたはIKEv2の[IKEv2の]フレッシュキーを確立するために使用することができます。
The ESP payload is composed of the IV followed by the ciphertext. The payload field, as defined in [ESP], is structured as shown in Figure 1.
ESPペイロードを暗号文に続くIVで構成されています。図1に示すように、ペイロードフィールドは、[ESP]で定義されるように、構成されています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initialization Vector |
| (8 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Encrypted Payload (variable) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Authentication Data (variable) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1. ESP Payload Encrypted with AES CCM
AES CCM図1. ESPペイロードの暗号化
The AES CCM IV field MUST be eight octets. The IV MUST be chosen by the encryptor in a manner that ensures that the same IV value is used only once for a given key. The encryptor can generate the IV in any manner that ensures uniqueness. Common approaches to IV generation include incrementing a counter for each packet and linear feedback shift registers (LFSRs).
AES CCMのIVフィールドは8つのオクテットでなければなりません。 IVは、同じIV値が指定されたキーの一度だけ使用されることを保証するように暗号化することによって選択されなければなりません。暗号化には、一意性を保証し、いかなる方法でIVを生成することができます。 IV世代の一般的なアプローチは、各パケットのためのカウンタをインクリメントし、線形フィードバックシフトレジスタ（LFSR）を含みます。
Including the IV in each packet ensures that the decryptor can generate the key stream needed for decryption, even when some datagrams are lost or reordered.
各パケットにおけるIV含めると、いくつかのデータグラムが失われたり、並べ替えた場合であっても、復号化は、復号に必要な鍵ストリームを生成することができることを保証します。
The encrypted payload contains the ciphertext.
暗号化されたペイロードは、暗号文が含まれています。
AES CCM mode does not require plaintext padding. However, ESP does require padding to 32-bit word-align the authentication data. The Padding, Pad Length, and Next Header fields MUST be concatenated with the plaintext before performing encryption, as described in [ESP]. When padding is required, it MUST be generated and checked in accordance with the conventions specified in [ESP].
AES CCMモードは、平文のパディングを必要としません。ただし、ESPは、認証データをワード整列32ビットにパディングを必要とします。 [ESP]に記載されているようにパディング、パッド長、次ヘッダフィールドは、暗号化を行う前に、平文と連結されなければなりません。パディングが必要な場合は、[ESP]で指定された規則に従って生成し、チェックしなければなりません。
AES CCM provides an encrypted ICV. The ICV provided by CCM is carried in the Authentication Data fields without further encryption. Implementations MUST support ICV sizes of 8 octets and 16 octets. Implementations MAY also support ICV 12 octets.
AES CCMは、暗号化されたICVを提供します。 CCMによって提供さICVはさらに、暗号化せずに認証データフィールドで運ばれます。実装は8つのオクテットと16オクテットのICVサイズをサポートしなければなりません。また、実装はICV 12オクテットをサポートするかもしれません。
Each packet conveys the IV that is necessary to construct the sequence of counter blocks used by counter mode to generate the key stream. The AES counter block is 16 octets. One octet is used for the CCM Flags, and 4 octets are used for the block counter, as specified by the CCM L parameter. The remaining octets are the nonce. These octets occupy the second through the twelfth octets in the counter block. Figure 2 shows the format of the nonce.
各パケットは、キーストリームを生成するカウンタ・モードで使用されるカウンタブロックのシーケンスを構築する必要があるIVを伝えます。 AESカウンタブロックは16オクテットです。 1つのオクテットは、CCMのフラグのために使用され、CCMのLパラメータで指定された4つのオクテットは、ブロックカウンタに使用されます。残りのオクテットはナンスです。これらのオクテットは、カウンタブロック第12オクテットを介して第2を占めています。図2は、一回だけのフォーマットを示します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Salt |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initialization Vector |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2. Nonce Format
図2.使節のフォーマット
The components of the nonce are as follows:
次のようにナンスのコンポーネントは次のとおりです。
Salt The salt field is 24 bits. As the name implies, it contains an unpredictable value. It MUST be assigned at the beginning of the security association. The salt value need not be secret, but it MUST NOT be predictable prior to the beginning of the security association.
塩は、塩フィールドは24ビットです。名前が示すように、それは予測できない値が含まれています。これは、セキュリティアソシエーションの先頭に割り当てなければなりません。ソルト値は秘密である必要はありませんが、それはセキュリティアソシエーションの開始前に予測可能にすることはできません。
Initialization Vector The IV field is 64 bits. As described in Section 3.1, the IV MUST be chosen by the encryptor in a manner that ensures that the same IV value is used only once for a given key.
初期化ベクトルザ・IV・フィールドは64ビットです。セクション3.1で説明したように、IVは、同じIV値が指定されたキーの一度だけ使用されることを保証するように暗号化することによって選択されなければなりません。
This construction permits each packet to consist of up to:
この構造は、最大で構成され、各パケットを許可します：
2^32 blocks = 4,294,967,296 blocks
= 68,719,476,736 octets
This construction provides more key stream for each packet than is needed to handle any IPv6 Jumbogram [JUMBO].
この構造は、任意のIPv6のジャンボグラム[JUMBO]を処理するために必要とされるよりも、各パケットのためのより多くのキーストリームを提供します。
The data integrity and data origin authentication for the Security Parameters Index (SPI) and (Extended) Sequence Number fields is provided without encrypting them. Two formats are defined: one for 32-bit sequence numbers and one for 64-bit extended sequence numbers. The format with 32-bit sequence numbers is shown in Figure 3, and the format with 64-bit extended sequence numbers is shown in Figure 4.
セキュリティパラメータインデックス（SPI）と（拡張）シーケンス番号フィールドのデータの整合性とデータ発信元認証は、それらを暗号化せずに提供されます。二つの形式が定義されている32ビットのシーケンス番号用と64ビットの拡張シーケンス番号のいずれかを。 32ビットのシーケンス番号を持つフォーマットは、図3に示されており、64ビットの拡張シーケンス番号を持つフォーマットは、図4に示されています。
Sequence Numbers are conveyed canonical network byte order. Extended Sequence Numbers are conveyed canonical network byte order, placing the high-order 32 bits first and the low-order 32 bits second. Canonical network byte order is fully described in RFC 791, Appendix B.
シーケンス番号は、標準的なネットワークバイトオーダーを伝えています。拡張シーケンス番号は、第1、第2の上位32ビットと下位32ビットを確定する、正規ネットワークバイト順に搬送されます。正規のネットワークバイトオーダーが完全にRFC 791に記載されており、付録B.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 32-bit Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3. AAD Format with 32-bit Sequence Number
32ビットのシーケンス番号を有する図3 AADフォーマット
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 64-bit Extended Sequence Number |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4. AAD Format with 64-bit Extended Sequence Number
64ビットの拡張シーケンス番号を持つ図4. AADのフォーマット
The initialization vector (IV) and the integrity check value (ICV) are the only sources of packet expansion. The IV always adds 8 octets to the front of the payload. The ICV is added at the end of the payload, and the CCM parameter M determines the size of the ICV. Implementations MUST support M values of 8 octets and 16 octets, and implementations MAY also support an M value of 12 octets.
初期化ベクトル（IV）と整合性チェック値（ICV）は、パケット拡張の唯一の供給源です。 IVは常にペイロードの前に8つのオクテットが追加されます。 ICVは、ペイロードの末尾に追加され、CCMパラメータMは、ICVのサイズを決定します。実装は8つのオクテットと16オクテットのM値をサポートしなければならない、と実装も12オクテットのM値をサポートするかもしれません。
This section describes the conventions used to generate keying material and salt values for use with AES CCM using the Internet Key Exchange (IKE) [IKE] protocol. The identifiers and attributes needed to negotiate a security association that uses AES CCM are also defined.
このセクションでは、AES CCMは、インターネット鍵交換（IKE）[IKE]プロトコルを用いた使用のための材料と塩の値をキーイング生成するために使用される規則を記述する。 AES CCMを使用してセキュリティアソシエーションをネゴシエートするために必要な識別子と属性も定義されています。
As previously described, implementations MUST use fresh keys with AES CCM. IKE can be used to establish fresh keys. This section describes the conventions for obtaining the unpredictable salt value for use in the nonce from IKE. Note that this convention provides a salt value that is secret as well as unpredictable.
前述のように、実装は、AES CCM新鮮なキーを使用しなければなりません。 IKEは、新鮮な鍵を確立するために使用することができます。このセクションでは、IKEからナンスに使用するために予測不可能なソルト値を取得するための規則を記述する。この規則は、秘密だけでなく、予測不可能である塩の価値を提供することに注意してください。
IKE makes use of a pseudo-random function (PRF) to derive keying material. The PRF is used iteratively to derive keying material of arbitrary size, called KEYMAT. Keying material is extracted from the output string without regard to boundaries.
IKEは、材料を合わせる導出する擬似ランダム関数（PRF）を利用します。 PRFは、任意のサイズの鍵材料と呼ばれるKEYMATを導き出すために反復的に使用されています。鍵材料は、境界に関係なく、出力文字列から抽出されます。
The size of KEYMAT MUST be three octets longer than is needed for the associated AES key. The keying material is used as follows:
KEYMATの大きさは、関連するAESキーのために必要とされるよりも3つのオクテット長くなければなりません。次のように鍵材料が使用されます。
AES CCM with a 128-bit key The KEYMAT requested for each AES CCM key is 19 octets. The first 16 octets are the 128-bit AES key, and the remaining three octets are used as the salt value in the counter block.
各AES CCMキーに対して要求128ビットの鍵KEYMATとAES CCMは19オクテットです。第16オクテットは、128ビットのAES鍵であり、残りの3つのオクテットは、カウンタブロック中の塩の値として使用されます。
AES CCM with a 192-bit key The KEYMAT requested for each AES CCM key is 27 octets. The first 24 octets are the 192-bit AES key, and the remaining three octets are used as the salt value in the counter block.
各AES CCMのキーのために要求された192ビットの鍵KEYMATとAES CCMは27オクテットです。第24オクテットは192ビットのAES鍵であり、残りの3つのオクテットは、カウンタブロック中の塩の値として使用されます。
AES CCM with a 256-bit key The KEYMAT requested for each AES CCM key is 35 octets. The first 32 octets are the 256-bit AES key, and the remaining three octets are used as the salt value in the counter block.
各AES CCMキーに対して要求256ビットの鍵KEYMATとAES CCMは35オクテットです。第32オクテットは、256ビットのAES鍵であり、残りの3つのオクテットは、カウンタブロック中の塩の値として使用されます。
This document does not specify the conventions for using AES CCM for IKE Phase 1 negotiations. For AES CCM to be used in this manner, a separate specification is needed, and an Encryption Algorithm Identifier needs to be assigned.
この文書では、IKEフェーズ1つのネゴシエーションのためのAES CCMを使用するための規則を指定していません。 AES CCMはこのように使用するため、別々の仕様が必要、および暗号化アルゴリズム識別子が割り当てられる必要があります。
For IKE Phase 2 negotiations, IANA has assigned three ESP Transform Identifiers for AES CCM with an explicit IV:
IKEフェーズ2つのネゴシエーションのために、IANAは3はESP明示的なIVとAES CCMの識別子を変換する割り当てられています：
14 for AES CCM with an 8-octet ICV; 15 for AES CCM with a 12-octet ICV; and 16 for AES CCM with a 16-octet ICV.
8オクテットICVとAES CCM 14。 12オクテットのICVとAES CCM 15。そして16オクテットICVとAES CCMのための16。
Because the AES supports three key lengths, the Key Length attribute MUST be specified in the IKE Phase 2 exchange [DOI]. The Key Length attribute MUST have a value of 128, 192, or 256.
AESは、3つのキー長をサポートしているため、キーの長さ属性は、IKEフェーズ2交換の[DOI]で指定する必要があります。キーの長さ属性が128、192、または256の値を持つ必要があります。
Section 8 of [CCM] provides test vectors that will assist implementers with AES CCM mode.
[CCM]のセクション8は、AES CCMモードと実装を支援するテストベクトルを提供します。
AES CCM employs counter (CTR) mode for confidentiality. If a counter value is ever used for more that one packet with the same key, then the same key stream will be used to encrypt both packets, and the confidentiality guarantees are voided.
AES CCMは、機密性のためのカウンタ（CTR）モードを採用しています。カウンタ値はこれまでと同じキーを持つつ以上のパケットのために使用されている場合は、同じキーストリームは、両方のパケットを暗号化するために使用され、機密性の保証が無効とされています。
What happens if the encryptor XORs the same key stream with two different packet plaintexts? Suppose two packets are defined by two plaintext byte sequences P1, P2, P3 and Q1, Q2, Q3, then both are encrypted with key stream K1, K2, K3. The two corresponding ciphertexts are:
暗号化は、2つの異なるパケット平文と同じキーストリームを排他的論理和演算場合はどうなりますか？二つのパケットは、2つの平文バイトのシーケンスP1、P2、P3とQ1、Q2、Q3によって定義されると仮定し、両方のキーストリームK1、K2、K3を用いて暗号化されています。 2対応する暗号文は以下のとおりです。
(P1 XOR K1), (P2 XOR K2), (P3 XOR K3)
（P1 XOR K1）、（K2）、XOR P2（P3 XOR K3）
(Q1 XOR K1), (Q2 XOR K2), (Q3 XOR K3)
（Q1 XOR K1）、（K2）、XOR（Q2とQ3 XOR K3）
If both of these two ciphertext streams are exposed to an attacker, then a catastrophic failure of confidentiality results, because:
これらの二つの暗号文ストリームの両方が、攻撃者、機密性の結果の致命的な障害、ためにさらされている場合：
(P1 XOR K1) XOR (Q1 XOR K1) = P1 XOR Q1 (P2 XOR K2) XOR (Q2 XOR K2) = P2 XOR Q2 (P3 XOR K3) XOR (Q3 XOR K3) = P3 XOR Q3
（P1 XOR K1 XOR）（XOR K1）Q1のQ1 = P1 XOR（XOR）XOR（排他的論理和Q2 K2 K2、P2）P2 = XOR（XOR K3）XOR（P3 Q2とQ3 XOR K3）= P3 XOR Q3
Once the attacker obtains the two plaintexts XORed together, it is relatively straightforward to separate them. Thus, using any stream cipher, including AES CTR, to encrypt two plaintexts under the same key stream leaks the plaintext.
攻撃者が一緒にXOR演算2つの平文を取得したら、それらを分離することは比較的簡単です。したがって、同一のキーストリームの下に2つの平文を暗号化するAES CTRを含む任意のストリーム暗号を使用して平文をリーク。
Therefore, AES CCM should not be used with statically configured keys. Extraordinary measures would be needed to prevent the reuse of a counter block value with the static key across power cycles. To be safe, implementations MUST use fresh keys with AES CCM. The IKE [IKE] protocol can be used to establish fresh keys.
したがって、AES CCMは、静的に設定キーで使用されるべきではありません。臨時措置はパワーサイクル全体で静的キーとカウンタブロック値の再使用を防止するために必要とされるであろう。安全のために、実装はAES CCM新鮮なキーを使用する必要があります。 IKE [IKE]プロトコルは、新鮮な鍵を確立するために使用することができます。
When IKE is used to establish fresh keys between two peer entities, separate keys are established for the two traffic flows. If a different mechanism is used to establish fresh keys, one that
IKEは、2つのピアエンティティ間の新鮮なキーを確立するために使用される場合、別々のキーは2つのトラフィックフローのために確立されています。別のメカニズムは、新鮮な鍵を確立するために使用されている場合は、1その
establishes only a single key to encrypt packets, then there is a high probability that the peers will select the same IV values for some packets. Thus, to avoid counter block collisions, ESP implementations that permit use of the same key for encrypting and decrypting packets with the same peer MUST ensure that the two peers assign different salt values to the security association (SA).
パケットを暗号化するための唯一つのキーを確立し、その後、ピアはいくつかのパケットに同じIV値を選択する確率が高いです。従って、カウンタブロックの衝突を回避するために、同じピアとのパケットを暗号化および復号化に同じ鍵を使用することを可能にするESP実装は、2つのピアがセキュリティアソシエーション（SA）に異なる塩値を割り当てることを確認しなければなりません。
Regardless of the mode used, AES with a 128-bit key is vulnerable to the birthday attack after 2^64 blocks are encrypted with a single key. Since ESP with Extended Sequence Numbers allows for up to 2^64 packets in a single SA, there is real potential for more than 2^64 blocks to be encrypted with one key. Implementations SHOULD generate a fresh key before 2^64 blocks are encrypted with the same key, or implementations SHOULD make use of the longer AES key sizes. Note that ESP with 32-bit Sequence Numbers will not exceed 2^64 blocks even if all of the packets are maximum-length Jumbograms.
2 ^ 64ブロックは、単一の鍵で暗号化された後にかかわらず、使用するモードの、128ビットの鍵を持つAESは、誕生日の攻撃に対して脆弱です。拡張シーケンス番号を持つESPは、単一のSAで最大2 ^ 64パケットを可能にしているので、1つのキーで暗号化する以上の2 ^ 64ブロックのための本当の可能性があります。 2 ^ 64ブロックは同じ鍵で暗号化される前に、実装は、新鮮なキーを生成する必要があり、または実装が長くAESキーサイズの使用をしなければなりません。 ESPは、32ビットのシーケンス番号を持つパケットの全てが最大長ジャンボグラムであっても2 ^ 64ブロックを超えないことに注意してください。
In the development of this specification, the use of the ESP sequence number field instead of an explicit IV field was considered. This section documents the rationale for the selection of an explicit IV. This selection is not a cryptographic security issue, as either approach will prevent counter block collisions.
この仕様の開発では、ESPのシーケンス番号フィールドの代わりに、明示的なIVフィールドの使用が考えられました。このセクションでは、明示的なIVの選択の根拠を説明します。いずれのアプローチは、カウンタブロックの衝突を防ぐことができますので、この選択は、暗号化セキュリティの問題ではありません。
The use of the explicit IV does not dictate the manner that the encryptor uses to assign the per-packet value in the counter block. This is desirable for several reasons.
明示的なIVを使用すると、暗号化は、カウンタブロックにおけるパケット単位の値を割り当てるために使用する方法を規定していません。これは、いくつかの理由のために望ましいです。
1. Only the encryptor can ensure that the value is not used for more than one packet, so there is no advantage to selecting a mechanism that allows the decryptor to determine whether counter block values collide. Damage from the collision is done, whether the decryptor detects it or not.
1.のみ暗号化値を複数のパケットに使用されていないことを保証することができるので、復号カウンタブロック値が衝突するかどうかを決定することを可能にするメカニズムを選択する利点はありません。衝突による損傷は、復号化がそれを検出したかどうかに関係なく、実行されます。
2. The use of explicit IVs allows adders, LFSRs, and any other technique that meets the time budget of the encryptor, so long as the technique results in a unique value for each packet. Adders are simple and straightforward to implement, but due to carries, they do not execute in constant time. LFSRs offer an alternative that executes in constant time.
2.明示のIVの使用があれば、各パケットに一意の値に技術の結果として、加算器、のLFSR、および暗号化の時間バジェットを満たす任意の他の技術を可能にします。加算器は、実装が単純明快ですが、運ぶのために、彼らは一定の時間で実行されません。 LFSRは、一定の時間で実行される代替手段を提供します。
3. Complexity is in control of the implementer. Furthermore, the decision made by the implementer of the encryptor does not make the decryptor more (or less) complex.
3.複雑さは、実装者の制御です。さらに、暗号化の実装によって行われた決定は、復号部以上（または以下）の複合体を作成しません。
4. The assignment of the per-packet counter block value needs to be inside the assurance boundary. Some implementations assign the sequence number inside the assurance boundary, but others do not. A sequence number collision does not have the dire consequences, but, as described in Section 6, a collision in counter block values has disastrous consequences.
4.パケットごとのカウンタブロック値の割り当てが保証境界内にあることが必要です。一部の実装では、保証境界内にシーケンス番号を割り当てるが、他にはありません。シーケンス番号衝突が悲惨な結果を有していないが、第6節で説明したように、カウンタブロック値の衝突は、悲惨な結果を有します。
5. Using the sequence number as the IV is possible in those architectures where the sequence number assignment is performed within the assurance boundary. In this situation, the sequence number and the IV field will contain the same value.
IVは、シーケンス番号の割り当てが保証境界内で実行されるこれらのアーキテクチャで可能となるように前記シーケンス番号を使用します。このような状況では、シーケンス番号とIVのフィールドに同じ値が含まれます。
6. By decoupling the IV and the sequence number, architectures where the sequence number assignment is performed outside the assurance boundary are accommodated.
IVおよびシーケンス番号を切り離すことによって6は、シーケンス番号の割り当てが保証境界の外部で実行されるアーキテクチャが収容されています。
The use of an explicit IV field directly follows from the decoupling of the sequence number and the per-packet counter block value. The additional overhead (64 bits for the IV field) is acceptable. This overhead is significantly less overhead associated with Cipher Block Chaining (CBC) mode. As normally employed, CBC requires a full block for the IV and, on average, half of a block for padding. AES CCM confidentiality processing with an explicit IV has about one-third of the overhead as AES CBC, and the overhead is constant for each packet.
明示的なIVフィールドの使用は、直接シーケンス番号とパケットごとのカウンタブロック値のデカップリングから得られます。追加のオーバーヘッド（IVフィールドの64ビット）が許容されます。このオーバーヘッドは、暗号ブロック連鎖（CBC）モードに関連する有意に少ないオーバーヘッドです。通常用いられているように、CBCは、IVのための完全なブロックを必要とし、パディングのためのブロックの平均、半分に。明示的なIVとAES CCMの秘匿処理がAES CBCとしてオーバーヘッドの約3分の1を有し、オーバーヘッドは、各パケットに対して一定です。
IANA has assigned three ESP transform numbers for use with AES CCM with an explicit IV:
IANAは3はESP明示的なIVとAES CCMで使用するための数値を変換する割り当てられています：
14 for AES CCM with an 8-octet ICV; 15 for AES CCM with a 12-octet ICV; and 16 for AES CCM with a 16-octet ICV.
8オクテットICVとAES CCM 14。 12オクテットのICVとAES CCM 15。そして16オクテットICVとAES CCMのための16。
Doug Whiting and Niels Ferguson worked with me to develop CCM mode. We developed CCM mode as part of the IEEE 802.11i security effort. One of the most attractive aspects of CCM mode is that it is unencumbered by patents. I acknowledge the companies that supported the development of an unencumbered authenticated encryption mode (in alphabetical order):
ダグ・ホワイティングとニールスファーガソンはCCMモードを開発するために私と一緒に働きました。私たちは、IEEE 802.11iセキュリティの取り組みの一環として、CCMモードを開発しました。 CCMモードの最も魅力的な側面の一つは、それが特許によって邪魔されないということです。私は（アルファベット順に）邪魔されない認証済み暗号化モードの開発をサポート企業を認めます：
Hifn Intersil MacFergus RSA Security
HIFNインターシルMacFergus RSAセキュリティ
Also, I thank Tero Kivinen for his comprehensive review of this document.
また、私は、この文書の彼の包括的な見直しのためのTERO Kivinenに感謝します。
This section provides normative and informative references.
このセクションでは、規範的で有益な参照を提供します。
[AES] NIST, FIPS PUB 197, "Advanced Encryption Standard (AES)," November 2001.
[AES] NIST、FIPS PUBの197、 "高度暗号化標準（AES）、" 2001年11月。
[DOI] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.
[DOI]パイパー、D.、RFC 2407 "ISAKMPのための解釈のインターネットIPセキュリティー領域"、1998年11月。
[ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[ESP]ケント、S.、 "IPカプセル化セキュリティペイロード（ESP）"、RFC 4303、2005年12月。
[CCM] Whiting, D., Housley, R., and N. Ferguson, "Counter with CBC-MAC (CCM)", RFC 3610, September 2003.
[CCM]ホワイティング、D.、Housley氏、R.、およびN.ファーガソン、 "CBC-MAC（CCM）とカウンター"、RFC 3610、2003年9月。
[STDWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[STDWORDS]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[ARCH] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[ARCH]ケント、S.とK. Seo、 "インターネットプロトコルのためのセキュリティアーキテクチャ"、RFC 4301、2005年12月。
[IKE] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[IKE]ハーキンとD.とD.カレル、 "インターネットキー交換（IKE）"、RFC 2409、1998年11月。
[IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[IKEv2の]カウフマン、C.、 "インターネットキーエクスチェンジ（IKEv2の）プロトコル"、RFC 4306、2005年12月。
[ROAD] Thayer, R., Doraswamy, N., and R. Glenn, "IP Security Document Roadmap", RFC 2411, November 1998.
[ROAD]セイヤー、R.、Doraswamy、N.、およびR.グレン、 "IPセキュリティドキュメントロードマップ"、RFC 2411、1998年11月。
[JUMBO] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms", RFC 2675, August 1999.
[JUMBO】ボーマン、D.、デアリング、S.、およびR. Hindenと "IPv6のジャンボグラム"、RFC 2675、1999年8月。
Author's Address
著者のアドレス
Russell Housley Vigil Security, LLC 918 Spring Knoll Drive Herndon, VA 20170 USA
ラッセルHousley氏ビジルセキュリティ、LLC 918春小山Driveハーンドン、VA 20170 USA
EMail: housley@vigilsec.com
メールアドレス：housley@vigilsec.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権（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.
この文書では、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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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 Editor機能のための基金は現在、インターネット協会によって提供されます。