Internet Engineering Task Force (IETF) D. McGrew
Request for Comments: 6655 Cisco Systems
Category: Standards Track D. Bailey
ISSN: 2070-1721 RSA, Security Division of EMC
July 2012
Internet Engineering Task Force (IETF) D. McGrew
Request for Comments: 6655 Cisco Systems
Category: Standards Track D. Bailey
ISSN: 2070-1721 RSA, Security Division of EMC
July 2012
AES-CCM Cipher Suites for Transport Layer Security (TLS)
用于传输层安全（TLS）的AES-CCM密码套件
Abstract
摘要
This memo describes the use of the Advanced Encryption Standard (AES) in the Counter with Cipher Block Chaining - Message Authentication Code (CBC-MAC) Mode (CCM) of operation within Transport Layer Security (TLS) and Datagram TLS (DTLS) to provide confidentiality and data origin authentication. The AES-CCM algorithm is amenable to compact implementations, making it suitable for constrained environments.
本备忘录描述了在传输层安全性（TLS）和数据报TLS（DTLS）内操作的密码块链-消息认证码（CBC-MAC）模式（CCM）计数器中使用高级加密标准（AES），以提供机密性和数据源认证。AES-CCM算法易于紧凑实现，因此适合于受限环境。
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/rfc6655.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6655.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 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. Conventions Used in This Document . . . . . . . . . . . . . . . 3
3. RSA-Based AES-CCM Cipher Suites . . . . . . . . . . . . . . . . 3
4. PSK-Based AES-CCM Cipher Suites . . . . . . . . . . . . . . . . 5
5. TLS Versions . . . . . . . . . . . . . . . . . . . . . . . . . 5
6. New AEAD Algorithms . . . . . . . . . . . . . . . . . . . . . . 5
6.1. AES-128-CCM with an 8-Octet Integrity Check Value (ICV) . . 6
6.2. AES-256-CCM with a 8-Octet Integrity Check Value (ICV) . . 6
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
8. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
8.1. Perfect Forward Secrecy . . . . . . . . . . . . . . . . . . 6
8.2. Counter Reuse . . . . . . . . . . . . . . . . . . . . . . . 6
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
10.1. Normative References . . . . . . . . . . . . . . . . . . . 7
10.2. Informative References . . . . . . . . . . . . . . . . . . 8
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . . 3
3. RSA-Based AES-CCM Cipher Suites . . . . . . . . . . . . . . . . 3
4. PSK-Based AES-CCM Cipher Suites . . . . . . . . . . . . . . . . 5
5. TLS Versions . . . . . . . . . . . . . . . . . . . . . . . . . 5
6. New AEAD Algorithms . . . . . . . . . . . . . . . . . . . . . . 5
6.1. AES-128-CCM with an 8-Octet Integrity Check Value (ICV) . . 6
6.2. AES-256-CCM with a 8-Octet Integrity Check Value (ICV) . . 6
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
8. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
8.1. Perfect Forward Secrecy . . . . . . . . . . . . . . . . . . 6
8.2. Counter Reuse . . . . . . . . . . . . . . . . . . . . . . . 6
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
10.1. Normative References . . . . . . . . . . . . . . . . . . . 7
10.2. Informative References . . . . . . . . . . . . . . . . . . 8
This document describes the use of Advanced Encryption Standard (AES) [AES] in Counter with CBC-MAC Mode (CCM) [CCM] in several TLS ciphersuites. AES-CCM provides both authentication and confidentiality and uses as its only primitive the AES encrypt operation (the AES decrypt operation is not needed). This makes it amenable to compact implementations, which is 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 IPsec Encapsulating Security Payload (ESP) [RFC4309] and 802.15.4 wireless networks [IEEE802154].
本文档描述了在几种TLS密码套件中使用CBC-MAC模式（CCM）[CCM]计数器的高级加密标准（AES）[AES]。AES-CCM提供身份验证和机密性，并将AES加密操作用作其唯一原语（不需要AES解密操作）。这使得它易于紧凑的实现，这在受限环境中是有利的。当然，为了实现互操作性（例如web客户端和嵌入式服务器之间的互操作性或嵌入式客户端和web服务器之间的互操作性），必须在受限环境之外采用。AES-CCM已指定用于IPsec封装安全有效负载（ESP）[RFC4309]和802.15.4无线网络[IEEE802154]。
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 document utilizes the AEAD facility within TLS 1.2 [RFC5246] and the AES-CCM-based AEAD algorithms defined in [RFC5116]. Additional AEAD algorithms are defined that use AES-CCM but 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]中定义的基于AES CCM的AEAD算法。定义了使用AES-CCM但认证标签较短的其他AEAD算法，因此更适合在带宽受限且消息大小可能较小的网络中使用。
The ciphersuites defined in this document use RSA or Pre-Shared Key (PSK) as their key establishment mechanism; these ciphersuites can be used with DTLS [RFC6347]. Since the ability to use AEAD ciphers was introduced in DTLS version 1.2, the ciphersuites defined in this document cannot be used with earlier versions of that protocol.
本文档中定义的密码套件使用RSA或预共享密钥（PSK）作为其密钥建立机制；这些密码套件可与DTL[RFC6347]一起使用。由于DTLS版本1.2中引入了使用AEAD密码的功能，因此本文档中定义的密码套件不能与该协议的早期版本一起使用。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
The ciphersuites 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 RSA-based ciphersuites are defined:
本文件中定义的密码套件基于[RFC5116]中描述的AES-CCM认证加密及相关数据（AEAD）算法AEAD_AES_128_CCM和AEAD_AES_256_CCM。定义了以下基于RSA的密码套件：
CipherSuite TLS_RSA_WITH_AES_128_CCM = {0xC0,0x9C}
CipherSuite TLS_RSA_WITH_AES_256_CCM = {0xC0,0x9D)
CipherSuite TLS_DHE_RSA_WITH_AES_128_CCM = {0xC0,0x9E}
CipherSuite TLS_DHE_RSA_WITH_AES_256_CCM = {0xC0,0x9F}
CipherSuite TLS_RSA_WITH_AES_128_CCM_8 = {0xC0,0xA0}
CipherSuite TLS_RSA_WITH_AES_256_CCM_8 = {0xC0,0xA1)
CipherSuite TLS_DHE_RSA_WITH_AES_128_CCM_8 = {0xC0,0xA2}
CipherSuite TLS_DHE_RSA_WITH_AES_256_CCM_8 = {0xC0,0xA3}
CipherSuite TLS_RSA_WITH_AES_128_CCM = {0xC0,0x9C}
CipherSuite TLS_RSA_WITH_AES_256_CCM = {0xC0,0x9D)
CipherSuite TLS_DHE_RSA_WITH_AES_128_CCM = {0xC0,0x9E}
CipherSuite TLS_DHE_RSA_WITH_AES_256_CCM = {0xC0,0x9F}
CipherSuite TLS_RSA_WITH_AES_128_CCM_8 = {0xC0,0xA0}
CipherSuite TLS_RSA_WITH_AES_256_CCM_8 = {0xC0,0xA1)
CipherSuite TLS_DHE_RSA_WITH_AES_128_CCM_8 = {0xC0,0xA2}
CipherSuite TLS_DHE_RSA_WITH_AES_256_CCM_8 = {0xC0,0xA3}
These ciphersuites make use of the AEAD capability in TLS 1.2 [RFC5246]. Each uses AES-CCM; those that end in "_8" have an 8-octet authentication tag, while the other ciphersuites have 16-octet authentication tags.
这些密码套件利用TLS 1.2[RFC5246]中的AEAD功能。每个都使用AES-CCM；以“_8”结尾的密码套件具有8个八位字节的身份验证标签，而其他密码套件具有16个八位字节的身份验证标签。
The Hashed Message Authentication Code (HMAC) truncation option described in Section 7 of [RFC6066] (which negotiates the "truncated_hmac" TLS extension) does not have an effect on cipher suites that do not use HMAC.
[RFC6066]第7节中描述的散列消息身份验证码（HMAC）截断选项（协商“truncated_HMAC”TLS扩展）对不使用HMAC的密码套件没有影响。
The "nonce" input to the AEAD algorithm is exactly that of [RFC5288]: the "nonce" SHALL be 12 bytes long and is constructed as follows: (this is an example of a "partially explicit" nonce; see Section 3.2.1 in [RFC5116]).
AEAD算法的“nonce”输入与[RFC5288]的输入完全相同：“nonce”的长度应为12字节，其构造如下：（这是“部分显式”nonce的示例；参见[RFC5116]中的第3.2.1节）。
struct {
opaque salt[4];
opaque nonce_explicit[8];
} CCMNonce;
struct {
opaque salt[4];
opaque nonce_explicit[8];
} CCMNonce;
The salt is the "implicit" part of the nonce and is not sent in the packet. Instead, the salt is generated as part of the handshake process: it is either the client_write_IV (when the client is sending) or the server_write_IV (when the server is sending). The salt length (SecurityParameters.fixed_iv_length) is 4 octets. The nonce_explicit is the "explicit" part of the nonce. It is chosen by the sender and is carried in each TLS record in the GenericAEADCipher.nonce_explicit field. The nonce_explicit length (SecurityParameters.record_iv_length) is 8 octets. Each value of the nonce_explicit MUST be distinct for each distinct invocation of the GCM encrypt function for any fixed key. Failure to meet this uniqueness requirement can significantly degrade security. The nonce_explicit MAY be the 64-bit sequence number (as long as those values are assured to meet the distinctness requirement).
salt是nonce的“隐式”部分，不在包中发送。相反，salt是作为握手过程的一部分生成的：它要么是客户端写入IV（当客户端发送时），要么是服务器写入IV（当服务器发送时）。salt长度（SecurityParameters.fixed_iv_长度）为4个八位字节。nonce_explicit是nonce的“显式”部分。它由发送方选择，并携带在GenericAEADCipher.nonce_显式字段中的每个TLS记录中。nonce_显式长度（SecurityParameters.record_iv_length）为8个八位字节。对于任何固定密钥的GCM encrypt函数的每次不同调用，nonce_explicit的每个值都必须是不同的。未能满足此唯一性要求可能会严重降低安全性。nonce_explicit可以是64位序列号（只要确保这些值满足区分性要求）。
In DTLS, the 64-bit seq_num is the 16-bit epoch concatenated with the 48-bit seq_num.
在DTLS中，64位seq_num是与48位seq_num串联的16位历元。
When the nonce_explicit is equal to the sequence number, the CCMNonce will have the structure of the CCMNonceExample given below.
当nonce_explicit等于序列号时，CCMNonce将具有下面给出的CCMNonceExample的结构。
struct {
uint32 client_write_IV; // low order 32-bits
uint64 seq_num; // TLS sequence number
} CCMClientNonce.
struct {
uint32 client_write_IV; // low order 32-bits
uint64 seq_num; // TLS sequence number
} CCMClientNonce.
struct {
uint32 server_write_IV; // low order 32-bits
uint64 seq_num; // TLS sequence number
} CCMServerNonce.
struct {
uint32 server_write_IV; // low order 32-bits
uint64 seq_num; // TLS sequence number
} CCMServerNonce.
struct {
case client:
CCMClientNonce;
case server:
CCMServerNonce:
} CCMNonceExample;
struct {
case client:
CCMClientNonce;
case server:
CCMServerNonce:
} CCMNonceExample;
These ciphersuites make use of the default TLS 1.2 Pseudorandom Function (PRF), which uses HMAC with the SHA-256 hash function. The RSA and DHE_RSA, key exchange is performed as defined in [RFC5246].
这些密码套件使用默认的TLS1.2伪随机函数（PRF），该函数使用HMAC和SHA-256哈希函数。RSA和DHE_RSA密钥交换按照[RFC5246]中的定义执行。
As in Section 3, these ciphersuites follow [RFC5116]. The PSK and DHE_PSK key exchange is performed as in [RFC4279]. The following ciphersuites are defined:
如第3节所述，这些密码套件遵循[RFC5116]。PSK和DHE_PSK密钥交换如[RFC4279]所示。定义了以下密码套件：
CipherSuite TLS_PSK_WITH_AES_128_CCM = {0xC0,0xA4}
CipherSuite TLS_PSK_WITH_AES_256_CCM = {0xC0,0xA5)
CipherSuite TLS_DHE_PSK_WITH_AES_128_CCM = {0xC0,0xA6}
CipherSuite TLS_DHE_PSK_WITH_AES_256_CCM = {0xC0,0xA7}
CipherSuite TLS_PSK_WITH_AES_128_CCM_8 = {0xC0,0xA8}
CipherSuite TLS_PSK_WITH_AES_256_CCM_8 = {0xC0,0xA9)
CipherSuite TLS_PSK_DHE_WITH_AES_128_CCM_8 = {0xC0,0xAA}
CipherSuite TLS_PSK_DHE_WITH_AES_256_CCM_8 = {0xC0,0xAB}
CipherSuite TLS_PSK_WITH_AES_128_CCM = {0xC0,0xA4}
CipherSuite TLS_PSK_WITH_AES_256_CCM = {0xC0,0xA5)
CipherSuite TLS_DHE_PSK_WITH_AES_128_CCM = {0xC0,0xA6}
CipherSuite TLS_DHE_PSK_WITH_AES_256_CCM = {0xC0,0xA7}
CipherSuite TLS_PSK_WITH_AES_128_CCM_8 = {0xC0,0xA8}
CipherSuite TLS_PSK_WITH_AES_256_CCM_8 = {0xC0,0xA9)
CipherSuite TLS_PSK_DHE_WITH_AES_128_CCM_8 = {0xC0,0xAA}
CipherSuite TLS_PSK_DHE_WITH_AES_256_CCM_8 = {0xC0,0xAB}
The "nonce" input to the AEAD algorithm is defined as in Section 3.
AEAD算法的“nonce”输入定义见第3节。
These ciphersuites make use of the default TLS 1.2 Pseudorandom Function (PRF), which uses HMAC with the SHA-256 hash function. The PSK and DHE_PSK key exchange is performed as defined in [RFC5487].
这些密码套件使用默认的TLS1.2伪随机函数（PRF），该函数使用HMAC和SHA-256哈希函数。PSK和DHE_PSK密钥交换按照[RFC5487]中的定义执行。
These ciphersuites make use of the authenticated encryption with additional data (AEAD) defined in TLS 1.2 [RFC5288]. Earlier versions of TLS do not have support for AEAD; for instance, the TLSCiphertext structure does not have the "aead" option in TLS 1.1. Consequently, these ciphersuites 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. Because TLS has no way for the client to indicate that it supports TLS 1.2 but not earlier, 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]中定义的带附加数据的认证加密（AEAD）。TLS的早期版本不支持AEAD；例如，TLSCiphertext结构在TLS 1.1中没有“aead”选项。因此，这些密码套件不得在较旧版本的TLS中协商。如果客户不提供TLS 1.2或更高版本，则不得提供这些密码套件。选择TLS早期版本的服务器不得选择这些密码套件之一。由于TLS无法让客户端指示它支持TLS 1.2但不支持更早版本，因此不合规的服务器可能会协商TLS 1.1或更早版本，并在此文档中选择一个密码套件。客户端必须检查TLS版本，如果检测到不正确的版本，则必须生成致命的“非法_参数”警报。
The following AEAD algorithms are defined:
定义了以下AEAD算法：
AEAD_AES_128_CCM_8 = 18 AEAD_AES_256_CCM_8 = 19
AEAD_AES_128_CCM_8=18 AEAD_AES_256_CCM_8=19
The AEAD_AES_128_CCM_8 authenticated encryption algorithm is identical to the AEAD_AES_128_CCM algorithm (see Section 5.3 of [RFC5116]), except that it uses 8 octets for authentication, instead of the full 16 octets used by AEAD_AES_128_CCM. The AEAD_AES_128_CCM_8 ciphertext consists of the ciphertext output of the CCM encryption operation concatenated with the 8-octet authentication tag output of the CCM encryption operation. Test cases are provided in [CCM]. The input and output lengths are the same as those for AEAD_AES_128_CCM. An AEAD_AES_128_CCM_8 ciphertext is exactly 8 octets longer than its corresponding plaintext.
AEAD_AES_128_CCM_8认证加密算法与AEAD_AES_128_CCM算法（见[RFC5116]第5.3节）相同，只是它使用8个八位字节进行认证，而不是AEAD_AES_128_CCM使用的全部16个八位字节。AEAD_AES_128_CCM_8密文由CCM加密操作的密文输出与CCM加密操作的8位八位组认证标签输出串联而成。[CCM]中提供了测试用例。输入和输出长度与AEAD_AES_128_CCM的输入和输出长度相同。AEAD_AES_128_CCM_8密文正好比其相应的明文长8个八位字节。
The AEAD_AES_256_CCM_8 authenticated encryption algorithm is identical to the AEAD_AES_256_CCM algorithm (see Section 5.4 of [RFC5116]), except that it uses 8 octets for authentication, instead of the full 16 octets used by AEAD_AES_256_CCM. The AEAD_AES_256_CCM_8 ciphertext consists of the ciphertext output of the CCM encryption operation concatenated with the 8-octet authentication tag output of the CCM encryption operation. Test cases are provided in [CCM]. The input and output lengths are as for AEAD_AES_128_CCM. An AEAD_AES_128_CCM_8 ciphertext is exactly 8 octets longer than its corresponding plaintext.
AEAD_AES_256_CCM_8认证加密算法与AEAD_AES_256_CCM算法（参见[RFC5116]第5.4节）相同，只是它使用8个八位字节进行认证，而不是AEAD_AES_256_CCM使用的全部16个八位字节。AEAD_AES_256_CCM_8密文由CCM加密操作的密文输出与CCM加密操作的8位八位组认证标签输出串联而成。[CCM]中提供了测试用例。输入和输出长度与AEAD_AES_128_CCM相同。AEAD_AES_128_CCM_8密文正好比其相应的明文长8个八位字节。
IANA has assigned the values for the ciphersuites defined in Sections 3 and 4 from the "TLS Cipher Suite" registry and the values of the AEAD algorithms defined in Section 6 from the "AEAD Algorithms" registry.
IANA已从“TLS密码套件”注册表中为第3节和第4节中定义的密码套件赋值，并从“AEAD算法”注册表中为第6节中定义的AEAD算法赋值。
The perfect forward secrecy properties of RSA-based TLS ciphersuites are discussed in the security analysis of [RFC5246]. It should be noted that only the ephemeral Diffie-Hellman-based ciphersuites are capable of providing perfect forward secrecy.
在[RFC5246]的安全性分析中讨论了基于RSA的TLS密码套件的完美前向保密性。应该注意的是，只有短暂的基于Diffie-Hellman的密码套件能够提供完美的前向保密性。
AES-CCM security requires that the counter is never reused. The IV construction in Section 3 is designed to prevent counter reuse.
AES-CCM安全性要求从不重用计数器。第3节中的IV构造旨在防止计数器重复使用。
This document borrows heavily from [RFC5288]. Thanks are due to Stephen Farrell and Robert Cragie for their input.
本文件大量借鉴了[RFC5288]。感谢Stephen Farrell和Robert Cragie的投入。
[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月。
[RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)", RFC 4279, December 2005.
[RFC4279]Eronen，P.和H.Tschofenig，“用于传输层安全（TLS）的预共享密钥密码套件”，RFC 4279，2005年12月。
[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月。
[RFC5487] Badra, M., "Pre-Shared Key Cipher Suites for TLS with SHA-256/384 and AES Galois Counter Mode", RFC 5487, March 2009.
[RFC5487]Badra，M.，“具有SHA-256/384和AES伽罗瓦计数器模式的TLS预共享密钥密码套件”，RFC 5487，2009年3月。
[RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, January 2011.
[RFC6066]Eastlake，D.，“传输层安全（TLS）扩展：扩展定义”，RFC6066，2011年1月。
[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月。
[IEEE802154] Institute of Electrical and Electronics Engineers, "Wireless Personal Area Networks", IEEE Standard 802.15.4-2006, 2006.
[IEEE802154]电气和电子工程师协会，“无线个人区域网络”，IEEE标准802.15.4-2006，2006年。
[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月。
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 RSA, Security Division of EMC 174 Middlesex Tpke. Bedford, MA 01463 USA
Daniel V.Bailey RSA，EMC 174 Middlesex Tpke的安全部门。美国马萨诸塞州贝德福德01463
EMail: dbailey@rsa.com
EMail: dbailey@rsa.com