[要約] RFC 5926は、TCP Authentication Option (TCP-AO) における暗号化アルゴリズムの使用に関する指針を提供します。TCP-AOは、TCP接続の認証と保護を目的としており、古いTCP MD5 Signature Option (RFC 2385) の代替として設計されています。この文書では、強力なセキュリティを提供するために推奨される暗号化アルゴリズムと、それらの適用方法について説明しています。関連するRFCには、TCP-AOを定義するRFC 5925や、後続の改良や拡張を扱うRFCが含まれます。RFC 5926は、インターネット上でのデータ転送の信頼性とセキュリティを高めるために、ネットワークエンジニアやシステム管理者によって利用されます。
Internet Engineering Task Force (IETF) G. Lebovitz
Request for Comments: 5926 Juniper
Category: Standards Track E. Rescorla
ISSN: 2070-1721 RTFM
June 2010
Cryptographic Algorithms for the TCP Authentication Option (TCP-AO)
TCP認証オプションの暗号化アルゴリズム（TCP-AO）
Abstract
概要
The TCP Authentication Option (TCP-AO) relies on security algorithms to provide authentication between two end-points. There are many such algorithms available, and two TCP-AO systems cannot interoperate unless they are using the same algorithms. This document specifies the algorithms and attributes that can be used in TCP-AO's current manual keying mechanism and provides the interface for future message authentication codes (MACs).
TCP認証オプション（TCP-AO）は、セキュリティアルゴリズムに依存して、2つのエンドポイント間の認証を提供します。利用可能なそのようなアルゴリズムは多数あり、2つのTCP-AOシステムは、同じアルゴリズムを使用しない限り相互運用できません。このドキュメントでは、TCP-AOの現在の手動キーイングメカニズムで使用できるアルゴリズムと属性を指定し、将来のメッセージ認証コード（MAC）のインターフェイスを提供します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5926.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc5926で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................2
2. Requirements ....................................................3
2.1. Requirements Language ......................................3
2.2. Algorithm Requirements .....................................3
2.3. Requirements for Future MAC Algorithms .....................3
3. Algorithms Specified ............................................4
3.1. Key Derivation Functions (KDFs) ............................4
3.1.1. Concrete KDFs .......................................5
3.1.1.1. KDF_HMAC_SHA1 ..............................6
3.1.1.2. KDF_AES_128_CMAC ...........................7
3.1.1.3. Tips for User Interfaces Regarding KDFs ....9
3.2. MAC Algorithms .............................................9
3.2.1. The Use of HMAC-SHA-1-96 ...........................10
3.2.2. The Use of AES-128-CMAC-96 .........................11
4. Security Considerations ........................................11
5. IANA Considerations ............................................13
6. Acknowledgements ...............................................13
7. References .....................................................14
7.1. Normative References ......................................14
7.2. Informative References ....................................14
This document is a companion to [RFC5925]. Like most modern security protocols, TCP-AO allows users to choose which cryptographic algorithm(s) they want to use to meet their security needs.
このドキュメントは、[RFC5925]のコンパニオンです。ほとんどの最新のセキュリティプロトコルと同様に、TCP-AOを使用すると、ユーザーはセキュリティのニーズを満たすために使用する暗号化アルゴリズムを選択できます。
TCP-AO provides cryptographic authentication and message integrity verification between two end-points. In order to accomplish this function, message authentication codes (MACs) are used, which then rely on shared keys. There are various ways to create MACs. The use of hash-based MACs (HMACs) is defined in [RFC2104]. The use of cipher-based MACs (CMACs) is defined in [NIST-SP800-38B].
TCP-AOは、2つのエンドポイント間の暗号化認証とメッセージ整合性検証を提供します。この機能を実行するために、メッセージ認証コード（MAC）が使用され、共有キーに依存します。 MACを作成するにはさまざまな方法があります。ハッシュベースのMAC（HMAC）の使用は[RFC2104]で定義されています。暗号ベースのMAC（CMAC）の使用は、[NIST-SP800-38B]で定義されています。
This RFC defines the general requirements for MACs used in TCP-AO, both for currently specified MACs and for any future specified MACs. It specifies two MAC algorithms required in all TCP-AO implementations. It also specifies two key derivation functions (KDFs) used to create the traffic keys used by the MACs. These KDFs are also required by all TCP-AO implementations.
このRFCは、TCP-AOで使用されるMACの一般的な要件を定義しています。現在指定されているMACと、今後指定されるMACの両方についてです。すべてのTCP-AO実装に必要な2つのMACアルゴリズムを指定します。また、MACが使用するトラフィックキーを作成するために使用される2つのキー導出関数（KDF）も指定します。これらのKDFは、すべてのTCP-AO実装でも必要です。
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]で説明されているように解釈されます。
When used in lowercase, these words convey their typical use in common language, and they are not to be interpreted as described in [RFC2119].
小文字で使用される場合、これらの単語は一般的な言語での典型的な使用を伝え、[RFC2119]で説明されているように解釈されません。
This is the initial specification of required cryptography for TCP-AO, and indicates two MAC algorithms and two KDFs. All four components MUST be implemented in order for the implementation to be fully compliant with this RFC.
これは、TCP-AOに必要な暗号化の初期仕様であり、2つのMACアルゴリズムと2つのKDFを示しています。実装がこのRFCに完全に準拠するためには、4つのコンポーネントすべてを実装する必要があります。
The following table indicates the required MAC algorithms and KDFs for TCP-AO:
次の表は、TCP-AOに必要なMACアルゴリズムとKDFを示しています。
Requirement Authentication Algorithm
要件認証アルゴリズム
------------ ------------------------
MUST HMAC-SHA-1-96 [RFC2104][FIPS-180-3]
必須HMAC-SHA-1-96 [RFC2104] [FIPS-180-3]
MUST AES-128-CMAC-96 [NIST-SP800-38B][FIPS197]
必須AES-128-CMAC-96 [NIST-SP800-38B] [FIPS197]
Requirement Key Derivation Function (KDF)
要件キー導出関数（KDF）
------------- ------------------------
MUST KDF_HMAC_SHA1
KDF_HMAC_SHA1にする必要があります
MUST KDF_AES_128_CMAC
KDF_AES_128_CMACにする必要があります
For an explanation of why two MAC algorithms were mandated, see the Section 4.
2つのMACアルゴリズムが義務付けられた理由の説明については、セクション4を参照してください。
TCP-AO is intended to support cryptographic agility. As a result, this document includes recommendations in various places for future MAC and KDF algorithms when used for TCP-AO. For future MAC algorithms specifically, they SHOULD protect at least 2**48 messages with a collision probability of less than one in 10**9.
TCP-AOは、暗号化の俊敏性をサポートすることを目的としています。その結果、このドキュメントには、TCP-AOで使用する場合の将来のMACおよびKDFアルゴリズムに関するさまざまな場所の推奨事項が含まれています。特に将来のMACアルゴリズムでは、衝突確率が10 ** 9分の1未満で少なくとも2 ** 48のメッセージを保護する必要があります。
TCP-AO requires two classes of cryptographic algorithms used on a particular connection, and refers to this document to define them both:
TCP-AOは、特定の接続で使用される2つのクラスの暗号化アルゴリズムを必要とし、このドキュメントを参照して両方を定義します。
(1) Key Derivation Functions (KDFs), which name a pseudorandom function (PRF) and use a Master_Key and some connection-specific input with that PRF to produce Traffic_Keys, the keys suitable for authenticating and integrity checking individual TCP segments, as described in TCP-AO.
（1）鍵導出関数（KDF）。これは、疑似ランダム関数（PRF）に名前を付け、Master_KeyとそのPRFとの接続固有の入力を使用して、個々のTCPセグメントの認証と整合性チェックに適した鍵であるTraffic_Keysを生成します。 TCP-AO。
(2) Message Authentication Code (MAC) algorithms, which take a key and a message and produce an authentication tag that can be used to verify the integrity and authenticity of those messages.
（2）メッセージ認証コード（MAC）アルゴリズム。キーとメッセージを受け取り、それらのメッセージの整合性と信頼性を検証するために使用できる認証タグを生成します。
In TCP-AO, these algorithms are always used in pairs. Each MAC algorithm MUST specify the KDF to be used with that MAC algorithm. However, a KDF MAY be used with more than one MAC algorithm.
TCP-AOでは、これらのアルゴリズムは常にペアで使用されます。各MACアルゴリズムは、そのMACアルゴリズムで使用されるKDFを指定する必要があります。ただし、KDFは複数のMACアルゴリズムで使用される場合があります。
TCP-AO's Traffic_Keys are derived using KDFs. The KDFs used in TCP-AO's current manual keying have the following interface:
TCP-AOのTraffic_Keysは、KDFを使用して導出されます。 TCP-AOの現在の手動キーイングで使用されているKDFには、次のインターフェースがあります。
Traffic_Key = KDF_alg(Master_Key, Context, Output_Length)
Traffic_Key = KDF_alg（Master_Key、Context、Output_Length）
where:
ただし：
- KDF_alg: the specific pseudorandom function (PRF) that is the basic building block used in constructing the given Traffic_Key.
- KDF_alg：特定のTraffic_Keyの構築に使用される基本的なビルディングブロックである特定の疑似ランダム関数（PRF）。
- Master_Key: In TCP-AO's manual key mode, this is a key shared by both peers, entered via some interface to their respective configurations. The Master_Key is used as the seed for the KDF. We assume that this is a human-readable pre-shared key (PSK); thus, we assume it is of variable length. Master_Keys SHOULD be random, but might not be (e.g., badly chosen by the user). For interoperability, the management interface by which the PSK is configured MUST accept ASCII strings, and SHOULD also allow for the configuration of any arbitrary binary string in hexadecimal form. Other configuration methods MAY be supported.
- Master_Key：TCP-AOの手動鍵モードでは、これは両方のピアによって共有される鍵であり、それぞれの構成へのインターフェースを介して入力されます。 Master_Keyは、KDFのシードとして使用されます。これは人間が読み取れる事前共有キー（PSK）であると想定しています。したがって、可変長であると想定します。 Master_Keysはランダムである必要がありますが、ランダムである必要はありません（たとえば、ユーザーが誤って選択した場合など）。相互運用性のために、PSKが構成される管理インターフェースはASCII文字列を受け入れなければならず（MUST）、16進形式の任意のバイナリ文字列の構成も可能にする必要があります（SHOULD）。他の構成方法がサポートされる場合があります。
- Context: A binary string containing information related to the specific connection for this derived keying material, as defined in [RFC5925], Section 5.2.
- コンテキスト：[RFC5925]のセクション5.2で定義されている、この派生鍵素材の特定の接続に関連する情報を含むバイナリ文字列。
- Output_Length: The length, in bits, of the key that the KDF will produce. This length must be the size required for the MAC algorithm that will use the PRF result as a seed.
- Output_Length：KDFが生成するキーの長さ（ビット単位）。この長さは、PRF結果をシードとして使用するMACアルゴリズムに必要なサイズでなければなりません。
When invoked, a KDF generates a string of length Output_Length bits based on the Master_Key and context value. This result may then be used as a cryptographic key for any algorithm that takes an Output_Length length key. A KDF MAY specify a maximum Output_Length parameter.
KDFが呼び出されると、Master_Keyとコンテキスト値に基づいて、長さOutput_Lengthビットの文字列が生成されます。この結果は、Output_Length長さのキーを使用するアルゴリズムの暗号化キーとして使用できます。 KDFは最大のOutput_Lengthパラメータを指定してもよい（MAY）。
This document defines two KDF algorithms, each paired with a corresponding PRF algorithm as explained below:
このドキュメントでは、2つのKDFアルゴリズムを定義し、それぞれを以下で説明するように、対応するPRFアルゴリズムとペアにします。
* KDF_HMAC_SHA1 based on PRF-HMAC-SHA1 [RFC2104][FIPS-180-3]
* PRF-HMAC-SHA1に基づくKDF_HMAC_SHA1 [RFC2104] [FIPS-180-3]
* KDF_AES_128_CMAC based on AES-CMAC-PRF-128 [NIST-SP800-38B][FIPS197]
* AES-CMAC-PRF-128に基づくKDF_AES_128_CMAC [NIST-SP800-38B] [FIPS197]
Both of these KDFs are based on the iteration-mode KDFs specified in [NIST-SP800-108]. This means that they use an underlying pseudorandom function (PRF) with a fixed-length output, 128 bits in the case of the AES-CMAC, and 160 bits in the case of HMAC-SHA1. The KDF generates an arbitrary number of output bits by operating the PRF in a "counter mode", where each invocation of the PRF uses a different input block differentiated by a block counter.
これらのKDFはどちらも、[NIST-SP800-108]で指定されている反復モードKDFに基づいています。つまり、AES-CMACの場合は128ビット、HMAC-SHA1の場合は160ビットの固定長出力を備えた、基になる疑似ランダム関数（PRF）を使用します。 KDFは、「カウンターモード」でPRFを操作することにより、任意の数の出力ビットを生成します。PRFの呼び出しごとに、ブロックカウンターによって区別される異なる入力ブロックを使用します。
Each input block is constructed as follows:
各入力ブロックは次のように構成されています。
( i || Label || Context || Output_Length )
（i ||ラベル||コンテキスト|| Output_Length）
Where
ただし
- "||": For any X || Y, "||" represents a concatenation operation of the binary strings X and Y.
- "||"：Xの場合|| Y、「||」バイナリ文字列XとYの連結演算を表します。
- i: A counter, a binary string that is an input to each iteration of the PRF in counter mode. The counter "i" is represented in a single octet. The number of iterations will depend on the specific size of the Output_Length desired for a given MAC. "i" always starts = 1.
- i：カウンター、カウンターモードでのPRFの各反復への入力であるバイナリ文字列。カウンター「i」は、単一のオクテットで表されます。反復回数は、特定のMACに必要なOutput_Lengthの特定のサイズによって異なります。 「i」は常に始まります= 1。
- Label: A binary string that clearly identifies the purpose of this KDF's derived keying material. For TCP-AO, we use the ASCII string "TCP-AO", where the last character is the capital letter "O", not to be confused with a zero. While this may seem like overkill in this specification since TCP-AO only describes one call to the KDF, it is included in order to comply with FIPS 140 certifications.
- ラベル：このKDFの派生キーイングマテリアルの目的を明確に識別するバイナリ文字列。 TCP-AOの場合、ASCII文字列「TCP-AO」を使用します。最後の文字は大文字の「O」であり、ゼロと混同しないようにしてください。 TCP-AOはKDFへの1つの呼び出しのみを記述するため、これはこの仕様では過剰に見えるかもしれませんが、FIPS 140認定に準拠するために含まれています。
- Context: The context argument provided to the KDF interface, as described above in Section 3.1 .
- コンテキスト：セクション3.1で説明したように、KDFインターフェースに提供されるコンテキスト引数。
- Output_Length: The length, in bits, of the key that the KDF will produce. The Output_length is represented within two octets. This length must be the size required for the MAC algorithm that will use the PRF result as a seed.
- Output_Length：KDFが生成するキーの長さ（ビット単位）。 Output_lengthは、2オクテット内で表されます。この長さは、PRF結果をシードとして使用するMACアルゴリズムに必要なサイズでなければなりません。
The output of multiple PRF invocations is simply concatenated. For the Traffic_Key, values of multiple PRF invocations are concatenated and truncated as needed to create a Traffic_Key of the desired length. For instance, if one were using KDF_HMAC_SHA1, which uses a 160-bit internal PRF to generate 320 bits of data, one would execute the PRF twice, once with i=1 and once with i=2. The result would be the entire output of the first invocation concatenated with the second invocation. For example,
複数のPRF呼び出しの出力は単純に連結されます。 Traffic_Keyの場合、必要な長さのTraffic_Keyを作成するために、複数のPRF呼び出しの値が必要に応じて連結および切り捨てられます。たとえば、160ビットの内部PRFを使用して320ビットのデータを生成するKDF_HMAC_SHA1を使用している場合、PRFを2回実行します。1回はi = 1、1回はi = 2です。結果は、2番目の呼び出しと連結された最初の呼び出しの出力全体になります。例えば、
Traffic_Key = KDF_alg(Master_Key, 1 || Label || Context || Output_length) || KDF_alg(Master_Key, 2 || Label || Context || Output_length)
Traffic_Key = KDF_alg（Master_Key、1 ||ラベル||コンテキスト|| Output_length）|| KDF_alg（Master_Key、2 ||ラベル||コンテキスト|| Output_length）
If the number of bits required is not an exact multiple of the output size of the PRF, then the output of the final invocation of the PRF is truncated as necessary.
必要なビット数がPRFの出力サイズの正確な倍数でない場合、PRFの最後の呼び出しの出力は必要に応じて切り捨てられます。
For KDF_HMAC_SHA1:
KDF_HMAC_SHA1の場合：
- PRF for KDF_alg: HMAC-SHA1 [RFC2104][FIPS-180-3].
- KDF_algのPRF：HMAC-SHA1 [RFC2104] [FIPS-180-3]。
- Use: HMAC-SHA1(Key, Input).
- 使用：HMAC-SHA1（キー、入力）。
- Key: Master_Key, configured by user, and passed to the KDF.
- キー：Master_Key。ユーザーによって構成され、KDFに渡されます。
- Input: ( i || Label || Context || Output_Length)
- 入力：（i ||ラベル||コンテキスト|| Output_Length）
- Output_Length: 160 bits.
- Output_Length：160ビット。
- Result: Traffic_Key, used in the MAC function by TCP-AO.
- 結果：TCP_AOによってMAC関数で使用されるTraffic_Key。
For KDF_AES_128_CMAC:
KDF_AES_128_CMACの場合：
- PRF for KDF_alg: AES-CMAC-PRF-128 [NIST-SP800-38B][FIPS197].
- KDF_algのPRF：AES-CMAC-PRF-128 [NIST-SP800-38B] [FIPS197]。
- Use: AES-CMAC(Key, Input).
- 使用：AES-CMAC（Key、Input）。
- Key: Master_Key (see usage below)
- キー：Master_Key（下記の使用法を参照）
- Input: ( i || Label || Context || Output_Length)
- 入力：（i ||ラベル||コンテキスト|| Output_Length）
- Output_Length: 128 bits.
- Output_Length：128ビット。
- Result: Traffic_Key, used in the MAC function by TCP-AO
- 結果：TCP_AOによってMAC関数で使用されるTraffic_Key
The Master_Key in TCP-AO's current manual keying mechanism is a shared secret, entered by an administrator. It is passed via an out-of-band mechanism between two devices, and often between two organizations. The shared secret does not have to be 16 octets, and the length may vary. However, AES_128_CMAC requires a key of exactly 16 octets (128 bits) in length. We could mandate that implementations force administrators to input Master_Keys of exactly 128-bit length when using AES_128_CMAC, and with sufficient randomness, but this places undue burden on the implementors and deployers. This specification RECOMMENDS that deployers use a randomly generated 128-bit string as the Master_Key, but acknowledges that deployers may not.
TCP-AOの現在の手動キーイングメカニズムのMaster_Keyは、管理者が入力した共有シークレットです。 2つのデバイス間で、多くの場合2つの組織間で、帯域外メカニズムを介して渡されます。共有秘密は16オクテットである必要はなく、長さが異なる場合があります。ただし、AES_128_CMACには、正確に16オクテット（128ビット）の長さのキーが必要です。 AES_128_CMACを使用する場合、実装は管理者に正確に128ビット長のMaster_Keysを入力し、十分なランダム性を要求することを義務付けることができますが、これにより実装者とデプロイヤに過度の負担がかかります。この仕様は、デプロイヤーがランダムに生成された128ビットの文字列をMaster_Keyとして使用することを推奨しますが、デプロイヤーは使用しない場合があることを認めています。
To handle variable length Master_Keys, we use the same mechanism as described in [RFC4615], Section 3. First, we use AES_128_CMAC with a fixed key of all zeros as a "randomness extractor", while using the shared secret Master_Key, MK, as the message input, to produce a 128- bit key Derived_Master_Key (K). Second, we use the result as a key, and run AES-128_CMAC again, this time using the result K as the Key, and the true input block as the Input to yield the Traffic_Key (TK) used in the MAC over the message. The description follows:
可変長のMaster_Keysを処理するために、[RFC4615]のセクション3で説明されているのと同じメカニズムを使用します。最初に、共有秘密のMaster_Key、MK、メッセージ入力。128ビットの鍵Derived_Master_Key（K）を生成します。次に、結果をキーとして使用し、AES-128_CMACを再度実行します。今回は結果Kをキーとして使用し、真の入力ブロックを入力として使用して、メッセージでMACで使用されるTraffic_Key（TK）を生成します。説明は次のとおりです。
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ KDF-AES-128-CMAC +
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ +
+ Input : MK (Master_Key, the variable-length shared secret) +
+ : I (Input, i.e., the input data of the PRF) +
+ : MKlen (length of MK in octets) +
+ : len (length of M in octets) +
+ Output : TK (Traffic_Key, 128-bit Pseudo-Random Variable) +
+ +
+-------------------------------------------------------------------+
+ Variable: K (128-bit key for AES-CMAC) +
+ +
+ Step 1. If MKlen is equal to 16 +
+ Step 1a. then +
+ K := MK; +
+ Step 1b. else +
+ K := AES-CMAC(0^128, MK, MKlen); +
+ Step 2. TK := AES-CMAC(K, I, len); +
+ return TK; +
+ +
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Figure 1
図1
In step 1, the 128-bit key, K, for AES-CMAC is derived as follows:
手順1では、AES-CMACの128ビットキーKが次のように導出されます。
o If the Master_Key, MK, provided by the administrator is exactly 128 bits, then we use it as is.
o 管理者から提供されたMaster_Key、MKがちょうど128ビットである場合、それをそのまま使用します。
o If it is longer or shorter than 128 bits, then we derive the key K by applying the AES-CMAC algorithm using the 128-bit all-zero string as the key and MK as the input message. This step is described in 1b.
o 128ビットより長いか短い場合は、128ビットのすべてゼロの文字列をキーとして使用し、MKを入力メッセージとして使用してAES-CMACアルゴリズムを適用することにより、キーKを導出します。このステップについては、1bで説明します。
In step 2, we apply the AES-CMAC algorithm again, this time using K as the key and I as the input message.
ステップ2では、AES-CMACアルゴリズムを再度適用します。今回は、キーとしてKを使用し、入力メッセージとしてIを使用します。
The output of this algorithm returns TK, the Traffic_Key, which is 128 bits and is suitable for use in the MAC function on each TCP segment of the connection.
このアルゴリズムの出力は、128ビットのTK、Traffic_Keyを返し、接続の各TCPセグメントのMAC関数での使用に適しています。
This section provides suggested representations for the KDFs in implementation user interfaces (UIs). Following these guidelines across common implementations will make interoperability easier and simpler for deployers.
このセクションでは、実装ユーザーインターフェイス（UI）でのKDFの推奨表現を示します。一般的な実装全体でこれらのガイドラインに従うことにより、デプロイヤーにとっての相互運用性がより簡単かつ単純になります。
UIs SHOULD refer to the choice of KDF_HMAC_SHA1 as simply "SHA1".
UIは、KDF_HMAC_SHA1の選択を単に「SHA1」と呼ぶ必要があります（SHOULD）。
UIs SHOULD refer to the choice of KDF_AES_128_CMAC as simply "AES128".
UIは、KDF_AES_128_CMACの選択を単に「AES128」と呼ぶ必要があります（SHOULD）。
The initial IANA registry values reflect these two entries.
IANAレジストリの初期値は、これら2つのエントリを反映しています。
UIs SHOULD use KDF_HMAC_SHA1 as the default selection in TCP-AO settings. KDF_HMAC_SHA1 is preferred at this time because it has wide support, being present in most implementations in the marketplace.
UIは、TCP-AO設定のデフォルトの選択としてKDF_HMAC_SHA1を使用する必要があります（SHOULD）。 KDF_HMAC_SHA1は幅広いサポートがあり、市場のほとんどの実装に存在しているため、現時点では推奨されています。
Each MAC_alg defined for TCP-AO has three fixed elements as part of its definition:
TCP-AOに対して定義された各MAC_algには、その定義の一部として3つの固定要素があります。
- KDF_Alg: Name of the TCP-AO KDF algorithm used to generate the Traffic_Key.
- KDF_Alg：Traffic_Keyの生成に使用されるTCP-AO KDFアルゴリズムの名前。
- Key_Length: Length, in bits, required for the Traffic_Key used in this MAC.
- Key_Length：このMACで使用されるTraffic_Keyに必要なビット単位の長さ。
- MAC_Length: The final length of the bits used in the TCP-AO MAC field. This value may be a truncation of the MAC function's original output length.
- MAC_Length：TCP-AO MACフィールドで使用されるビットの最終的な長さ。この値は、MAC関数の元の出力長の切り捨てである可能性があります。
MACs computed for TCP-AO have the following interface:
TCP-AO用に計算されたMACには、次のインターフェースがあります。
MAC = MAC_alg(Traffic_Key, Message)
MAC = MAC_alg（Traffic_Key、Message）
where:
ただし：
- MAC_alg: MAC Algorithm used.
- MAC_alg：使用されるMACアルゴリズム。
- Traffic_Key: Variable; the result of KDF.
- Traffic_Key：変数; KDFの結果。
- Message The message to be authenticated, as specified in [RFC5925], Section 5.1.
- メッセージ[RFC5925]のセクション5.1で指定されている、認証されるメッセージ。
This document specifies two MAC algorithm options for generating the MAC as used by TCP-AO:
このドキュメントでは、TCP-AOで使用されるMACを生成するための2つのMACアルゴリズムオプションを指定します。
* HMAC-SHA-1-96 based on [RFC2104] and [FIPS-180-3].
* [RFC2104]および[FIPS-180-3]に基づくHMAC-SHA-1-96。
* AES-128-CMAC-96 based on [NIST-SP800-38B][FIPS197]
* [NIST-SP800-38B] [FIPS197]に基づくAES-128-CMAC-96
Both provide a high level of security and efficiency. The AES-128- CMAC-96 is potentially more efficient, particularly in hardware, but HMAC-SHA-1-96 is more widely used in Internet protocols and in most cases could be supported with little or no additional code in today's deployed software and devices.
どちらも高レベルのセキュリティと効率を提供します。 AES-128- CMAC-96は、特にハードウェアにおいて潜在的に効率的ですが、HMAC-SHA-1-96はインターネットプロトコルでより広く使用されており、ほとんどの場合、今日の展開されたソフトウェアでほとんどまたはまったく追加コードなしでサポートできます。デバイス。
An important aspect to note about these algorithms' definitions for use in TCP-AO is the fact that the MAC outputs are truncated to 96 bits. AES-128-CMAC-96 produces a 128-bit MAC, and HMAC SHA-1 produces a 160-bit result. The MAC output is then truncated to 96 bits to provide a reasonable trade-off between security and message size, for fitting into the TCP-AO option field.
TCP-AOで使用するこれらのアルゴリズムの定義について注意する重要な側面は、MAC出力が96ビットに切り捨てられるという事実です。 AES-128-CMAC-96は128ビットMACを生成し、HMAC SHA-1は160ビット結果を生成します。次に、MAC出力は96ビットに切り捨てられ、TCP-AOオプションフィールドに適合させるために、セキュリティとメッセージサイズ間の適切なトレードオフが提供されます。
By definition, HMAC [RFC2104] requires a cryptographic hash function. SHA1 will be that hash function used for authenticating and providing integrity validation on TCP segments with HMAC.
定義により、HMAC [RFC2104]は暗号化ハッシュ関数を必要とします。 SHA1は、HMACを使用してTCPセグメントの認証と整合性検証を行うために使用されるハッシュ関数です。
The three fixed elements for HMAC-SHA-1-96 are:
HMAC-SHA-1-96の3つの固定要素は次のとおりです。
- KDF_Alg: KDF_HMAC_SHA1.
- KDF_Alg：KDF_HMAC_SHA1。
- Key_Length: 160 bits.
- Key_Length：160ビット。
- MAC_Length: 96 bits.
- MAC_Length：96ビット。
For:
ために：
MAC = MAC_alg (Traffic_Key, Message)
MAC = MAC_alg（Traffic_Key、メッセージ）
HMAC-SHA-1-96 for TCP-AO has the following values:
TCP-AOのHMAC-SHA-1-96には次の値があります。
- MAC_alg: HMAC-SHA1.
- MAC_alg：HMAC-SHA1。
- Traffic_Key: Variable; the result of the KDF.
- Traffic_Key：変数; KDFの結果。
- Message: The message to be authenticated, as specified in [RFC5925], Section 5.1.
- メッセージ：[RFC5925]のセクション5.1で指定されている、認証されるメッセージ。
In the context of TCP-AO, when we say "AES-128-CMAC-96", we actually define a usage of AES-128 as a cipher-based MAC according to [NIST-SP800-38B].
TCP-AOのコンテキストで「AES-128-CMAC-96」と言う場合、実際には[NIST-SP800-38B]に従ってAES-128の使用法を暗号ベースのMACとして定義します。
The three fixed elements for AES-128-CMAC-96 are:
AES-128-CMAC-96の3つの固定要素は次のとおりです。
- KDF_Alg: KDF_AES_128_CMAC.
- KDF_Alg：KDF_AES_128_CMAC。
- Key_Length: 128 bits.
- Key_Length：128ビット。
- MAC_Length: 96 bits.
- MAC_Length：96ビット。
For:
ために：
MAC = MAC_alg (Traffic_Key, Message)
MAC = MAC_alg（Traffic_Key、メッセージ）
AES-128-CMAC-96 for TCP-AO has the following values:
TCP-AOのAES-128-CMAC-96には次の値があります。
- MAC_alg: AES-128-CMAC-96. [NIST-SP800-38B]
- MAC_alg：AES-128-CMAC-96。 [NIST-SP800-38B]
- Traffic_Key: Variable; the result of the KDF.
- Traffic_Key：変数; KDFの結果。
- Message: The message to be authenticated, as specified in [RFC5925], Section 5.1.
- メッセージ：[RFC5925]のセクション5.1で指定されている、認証されるメッセージ。
This document inherits all of the security considerations of the TCP-AO [RFC5925], the AES-CMAC [RFC4493], and the HMAC-SHA-1 [RFC2104] documents.
このドキュメントは、TCP-AO [RFC5925]、AES-CMAC [RFC4493]、およびHMAC-SHA-1 [RFC2104]ドキュメントのセキュリティに関する考慮事項をすべて継承しています。
The security of cryptography-based systems depends on both the strength of the cryptographic algorithms chosen and the strength of the keys used with those algorithms. The security also depends on the engineering of the protocol used by the system to ensure that there are no non-cryptographic ways to bypass the security of the overall system.
暗号化ベースのシステムのセキュリティは、選択した暗号化アルゴリズムの強度とそれらのアルゴリズムで使用される鍵の強度の両方に依存します。セキュリティは、システム全体のセキュリティを回避する非暗号化の方法がないことを保証するために、システムが使用するプロトコルの設計にも依存します。
Care should also be taken to ensure that the selected key is unpredictable, avoiding any keys known to be weak for the algorithm in use. [RFC4086] contains helpful information on both key generation techniques and cryptographic randomness.
また、選択したキーが予測不能になるように注意を払い、使用中のアルゴリズムに対して脆弱であることがわかっているキーを回避する必要があります。 [RFC4086]には、鍵生成技術と暗号のランダム性の両方に関する役立つ情報が含まれています。
Note that in the composition of KDF_AES_128_CMAC, the PRF needs a 128-bit / 16-byte key as the seed. However, for convenience to the administrators/deployers, we did not want to force them to enter a 16-byte Master_Key. So we specified the sub-key routine that could handle a variable length Master_Key, one that might be less than 16 bytes. This does NOT mean that it is safe for administrators to use weak keys. Administrators are encouraged to follow [RFC4086] as listed above. We simply attempted to "put a fence around foolishness", as much as possible.
KDF_AES_128_CMACの構成では、PRFがシードとして128ビット/ 16バイトの鍵を必要とすることに注意してください。ただし、管理者/デプロイメント担当者の便宜のために、16バイトのMaster_Keyを入力するように強制したくありませんでした。そこで、可変長のMaster_Keyを処理できるサブキールーチンを指定しました。これは16バイト未満の可能性があります。これは、管理者が脆弱なキーを使用しても安全であることを意味するものではありません。管理者は、上記の[RFC4086]に従うことをお勧めします。私たちはできるだけ「愚かさの周りに柵を張る」ことを試みただけです。
This document concerns itself with the selection of cryptographic algorithms for the use of TCP-AO. The algorithms identified in this document as "MUST implement" are not known to be broken at the current time, and cryptographic research so far leads us to believe that they will likely remain secure into the foreseeable future. Some of the algorithms may be found in the future to have properties significantly weaker than those that were believed at the time this document was produced. Expect that new revisions of this document will be issued from time to time. Be sure to search for more recent versions of this document before implementing.
このドキュメントは、TCP-AOを使用するための暗号アルゴリズムの選択に関係しています。このドキュメントで「実装する必要がある」と識別されたアルゴリズムは、現時点で壊れていることは知られていないため、これまでのところ、暗号研究により、近い将来、それらのアルゴリズムは安全であり続けると思われます。アルゴリズムのいくつかは、このドキュメントが作成されたときに信じられていたものよりも著しく弱い特性を持つ将来的に見つかるかもしれません。このドキュメントの新しい改訂版が随時発行されることを期待してください。実装する前に、このドキュメントの最新バージョンを検索してください。
NOTE EXPLAINING WHY TWO MAC ALGORITHMS WERE MANDATED:
2つのMACアルゴリズムが義務付けられた理由の説明：
Two MAC algorithms and two corresponding KDFs are mandated as a result of discussion in the TCPM WG, and in consultation with the Security Area Directors. SHA-1 was selected because it is widely deployed and currently has sufficient strength and reasonable computational cost, so it is a "MUST" for TCP-AO today. The security strength of SHA-1 HMACs should be sufficient for the foreseeable future, especially given that the tags are truncated to 96 bits.
TCPM WGでの議論の結果、およびセキュリティエリアディレクターとの協議の結果、2つのMACアルゴリズムと2つの対応するKDFが義務付けられています。 SHA-1は、広く展開されており、現在十分な強度と合理的な計算コストを備えているため、今日のTCP-AOの「必須」です。 SHA-1 HMACのセキュリティ強度は、特にタグが96ビットに切り捨てられている場合、予測可能な将来には十分なはずです。
Recently exposed vulnerabilities in other MACs (e.g., MD5 or HMAC MD5) aren't practical on HMAC-SHA-1, but these types of analyses are mounting and could potentially pose a concern for HMAC forgery if they were significantly improved, over time. The security issues driving the migration from SHA-1 to SHA-256 for digital signatures [HMAC-ATTACK] do not immediately render SHA-1 weak for this application of SHA-1 in HMAC mode.
他のMAC（MD5やHMAC MD5など）で最近公開された脆弱性はHMAC-SHA-1では実用的ではありませんが、これらのタイプの分析は増加しており、時間の経過とともに大幅に改善された場合、HMAC偽造が懸念される可能性があります。デジタル署名のSHA-1からSHA-256への移行を促進するセキュリティの問題[HMAC-ATTACK]は、HMACモードでのSHA-1のこのアプリケーションに対してSHA-1をすぐに弱めません。
AES-128 CMAC is considered to be a stronger algorithm than SHA-1, but may not yet have very wide implementation. AES-128 CMAC is also a "MUST" to implement, in order to drive vendors toward its use, and to allow for another MAC option, if SHA-1 were to be compromised.
AES-128 CMACはSHA-1よりも強力なアルゴリズムであると考えられていますが、まだそれほど広範囲に実装されていない可能性があります。 AES-128 CMACは、ベンダーをその使用に向かわせ、SHA-1が危険にさらされた場合に別のMACオプションを可能にするために実装する必要もあります。
IANA has created the following registry (http://www.iana.org).
IANAは次のレジストリ（http://www.iana.org）を作成しました。
Registry Name: Cryptographic Algorithms for TCP-AO Registration Procedure: RFC Publication after Expert Review
レジストリ名：TCP-AO登録手順の暗号化アルゴリズム：エキスパートレビュー後のRFC発行
Initial contents of this registry are:
このレジストリの初期内容は次のとおりです。
Algorithm | Reference
----------------|-----------
SHA1 | [RFC5926]
AES128 | [RFC5926]
Eric "EKR" Rescorla, who provided a ton of input and feedback, including a somewhat heavy re-write of Section 3.1.x, earning him an author slot on the document.
Eric "EKR" Rescorlaは、セクション3.1.xのやや重い書き直しを含め、大量の入力とフィードバックを提供し、ドキュメントの著者スロットを獲得しました。
Paul Hoffman, from whose [RFC4308] I sometimes copied, to quickly create a first version here.
[RFC4308]のコピー元のPaul Hoffmanが、ここで最初のバージョンをすばやく作成しました。
Tim Polk, whose email summarizing SAAG's guidance to TCPM on the two hash algorithms for TCP-AO is largely cut-and-pasted into various sections of this document.
TCP-AOの2つのハッシュアルゴリズムに関するSAAGのTCPMへのガイダンスを要約した電子メールのTim Polkは、主にこのドキュメントのさまざまなセクションにカットアンドペーストされています。
Jeff Schiller, Donald Eastlake, and the IPsec WG, whose [RFC4307] & [RFC4835] text was consulted and sometimes used in the Requirements Section 2 of this document.
Jeff Schiller、Donald Eastlake、およびIPsec WG。[RFC4307]および[RFC4835]のテキストが参照され、このドキュメントの要件セクション2で使用されることもあります。
(In other words, I was truly only an editor of others' text in creating this document.)
（つまり、私はこのドキュメントを作成するにあたって、本当に他の人のテキストの編集者でした。）
Eric "EKR" Rescorla and Brian Weis, who brought to clarity the issues with the inputs to PRFs for the KDFs. EKR was also of great assistance in how to structure the text, as well as helping to guide good cryptographic decisions.
KDFのPRFへの入力に関する問題を明確にしたエリック "EKR" RescorlaおよびBrian Weis。 EKRはまた、テキストを構造化する方法、および適切な暗号化の決定を導くのに役立つ非常に役立ちました。
The TCPM working group, who put up with all us crypto and routing folks DoS'ing their WG for 2 years, and who provided reviews of this document.
TCPMワーキンググループは、私たち全員がWGを2年間DoSする暗号化とルーティングの人々に耐え、このドキュメントのレビューを提供しました。
[FIPS-180-3] FIPS Publication 180-3, "Secured Hash Standard", FIPS 180-3, October 2008.
[FIPS-180-3] FIPS Publication 180-3、「Secured Hash Standard」、FIPS 180-3、2008年10月。
[FIPS197] FIPS Publications 197, "Advanced Encryption Standard (AES)", FIPS 197, November 2001.
[FIPS197] FIPS Publications 197、「Advanced Encryption Standard（AES）」、FIPS 197、2001年11月。
[NIST-SP800-108] National Institute of Standards and Technology, "Recommendation for Key Derivation Using Pseudorandom Functions, NIST SP800-108", SP 800- 108, October 2009.
[NIST-SP800-108]国立標準技術研究所、「疑似ランダム関数を使用した鍵導出の推奨、NIST SP800-108」、SP 800-108、2009年10月。
[NIST-SP800-38B] National Institute of Standards and Technology, "Recommendation for Block Cipher Modes of Operation: The CMAC Mode for Authentication", SP 800-38B, May 2005.
[NIST-SP800-38B]米国国立標準技術研究所、「ブロック暗号化動作モードの推奨：認証用のCMACモード」、SP 800-38B、2005年5月。
[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：Keyed-Hashing for Message Authentication」、RFC 2104、1997年2月。
[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月。
[RFC4493] Song, JH., Poovendran, R., Lee, J., and T. Iwata, "The AES-CMAC Algorithm", RFC 4493, June 2006.
[RFC4493] Song、JH。、Poovendran、R.、Lee、J。、およびT. Iwata、「AES-CMACアルゴリズム」、RFC 4493、2006年6月。
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, June 2010.
[RFC5925] Touch、J.、Mankin、A。、およびR. Bonica、「The TCP Authentication Option」、RFC 5925、2010年6月。
[HMAC-ATTACK] "On the Security of HMAC and NMAC Based on HAVAL, MD4, MD5, SHA-0 and SHA-1", <http:// www.springerlink.com/content/00w4v62651001303> , 2006, <http://eprint.iacr.org/2006/187>.
[HMAC-ATTACK]「HAVAL、MD4、MD5、SHA-0およびSHA-1に基づくHMACおよびNMACのセキュリティについて」、<http：// www.springerlink.com/content/00w4v62651001303>、2006、<http ：//eprint.iacr.org/2006/187>。
[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、「Randomness Requirements for Security」、BCP 106、RFC 4086、2005年6月。
[RFC4307] Schiller, J., "Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2)", RFC 4307, December 2005.
[RFC4307] Schiller、J。、「インターネットキーエクスチェンジバージョン2（IKEv2）で使用する暗号化アルゴリズム」、RFC 4307、2005年12月。
[RFC4308] Hoffman, P., "Cryptographic Suites for IPsec", RFC 4308, December 2005.
[RFC4308]ホフマン、P。、「IPsecの暗号スイート」、RFC 4308、2005年12月。
[RFC4615] Song, J., Poovendran, R., Lee, J., and T. Iwata, "The Advanced Encryption Standard-Cipher-based Message Authentication Code-Pseudo-Random Function-128 (AES-CMAC-PRF-128) Algorithm for the Internet Key Exchange Protocol (IKE)", RFC 4615, August 2006.
[RFC4615] Song、J.、Poovendran、R.、Lee、J。、およびT. Iwata、「Advanced Encryption Standard-Cipher-based Message Authentication Code-Pseudo-Random Function-128（AES-CMAC-PRF-128 ）Internet Key Exchange Protocol（IKE）のアルゴリズム」、RFC 4615、2006年8月。
[RFC4835] Manral, V., "Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 4835, April 2007.
[RFC4835] Manral、V。、「カプセル化セキュリティペイロード（ESP）および認証ヘッダー（AH）の暗号化アルゴリズム実装要件」、RFC 4835、2007年4月。
Authors' Addresses
著者のアドレス
Gregory Lebovitz Juniper Networks, Inc. 1194 North Mathilda Ave. Sunnyvale, CA 94089-1206 US
Gregory Lebovitz Juniper Networks、Inc. 1194 North Mathilda Ave. Sunnyvale、CA 94089-1206 US
Phone: EMail: gregory.ietf@gmail.com
電話：メール：gregory.ietf@gmail.com
Eric Rescorla RTFM, Inc. 2064 Edgewood Drive Palo Alto, CA 94303 US
Eric Rescorla RTFM、Inc. 2064 Edgewood Drive Palo Alto、CA 94303 US
Phone: 650-678-2350 EMail: ekr@rtfm.com
電話：650-678-2350メール：ekr@rtfm.com