[要約] RFC 5116 は、認証付き暗号（AEAD: Authenticated Encryption with Associated Data）の使用方法と API 仕様を定義しています。暗号化と同時にメッセージ認証を行い、改ざん検知と機密性を確保します。共通のインタフェースを示すことで、異なる暗号アルゴリズム間の互換性を高めています。
Network Working Group D. McGrew
Request for Comments: 5116 Cisco Systems, Inc.
Category: Standards Track January 2008
An Interface and Algorithms for Authenticated Encryption
認証付き暗号のためのインターフェイスとアルゴリズム
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）の現在の版を参照してください。このメモの配布は無制限です。
Abstract
概要
This document defines algorithms for Authenticated Encryption with Associated Data (AEAD), and defines a uniform interface and a registry for such algorithms. The interface and registry can be used as an application-independent set of cryptoalgorithm suites. This approach provides advantages in efficiency and security, and promotes the reuse of crypto implementations.
このドキュメントは、関連データ付き認証付き暗号（AEAD）のアルゴリズムを定義し、そのようなアルゴリズムのための統一されたインターフェイスとレジストリを定義します。インターフェイスとレジストリは、アプリケーションに依存しない暗号アルゴリズムスイートのセットとして使用できます。このアプローチは、効率とセキュリティの利点を提供し、暗号実装の再利用を促進します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4. Conventions Used in This Document . . . . . . . . . . . . 4
2. AEAD Interface . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Authenticated Encryption . . . . . . . . . . . . . . . . . 5
2.2. Authenticated Decryption . . . . . . . . . . . . . . . . . 7
2.3. Data Formatting . . . . . . . . . . . . . . . . . . . . . 7
3. Guidance on the Use of AEAD Algorithms . . . . . . . . . . . . 8
3.1. Requirements on Nonce Generation . . . . . . . . . . . . . 8
3.2. Recommended Nonce Formation . . . . . . . . . . . . . . . 9
3.2.1. Partially Implicit Nonces . . . . . . . . . . . . . . 10
3.3. Construction of AEAD Inputs . . . . . . . . . . . . . . . 11
3.4. Example Usage . . . . . . . . . . . . . . . . . . . . . . 11
4. Requirements on AEAD Algorithm Specifications . . . . . . . . 12
5. AEAD Algorithms . . . . . . . . . . . . . . . . . . . . . . . 14
5.1. AEAD_AES_128_GCM . . . . . . . . . . . . . . . . . . . . . 14
5.1.1. Nonce Reuse . . . . . . . . . . . . . . . . . . . . . 14
5.2. AEAD_AES_256_GCM . . . . . . . . . . . . . . . . . . . . . 15
5.3. AEAD_AES_128_CCM . . . . . . . . . . . . . . . . . . . . . 15
5.3.1. Nonce Reuse . . . . . . . . . . . . . . . . . . . . . 16
5.4. AEAD_AES_256_CCM . . . . . . . . . . . . . . . . . . . . . 16
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
7. Other Considerations . . . . . . . . . . . . . . . . . . . . . 17
8. Security Considerations . . . . . . . . . . . . . . . . . . . 18
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
10.1. Normative References . . . . . . . . . . . . . . . . . . . 19
10.2. Informative References . . . . . . . . . . . . . . . . . . 19
Authenticated encryption [BN00] is a form of encryption that, in addition to providing confidentiality for the plaintext that is encrypted, provides a way to check its integrity and authenticity. Authenticated Encryption with Associated Data, or AEAD [R02], adds the ability to check the integrity and authenticity of some Associated Data (AD), also called "additional authenticated data", that is not encrypted.
認証付き暗号[BN00]は、暗号化された平文の機密性を提供することに加えて、その整合性と真正性を確認する方法を提供する暗号化の形式です。関連データ付き認証付き暗号、すなわちAEAD [R02]は、暗号化されない「追加の認証データ」とも呼ばれるいくつかの関連データ（AD）の整合性と真正性を確認する機能を追加します。
Many cryptographic applications require both confidentiality and message authentication. Confidentiality is a security service that ensures that data is available only to those authorized to obtain it; usually it is realized through encryption. Message authentication is the service that ensures that data has not been altered or forged by unauthorized entities; it can be achieved by using a Message Authentication Code (MAC). This service is also called data integrity. Many applications use an encryption method and a MAC together to provide both of those security services, with each algorithm using an independent key. More recently, the idea of providing both security services using a single cryptoalgorithm has become accepted. In this concept, the cipher and MAC are replaced by an Authenticated Encryption with Associated Data (AEAD) algorithm.
多くの暗号化アプリケーションには、機密性とメッセージ認証の両方が必要です。機密性は、データを取得することを許可されたもののみがデータを利用できるようにするセキュリティサービスです。通常、暗号化によって実現されます。メッセージ認証とは、不正なエンティティによってデータが変更または偽造されていないことを保証するサービスです。メッセージ認証コード（MAC）を使用して達成できます。このサービスは、データの整合性とも呼ばれます。多くのアプリケーションは、暗号化方法とMACを使用して、これらのセキュリティサービスの両方を提供し、各アルゴリズムは独立したキーを使用しています。より最近では、単一の暗号アルゴリズムを使用して両方のセキュリティサービスを提供するというアイデアが受け入れられました。この概念では、暗号とMACは、関連データ付き認証付き暗号（AEAD）アルゴリズムに置き換えられます。
Several crypto algorithms that implement AEAD algorithms have been defined, including block cipher modes of operation and dedicated algorithms. Some of these algorithms have been adopted and proven useful in practice. Additionally, AEAD is close to an 'idealized' view of encryption, such as those used in the automated analysis of cryptographic protocols (see, for example, Section 2.5 of [BOYD]).
AEADアルゴリズムを実装するいくつかの暗号アルゴリズムが定義されています。これらのアルゴリズムのいくつかは採用されており、実際に有用であることが証明されています。さらに、AEADは、暗号化プロトコルの自動分析で使用されるものなど、暗号化の「理想化された」ビューに近いものです（たとえば、[Boyd]のセクション2.5を参照）。
The benefits of AEAD algorithms, and this interface, are outlined in Section 1.3.
AEADアルゴリズム、およびこのインターフェイスの利点は、セクション1.3で概説されています。
In this document, we define an AEAD algorithm as an abstraction, by specifying an interface to an AEAD and defining an IANA registry for AEAD algorithms. We populate this registry with four AEAD algorithms based on the Advanced Encryption Standard (AES) in Galois/Counter Mode [GCM] with 128- and 256-bit keys, and AES in Counter and CBC MAC Mode [CCM] with 128- and 256-bit keys.
このドキュメントでは、AEADへのインターフェイスを規定し、AEADアルゴリズムのIANAレジストリを定義することにより、AEADアルゴリズムを抽象化されたものとして定義します。このレジストリに、128ビットおよび256ビットのキーを持つGalois/Counter Mode [GCM]のAdvanced Encryption Standard (AES)と、128ビットおよび256ビットのキーを持つCounter and CBC MAC Mode [CCM]のAESに基づく4つのAEADアルゴリズムを登録します。
In the following, we define the AEAD interface (Section 2), and then provide guidance on the use of AEAD algorithms (Section 3), and outline the requirements that each AEAD algorithm must meet (Section 4). Then we define several AEAD algorithms (Section 5), and establish an IANA registry for AEAD algorithms (Section 6). Lastly, we discuss some other considerations (Section 7).
以下では、AEADインターフェイス（セクション2）を定義し、AEADアルゴリズム（セクション3）の使用に関するガイダンスを提供し、各AEADアルゴリズムが満たさなければならない要件（セクション4）を概説します。次に、いくつかのAEADアルゴリズム（セクション5）を定義し、AEADアルゴリズムのIANAレジストリ（セクション6）を確立します。最後に、その他の考慮事項（セクション7）について説明します。
The AEAD interface specification does not address security protocol issues such as anti-replay services or access control decisions that are made on authenticated data. Instead, the specification aims to abstract the cryptography away from those issues. The interface, and the guidance about how to use it, are consistent with the recommendations from [EEM04].
AEADインターフェイスの仕様は、アンチリプレイサービスや、認証されたデータに基づいて行われるアクセス制御の決定などのセキュリティプロトコルの問題には対処しません。代わりに、仕様は、これらの問題から暗号化を抽象化することを目的としています。インターフェイスとそれの使用方法に関するガイダンスは、[EEM04]の推奨事項と一致しています。
The AEAD approach enables applications that need cryptographic security services to more easily adopt those services. It benefits the application designer by allowing them to focus on important issues such as security services, canonicalization, and data marshaling, and relieving them of the need to design crypto mechanisms that meet their security goals. Importantly, the security of an AEAD algorithm can be analyzed independent from its use in a particular application. This property frees the user of the AEAD of the need to consider security aspects such as the relative order of authentication and encryption and the security of the particular combination of cipher and MAC, such as the potential loss of confidentiality through the MAC. The application designer that uses the AEAD interface need not select a particular AEAD algorithm during the design stage. Additionally, the interface to the AEAD is relatively simple, since it requires only a single key as input and requires only a single identifier to indicate the algorithm in use in a particular case.
AEADアプローチにより、暗号化セキュリティサービスが必要なアプリケーションがこれらのサービスをより簡単に採用することを可能にします。セキュリティサービス、正規化、データマーシャリングなどの重要な問題に焦点を当てることができることにより、アプリケーションデザイナーに利益をもたらし、セキュリティ目標を達成する暗号メカニズムを設計する必要性から解放します。重要なことに、AEADアルゴリズムのセキュリティは、特定のアプリケーションでの使用から独立して分析できます。この特性は、認証と暗号化の相対順序などのセキュリティの側面や、MACを介した機密性の潜在的な損失など、暗号とMACの特定の組み合わせのセキュリティを考慮する必要性からAEADのユーザーを解放します。AEADインターフェイスを使用するアプリケーションデザイナーは、設計段階で特定のAEADアルゴリズムを選択する必要はありません。さらに、AEADへのインターフェイスは比較的単純です。これは、入力として単一のキーのみを必要とし、特定のケースで使用されているアルゴリズムを示すために単一の識別子のみを必要とするためです。
The AEAD approach benefits the implementer of the crypto algorithms by making available optimizations that are otherwise not possible to reduce the amount of computation, the implementation cost, and/or the storage requirements. The simpler interface makes testing easier; this is a considerable benefit for a crypto algorithm implementation. By providing a uniform interface to access cryptographic services, the AEAD approach allows a single crypto implementation to more easily support multiple applications. For example, a hardware module that supports the AEAD interface can easily provide crypto acceleration to any application using that interface, even to applications that had not been designed when the module was built.
AEADアプローチは、計算量、実装コスト、および/またはストレージ要件を削減するための、他の方法では不可能な最適化を利用可能にすることにより、暗号アルゴリズムの実装者に利益をもたらします。よりシンプルなインターフェイスにより、テストが簡単になります。これは、暗号アルゴリズムの実装にとって大きな利点です。暗号化サービスにアクセスするための均一なインターフェイスを提供することにより、AEADアプローチにより、単一の暗号実装が複数のアプリケーションをより簡単にサポートできるようになります。たとえば、AEADインターフェイスをサポートするハードウェアモジュールは、モジュールが構築されたときに設計されていないアプリケーションにも、そのインターフェイスを使用して任意のアプリケーションに暗号アクセラレーションを簡単に提供できます。
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」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、「OPTIONAL」は、[RFC2119]で説明されているとおりに解釈されます。
An AEAD algorithm has two operations, authenticated encryption and authenticated decryption. The inputs and outputs of these algorithms are defined below in terms of octet strings.
AEADアルゴリズムには、認証された暗号化と認証された復号化という2つの操作があります。これらのアルゴリズムの入力と出力は、オクテット文字列の観点から以下に定義されています。
An implementation MAY accept additional inputs. For example, an input could be provided to allow the user to select between different implementation strategies. However, such extensions MUST NOT affect interoperability with other implementations.
実装は追加の入力を受け入れる場合があります。たとえば、ユーザーが異なる実装戦略を選択できるように入力を提供できます。ただし、このような拡張機能は、他の実装との相互運用性に影響してはなりません。
The authenticated encryption operation has four inputs, each of which is an octet string:
認証された暗号化操作には4つの入力があり、それぞれがOctet文字列です。
A secret key K, which MUST be generated in a way that is uniformly random or pseudorandom.
秘密鍵Kは、均一にランダムまたは擬似ランダムの方法で生成する必要があります。
A nonce N. Each nonce provided to distinct invocations of the Authenticated Encryption operation MUST be distinct, for any particular value of the key, unless each and every nonce is zero-length. Applications that can generate distinct nonces SHOULD use the nonce formation method defined in Section 3.2, and MAY use any other method that meets the uniqueness requirement. Other applications SHOULD use zero-length nonces.
ナンスN。認証付き暗号化操作の個別の呼び出しに提供される各ナンスは、すべてのナンスが長さゼロでない限り、キーの特定の値に対して異なっていなければなりません。個別のナンスを生成できるアプリケーションは、セクション3.2で定義されているナンス形成法を使用すべきであり（SHOULD）、一意性要件を満たす他の方法を使用してもかまいません（MAY）。他のアプリケーションでは、長さゼロのナンスを使用すべきです（SHOULD）。
A plaintext P, which contains the data to be encrypted and authenticated.
暗号化および認証されるデータを含む平文P。
The associated data A, which contains the data to be authenticated, but not encrypted.
関連するデータAには、認証されるデータが含まれていますが、暗号化されていません。
There is a single output:
単一の出力があります。
A ciphertext C, which is at least as long as the plaintext, or
暗号文C、少なくとも平文と同じくらい長い、または
an indication that the requested encryption operation could not be performed.
要求された暗号化操作を実行できなかったことを示しています。
All of the inputs and outputs are variable-length octet strings, whose lengths obey the following restrictions:
すべての入力と出力は、長さの長さのオクテット文字列であり、その長さは次の制限に従います。
The number of octets in the key K is between 1 and 255. For each AEAD algorithm, the length of K MUST be fixed.
キーKのオクテット数は1〜255です。AEADアルゴリズムごとに、Kの長さを固定する必要があります。
For any particular value of the key, either 1) each nonce provided to distinct invocations of the Authenticated Encryption operation MUST be distinct, or 2) each and every nonce MUST be zero-length. If zero-length nonces are used with a particular key, then each and every nonce used with that key MUST have a length of zero. Otherwise, the number of octets in the nonce SHOULD be twelve (12). Nonces with different lengths MAY be used with a particular key. Some algorithms cannot be used with zero-length nonces, but others can; see Section 4. Applications that conform to the recommended nonce length will avoid having to construct nonces with different lengths, depending on the algorithm that is in use. This guidance helps to keep algorithm-specific logic out of applications.
キーの特定の値については、1）認証付き暗号化操作の個別の呼び出しに提供される各ナンスは異なっていなければならない、または2）すべてのナンスが長さゼロでなければなりません。特定のキーで長さゼロのナンスが使用されている場合、そのキーで使用されるすべてのナンスは長さゼロでなければなりません。それ以外の場合、ナンスのオクテット数は12であるべきです（SHOULD）。特定のキーで異なる長さのナンスを使用してもかまいません（MAY）。一部のアルゴリズムは長さゼロのナンスでは使用できませんが、他のアルゴリズムは使用できます。セクション4を参照してください。推奨されるナンス長に準拠するアプリケーションは、使用中のアルゴリズムに応じて異なる長さのナンスを構築する必要がなくなります。このガイダンスは、アルゴリズム固有のロジックをアプリケーションから排除するのに役立ちます。
The number of octets in the plaintext P MAY be zero.
平文Pのオクテット数はゼロであってもかまいません（MAY）。
The number of octets in the associated data A MAY be zero.
関連するデータAのオクテットの数はゼロになる場合があります。
The number of octets in the ciphertext C MAY be zero.
暗号文Cのオクテット数はゼロであってもかまいません（MAY）。
This specification does not put a maximum length on the nonce, the plaintext, the ciphertext, or the additional authenticated data. However, a particular AEAD algorithm MAY further restrict the lengths of those inputs and outputs. A particular AEAD implementation MAY further restrict the lengths of its inputs and outputs. If a particular implementation of an AEAD algorithm is requested to process an input that is outside the range of admissible lengths, or an input that is outside the range of lengths supported by that implementation, it MUST return an error code and it MUST NOT output any other information. In particular, partially encrypted or partially decrypted data MUST NOT be returned.
この仕様では、ナンス、平文、暗号文、または追加の認証データに最大長を設けません。ただし、特定のAEADアルゴリズムは、これらの入力と出力の長さをさらに制限する場合があります。特定のAEAD実装は、入力と出力の長さをさらに制限する場合があります。AEADアルゴリズムの特定の実装が、許容される長さの範囲外の入力、またはその実装によってサポートされている長さの範囲外の入力を処理することを要求された場合、エラーコードを返す必要があり、その他の情報を出力してはなりません。特に、部分的に暗号化されたデータまたは部分的に復号化されたデータを返してはいけません。
Both confidentiality and message authentication are provided on the plaintext P. When the length of P is zero, the AEAD algorithm acts as a Message Authentication Code on the input A.
機密性とメッセージ認証の両方が平文Pで提供されます。Pの長さがゼロの場合、AEADアルゴリズムは入力Aのメッセージ認証コードとして機能します。
The associated data A is used to protect information that needs to be authenticated, but does not need to be kept confidential. When using an AEAD to secure a network protocol, for example, this input could include addresses, ports, sequence numbers, protocol version numbers, and other fields that indicate how the plaintext or ciphertext should be handled, forwarded, or processed. In many situations, it is desirable to authenticate these fields, though they must be left in the clear to allow the network or system to function properly. When this data is included in the input A, authentication is provided without copying the data into the plaintext.
関連データAは、認証が必要な情報を保護するために使用されますが、機密に保つ必要はありません。たとえば、AEADを使用してネットワークプロトコルを保護する場合、この入力には、アドレス、ポート、シーケンス番号、プロトコルバージョン番号、および平文または暗号文を処理、転送、または処理する方法を示すその他のフィールドが含まれる可能性があります。多くの状況では、これらのフィールドを認証することが望ましいですが、ネットワークまたはシステムが適切に機能できるようにするには、平文のままにしておく必要があります。このデータが入力Aに含まれている場合、データを平文にコピーすることなく認証が提供されます。
The secret key K MUST NOT be included in any of the other inputs (N, P, and A). (This restriction does not mean that the values of those inputs must be checked to ensure that they do not include substrings that match the key; instead, it means that the key must not be explicitly copied into those inputs.)
秘密鍵Kは、他の入力（N、P、およびA）のいずれにも含めてはなりません。（この制限は、これらの入力の値をチェックして、キーと一致するサブストリングを含めないことを確認する必要があるという意味ではありません。代わりに、キーをそれらの入力に明示的にコピーしてはならないことを意味します。）
The nonce is authenticated internally to the algorithm, and it is not necessary to include it in the AD input. The nonce MAY be included in P or A if it is convenient to the application.
ナンスはアルゴリズム内部で認証されるため、AD入力に含める必要はありません。ナンスは、アプリケーションに便利な場合はPまたはAに含まれる場合があります。
The nonce MAY be stored or transported with the ciphertext, or it MAY be reconstructed immediately prior to the authenticated decryption operation. It is sufficient to provide the decryption module with enough information to allow it to construct the nonce. (For example, a system could use a nonce consisting of a sequence number in a particular format, in which case it could be inferred from the order of the ciphertexts.) Because the authenticated decryption process detects incorrect nonce values, no security failure will result if a nonce is incorrectly reconstructed and fed into an authenticated decryption operation. Any nonce reconstruction method will need to take into account the possibility of loss or reorder of ciphertexts between the encryption and decryption processes.
ナンスは、暗号文と共に保存または転送される場合があります。または、認証付き復号化操作の直前に再構築される場合があります。復号化モジュールに、ナンスを構築できるように十分な情報を提供するだけで十分です。（たとえば、システムは、特定の形式のシーケンス番号で構成されるナンスを使用できます。この場合、暗号文の順序から推測できます。）認証付き復号化プロセスが誤ったナンス値を検出するため、ナンスが誤って再構築され、認証付き復号化操作に供給されたとしても、セキュリティ上の失敗は発生しません。ナンス再構成方法は、暗号化と復号化プロセスの間の暗号文の損失または順序変更の可能性を考慮に入れる必要があります。
Applications MUST NOT assume any particular structure or formatting of the ciphertext.
アプリケーションは、暗号文の特定の構造またはフォーマットを想定してはなりません。
The authenticated decryption operation has four inputs: K, N, A, and C, as defined above. It has only a single output, either a plaintext value P or a special symbol FAIL that indicates that the inputs are not authentic. A ciphertext C, a nonce N, and associated data A are authentic for key K when C is generated by the encrypt operation with inputs K, N, P, and A, for some values of N, P, and A. The authenticated decrypt operation will, with high probability, return FAIL whenever the inputs N, P, and A were crafted by a nonce-respecting adversary that does not know the secret key (assuming that the AEAD algorithm is secure).
認証付き復号化操作には、上記で定義されているように、K、N、A、Cの4つの入力があります。平文値Pまたは入力が真正ではないことを示す特別なシンボルFAILのいずれかの単一の出力のみがあります。N、P、およびAの一部の値について、入力K、N、P、およびAを使用した暗号化操作によってCが生成される場合、暗号文C、ナンスN、および関連データAはキーKに対して真正です。認証付き復号化操作は、入力N、P、およびAが秘密鍵を知らないナンスを尊重する攻撃者によって作成された場合、高い確率でFAILを返します（AEADアルゴリズムが安全であると仮定）。
This document does not specify any particular encoding for the AEAD inputs and outputs, since the encoding does not affect the security services provided by an AEAD algorithm.
エンコードはAEADアルゴリズムによって提供されるセキュリティサービスに影響しないため、このドキュメントではAEAD入力と出力の特定のエンコードは指定されていません。
When choosing the format of application data, an application SHOULD position the ciphertext C so that it appears after any other data that is needed to construct the other inputs to the authenticated decryption operation. For instance, if the nonce and ciphertext both appear in a packet, the former value should precede the latter. This rule facilitates efficient and simple hardware implementations of AEAD algorithms.
アプリケーションデータの形式を選択するとき、アプリケーションは、認証付き復号化操作への他の入力を構築するために必要な他のデータの後に表示されるように、暗号文Cを配置すべきです（SHOULD）。たとえば、ナンスと暗号文が両方ともパケットに表示される場合、前者の値は後者に先行するはずです。このルールは、AEADアルゴリズムの効率的でシンプルなハードウェア実装を容易にします。
This section provides advice that must be followed in order to use an AEAD algorithm securely.
このセクションでは、AEADアルゴリズムを安全に使用するために従わなければならないアドバイスを提供します。
If an application is unable to meet the uniqueness requirement on nonce generation, then it MUST use a zero-length nonce. Randomized or stateful algorithms, which are defined below, are suitable for use with such applications. Otherwise, an application SHOULD use nonces with a length of twelve octets. Since algorithms are encouraged to support that length, applications should use that length to aid interoperability.
アプリケーションがナンス生成の一意性要件を満たすことができない場合、長さゼロのナンスを使用しなければなりません。以下に定義されているランダム化またはステートフルアルゴリズムは、そのようなアプリケーションでの使用に適しています。それ以外の場合、アプリケーションでは、12オクテットの長さのナンスを使用すべきです。アルゴリズムはその長さをサポートするように推奨されるため、アプリケーションはその長さを使用して相互運用性を支援すべきです。
It is essential for security that the nonces be constructed in a manner that respects the requirement that each nonce value be distinct for each invocation of the authenticated encryption operation, for any fixed value of the key. In this section, we call attention to some consequences of this requirement in different scenarios.
セキュリティにとって、ナンスは、キーの固定値に対して、認証付き暗号化操作の各呼び出しごとに各ナンス値が異なるという要件を遵守する方法で構築されることが不可欠です。このセクションでは、さまざまなシナリオでこの要件のいくつかの結果に注意を喚起します。
When there are multiple devices performing encryption using a single key, those devices must coordinate to ensure that the nonces are unique. A simple way to do this is to use a nonce format that contains a field that is distinct for each one of the devices, as described in Section 3.2. Note that there is no need to coordinate the details of the nonce format between the encrypter and the decrypter, as long the entire nonce is sent or stored with the ciphertext and is thus available to the decrypter. If the complete nonce is not available to the decrypter, then the decrypter will need to know how the nonce is structured so that it can reconstruct it. Applications SHOULD provide encryption engines with some freedom in choosing their nonces; for example, a nonce could contain both a counter and a field that is set by the encrypter but is not processed by the receiver. This freedom allows a set of encryption devices to more readily coordinate to ensure the distinctness of their nonces.
単一のキーを使用して暗号化を実行する複数のデバイスがある場合、それらのデバイスは、ナンスが一意であることを確認するために調整する必要があります。これを行う簡単な方法は、セクション3.2で説明されているように、デバイスのそれぞれに対して異なるフィールドを含むナンス形式を使用することです。ナンス全体が暗号文と共に送信または保存され、復号化器が利用できる限り、暗号化器と復号化器の間でナンス形式の詳細を調整する必要はないことに注意してください。完全なナンスが復号化器で利用できない場合、復号化器はそれを再構築できるように、ナンスがどのように構造化されているかを知る必要があります。アプリケーションは、暗号化エンジンに、ナンスを選択する自由を提供すべきです。たとえば、ナンスには、暗号化器によって設定されているが、受信機によって処理されないカウンターとフィールドの両方を含めることができます。この自由により、一連の暗号化デバイスがより容易に調整して、ナンスの独自性を確保できます。
If a secret key will be used for a long period of time, e.g., across multiple reboots, then the nonce will need to be stored in non-volatile memory. In such cases, it is essential to use checkpointing of the nonce; that is, the current nonce value should be stored to provide the state information needed to resume encryption in case of unexpected failure. One simple way to provide a high assurance that a nonce value will not be used repeatedly is to wait until the encryption process receives confirmation from the storage process indicating that the succeeding nonce value has already been stored. Because this method may add significant latency, it may be desirable to store a nonce value that is several values ahead in the sequence. As an example, the nonce 100 could be stored, after which the nonces 1 through 99 could be used for encryption. The nonce value 200 could be stored at the same time that nonces 1 through 99 are being used, and so on.
秘密鍵が長期間使用される場合、たとえば複数の再起動にまたがって使用される場合、ナンスは不揮発性メモリに保存する必要があります。そのような場合、ナンスのチェックポイントを使用することが不可欠です。つまり、現在のナンス値は、予期しない障害の場合に暗号化を再開するために必要な状態情報を提供するために保存する必要があります。ナンス値が繰り返し使用されないという高い保証を提供する簡単な方法の1つは、暗号化プロセスが保存プロセスから確認を受信して、後続のナンス値が既に保存されていることを示すまで待つことです。この方法は大きな遅延を追加する可能性があるため、シーケンスのいくつか先のナンス値を保存することが望ましい場合があります。例として、ナンス100を保存し、その後、ナンス1から99を暗号化に使用できます。ナンス値200は、ナンス1から99が使用されている間に保存できます。
Many problems with nonce reuse can be avoided by changing a key in a situation in which nonce coordination is difficult.
ナンスの調整が困難な状況では、キーを変更することで、ナンスの再利用に関する多くの問題を回避できます。
Each AEAD algorithm SHOULD describe what security degradation would result from an inadvertent reuse of a nonce value.
各AEADアルゴリズムは、ナンス値の不注意な再利用からどのようなセキュリティの劣化が生じるかを説明すべきです。
The following method to construct nonces is RECOMMENDED. The nonce is formatted as illustrated in Figure 1, with the initial octets consisting of a Fixed field, and the final octets consisting of a Counter field. For each fixed key, the length of each of these fields, and thus the length of the nonce, is fixed. Implementations SHOULD support 12-octet nonces in which the Counter field is four octets long.
ナンスを構築するための次の方法が推奨されます。ナンスは、図1に示すようにフォーマットされており、最初のオクテットは固定フィールドで構成され、最後のオクテットはカウンターフィールドで構成されています。固定キーごとに、これらの各フィールドの長さ、したがってナンスの長さが固定されています。実装は、カウンターフィールドの長さが4オクテットの12オクテットのナンスをサポートすべきです。
<----- variable ----> <----------- variable ----------->
+---------------------+----------------------------------+
| Fixed | Counter |
+---------------------+----------------------------------+
Figure 1: Recommended nonce format
図1：推奨されるナンス形式
The Counter fields of successive nonces form a monotonically increasing sequence, when those fields are regarded as unsigned integers in network byte order. The length of the Counter field MUST remain constant for all nonces that are generated for a given encryption device. The Counter part SHOULD be equal to zero for the first nonce, and increment by one for each successive nonce that is generated. However, any particular Counter value MAY be skipped over, and left out of the sequence of values that are used, if it is convenient. For example, an application could choose to skip the initial Counter=0 value, and set the Counter field of the initial nonce to 1. Thus, at most 2^(8*C) nonces can be generated when the Counter field is C octets in length.
連続したナンスのカウンターフィールドは、これらのフィールドがネットワークバイト順で符号なし整数と見なされる場合、単調に増加するシーケンスを形成します。カウンターフィールドの長さは、特定の暗号化デバイスに対して生成されるすべてのナンスに対して一定のままでなければなりません。カウンター部分は、最初のナンスではゼロに等しく、生成される連続したナンスごとに1つずつ増加すべきです。ただし、特定のカウンター値がスキップされ、便利な場合は使用される値のシーケンスから除外される場合があります。たとえば、アプリケーションは、初期カウンター= 0値をスキップし、初期のナンスのカウンターフィールドを1に設定することを選択できます。したがって、カウンターフィールドの長さがCオクテットの場合、最大で2^(8*C)個のナンスを生成できます。
The Fixed field MUST remain constant for all nonces that are generated for a given encryption device. If different devices are performing encryption with a single key, then each distinct device MUST use a distinct Fixed field, to ensure the uniqueness of the nonces. Thus, at most 2^(8*F) distinct encrypters can share a key when the Fixed field is F octets in length.
固定フィールドは、特定の暗号化デバイスに対して生成されたすべてのナンスに対して一定のままでなければなりません。異なるデバイスが単一のキーを使用して暗号化を実行している場合、それぞれの異なるデバイスは、ナンスの一意性を確保するために、異なる固定フィールドを使用する必要があります。したがって、固定フィールドの長さがFオクテットの場合、最大で2^(8*F)個の異なる暗号化器がキーを共有できます。
In some cases, it is desirable to not transmit or store an entire nonce, but instead to reconstruct that value from contextual information immediately prior to decryption. As an example, ciphertexts could be stored in sequence on a disk, and the nonce for a particular ciphertext could be inferred from its location, as long as the rule for generating the nonces is known by the decrypter. We call the portion of the nonce that is stored or sent with the ciphertext the explicit part. We call the portion of the nonce that is inferred the implicit part. When part of the nonce is implicit, the following specialization of the above format is RECOMMENDED. The Fixed field is divided into two sub-fields: a Fixed-Common field and a Fixed-Distinct field. This format is shown in Figure 2. If different devices are performing encryption with a single key, then each distinct device MUST use a distinct Fixed-Distinct field. The Fixed-Common field is common to all nonces. The Fixed-Distinct field and the Counter field MUST be in the explicit part of the nonce. The Fixed-Common field MAY be in the implicit part of the nonce. These conventions ensure that the nonce is easy to reconstruct from the explicit data.
場合によっては、ナンス全体を送信または保存せずに、代わりに復号化の直前にコンテキスト情報からその値を再構築することが望ましいです。例として、暗号文はディスク上に順番に保存され、特定の暗号文のナンスは、ナンスを生成するためのルールが復号化器に知られている限り、その場所から推測することができます。暗号文と共に保存または送信されるナンスの部分を明示的な部分と呼びます。推測されるナンスの部分を暗黙の部分と呼びます。ナンスの一部が暗黙的である場合、上記の形式の以下の特化が推奨されます。固定フィールドは、固定共通フィールドと固定個別フィールドの2つのサブフィールドに分割されます。この形式を図2に示します。異なるデバイスが単一のキーを使用して暗号化を実行している場合、それぞれの異なるデバイスは個別の固定個別フィールドを使用する必要があります。固定共通フィールドは、すべてのナンスに共通しています。固定個別フィールドとカウンターフィールドは、ナンスの明示的な部分にある必要があります。固定共通フィールドは、ナンスの暗黙の部分にある可能性があります。これらの規則により、ナンスが明示的なデータから簡単に再構築できるようになります。
+-------------------+--------------------+---------------+
| Fixed-Common | Fixed-Distinct | Counter |
+-------------------+--------------------+---------------+
<---- implicit ---> <------------ explicit ------------>
Figure 2: Partially implicit nonce format
図2：部分的に暗黙のナンス形式
The rationale for the partially implicit nonce format is as follows. This method of nonce construction incorporates the best known practice; it is used by both GCM Encapuslating Security Payload (ESP) [RFC4106] and CCM ESP [RFC4309], in which the Fixed field contains the Salt value and the lowest eight octets of the nonce are explicitly carried in the ESP packet. In GCM ESP, the Fixed field must be at least four octets long, so that it can contain the Salt value. In CCM ESP, the Fixed field must be at least three octets long for the same reason. This nonce generation method is also used by several counter mode variants including CTR ESP.
部分的に暗黙のナンス形式の理論的根拠は次のとおりです。このナンス構築の方法には、最もよく知られているプラクティスが組み込まれています。これは、GCMカプセル化セキュリティペイロード（ESP）[RFC4106]とCCM ESP [RFC4309]の両方で使用されます。ここでは、固定フィールドにはソルト値が含まれ、ナンスの最下位8オクテットがESPパケットで明示的に運ばれます。GCM ESPでは、固定フィールドはソルト値を含めることができるように、少なくとも4オクテットの長さでなければなりません。CCM ESPでは、固定フィールドは同じ理由で少なくとも3オクテットの長さでなければなりません。このナンス生成法は、CTR ESPを含むいくつかのカウンターモードバリアントによっても使用されます。
If the AD input is constructed out of multiple data elements, then it is essential that it be unambiguously parseable into its constituent elements, without the use of any unauthenticated data in the parsing process. (In mathematical terms, the AD input must be an injective function of the data elements.) If an application constructs its AD input in such a way that there are two distinct sets of data elements that result in the same AD value, then an attacker could cause a receiver to accept a bogus set by substituting one set for the other. The requirement that the AD be uniquely parseable ensures that this attack is not possible. This requirement is trivially met if the AD is composed of fixed-width elements. If the AD contains a variable-length string, for example, this requirement can be met by also including the length of the string in the AD.
AD入力が複数のデータ要素から構築されている場合、解析プロセスで認証されていないデータを使用せずに、その構成要素に一意に解析可能であることが不可欠です。（数学用語では、AD入力はデータ要素の単射関数でなければなりません。）アプリケーションがAD入力を構築する場合、同じAD値になる2つの異なるデータ要素のセットがあるようにすると、攻撃者は一方のセットを他方のセットに置き換えることで、受信者に偽のセットを受け入れさせることができます。ADが一意に解析可能であるという要件は、この攻撃が不可能であることを保証します。この要件は、ADが固定幅要素で構成されている場合、簡単に満たされます。たとえば、ADに可変長文字列が含まれている場合、この要件は、ADに文字列の長さを含めることで満たすことができます。
Similarly, if the plaintext is constructed out of multiple data elements, then it is essential that it be unambiguously parseable into its constituent elements, without using any unauthenticated data in the parsing process. Note that data included in the AD may be used when parsing the plaintext, though of course since the AD is not encrypted there is a potential loss of confidentiality when information about the plaintext is included in the AD.
同様に、平文が複数のデータ要素から構築されている場合、解析プロセスで認証されていないデータを使用せずに、構成要素に一意に解析可能であることが不可欠です。ADに含まれるデータは、平文を解析するときに使用できることに注意してください。もちろん、ADは暗号化されていないため、平文に関する情報がADに含まれている場合、機密性の潜在的な損失があります。
To make use of an AEAD algorithm, an application must define how the encryption algorithm's inputs are defined in terms of application data, and how the ciphertext and nonce are conveyed. The clearest way to do this is to express each input in terms of the data that form it, then to express the application data in terms of the outputs of the AEAD encryption operation.
AEADアルゴリズムを使用するには、アプリケーションは、暗号化アルゴリズムの入力がアプリケーションデータの観点から定義される方法と、暗号文とナンスの伝達方法を定義する必要があります。これを行う最も明確な方法は、それを形成するデータに関して各入力を表現し、AEAD暗号化操作の出力に関してアプリケーションデータを表現することです。
For example, AES-GCM ESP [RFC4106] can be expressed as follows. The AEAD inputs are
たとえば、AES-GCM ESP [RFC4106]は次のように表現できます。AEAD入力はです
P = RestOfPayloadData || TFCpadding || Padding || PadLength ||
NextHeader
N = Salt || IV
A = SPI || SequenceNumber
where the symbol "||" denotes the concatenation operation, and the fields RestOfPayloadData, TFCpadding, Padding, PadLength, NextHeader, SPI, and SequenceNumber are as defined in [RFC4303], and the fields Salt and IV are as defined in [RFC4106]. The field RestOfPayloadData contains the plaintext data that is described by the NextHeader field, and no other data. (Recall that the PayloadData field contains both the IV and the RestOfPayloadData; see Figure 2 of [RFC4303] for an illustration.)
記号「||」は連結操作を示し、フィールド RestOfPayloadData、TFCpadding、Padding、PadLength、NextHeader、SPI、および SequenceNumber は [RFC4303] で定義されている通りであり、フィールド Salt および IV は [RFC4106] で定義されている通りです。フィールド RestOfPayloadData には、NextHeader フィールドで記述される平文データが含まれ、他のデータは含まれません。（PayloadData フィールドには、IV と RestOfPayloadData の両方が含まれていることを思い出してください。図については、[RFC4303] の図 2 を参照してください。）
The format of the ESP packet can be expressed as
ESPパケットの形式は、
ESP = SPI || SequenceNumber || IV || C
where C is the AEAD ciphertext (which in this case incorporates the authentication tag). Please note that here we have not described the use of the ESP Extended Sequence Number.
ここで、CはAEAD暗号文です（この場合、認証タグが組み込まれています）。ここでは、ESP拡張シーケンス番号の使用については説明していないことに注意してください。
Each AEAD algorithm MUST only accept keys with a fixed key length K_LEN, and MUST NOT require any particular data format for the keys provided as input. An algorithm that requires such structure (e.g., one with subkeys in a particular parity-check format) will need to provide it internally.
各AEADアルゴリズムは、固定キー長K_LENのキーのみを受け入れる必要があり、入力として提供されるキーの特定のデータ形式を必要としてはいけません。そのような構造を必要とするアルゴリズム（たとえば、特定のパリティチェック形式のサブキーを持つ）は、内部でそれを提供する必要があります。
Each AEAD algorithm MUST accept any plaintext with a length between zero and P_MAX octets, inclusive, where the value P_MAX is specific to that algorithm. The value of P_MAX MUST be larger than zero, and SHOULD be at least 65,536 (2^16) octets. This size is a typical upper limit for network data packets. Other applications may use even larger values of P_MAX, so it is desirable for general-purpose algorithms to support higher values.
各AEADアルゴリズムは、値P_MAXがそのアルゴリズムに固有の値であるゼロとP_MAXオクテットの長さの平文を受け入れる必要があります。P_MAXの値はゼロよりも大きくなければならず、少なくとも65,536（2^16）オクテットであるべきです。このサイズは、ネットワークデータパケットの典型的な上限です。他のアプリケーションはP_MAXのさらに大きな値を使用する可能性があるため、汎用アルゴリズムがより高い値をサポートすることが望ましいです。
Each AEAD algorithm MUST accept any associated data with a length between zero and A_MAX octets, inclusive, where the value A_MAX is specific to that algorithm. The value of A_MAX MUST be larger than zero, and SHOULD be at least 65,536 (2^16) octets. Other applications may use even larger values of A_MAX, so it is desirable for general-purpose algorithms to support higher values.
各AEADアルゴリズムは、ゼロとA_maxのオクテットの長さの関連データを受け入れる必要があります。A_MAXの値はゼロよりも大きくなければならず、少なくとも65,536（2^16）オクテットでなければなりません。他のアプリケーションはA_MAXのさらに大きな値を使用する可能性があるため、汎用アルゴリズムがより高い値をサポートすることが望ましいです。
Each AEAD algorithm MUST accept any nonce with a length between N_MIN and N_MAX octets, inclusive, where the values of N_MIN and N_MAX are specific to that algorithm. The values of N_MAX and N_MIN MAY be equal. Each algorithm SHOULD accept a nonce with a length of twelve (12) octets. Randomized or stateful algorithms, which are described below, MAY have an N_MAX value of zero.
各AEADアルゴリズムは、N_MINとN_MAXオクテットの長さの任意のナンスを受け入れる必要があります。N_MAXとN_MINの値は等しい場合があります。各アルゴリズムは、12（12）のオクテットの長さのナンスを受け入れるべきです。以下で説明するランダム化またはステートフルアルゴリズムのN_MAX値はゼロの場合があります。
An AEAD algorithm MAY structure its ciphertext output in any way; for example, the ciphertext can incorporate an authentication tag. Each algorithm SHOULD choose a structure that is amenable to efficient processing.
AEADアルゴリズムは、その暗号文の出力を何らかの形で構成する場合があります。たとえば、ciphertextに認証タグを組み込むことができます。各アルゴリズムは、効率的な処理に適した構造を選択する必要があります。
An Authenticated Encryption algorithm MAY incorporate or make use of a random source, e.g., for the generation of an internal initialization vector that is incorporated into the ciphertext output. An AEAD algorithm of this sort is called randomized; though note that only encryption is random, and decryption is always deterministic. A randomized algorithm MAY have a value of N_MAX that is equal to zero.
認証された暗号化アルゴリズムは、ランダムソースを組み込んだり、使用したりする場合があります。この種のAEADアルゴリズムは、ランダム化と呼ばれます。ただし、暗号化のみがランダムであり、復号化は常に決定論的であることに注意してください。ランダム化されたアルゴリズムには、ゼロに等しいN_MAXの値がある場合があります。
An Authenticated Encryption algorithm MAY incorporate internal state information that is maintained between invocations of the encrypt operation, e.g., to allow for the construction of distinct values that are used as internal nonces by the algorithm. An AEAD algorithm of this sort is called stateful. This method could be used by an algorithm to provide good security even when the application inputs zero-length nonces. A stateful algorithm MAY have a value of N_MAX that is equal to zero.
認証付き暗号化アルゴリズムには、アルゴリズムによって内部ナンスとして使用される個別の値の構築を可能にするために、暗号化操作の呼び出しの間に維持される内部状態情報を組み込むことができます。この種のAEADアルゴリズムは、ステートフルと呼ばれます。この方法は、アプリケーションが長さゼロのナンスを入力した場合でも、適切なセキュリティを提供するためにアルゴリズムによって使用できます。ステートフルアルゴリズムは、ゼロに等しいN_MAXの値を持っている場合があります。
The specification of an AEAD algorithm MUST include the values of K_LEN, P_MAX, A_MAX, N_MIN, and N_MAX defined above. Additionally, it MUST specify the number of octets in the largest possible ciphertext, which we denote C_MAX.
AEADアルゴリズムの仕様には、上記で定義されたK_LEN、P_MAX、A_MAX、N_MIN、およびN_MAXの値を含める必要があります。さらに、C_MAXを示す可能性のある最大の暗号文のオクテット数を指定する必要があります。
Each AEAD algorithm MUST provide a description relating the length of the plaintext to that of the ciphertext. This relation MUST NOT depend on external parameters, such as an authentication strength parameter (e.g., authentication tag length). That sort of dependence would complicate the use of the algorithm by creating a situation in which the information from the AEAD registry was not sufficient to ensure interoperability.
各AEADアルゴリズムは、プレーンテキストの長さを暗号文の長さに関連付ける説明を提供する必要があります。この関係は、認証強度パラメーター（認証タグの長さなど）などの外部パラメーターに依存してはなりません。この種の依存関係は、AEADレジストリからの情報が相互運用性を確保するのに十分ではない状況を作成することにより、アルゴリズムの使用を複雑にするでしょう。
EACH AEAD algorithm specification SHOULD describe what security degradation would result from an inadvertent reuse of a nonce value.
各AEADアルゴリズムの仕様は、ナンス値の不注意な再利用からセキュリティの劣化がどのような結果として生じるかを説明すべきです。
Each AEAD algorithm specification SHOULD provide a reference to a detailed security analysis. This document does not specify a particular security model, because several different models have been used in the literature. The security analysis SHOULD define or reference a security model.
各AEADアルゴリズムの仕様は、詳細なセキュリティ分析への参照を提供する必要があります。いくつかの異なるモデルが文献で使用されているため、このドキュメントは特定のセキュリティモデルを指定していません。セキュリティ分析では、セキュリティモデルを定義または参照する必要があります。
An algorithm that is randomized or stateful, as defined above, SHOULD describe itself using those terms.
上記で定義されているように、ランダム化またはステートフルであるアルゴリズムは、それらの用語を使用してそれ自体を記述する必要があります。
This section defines four AEAD algorithms; two are based on AES GCM, two are based on AES CCM. Each pair includes an algorithm with a key size of 128 bits and one with a key size of 256 bits.
このセクションでは、4つのAEADアルゴリズムを定義します。2つはAES GCMに基づいており、2つはAES CCMに基づいています。各ペアには、キーサイズの128ビットとキーサイズが256ビットのアルゴリズムが含まれています。
The AEAD_AES_128_GCM authenticated encryption algorithm works as specified in [GCM], using AES-128 as the block cipher, by providing the key, nonce, and plaintext, and associated data to that mode of operation. An authentication tag with a length of 16 octets (128 bits) is used. The AEAD_AES_128_GCM ciphertext is formed by appending the authentication tag provided as an output to the GCM encryption operation to the ciphertext that is output by that operation. Test cases are provided in the appendix of [GCM]. The input and output lengths are as follows:
AEAD_AES_128_GCM認証付き暗号化アルゴリズムは、[GCM]で指定されているように機能し、AES-128をブロック暗号として使用し、キー、ナンス、平文、および関連データをその動作モードに提供します。長さ16オクテット（128ビット）の認証タグが使用されます。AEAD_AES_128_GCM暗号文は、GCM暗号化操作への出力として提供される認証タグを、その操作によって出力される暗号文に追加することによって形成されます。テストケースは[GCM]の付録に記載されています。入力と出力の長さは次のとおりです。
K_LEN is 16 octets,
K_LENは16オクテットです、
P_MAX is 2^36 - 31 octets,
P_MAXは2^36-31オクテットです、
A_MAX is 2^61 - 1 octets,
A_MAXは2^61-1オクテットです、
N_MIN and N_MAX are both 12 octets, and
N_MINとN_MAXはどちらも12オクテットです
C_MAX is 2^36 - 15 octets.
C_MAXは2^36-15オクテットです。
An AEAD_AES_128_GCM ciphertext is exactly 16 octets longer than its corresponding plaintext.
AEAD_AES_128_GCM暗号文は、対応する平文よりもちょうど16オクテット長いです。
A security analysis of GCM is available in [MV04].
GCMのセキュリティ分析は[MV04]で入手できます。
The inadvertent reuse of the same nonce by two invocations of the GCM encryption operation, with the same key, but with distinct plaintext values, undermines the confidentiality of the plaintexts protected in those two invocations, and undermines all of the authenticity and integrity protection provided by that key. For this reason, GCM should only be used whenever nonce uniqueness can be provided with assurance. The design feature that GCM uses to achieve minimal latency causes the vulnerabilities on the subsequent uses of the key. Note that it is acceptable to input the same nonce value multiple times to the decryption operation.
同じキーを使用して、GCM暗号化操作の2つの呼び出しによる同じナンスの不注意な再利用は、異なる平文値を持つ場合、これらの2つの呼び出しで保護されている平文の機密性を損ない、そのキーによって提供されるすべての真正性と整合性の保護を損ないます。このため、GCMは、ナンスの一意性を保証できる場合にのみ使用すべきです。GCMが最小限のレイテンシを達成するために使用する設計機能は、キーのその後の使用における脆弱性を引き起こします。同じナンス値を復号化操作に複数回入力することは許容されることに注意してください。
The security consequences are quite serious if an attacker observes two ciphertexts that were created using the same nonce and key values, unless the plaintext and AD values in both invocations of the encrypt operation were identical. First, a loss of confidentiality ensues because he will be able to reconstruct the bitwise exclusive-or of the two plaintext values. Second, a loss of integrity ensues because the attacker will be able to recover the internal hash key used to provide data integrity. Knowledge of this key makes subsequent forgeries trivial.
攻撃者が、暗号化操作の両方の呼び出しの平文とAD値が同一でない限り、同じナンスとキー値を使用して作成された2つの暗号文を観察する場合、セキュリティの結果は非常に深刻です。第一に、彼は2つの平文値のビットごとの排他的論理和を再構築できるため、機密性の損失が生じます。第二に、攻撃者はデータの整合性を提供するために使用される内部ハッシュキーを回復できるため、整合性の喪失が生じます。この鍵の知識は、その後の偽造を容易にします。
This algorithm is identical to AEAD_AES_128_GCM, but with the following differences:
このアルゴリズムは、AEAD_AES_128_GCMと同じですが、次の違いがあります。
K_LEN is 32 octets, instead of 16 octets, and
K_LENは16オクテットの代わりに32オクテットです。
AES-256 GCM is used instead of AES-128 GCM.
AES-256 GCMがAES-128 GCMの代わりに使用されます。
The AEAD_AES_128_CCM authenticated encryption algorithm works as specified in [CCM], using AES-128 as the block cipher, by providing the key, nonce, associated data, and plaintext to that mode of operation. The formatting and counter generation function are as specified in Appendix A of that reference, and the values of the parameters identified in that appendix are as follows:
AEAD_AES_128_CCM認証付き暗号化アルゴリズムは、[CCM]で指定されているように機能し、AES-128をブロック暗号として使用し、キー、ナンス、関連データ、および平文をその動作モードに提供します。フォーマットおよびカウンター生成関数は、その参照の付録Aで指定されているとおりであり、その付録で特定されたパラメーターの値は次のとおりです。
the nonce length n is 12,
ナンスの長さnは12です
the tag length t is 16, and
タグの長さtは16です
the value of q is 3.
qの値は3です。
An authentication tag with a length of 16 octets (128 bits) is used. The AEAD_AES_128_CCM ciphertext is formed by appending the authentication tag provided as an output to the CCM encryption operation to the ciphertext that is output by that operation. Test cases are provided in [CCM]. The input and output lengths are as follows:
長さ16オクテット（128ビット）の認証タグが使用されます。AEAD_AES_128_CCM暗号文は、CCM暗号化操作への出力として提供される認証タグを、その操作によって出力される暗号文に追加することにより形成されます。テストケースは[CCM]で提供されます。入力と出力の長さは次のとおりです。
K_LEN is 16 octets,
K_LENは16オクテットです、
P_MAX is 2^24 - 1 octets,
P_MAXは2^24-1オクテットです、
A_MAX is 2^64 - 1 octets,
A_MAXは2^64-1オクテットです、
N_MIN and N_MAX are both 12 octets, and
N_MINとN_MAXはどちらも12オクテットです
C_MAX is 2^24 + 15 octets.
C_MAXは2^24 + 15オクテットです。
An AEAD_AES_128_CCM ciphertext is exactly 16 octets longer than its corresponding plaintext.
AEAD_AES_128_CCM暗号文は、対応する平文よりもちょうど16オクテット長いです。
A security analysis of AES CCM is available in [J02].
AES CCMのセキュリティ分析は[J02]で入手できます。
Inadvertent reuse of the same nonce by two invocations of the CCM encryption operation, with the same key, undermines the security for the messages processed with those invocations. A loss of confidentiality ensues because an adversary will be able to reconstruct the bitwise exclusive-or of the two plaintext values.
同じキーを使用して、CCM暗号化操作の2つの呼び出しによる同じナンスの不注意な再利用は、それらの呼び出しで処理されたメッセージのセキュリティを損ないます。敵対者が2つの平文値のビットごとの排他的論理和を再構築できるため、機密性の損失が生じます。
This algorithm is identical to AEAD_AES_128_CCM, but with the following differences:
このアルゴリズムは、AEAD_AES_128_CCMと同じですが、次の違いがあります。
K_LEN is 32 octets, instead of 16, and
K_LENは16ではなく32オクテットです。
AES-256 CCM is used instead of AES-128 CCM.
AES-256 CCMがAES-128 CCMの代わりに使用されます。
The Internet Assigned Numbers Authority (IANA) has defined the "AEAD Registry" described below. An algorithm designer MAY register an algorithm in order to facilitate its use. Additions to the AEAD Registry require that a specification be documented in an RFC or another permanent and readily available reference, in sufficient detail that interoperability between independent implementations is possible. Each entry in the registry contains the following elements:
インターネットが割り当てられた番号局（IANA）は、以下に説明する「AEADレジストリ」を定義しました。アルゴリズム設計者は、その使用を容易にするためにアルゴリズムを登録することができます。AEADレジストリに追加するには、独立した実装間の相互運用性が可能であるという十分な詳細で、RFCまたは別の永続的で容易に利用可能な参照で仕様を文書化する必要があります。レジストリ内の各エントリには、次の要素が含まれています。
a short name, such as "AEAD_AES_128_GCM", that starts with the string "AEAD",
「aead_aes_128_gcm」などの短い名前は、文字列「aead」から始まる、
a positive number, and
正の数、そして
a reference to a specification that completely defines an AEAD algorithm and provides test cases that can be used to verify the correctness of an implementation.
AEADアルゴリズムを完全に定義し、実装の正確性を検証するために使用できるテストケースを提供する仕様への参照。
Requests to add an entry to the registry MUST include the name and the reference. The number is assigned by IANA. These number assignments SHOULD use the smallest available positive number. Submitters SHOULD have their requests reviewed by the IRTF Crypto Forum Research Group (CFRG) at cfrg@ietf.org. Interested applicants that are unfamiliar with IANA processes should visit http://www.iana.org.
レジストリにエントリを追加するリクエストには、名前と参照を含める必要があります。番号はIANAによって割り当てられます。これらの数の割り当ては、利用可能な最小の正の数を使用する必要があります。提出者は、cfrg@ietf.orgのIRTF Crypto Forum Research Group（CFRG）によってリクエストをレビューする必要があります。IANAプロセスに不慣れな興味のある応募者は、http：//www.iana.orgにアクセスする必要があります。
The numbers between 32,768 (binary 1000000000000000) and 65,535 (binary 1111111111111111) inclusive, will not be assigned by IANA, and are reserved for private use; no attempt will be made to prevent multiple sites from using the same value in different (and incompatible) ways [RFC2434].
32,768（2進数 1000000000000000）から 65,535（2進数 1111111111111111）までの数字はIANAによって割り当てられることはなく、私的使用のために予約されています。複数のサイトが同じ値を異なる（互換性のない）方法で使用することを防ぐ試みは行われません [RFC2434]。
IANA has added the following entries to the AEAD Registry:
IANAは、AEADレジストリに次のエントリを追加しました。
+------------------+-------------+--------------------+
| Name | Reference | Numeric Identifier |
+------------------+-------------+--------------------+
| AEAD_AES_128_GCM | Section 5.1 | 1 |
| AEAD_AES_256_GCM | Section 5.2 | 2 |
| AEAD_AES_128_CCM | Section 5.3 | 3 |
| AEAD_AES_256_CCM | Section 5.4 | 4 |
+------------------+-------------+--------------------+
An IANA registration of an AEAD does not constitute an endorsement of that algorithm or its security.
AEADのIANA登録は、そのアルゴリズムまたはそのセキュリティの承認を構成するものではありません。
Directly testing a randomized AEAD encryption algorithm using test cases with fixed inputs and outputs is not possible, since the encryption process is non-deterministic. However, it is possible to test a randomized AEAD algorithm using the following technique. The authenticated decryption algorithm is deterministic, and it can be directly tested. The authenticated encryption algorithm can be tested by encrypting a plaintext, decrypting the resulting ciphertext, and comparing the original plaintext to the post-decryption plaintext. Combining both of these tests covers both the encryption and decryption algorithms.
暗号化プロセスは非決定的であるため、固定入力と出力を使用したテストケースを使用してランダム化されたAEAD暗号化アルゴリズムを直接テストすることは不可能です。ただし、次の手法を使用して、ランダム化されたAEADアルゴリズムをテストすることができます。認証付き復号化アルゴリズムは決定論的であり、直接テストできます。認証付き暗号化アルゴリズムは、平文を暗号化し、結果の暗号文を復号化し、元の平文を復号化後の平文と比較することでテストできます。これらのテストの両方を組み合わせることで、暗号化と復号化アルゴリズムの両方をカバーします。
The AEAD algorithms selected reflect those that have been already adopted by standards. It is an open question as to what other AEAD algorithms should be added. Many variations on basic algorithms are possible, each with its own advantages. While it is desirable to admit any algorithms that are found to be useful in practice, it is also desirable to limit the total number of registered algorithms. The current specification requires that a registered algorithm provide a complete specification and a set of validation data; it is hoped that these prerequisites set the admission criteria appropriately.
選択されたAEADアルゴリズムは、すでに標準で採用されているものを反映しています。他にどのようなAEADアルゴリズムを追加すべきかは未解決の問題です。基本的なアルゴリズムの多くのバリエーションが可能であり、それぞれに独自の利点があります。実際に有用であることが判明したアルゴリズムを認めることが望ましいですが、登録されたアルゴリズムの総数を制限することも望ましいです。現在の仕様では、登録されたアルゴリズムが完全な仕様と一連の検証データを提供する必要があります。これらの前提条件が登録基準を適切に設定することが期待されています。
It may be desirable to define an AEAD algorithm that uses the generic composition with the encrypt-then-MAC method [BN00], combining a common encryption algorithm, such as CBC [MODES], with a common message authentication code, such as HMAC-SHA1 [RFC2104] or AES CMAC [CMAC]. An AEAD algorithm of this sort would reflect the best current practice, and might be more easily supported by crypto modules that lack support for other AEAD algorithms.
Encrypt-then-MAC法[BN00]を用いた一般的な構成を使用するAEADアルゴリズムを定義することが望ましい場合があります。これは、CBC [MODES]などの一般的な暗号化アルゴリズムと、HMAC-SHA1 [RFC2104]やAES CMAC [CMAC]などの一般的なメッセージ認証コードを組み合わせたものです。この種のAEADアルゴリズムは、現在の最良のプラクティスを反映し、他のAEADアルゴリズムのサポートがない暗号モジュールによってより簡単にサポートされる可能性があります。
This document describes authenticated encryption algorithms, and provides guidance on their use. While these algorithms make it easier, in some ways, to design a cryptographic application, it should be borne in mind that strong cryptographic security is difficult to achieve. While AEAD algorithms are quite useful, they do nothing to address the issues of key generation [RFC4086] and key management [RFC4107].
このドキュメントは、認証付き暗号化アルゴリズムについて説明し、それらの使用に関するガイダンスを提供します。これらのアルゴリズムは、ある意味で、暗号化アプリケーションの設計を容易にしますが、強力な暗号化セキュリティを達成するのは難しいことを念頭に置いておく必要があります。AEADアルゴリズムは非常に有用ですが、鍵生成[RFC4086]および鍵管理[RFC4107]の問題には対処しません。
AEAD algorithms that rely on distinct nonces may be inappropriate for some applications or for some scenarios. Application designers should understand the requirements outlined in Section 3.1.
個別のナンスに依存するAEADアルゴリズムは、一部のアプリケーションまたは一部のシナリオにとって不適切な場合があります。アプリケーション設計者は、セクション3.1で概説されている要件を理解する必要があります。
A software implementation of the AEAD encryption operation in a Virtual Machine (VM) environment could inadvertently reuse a nonce due to a "rollback" of the VM to an earlier state [GR05]. Applications are encouraged to document potential issues to help the user of the application and the VM avoid unintentional mistakes of this sort. The possibility exists that an attacker can cause a VM rollback; threats and mitigations in that scenario are an area of active research. For perspective, we note that an attacker who can trigger such a rollback may have already succeeded in subverting the security of the system, e.g., by causing an accounting error.
Virtual Machine（VM）環境でのAEAD暗号化操作のソフトウェア実装は、VMの以前の状態への「ロールバック」[GR05]により、誤ってナンスを再利用する可能性があります。アプリケーションは、潜在的な問題を文書化してアプリケーションのユーザーを支援し、VMがこの種の意図しない間違いを回避できるようにすることが推奨されます。攻撃者がVMロールバックを引き起こす可能性がある可能性があります。そのシナリオでの脅威と緩和策は、活発な研究分野です。視点として、そのようなロールバックをトリガーできる攻撃者は、たとえば、課金エラーを引き起こすなどして、システムのセキュリティを侵害することにすでに成功している可能性があることに注意してください。
An IANA registration of an AEAD algorithm MUST NOT be regarded as an endorsement of its security. Furthermore, the perceived security level of an algorithm can degrade over time, due to cryptanalytic advances or to "Moore's Law", that is, the diminishing cost of computational resources over time.
AEADアルゴリズムのIANA登録は、セキュリティの承認と見なされてはなりません。さらに、暗号解読の進歩または「ムーアの法則」、つまり時間の経過に伴う計算リソースのコストの減少により、アルゴリズムの知覚されたセキュリティレベルは、時間の経過とともに低下する可能性があります。
Many reviewers provided valuable comments on earlier drafts of this document. Some fruitful discussions took place on the email list of the Crypto Forum Research Group in 2006.
多くのレビュアーは、この文書の以前のドラフトに関する貴重なコメントを提供しました。2006年のCrypto Forum Research Groupのメーリングリストでは、実り多い議論が行われました。
[CCM] Dworkin, M., "NIST Special Publication 800-38C: The CCM Mode for Authentication and Confidentiality", U.S. National Institute of Standards and Technology, <http://csrc.nist.gov/publications/nistpubs/800-38C/ SP800-38C.pdf>.
[CCM] Dworkin, M., "NIST Special Publication 800-38C: 認証と機密性のためのCCMモード", 米国国立標準技術研究所, <http://csrc.nist.gov/publications/nistpubs/800-38C/ SP800-38C.pdf>。
[GCM] Dworkin, M., "NIST Special Publication 800-38D: Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC.", U.S. National Institute of Standards and Technology, November 2007, <http://csrc.nist.gov/publications/nistpubs/800-38D/ SP-800-38D.pdf>.
[GCM] Dworkin, M., "NIST Special Publication 800-38D: ブロック暗号動作モードの推奨：Galois/Counter Mode (GCM) および GMAC", 米国国立標準技術研究所, 2007年11月, <http://csrc.nist.gov/publications/nistpubs/800-38D/ SP-800-38D.pdf>。
[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月。
[BN00] Bellare, M. and C. Namprempre, "Authenticated encryption: Relations among notions and analysis of the generic composition paradigm", Proceedings of ASIACRYPT 2000, Springer-Verlag, LNCS 1976, pp. 531-545, 2002.
[BN00] Bellare、M。and C. Namprempre、「認証された暗号化：概念間の関係と一般的な構成パラダイムの分析」、Asiacrypt 2000の議事録、Springer-Verlag、LNCS 1976、pp。531-545、2002。
[BOYD] Boyd, C. and A. Mathuria, "Protocols for Authentication and Key Establishment", Springer 2003.
[Boyd] Boyd、C。and A. Mathuria、「認証と主要な設立のためのプロトコル」、Springer 2003。
[CMAC] "NIST Special Publication 800-38B", <http://csrc.nist.gov/ publications/nistpubs/800-38B/SP_800-38B.pdf>.
[cmac] "nist Special Publication 800-38b"、<http://csrc.nist.gov/ publications/nistpubs/800-38b/sp_800-38b.pdf>。
[EEM04] Bellare, M., Namprempre, C., and T. Kohno, "Breaking and provably repairing the SSH authenticated encryption scheme: A case study of the Encode-then-Encrypt-and-MAC paradigm", ACM Transactions on Information and System Security, <http://www-cse.ucsd.edu/users/tkohno/papers/TISSEC04/>.
[EEM04] Bellare、M.、Namprempre、C。、およびT. Kohno、「SSH認証暗号化スキームの破壊と修復：エンコード - エンコリプトとMACパラダイムの事例研究」、情報に関するACMトランザクションのケーススタディ」システムセキュリティ、<http://www-cse.ucsd.edu/users/tkohno/papers/tissec04/>。
[GR05] Garfinkel, T. and M. Rosenblum, "When Virtual is Harder than Real: Security Challenges in Virtual Machine Based Computing Environments", Proceedings of the 10th Workshop on Hot Topics in Operating Systems, <http://www.stanford.edu/~talg/papers/HOTOS05/ virtual-harder-hotos05.pdf>.
[GR05] Garfinkel、T。およびM. Rosenblum、「仮想が実際よりも難しい場合：仮想マシンベースのコンピューティング環境におけるセキュリティの課題」、オペレーティングシステムのホットトピックに関する第10回ワークショップの議事録<http：//www.stanford.edu/〜talg/papers/hotos05/virtual-harder-hotos05.pdf>。
[J02] Jonsson, J., "On the Security of CTR + CBC-MAC", Proceedings of the 9th Annual Workshop on Selected Areas on Cryptography, 2002, <http://csrc.nist.gov/groups/ST/ toolkit/BCM/documents/proposedmodes/ccm/ccm-ad1.pdf>.
[J02] Jonsson、J。、「CTR CBC-MACのセキュリティに関する」、2002年、暗号化の選択されたエリアに関する第9回年次ワークショップの議事録、<http://csrc.nist.gov/groups/st/ Toolkit/bcm/documents/proposedmodes/ccm/ccm-ad1.pdf>。
[MODES] Dworkin, M., "NIST Special Publication 800-38: Recommendation for Block Cipher Modes of Operation", U.S. National Institute of Standards and Technology, <http://csrc.nist.gov/publications/nistpubs/800-38a/ sp800-38a.pdf>.
[Modes] Dworkin、M。、「Nist Special Publication 800-38：Block Cipher Modes of Operationの推奨」、米国国立標準技術研究所、<http://csrc.nist.gov/publications/nistpubs/800-38a/ sp800-38a.pdf>。
[MV04] McGrew, D. and J. Viega, "The Security and Performance of the Galois/Counter Mode (GCM)", Proceedings of INDOCRYPT '04, December 2004, <http://eprint.iacr.org/2004/193>.
[MV04] McGrew、D。およびJ. Viega、「Galois/Counter Mode（GCM）のセキュリティとパフォーマンス」、Indocrypt '04の議事録、2004年12月、<http://eprint.iacr.org/2004/193>。
[R02] Rogaway, P., "Authenticated encryption with Associated-Data", ACM Conference on Computer and Communication Security (CCS'02), pp. 98-107, ACM Press, 2002, <http://www.cs.ucdavis.edu/~rogaway/papers/ad.html>.
[R02] Rogaway、P。、「関連データ付き認証付き暗号」、ACM Conference on Computer and Communication Security（CCS'02）、pp。98-107、ACM Press、2002、<http：//www.cs。ucdavis.edu/~rogaway/papers/ad.html>。
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104] Krawczyk、H.、Bellare、M。、およびR. CaNetti、「HMAC：メッセージ認証のためのキー付きハッシング」、RFC 2104、1997年2月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 2434、1998年10月。
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086] Eastlake、D.、Schiller、J。、およびS. Crocker、「セキュリティのランダム性要件」、BCP 106、RFC 4086、2005年6月。
[RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)", RFC 4106, June 2005.
[RFC4106] Viega、J。およびD. McGrew、「セキュリティペイロードをカプセル化するIPSEC（ESP）でのガロア/カウンターモード（GCM）の使用」、RFC 4106、2005年6月。
[RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key Management", BCP 107, RFC 4107, June 2005.
[RFC4107] Bellovin、S。およびR. Housley、「暗号化キー管理のためのガイドライン」、BCP 107、RFC 4107、2005年6月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303] Kent、S。、「セキュリティペイロード（ESP）」、RFC 4303、2005年12月。
[RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload (ESP)", RFC 4309, December 2005.
[RFC4309] Housley、R。、「Advanced Encryption Standard（AES）CCMモードを使用して、IPSECがセキュリティペイロードをカプセル化する（ESP）を使用して」、RFC 4309、2005年12月。
Author's Address
著者の連絡先
David A. McGrew Cisco Systems, Inc. 510 McCarthy Blvd. Milpitas, CA 95035 US
David A. McGrew Cisco Systems、Inc。510 McCarthy Blvd.Milpitas、CA 95035 US
Phone: (408) 525 8651
EMail: mcgrew@cisco.com
URI: http://www.mindspring.com/~dmcgrew/dam.htm
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（2008）。
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, THE IETF TRUST 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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
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への情報をお問い合わせください。