Internet Engineering Task Force (IETF) D. McGrew
Request for Comments: 7251 Cisco Systems
Category: Informational D. Bailey
ISSN: 2070-1721 Ruhr-University Bochum
M. Campagna
R. Dugal
Certicom Corp.
June 2014
Internet Engineering Task Force (IETF) D. McGrew
Request for Comments: 7251 Cisco Systems
Category: Informational D. Bailey
ISSN: 2070-1721 Ruhr-University Bochum
M. Campagna
R. Dugal
Certicom Corp.
June 2014
AES-CCM Elliptic Curve Cryptography (ECC) Cipher Suites for TLS
用于TLS的AES-CCM椭圆曲线加密（ECC）密码套件
Abstract
摘要
This memo describes the use of the Advanced Encryption Standard (AES) in the Counter and CBC-MAC Mode (CCM) of operation within Transport Layer Security (TLS) to provide confidentiality and data-origin authentication. The AES-CCM algorithm is amenable to compact implementations, making it suitable for constrained environments, while at the same time providing a high level of security. The cipher suites defined in this document use Elliptic Curve Cryptography (ECC) and are advantageous in networks with limited bandwidth.
本备忘录描述了在计数器中使用高级加密标准（AES）和传输层安全性（TLS）中的CBC-MAC模式（CCM）操作，以提供机密性和数据源身份验证。AES-CCM算法适用于紧凑的实现，使其适用于受限环境，同时提供高级别的安全性。本文中定义的密码套件使用椭圆曲线密码（ECC），在带宽有限的网络中具有优势。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非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/rfc7251.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7251.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions Used in This Document . . . . . . . . . . . . 3
2. ECC-Based AES-CCM Cipher Suites . . . . . . . . . . . . . . . 3
2.1. AEAD Algorithms . . . . . . . . . . . . . . . . . . . . . 5
2.2. Requirements on Curves and Hashes . . . . . . . . . . . . 5
3. TLS Versions . . . . . . . . . . . . . . . . . . . . . . . . 5
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
5.1. Perfect Forward Secrecy . . . . . . . . . . . . . . . . . 6
5.2. Counter Reuse . . . . . . . . . . . . . . . . . . . . . . 6
5.3. Hardware Security Modules . . . . . . . . . . . . . . . . 6
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Normative References . . . . . . . . . . . . . . . . . . 7
7.2. Informative References . . . . . . . . . . . . . . . . . 8
Appendix A. Recommended Curves and Algorithms . . . . . . . . . 9
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions Used in This Document . . . . . . . . . . . . 3
2. ECC-Based AES-CCM Cipher Suites . . . . . . . . . . . . . . . 3
2.1. AEAD Algorithms . . . . . . . . . . . . . . . . . . . . . 5
2.2. Requirements on Curves and Hashes . . . . . . . . . . . . 5
3. TLS Versions . . . . . . . . . . . . . . . . . . . . . . . . 5
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
5.1. Perfect Forward Secrecy . . . . . . . . . . . . . . . . . 6
5.2. Counter Reuse . . . . . . . . . . . . . . . . . . . . . . 6
5.3. Hardware Security Modules . . . . . . . . . . . . . . . . 6
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Normative References . . . . . . . . . . . . . . . . . . 7
7.2. Informative References . . . . . . . . . . . . . . . . . 8
Appendix A. Recommended Curves and Algorithms . . . . . . . . . 9
This document describes the use of Advanced Encryption Standard (AES) [AES] in Counter with CBC-MAC Mode (CCM) [CCM] in several TLS cipher suites. AES-CCM provides both authentication and confidentiality (encryption and decryption) and uses as its only primitive the AES encrypt block cipher operation. This makes it amenable to compact implementations, which are advantageous in constrained environments. Of course, adoption outside of constrained environments is necessary to enable interoperability, such as that between web clients and embedded servers, or between embedded clients and web servers. The use of AES-CCM has been specified for the IPsec Encapsulating Security Payload (ESP) [RFC4309] and 802.15.4 wireless networks [IEEE802154].
本文档描述了高级加密标准（AES）[AES]在几个TLS密码套件中与CBC-MAC模式（CCM）[CCM]计数器的使用。AES-CCM提供身份验证和机密性（加密和解密），并将AES加密分组密码操作用作其唯一原语。这使得它易于紧凑的实现，这在受限环境中是有利的。当然，为了实现互操作性，需要在受限环境之外采用，例如web客户端和嵌入式服务器之间，或者嵌入式客户端和web服务器之间。已为IPsec封装安全有效负载（ESP）[RFC4309]和802.15.4无线网络[IEEE802154]指定使用AES-CCM。
Authenticated encryption, 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 [RFC5116], adds the ability to check the integrity and authenticity of some associated data that is not encrypted. This memo utilizes the AEAD facility within TLS 1.2 [RFC5246] and the AES-CCM-based AEAD algorithms defined in [RFC5116] and [RFC6655]. All of these algorithms use AES-CCM; some have shorter authentication tags and are therefore more suitable for use across networks in which bandwidth is constrained and message sizes may be small.
认证加密除了为加密的明文提供机密性外，还提供了一种检查其完整性和真实性的方法。使用关联数据进行身份验证加密或AEAD[RFC5116]增加了检查未加密的某些关联数据的完整性和真实性的能力。本备忘录利用了TLS 1.2[RFC5246]中的AEAD设施以及[RFC5116]和[RFC6655]中定义的基于AES CCM的AEAD算法。所有这些算法都使用AES-CCM；有些具有较短的身份验证标签，因此更适合在带宽受限且消息大小可能较小的网络中使用。
The cipher suites defined in this document use Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) as their key establishment mechanism; these cipher suites can be used with DTLS [RFC6347].
本文中定义的密码套件使用短暂椭圆曲线Diffie-Hellman（ECDHE）作为密钥建立机制；这些密码套件可与DTL[RFC6347]一起使用。
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]中所述进行解释。
The cipher suites defined in this document are based on the AES-CCM Authenticated Encryption with Associated Data (AEAD) algorithms AEAD_AES_128_CCM and AEAD_AES_256_CCM described in [RFC5116]. The following cipher suites are defined:
本文件中定义的密码套件基于[RFC5116]中描述的AES-CCM认证加密及相关数据（AEAD）算法AEAD_AES_128_CCM和AEAD_AES_256_CCM。定义了以下密码套件：
CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_CCM = {0xC0,0xAC}
CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CCM = {0xC0,0xAD}
CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 = {0xC0,0xAE}
CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CCM_8 = {0xC0,0xAF}
CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_CCM = {0xC0,0xAC}
CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CCM = {0xC0,0xAD}
CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 = {0xC0,0xAE}
CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CCM_8 = {0xC0,0xAF}
These cipher suites make use of the AEAD capability in TLS 1.2 [RFC5246]. Note that each of these AEAD algorithms uses AES-CCM. Cipher suites ending with "8" use eight-octet authentication tags; the other cipher suites have 16-octet authentication tags.
这些密码套件利用TLS 1.2[RFC5246]中的AEAD功能。请注意，这些AEAD算法都使用AES-CCM。以“8”结尾的密码套件使用八个八位组认证标签；其他密码套件有16个八位字节身份验证标签。
The HMAC truncation option described in Section 7 of [RFC6066] (which negotiates the "truncated_hmac" TLS extension) does not have an effect on the cipher suites defined in this note, because they do not use HMAC to protect TLS records.
[RFC6066]第7节中描述的HMAC截断选项（协商“截断的_HMAC”TLS扩展）对本说明中定义的密码套件没有影响，因为它们不使用HMAC保护TLS记录。
The "nonce" input to the AEAD algorithm is as defined in [RFC6655].
AEAD算法的“nonce”输入如[RFC6655]中所定义。
In DTLS, the 64-bit seq_num field is the 16-bit DTLS epoch field concatenated with the 48-bit sequence_number field. The epoch and sequence_number appear in the DTLS record layer.
在DTLS中，64位seq_num字段是16位DTLS历元字段，与48位序列号字段连接在一起。纪元和序列号显示在DTLS记录层中。
This construction allows the internal counter to be 32 bits long, which is a convenient size for use with CCM.
这种结构允许内部计数器为32位长，这对于CCM来说是一个方便的尺寸。
These cipher suites make use of the default TLS 1.2 Pseudorandom Function (PRF), which uses HMAC with the SHA-256 hash function.
这些密码套件使用默认的TLS1.2伪随机函数（PRF），该函数使用HMAC和SHA-256哈希函数。
The ECDHE_ECDSA key exchange is performed as defined in [RFC4492], with the following additional stipulations:
ECDHE_ECDSA密钥交换按照[RFC4492]中的定义执行，并附带以下附加规定：
o Curves with a cofactor equal to one SHOULD be used; this simplifies their use.
o 应使用辅因子等于1的曲线；这简化了它们的使用。
o The uncompressed point format MUST be supported. Other point formats MAY be used.
o 必须支持未压缩的点格式。可以使用其他点格式。
o The client SHOULD offer the elliptic_curves extension, and the server SHOULD expect to receive it.
o 客户端应该提供椭圆曲线扩展，服务器应该期望收到它。
o The client MAY offer the ec_point_formats extension, but the server need not expect to receive it.
o 客户端可以提供ec_point_formats扩展，但服务器无需期望收到它。
o Fundamental ECC algorithms [RFC6090] MAY be used as an implementation method.
o 基本ECC算法[RFC6090]可用作实现方法。
o If the server uses a certificate, then the requirements in RFC 4492 apply: "The server's certificate MUST contain an ECDSA-capable public key and be signed with ECDSA." Guidance on acceptable choices of hashes and curves that can be used with each cipher suite is detailed in Section 2.2. The Signature Algorithms extension (Section 7.4.1.4.1 of [RFC5246]) SHOULD be used to indicate support of those signature and hash algorithms. If a client certificate is used, the same criteria SHOULD apply to it.
o 如果服务器使用证书，则RFC 4492中的要求适用：“服务器的证书必须包含支持ECDSA的公钥，并使用ECDSA签名。”第2.2节详细介绍了可用于每个密码套件的哈希和曲线的可接受选择指南。签名算法扩展（RFC5246第7.4.1.4.1节）应用于表示支持这些签名和哈希算法。如果使用客户机证书，则应采用相同的标准。
Implementations of these cipher suites will interoperate with [RFC4492] but can be more compact than a full implementation of that RFC.
这些密码套件的实现将与[RFC4492]互操作，但可以比该RFC的完整实现更紧凑。
The following AEAD algorithms are used:
使用以下AEAD算法：
AEAD_AES_128_CCM is used in the TLS_ECDHE_ECDSA_WITH_AES_128_CCM cipher suite,
AEAD_AES_128_CCM与_AES_128_CCM密码套件一起用于TLS_ECDHE_ECDSA_，
AEAD_AES_256_CCM is used in the TLS_ECDHE_ECDSA_WITH_AES_256_CCM cipher suite,
AEAD_AES_256_CCM与_AES_256_CCM密码套件一起用于TLS_ECDHE_ECDSA_，
AEAD_AES_128_CCM_8 is used in the TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 cipher suite, and
AEAD_AES_128_CCM_8与_AES_128_CCM_8密码套件一起用于TLS_ECDHE_ECDSA_，以及
AEAD_AES_256_CCM_8 is used in the TLS_ECDHE_ECDSA_WITH_AES_256_CCM_8 cipher suite.
AEAD_AES_256_CCM_8与AES_256_CCM_8密码套件一起用于TLS_ECDHE_ECDSA_。
Implementations SHOULD select elliptic curves and hash functions so that AES-128 is used with a curve and a hash function supporting a 128-bit security level, and AES-256 is used with a curve and a hash function supporting a 192-bit or 256-bit security level. More detailed guidance on cryptographic parameter selection is given in [SP800-57] (see especially Tables 2 and 3).
实现应选择椭圆曲线和散列函数，以便AES-128与支持128位安全级别的曲线和散列函数一起使用，AES-256与支持192位或256位安全级别的曲线和散列函数一起使用。[SP800-57]中给出了关于加密参数选择的更详细指导（特别参见表2和表3）。
Appendix A describes suitable curves and hash functions that are widely available.
附录A描述了广泛可用的合适曲线和散列函数。
These cipher suites make use of the authenticated encryption with additional data defined in TLS 1.2 [RFC5288]. They MUST NOT be negotiated in older versions of TLS. Clients MUST NOT offer these cipher suites if they do not offer TLS 1.2 or later. Servers that select an earlier version of TLS MUST NOT select one of these cipher suites. Earlier versions do not have support for AEAD; for instance, the TLSCiphertext structure does not have the "aead" option in TLS 1.1. Because TLS has no way for the client to indicate that it supports TLS 1.2 but not earlier versions, a non-compliant server might potentially negotiate TLS 1.1 or earlier and select one of the cipher suites in this document. Clients MUST check the TLS version and generate a fatal "illegal_parameter" alert if they detect an incorrect version.
这些密码套件使用TLS 1.2[RFC5288]中定义的附加数据的认证加密。不得在较旧版本的TLS中协商。如果客户不提供TLS 1.2或更高版本，则不得提供这些密码套件。选择TLS早期版本的服务器不得选择这些密码套件之一。早期版本不支持AEAD；例如，TLSCiphertext结构在TLS 1.1中没有“aead”选项。由于TLS无法让客户端表明它支持TLS 1.2，但不支持早期版本，因此不兼容的服务器可能会协商TLS 1.1或早期版本，并选择此文档中的一个密码套件。客户端必须检查TLS版本，如果检测到不正确的版本，则必须生成致命的“非法_参数”警报。
IANA has assigned the values for the cipher suites defined in Section 2 from the "TLS Cipher Suite Registry". The DTLS-OK column has been marked as "Y" for each of these algorithms.
IANA已从“TLS密码套件注册表”中为第2节中定义的密码套件分配了值。对于每种算法，DTLS-OK列都标记为“Y”。
The perfect forward secrecy properties of ephemeral Diffie-Hellman cipher suites are discussed in the security analysis of [RFC5246]. This analysis applies to the ECDHE cipher suites.
在[RFC5246]的安全性分析中，讨论了短暂Diffie-Hellman密码组的完全前向保密性。此分析适用于ECDHE密码套件。
AES-CCM security requires that the counter never be reused. The IV construction in Section 2 is designed to prevent counter reuse.
AES-CCM安全性要求永远不要重用计数器。第2节中的IV构造旨在防止计数器重复使用。
A cipher suite can be implemented in such a way that the secret keys and private keys are stored inside a Hardware Security Module (HSM), and the cryptographic operations involving those keys are performed by the HSM on data provided by an application interacting with the HSM through an interface such as that defined by the Cryptographic Token Interface Standard [PKCS11]. When an AEAD cipher suite, such as those in this note, are implemented in this way, special handling of the nonce is required. This is because the "salt" part of the nonce is set to the client_write_IV or server_write_IV, which is a function of the TLS master secret.
密码套件的实现方式可以使密钥和私钥存储在硬件安全模块（HSM）中，并且涉及这些密钥的加密操作由HSM对通过诸如加密令牌接口标准[PKCS11]定义的接口与HSM交互的应用程序提供的数据执行。当AEAD密码套件（如本说明中的密码套件）以这种方式实现时，需要对nonce进行特殊处理。这是因为nonce的“salt”部分被设置为client_write_IV或server_write_IV，这是TLS主密钥的函数。
Another potential issue with the Cryptographic Token Interface Standard is that the use of the DecryptUpdate function is not possible with the CCM decrypt operation or the decrypt operation of any other authenticated encryption method. This is because the DecryptUpdate requires that post-decryption plaintext be returned before the authentication check is completed.
加密令牌接口标准的另一个潜在问题是，在CCM解密操作或任何其他认证加密方法的解密操作中，无法使用DecryptUpdate函数。这是因为解密更新要求在完成身份验证检查之前返回解密后的明文。
This document borrows heavily from [RFC5288]. Thanks are due to Robert Cragie for his great help in making this work complete, correct, and useful, and to Peter Dettman for his review. Thanks also to Mike StJohns for pointing out the HSM issues.
本文件大量借鉴了[RFC5288]。感谢Robert Cragie在使这项工作完整、正确和有用方面提供的巨大帮助，感谢Peter Dettman的评论。还感谢Mike StJohns指出HSM问题。
This document is motivated by the considerations raised in the Zigbee Smart Energy 2.0 working group.
本文件基于Zigbee智能能源2.0工作组提出的考虑。
[AES] National Institute of Standards and Technology, "Specification for the Advanced Encryption Standard (AES)", FIPS 197, November 2001.
[AES]国家标准与技术研究所，“高级加密标准（AES）规范”，FIPS 197，2001年11月。
[CCM] National Institute of Standards and Technology, "Recommendation for Block Cipher Modes of Operation: The CCM Mode for Authentication and Confidentiality", SP 800-38C, May 2004.
[CCM]国家标准与技术研究所，“分组密码操作模式的建议：认证和保密的CCM模式”，SP 800-38C，2004年5月。
[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月。
[RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)", RFC 4492, May 2006.
[RFC4492]Blake Wilson，S.，Bolyard，N.，Gupta，V.，Hawk，C.，和B.Moeller，“用于传输层安全（TLS）的椭圆曲线密码（ECC）密码套件”，RFC 4492，2006年5月。
[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated Encryption", RFC 5116, January 2008.
[RFC5116]McGrew，D.“认证加密的接口和算法”，RFC 5116，2008年1月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年8月。
[RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, August 2008.
[RFC5288]Salowey，J.，Choudhury，A.，和D.McGrew，“用于TLS的AES伽罗瓦计数器模式（GCM）密码套件”，RFC 5288，2008年8月。
[RFC5639] Lochter, M. and J. Merkle, "Elliptic Curve Cryptography (ECC) Brainpool Standard Curves and Curve Generation", RFC 5639, March 2010.
[RFC5639]Lochter，M.和J.Merkle，“椭圆曲线加密（ECC）大脑池标准曲线和曲线生成”，RFC 56392010年3月。
[RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, January 2011.
[RFC6066]Eastlake，D.，“传输层安全（TLS）扩展：扩展定义”，RFC6066，2011年1月。
[RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic Curve Cryptography Algorithms", RFC 6090, February 2011.
[RFC6090]McGrew，D.，Igoe，K.，和M.Salter，“基本椭圆曲线密码算法”，RFC 60902011年2月。
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, January 2012.
[RFC6347]Rescorla，E.和N.Modadugu，“数据报传输层安全版本1.2”，RFC 6347，2012年1月。
[RFC6655] McGrew, D. and D. Bailey, "AES-CCM Cipher Suites for Transport Layer Security (TLS)", RFC 6655, July 2012.
[RFC6655]McGrew，D.和D.Bailey，“用于传输层安全（TLS）的AES-CCM密码套件”，RFC 66552012年7月。
[SP800-57] National Institute of Standards and Technology, "Recommendation for Key Management - Part 1: General (Revision 3)", SP 800-57 Part 1, July 2012.
[SP800-57]国家标准与技术研究所，“密钥管理建议-第1部分：总则（第3版）”，SP 800-57第1部分，2012年7月。
[IEEE802154] IEEE, "Wireless Personal Area Networks", IEEE Standard 802.15.4-2006, 2006.
[IEEE802154]IEEE，“无线个人区域网络”，IEEE标准802.15.4-2006，2006年。
[PKCS11] RSA Laboratories, "PKCS #11: Cryptographic Token Interface Standard version 2.20", Public Key Cryptography Standards PKCS#11-v2.20, 2004.
[PKCS11]RSA实验室，“PKCS#11：加密令牌接口标准版本2.20”，公钥加密标准PKCS#11-v2.202004。
[RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload (ESP)", RFC 4309, December 2005.
[RFC4309]Housley，R.，“使用高级加密标准（AES）CCM模式和IPsec封装安全有效载荷（ESP）”，RFC 4309，2005年12月。
This memo does not mandate any particular elliptic curves or cryptographic algorithms, for the sake of flexibility. However, since the main motivation for the AES-CCM-ECC cipher suites is their suitability for constrained environments, it is valuable to identify a particular suitable set of curves and algorithms.
出于灵活性考虑，本备忘录不强制要求任何特定的椭圆曲线或加密算法。然而，由于AES-CCM-ECC密码套件的主要动机是其对受限环境的适用性，因此确定一组特别合适的曲线和算法是很有价值的。
This appendix identifies a set of elliptic curves and cryptographic algorithms that meet the requirements of this note and that are widely supported and believed to be secure.
本附录确定了一组椭圆曲线和密码算法，这些椭圆曲线和密码算法满足本说明的要求，并得到广泛支持，被认为是安全的。
The curves and hash algorithms recommended for each cipher suite are:
为每个密码套件推荐的曲线和哈希算法为：
An implementation that includes either TLS_ECDHE_ECDSA_WITH_AES_128_CCM or TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 SHOULD support the secp256r1 curve and the SHA-256 hash function.
包含TLS_ECDHE_ECDSA_与_AES_128_CCM或TLS_ECDHE_ECDSA_与_AES_128_CCM_8的实现应支持secp256r1曲线和SHA-256哈希函数。
An implementation that includes either TLS_ECDHE_ECDSA_WITH_AES_256_CCM or TLS_ECDHE_ECDSA_WITH_AES_256_CCM_8 SHOULD support the secp384r1 curve and the SHA-384 hash function, and MAY support the secp521r1 curve and the SHA-512 hash function.
包含TLS_ECDHE_ECDSA_WITH_AES_256_CCM或TLS_ECDHE_ECDSA_WITH_AES_256_CCM_8的实现应支持secp384r1曲线和SHA-384哈希函数，并可支持secp521r1曲线和SHA-512哈希函数。
More information about the secp256r1, secp384r1, and secp521r1 curves is available in Appendix A of [RFC4492].
有关secp256r1、secp384r1和secp521r1曲线的更多信息，请参见[RFC4492]的附录A。
It is not necessary to implement the above curves and hash functions in order to conform to this specification. Other elliptic curves, such as the Brainpool curves [RFC5639], for example, meet the criteria laid out in this memo.
为了符合本规范，无需实现上述曲线和散列函数。其他椭圆曲线，例如Brainpool曲线[RFC5639]，符合本备忘录中列出的标准。
Authors' Addresses
作者地址
David McGrew Cisco Systems 13600 Dulles Technology Drive Herndon, VA 20171 USA
David McGrew Cisco Systems 13600美国弗吉尼亚州赫恩顿杜勒斯技术大道20171
EMail: mcgrew@cisco.com
EMail: mcgrew@cisco.com
Daniel V. Bailey Ruhr-University Bochum Universitatsstr. 150 44801 Bochum Germany
丹尼尔V.贝利鲁尔大学波鸿大学。150 44801波鸿德国
EMail: danbailey@sth.rub.de
EMail: danbailey@sth.rub.de
Matthew Campagna Certicom Corp. 5520 Explorer Drive #400 Mississauga, Ontario L4W 5L1 Canada
Matthew Campagna Certicom Corp.位于加拿大安大略省米西索加400号探索者大道5520号L4W 5L1
EMail: mcampagna@gmail.com
EMail: mcampagna@gmail.com
Robert Dugal Certicom Corp. 4701 Tahoe Blvd., Building A Mississauga, Ontario L4W 0B5 Canada
Robert Dugal Certicom Corp.位于加拿大安大略省米西索加市塔霍大道4701号，邮编L4W 0B5
EMail: rdugal@certicom.com
EMail: rdugal@certicom.com