Internet Engineering Task Force (IETF) G. Lebovitz
Request for Comments: 5926 Juniper
Category: Standards Track E. Rescorla
ISSN: 2070-1721 RTFM
June 2010
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）依赖于安全算法在两个端点之间提供身份验证。有许多这样的算法可用，两个TCP-AO系统不能互操作，除非它们使用相同的算法。本文件规定了可用于TCP-AO当前手动键控机制的算法和属性，并为未来的消息认证码（MAC）提供了接口。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
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）的产品。它代表了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.
版权所有（c）2010 IETF信托基金和确定为文件作者的人员。版权所有。
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)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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
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在两个端点之间提供加密身份验证和消息完整性验证。为了完成此功能，使用消息身份验证码（MAC），然后使用共享密钥。创建Mac有多种方法。[RFC2104]中定义了基于哈希的MAC（HMAC）的使用。[NIST-SP800-38B]中定义了基于密码的MAC（CMAC）的使用。
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实现中所需的两种MAC算法。它还指定了两个密钥派生函数（KDF），用于创建MAC使用的通信密钥。所有TCP-AO实现都需要这些KDF。
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[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所需加密的初始规范，表示两种MAC算法和两种KDF。为了使实施完全符合本RFC，必须实施所有四个组件。
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.
有关为什么强制使用两种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算法，它们应该保护至少2**48条消息，冲突概率小于十分之一**9。
TCP-AO requires two classes of cryptographic algorithms used on a particular connection, and refers to this document to define them both:
TCP-AO要求在特定连接上使用两类加密算法，并参考本文档来定义这两类算法：
(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），并使用主密钥和该PRF的某些连接特定输入来生成流量密钥，这些密钥适用于验证和完整性检查各个TCP段，如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的流量密钥是使用KDFs导出的。TCP-AO当前手动键控中使用的KDF具有以下接口：
Traffic_Key = KDF_alg(Master_Key, Context, Output_Length)
流量密钥=KDF alg（主密钥、上下文、输出长度）
where:
哪里：
- KDF_alg: the specific pseudorandom function (PRF) that is the basic building block used in constructing the given Traffic_Key.
- KDF_alg：特定的伪随机函数（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.
- 主密钥：在TCP-AO的手动密钥模式下，这是一个由两个对等方共享的密钥，通过一些接口输入到各自的配置中。主密钥用作KDF的种子。我们假设这是一个人类可读的预共享密钥（PSK）；因此，我们假设它的长度是可变的。主密钥应该是随机的，但可能不是（例如，用户选择错误）。为了实现互操作性，配置PSK的管理接口必须接受ASCII字符串，并且还应允许以十六进制形式配置任意二进制字符串。可能支持其他配置方法。
- 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会根据主密钥和上下文值生成一个长度输出长度位字符串。然后，该结果可以用作任何采用输出长度密钥的算法的加密密钥。KDF可以指定最大输出长度参数。
This document defines two KDF algorithms, each paired with a corresponding PRF algorithm as explained below:
本文档定义了两种KDF算法，每种算法都与相应的PRF算法配对，如下所述：
* KDF_HMAC_SHA1 based on PRF-HMAC-SHA1 [RFC2104][FIPS-180-3]
* KDF_HMAC_SHA1基于PRF-HMAC-SHA1[RFC2104][FIPS-180-3]
* KDF_AES_128_CMAC based on AES-CMAC-PRF-128 [NIST-SP800-38B][FIPS197]
* KDF_AES_128_CMAC基于AES-CMAC-PRF-128[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。这意味着它们使用具有固定长度输出的基础伪随机函数（PRF），AES-CMAC为128位，HMAC-SHA1为160位。KDF通过在“计数器模式”下操作PRF生成任意数量的输出位，其中PRF的每次调用使用由块计数器区分的不同输入块。
Each input block is constructed as follows:
每个输入块的构造如下所示：
( i || Label || Context || Output_Length )
（i | |标签| |上下文| |输出| U长度）
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所需的输出长度的具体大小。“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的一次调用，因此在本规范中这似乎有些过分，但为了符合FIPS 140认证，将其包括在内。
- Context: The context argument provided to the KDF interface, as described above in Section 3.1 .
- 上下文：提供给KDF接口的上下文参数，如上文第3.1节所述。
- 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将生成的密钥的长度（以位为单位）。输出长度用两个八位字节表示。该长度必须是将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_密钥，多个PRF调用的值会根据需要进行连接和截断，以创建所需长度的Traffic_密钥。例如，如果使用KDF_HMAC_SHA1，即使用160位内部PRF生成320位数据，则将执行PRF两次，一次执行i=1，一次执行i=2。结果将是第一次调用的整个输出与第二次调用连接在一起。例如
Traffic_Key = KDF_alg(Master_Key, 1 || Label || Context || Output_length) || KDF_alg(Master_Key, 2 || Label || Context || Output_length)
流量键=KDF alg（主键，1 |标签|上下文|输出长度）| KDF alg（主键，2 |标签|上下文|输出长度）
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.
- 密钥：主密钥，由用户配置，并传递给KDF。
- Input: ( i || Label || Context || Output_Length)
- 输入：（i | |标签| |上下文| |输出| U长度）
- Output_Length: 160 bits.
- 输出长度：160位。
- Result: Traffic_Key, used in the MAC function by TCP-AO.
- 结果：TCP-AO在MAC功能中使用的流量密钥。
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: Master_Key (see usage below)
- 钥匙：主钥匙（参见下面的用法）
- Input: ( i || Label || Context || Output_Length)
- 输入：（i | |标签| |上下文| |输出| U长度）
- Output_Length: 128 bits.
- 输出长度：128位。
- Result: Traffic_Key, used in the MAC function by TCP-AO
- 结果：TCP-AO在MAC功能中使用的流量密钥
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当前手动密钥机制中的主密钥是由管理员输入的共享密钥。它通过带外机制在两个设备之间传递，通常在两个组织之间传递。共享秘密不必是16个八位字节，长度可能会有所不同。然而，AES_128_CMAC需要长度正好为16个八位字节（128位）的密钥。我们可以要求实现强制管理员在使用AES_128_CMAC时输入长度正好为128位的主密钥，并且具有足够的随机性，但这给实现者和部署者带来了不必要的负担。本规范建议部署人员使用随机生成的128位字符串作为主密钥，但承认部署人员可能不会。
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:
为了处理可变长度的主密钥，我们使用与[RFC4615]第3节所述相同的机制。首先，我们使用具有全零固定密钥的AES_128_CMAC作为“随机性提取器”，同时使用共享密钥主密钥MK作为消息输入，以生成128位密钥派生的主密钥（K）。其次，我们使用结果作为密钥，再次运行AES-128_CMAC，这次使用结果K作为密钥，使用真实输入块作为输入，以生成消息上MAC中使用的通信量_密钥（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; +
+ +
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ 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 如果管理员提供的主密钥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位，则我们通过应用AES-CMAC算法，使用128位全零字符串作为密钥，MK作为输入消息，推导出密钥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.
该算法的输出返回TK，即通信量密钥，为128位，适合在连接的每个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".
UIs应将KDF_HMAC_SHA1的选择简称为“SHA1”。
UIs SHOULD refer to the choice of KDF_AES_128_CMAC as simply "AES128".
UIs应将KDF_AES_128_CMAC的选择简称为“AES128”。
The initial IANA registry values reflect these two entries.
初始IANA注册表值反映了这两个条目。
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应使用KDF_HMAC_SHA1作为TCP-AO设置中的默认选择。KDF_HMAC_SHA1目前是首选，因为它具有广泛的支持，在市场上的大多数实现中都有。
Each MAC_alg defined for TCP-AO has three fixed elements as part of its definition:
为TCP-AO定义的每个MAC_alg有三个固定元素作为其定义的一部分：
- KDF_Alg: Name of the TCP-AO KDF algorithm used to generate the Traffic_Key.
- KDF_Alg：用于生成流量_密钥的TCP-AO KDF算法的名称。
- Key_Length: Length, in bits, required for the Traffic_Key used in this MAC.
- 密钥长度：此MAC中使用的流量密钥所需的长度，以位为单位。
- 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_长度：TCP-AO MAC字段中使用的位的最终长度。该值可能是MAC函数原始输出长度的截断。
MACs computed for TCP-AO have the following interface:
为TCP-AO计算的MAC具有以下接口：
MAC = MAC_alg(Traffic_Key, Message)
MAC=MAC\u alg（流量密钥、消息）
where:
哪里：
- MAC_alg: MAC Algorithm used.
- MAC_alg：使用MAC算法。
- Traffic_Key: Variable; the result of KDF.
- 流量_键：可变；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:
本文件规定了两种MAC算法选项，用于生成TCP-AO使用的MAC：
* HMAC-SHA-1-96 based on [RFC2104] and [FIPS-180-3].
* HMAC-SHA-1-96基于[RFC2104]和[FIPS-180-3]。
* AES-128-CMAC-96 based on [NIST-SP800-38B][FIPS197]
* AES-128-CMAC-96基于[NIST-SP800-38B][FIPS197]
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的三个固定元件为：
- KDF_Alg: KDF_HMAC_SHA1.
- KDF_Alg:KDF_HMAC_SHA1。
- Key_Length: 160 bits.
- 密钥长度：160位。
- MAC_Length: 96 bits.
- MAC_长度：96位。
For:
用于：
MAC = MAC_alg (Traffic_Key, Message)
MAC=MAC\u alg（流量密钥、消息）
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.
- 流量_键：可变；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的三个固定元件为：
- KDF_Alg: KDF_AES_128_CMAC.
- KDF_Alg:KDF_AES_128_CMAC。
- Key_Length: 128 bits.
- 密钥长度：128位。
- MAC_Length: 96 bits.
- MAC_长度：96位。
For:
用于：
MAC = MAC_alg (Traffic_Key, Message)
MAC=MAC\u alg（流量密钥、消息）
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.
- 流量_键：可变；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
注意，在KDF_AES_128_CMAC的组合中，PRF需要128位/16字节的密钥作为种子。但是，为了方便管理员/部署人员，我们不想强制他们输入
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.
16字节主密钥。因此，我们指定了子密钥例程，它可以处理长度可变的主密钥，一个可能小于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:
请注意，解释为何强制使用两种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工作组的讨论结果，并在与安全区域主管协商后，授权使用两种MAC算法和两种相应的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]不会立即使SHA-1在HMAC模式下的应用变得脆弱。
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]
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.
保罗·霍夫曼（Paul Hoffman，我有时从他的[RFC4308]中复制）在这里快速创建了第一个版本。
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.
Tim Polk的电子邮件总结了SAAG就TCP-AO的两种哈希算法向TCPM提供的指导，该邮件主要被剪切并粘贴到本文档的各个部分中。
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工作组（其[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.
Eric“EKR”Rescorla和Brian Weis，他们为KDF向PRFs提供的输入澄清了问题。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工作组，他们与美国所有加密和路由人员一起工作了2年，并对本文件进行了审查。
[FIPS-180-3] FIPS Publication 180-3, "Secured Hash Standard", FIPS 180-3, October 2008.
[FIPS-180-3]FIPS出版物180-3，“安全哈希标准”，FIPS 180-3，2008年10月。
[FIPS197] FIPS Publications 197, "Advanced Encryption Standard (AES)", FIPS 197, November 2001.
[FIPS197]FIPS出版物197，“高级加密标准（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：用于消息认证的键控哈希”，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，“TCP认证选项”，RFC 59252010年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]“基于哈弗、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，“安全的随机性要求”，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]Hoffman，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，“互联网密钥交换协议（IKE）的基于密码的消息认证码伪随机函数128（AES-CMAC-PRF-128）算法的高级加密标准”，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号，邮编94089-1206
Phone: EMail: gregory.ietf@gmail.com
电话：电子邮件：格雷戈里。ietf@gmail.com
Eric Rescorla RTFM, Inc. 2064 Edgewood Drive Palo Alto, CA 94303 US
Eric Rescorla RTFM，Inc.美国加利福尼亚州帕洛阿尔托埃奇伍德大道2064号，邮编94303
Phone: 650-678-2350 EMail: ekr@rtfm.com
电话：650-678-2350电子邮件：ekr@rtfm.com