[要約] RFC 5116は、認証付き暗号化（Authenticated Encryption, AE）のためのインターフェースとアルゴリズムに関する文書です。この文書では、データの機密性と完全性の両方を保証するための暗号化手法について説明しています。利用場面としては、セキュアな通信を必要とするネットワークプロトコルやアプリケーションでの使用が挙げられます。関連するRFCとしては、RFC 5288（TLSでのAES-GCMの使用）やRFC 8439（ChaCha20とPoly1305の使用）などがあり、これらは特定の認証付き暗号化アルゴリズムの使用を詳述しています。
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アルゴリズムを抽象として定義します。このレジストリに、ガロア/カウンターモード[GCM]の高度な暗号化標準（AES）に基づいて、128および256ビットキーを備えた4つのAEADアルゴリズム、およびカウンターおよびCBC MACモード[CCM]のAEに128-および256のAESに入力します。 - ビットキー。
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へのインターフェイスは比較的単純です。これは、入力として単一のキーのみを必要とし、特定のケースで使用されているアルゴリズムを示すために単一の識別子のみを必要とするためです。
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アプローチは、計算量、実装コスト、および/またはストレージ要件を削減するために不可能な最適化を可能にすることにより、Cryptoアルゴリズムの実装者に利益をもたらします。よりシンプルなインターフェイスにより、テストが簡単になります。これは、Cryptoアルゴリズムの実装にとって大きな利点です。暗号化サービスにアクセスするための均一なインターフェイスを提供することにより、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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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.
Nonce N.認証された暗号化操作の明確な呼び出しに提供される各非CEは、すべてのNonCEがゼロレングスでない限り、キーの特定の値に対して明確でなければなりません。個別のNONCEを生成できるアプリケーションは、セクション3.2で定義されているNonCEフォーメーション法を使用し、一意性要件を満たす他の方法を使用する場合があります。他のアプリケーションでは、ゼロ長さのnoncesを使用する必要があります。
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
ciphertext 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）認証された暗号化操作の明確な呼び出しに提供される各nonceは明確である必要があります。特定のキーでゼロの長さの非能力が使用されている場合、そのキーで使用されるすべての非CEがゼロの長さを持っている必要があります。それ以外の場合、ノンセのオクテットの数は12でなければなりません（12）。特定のキーでは、異なる長さの非セースを使用できます。一部のアルゴリズムは、ゼロの長さのノンセスでは使用できませんが、他のアルゴリズムも使用できます。セクション4を参照してください。推奨されるノンセの長さに準拠するアプリケーションは、使用中のアルゴリズムに応じて、異なる長さの非能力を構築する必要がありません。このガイダンスは、アルゴリズム固有のロジックをアプリケーションから除外するのに役立ちます。
The number of octets in the plaintext P MAY be zero.
Plantext Pのオクテットの数はゼロになる可能性があります。
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のオクテットの数はゼロかもしれません。
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.
この仕様では、NONCE、プレーンテキスト、暗号文、または追加の認証されたデータに最大の長さを置くことはありません。ただし、特定の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.
機密性とメッセージ認証の両方がPlantext 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.
NonCEはアルゴリズムに内部的に認証されており、AD入力に含める必要はありません。Nonceは、アプリケーションに便利な場合は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.
Nonceは、暗号文で保存または輸送される場合があります。または、認証された復号化操作の直前に再構築される場合があります。復号化モジュールに、非CEを構築できるように十分な情報を提供するだけで十分です。（たとえば、システムは、特定の形式のシーケンス番号で構成されるNonCEを使用できます。この場合、暗号文の順序から推測できます。）認証された復号化プロセスが誤ったNonCE値を検出するため、セキュリティ障害は発生しません。非CEが誤って再構築され、認証された復号化操作に供給された場合。NonCe再構成方法は、暗号化と復号化プロセスの間の暗号文の損失または再注文の可能性を考慮に入れる必要があります。
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または入力が本物ではないことを示す特別なシンボル障害のいずれかの出力のみがあります。n、p、およびAの一部の値について、入力k、n、p、およびaを使用した暗号化操作によってCが生成される場合、cはキーkに対して、ciphertext c、a nonce n、および関連データAが本物です。操作は、高い確率で、入力n、p、およびAが秘密の鍵を知らない非CEの尊敬の敵によって作成されたときに故障する場合に失敗します（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を配置する必要があります。たとえば、ノンセと暗号文が両方ともパケットに表示される場合、前者の値は後者に先行するはずです。このルールは、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.
アプリケーションがNonCeの生成の一意性要件を満たすことができない場合、ゼロ長のNonCEを使用する必要があります。以下に定義されているランダム化またはステートフルアルゴリズムは、そのようなアプリケーションでの使用に適しています。それ以外の場合、アプリケーションでは、12個のオクテットの長さのNoncesを使用する必要があります。アルゴリズムはその長さをサポートするように推奨されるため、アプリケーションはその長さを使用して相互運用性を支援する必要があります。
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.
セキュリティにとって、非能力は、キーの固定値に対して、認証された暗号化操作の各呼び出しに対して、各nonce値が明確であるという要件を尊重する方法で構築することが不可欠です。このセクションでは、さまざまなシナリオでこの要件のいくつかの結果に注意を喚起します。
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で説明されているように、デバイスのそれぞれに対して異なるフィールドを含むNonCE形式を使用することです。暗号化と復号化された形式の詳細を調整する必要はないことに注意してください。長い間、nonce全体がciphertextで送信または保存されているため、復号化されていることに注意してください。完全な非CEが復号化されていない場合、復号はそれを再構築できるように、非CEがどのように構造化されているかを知る必要があります。アプリケーションは、暗号化エンジンに、非能力を選択する自由を提供する必要があります。たとえば、非CEには、暗号化者によって設定されているが、受信機によって処理されないカウンターとフィールドの両方を含めることができます。この自由により、一連の暗号化デバイスがより容易に調整して、非能力の明確さを確保できます。
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.
秘密の鍵が長期間使用される場合、たとえば複数の再起動で使用される場合、NonCEは不揮発性メモリに保存する必要があります。そのような場合、ノンセのチェックポイントを使用することが不可欠です。つまり、現在のNONCE値は、予期しない障害の場合に暗号化を再開するために必要な状態情報を提供するために保存する必要があります。NonCe値が繰り返し使用されないという高い保証を提供する簡単な方法の1つは、暗号化プロセスが保存プロセスから確認を受信して、後続のNonCe値が既に保存されていることを示すまで待つことです。この方法は大きな遅延を追加する可能性があるため、シーケンスでいくつかの値であるNonCE値を保存することが望ましい場合があります。例として、NonCe 100を保存できます。その後、Nonces 1から99を暗号化に使用できます。NonCe Value 200は、Nonces 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アルゴリズムは、セキュリティの劣化が、NonCE値の不注意な再利用からどのような結果として生じるかを説明する必要があります。
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.
Noncesを構築するための次の方法が推奨されます。NonCEは、図1に示すようにフォーマットされており、最初のオクテットは固定フィールドで構成され、最終オクテットはカウンターフィールドで構成されています。固定キーごとに、これらの各フィールドの長さ、したがって非CEの長さが固定されています。実装は、カウンターフィールドの長さ4オクテットの12-OCTET Noncesをサポートする必要があります。
<----- 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.
連続したノンースのカウンターフィールドは、これらのフィールドがネットワークバイトの順序で符号なし整数と見なされる場合、単調に増加するシーケンスを形成します。カウンターフィールドの長さは、特定の暗号化デバイスに対して生成されるすべての非能力に対して一定のままでなければなりません。カウンターパーツは、最初のNonCEではゼロに等しく、生成される連続した非CEごとに1つずつ増加する必要があります。ただし、特定のカウンター値がスキップされ、便利な場合は使用される値のシーケンスから除外される場合があります。たとえば、アプリケーションは、初期カウンター= 0値をスキップし、初期の非CEのカウンターフィールドを1に設定することを選択できます。長さで。
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.
固定フィールドは、特定の暗号化デバイスに対して生成されたすべての非性能に対して一定のままでなければなりません。異なるデバイスが単一のキーを使用して暗号化を実行している場合、それぞれの異なるデバイスは、Noncesの一意性を確保するために、異なる固定フィールドを使用する必要があります。したがって、最大で2^（8*f）異なる暗号化は、固定フィールドの長さが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.
場合によっては、非CE全体を送信または保存せずに、代わりに復号化の直前にコンテキスト情報からその値を再構築することが望ましいです。例として、暗号文はディスク上に順番に保存され、特定の暗号文の非CEは、非速度を生成するためのルールが復号化されている限り、その場所から推測することができます。ciphertextで保存または送信されるノンセの部分を明示的な部分と呼びます。暗黙の部分と推測されるノンセの部分を呼び出します。NonCeの一部が暗黙的である場合、上記の形式の以下の専門化が推奨されます。固定フィールドは、固定コモンフィールドと固定距離フィールドの2つのサブフィールドに分割されます。この形式を図2に示します。異なるデバイスが単一のキーを使用して暗号化を実行している場合、それぞれの異なるデバイスは個別の固定距離フィールドを使用する必要があります。固定領域は、すべてのノンセスに共通しています。固定距離フィールドとカウンターフィールドは、ノンセの明示的な部分にある必要があります。固定領域は、非CEの暗黙の部分にある可能性があります。これらの規則により、NonCEが明示的なデータから簡単に再構築できるようになります。
+-------------------+--------------------+---------------+
| 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.
部分的に暗黙のノンセ形式の理論的根拠は次のとおりです。このノンセ構造の方法には、最もよく知られているプラクティスが組み込まれています。これは、セキュリティペイロード（ESP）[RFC4106]とCCM ESP [RFC4309]とCCM ESP [RFC4309]の両方で使用されます。このフィールドには、塩値が含まれ、非CEの最低8オクテットがESPパケットに明示的に運ばれます。GCM ESPでは、固定フィールドは塩値を含めることができるように、少なくとも4オクテットの長さでなければなりません。CCM ESPでは、固定フィールドは同じ理由で少なくとも3オクテットの長さでなければなりません。このNonCe生成法は、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に可変長文字列が含まれている場合、この要件は、広告に文字列の長さを含めることで満たすことができます。
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.
同様に、プレーンテキストが複数のデータ要素から構築されている場合、解析プロセスで認可されていないデータを使用せずに、構成要素に明確に解析可能であることが不可欠です。広告に含まれるデータは、プレーンテキストを解析するときに使用できることに注意してください。もちろん、広告は暗号化されていないため、広告に関する情報が広告に含まれている場合、機密性の潜在的な損失があります。
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アルゴリズムを使用するには、アプリケーションは、暗号化アルゴリズムの入力がアプリケーションデータの観点から定義される方法と、CiphertextとNonCeの伝達方法を定義する必要があります。これを行う最も明確な方法は、それを形成するデータに関して各入力を表現し、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
p = retyofpayloaddata ||tfcpadding ||パディング||Padlength ||Nextheader
N = Salt || IV
n =塩||IV
A = SPI || SequenceNumber
a = spi ||シーケンセンサー
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.)
シンボル「||」連結操作を示し、フィールドは、[RFC4303]で定義されているように、[RFC4106]で定義されているように、[RFC4303]で定義されているように、[RFC4303]で定義されているように、[Padding、Padlength、Nextheader、SPI、およびSequenCenumberのremsive scatenation操作を示します。フィールドRESTOFOFPAYLOADDATAには、NexTheaderフィールドで説明されているプレーンテキストデータが含まれており、他のデータは含まれていません。（PayloadDataフィールドには、IVとrepofpayloadDataの両方が含まれていることを思い出してください。図については、[RFC4303]の図2を参照してください。）
The format of the ESP packet can be expressed as
ESPパケットの形式は、
ESP = SPI || SequenceNumber || IV || C
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オクテットの長さの任意のNONCEを受け入れる必要があります。n_maxとn_minの値は等しい場合があります。各アルゴリズムは、12（12）のオクテットの長さの非CEを受け入れる必要があります。以下で説明するランダム化またはステートフルアルゴリズムの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アルゴリズムは、Statefulと呼ばれます。この方法は、アプリケーションがゼロ長さのnoncesを入力した場合でも、適切なセキュリティを提供するためにアルゴリズムによって使用できます。ステートフルアルゴリズムは、ゼロに等しい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アルゴリズムの仕様は、NonCE値の不注意な再利用からセキュリティの劣化がどのような結果として生じるかを説明する必要があります。
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 Ciphertextは、その操作によって出力されるCiphertextへの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 Ciphertextは、対応するプレーンテキストよりもちょうど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は、NonCeの一意性を保証することができる場合にのみ使用する必要があります。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,
NonCeの長さ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 CIPHERTEXTは、その操作によって出力されるCCM暗号化操作への出力として提供される認証タグを追加することにより形成されます。テストケースは[CCM]で提供されます。入力と出力の長さは次のとおりです。
K_LEN is 16 octets,
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.
A security analysis of AES CCM is available in [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つの呼び出しによる同じ非CEの不注意な再利用は、それらの呼び出しで処理されたメッセージのセキュリティを損なうものです。敵がビットワイズの排他的または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（バイナリ1000000000000000）と65,535（バイナリ11111111111111111111111111111111111年生）の数値は、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.
ジェネリック構成を暗号化 - Then-MACメソッド[BN00]で使用するAEADアルゴリズムを定義することが望ましい場合があります。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]のために、誤って非CEを再利用する可能性があります。アプリケーションは、潜在的な問題を文書化してアプリケーションのユーザーを支援し、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：<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。、「Assutived-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>。
[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.
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への情報をお問い合わせください。