Internet Engineering Task Force (IETF) H. Tschofenig, Ed.
Request for Comments: 7925 ARM Ltd.
Category: Standards Track T. Fossati
ISSN: 2070-1721 Nokia
July 2016
Internet Engineering Task Force (IETF) H. Tschofenig, Ed.
Request for Comments: 7925 ARM Ltd.
Category: Standards Track T. Fossati
ISSN: 2070-1721 Nokia
July 2016
Transport Layer Security (TLS) / Datagram Transport Layer Security (DTLS) Profiles for the Internet of Things
物联网的传输层安全（TLS）/数据报传输层安全（DTLS）配置文件
Abstract
摘要
A common design pattern in Internet of Things (IoT) deployments is the use of a constrained device that collects data via sensors or controls actuators for use in home automation, industrial control systems, smart cities, and other IoT deployments.
物联网（IoT）部署中的一种常见设计模式是使用受限设备，该设备通过传感器或控制执行器收集数据，用于家庭自动化、工业控制系统、智能城市和其他物联网部署。
This document defines a Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) 1.2 profile that offers communications security for this data exchange thereby preventing eavesdropping, tampering, and message forgery. The lack of communication security is a common vulnerability in IoT products that can easily be solved by using these well-researched and widely deployed Internet security protocols.
本文档定义了传输层安全性（TLS）和数据报传输层安全性（DTLS）1.2配置文件，该配置文件为该数据交换提供通信安全性，从而防止窃听、篡改和消息伪造。缺乏通信安全是物联网产品中的一个常见漏洞，通过使用这些经过充分研究和广泛部署的互联网安全协议可以轻松解决。
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 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第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/rfc7925.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7925.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 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 . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. TLS and DTLS . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Communication Models . . . . . . . . . . . . . . . . . . 6
3.3. The Ciphersuite Concept . . . . . . . . . . . . . . . . . 20
4. Credential Types . . . . . . . . . . . . . . . . . . . . . . 21
4.1. Preconditions . . . . . . . . . . . . . . . . . . . . . . 21
4.2. Pre-Shared Secret . . . . . . . . . . . . . . . . . . . . 23
4.3. Raw Public Key . . . . . . . . . . . . . . . . . . . . . 25
4.4. Certificates . . . . . . . . . . . . . . . . . . . . . . 27
5. Signature Algorithm Extension . . . . . . . . . . . . . . . . 32
6. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 32
7. Session Resumption . . . . . . . . . . . . . . . . . . . . . 34
8. Compression . . . . . . . . . . . . . . . . . . . . . . . . . 35
9. Perfect Forward Secrecy . . . . . . . . . . . . . . . . . . . 35
10. Keep-Alive . . . . . . . . . . . . . . . . . . . . . . . . . 36
11. Timeouts . . . . . . . . . . . . . . . . . . . . . . . . . . 38
12. Random Number Generation . . . . . . . . . . . . . . . . . . 39
13. Truncated MAC and Encrypt-then-MAC Extension . . . . . . . . 40
14. Server Name Indication (SNI) . . . . . . . . . . . . . . . . 40
15. Maximum Fragment Length Negotiation . . . . . . . . . . . . . 41
16. Session Hash . . . . . . . . . . . . . . . . . . . . . . . . 41
17. Renegotiation Attacks . . . . . . . . . . . . . . . . . . . . 42
18. Downgrading Attacks . . . . . . . . . . . . . . . . . . . . . 42
19. Crypto Agility . . . . . . . . . . . . . . . . . . . . . . . 43
20. Key Length Recommendations . . . . . . . . . . . . . . . . . 44
21. False Start . . . . . . . . . . . . . . . . . . . . . . . . . 45
22. Privacy Considerations . . . . . . . . . . . . . . . . . . . 45
23. Security Considerations . . . . . . . . . . . . . . . . . . . 46
24. References . . . . . . . . . . . . . . . . . . . . . . . . . 47
24.1. Normative References . . . . . . . . . . . . . . . . . . 47
24.2. Informative References . . . . . . . . . . . . . . . . . 48
Appendix A. Conveying DTLS over SMS . . . . . . . . . . . . . . 56
A.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 56
A.2. Message Segmentation and Reassembly . . . . . . . . . . . 57
A.3. Multiplexing Security Associations . . . . . . . . . . . 57
A.4. Timeout . . . . . . . . . . . . . . . . . . . . . . . . . 58
Appendix B. DTLS Record Layer Per-Packet Overhead . . . . . . . 59
Appendix C. DTLS Fragmentation . . . . . . . . . . . . . . . . . 60
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 60
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 61
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. TLS and DTLS . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Communication Models . . . . . . . . . . . . . . . . . . 6
3.3. The Ciphersuite Concept . . . . . . . . . . . . . . . . . 20
4. Credential Types . . . . . . . . . . . . . . . . . . . . . . 21
4.1. Preconditions . . . . . . . . . . . . . . . . . . . . . . 21
4.2. Pre-Shared Secret . . . . . . . . . . . . . . . . . . . . 23
4.3. Raw Public Key . . . . . . . . . . . . . . . . . . . . . 25
4.4. Certificates . . . . . . . . . . . . . . . . . . . . . . 27
5. Signature Algorithm Extension . . . . . . . . . . . . . . . . 32
6. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 32
7. Session Resumption . . . . . . . . . . . . . . . . . . . . . 34
8. Compression . . . . . . . . . . . . . . . . . . . . . . . . . 35
9. Perfect Forward Secrecy . . . . . . . . . . . . . . . . . . . 35
10. Keep-Alive . . . . . . . . . . . . . . . . . . . . . . . . . 36
11. Timeouts . . . . . . . . . . . . . . . . . . . . . . . . . . 38
12. Random Number Generation . . . . . . . . . . . . . . . . . . 39
13. Truncated MAC and Encrypt-then-MAC Extension . . . . . . . . 40
14. Server Name Indication (SNI) . . . . . . . . . . . . . . . . 40
15. Maximum Fragment Length Negotiation . . . . . . . . . . . . . 41
16. Session Hash . . . . . . . . . . . . . . . . . . . . . . . . 41
17. Renegotiation Attacks . . . . . . . . . . . . . . . . . . . . 42
18. Downgrading Attacks . . . . . . . . . . . . . . . . . . . . . 42
19. Crypto Agility . . . . . . . . . . . . . . . . . . . . . . . 43
20. Key Length Recommendations . . . . . . . . . . . . . . . . . 44
21. False Start . . . . . . . . . . . . . . . . . . . . . . . . . 45
22. Privacy Considerations . . . . . . . . . . . . . . . . . . . 45
23. Security Considerations . . . . . . . . . . . . . . . . . . . 46
24. References . . . . . . . . . . . . . . . . . . . . . . . . . 47
24.1. Normative References . . . . . . . . . . . . . . . . . . 47
24.2. Informative References . . . . . . . . . . . . . . . . . 48
Appendix A. Conveying DTLS over SMS . . . . . . . . . . . . . . 56
A.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 56
A.2. Message Segmentation and Reassembly . . . . . . . . . . . 57
A.3. Multiplexing Security Associations . . . . . . . . . . . 57
A.4. Timeout . . . . . . . . . . . . . . . . . . . . . . . . . 58
Appendix B. DTLS Record Layer Per-Packet Overhead . . . . . . . 59
Appendix C. DTLS Fragmentation . . . . . . . . . . . . . . . . . 60
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 60
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 61
An engineer developing an Internet of Things (IoT) device needs to investigate the security threats and decide about the security services that can be used to mitigate these threats.
开发物联网（IoT）设备的工程师需要调查安全威胁，并决定可用于缓解这些威胁的安全服务。
Enabling IoT devices to exchange data often requires authentication of the two endpoints and the ability to provide integrity and confidentiality protection of exchanged data. While these security services can be provided at different layers in the protocol stack, the use of Transport Layer Security (TLS) / Datagram Transport Layer Security (DTLS) has been very popular with many application protocols, and it is likely to be useful for IoT scenarios as well.
使物联网设备能够交换数据通常需要对两个端点进行身份验证，并能够提供交换数据的完整性和机密性保护。虽然这些安全服务可以在协议栈的不同层提供，但传输层安全性（TLS）/数据报传输层安全性（DTLS）的使用在许多应用协议中都非常流行，并且可能对物联网场景也很有用。
Fitting Internet protocols into constrained devices can be difficult, but thanks to the standardization efforts, new profiles and protocols are available, such as the Constrained Application Protocol (CoAP) [RFC7252]. CoAP messages are mainly carried over UDP/DTLS, but other transports can be utilized, such as SMS (as described in Appendix A) or TCP (as currently being proposed with [COAP-TCP-TLS]).
将Internet协议安装到受约束的设备中可能很困难，但由于标准化工作，新的配置文件和协议可用，例如受约束的应用程序协议（CoAP）[RFC7252]。CoAP消息主要通过UDP/DTL传输，但也可以使用其他传输方式，如SMS（如附录A所述）或TCP（如[CoAP-TCP-TLS]当前提议的）。
While the main goal for this document is to protect CoAP messages using DTLS 1.2 [RFC6347], the information contained in the following sections is not limited to CoAP nor to DTLS itself.
虽然本文档的主要目标是使用DTLS 1.2[RFC6347]保护CoAP消息，但以下章节中包含的信息不仅限于CoAP，也不限于DTLS本身。
Instead, this document defines a profile of DTLS 1.2 [RFC6347] and TLS 1.2 [RFC5246] that offers communication security services for IoT applications and is reasonably implementable on many constrained devices. Profile thereby means that available configuration options and protocol extensions are utilized to best support the IoT environment. This document does not alter TLS/DTLS specifications and does not introduce any new TLS/DTLS extension.
相反，本文件定义了DTLS 1.2[RFC6347]和TLS 1.2[RFC5246]的配置文件，该配置文件为物联网应用提供通信安全服务，并可在许多受限设备上合理实施。因此，配置文件意味着利用可用的配置选项和协议扩展来最好地支持物联网环境。本文档不会更改TLS/DTLS规范，也不会引入任何新的TLS/DTLS扩展。
The main target audience for this document is the embedded system developer configuring and using a TLS/DTLS stack. This document may, however, also help those developing or selecting a suitable TLS/DTLS stack for an IoT product. If you are familiar with (D)TLS, then skip ahead to Section 4.
本文档的主要目标受众是配置和使用TLS/DTLS堆栈的嵌入式系统开发人员。然而，本文件也可能有助于为物联网产品开发或选择合适的TLS/DTLS堆栈。如果您熟悉（D）TLS，请跳到第4节。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照RFC 2119[RFC2119]中的说明进行解释。
This specification refers to TLS as well as DTLS and particularly to version 1.2, which is the most recent version at the time of writing.
本规范涉及TLS和DTL，尤其是1.2版，这是撰写本文时的最新版本。
We refer to TLS/DTLS whenever the text is applicable to both versions of the protocol and to TLS or DTLS when there are differences between the two protocols. Note that TLS 1.3 is being developed, but it is not expected that this profile will "just work" due to the significant changes being done to TLS for version 1.3.
当文本适用于协议的两个版本时，我们引用TLS/DTLS；当两个协议之间存在差异时，我们引用TLS或DTLS。请注意，TLS 1.3正在开发中，但由于对TLS 1.3版所做的重大更改，预计该概要文件不会“正常工作”。
Note that "client" and "server" in this document refer to TLS/DTLS roles, where the client initiates the handshake. This does not restrict the interaction pattern of the protocols on top of DTLS since the record layer allows bidirectional communication. This aspect is further described in Section 3.2.
请注意，本文档中的“客户机”和“服务器”指的是TLS/DTLS角色，客户机在其中发起握手。这并不限制DTL之上协议的交互模式，因为记录层允许双向通信。第3.2节进一步描述了这一方面。
RFC 7228 [RFC7228] introduces the notion of constrained-node networks, which are made of small devices with severe constraints on power, memory, and processing resources. The terms constrained devices and IoT devices are used interchangeably.
RFC 7228[RFC7228]引入了受约束节点网络的概念，该网络由小型设备组成，这些设备在电源、内存和处理资源方面受到严重限制。术语受限设备和物联网设备可互换使用。
The terms "certification authority" (CA) and "distinguished name" (DN) are taken from [RFC5280]. The terms "trust anchor" and "trust anchor store" are defined in [RFC6024] as:
术语“证书颁发机构”（CA）和“可分辨名称”（DN）取自[RFC5280]。[RFC6024]中将术语“信任锚”和“信任锚存储”定义为：
A trust anchor represents an authoritative entity via a public key and associated data. The public key is used to verify digital signatures, and the associated data is used to constrain the types of information for which the trust anchor is authoritative.
信任锚通过公钥和相关数据表示权威实体。公钥用于验证数字签名，关联数据用于约束信任锚具有权威性的信息类型。
A trust anchor store is a set of one or more trust anchors stored
in a device.... A device may have more than one trust anchor
store, each of which may be used by one or more applications.
A trust anchor store is a set of one or more trust anchors stored
in a device.... A device may have more than one trust anchor
store, each of which may be used by one or more applications.
The TLS protocol [RFC5246] provides authenticated, confidentiality-and integrity-protected communication between two endpoints. The protocol is composed of two layers: the Record Protocol and the handshaking protocols. At the lowest level, layered on top of a reliable transport protocol (e.g., TCP), is the Record Protocol. It provides connection security by using symmetric cryptography for confidentiality, data origin authentication, and integrity protection. The Record Protocol is used for encapsulation of various higher-level protocols. The handshaking protocols consist of three subprotocols -- namely, the handshake protocol, the change cipher spec protocol, and the alert protocol. The handshake protocol allows the server and client to authenticate each other and to negotiate an encryption algorithm and cryptographic keys before the application protocol transmits or receives data.
TLS协议[RFC5246]在两个端点之间提供经过身份验证、机密性和完整性保护的通信。该协议由两层组成：记录协议和握手协议。在最底层，在可靠传输协议（如TCP）之上分层的是记录协议。它通过使用对称加密来实现机密性、数据源身份验证和完整性保护，从而提供连接安全性。记录协议用于封装各种高级协议。握手协议由三个子协议组成，即握手协议、更改密码规范协议和警报协议。握手协议允许服务器和客户端在应用程序协议发送或接收数据之前相互验证并协商加密算法和加密密钥。
The design of DTLS [RFC6347] is intentionally very similar to TLS. However, since DTLS operates on top of an unreliable datagram transport, it must explicitly cope with the absence of reliable and ordered delivery assumptions made by TLS. RFC 6347 explains these differences in great detail. As a short summary, for those not familiar with DTLS, the differences are:
DTLS[RFC6347]的设计有意与TLS非常相似。然而，由于DTL在不可靠的数据报传输上运行，它必须明确地处理TLS所做的可靠和有序交付假设的缺失。RFC6347非常详细地解释了这些差异。作为一个简短的总结，对于那些不熟悉DTL的人来说，区别在于：
o An explicit sequence number and an epoch field is included in the Record Protocol. Section 4.1 of RFC 6347 explains the processing rules for these two new fields. The value used to compute the Message Authentication Code (MAC) is the 64-bit value formed by concatenating the epoch and the sequence number.
o 记录协议中包含一个显式序列号和一个历元字段。RFC 6347的第4.1节解释了这两个新字段的处理规则。用于计算消息认证码（MAC）的值是通过连接历元和序列号形成的64位值。
o Stream ciphers must not be used with DTLS. The only stream cipher defined for TLS 1.2 is RC4, and due to cryptographic weaknesses, it is not recommended anymore even for use with TLS [RFC7465]. Note that the term "stream cipher" is a technical term in the TLS specification. Section 4.7 of RFC 5246 defines stream ciphers in TLS as follows: "In stream cipher encryption, the plaintext is exclusive-ORed with an identical amount of output generated from a cryptographically secure keyed pseudorandom number generator."
o 流密码不能与DTL一起使用。为TLS 1.2定义的唯一流密码是RC4，并且由于密码弱点，不再建议将其用于TLS[RFC7465]。注意，术语“流密码”是TLS规范中的技术术语。RFC 5246第4.7节对TLS中的流密码定义如下：“在流密码加密中，明文与加密安全密钥伪随机数生成器生成的相同数量的输出进行异或运算。”
o The TLS handshake protocol has been enhanced to include a stateless cookie exchange for Denial-of-Service (DoS) resistance. For this purpose, a new handshake message, the HelloVerifyRequest, was added to DTLS. This handshake message is sent by the server and includes a stateless cookie, which is returned in a ClientHello message back to the server. Although the exchange is optional for the server to execute, a client implementation has to be prepared to respond to it. Furthermore, the handshake message format has been extended to deal with message loss, reordering, and fragmentation.
o TLS握手协议已得到增强，包括无状态cookie交换以抵抗拒绝服务（DoS）。为此，向DTLS添加了一条新的握手消息HelloVerifyRequest。此握手消息由服务器发送，并包含一个无状态cookie，该cookie在ClientHello消息中返回给服务器。虽然exchange对于服务器来说是可选的，但是必须准备一个客户端实现来响应它。此外，握手消息格式已被扩展以处理消息丢失、重新排序和碎片。
This document describes a profile of DTLS and, to be useful, it has to make assumptions about the envisioned communication architecture.
本文档描述了DTL的概要，为了有用，它必须对设想的通信体系结构进行假设。
Two communication architectures (and consequently two profiles) are described in this document.
本文档中描述了两种通信体系结构（以及两种配置文件）。
The communication architecture shown in Figure 1 assumes a unicast communication interaction with an IoT device utilizing a constrained TLS/DTLS client interacting with one or multiple TLS/DTLS servers.
图1所示的通信体系结构假设与物联网设备进行单播通信交互，该设备利用与一个或多个TLS/DTLS服务器交互的受限TLS/DTLS客户端。
Before a client can initiate the TLS/DTLS handshake, it needs to know the IP address of that server and what credentials to use. Application-layer protocols, such as CoAP, which is conveyed on top of DTLS, may be configured with URIs of the endpoints to which CoAP needs to register and publish data. This configuration information (including non-confidential credentials, like certificates) may be conveyed to clients as part of a firmware/software package or via a configuration protocol. The following credential types are supported by this profile:
在客户端可以启动TLS/DTLS握手之前，它需要知道该服务器的IP地址以及要使用的凭据。应用层协议，例如在DTL之上传输的CoAP，可以使用CoAP需要注册和发布数据的端点的URI进行配置。该配置信息（包括非机密凭证，如证书）可作为固件/软件包的一部分或通过配置协议传送给客户端。此配置文件支持以下凭据类型：
o For authentication based on the Pre-Shared Key (PSK) (see Section 4.2), this includes the paired "PSK identity" and shared secret to be used with each server.
o 对于基于预共享密钥（PSK）的身份验证（参见第4.2节），这包括与每个服务器一起使用的成对“PSK标识”和共享密钥。
o For authentication based on the raw public key (see Section 4.3), this includes either the server's public key or the hash of the server's public key.
o 对于基于原始公钥的身份验证（参见第4.3节），这包括服务器公钥或服务器公钥的哈希。
o For certificate-based authentication (see Section 4.4), this includes a pre-populated trust anchor store that allows the DTLS stack to perform path validation for the certificate obtained during the handshake with the server.
o 对于基于证书的身份验证（请参见第4.4节），这包括一个预填充的信任锚存储，它允许DTLS堆栈对在与服务器握手期间获得的证书执行路径验证。
Figure 1 shows example configuration information stored at the constrained client for use with respective servers.
图1显示了存储在受约束客户机上的用于各个服务器的配置信息示例。
This document focuses on the description of the DTLS client-side functionality but, quite naturally, the equivalent server-side support has to be available.
本文档重点介绍DTLS客户端功能，但很自然，必须提供等效的服务器端支持。
+////////////////////////////////////+
| Configuration |
|////////////////////////////////////|
| Server A --> PSK Identity, PSK |
| |
| Server B --> Public Key (Server B),|
| Public/Private Key |
| (for Client) |
| |
| Server C --> Public/Private Key |
| (for Client) |
| Trust Anchor Store |
+------------------------------------+
oo
oooooo
o
+-----------+
|Constrained|
|TLS/DTLS |
|Client |-
+-----------+ \
\ ,-------.
,' `. +------+
/ IP-Based \ |Server|
( Network ) | A |
\ / +------+
`. ,'
'---+---' +------+
| |Server|
| | B |
| +------+
|
| +------+
+----------------->|Server|
| C |
+------+
+////////////////////////////////////+
| Configuration |
|////////////////////////////////////|
| Server A --> PSK Identity, PSK |
| |
| Server B --> Public Key (Server B),|
| Public/Private Key |
| (for Client) |
| |
| Server C --> Public/Private Key |
| (for Client) |
| Trust Anchor Store |
+------------------------------------+
oo
oooooo
o
+-----------+
|Constrained|
|TLS/DTLS |
|Client |-
+-----------+ \
\ ,-------.
,' `. +------+
/ IP-Based \ |Server|
( Network ) | A |
\ / +------+
`. ,'
'---+---' +------+
| |Server|
| | B |
| +------+
|
| +------+
+----------------->|Server|
| C |
+------+
Figure 1: Constrained Client Profile
图1：受约束的客户端概要文件
Reuse is a recurring theme when considering constrained environments and is behind a lot of the directions taken in developments for constrained environments. The corollary of reuse is to not add functionality if it can be avoided. An example relevant to the use of TLS is network access authentication, which takes place when a device connects to a network and needs to go through an authentication and access control procedure before it is allowed to communicate with other devices or connect to the Internet.
在考虑受约束的环境时，重用是一个反复出现的主题，并且是受约束环境开发中采取的许多方向的背后。重用的必然结果是，如果可以避免，就不要添加功能。与TLS的使用相关的一个示例是网络访问认证，当设备连接到网络时发生，并且在允许其与其他设备通信或连接到Internet之前需要经历认证和访问控制过程。
Figure 2 shows the network access architecture with the IoT device initiating the communication to an access point in the network using the procedures defined for a specific physical layer. Since credentials may be managed and stored centrally, in the Authentication, Authorization, and Accounting (AAA) server, the security protocol exchange may need to be relayed via the Authenticator, i.e., functionality running on the access point to the AAA server. The authentication and key exchange protocol itself is encapsulated within a container, the Extensible Authentication Protocol (EAP) [RFC3748], and messages are conveyed back and forth between the EAP endpoints, namely the EAP peer located on the IoT device and the EAP server located on the AAA server or the access point. To route EAP messages from the access point, acting as a AAA client, to the AAA server requires an adequate protocol mechanism, namely RADIUS [RFC2865] or Diameter [RFC6733].
图2显示了网络接入架构，其中物联网设备使用为特定物理层定义的程序启动与网络中接入点的通信。由于凭证可以集中管理和存储在认证、授权和计费（AAA）服务器中，因此安全协议交换可能需要通过认证器中继，即，在AAA服务器的接入点上运行的功能。认证和密钥交换协议本身封装在容器中，可扩展认证协议（EAP）[RFC3748]，消息在EAP端点之间来回传输，即位于物联网设备上的EAP对等方和位于AAA服务器或接入点上的EAP服务器。要将EAP消息从作为AAA客户端的接入点路由到AAA服务器，需要适当的协议机制，即RADIUS[RFC2865]或Diameter[RFC6733]。
More details about the concepts and a description about the terminology can be found in RFC 5247 [RFC5247].
有关概念和术语说明的更多详细信息，请参见RFC 5247[RFC5247]。
+--------------+
|Authentication|
|Authorization |
|Accounting |
|Server |
|(EAP Server) |
| |
+-^----------^-+
* EAP o RADIUS/
* o Diameter
--v----------v--
/// \\\
// \\
| Federation |
| Substrate |
\\ //
\\\ ///
--^----------^--
* EAP o RADIUS/
* o Diameter
+-------------+ +-v----------v--+
| | EAP/EAP Method | |
| Internet of |<***************************>| Access Point |
| Things | |(Authenticator)|
| Device | EAP Lower Layer and |(AAA Client) |
| (EAP Peer) | Secure Association Protocol | |
| |<--------------------------->| |
| | | |
| | Physical Layer | |
| |<===========================>| |
+-------------+ +---------------+
Legend:
+--------------+
|Authentication|
|Authorization |
|Accounting |
|Server |
|(EAP Server) |
| |
+-^----------^-+
* EAP o RADIUS/
* o Diameter
--v----------v--
/// \\\
// \\
| Federation |
| Substrate |
\\ //
\\\ ///
--^----------^--
* EAP o RADIUS/
* o Diameter
+-------------+ +-v----------v--+
| | EAP/EAP Method | |
| Internet of |<***************************>| Access Point |
| Things | |(Authenticator)|
| Device | EAP Lower Layer and |(AAA Client) |
| (EAP Peer) | Secure Association Protocol | |
| |<--------------------------->| |
| | | |
| | Physical Layer | |
| |<===========================>| |
+-------------+ +---------------+
Legend:
<****>: Device-to-AAA-Server Exchange
<---->: Device-to-Authenticator Exchange
<oooo>: AAA-Client-to-AAA-Server Exchange
<====>: Physical layer like IEEE 802.11/802.15.4
<****>: Device-to-AAA-Server Exchange
<---->: Device-to-Authenticator Exchange
<oooo>: AAA-Client-to-AAA-Server Exchange
<====>: Physical layer like IEEE 802.11/802.15.4
Figure 2: Network Access Architecture
图2：网络访问架构
One standardized EAP method is EAP-TLS, defined in RFC 5216 [RFC5216], which reuses the TLS-based protocol exchange and encapsulates it inside the EAP payload. In terms of reuse, this allows many components of the TLS protocol to be shared between the network access security functionality and the TLS functionality needed for securing application-layer traffic. In the EAP-TLS exchange shown in Figure 3, the IoT device as the EAP peer acts as a TLS client.
一种标准化的EAP方法是RFC 5216[RFC5216]中定义的EAP-TLS，它重用基于TLS的协议交换，并将其封装在EAP有效负载内。就重用而言，这允许在网络访问安全功能和保护应用层通信所需的TLS功能之间共享TLS协议的许多组件。在图3所示的EAP-TLS交换中，作为EAP对等方的IoT设备充当TLS客户端。
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/
Identity
EAP-Response/
Identity (MyID) ->
<- EAP-Request/
EAP-Type=EAP-TLS
(TLS Start)
EAP-Response/
EAP-Type=EAP-TLS
(TLS client_hello)->
<- EAP-Request/
EAP-Type=EAP-TLS
(TLS server_hello,
TLS certificate,
[TLS server_key_exchange,]
TLS certificate_request,
TLS server_hello_done)
EAP-Response/
EAP-Type=EAP-TLS
(TLS certificate,
TLS client_key_exchange,
TLS certificate_verify,
TLS change_cipher_spec,
TLS finished) ->
<- EAP-Request/
EAP-Type=EAP-TLS
(TLS change_cipher_spec,
TLS finished)
EAP-Response/
EAP-Type=EAP-TLS ->
<- EAP-Success
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/
Identity
EAP-Response/
Identity (MyID) ->
<- EAP-Request/
EAP-Type=EAP-TLS
(TLS Start)
EAP-Response/
EAP-Type=EAP-TLS
(TLS client_hello)->
<- EAP-Request/
EAP-Type=EAP-TLS
(TLS server_hello,
TLS certificate,
[TLS server_key_exchange,]
TLS certificate_request,
TLS server_hello_done)
EAP-Response/
EAP-Type=EAP-TLS
(TLS certificate,
TLS client_key_exchange,
TLS certificate_verify,
TLS change_cipher_spec,
TLS finished) ->
<- EAP-Request/
EAP-Type=EAP-TLS
(TLS change_cipher_spec,
TLS finished)
EAP-Response/
EAP-Type=EAP-TLS ->
<- EAP-Success
Figure 3: EAP-TLS Exchange
图3:EAP-TLS交换
The guidance in this document also applies to the use of EAP-TLS for network access authentication. An IoT device using a network access authentication solution based on TLS can reuse most parts of the code for the use of DTLS/TLS at the application layer, thereby saving a significant amount of flash memory. Note, however, that the credentials used for network access authentication and those used for application-layer security are very likely different.
本文件中的指南也适用于使用EAP-TLS进行网络访问认证。使用基于TLS的网络访问认证解决方案的IoT设备可以在应用层重用DTL/TLS使用的大部分代码，从而节省大量闪存。但是，请注意，用于网络访问身份验证的凭据和用于应用程序层安全性的凭据很可能不同。
When a constrained client uploads sensor data to a server infrastructure, it may use CoAP by pushing the data via a POST message to a preconfigured endpoint on the server. In certain circumstances, this might be too limiting and additional functionality is needed, as shown in Figures 4 and 5, where the IoT device itself runs a CoAP server hosting the resource that is made accessible to other entities. Despite running a CoAP server on the IoT device, it is still the DTLS client on the IoT device that initiates the interaction with the non-constrained resource server in our scenario.
当受约束的客户端将传感器数据上传到服务器基础设施时，它可以通过POST消息将数据推送到服务器上的预配置端点来使用CoAP。在某些情况下，这可能过于有限，需要额外的功能，如图4和图5所示，其中物联网设备本身运行承载其他实体可以访问的资源的CoAP服务器。尽管在物联网设备上运行CoAP服务器，但在我们的场景中，启动与非受限资源服务器交互的仍然是物联网设备上的DTLS客户端。
Figure 4 shows a sensor starting a DTLS exchange with a resource directory and uses CoAP to register available resources in Figure 5. [CoRE-RD] defines the resource directory (RD) as a web entity that stores information about web resources and implements Representational State Transfer (REST) interfaces for registration and lookup of those resources. Note that the described exchange is borrowed from the Open Mobile Alliance (OMA) Lightweight Machine-to-Machine (LWM2M) specification [LWM2M] that uses RD but adds proxy functionality.
图4显示了一个传感器使用资源目录启动DTLS交换，并使用CoAP注册图5中的可用资源。[CoRE RD]将资源目录（RD）定义为一个web实体，它存储有关web资源的信息，并实现用于注册和查找这些资源的代表性状态转移（REST）接口。请注意，所描述的交换借用了开放移动联盟（OMA）轻量级机器对机器（LWM2M）规范[LWM2M]，该规范使用RD，但添加了代理功能。
The initial DTLS interaction between the sensor, acting as a DTLS client, and the resource directory, acting as a DTLS server, will be a full DTLS handshake. Once this handshake is complete, both parties have established the DTLS record layer. Subsequently, the CoAP client can securely register at the resource directory.
传感器（充当DTLS客户端）和资源目录（充当DTLS服务器）之间的初始DTLS交互将是完整的DTLS握手。一旦握手完成，双方就建立了DTLS记录层。随后，CoAP客户端可以安全地在资源目录中注册。
After some time (assuming that the client regularly refreshes its registration), the resource directory receives a request from an application to retrieve the temperature information from the sensor. This request is relayed by the resource directory to the sensor using a GET message exchange. The already established DTLS record layer can be used to secure the message exchange.
一段时间后（假设客户机定期刷新其注册），资源目录收到来自应用程序的请求，以从传感器检索温度信息。该请求由资源目录使用GET消息交换转发给传感器。已经建立的DTLS记录层可用于保护消息交换。
Resource
Sensor Directory
------ ---------
Resource
Sensor Directory
------ ---------
+---
|
| ClientHello -------->
| #client_certificate_type#
F| #server_certificate_type#
U|
L| <------- HelloVerifyRequest
L|
| ClientHello -------->
D| #client_certificate_type#
T| #server_certificate_type#
L|
S| ServerHello
| #client_certificate_type#
H| #server_certificate_type#
A| Certificate
N| ServerKeyExchange
D| CertificateRequest
S| <-------- ServerHelloDone
H|
A| Certificate
K| ClientKeyExchange
E| CertificateVerify
| [ChangeCipherSpec]
| Finished -------->
|
| [ChangeCipherSpec]
| <-------- Finished
+---
+---
|
| ClientHello -------->
| #client_certificate_type#
F| #server_certificate_type#
U|
L| <------- HelloVerifyRequest
L|
| ClientHello -------->
D| #client_certificate_type#
T| #server_certificate_type#
L|
S| ServerHello
| #client_certificate_type#
H| #server_certificate_type#
A| Certificate
N| ServerKeyExchange
D| CertificateRequest
S| <-------- ServerHelloDone
H|
A| Certificate
K| ClientKeyExchange
E| CertificateVerify
| [ChangeCipherSpec]
| Finished -------->
|
| [ChangeCipherSpec]
| <-------- Finished
+---
Note: Extensions marked with "#" were introduced with RFC 7250.
注：RFC 7250引入了标有“#”的扩展。
Figure 4: DTLS/CoAP Exchange Using Resource Directory:
Part 1 -- DTLS Handshake
Figure 4: DTLS/CoAP Exchange Using Resource Directory:
Part 1 -- DTLS Handshake
Figure 5 shows the DTLS-secured communication between the sensor and the resource directory using CoAP.
图5显示了使用CoAP在传感器和资源目录之间进行的DTLS安全通信。
Resource
Sensor Directory
------ ---------
Resource
Sensor Directory
------ ---------
[[==============DTLS-Secured Communication===================]]
[[==============DTLS-Secured Communication===================]]
+--- ///+
C| \ D
O| Req: POST coap://rd.example.com/rd?ep=node1 \ T
A| Payload: \ L
P| </temp>;ct=41; \ S
| rt="temperature-c";if="sensor", \
R| </light>;ct=41; \ R
D| rt="light-lux";if="sensor" \ E
| --------> \ C
R| \ O
E| \ R
G| Res: 2.01 Created \ D
| <-------- Location: /rd/4521 \
| \ L
+--- \ A
\ Y
* \ E
* (time passes) \ R
* \
+--- \ P
C| \ R
O| Req: GET coaps://sensor.example.com/temp \ O
A| <-------- \ T
P| \ E
| Res: 2.05 Content \ C
G| Payload: \ T
E| 25.5 --------> \ E
T| \ D
+--- ///+
+--- ///+
C| \ D
O| Req: POST coap://rd.example.com/rd?ep=node1 \ T
A| Payload: \ L
P| </temp>;ct=41; \ S
| rt="temperature-c";if="sensor", \
R| </light>;ct=41; \ R
D| rt="light-lux";if="sensor" \ E
| --------> \ C
R| \ O
E| \ R
G| Res: 2.01 Created \ D
| <-------- Location: /rd/4521 \
| \ L
+--- \ A
\ Y
* \ E
* (time passes) \ R
* \
+--- \ P
C| \ R
O| Req: GET coaps://sensor.example.com/temp \ O
A| <-------- \ T
P| \ E
| Res: 2.05 Content \ C
G| Payload: \ T
E| 25.5 --------> \ E
T| \ D
+--- ///+
Figure 5: DTLS/CoAP Exchange Using Resource Directory:
Part 2 -- CoAP/RD Exchange
Figure 5: DTLS/CoAP Exchange Using Resource Directory:
Part 2 -- CoAP/RD Exchange
Note that the CoAP GET message transmitted from the resource server is protected using the previously established DTLS record layer.
请注意，从资源服务器传输的CoAP GET消息使用先前建立的DTLS记录层进行保护。
Section 3.2.1 illustrates a deployment model where the TLS/DTLS client is constrained and efforts need to be taken to improve memory utilization, bandwidth consumption, reduce performance impacts, etc. In this section, we assume a scenario where constrained devices run TLS/DTLS servers to secure access to application-layer services running on top of CoAP, HTTP, or other protocols. Figure 6 illustrates a possible deployment whereby a number of constrained servers are waiting for regular clients to access their resources. The entire process is likely, but not necessarily, controlled by a third party, the authentication and authorization server. This authentication and authorization server is responsible for holding authorization policies that govern the access to resources and distribution of keying material.
第3.2.1节说明了一个部署模型，其中TLS/DTLS客户端受到限制，需要采取措施提高内存利用率、带宽消耗、降低性能影响等。在本节中，我们假设一个场景，受约束的设备运行TLS/DTLS服务器，以确保对运行在CoAP、HTTP或其他协议之上的应用层服务的访问。图6说明了一种可能的部署，其中许多受约束的服务器正在等待常规客户端访问其资源。整个过程可能（但不一定）由第三方（身份验证和授权服务器）控制。此身份验证和授权服务器负责保存控制对资源的访问和密钥材料分发的授权策略。
+////////////////////////////////////+
| Configuration |
|////////////////////////////////////|
| Credentials |
| Client A -> Public Key |
| Server S1 -> Symmetric Key |
| Server S2 -> Certificate |
| Server S3 -> Public Key |
| Trust Anchor Store |
| Access Control Lists |
| Resource X: Client A / GET |
| Resource Y: Client A / PUT |
+------------------------------------+
oo
oooooo
o
+---------------+ +-----------+
|Authentication | +-------->|TLS/DTLS |
|& Authorization| | |Client A |
|Server | | +-----------+
+---------------+ ++
^ | +-----------+
\ | |Constrained|
\ ,-------. | Server S1 |
,' `. +-----------+
/ Local \
( Network )
\ / +-----------+
`. ,' |Constrained|
'---+---' | Server S2 |
| +-----------+
|
| +-----------+
+-----------------> |Constrained|
| Server S3 |
+-----------+
+////////////////////////////////////+
| Configuration |
|////////////////////////////////////|
| Credentials |
| Client A -> Public Key |
| Server S1 -> Symmetric Key |
| Server S2 -> Certificate |
| Server S3 -> Public Key |
| Trust Anchor Store |
| Access Control Lists |
| Resource X: Client A / GET |
| Resource Y: Client A / PUT |
+------------------------------------+
oo
oooooo
o
+---------------+ +-----------+
|Authentication | +-------->|TLS/DTLS |
|& Authorization| | |Client A |
|Server | | +-----------+
+---------------+ ++
^ | +-----------+
\ | |Constrained|
\ ,-------. | Server S1 |
,' `. +-----------+
/ Local \
( Network )
\ / +-----------+
`. ,' |Constrained|
'---+---' | Server S2 |
| +-----------+
|
| +-----------+
+-----------------> |Constrained|
| Server S3 |
+-----------+
Figure 6: Constrained Server Profile
图6：受约束的服务器配置文件
A deployment with constrained servers has to overcome several challenges. Below we explain how these challenges can be solved with CoAP, as an example. Other protocols may offer similar capabilities. While the requirements for the TLS/DTLS protocol profile change only slightly when run on a constrained server (in comparison to running it on a constrained client), several other ecosystem factors will impact deployment.
使用受限服务器的部署必须克服几个挑战。下面我们以CoAP为例解释如何解决这些挑战。其他协议可能提供类似的功能。虽然TLS/DTLS协议概要文件的要求在受约束的服务器上运行时仅发生轻微变化（与在受约束的客户端上运行相比），但其他几个生态系统因素将影响部署。
There are several challenges that need to be addressed:
有几个挑战需要解决：
Discovery and Reachability:
发现和可达性：
A client must first and foremost discover the server before initiating a connection to it. Once it has been discovered, reachability to the device needs to be maintained.
客户端必须首先发现服务器，然后才能启动与服务器的连接。一旦被发现，需要保持设备的可达性。
In CoAP, the discovery of resources offered by servers is accomplished by sending a unicast or multicast CoAP GET to a well-known URI. The Constrained RESTful Environments (CoRE) Link Format specification [RFC6690] describes the use case (see Section 1.2.1) and reserves the URI (see Section 7.1). Section 7 of the CoAP specification [RFC7252] describes the discovery procedure. [RFC7390] describes the use case for discovering CoAP servers using multicast (see Section 3.3) and specifies the protocol processing rules for CoAP group communications (see Section 2.7).
在CoAP中，服务器提供的资源的发现是通过将单播或多播CoAP GET发送到已知的URI来完成的。受限RESTful环境（CoRE）链接格式规范[RFC6690]描述了用例（参见第1.2.1节）并保留了URI（参见第7.1节）。CoAP规范[RFC7252]第7节描述了发现程序。[RFC7390]描述了使用多播发现CoAP服务器的用例（参见第3.3节），并指定了CoAP组通信的协议处理规则（参见第2.7节）。
The use of RD [CoRE-RD] is yet another possibility for discovering registered servers and their resources. Since RD is usually not a proxy, clients can discover links registered with the RD and then access them directly.
使用RD[核心RD]是发现已注册服务器及其资源的另一种可能性。由于RD通常不是代理，所以客户端可以发现在RD注册的链接，然后直接访问它们。
Authentication:
身份验证：
The next challenge concerns the provisioning of authentication credentials to the clients as well as servers. In Section 3.2.1, we assume that credentials (and other configuration information) are provisioned to the device, and that those can be used with the authorization servers. Of course, this leads to a very static relationship between the clients and their server-side infrastructure but poses fewer challenges from a deployment point of view, as described in Section 2 of [RFC7452]. In any case, engineers and product designers have to determine how the relevant credentials are distributed to the respective parties. For example, shared secrets may need to be provisioned to clients and the constrained servers for subsequent use of TLS/DTLS PSK. In other deployments, certificates, private keys, and trust anchors for use with certificate-based authentication may need to be utilized.
下一个挑战涉及向客户端和服务器提供身份验证凭据。在第3.2.1节中，我们假设已向设备提供凭据（和其他配置信息），并且这些凭据可以与授权服务器一起使用。当然，这会导致客户机与其服务器端基础设施之间的关系非常静态，但从部署的角度来看，挑战较少，如[RFC7452]第2节所述。在任何情况下，工程师和产品设计师必须确定如何将相关凭证分发给各方。例如，可能需要向客户端和受约束的服务器提供共享机密，以便后续使用TLS/DTLS PSK。在其他部署中，可能需要使用用于基于证书的身份验证的证书、私钥和信任锚。
Practical solutions use either pairing (also called imprinting) or a trusted third party. With pairing, two devices execute a special protocol exchange that is unauthenticated to establish a shared key (for example, using an unauthenticated Diffie-Hellman (DH) exchange). To avoid man-in-the-middle attacks, an out-of-band channel is used to verify that nobody has tampered
实用的解决方案使用配对（也称为印记）或可信的第三方。通过配对，两台设备执行未经验证的特殊协议交换以建立共享密钥（例如，使用未经验证的Diffie-Hellman（DH）交换）。为了避免中间人攻击，使用带外通道验证没有人篡改
with the exchanged protocol messages. This out-of-band channel can come in many forms, including:
使用交换的协议消息。这种带外信道可以有多种形式，包括：
* Human involvement by comparing hashed keys, entering passkeys, and scanning QR codes
* 通过比较散列键、输入密钥和扫描QR码，人类参与
* The use of alternative wireless communication channels (e.g., infrared communication in addition to Wi-Fi)
* 使用替代无线通信信道（例如，除了Wi-Fi之外的红外通信）
* Proximity-based information
* 基于邻近性的信息
More details about these different pairing/imprinting techniques can be found in the Smart Object Security Workshop report [RFC7397] and various position papers submitted on that topic, such as [ImprintingSurvey]. The use of a trusted third party follows a different approach and is subject to ongoing standardization efforts in the Authentication and Authorization for Constrained Environments (ACE) working group [ACE-WG].
有关这些不同配对/印记技术的更多详细信息，请参阅智能对象安全研讨会报告[RFC7397]和就此主题提交的各种立场文件，如[ImpringSurvey]。受信任第三方的使用遵循不同的方法，并取决于受限环境认证和授权（ACE）工作组[ACE-WG]正在进行的标准化工作。
Authorization
批准
The last challenge is the ability for the constrained server to make an authorization decision when clients access protected resources. Pre-provisioning access control information to constrained servers may be one option but works only in a small scale, less dynamic environment. For a finer-grained and more dynamic access control solution, the reader is referred to the ongoing work in the IETF ACE working group.
最后一个挑战是受约束的服务器在客户端访问受保护的资源时做出授权决策的能力。将访问控制信息预调配到受约束的服务器可能是一种选择，但仅适用于小规模、动态性较差的环境。对于更细粒度和更动态的访问控制解决方案，读者可以参考IETF ACE工作组正在进行的工作。
Figure 7 shows an example interaction whereby a device, a thermostat in our case, searches in the local network for discoverable resources and accesses those. The thermostat starts the procedure using a link-local discovery message using the "All CoAP Nodes" multicast address by utilizing the link format per RFC 6690 [RFC6690]. The IPv6 multicast address used for CoAP link-local discovery is FF02::FD. As a result, a temperature sensor and a fan respond. These responses allow the thermostat to subsequently read temperature information from the temperature sensor with a CoAP GET request issued to the previously learned endpoint. In this example we assume that accessing the temperature sensor readings and controlling the fan requires authentication and authorization of the thermostat and TLS is used to authenticate both endpoints and to secure the communication.
图7显示了一个交互示例，在此示例中，一个设备（本例中的恒温器）在本地网络中搜索可发现的资源并访问这些资源。恒温器通过使用RFC 6690[RFC6690]规定的链路格式，使用“所有CoAP节点”多播地址，使用链路本地发现消息启动程序。用于CoAP链路本地发现的IPv6多播地址为FF02:：FD。因此，温度传感器和风扇会做出响应。这些响应允许恒温器随后从温度传感器读取温度信息，并向先前读入的端点发出CoAP GET请求。在本例中，我们假设访问温度传感器读数和控制风扇需要恒温器的认证和授权，TLS用于认证两个端点并保护通信。
Temperature
Thermostat Sensor Fan
---------- --------- ---
Temperature
Thermostat Sensor Fan
---------- --------- ---
Discovery
-------------------->
GET coap://[FF02::FD]/.well-known/core
Discovery
-------------------->
GET coap://[FF02::FD]/.well-known/core
CoAP 2.05 Content
<-------------------------------
</3303/0/5700>;rt="temperature";
if="sensor"
CoAP 2.05 Content
<-------------------------------
</3303/0/5700>;rt="temperature";
if="sensor"
CoAP 2.05 Content
<--------------------------------------------------
</fan>;rt="fan";if="actuation"
CoAP 2.05 Content
<--------------------------------------------------
</fan>;rt="fan";if="actuation"
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
\ Protocol steps to obtain access token or keying /
\ material for access to the temperature sensor and fan. /
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
\ Protocol steps to obtain access token or keying /
\ material for access to the temperature sensor and fan. /
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
Read Sensor Data
(authenticated/authorized)
------------------------------->
GET /3303/0/5700
Read Sensor Data
(authenticated/authorized)
------------------------------->
GET /3303/0/5700
CoAP 2.05 Content
<-------------------------------
22.5 C
CoAP 2.05 Content
<-------------------------------
22.5 C
Configure Actuator
(authenticated/authorized)
------------------------------------------------->
PUT /fan?on-off=true
CoAP 2.04 Changed
<-------------------------------------------------
Configure Actuator
(authenticated/authorized)
------------------------------------------------->
PUT /fan?on-off=true
CoAP 2.04 Changed
<-------------------------------------------------
Figure 7: Local Discovery and Resource Access
图7：本地发现和资源访问
TLS (and consequently DTLS) support ciphersuites, and an IANA registry [IANA-TLS] was created to register the suites. A ciphersuite (and the specification that defines it) contains the following information:
TLS（因此DTL）支持密码套件，并创建了IANA注册表[IANA-TLS]来注册套件。密码套件（以及定义它的规范）包含以下信息：
o Authentication and key exchange algorithm (e.g., PSK)
o 身份验证和密钥交换算法（如PSK）
o Cipher and key length (e.g., Advanced Encryption Standard (AES) with 128-bit keys [AES])
o 密码和密钥长度（例如，具有128位密钥[AES]的高级加密标准（AES））
o Mode of operation (e.g., Counter with CBC-MAC (CCM) mode for AES) [RFC3610]
o 操作模式（例如，AES使用CBC-MAC（CCM）模式的计数器）[RFC3610]
o Hash algorithm for integrity protection, such as the Secure Hash Algorithm (SHA) in combination with Keyed-Hashing for Message Authentication (HMAC) (see [RFC2104] and [RFC6234])
o 用于完整性保护的散列算法，例如安全散列算法（SHA）与用于消息身份验证的密钥散列（HMAC）相结合（请参见[RFC2104]和[RFC6234]）
o Hash algorithm for use with pseudorandom functions (e.g., HMAC with the SHA-256)
o 用于伪随机函数的哈希算法（例如，带有SHA-256的HMAC）
o Misc information (e.g., length of authentication tags)
o 杂项信息（例如，认证标签的长度）
o Information whether the ciphersuite is suitable for DTLS or only for TLS
o 密码套件是否适用于DTL或仅适用于TLS的信息
The TLS ciphersuite TLS_PSK_WITH_AES_128_CCM_8, for example, uses a pre-shared authentication and key exchange algorithm. [RFC6655] defines this ciphersuite. It uses the AES encryption algorithm, which is a block cipher. Since the AES algorithm supports different key lengths (such as 128, 192, and 256 bits), this information has to be specified as well, and the selected ciphersuite supports 128-bit keys. A block cipher encrypts plaintext in fixed-size blocks, and AES operates on a block size of 128 bits. For messages exceeding 128 bits, the message is partitioned into 128-bit blocks, and the AES cipher is applied to these input blocks with appropriate chaining, which is called mode of operation.
例如，TLS密码套件TLS_PSK_和_AES_128_CCM_8使用预共享身份验证和密钥交换算法。[RFC6655]定义此密码套件。它使用AES加密算法，这是一种分组密码。由于AES算法支持不同的密钥长度（例如128、192和256位），因此也必须指定此信息，并且选定的密码套件支持128位密钥。分组密码在固定大小的块中加密明文，AES对128位的块大小进行操作。对于超过128位的消息，消息被划分为128位块，AES密码通过适当的链接应用于这些输入块，这称为操作模式。
TLS 1.2 introduced Authenticated Encryption with Associated Data (AEAD) ciphersuites (see [RFC5116] and [RFC6655]). AEAD is a class of block cipher modes that encrypt (parts of) the message and authenticate the message simultaneously. AES-CCM [RFC6655] is an example of such a mode.
TLS 1.2引入了带有关联数据的认证加密（AEAD）密码套件（参见[RFC5116]和[RFC6655]）。AEAD是一类分组密码模式，可同时加密（部分）消息和验证消息。AES-CCM[RFC6655]就是这种模式的一个例子。
Some AEAD ciphersuites have shorter authentication tags (i.e., message authentication codes) and are therefore more suitable for networks with low bandwidth where small message size matters. The
一些AEAD密码套件具有较短的身份验证标签（即消息身份验证码），因此更适合于消息大小较小的低带宽网络。这个
TLS_PSK_WITH_AES_128_CCM_8 ciphersuite that ends in "_8" has an 8-octet authentication tag, while the regular CCM ciphersuites have, at the time of writing, 16-octet authentication tags. The design of CCM and the security properties are described in [CCM].
TLS_PSK_和以“_8”结尾的_AES_128_CCM_8密码套件具有8个八位字节的身份验证标签，而在编写本文时，常规CCM密码套件具有16个八位字节的身份验证标签。CCM的设计和安全特性在[CCM]中进行了描述。
TLS 1.2 also replaced the combination of MD5/SHA-1 hash functions in the TLS pseudorandom function (PRF) used in earlier versions of TLS with ciphersuite-specified PRFs. For this reason, authors of more recent TLS 1.2 ciphersuite specifications explicitly indicate the MAC algorithm and the hash functions used with the TLS PRF.
TLS 1.2还将TLS早期版本中使用的TLS伪随机函数（PRF）中MD5/SHA-1哈希函数的组合替换为密码套件指定的PRF。因此，最新的TLS 1.2 ciphersuite规范的作者明确指出了与TLS PRF一起使用的MAC算法和哈希函数。
The mandatory-to-implement functionality will depend on the credential type used with IoT devices. The subsections below describe the implications of three different credential types, namely pre-shared secrets, raw public keys, and certificates.
实施功能的强制性要求将取决于物联网设备使用的凭证类型。下面的小节描述了三种不同凭证类型的含义，即预共享机密、原始公钥和证书。
All exchanges described in the subsequent sections assume that some information has been distributed before the TLS/DTLS interaction starts. The credentials are used to authenticate the client to the server, and vice versa. What information items have to be distributed depends on the chosen credential types. In all cases, the IoT device needs to know what algorithms to prefer, particularly if there are multiple algorithm choices available as part of the implemented ciphersuites, as well as information about the other communication endpoint (for example, in the form of a URI) a particular credential has to be used with.
后续章节中描述的所有交换都假设在TLS/DTLS交互开始之前已经分发了一些信息。凭据用于向服务器验证客户端，反之亦然。必须分发哪些信息项取决于所选的凭据类型。在所有情况下，物联网设备都需要知道更喜欢什么算法，特别是当有多个算法选择作为所实现的密码套件的一部分可用时，以及关于必须与特定凭证一起使用的其他通信端点的信息（例如，以URI的形式）。
Pre-Shared Secrets: In this case, a shared secret together with an identifier needs to be made available to the device as well as to the other communication party.
预共享机密：在这种情况下，需要向设备以及其他通信方提供共享机密和标识符。
Raw Public Keys: A public key together with a private key are stored on the device and typically associated with some identifier. To authenticate the other communication party, the appropriate credential has to be known. If the other end uses raw public keys as well, then their public key needs to be provisioned (out of band) to the device.
原始公钥：公钥和私钥存储在设备上，通常与某个标识符关联。要认证另一通信方，必须知道相应的凭据。如果另一端也使用原始公钥，则需要将其公钥（带外）提供给设备。
Certificates: The use of certificates requires the device to store the public key (as part of the certificate) as well as the private key. The certificate will contain the identifier of the device as well as various other attributes. Both communication parties are assumed to be in possession of a trust anchor store that contains CA certificates and, in case of certificate pinning, end-entity
证书：证书的使用要求设备存储公钥（作为证书的一部分）和私钥。证书将包含设备的标识符以及各种其他属性。假定通信双方都拥有一个信任锚存储，该存储包含CA证书，在证书固定的情况下，还包含终端实体
certificates. Similar to the other credentials, the IoT device needs information about which entity to use which certificate with. Without a trust anchor store on the IoT device, it will not be possible to perform certificate validation.
证书。与其他凭证类似，IoT设备需要有关使用哪个证书的实体的信息。如果IoT设备上没有信任锚存储，则无法执行证书验证。
We call the above-listed information "device credentials" and these device credentials may be provisioned to the device already during the manufacturing time or later in the process, depending on the envisioned business and deployment model. These initial credentials are often called "root of trust". Whatever process is chosen for generating these initial device credentials, it MUST be ensured that a different key pair is provisioned for each device and installed in as secure a manner as possible. For example, it is preferable to generate public/private keys on the IoT device itself rather than generating them outside the device. Since an IoT device is likely to interact with various other parties, the initial device credential may only be used with some dedicated entities, and configuring further configuration and credentials to the device is left to a separate interaction. An example of a dedicated protocol used to distribute credentials, access control lists, and configure information is the LWM2M protocol [LWM2M].
我们将上面列出的信息称为“设备凭据”，这些设备凭据可能会在制造期间或稍后的过程中提供给设备，具体取决于设想的业务和部署模型。这些初始凭证通常称为“信任根”。无论选择哪个过程来生成这些初始设备凭据，都必须确保为每个设备提供不同的密钥对，并以尽可能安全的方式安装。例如，优选在IoT设备本身上生成公钥/私钥，而不是在设备外部生成它们。由于IoT设备可能与各种其他方交互，因此初始设备凭证可能仅与一些专用实体一起使用，并且将对设备的进一步配置和凭证的配置留给单独的交互。用于分发凭据、访问控制列表和配置信息的专用协议的一个示例是LWM2M协议[LWM2M]。
For all the credentials listed above, there is a chance that those may need to be replaced or deleted. While separate protocols have been developed to check the status of these credentials and to manage these credentials, such as the Trust Anchor Management Protocol (TAMP) [RFC5934], their usage is, however, not envisioned in the IoT context so far. IoT devices are assumed to have a software update mechanism built-in, and it will allow updates of low-level device information, including credentials and configuration parameters. This document does, however, not mandate a specific software/firmware update protocol.
对于上面列出的所有凭据，可能需要替换或删除这些凭据。虽然已经开发了单独的协议来检查这些凭证的状态并管理这些凭证，例如信任锚管理协议（TAMP）[RFC5934]，但是，到目前为止，在物联网上下文中还没有设想它们的使用。IoT设备被假定具有内置的软件更新机制，它将允许更新低级设备信息，包括凭证和配置参数。但是，本文件并不强制要求特定的软件/固件更新协议。
With all credentials used as input to TLS/DTLS authentication, it is important that these credentials have been generated with care. When using a pre-shared secret, a critical consideration is using sufficient entropy during the key generation, as discussed in [RFC4086]. Deriving a shared secret from a password, some device identifiers, or other low-entropy sources is not secure. A low-entropy secret, or password, is subject to dictionary attacks. Attention also has to be paid when generating public/private key pairs since the lack of randomness can result in the same key pair being used in many devices. This topic is also discussed in Section 12 since keys are generated during the TLS/DTLS exchange itself as well, and the same considerations apply.
由于所有凭据都用作TLS/DTLS身份验证的输入，因此生成这些凭据时务必小心。当使用预共享秘密时，关键考虑因素是在密钥生成期间使用足够的熵，如[RFC4086]中所述。从密码、某些设备标识符或其他低熵源派生共享秘密是不安全的。低熵秘密或密码会受到字典攻击。在生成公钥/私钥对时还必须注意，因为缺少随机性可能会导致在许多设备中使用相同的密钥对。第12节还讨论了此主题，因为密钥也是在TLS/DTLS交换过程中生成的，同样的注意事项也适用于此。
The use of pre-shared secrets is one of the most basic techniques for TLS/DTLS since it is both computationally efficient and bandwidth conserving. Authentication based on pre-shared secrets was introduced to TLS in RFC 4279 [RFC4279].
预共享秘密的使用是TLS/DTL最基本的技术之一，因为它既具有计算效率又节省带宽。RFC 4279[RFC4279]中向TLS引入了基于预共享秘密的身份验证。
Figure 8 illustrates the DTLS exchange including the cookie exchange. While the server is not required to initiate a cookie exchange with every handshake, the client is required to implement and to react on it when challenged, as defined in RFC 6347 [RFC6347]. The cookie exchange allows the server to react to flooding attacks.
图8说明了DTLS交换，包括cookie交换。虽然服务器不需要在每次握手时启动cookie交换，但客户机需要实现cookie交换，并在受到质询时做出反应，如RFC 6347[RFC6347]中所定义。cookie交换允许服务器对洪水攻击作出反应。
Client Server
------ ------
ClientHello -------->
Client Server
------ ------
ClientHello -------->
<-------- HelloVerifyRequest
(contains cookie)
<-------- HelloVerifyRequest
(contains cookie)
ClientHello -------->
(with cookie)
ServerHello
*ServerKeyExchange
<-------- ServerHelloDone
ClientKeyExchange
ChangeCipherSpec
Finished -------->
ChangeCipherSpec
<-------- Finished
ClientHello -------->
(with cookie)
ServerHello
*ServerKeyExchange
<-------- ServerHelloDone
ClientKeyExchange
ChangeCipherSpec
Finished -------->
ChangeCipherSpec
<-------- Finished
Application Data <-------> Application Data
Application Data <-------> Application Data
Legend:
图例：
* indicates an optional message payload
* 指示可选的消息负载
Figure 8: DTLS PSK Authentication Including the Cookie Exchange
图8:DTLS PSK身份验证，包括Cookie交换
Note that [RFC4279] used the term "PSK identity" to refer to the identifier used to refer to the appropriate secret. While "identifier" would be more appropriate in this context, we reuse the terminology defined in RFC 4279 to avoid confusion. RFC 4279 does not mandate the use of any particular type of PSK identity, and the client and server have to agree on the identities and keys to be used. The UTF-8 encoding of identities described in Section 5.1 of RFC 4279 aims to improve interoperability for those cases where the identity is configured by a human using some management interface
注意，[RFC4279]使用术语“PSK标识”来指代用于指代适当机密的标识符。虽然“标识符”在这种情况下更合适，但我们重用RFC 4279中定义的术语以避免混淆。RFC 4279不强制使用任何特定类型的PSK标识，客户端和服务器必须就要使用的标识和密钥达成一致。RFC 4279第5.1节中描述的身份UTF-8编码旨在改进由人员使用某些管理界面配置身份的情况下的互操作性
provided by a web browser. However, many IoT devices do not have a user interface, and most of their credentials are bound to the device rather than to the user. Furthermore, credentials are often provisioned into hardware modules or provisioned alongside with firmware. As such, the encoding considerations are not applicable to this usage environment. For use with this profile, the PSK identities SHOULD NOT assume a structured format (such as domain names, distinguished names, or IP addresses), and a byte-by-byte comparison operation MUST be used by the server for any operation related to the PSK identity. These types of identifiers are called "absolute" per RFC 6943 [RFC6943].
由web浏览器提供。然而，许多物联网设备没有用户界面，它们的大部分凭证都绑定到设备而不是用户。此外，凭据通常配置到硬件模块中，或者与固件一起配置。因此，编码注意事项不适用于此使用环境。与此配置文件一起使用时，PSK标识不应采用结构化格式（如域名、可分辨名称或IP地址），服务器必须对与PSK标识相关的任何操作使用逐字节比较操作。根据RFC 6943[RFC6943]，这些类型的标识符称为“绝对”。
Protocol-wise, the client indicates which key it uses by including a "PSK identity" in the ClientKeyExchange message. As described in Section 3.2, clients may have multiple pre-shared keys with a single server, for example, in a hosting context. The TLS Server Name Indication (SNI) extension allows the client to convey the name of the server it is contacting. A server implementation needs to guide the selection based on a received SNI value from the client.
在协议方面，客户端通过在ClientKeyExchange消息中包含“PSK标识”来指示它使用的密钥。如第3.2节所述，例如，在托管上下文中，客户端可能与单个服务器具有多个预共享密钥。TLS服务器名称指示（SNI）扩展允许客户端传递其正在联系的服务器的名称。服务器实现需要根据从客户端接收到的SNI值指导选择。
RFC 4279 requires TLS implementations supporting PSK ciphersuites to support arbitrary PSK identities up to 128 octets in length and arbitrary PSKs up to 64 octets in length. This is a useful assumption for TLS stacks used in the desktop and mobile environments where management interfaces are used to provision identities and keys. Implementations in compliance with this profile MAY use PSK identities up to 128 octets in length and arbitrary PSKs up to 64 octets in length. The use of shorter PSK identities is RECOMMENDED.
RFC 4279要求支持PSK密码套件的TLS实现支持长度最多为128个八位字节的任意PSK标识和长度最多为64个八位字节的任意PSK标识。对于桌面和移动环境中使用的TLS堆栈来说，这是一个有用的假设，在这些环境中，管理接口用于提供身份和密钥。符合此配置文件的实现可以使用长度最多为128个八位字节的PSK标识和长度最多为64个八位字节的任意PSK标识。建议使用较短的PSK标识。
"The Constrained Application Protocol (CoAP)" [RFC7252] currently specifies TLS_PSK_WITH_AES_128_CCM_8 as the mandatory-to-implement ciphersuite for use with shared secrets. This ciphersuite uses the AES algorithm with 128 bit keys and CCM as the mode of operation. The label "_8" indicates that an 8-octet authentication tag is used. Note that the shorted authentication tag increases the chance that an adversary with no knowledge of the secret key can present a message with a MAC that will pass the verification procedure. The likelihood of accepting forged data is explained in Section 5.3.5 of [SP800-107-rev1] and depends on the lengths of the authentication tag and allowed numbers of MAC verifications using a given key.
“受约束的应用程序协议（CoAP）”[RFC7252]目前将TLS_PSK_和_AES_128_CCM_8指定为实现用于共享机密的密码套件的强制要求。此密码套件使用具有128位密钥的AES算法和CCM作为操作模式。标签“_8”表示使用了8个八位字节的身份验证标签。请注意，短接的身份验证标签增加了不知道密钥的对手向通过验证过程的MAC提供消息的机会。[SP800-107-rev1]第5.3.5节解释了接受伪造数据的可能性，并取决于身份验证标签的长度和使用给定密钥进行MAC验证的允许次数。
This ciphersuite makes use of the default TLS 1.2 PRF, which uses an HMAC with the SHA-256 hash function. Note: Starting with TLS 1.2 (and consequently DTLS 1.2), ciphersuites have to specify the PRF. RFC 5246 states that "New cipher suites MUST explicitly specify a PRF and, in general, SHOULD use the TLS PRF with SHA-256 or a stronger standard hash function." The ciphersuites recommended in this document use the SHA-256 construct defined in Section 5 of RFC 5246.
此密码套件使用默认的TLS 1.2 PRF，它使用带有SHA-256哈希函数的HMAC。注意：从TLS 1.2（以及DTLS 1.2）开始，密码套件必须指定PRF。RFC 5246规定，“新密码套件必须明确指定PRF，通常应使用TLS PRF和SHA-256或更强大的标准哈希函数。”本文件中推荐的密码套件使用RFC 5246第5节中定义的SHA-256构造。
A device compliant with the profile in this section MUST implement TLS_PSK_WITH_AES_128_CCM_8 and follow the guidance from this section.
符合本节中配置文件的设备必须实现TLS_PSK_和_AES_128_CCM_8，并遵循本节的指导。
The use of raw public keys with TLS/DTLS, as defined in [RFC7250], is the first entry point into public key cryptography without having to pay the price of certificates and a public key infrastructure (PKI). The specification reuses the existing Certificate message to convey the raw public key encoded in the SubjectPublicKeyInfo structure. To indicate support, two new extensions had been defined, as shown in Figure 9, namely the server_certificate_type and the client_certificate_type.
[RFC7250]中定义的原始公钥与TLS/DTL的结合使用是公钥加密的第一个切入点，无需支付证书和公钥基础设施（PKI）的费用。该规范重用现有的证书消息来传递SubjectPublicKeyInfo结构中编码的原始公钥。为了表示支持，定义了两个新的扩展，如图9所示，即服务器证书类型和客户端证书类型。
Client Server
------ ------
Client Server
------ ------
ClientHello -------->
#client_certificate_type#
#server_certificate_type#
ClientHello -------->
#client_certificate_type#
#server_certificate_type#
ServerHello
#client_certificate_type#
#server_certificate_type#
Certificate
ServerKeyExchange
CertificateRequest
<-------- ServerHelloDone
ServerHello
#client_certificate_type#
#server_certificate_type#
Certificate
ServerKeyExchange
CertificateRequest
<-------- ServerHelloDone
Certificate
ClientKeyExchange
CertificateVerify
[ChangeCipherSpec]
Finished -------->
Certificate
ClientKeyExchange
CertificateVerify
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<-------- Finished
[ChangeCipherSpec]
<-------- Finished
Note: Extensions marked with "#" were introduced with RFC 7250.
注：RFC 7250引入了标有“#”的扩展。
Figure 9: DTLS Raw Public Key Exchange
图9:DTLS原始公钥交换
The CoAP-recommended ciphersuite for use with this credential type is TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 [RFC7251]. This AES-CCM TLS ciphersuite based on elliptic curve cryptography (ECC) uses the Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) as the key establishment mechanism and an Elliptic Curve Digital Signature
CoAP推荐用于此凭证类型的密码套件为TLS_ECDHE_ECDSA_with_AES_128_CCM_8[RFC7251]。这种基于椭圆曲线密码（ECC）的AES-CCM TLS密码套件使用瞬时椭圆曲线Diffie-Hellman（ECDHE）作为密钥建立机制和椭圆曲线数字签名
Algorithm (ECDSA) for authentication. The named DH groups [FFDHE-TLS] are not applicable to this profile since it relies on the ECC-based counterparts. This ciphersuite makes use of the AEAD capability in DTLS 1.2 and utilizes an 8-octet authentication tag. The use of a DH key exchange provides perfect forward secrecy (PFS). More details about PFS can be found in Section 9.
用于身份验证的算法（ECDSA）。命名的DH组[FFDHE-TLS]不适用于此配置文件，因为它依赖于基于ECC的对应项。此密码套件利用DTLS 1.2中的AEAD功能，并使用8个八位字节的身份验证标签。DH密钥交换的使用提供了完美的前向保密性（PFS）。有关PFS的更多详细信息，请参见第9节。
[RFC6090] provides valuable information for implementing ECC algorithms, particularly for choosing methods that have been available in the literature for a long time (i.e., 20 years and more).
[RFC6090]为实现ECC算法提供了有价值的信息，特别是选择文献中已有很长时间（即20年或更长时间）的方法。
A device compliant with the profile in this section MUST implement TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 and follow the guidance from this section.
符合本节中配置文件的设备必须使用\u AES\u 128\u CCM\u 8实现TLS\u ECDHE\u ECDSA\u，并遵循本节的指导。
The use of mutual certificate-based authentication is shown in Figure 10, which makes use of the "cached_info" extension [RFC7924]. Support of the "cached_info" extension is REQUIRED. Caching certificate chains allows the client to reduce the communication overhead significantly, otherwise the server would provide the end-entity certificate and the certificate chain with every full DTLS handshake.
图10显示了基于相互证书的身份验证的使用，它使用了“cached_info”扩展[RFC7924]。需要支持“cached_info”扩展。缓存证书链允许客户端显著减少通信开销，否则服务器将在每次完整DTLS握手时提供最终实体证书和证书链。
Client Server
------ ------
Client Server
------ ------
ClientHello -------->
*cached_info*
ClientHello -------->
*cached_info*
ServerHello
*cached_info*
Certificate
ServerKeyExchange
CertificateRequest
<-------- ServerHelloDone
ServerHello
*cached_info*
Certificate
ServerKeyExchange
CertificateRequest
<-------- ServerHelloDone
Certificate
ClientKeyExchange
CertificateVerify
[ChangeCipherSpec]
Finished -------->
Certificate
ClientKeyExchange
CertificateVerify
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<-------- Finished
[ChangeCipherSpec]
<-------- Finished
Note: Extensions marked with "*" were introduced with RFC 7924.
注：RFC 7924引入了标有“*”的扩展。
Figure 10: DTLS Mutual Certificate-Based Authentication
图10:DTLS基于相互证书的身份验证
TLS/DTLS offers a lot of choices when selecting ECC-based ciphersuites. This document restricts the use to named curves defined in RFC 4492 [RFC4492]. At the time of writing, the recommended curve is secp256r1, and the use of uncompressed points follows the recommendation in CoAP. Note that standardization for Curve25519 (for ECDHE) is ongoing (see [RFC7748]), and support for this curve will likely be required in the future.
在选择基于ECC的密码套件时，TLS/DTLS提供了很多选择。本文档限制使用RFC 4492[RFC4492]中定义的命名曲线。在撰写本文时，建议的曲线为secp256r1，未压缩点的使用遵循CoAP中的建议。请注意，曲线25519（用于ECDHE）的标准化正在进行中（请参见[RFC7748]），未来可能需要对该曲线的支持。
A device compliant with the profile in this section MUST implement TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 and follow the guidance from this section.
符合本节中配置文件的设备必须使用\u AES\u 128\u CCM\u 8实现TLS\u ECDHE\u ECDSA\u，并遵循本节的指导。
The algorithm for verifying the service identity, as described in RFC 6125 [RFC6125], is essential for ensuring proper security when certificates are used. As a summary, the algorithm contains the following steps:
如RFC 6125[RFC6125]所述，验证服务标识的算法对于确保使用证书时的适当安全性至关重要。作为总结，该算法包含以下步骤：
1. The client constructs a list of acceptable reference identifiers based on the source domain and, optionally, the type of service to which the client is connecting.
1. 客户机基于源域和客户机连接的服务类型（可选）构造可接受的引用标识符列表。
2. The server provides its identifiers in the form of a PKIX certificate.
2. 服务器以PKIX证书的形式提供其标识符。
3. The client checks each of its reference identifiers against the presented identifiers for the purpose of finding a match.
3. 客户机根据提供的标识符检查其每个参考标识符，以查找匹配项。
4. When checking a reference identifier against a presented identifier, the client matches the source domain of the identifiers and, optionally, their application service type.
4. 当对照呈现的标识符检查引用标识符时，客户机将匹配标识符的源域以及（可选）它们的应用程序服务类型。
For various terms used in the algorithm shown above, consult RFC 6125. It is important to highlight that comparing the reference identifier against the presented identifier obtained from the certificate is required to ensure the client is communicating with the intended server.
对于上述算法中使用的各种术语，请参考RFC 6125。需要强调的是，需要将参考标识符与从证书中获得的呈现标识符进行比较，以确保客户端与预期服务器通信。
It is worth noting that the algorithm description and the text in RFC 6125 assumes that fully qualified DNS domain names are used. If a server node is provisioned with a fully qualified DNS domain, then the server certificate MUST contain the fully qualified DNS domain name or "FQDN" as dNSName [RFC5280]. For CoAP, the coaps URI scheme is described in Section 6.2 of [RFC7252]. This FQDN is stored in the SubjectAltName or in the leftmost Common Name (CN) component of the subject name, as explained in Section 9.1.3.3 of [RFC7252], and used by the client to match it against the FQDN used during the lookup process, as described in [RFC6125]. For other protocols, the appropriate URI scheme specification has to be consulted.
值得注意的是，RFC 6125中的算法描述和文本假定使用完全限定的DNS域名。如果服务器节点配置了完全限定的DNS域，则服务器证书必须包含完全限定的DNS域名或“FQDN”作为dNSName[RFC5280]。对于CoAP，coaps URI方案在[RFC7252]的第6.2节中进行了描述。如[RFC7252]第9.1.3.3节所述，此FQDN存储在主题名称的SubjectAltName或最左边的通用名称（CN）组件中，并由客户端用于将其与查找过程中使用的FQDN进行匹配，如[RFC6125]所述。对于其他协议，必须参考适当的URI方案规范。
The following recommendation is provided:
提出以下建议：
1. Certificates MUST NOT use DNS domain names in the CN of certificates and instead use the subjectAltName attribute, as described in the previous paragraph.
1. 证书不得在证书的CN中使用DNS域名，而应使用subjectAltName属性，如前一段所述。
2. Certificates MUST NOT contain domain names with wildcard characters.
2. 证书不能包含带有通配符的域名。
3. Certificates MUST NOT contain multiple names (e.g., more than one dNSName field).
3. 证书不得包含多个名称（例如，多个dNSName字段）。
Note that there will be servers that are not provisioned for use with DNS domain names, for example, IoT devices that offer resources to nearby devices in a local area network, as shown in Figure 7. When such constrained servers are used, then the use of certificates as described in Section 4.4.2 is applicable. Note that the SNI extension cannot be used in this case since SNI does not offer the ability to convey a 64-bit Extended Unique Identifier (EUI-64) [EUI64]. Note that this document does not recommend use of IP addresses in certificates nor does it discuss the implications of placing IP addresses in certificates.
请注意，将有一些服务器未配置为与DNS域名一起使用，例如，为局域网中的附近设备提供资源的物联网设备，如图7所示。当使用此类受约束的服务器时，可使用第4.4.2节所述的证书。注意，在这种情况下不能使用SNI扩展，因为SNI不提供传送64位扩展唯一标识符（EUI-64）[EUI64]的能力。请注意，本文档不建议在证书中使用IP地址，也不讨论在证书中放置IP地址的含义。
For client certificates, the identifier used in the SubjectAltName or in the leftmost CN component of subject name MUST be an EUI-64.
对于客户端证书，SubjectAltName或subject name最左侧CN组件中使用的标识符必须是EUI-64。
For certificate revocation, neither the Online Certificate Status Protocol (OCSP) nor Certificate Revocation Lists (CRLs) are used. Instead, this profile relies on a software update mechanism to provision information about revoked certificates. While multiple OCSP stapling [RFC6961] has recently been introduced as a mechanism to piggyback OCSP request/responses inside the DTLS/TLS handshake (to avoid the cost of a separate protocol handshake), further investigations are needed to determine its suitability for the IoT environment.
对于证书吊销，既不使用联机证书状态协议（OCSP），也不使用证书吊销列表（CRL）。相反，此配置文件依赖于软件更新机制来提供有关已吊销证书的信息。虽然多OCSP绑定[RFC6961]最近被引入作为DTLS/TLS握手内搭载OCSP请求/响应的机制（以避免单独协议握手的成本），但需要进一步研究以确定其适用于物联网环境。
As stated earlier in this section, modifications to the trust anchor store depends on a software update mechanism as well. There are limitations to the use of a software update mechanism because of the potential inability to change certain types of keys, such as those provisioned during manufacturing. For this reason, manufacturer-provisioned credentials are typically employed only to obtain further certificates (for example, via a key distribution server) for use with servers the IoT device is finally communicating with.
如本节前面所述，对信任锚存储的修改也取决于软件更新机制。由于可能无法更改某些类型的密钥（例如在制造过程中提供的密钥），软件更新机制的使用受到限制。因此，制造商提供的凭证通常仅用于获取进一步的证书（例如，通过密钥分发服务器），以便与IoT设备最终与之通信的服务器一起使用。
All certificate elements listed in Table 1 MUST be implemented by clients and servers claiming support for certificate-based authentication. No other certificate elements are used by this specification.
表1中列出的所有证书元素必须由声称支持基于证书的身份验证的客户端和服务器实现。本规范不使用其他证书元素。
When using certificates, IoT devices MUST provide support for a server certificate chain of at least 3, not including the trust anchor, and MAY reject connections from servers offering chains longer than 3. IoT devices MAY have client certificate chains of any length. Obviously, longer chains require more digital signature verification operations to perform and lead to larger certificate messages in the TLS handshake.
使用证书时，物联网设备必须支持至少3个服务器证书链（不包括信任锚点），并且可能拒绝来自提供超过3个链的服务器的连接。物联网设备可能具有任意长度的客户端证书链。显然，更长的链需要执行更多的数字签名验证操作，从而在TLS握手中产生更大的证书消息。
Table 1 provides a summary of the elements in a certificate for use with this profile.
表1提供了用于此配置文件的证书中元素的摘要。
+----------------------+--------------------------------------------+
| Element | Notes |
+----------------------+--------------------------------------------+
| version | This profile uses X.509 v3 certificates |
| | [RFC5280]. |
| | |
| serialNumber | Positive integer unique per certificate. |
| | |
| signature | This field contains the signature |
| | algorithm, and this profile uses ecdsa- |
| | with-SHA256 or stronger [RFC5758]. |
| | |
| issuer | Contains the DN of the issuing CA. |
| | |
| validity | Values expressed as UTC time in notBefore |
| | and notAfter fields. No validity period |
| | mandated. |
| | |
| subject | See rules outlined in this section. |
| | |
| subjectPublicKeyInfo | The SubjectPublicKeyInfo structure |
| | indicates the algorithm and any associated |
| | parameters for the ECC public key. This |
| | profile uses the id-ecPublicKey algorithm |
| | identifier for ECDSA signature keys, as |
| | defined and specified in [RFC5480]. |
| | |
| signatureAlgorithm | The ECDSA signature algorithm with ecdsa- |
| | with-SHA256 or stronger. |
| | |
| signatureValue | Bit string containing the digital |
| | signature. |
| | |
+----------------------+--------------------------------------------+
| Element | Notes |
+----------------------+--------------------------------------------+
| version | This profile uses X.509 v3 certificates |
| | [RFC5280]. |
| | |
| serialNumber | Positive integer unique per certificate. |
| | |
| signature | This field contains the signature |
| | algorithm, and this profile uses ecdsa- |
| | with-SHA256 or stronger [RFC5758]. |
| | |
| issuer | Contains the DN of the issuing CA. |
| | |
| validity | Values expressed as UTC time in notBefore |
| | and notAfter fields. No validity period |
| | mandated. |
| | |
| subject | See rules outlined in this section. |
| | |
| subjectPublicKeyInfo | The SubjectPublicKeyInfo structure |
| | indicates the algorithm and any associated |
| | parameters for the ECC public key. This |
| | profile uses the id-ecPublicKey algorithm |
| | identifier for ECDSA signature keys, as |
| | defined and specified in [RFC5480]. |
| | |
| signatureAlgorithm | The ECDSA signature algorithm with ecdsa- |
| | with-SHA256 or stronger. |
| | |
| signatureValue | Bit string containing the digital |
| | signature. |
| | |
| Extension: | See rules outlined in this section. |
| subjectAltName | |
| | |
| Extension: | Indicates whether the subject of the |
| BasicConstraints | certificate is a CA and the maximum depth |
| | of valid certification paths that include |
| | this certificate. This extension is used |
| | for CA certs only, and then the value of |
| | the "cA" field is set to TRUE. The |
| | default is FALSE. |
| | |
| Extension: Key Usage | The KeyUsage field MAY have the following |
| | values in the context of this profile: |
| | digitalSignature or keyAgreement, |
| | keyCertSign for verifying signatures on |
| | public key certificates. |
| | |
| Extension: Extended | The ExtKeyUsageSyntax field MAY have the |
| Key Usage | following values in context of this |
| | profile: id-kp-serverAuth for server |
| | authentication, id-kp-clientAuth for |
| | client authentication, id-kp-codeSigning |
| | for code signing (for software update |
| | mechanism), and id-kp-OCSPSigning for |
| | future OCSP usage in TLS. |
+----------------------+--------------------------------------------+
| Extension: | See rules outlined in this section. |
| subjectAltName | |
| | |
| Extension: | Indicates whether the subject of the |
| BasicConstraints | certificate is a CA and the maximum depth |
| | of valid certification paths that include |
| | this certificate. This extension is used |
| | for CA certs only, and then the value of |
| | the "cA" field is set to TRUE. The |
| | default is FALSE. |
| | |
| Extension: Key Usage | The KeyUsage field MAY have the following |
| | values in the context of this profile: |
| | digitalSignature or keyAgreement, |
| | keyCertSign for verifying signatures on |
| | public key certificates. |
| | |
| Extension: Extended | The ExtKeyUsageSyntax field MAY have the |
| Key Usage | following values in context of this |
| | profile: id-kp-serverAuth for server |
| | authentication, id-kp-clientAuth for |
| | client authentication, id-kp-codeSigning |
| | for code signing (for software update |
| | mechanism), and id-kp-OCSPSigning for |
| | future OCSP usage in TLS. |
+----------------------+--------------------------------------------+
Table 1: Certificate Content
表1：证书内容
There are various cryptographic algorithms available to sign digital certificates; those algorithms include RSA, the Digital Signature Algorithm (DSA), and ECDSA. As Table 1 shows, certificates are signed using ECDSA in this profile. This is not only true for the end-entity certificates but also for all other certificates in the chain, including CA certificates. This profiling reduces the amount of flash memory needed on an IoT device to store the code of several algorithm implementations due to the smaller number of options.
有各种加密算法可用于签署数字证书；这些算法包括RSA、数字签名算法（DSA）和ECDSA。如表1所示，在此配置文件中使用ECDSA对证书进行签名。这不仅适用于终端实体证书，也适用于链中的所有其他证书，包括CA证书。由于选项数量较少，此评测减少了物联网设备上存储多个算法实现代码所需的闪存量。
Further details about X.509 certificates can be found in Section 9.1.3.3 of [RFC7252].
有关X.509证书的更多详细信息，请参见[RFC7252]的第9.1.3.3节。
RFC 6066 [RFC6066] allows the sending of client-side certificates to be avoided and uses URLs instead. This reduces the over-the-air transmission. Note that the TLS "cached_info" extension does not provide any help with caching client certificates.
RFC 6066[RFC6066]允许避免发送客户端证书，而是使用URL。这减少了空中传输。请注意，TLS“cached_info”扩展在缓存客户端证书方面不提供任何帮助。
TLS/DTLS clients MUST implement support for client certificate URLs for those environments where client-side certificates are used and the server-side is not constrained. For constrained servers this functionality is NOT RECOMMENDED since it forces the server to execute an additional protocol exchange, potentially using a protocol it does not even support. The use of this extension also increases the risk of a DoS attack against the constrained server due to the additional workload.
对于使用客户端证书且服务器端不受约束的环境，TLS/DTLS客户端必须实现对客户端证书URL的支持。对于受约束的服务器，不建议使用此功能，因为它会强制服务器执行附加的协议交换，可能会使用它甚至不支持的协议。由于额外的工作负载，使用此扩展还会增加受约束服务器遭受DoS攻击的风险。
RFC 6066 [RFC6066] allows clients to indicate what trust anchor they support. With certificate-based authentication, a DTLS server conveys its end-entity certificate to the client during the DTLS handshake. Since the server does not necessarily know what trust anchors the client has stored, to facilitate certification path construction and validation, it includes intermediate CA certs in the certificate payload.
RFC 6066[RFC6066]允许客户端指示他们支持的信任锚。通过基于证书的身份验证，DTLS服务器在DTLS握手期间将其最终实体证书传送给客户端。由于服务器不一定知道客户端存储了什么信任锚，为了便于证书路径的构建和验证，它在证书有效负载中包含了中间CA证书。
Today, in most IoT deployments there is a fairly static relationship between the IoT device (and the software running on them) and the server-side infrastructure. For these deployments where IoT devices interact with a fixed, preconfigured set of servers, this extension is NOT RECOMMENDED.
如今，在大多数物联网部署中，物联网设备（及其上运行的软件）与服务器端基础设施之间存在相当静态的关系。对于IoT设备与一组固定的、预配置的服务器交互的部署，不建议使用此扩展。
In cases where clients interact with dynamically discovered TLS/DTLS servers, for example, in the use cases described in Section 3.2.2, the use of this extension is RECOMMENDED.
在客户端与动态发现的TLS/DTLS服务器交互的情况下，例如，在第3.2.2节描述的用例中，建议使用此扩展。
The "signature_algorithms" extension, defined in Section 7.4.1.4.1 of RFC 5246 [RFC5246], allows the client to indicate to the server which signature/hash algorithm pairs may be used in digital signatures. The client MUST send this extension to select the use of SHA-256, otherwise if this extension is absent, RFC 5246 defaults to SHA-1 / ECDSA for the ECDH_ECDSA and the ECDHE_ECDSA key exchange algorithms.
RFC 5246[RFC5246]第7.4.1.4.1节中定义的“签名算法”扩展允许客户端向服务器指示数字签名中可以使用哪些签名/哈希算法对。客户端必须发送此扩展以选择SHA-256的使用，否则，如果缺少此扩展，RFC 5246将默认为ECDH_ECDSA和ECDHE_ECDSA密钥交换算法的SHA-1/ECDSA。
The "signature_algorithms" extension is not applicable to the PSK-based ciphersuite described in Section 4.2.
“签名算法”扩展不适用于第4.2节中描述的基于PSK的密码套件。
TLS/DTLS uses the alert protocol to convey errors and specifies a long list of error types. However, not all error messages defined in the TLS/DTLS specification are applicable to this profile. In general, there are two categories of errors (as defined in Section 7.2 of RFC 5246), namely fatal errors and warnings. Alert
TLS/DTLS使用警报协议传递错误，并指定一长串错误类型。但是，并非TLS/DTLS规范中定义的所有错误消息都适用于此概要文件。一般来说，有两类错误（如RFC 5246第7.2节所定义），即致命错误和警告。警觉的
messages with a level of "fatal" result in the immediate termination of the connection. If possible, developers should try to develop strategies to react to those fatal errors, such as restarting the handshake or informing the user using the (often limited) user interface. Warnings may be ignored by the application since many IoT devices will have either limited ways to log errors or no ability at all. In any case, implementers have to carefully evaluate the impact of errors and ways to remedy the situation since a commonly used approach for delegating decision making to users is difficult (or impossible) to accomplish in a timely fashion.
级别为“致命”的消息会导致连接立即终止。如果可能的话，开发人员应该尝试制定应对这些致命错误的策略，例如重新启动握手或使用（通常有限的）用户界面通知用户。应用程序可能会忽略警告，因为许多物联网设备记录错误的方式有限，或者根本无法记录错误。在任何情况下，实施者都必须仔细评估错误的影响以及纠正这种情况的方法，因为将决策授权给用户的常用方法很难（或不可能）及时完成。
All error messages marked as RESERVED are only supported for backwards compatibility with the Secure Socket Layer (SSL) and MUST NOT be used with this profile. Those include decryption_failed_RESERVED, no_certificate_RESERVED, and export_restriction_RESERVED.
所有标记为保留的错误消息仅支持与安全套接字层（SSL）向后兼容，并且不得与此配置文件一起使用。这些包括解密失败保留、无证书保留和导出限制保留。
A number of the error messages MUST only be used for certificate-based ciphersuites. Hence, the following error messages MUST NOT be used with PSK and raw public key authentication:
许多错误消息只能用于基于证书的密码套件。因此，以下错误消息不得与PSK和原始公钥身份验证一起使用：
o bad_certificate,
o 坏证书，
o unsupported_certificate,
o 不支持的\u证书，
o certificate_revoked,
o 证书被吊销，
o certificate_expired,
o 证书已过期，
o certificate_unknown,
o 证书(未知),，
o unknown_ca, and
o 未知，以及
o access_denied.
o 访问被拒绝。
Since this profile does not make use of compression at the TLS layer, the decompression_failure error message MUST NOT be used either.
由于此配置文件未在TLS层使用压缩，因此也不得使用解压缩失败错误消息。
RFC 4279 introduced the new alert message "unknown_psk_identity" for PSK ciphersuites. As stated in Section 2 of RFC 4279, the decrypt_error error message may also be used instead. For this profile, the TLS server MUST return the decrypt_error error message instead of the unknown_psk_identity since the two mechanisms exist and provide the same functionality.
RFC 4279为psk密码套件引入了新的警报消息“未知psk身份”。如RFC 4279第2节所述，也可以使用解密错误消息。对于此配置文件，TLS服务器必须返回decrypt_错误消息，而不是未知的_psk_标识，因为这两种机制存在并提供相同的功能。
Furthermore, the following errors should not occur with devices and servers supporting this specification, but implementations MUST be prepared to process these errors to deal with servers that are not compliant to the profiles in this document:
此外，支持本规范的设备和服务器不应出现以下错误，但必须准备好实施来处理这些错误，以处理不符合本文档中配置文件的服务器：
protocol_version: While this document focuses only on one version of the TLS/DTLS protocol, namely version 1.2, ongoing work on TLS/ DTLS 1.3 is in progress at the time of writing.
协议_版本：虽然本文件仅关注TLS/DTLS协议的一个版本，即版本1.2，但在编写本文件时，正在进行的TLS/DTLS 1.3工作正在进行中。
insufficient_security: This error message indicates that the server requires ciphers to be more secure. This document specifies only one ciphersuite per profile, but it is likely that additional ciphersuites will get added over time.
_安全性不足：此错误消息表示服务器要求密码更安全。本文档仅为每个配置文件指定一个密码套件，但随着时间的推移，可能会添加更多的密码套件。
user_canceled: Many IoT devices are unattended and hence this error message is unlikely to occur.
用户_已取消：许多物联网设备无人值守，因此不太可能出现此错误消息。
Session resumption is a feature of the core TLS/DTLS specifications that allows a client to continue with an earlier established session state. The resulting exchange is shown in Figure 11. In addition, the server may choose not to do a cookie exchange when a session is resumed. Still, clients have to be prepared to do a cookie exchange with every handshake. The cookie exchange is not shown in the figure.
会话恢复是核心TLS/DTLS规范的一项功能，它允许客户端继续使用先前建立的会话状态。结果交换如图11所示。此外，服务器可以选择在会话恢复时不进行cookie交换。不过，客户必须准备好在每次握手时交换cookie。图中未显示cookie交换。
Client Server
------ ------
Client Server
------ ------
ClientHello -------->
ServerHello
[ChangeCipherSpec]
<-------- Finished
[ChangeCipherSpec]
Finished -------->
Application Data <-------> Application Data
ClientHello -------->
ServerHello
[ChangeCipherSpec]
<-------- Finished
[ChangeCipherSpec]
Finished -------->
Application Data <-------> Application Data
Figure 11: DTLS Session Resumption
图11:DTLS会话恢复
Constrained clients MUST implement session resumption to improve the performance of the handshake. This will lead to a reduced number of message exchanges, lower computational overhead (since only symmetric cryptography is used during a session resumption exchange), and session resumption requires less bandwidth.
受约束的客户端必须实现会话恢复以提高握手的性能。这将减少消息交换的数量，降低计算开销（因为在会话恢复交换期间仅使用对称加密），并且会话恢复需要更少的带宽。
For cases where the server is constrained (but not the client), the client MUST implement RFC 5077 [RFC5077]. Note that the constrained
对于服务器受到约束（而不是客户端）的情况，客户端必须实现RFC 5077[RFC5077]。请注意，受约束的
server refers to a device that has limitations in terms of RAM and flash memory, which place restrictions on the amount of TLS/DTLS security state information that can be stored on such a device. RFC 5077 specifies a version of TLS/DTLS session resumption that does not require per-session state information to be maintained by the constrained server. This is accomplished by using a ticket-based approach.
服务器指的是在RAM和闪存方面有限制的设备，这对可存储在此类设备上的TLS/DTLS安全状态信息的数量有限制。RFC 5077指定TLS/DTLS会话恢复的版本，该版本不需要受约束服务器维护每个会话的状态信息。这是通过使用基于票据的方法实现的。
If both the client and the server are constrained devices, both devices SHOULD implement RFC 5077 and MUST implement basic session resumption. Clients that do not want to use session resumption are always able to send a ClientHello message with an empty session_id to revert to a full handshake.
如果客户端和服务器都是受约束的设备，则这两个设备都应实现RFC 5077，并且必须实现基本会话恢复。不希望使用会话恢复的客户端始终能够发送带有空会话id的ClientHello消息，以恢复为完全握手。
Section 3.3 of [RFC7525] recommends disabling TLS-/DTLS-level compression due to attacks, such as CRIME [CRIME]. For IoT applications, compression at the TLS/DTLS layer is not needed since application-layer protocols are highly optimized, and the compression algorithms at the DTLS layer increases code size and complexity.
[RFC7525]第3.3节建议禁用TLS-/DTLS级别的压缩，原因是攻击，如犯罪[CRIME]。对于物联网应用，不需要TLS/DTLS层的压缩，因为应用层协议经过高度优化，DTLS层的压缩算法增加了代码大小和复杂性。
TLS/DTLS layer compression is NOT RECOMMENDED by this TLS/DTLS profile.
此TLS/DTLS配置文件不推荐TLS/DTLS层压缩。
PFS is a property that preserves the confidentiality of past protocol interactions even in situations where the long-term secret is compromised.
PFS是一种保护过去协议交互的机密性的属性，即使在长期机密被泄露的情况下也是如此。
The PSK ciphersuite recommended in Section 4.2 does not offer this property since it does not utilize a DH exchange. New ciphersuites that support PFS for PSK-based authentication, such as proposed in [PSK-AES-CCM-TLS], might become available as a standardized ciphersuite in the (near) future. The recommended PSK-based ciphersuite offers excellent performance, a very small memory footprint, and has the lowest on the wire overhead at the expense of not using any public cryptography. For deployments where public key cryptography is acceptable, the use of raw public keys might offer a middle ground between the PSK ciphersuite in terms of out-of-band validation and the functionality offered by asymmetric cryptography.
第4.2节中推荐的PSK密码套件不提供此属性，因为它不使用DH交换。[PSK-AES-CCM-TLS]中提出的支持PFS进行基于PSK的身份验证的新密码套件可能在不久的将来作为标准化密码套件提供。推荐的基于PSK的密码套件提供了优异的性能、非常小的内存占用，并且在不使用任何公共密码的情况下具有最低的在线开销。对于可接受公钥加密的部署，原始公钥的使用可能会在PSK密码套件的带外验证和非对称加密提供的功能之间提供一个中间地带。
Physical attacks create additional opportunities to gain access to the crypto material stored on IoT devices. A PFS ciphersuite prevents an attacker from obtaining the communication content exchanged prior to a successful long-term key compromise; however, an implementation that (for performance or energy efficiency reasons)
物理攻击为访问存储在物联网设备上的加密材料创造了额外的机会。PFS密码套件可防止攻击者获得在成功长期密钥泄露之前交换的通信内容；但是，（出于性能或能源效率原因）实施
has been reusing the same ephemeral DH keys over multiple different sessions partially defeats PFS, thus increasing the damage extent. For this reason, implementations SHOULD NOT reuse ephemeral DH keys over multiple protocol exchanges.
在多个不同的会话中重复使用相同的短暂DH密钥会部分破坏PFS，从而增加损坏程度。因此，实现不应在多个协议交换上重用临时DH密钥。
The impact of the disclosure of past communication interactions and the desire to increase the cost for pervasive monitoring (as demanded by [RFC7258]) has to be taken into account when selecting a ciphersuite that does not support the PFS property.
在选择不支持PFS属性的密码套件时，必须考虑披露过去通信交互的影响和增加普及监控成本的愿望（如[RFC7258]所要求）。
Client implementations claiming support of this profile MUST implement the ciphersuites listed in Section 4 according to the selected credential type.
声称支持此配置文件的客户端实现必须根据所选凭据类型实现第4节中列出的密码套件。
Application-layer communication may create state at the endpoints, and this state may expire at some time. For this reason, applications define ways to refresh state, if necessary. While the application-layer exchanges are largely outside the scope of the underlying TLS/DTLS exchange, similar state considerations also play a role at the level of TLS/DTLS. While TLS/DTLS also creates state in the form of a security context (see the security parameter described in Appendix A.6 in RFC 5246) at the client and the server, this state information does not expire. However, network intermediaries may also allocate state and require this state to be kept alive. Failure to keep state alive at a stateful packet filtering firewall or at a NAT may result in the inability for one node to reach the other since packets will get blocked by these middleboxes. Periodic keep-alive messages exchanged between the TLS/ DTLS client and server keep state at these middleboxes alive. According to measurements described in [HomeGateway], there is some variance in state management practices used in residential gateways, but the timeouts are heavily impacted by the choice of the transport-layer protocol: timeouts for UDP are typically much shorter than those for TCP.
应用层通信可能会在端点处创建状态，并且该状态可能会在某个时间过期。因此，如果需要，应用程序定义刷新状态的方法。虽然应用层交换在很大程度上超出了底层TLS/DTLS交换的范围，但类似的状态考虑也在TLS/DTLS级别发挥作用。虽然TLS/DTLS还在客户端和服务器上以安全上下文的形式创建状态（参见RFC 5246附录a.6中描述的安全参数），但该状态信息不会过期。然而，网络中介也可以分配状态，并要求该状态保持活动状态。在有状态数据包过滤防火墙或NAT上未能保持状态为活动状态可能导致一个节点无法到达另一个节点，因为数据包将被这些中间盒阻止。TLS/DTLS客户端和服务器之间定期交换的保持活动消息使这些中间盒的状态保持活动。根据[HomeGateway]中描述的测量，住宅网关中使用的状态管理实践存在一些差异，但超时严重受传输层协议选择的影响：UDP的超时通常比TCP的超时短得多。
RFC 6520 [RFC6520] defines a heartbeat mechanism to test whether the other peer is still alive. As an additional feature, the same mechanism can also be used to perform Path Maximum Transmission Unit (MTU) Discovery.
RFC 6520[RFC6520]定义了一种心跳机制，用于测试另一个对等方是否仍处于活动状态。作为附加功能，同样的机制也可用于执行路径最大传输单元（MTU）发现。
A recommendation about the use of RFC 6520 depends on the type of message exchange an IoT device performs and the number of messages the application needs to exchange as part of their application functionality. There are three types of exchanges that need to be analyzed:
关于使用RFC 6520的建议取决于物联网设备执行的消息交换类型以及作为其应用程序功能的一部分，应用程序需要交换的消息数量。需要分析三种类型的交易所：
Client-Initiated, One-Shot Messages
客户端启动的一次性消息
This is a common communication pattern where IoT devices upload data to a server on the Internet on an irregular basis. The communication may be triggered by specific events, such as opening a door.
这是一种常见的通信模式，其中物联网设备不定期地将数据上传到互联网上的服务器。通信可能由特定事件触发，例如开门。
The DTLS handshake may need to be restarted (ideally using session resumption, if possible) in case of an IP address change.
如果IP地址发生变化，可能需要重新启动DTLS握手（如果可能，最好使用会话恢复）。
In this case, there is no use for a keep-alive extension for this scenario.
在这种情况下，对于这个场景来说，保持活动的扩展是没有用的。
Client-Initiated, Regular Data Uploads
客户端启动的定期数据上载
This is a variation of the previous case whereby data gets uploaded on a regular basis, for example, based on frequent temperature readings. If neither NAT bindings nor IP address changes occurred, then the record layer will not notice any changes. For the case where the IP address and port number changes, it is necessary to recreate the record layer using session resumption.
这是前一种情况的变化，即定期上传数据，例如，基于频繁的温度读数。如果NAT绑定和IP地址均未发生更改，则记录层不会注意到任何更改。对于IP地址和端口号更改的情况，有必要使用会话恢复重新创建记录层。
In this scenario, there is no use for a keep-alive extension. It is also very likely that the device will enter a sleep cycle in between data transmissions to keep power consumption low.
在这个场景中，保持活动的扩展没有任何用处。设备也很可能在数据传输之间进入睡眠周期，以保持低功耗。
Server-Initiated Messages
服务器启动的消息
In the two previous scenarios, the client initiates the protocol interaction and maintains it. Since messages to the client may get blocked by middleboxes, the initial connection setup is triggered by the client and then kept alive by the server.
在前面两个场景中，客户机启动并维护协议交互。由于发送给客户端的消息可能会被中间件阻止，因此初始连接设置由客户端触发，然后由服务器保持活动状态。
For this message exchange pattern, the use of DTLS heartbeat messages is quite useful but may have to be coordinated with application exchanges (for example, when the CoAP resource directory is used) to avoid redundant keep-alive message exchanges. The MTU discovery mechanism, which is also part of [RFC6520], is less likely to be relevant since for many IoT deployments, the most constrained link is the wireless interface between the IoT device and the network itself (rather than some links along the end-to-end path). Only in more complex network topologies, such as multi-hop mesh networks, path MTU discovery might be appropriate. It also has to be noted that DTLS itself already provides a basic path discovery mechanism (see Section 4.1.1.1 of RFC 6347) by using the fragmentation capability of the handshake protocol.
对于这种消息交换模式，DTLS心跳消息的使用非常有用，但可能必须与应用程序交换相协调（例如，当使用CoAP资源目录时），以避免冗余的保持活动消息交换。MTU发现机制（也是[RFC6520]的一部分）不太可能相关，因为对于许多物联网部署而言，最受限制的链路是物联网设备与网络本身之间的无线接口（而不是端到端路径上的一些链路）。只有在更复杂的网络拓扑（如多跳网状网络）中，路径MTU发现才是合适的。还必须注意，DTLS本身已经通过使用握手协议的分段功能提供了基本的路径发现机制（参见RFC 6347第4.1.1.1节）。
For server-initiated messages, the heartbeat extension is RECOMMENDED.
对于服务器启动的消息，建议使用心跳扩展。
A variety of wired and wireless technologies are available to connect devices to the Internet. Many of the low-power radio technologies, such as IEEE 802.15.4 or Bluetooth Smart, only support small frame sizes (e.g., 127 bytes in case of IEEE 802.15.4 as explained in [RFC4919]). Other radio technologies, such as the Global System for Mobile Communications (GSM) using the short messaging service (SMS), have similar constraints in terms of payload sizes, such as 140 bytes without the optional segmentation and reassembly scheme known as "Concatenated SMS", but show higher latency.
各种有线和无线技术可用于将设备连接到互联网。许多低功率无线电技术，如IEEE 802.15.4或Bluetooth Smart，仅支持较小的帧大小（如[RFC4919]中解释的IEEE 802.15.4中的127字节）。其他无线电技术，例如使用短消息服务（SMS）的全球移动通信系统（GSM），在有效载荷大小方面具有类似的限制，例如没有称为“串联SMS”的可选分段和重组方案的140字节，但显示出更高的延迟。
The DTLS handshake protocol adds a fragmentation and reassembly mechanism to the TLS handshake protocol since each DTLS record must fit within a single transport layer datagram, as described in Section 4.2.3 of [RFC6347]. Since handshake messages are potentially bigger than the maximum record size, the mechanism fragments a handshake message over a number of DTLS records, each of which can be transmitted separately.
DTLS握手协议向TLS握手协议添加了一种分段和重组机制，因为每个DTLS记录必须适合于单个传输层数据报，如[RFC6347]第4.2.3节所述。由于握手消息可能大于最大记录大小，因此该机制将握手消息分段到多个DTLS记录上，每个DTLS记录都可以单独传输。
To deal with the unreliable message delivery provided by UDP, DTLS adds timeouts and "per-flight" retransmissions, as described in Section 4.2.4 of [RFC6347]. Although the timeout values are implementation specific, recommendations are provided in Section 4.2.4.1 of [RFC6347], with an initial timer value of 1 second and double the value at each retransmission, up to no less than 60 seconds.
为了处理UDP提供的不可靠消息传递，DTLS添加了超时和“每次飞行”重传，如[RFC6347]第4.2.4节所述。尽管超时值是特定于实现的，但[RFC6347]第4.2.4.1节提供了建议，初始计时器值为1秒，每次重传时为该值的两倍，最长不少于60秒。
TLS protocol steps can take longer due to higher processing time on the constrained side. On the other hand, the way DTLS handles retransmission, which is per-flight instead of per-segment, tends to interact poorly with low-bandwidth networks.
由于受约束端的处理时间较长，TLS协议步骤可能需要更长的时间。另一方面，DTLS处理重传的方式（即每航班而不是每段重传）往往与低带宽网络的交互较差。
For these reasons, it's essential that the probability of a spurious retransmit is minimized and, on timeout, the sending endpoint does not react too aggressively. The latter is particularly relevant when the Wireless Sensor Network (WSN) is temporarily congested: if lost packets are reinjected too quickly, congestion worsens.
出于这些原因，必须将伪重传的概率降至最低，并且在超时时，发送端点不会做出过于积极的反应。当无线传感器网络（WSN）暂时拥塞时，后者尤其重要：如果丢失的数据包被过快地重新注入，拥塞就会恶化。
An initial timer value of 9 seconds with exponential back off up to no less then 60 seconds is therefore RECOMMENDED.
因此，建议初始计时器值为9秒，指数后退不少于60秒。
This value is chosen big enough to absorb large latency variance due to either slow computation on constrained endpoints or intrinsic network characteristics (e.g., GSM-SMS), as well as to produce a low
该值选择得足够大，以吸收由于受限端点上的计算速度慢或固有网络特性（例如GSM-SMS）导致的较大延迟变化，并产生较低的延迟
number of retransmission events and relax the pacing between them. Its worst case wait time is the same as using 1s timeout (i.e., 63s), while triggering less than half of the retransmissions (2 instead of 5).
重新传输事件的数量，并放松它们之间的步调。其最坏情况下的等待时间与使用1s超时（即63s）相同，同时触发不到一半的重传（2而不是5）。
In order to minimize the wake time during DTLS handshake, sleepy nodes might decide to select a lower threshold and, consequently, a smaller initial timeout value. If this is the case, the implementation MUST keep into account the considerations about network stability described in this section.
为了最小化DTLS握手期间的唤醒时间，休眠节点可能决定选择较低的阈值，从而选择较小的初始超时值。如果是这种情况，实施时必须考虑本节中描述的有关网络稳定性的考虑因素。
The TLS/DTLS protocol requires random numbers to be available during the protocol run. For example, during the ClientHello and the ServerHello exchange, the client and the server exchange random numbers. Also, the use of the DH exchange requires random numbers during the key pair generation.
TLS/DTLS协议要求在协议运行期间提供随机数。例如，在ClientHello和ServerHello交换期间，客户端和服务器交换随机数。此外，DH交换的使用需要在密钥对生成期间使用随机数。
It is important to note that sources contributing to the randomness pool on laptops or desktop PCs are not available on many IoT devices, such as mouse movement, timing of keystrokes, air turbulence on the movement of hard drive heads, etc. Other sources have to be found or dedicated hardware has to be added.
需要注意的是，笔记本电脑或台式电脑上的随机性池的来源在许多物联网设备上都不可用，例如鼠标移动、按键计时、硬盘驱动器头移动时的空气湍流等。必须找到其他来源或添加专用硬件。
Lacking sources of randomness in an embedded system may lead to the same keys generated again and again.
嵌入式系统中缺少随机性源可能会导致重复生成相同的密钥。
The ClientHello and the ServerHello messages contain the "Random" structure, which has two components: gmt_unix_time and a sequence of 28 random bytes. gmt_unix_time holds the current time and date in standard UNIX 32-bit format (seconds since the midnight starting Jan 1, 1970, GMT). Since many IoT devices do not have access to an accurate clock, it is RECOMMENDED that the receiver of a ClientHello or ServerHello does not assume that the value in "Random.gmt_unix_time" is an accurate representation of the current time and instead treats it as an opaque random string.
ClientHello和ServerHello消息包含“随机”结构，它有两个组件：gmt\u unix\u时间和28个随机字节的序列。gmt_unix_time以标准的unix 32位格式保存当前时间和日期（自1970年1月1日午夜开始的秒数，gmt）。由于许多物联网设备无法访问准确的时钟，建议ClientHello或ServerHello的接收器不要假设“Random.gmt_unix_time”中的值是当前时间的准确表示，而是将其视为不透明的随机字符串。
When TLS is used with certificate-based authentication, the availability of time information is needed to check the validity of a certificate. Higher-layer protocols may provide secure time information. The gmt_unix_time component of the ServerHello is not used for this purpose.
当TLS与基于证书的身份验证一起使用时，需要时间信息的可用性来检查证书的有效性。高层协议可以提供安全的时间信息。ServerHello的gmt\u unix\u时间组件不用于此目的。
IoT devices using TLS/DTLS must offer ways to generate quality random numbers. There are various implementation choices for integrating a hardware-based random number generator into a product: an implementation inside the microcontroller itself is one option, but
使用TLS/DTL的物联网设备必须提供生成高质量随机数的方法。将基于硬件的随机数生成器集成到产品中有多种实现选择：微控制器内部的实现是一种选择，但是
dedicated crypto chips are also reasonable choices. The best choice will depend on various factors outside the scope of this document. Guidelines and requirements for random number generation can be found in RFC 4086 [RFC4086] and in the NIST Special Publication 800-90a [SP800-90A].
专用加密芯片也是合理的选择。最佳选择取决于本文件范围之外的各种因素。随机数生成的指南和要求见RFC 4086[RFC4086]和NIST特别出版物800-90a[SP800-90a]。
Chip manufacturers are highly encouraged to provide sufficient documentation of their design for random number generators so that customers can have confidence about the quality of the generated random numbers. The confidence can be increased by providing information about the procedures that have been used to verify the randomness of numbers generated by the hardware modules. For example, NIST Special Publication 800-22b [SP800-22b] describes statistical tests that can be used to verify random number generators.
强烈鼓励芯片制造商提供足够的随机数发生器设计文档，以便客户对生成的随机数的质量有信心。通过提供有关用于验证硬件模块生成的数字的随机性的程序的信息，可以提高置信度。例如，NIST特别出版物800-22b[SP800-22b]描述了可用于验证随机数生成器的统计测试。
The truncated MAC extension was introduced in RFC 6066 [RFC6066] with the goal to reduce the size of the MAC used at the record layer. This extension was developed for TLS ciphersuites that used older modes of operation where the MAC and the encryption operation were performed independently.
RFC66066[RFC6066]中引入了截断MAC扩展，目的是减少记录层使用的MAC的大小。此扩展是为使用旧操作模式的TLS密码套件开发的，其中MAC和加密操作是独立执行的。
The recommended ciphersuites in this document use the newer AEAD construct, namely the CCM mode with 8-octet authentication tags, and are therefore not applicable to the truncated MAC extension.
本文档中推荐的密码套件使用较新的AEAD构造，即带有8个八位字节身份验证标签的CCM模式，因此不适用于截断的MAC扩展。
RFC 7366 [RFC7366] introduced the encrypt-then-MAC extension (instead of the previously used MAC-then-encrypt) since the MAC-then-encrypt mechanism has been the subject of a number of security vulnerabilities. RFC 7366 is, however, also not applicable to the AEAD ciphers recommended in this document.
RFC 7366[RFC7366]引入了加密然后MAC扩展（而不是以前使用的MAC然后加密），因为MAC然后加密机制一直是许多安全漏洞的主题。然而，RFC 7366也不适用于本文件中推荐的AEAD密码。
Implementations conformant to this specification MUST use AEAD ciphers. RFC 7366 ("encrypt-then-MAC") and RFC 6066 ("truncated MAC extension") are not applicable to this specification and MUST NOT be used.
符合本规范的实现必须使用AEAD密码。RFC 7366（“加密然后MAC”）和RFC 6066（“截断MAC扩展”）不适用于本规范，不得使用。
The SNI extension [RFC6066] defines a mechanism for a client to tell a TLS/DTLS server the name of the server it wants to contact. This is a useful extension for many hosting environments where multiple virtual servers are run on a single IP address.
SNI扩展[RFC6066]定义了一种机制，用于客户端告知TLS/DTLS服务器它要联系的服务器的名称。对于许多托管环境来说，这是一个有用的扩展，其中多个虚拟服务器在单个IP地址上运行。
Implementing the Server Name Indication extension is REQUIRED unless it is known that a TLS/DTLS client does not interact with a server in a hosting environment.
除非已知TLS/DTLS客户端不与宿主环境中的服务器交互，否则需要实现服务器名称指示扩展。
This RFC 6066 extension lowers the maximum fragment length support needed for the record layer from 2^14 bytes to 2^9 bytes.
此RFC 6066扩展将记录层所需的最大片段长度支持从2^14字节降低到2^9字节。
This is a very useful extension that allows the client to indicate to the server how much maximum memory buffers it uses for incoming messages. Ultimately, the main benefit of this extension is to allow client implementations to lower their RAM requirements since the client does not need to accept packets of large size (such as 16K packets as required by plain TLS/DTLS).
这是一个非常有用的扩展，它允许客户端向服务器指示它对传入消息使用的最大内存缓冲区数量。最终，此扩展的主要好处是允许客户机实现降低其RAM要求，因为客户机不需要接受大容量的数据包（如普通TLS/DTL所需的16K数据包）。
Client implementations MUST support this extension.
客户端实现必须支持此扩展。
In order to begin connection protection, the Record Protocol requires specification of a suite of algorithms, a master secret, and the client and server random values. The algorithm for computing the master secret is defined in Section 8.1 of RFC 5246, but it only includes a small number of parameters exchanged during the handshake and does not include parameters like the client and server identities. This can be utilized by an attacker to mount a man-in-the-middle attack since the master secret is not guaranteed to be unique across sessions, as discovered in the "triple handshake" attack [Triple-HS].
为了开始连接保护，记录协议需要指定一套算法、主密钥以及客户端和服务器随机值。RFC 5246第8.1节定义了计算主密钥的算法，但它仅包括握手期间交换的少量参数，不包括客户端和服务器身份等参数。攻击者可以利用这一点发动中间人攻击，因为主秘密不能保证在会话中是唯一的，正如在“三重握手”攻击[triple HS]中发现的那样。
[RFC7627] defines a TLS extension that binds the master secret to a log of the full handshake that computes it, thus preventing such attacks.
[RFC7627]定义了一个TLS扩展，该扩展将主密钥绑定到计算它的完整握手日志，从而防止此类攻击。
Client implementations SHOULD implement this extension even though the ciphersuites recommended by this profile are not vulnerable to this attack. For DH-based ciphersuites, the keying material is contributed by both parties and in case of the pre-shared secret key ciphersuite, both parties need to be in possession of the shared secret to ensure that the handshake completes successfully. It is, however, possible that some application-layer protocols will tunnel other authentication protocols on top of DTLS making this attack relevant again.
即使此配置文件推荐的密码套件不易受到此攻击，客户端实现也应实现此扩展。对于基于DH的密码套件，密钥材料由双方提供，对于预共享密钥密码套件，双方都需要拥有共享密钥，以确保握手成功完成。但是，某些应用层协议可能会在DTL之上通过隧道传输其他身份验证协议，从而使此攻击再次相关。
TLS/DTLS allows a client and a server that already have a TLS/DTLS connection to negotiate new parameters, generate new keys, etc., by using the renegotiation feature. Renegotiation happens in the existing connection, with the new handshake packets being encrypted along with application data. Upon completion of the renegotiation procedure, the new channel replaces the old channel.
TLS/DTLS允许已经具有TLS/DTLS连接的客户端和服务器通过使用重新协商功能协商新参数、生成新密钥等。重新协商发生在现有连接中，新的握手数据包与应用程序数据一起加密。重新谈判程序完成后，新渠道将取代旧渠道。
As described in RFC 5746 [RFC5746], there is no cryptographic binding between the two handshakes, although the new handshake is carried out using the cryptographic parameters established by the original handshake.
如RFC 5746[RFC5746]所述，两次握手之间没有密码绑定，尽管新握手是使用原始握手建立的密码参数执行的。
To prevent the renegotiation attack [RFC5746], this specification REQUIRES the TLS renegotiation feature to be disabled. Clients MUST respond to server-initiated renegotiation attempts with an alert message (no_renegotiation), and clients MUST NOT initiate them.
为防止重新协商攻击[RFC5746]，本规范要求禁用TLS重新协商功能。客户端必须使用警报消息（无重新协商）响应服务器启动的重新协商尝试，并且客户端不得启动它们。
When a client sends a ClientHello with a version higher than the highest version known to the server, the server is supposed to reply with ServerHello.version equal to the highest version known to the server, and then the handshake can proceed. This behavior is known as version tolerance. Version intolerance is when the server (or a middlebox) breaks the handshake when it sees a ClientHello.version higher than what it knows about. This is the behavior that leads some clients to rerun the handshake with a lower version. As a result, a potential security vulnerability is introduced when a system is running an old TLS/SSL version (e.g., because of the need to integrate with legacy systems). In the worst case, this allows an attacker to downgrade the protocol handshake to SSL 3.0. SSL 3.0 is so broken that there is no secure cipher available for it (see [RFC7568]).
当客户端发送的ClientHello版本高于服务器已知的最高版本时，服务器应使用等于服务器已知的最高版本的ServerHello.version进行回复，然后握手可以继续。这种行为称为版本公差。版本不容忍是指当服务器（或中间包）看到ClientHello.Version高于其所知道的版本时，中断握手。这是导致一些客户端使用较低版本重新运行握手的行为。因此，当系统运行旧TLS/SSL版本时（例如，由于需要与遗留系统集成），会引入潜在的安全漏洞。在最坏的情况下，这允许攻击者将协议握手降级为SSL 3.0。SSL 3.0已损坏，因此没有可用的安全密码（请参阅[RFC7568]）。
The above-described downgrade vulnerability is solved by the TLS Fallback Signaling Cipher Suite Value (SCSV) [RFC7507] extension. However, the solution is not applicable to implementations conforming to this profile since the version negotiation MUST use TLS/DTLS version 1.2 (or higher). More specifically, this implies:
TLS回退信令密码套件值（SCSV）[RFC7507]扩展解决了上述降级漏洞。但是，该解决方案不适用于符合此配置文件的实现，因为版本协商必须使用TLS/DTLS版本1.2（或更高版本）。更具体地说，这意味着：
o Clients MUST NOT send a TLS/DTLS version lower than version 1.2 in the ClientHello.
o 客户端不得在ClientHello中发送低于1.2版的TLS/DTLS版本。
o Clients MUST NOT retry a failed negotiation offering a TLS/DTLS version lower than 1.2.
o 客户端不得重试TLS/DTLS版本低于1.2的失败协商。
o Servers MUST fail the handshake by sending a protocol_version fatal alert if a TLS/DTLS version >= 1.2 cannot be negotiated. Note that the aborted connection is non-resumable.
o 如果无法协商TLS/DTLS版本>=1.2，服务器必须发送协议版本致命警报，使握手失败。请注意，中止的连接是不可恢复的。
This document recommends that software and chip manufacturers implement AES and the CCM mode of operation. This document references the CoAP-recommended ciphersuite choices, which have been selected based on implementation and deployment experience from the IoT community. Over time, the preference for algorithms will, however, change. Not all components of a ciphersuite are likely to change at the same speed. Changes are more likely expected for ciphers, the mode of operation, and the hash algorithms. The recommended key lengths have to be adjusted over time as well. Some deployment environments will also be impacted by local regulation, which might dictate a certain algorithm and key size combination. Ongoing discussions regarding the choice of specific ECC curves will also likely impact implementations. Note that this document does not recommend or mandate a specific ECC curve.
本文件建议软件和芯片制造商实施AES和CCM操作模式。本文件参考了CoAP推荐的密码套件选项，这些选项是根据物联网社区的实施和部署经验选择的。然而，随着时间的推移，对算法的偏好将发生变化。并非密码套件的所有组件都可能以相同的速度更改。密码、操作模式和哈希算法更有可能发生更改。建议的键长度也必须随时间调整。某些部署环境还将受到本地法规的影响，这些法规可能规定特定的算法和密钥大小组合。正在进行的关于选择特定ECC曲线的讨论也可能会影响实施。请注意，本文件不建议或要求使用特定的ECC曲线。
The following recommendations can be made to chip manufacturers:
可向芯片制造商提出以下建议：
o Make any AES hardware-based crypto implementation accessible to developers working on security implementations at higher layers in the protocol stack. Sometimes hardware implementations are added to microcontrollers to offer support for functionality needed at the link layer and are only available to the on-chip link-layer protocol implementation. Such a setup does not allow application developers to reuse the hardware-based AES implementation.
o 使任何基于AES硬件的加密实现可供在协议栈的更高层进行安全实现的开发人员访问。有时，硬件实现被添加到微控制器中，以提供对链路层所需功能的支持，并且仅对片上链路层协议实现可用。这样的设置不允许应用程序开发人员重用基于硬件的AES实现。
o Provide flexibility for the use of the crypto function with future extensibility in mind. For example, making an AES-CCM implementation available to developers is a first step but such an implementation may not be usable due to parameter differences between an AES-CCM implementation. AES-CCM in IEEE 802.15.4 and Bluetooth Smart use a nonce length of 13 octets while DTLS uses a nonce length of 12 octets. Hardware implementations of AES-CCM for IEEE 802.15.4 and Bluetooth Smart are therefore not reusable by a DTLS stack.
o 考虑到未来的可扩展性，为加密函数的使用提供灵活性。例如，使开发人员可以使用AES-CCM实现是第一步，但是由于AES-CCM实现之间的参数差异，这样的实现可能不可用。IEEE 802.15.4和Bluetooth Smart中的AES-CCM使用13个八位字节的nonce长度，而DTLS使用12个八位字节的nonce长度。因此，用于IEEE 802.15.4和Bluetooth Smart的AES-CCM硬件实现不能被DTLS堆栈重用。
o Offer access to building blocks in addition (or as an alternative) to the complete functionality. For example, a chip manufacturer who gives developers access to the AES crypto function can use it to build an efficient AES-GCM implementation. Another example is to make a special instruction available that increases the speed of speed-up carryless multiplications.
o 除了（或作为替代）完整功能之外，还提供对构建块的访问。例如，允许开发人员访问AES加密功能的芯片制造商可以使用它构建高效的AES-GCM实现。另一个例子是使一条特殊指令可用，以提高无携带乘法的加速速度。
As a recommendation for developers and product architects, we suggest that sufficient headroom is provided to allow an upgrade to a newer cryptographic algorithm over the lifetime of the product. As an example, while AES-CCM is recommended throughout this specification, future products might use the ChaCha20 cipher in combination with the Poly1305 authenticator [RFC7539]. The assumption is made that a robust software update mechanism is offered.
作为对开发人员和产品架构师的建议，我们建议提供足够的净空，以便在产品的生命周期内升级到更新的加密算法。例如，尽管本规范中建议使用AES-CCM，但未来的产品可能会结合使用ChaCha20密码和Poly1305认证器[RFC7539]。假设提供了一种健壮的软件更新机制。
RFC 4492 [RFC4492] gives approximate comparable key sizes for symmetric- and asymmetric-key cryptosystems based on the best-known algorithms for attacking them. While other publications suggest slightly different numbers, such as [Keylength], the approximate relationship still holds true. Figure 12 illustrates the comparable key sizes in bits.
RFC 4492[RFC4492]基于最著名的攻击算法，给出了对称和非对称密钥密码系统的近似可比密钥大小。尽管其他出版物给出的数字略有不同，如[Keylength]，但近似关系仍然成立。图12以位为单位说明了可比较的密钥大小。
Symmetric | ECC | DH/DSA/RSA
------------+---------+-------------
80 | 163 | 1024
112 | 233 | 2048
128 | 283 | 3072
192 | 409 | 7680
256 | 571 | 15360
Symmetric | ECC | DH/DSA/RSA
------------+---------+-------------
80 | 163 | 1024
112 | 233 | 2048
128 | 283 | 3072
192 | 409 | 7680
256 | 571 | 15360
Figure 12: Comparable Key Sizes (in Bits) Based on RFC 4492
图12：基于RFC 4492的可比较密钥大小（以位为单位）
At the time of writing, the key size recommendations for use with TLS-based ciphers found in [RFC7525] recommend DH key lengths of at least 2048 bits, which corresponds to a 112-bit symmetric key and a 233-bit ECC key. These recommendations are roughly in line with those from other organizations, such as the National Institute of Standards and Technology (NIST) or the European Network and Information Security Agency (ENISA). The authors of [ENISA-Report2013] add that a 80-bit symmetric key is sufficient for legacy applications for the coming years, but a 128-bit symmetric key is the minimum requirement for new systems being deployed. The authors further note that one needs to also take into account the length of time data needs to be kept secure for. The use of 80-bit symmetric keys for transactional data may be acceptable for the near future while one has to insist on 128-bit symmetric keys for long-lived data.
在撰写本文时，[RFC7525]中的基于TLS的密码使用的密钥大小建议建议DH密钥长度至少为2048位，对应于112位对称密钥和233位ECC密钥。这些建议与其他组织的建议大致一致，如国家标准与技术研究所（NIST）或欧洲网络与信息安全局（ENISA）。[ENISA-Report2013]的作者补充说，80位对称密钥对于未来几年的遗留应用程序来说已经足够，但128位对称密钥是部署新系统的最低要求。作者进一步指出，还需要考虑到数据需要安全保存的时间长度。在不久的将来，对于事务数据使用80位对称密钥可能是可以接受的，而对于长寿命数据，必须坚持使用128位对称密钥。
Note that the recommendations for 112-bit symmetric keys are chosen conservatively under the assumption that IoT devices have a long expected lifetime (such as 10+ years) and that this key length recommendation refers to the long-term keys used for device authentication. Keys, which are provisioned dynamically, for the
注意，112位对称密钥的建议是在假设IoT设备具有较长的预期寿命（例如10+年）并且该密钥长度建议是指用于设备认证的长期密钥的情况下保守选择的。动态配置的密钥，用于
protection of transactional data (such as ephemeral DH keys used in various TLS/DTLS ciphersuites) may be shorter considering the sensitivity of the exchanged data.
考虑到交换数据的敏感性，事务数据（例如各种TLS/DTLS密码套件中使用的临时DH密钥）的保护可能更短。
A full TLS handshake as specified in [RFC5246] requires two full protocol rounds (four flights) before the handshake is complete and the protocol parties may begin to send application data.
[RFC5246]中规定的完整TLS握手需要两次完整的协议回合（四次飞行），然后握手完成，协议方可以开始发送应用程序数据。
An abbreviated handshake (resuming an earlier TLS session) is complete after three flights, thus adding just one round-trip time if the client sends application data first.
三次飞行后，一次简短的握手（恢复先前的TLS会话）就完成了，因此，如果客户端首先发送应用程序数据，则只需增加一次往返时间。
If the conditions outlined in [TLS-FALSESTART] are met, application data can be transmitted when the sender has sent its own "ChangeCipherSpec" and "Finished" messages. This achieves an improvement of one round-trip time for full handshakes if the client sends application data first and for abbreviated handshakes if the server sends application data first.
如果满足[TLS-FALSESTART]中概述的条件，则当发送方发送其自己的“ChangeCipherSpec”和“Finished”消息时，可以传输应用程序数据。如果客户机首先发送应用程序数据，则完整握手的往返时间缩短；如果服务器首先发送应用程序数据，则缩短握手的往返时间缩短。
The conditions for using the TLS False Start mechanism are met by the public-key-based ciphersuites in this document. In summary, the conditions are:
本文档中基于公钥的密码套件满足使用TLS错误启动机制的条件。总之，这些条件是：
o Modern symmetric ciphers with an effective key length of 128 bits, such as AES-128-CCM
o 有效密钥长度为128位的现代对称密码，如AES-128-CCM
o Client certificate types, such as ecdsa_sign
o 客户端证书类型，如ecdsa_签名
o Key exchange methods, such as ECDHE_ECDSA
o 密钥交换方法，如ECDHE_ECDSA
Based on the improvement over a full round-trip for the full TLS/DTLS exchange, this specification RECOMMENDS the use of the False Start mechanism when clients send application data first.
基于对完整TLS/DTLS交换的完整往返的改进，本规范建议在客户端首先发送应用程序数据时使用错误启动机制。
The DTLS handshake exchange conveys various identifiers, which can be observed by an on-path eavesdropper. For example, the DTLS PSK exchange reveals the PSK identity, the supported extensions, the session ID, algorithm parameters, etc. When session resumption is used, then individual TLS sessions can be correlated by an on-path adversary. With many IoT deployments, it is likely that keying material and their identifiers are persistent over a longer period of time due to the cost of updating software on these devices.
DTLS握手交换传递各种标识符，路径窃听者可以观察到这些标识符。例如，DTLS PSK交换显示PSK标识、支持的扩展、会话ID、算法参数等。当使用会话恢复时，路径上的对手可以关联各个TLS会话。对于许多物联网部署，由于更新这些设备上的软件的成本，键控材料及其标识符可能会在较长时间内保持不变。
User participation poses a challenge in many IoT deployments since many of the IoT devices operate unattended, even though they are initially provisioned by a human. The ability to control data sharing and to configure preferences will have to be provided at a system level rather than at the level of the DTLS exchange itself, which is the scope of this document. Quite naturally, the use of DTLS with mutual authentication will allow a TLS server to collect authentication information about the IoT device (likely over a long period of time). While this strong form of authentication will prevent misattribution, it also allows strong identification. Device-related data collection (e.g., sensor recordings) associated with other data types will prove to be truly useful, but this extra data might include personal information about the owner of the device or data about the environment it senses. Consequently, the data stored on the server side will be vulnerable to stored data compromise. For the communication between the client and the server, this specification prevents eavesdroppers from gaining access to the communication content. While the PSK-based ciphersuite does not provide PFS, the asymmetric versions do. This prevents an adversary from obtaining past communication content when access to a long-term secret has been gained. Note that no extra effort to make traffic analysis more difficult is provided by the recommendations made in this document.
用户参与在许多物联网部署中是一个挑战，因为许多物联网设备在无人值守的情况下运行，即使它们最初是由人提供的。控制数据共享和配置首选项的能力必须在系统级别而不是DTLS交换本身级别提供，这是本文档的范围。很自然地，使用DTL和相互认证将允许TLS服务器收集有关物联网设备的认证信息（可能需要很长一段时间）。虽然这种强有力的身份验证形式将防止误判，但它也允许进行强有力的身份验证。与其他数据类型相关的设备相关数据收集（如传感器记录）将被证明是真正有用的，但这些额外数据可能包括设备所有者的个人信息或其感知环境的数据。因此，存储在服务器端的数据容易受到存储数据泄露的影响。对于客户端和服务器之间的通信，此规范防止窃听者访问通信内容。虽然基于PSK的密码套件不提供PFS，但非对称版本提供PFS。这可以防止对手在获得长期机密时获取过去的通信内容。请注意，本文件中的建议并未提供额外的努力，使流量分析更加困难。
Note that the absence or presence of communication itself might reveal information to an adversary. For example, a presence sensor may initiate messaging when a person enters a building. While TLS/ DTLS would offer confidentiality protection of the transmitted information, it does not help to conceal all communication patterns. Furthermore, the IP header, which is not protected by TLS/DTLS, additionally reveals information about the other communication endpoint. For applications where such privacy concerns exist, additional safeguards are required, such as injecting dummy traffic and onion routing. A detailed treatment of such solutions is outside the scope of this document and requires a system-level view.
注意，通信本身的缺失或存在可能会向对手透露信息。例如，当有人进入建筑物时，存在传感器可以启动消息传递。虽然TLS/DTL将为传输的信息提供保密保护，但它无助于隐藏所有通信模式。此外，不受TLS/DTL保护的IP报头还显示了有关其他通信端点的信息。对于存在此类隐私问题的应用程序，需要额外的保护措施，例如注入虚拟流量和洋葱路由。此类解决方案的详细处理不在本文档范围内，需要系统级视图。
This entire document is about security.
整个文档都是关于安全性的。
We would also like to point out that designing a software update mechanism into an IoT system is crucial to ensure that both functionality can be enhanced and that potential vulnerabilities can be fixed. This software update mechanism is important for changing configuration information, for example, trust anchors and other keying-related information. Such a suitable software update mechanism is available with the LWM2M protocol published by the OMA [LWM2M].
我们还想指出，在物联网系统中设计软件更新机制对于确保这两种功能得到增强和潜在漏洞得到修复至关重要。此软件更新机制对于更改配置信息（例如，信任锚和其他键控相关信息）非常重要。OMA[LWM2M]发布的LWM2M协议提供了这种合适的软件更新机制。
[EUI64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64)", Registration Authority, <https://standards.ieee.org/regauth/ oui/tutorials/EUI64.html>.
[EUI64]IEEE，“64位全局标识符（EUI-64）指南”，注册机构<https://standards.ieee.org/regauth/ oui/tutorials/EUI64.html>。
[GSM-SMS] ETSI, "3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Technical realization of the Short Message Service (SMS) (Release 13)", 3GPP TS 23.040 V13.1.0, March 2016.
[GSM-SMS]ETSI，“第三代合作伙伴项目；技术规范组核心网络和终端；短消息服务（SMS）的技术实现（第13版）”，3GPP TS 23.040 V13.1.0，2016年3月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC4279] Eronen, P., Ed. and H. Tschofenig, Ed., "Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)", RFC 4279, DOI 10.17487/RFC4279, December 2005, <http://www.rfc-editor.org/info/rfc4279>.
[RFC4279]Eronen，P.，Ed.和H.Tschofenig，Ed.，“用于传输层安全（TLS）的预共享密钥密码套件”，RFC 4279，DOI 10.17487/RFC4279，2005年12月<http://www.rfc-editor.org/info/rfc4279>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，DOI 10.17487/RFC5246，2008年8月<http://www.rfc-editor.org/info/rfc5246>.
[RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, "Transport Layer Security (TLS) Renegotiation Indication Extension", RFC 5746, DOI 10.17487/RFC5746, February 2010, <http://www.rfc-editor.org/info/rfc5746>.
[RFC5746]Rescorla，E.，Ray，M.，Dispensa，S.，和N.Oskov，“传输层安全（TLS）重新协商指示扩展”，RFC 5746，DOI 10.17487/RFC5746，2010年2月<http://www.rfc-editor.org/info/rfc5746>.
[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, DOI 10.17487/RFC6066, January 2011, <http://www.rfc-editor.org/info/rfc6066>.
[RFC6066]Eastlake 3rd，D.，“传输层安全（TLS）扩展：扩展定义”，RFC 6066，DOI 10.17487/RFC6066，2011年1月<http://www.rfc-editor.org/info/rfc6066>.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 2011, <http://www.rfc-editor.org/info/rfc6125>.
[RFC6125]Saint Andre，P.和J.Hodges，“在传输层安全（TLS）环境下使用X.509（PKIX）证书在互联网公钥基础设施内表示和验证基于域的应用程序服务身份”，RFC 6125，DOI 10.17487/RFC6125，2011年3月<http://www.rfc-editor.org/info/rfc6125>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, <http://www.rfc-editor.org/info/rfc6347>.
[RFC6347]Rescorla，E.和N.Modadugu，“数据报传输层安全版本1.2”，RFC 6347，DOI 10.17487/RFC6347，2012年1月<http://www.rfc-editor.org/info/rfc6347>.
[RFC6520] Seggelmann, R., Tuexen, M., and M. Williams, "Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Heartbeat Extension", RFC 6520, DOI 10.17487/RFC6520, February 2012, <http://www.rfc-editor.org/info/rfc6520>.
[RFC6520]Seggelmann，R.，Tuexen，M.和M.Williams，“传输层安全性（TLS）和数据报传输层安全性（DTLS）心跳扩展”，RFC 6520，DOI 10.17487/RFC6520，2012年2月<http://www.rfc-editor.org/info/rfc6520>.
[RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., Weiler, S., and T. Kivinen, "Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, June 2014, <http://www.rfc-editor.org/info/rfc7250>.
[RFC7250]Wouters，P.，Ed.，Tschofenig，H.，Ed.，Gilmore，J.，Weiler，S.，和T.Kivinen，“在传输层安全性（TLS）和数据报传输层安全性（DTLS）中使用原始公钥”，RFC 7250，DOI 10.17487/RFC72502014年6月<http://www.rfc-editor.org/info/rfc7250>.
[RFC7251] McGrew, D., Bailey, D., Campagna, M., and R. Dugal, "AES-CCM Elliptic Curve Cryptography (ECC) Cipher Suites for TLS", RFC 7251, DOI 10.17487/RFC7251, June 2014, <http://www.rfc-editor.org/info/rfc7251>.
[RFC7251]McGrew，D.，Bailey，D.，Campagna，M.，和R.Dugal，“用于TLS的AES-CCM椭圆曲线加密（ECC）密码套件”，RFC 7251，DOI 10.17487/RFC7251，2014年6月<http://www.rfc-editor.org/info/rfc7251>.
[RFC7627] Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A., Langley, A., and M. Ray, "Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension", RFC 7627, DOI 10.17487/RFC7627, September 2015, <http://www.rfc-editor.org/info/rfc7627>.
[RFC7627]Bhargavan，K.，Ed.，Delignat Lavaud，A.，Pironti，A.，Langley，A.，和M.Ray，“传输层安全（TLS）会话哈希和扩展主秘密扩展”，RFC 7627，DOI 10.17487/RFC7627，2015年9月<http://www.rfc-editor.org/info/rfc7627>.
[RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security (TLS) Cached Information Extension", RFC 7924, DOI 10.17487/RFC7924, July 2016, <http://www.rfc-editor.org/info/rfc7924>.
[RFC7924]Santesson，S.和H.Tschofenig，“传输层安全（TLS）缓存信息扩展”，RFC 7924DOI 10.17487/RFC79242016年7月<http://www.rfc-editor.org/info/rfc7924>.
[WAP-WDP] Open Mobile Alliance, "Wireless Datagram Protocol", Wireless Application Protocol, WAP-259-WDP, June 2001.
[WAP-WDP]开放移动联盟，“无线数据报协议”，无线应用协议，WAP-259-WDP，2001年6月。
[ACE-WG] IETF, "Authentication and Authorization for Constrained Environments (ACE) Working Group", <https://datatracker.ietf.org/wg/ace/charter>.
[ACE-WG]IETF，“受限环境认证和授权（ACE）工作组”<https://datatracker.ietf.org/wg/ace/charter>.
[AES] National Institute of Standards and Technology, "Advanced Encryption Standard (AES)", NIST FIPS PUB 197, November 2001, <http://csrc.nist.gov/publications/fips/fips197/ fips-197.pdf>.
[AES]国家标准与技术研究所，“高级加密标准（AES）”，NIST FIPS PUB 197，2001年11月<http://csrc.nist.gov/publications/fips/fips197/ fips-197.pdf>。
[CCM] National Institute of Standards and Technology, "Recommendation for Block Cipher Modes of Operation: The CCM Mode for Authentication and Confidentiality", NIST Special Publication 800-38C, May 2004, <http://csrc.nist.gov/publications/nistpubs/800-38C/ SP800-38C_updated-July20_2007.pdf>.
[CCM]国家标准与技术研究所，“分组密码操作模式建议：认证和保密的CCM模式”，NIST特别出版物800-38C，2004年5月<http://csrc.nist.gov/publications/nistpubs/800-38C/ SP800-38C_更新-July20_2007.pdf>。
[COAP-TCP-TLS] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., Silverajan, B., and B. Raymor, "CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets", Work in Progress, draft-ietf-core-coap-tcp-tls-03, July 2016.
[COAP-TCP-TLS]Bormann，C.，Lemay，S.，Tschofenig，H.，Hartke，K.，Silverajan，B.，和B.Raymor，“TCP，TLS和WebSocket上的COAP（受限应用程序协议）”，正在进行的工作，草案-ietf-core-COAP-TCP-TLS-032016年7月。
[CoRE-RD] Shelby, Z., Koster, M., Bormann, C., and P. Stok, "CoRE Resource Directory", Work in Progress, draft-ietf-core-resource-directory-08, July 2016.
[核心研发]谢尔比，Z.，科斯特，M.，鲍曼，C.，和P.斯托克，“核心资源目录”，正在进行的工作，草稿-ietf-CoRE-Resource-Directory-082016年7月。
[CRIME] Wikipedia, "CRIME", May 2016, <https://en.wikipedia.org/w/ index.php?title=CRIME&oldid=721665716>.
[犯罪]维基百科，“犯罪”，2016年5月<https://en.wikipedia.org/w/ index.php？title=CRIME&oldid=721665716>。
[ENISA-Report2013] ENISA, "Algorithms, Key Sizes and Parameters Report - 2013", October 2013, <https://www.enisa.europa.eu/ activities/identity-and-trust/library/deliverables/ algorithms-key-sizes-and-parameters-report>.
[ENISA-Report2013]ENISA，“算法、关键尺寸和参数报告-2013”，2013年10月<https://www.enisa.europa.eu/ 活动/身份和信任/库/可交付成果/算法密钥大小和参数报告>。
[FFDHE-TLS] Gillmor, D., "Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for TLS", Work in Progress, draft-ietf-tls-negotiated-ff-dhe-10, June 2015.
[FFDHE-TLS]Gillmor，D.，“TLS的协商有限域Diffie-Hellman瞬时参数”，正在进行的工作，草案-ietf-TLS-协商-ff-dhe-10，2015年6月。
[HomeGateway] Eggert, L., Hatoen, S., Kojo, M., Nyrhinen, A., Sarolahti, P., and S. Strowes, "An Experimental Study of Home Gateway Characteristics", In Proceedings of the 10th ACM SIGCOMM conference on Internet measurement, DOI 10.1145/1879141.1879174, 2010, <http://conferences.sigcomm.org/imc/2010/papers/p260.pdf>.
[家庭网关]Eggert，L.，Hatoen，S.，Kojo，M.，Nyrhinen，A.，Sarolahti，P.，和S.Strowes，“家庭网关特性的实验研究”，发表于第十届ACM SIGCOMM互联网测量会议记录，DOI 10.1145/1879141.18791742010年<http://conferences.sigcomm.org/imc/2010/papers/p260.pdf>.
[IANA-TLS] IANA, "Transport Layer Security (TLS) Parameters", <https://www.iana.org/assignments/tls-parameters>.
[IANA-TLS]IANA，“传输层安全（TLS）参数”<https://www.iana.org/assignments/tls-parameters>.
[ImprintingSurvey] Chilton, E., "A Brief Survey of Imprinting Options for Constrained Devices", March 2012, <http://www.lix.polytechnique.fr/hipercom/ SmartObjectSecurity/papers/EricRescorla.pdf>.
[ImpringSurvey]Chilton，E.，“受限制设备的压印选项的简要调查”，2012年3月<http://www.lix.polytechnique.fr/hipercom/ SmartObjectSecurity/papers/EricRescorla.pdf>。
[Keylength] Giry, D., "Cryptographic Key Length Recommendations", September 2015, <http://www.keylength.com>.
[Keylength]Giry，D.，“加密密钥长度建议”，2015年9月<http://www.keylength.com>.
[LWM2M] Open Mobile Alliance, "Lightweight Machine-to-Machine Requirements", Candidate Version 1.0, OMA-RD-LightweightM2M-V1_0-20131210-C, December 2013, <http://openmobilealliance.org/about-oma/work-program/ m2m-enablers>.
[LWM2M]开放移动联盟，“轻量级机器对机器要求”，候选版本1.0，OMA-RD-LightweightM2M-V1_0-20131210-C，2013年12月<http://openmobilealliance.org/about-oma/work-program/ m2m启用码>。
[PSK-AES-CCM-TLS] Schmertmann, L. and C. Bormann, "ECDHE-PSK AES-CCM Cipher Suites with Forward Secrecy for Transport Layer Security (TLS)", Work in Progress, draft-schmertmann-dice-ccm-psk-pfs-01, August 2014.
[PSK-AES-CCM-TLS]Schmertmann，L.和C.Bormann，“传输层安全（TLS）前向保密的ECDHE-PSK AES-CCM密码套件”，正在进行的工作，草稿-Schmertmann-dice-CCM-PSK-pfs-012014年8月。
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August 1996, <http://www.rfc-editor.org/info/rfc1981>.
[RFC1981]McCann，J.，Deering，S.，和J.Mogul，“IP版本6的路径MTU发现”，RFC 1981，DOI 10.17487/RFC19811996年8月<http://www.rfc-editor.org/info/rfc1981>.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, DOI 10.17487/RFC2104, February 1997, <http://www.rfc-editor.org/info/rfc2104>.
[RFC2104]Krawczyk，H.，Bellare，M.，和R.Canetti，“HMAC：用于消息认证的键控哈希”，RFC 2104，DOI 10.17487/RFC2104，1997年2月<http://www.rfc-editor.org/info/rfc2104>.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, DOI 10.17487/RFC2865, June 2000, <http://www.rfc-editor.org/info/rfc2865>.
[RFC2865]Rigney，C.，Willens，S.，Rubens，A.，和W.Simpson，“远程认证拨入用户服务（RADIUS）”，RFC 2865，DOI 10.17487/RFC2865，2000年6月<http://www.rfc-editor.org/info/rfc2865>.
[RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with CBC-MAC (CCM)", RFC 3610, DOI 10.17487/RFC3610, September 2003, <http://www.rfc-editor.org/info/rfc3610>.
[RFC3610]Whiting，D.，Housley，R.，和N.Ferguson，“CBC-MAC（CCM）计数器”，RFC 3610，DOI 10.17487/RFC3610，2003年9月<http://www.rfc-editor.org/info/rfc3610>.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, <http://www.rfc-editor.org/info/rfc3748>.
[RFC3748]Aboba，B.，Blunk，L.，Vollbrecht，J.，Carlson，J.，和H.Levkowetz，编辑，“可扩展身份验证协议（EAP）”，RFC 3748，DOI 10.17487/RFC3748，2004年6月<http://www.rfc-editor.org/info/rfc3748>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, <http://www.rfc-editor.org/info/rfc4086>.
[RFC4086]Eastlake 3rd，D.，Schiller，J.，和S.Crocker，“安全的随机性要求”，BCP 106，RFC 4086，DOI 10.17487/RFC4086，2005年6月<http://www.rfc-editor.org/info/rfc4086>.
[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, DOI 10.17487/RFC4492, May 2006, <http://www.rfc-editor.org/info/rfc4492>.
[RFC4492]Blake Wilson，S.，Bolyard，N.，Gupta，V.，Hawk，C.，和B.Moeller，“用于传输层安全（TLS）的椭圆曲线密码（ECC）密码套件”，RFC 4492，DOI 10.17487/RFC4492，2006年5月<http://www.rfc-editor.org/info/rfc4492>.
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, <http://www.rfc-editor.org/info/rfc4821>.
[RFC4821]Mathis，M.和J.Heffner，“打包层路径MTU发现”，RFC 4821，DOI 10.17487/RFC4821，2007年3月<http://www.rfc-editor.org/info/rfc4821>.
[RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals", RFC 4919, DOI 10.17487/RFC4919, August 2007, <http://www.rfc-editor.org/info/rfc4919>.
[RFC4919]Kushalnagar，N.，黑山，G.和C.Schumacher，“低功率无线个人区域网络（6LoWPANs）上的IPv6：概述，假设，问题陈述和目标”，RFC 4919，DOI 10.17487/RFC4919，2007年8月<http://www.rfc-editor.org/info/rfc4919>.
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, "Transport Layer Security (TLS) Session Resumption without Server-Side State", RFC 5077, DOI 10.17487/RFC5077, January 2008, <http://www.rfc-editor.org/info/rfc5077>.
[RFC5077]Salowey，J.，Zhou，H.，Eronen，P.，和H.Tschofenig，“无服务器端状态的传输层安全（TLS）会话恢复”，RFC 5077，DOI 10.17487/RFC5077，2008年1月<http://www.rfc-editor.org/info/rfc5077>.
[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, <http://www.rfc-editor.org/info/rfc5116>.
[RFC5116]McGrew，D.“认证加密的接口和算法”，RFC 5116，DOI 10.17487/RFC5116，2008年1月<http://www.rfc-editor.org/info/rfc5116>.
[RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS Authentication Protocol", RFC 5216, DOI 10.17487/RFC5216, March 2008, <http://www.rfc-editor.org/info/rfc5216>.
[RFC5216]Simon，D.，Aboba，B.和R.Hurst，“EAP-TLS认证协议”，RFC 5216，DOI 10.17487/RFC5216，2008年3月<http://www.rfc-editor.org/info/rfc5216>.
[RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible Authentication Protocol (EAP) Key Management Framework", RFC 5247, DOI 10.17487/RFC5247, August 2008, <http://www.rfc-editor.org/info/rfc5247>.
[RFC5247]Aboba，B.，Simon，D.，和P.Eronen，“可扩展认证协议（EAP）密钥管理框架”，RFC 5247，DOI 10.17487/RFC5247，2008年8月<http://www.rfc-editor.org/info/rfc5247>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <http://www.rfc-editor.org/info/rfc5280>.
[RFC5280]Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 5280，DOI 10.17487/RFC5280，2008年5月<http://www.rfc-editor.org/info/rfc5280>.
[RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, DOI 10.17487/RFC5288, August 2008, <http://www.rfc-editor.org/info/rfc5288>.
[RFC5288]Salowey，J.，Choudhury，A.，和D.McGrew，“用于TLS的AES伽罗瓦计数器模式（GCM）密码套件”，RFC 5288，DOI 10.17487/RFC5288，2008年8月<http://www.rfc-editor.org/info/rfc5288>.
[RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, "Elliptic Curve Cryptography Subject Public Key Information", RFC 5480, DOI 10.17487/RFC5480, March 2009, <http://www.rfc-editor.org/info/rfc5480>.
[RFC5480]Turner，S.，Brown，D.，Yiu，K.，Housley，R.，和T.Polk，“椭圆曲线加密主题公钥信息”，RFC 5480，DOI 10.17487/RFC5480，2009年3月<http://www.rfc-editor.org/info/rfc5480>.
[RFC5758] Dang, Q., Santesson, S., Moriarty, K., Brown, D., and T. Polk, "Internet X.509 Public Key Infrastructure: Additional Algorithms and Identifiers for DSA and ECDSA", RFC 5758, DOI 10.17487/RFC5758, January 2010, <http://www.rfc-editor.org/info/rfc5758>.
[RFC5758]Dang，Q.，Santesson，S.，Moriarty，K.，Brown，D.，和T.Polk，“互联网X.509公钥基础设施：DSA和ECDSA的附加算法和标识符”，RFC 5758，DOI 10.17487/RFC5758，2010年1月<http://www.rfc-editor.org/info/rfc5758>.
[RFC5934] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor Management Protocol (TAMP)", RFC 5934, DOI 10.17487/RFC5934, August 2010, <http://www.rfc-editor.org/info/rfc5934>.
[RFC5934]Housley，R.，Ashmore，S.，和C.Wallace，“信任锚管理协议（TAMP）”，RFC 5934，DOI 10.17487/RFC59342010年8月<http://www.rfc-editor.org/info/rfc5934>.
[RFC6024] Reddy, R. and C. Wallace, "Trust Anchor Management Requirements", RFC 6024, DOI 10.17487/RFC6024, October 2010, <http://www.rfc-editor.org/info/rfc6024>.
[RFC6024]Reddy，R.和C.Wallace，“信托锚管理要求”，RFC 6024，DOI 10.17487/RFC60242010年10月<http://www.rfc-editor.org/info/rfc6024>.
[RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic Curve Cryptography Algorithms", RFC 6090, DOI 10.17487/RFC6090, February 2011, <http://www.rfc-editor.org/info/rfc6090>.
[RFC6090]McGrew，D.，Igoe，K.，和M.Salter，“基本椭圆曲线密码算法”，RFC 6090，DOI 10.17487/RFC6090，2011年2月<http://www.rfc-editor.org/info/rfc6090>.
[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, May 2011, <http://www.rfc-editor.org/info/rfc6234>.
[RFC6234]Eastlake 3rd，D.和T.Hansen，“美国安全哈希算法（基于SHA和SHA的HMAC和HKDF）”，RFC 6234，DOI 10.17487/RFC6234，2011年5月<http://www.rfc-editor.org/info/rfc6234>.
[RFC6655] McGrew, D. and D. Bailey, "AES-CCM Cipher Suites for Transport Layer Security (TLS)", RFC 6655, DOI 10.17487/RFC6655, July 2012, <http://www.rfc-editor.org/info/rfc6655>.
[RFC6655]McGrew，D.和D.Bailey，“用于传输层安全（TLS）的AES-CCM密码套件”，RFC 6655，DOI 10.17487/RFC6655，2012年7月<http://www.rfc-editor.org/info/rfc6655>.
[RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, <http://www.rfc-editor.org/info/rfc6690>.
[RFC6690]Shelby，Z.“受限RESTful环境（核心）链接格式”，RFC 6690，DOI 10.17487/RFC6690，2012年8月<http://www.rfc-editor.org/info/rfc6690>.
[RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, Ed., "Diameter Base Protocol", RFC 6733, DOI 10.17487/RFC6733, October 2012, <http://www.rfc-editor.org/info/rfc6733>.
[RFC6733]Fajardo，V.，Ed.，Arkko，J.，Loughney，J.，和G.Zorn，Ed.，“直径基准协议”，RFC 6733，DOI 10.17487/RFC6733，2012年10月<http://www.rfc-editor.org/info/rfc6733>.
[RFC6943] Thaler, D., Ed., "Issues in Identifier Comparison for Security Purposes", RFC 6943, DOI 10.17487/RFC6943, May 2013, <http://www.rfc-editor.org/info/rfc6943>.
[RFC6943]Thaler，D.，Ed.，“出于安全目的的标识符比较问题”，RFC 6943，DOI 10.17487/RFC6943，2013年5月<http://www.rfc-editor.org/info/rfc6943>.
[RFC6961] Pettersen, Y., "The Transport Layer Security (TLS) Multiple Certificate Status Request Extension", RFC 6961, DOI 10.17487/RFC6961, June 2013, <http://www.rfc-editor.org/info/rfc6961>.
[RFC6961]Pettersen，Y，“传输层安全性（TLS）多证书状态请求扩展”，RFC 6961，DOI 10.17487/RFC69611913年6月<http://www.rfc-editor.org/info/rfc6961>.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for Constrained-Node Networks", RFC 7228, DOI 10.17487/RFC7228, May 2014, <http://www.rfc-editor.org/info/rfc7228>.
[RFC7228]Bormann，C.，Ersue，M.和A.Keranen，“受限节点网络的术语”，RFC 7228，DOI 10.17487/RFC7228，2014年5月<http://www.rfc-editor.org/info/rfc7228>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, <http://www.rfc-editor.org/info/rfc7252>.
[RFC7252]Shelby，Z.，Hartke，K.，和C.Bormann，“受限应用协议（CoAP）”，RFC 7252，DOI 10.17487/RFC7252，2014年6月<http://www.rfc-editor.org/info/rfc7252>.
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2014, <http://www.rfc-editor.org/info/rfc7258>.
[RFC7258]Farrell，S.和H.Tschofenig，“普遍监控是一种攻击”，BCP 188，RFC 7258，DOI 10.17487/RFC7258，2014年5月<http://www.rfc-editor.org/info/rfc7258>.
[RFC7366] Gutmann, P., "Encrypt-then-MAC for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", RFC 7366, DOI 10.17487/RFC7366, September 2014, <http://www.rfc-editor.org/info/rfc7366>.
[RFC7366]Gutmann，P.，“为传输层安全性（TLS）和数据报传输层安全性（DTLS）加密MAC”，RFC 7366，DOI 10.17487/RFC7366，2014年9月<http://www.rfc-editor.org/info/rfc7366>.
[RFC7390] Rahman, A., Ed. and E. Dijk, Ed., "Group Communication for the Constrained Application Protocol (CoAP)", RFC 7390, DOI 10.17487/RFC7390, October 2014, <http://www.rfc-editor.org/info/rfc7390>.
[RFC7390]Rahman，A.，Ed.和E.Dijk，Ed.，“受限应用协议（CoAP）的组通信”，RFC 7390，DOI 10.17487/RFC7390，2014年10月<http://www.rfc-editor.org/info/rfc7390>.
[RFC7397] Gilger, J. and H. Tschofenig, "Report from the Smart Object Security Workshop", RFC 7397, DOI 10.17487/RFC7397, December 2014, <http://www.rfc-editor.org/info/rfc7397>.
[RFC7397]Gilger，J.和H.Tschofenig，“智能对象安全研讨会报告”，RFC 7397，DOI 10.17487/RFC7397，2014年12月<http://www.rfc-editor.org/info/rfc7397>.
[RFC7400] Bormann, C., "6LoWPAN-GHC: Generic Header Compression for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)", RFC 7400, DOI 10.17487/RFC7400, November 2014, <http://www.rfc-editor.org/info/rfc7400>.
[RFC7400]Bormann，C.，“6LoWPAN GHC：低功率无线个人区域网络（6LoWPANs）上IPv6的通用报头压缩”，RFC 7400，DOI 10.17487/RFC7400，2014年11月<http://www.rfc-editor.org/info/rfc7400>.
[RFC7452] Tschofenig, H., Arkko, J., Thaler, D., and D. McPherson, "Architectural Considerations in Smart Object Networking", RFC 7452, DOI 10.17487/RFC7452, March 2015, <http://www.rfc-editor.org/info/rfc7452>.
[RFC7452]Tschofenig，H.，Arkko，J.，Thaler，D.，和D.McPherson，“智能对象网络中的架构考虑”，RFC 7452，DOI 10.17487/RFC7452，2015年3月<http://www.rfc-editor.org/info/rfc7452>.
[RFC7465] Popov, A., "Prohibiting RC4 Cipher Suites", RFC 7465, DOI 10.17487/RFC7465, February 2015, <http://www.rfc-editor.org/info/rfc7465>.
[RFC7465]Popov，A.，“禁止RC4密码套件”，RFC 7465，DOI 10.17487/RFC7465，2015年2月<http://www.rfc-editor.org/info/rfc7465>.
[RFC7507] Moeller, B. and A. Langley, "TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks", RFC 7507, DOI 10.17487/RFC7507, April 2015, <http://www.rfc-editor.org/info/rfc7507>.
[RFC7507]Moeller，B.和A.Langley，“用于防止协议降级攻击的TLS回退信令密码套件值（SCSV）”，RFC 7507，DOI 10.17487/RFC7507，2015年4月<http://www.rfc-editor.org/info/rfc7507>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, <http://www.rfc-editor.org/info/rfc7525>.
[RFC7525]Sheffer，Y.，Holz，R.，和P.Saint Andre，“安全使用传输层安全性（TLS）和数据报传输层安全性（DTLS）的建议”，BCP 195，RFC 7525，DOI 10.17487/RFC7525，2015年5月<http://www.rfc-editor.org/info/rfc7525>.
[RFC7539] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF Protocols", RFC 7539, DOI 10.17487/RFC7539, May 2015, <http://www.rfc-editor.org/info/rfc7539>.
[RFC7539]Nir，Y.和A.Langley，“IETF协议的ChaCha20和Poly1305”，RFC 7539，DOI 10.17487/RFC7539，2015年5月<http://www.rfc-editor.org/info/rfc7539>.
[RFC7568] Barnes, R., Thomson, M., Pironti, A., and A. Langley, "Deprecating Secure Sockets Layer Version 3.0", RFC 7568, DOI 10.17487/RFC7568, June 2015, <http://www.rfc-editor.org/info/rfc7568>.
[RFC7568]Barnes，R.，Thomson，M.，Pironti，A.，和A.Langley，“不推荐安全套接字层版本3.0”，RFC 7568，DOI 10.17487/RFC7568，2015年6月<http://www.rfc-editor.org/info/rfc7568>.
[RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves for Security", RFC 7748, DOI 10.17487/RFC7748, January 2016, <http://www.rfc-editor.org/info/rfc7748>.
[RFC7748]兰利，A.，汉堡，M.和S.特纳，“安全的椭圆曲线”，RFC 7748，DOI 10.17487/RFC7748，2016年1月<http://www.rfc-editor.org/info/rfc7748>.
[SP800-107-rev1] National Institute of Standards and Technology, "Recommendation for Applications Using Approved Hash Algorithms", NIST Special Publication 800-107, Revision 1, DOI 10.6028/NIST.SP.800-107r1, August 2012, <http://csrc.nist.gov/publications/nistpubs/800-107-rev1/ sp800-107-rev1.pdf>.
[SP800-107-rev1]国家标准与技术研究所，“使用经批准的哈希算法的应用建议”，NIST特别出版物800-107，第1版，DOI 10.6028/NIST.SP.800-107r1，2012年8月<http://csrc.nist.gov/publications/nistpubs/800-107-rev1/ sp800-107-rev1.pdf>。
[SP800-22b] National Institute of Standards and Technology, "A Statistical Test Suite for Random and Pseudorandom Number Generators for Cryptographic Applications", NIST Special Publication 800-22, Revision 1a, April 2010, <http://csrc.nist.gov/publications/nistpubs/800-22-rev1a/ SP800-22rev1a.pdf>.
[SP800-22b]国家标准与技术研究所，“密码应用中随机和伪随机数生成器的统计测试套件”，NIST特别出版物800-22，第1a版，2010年4月<http://csrc.nist.gov/publications/nistpubs/800-22-rev1a/ SP800-22rev1a.pdf>。
[SP800-90A] National Institute of Standards and Technology, "Recommendation for Random Number Generation Using Deterministic Random Bit Generators", NIST Special Publication 800-90A Revision 1, DOI 10.6028/NIST.SP.800-90Ar1, June 2015, <http://csrc.nist.gov/publications/drafts/800-90/ sp800-90a_r1_draft_november2014_ver.pdf>.
[SP800-90A]国家标准与技术研究所，“使用确定性随机位发生器生成随机数的建议”，NIST特别出版物800-90A第1版，DOI 10.6028/NIST.SP.800-90Ar1，2015年6月<http://csrc.nist.gov/publications/drafts/800-90/ sp800-90a\u r1\u草案\u 2014年11月\u ver.pdf>。
[TLS-FALSESTART] Langley, A., Modadugu, N., and B. Moeller, "Transport Layer Security (TLS) False Start", Work in Progress, draft-ietf-tls-falsestart-02, May 2016.
[TLS-FALSESTART]Langley，A.，Modadugu，N.，和B.Moeller，“传输层安全（TLS）错误启动”，正在进行的工作，草案-ietf-TLS-FALSESTART-022016年5月。
[Triple-HS] Bhargavan, K., Delignat-Lavaud, C., Pironti, A., and P. Yves Strub, "Triple Handshakes and Cookie Cutters: Breaking and Fixing Authentication over TLS", In Proceedings of the IEEE Symposium on Security and Privacy, Pages 98-113, DOI 10.1109/SP.2014.14, 2014.
[Triple HS]Bhargavan，K.，Delignat Lavaud，C.，Pironti，A.，和P.Yves Strub，“三重握手和切饼干器：通过TLS破坏和修复身份验证”，《IEEE安全和隐私研讨会论文集》，第98-113页，DOI 10.1109/SP.2014.14，2014年。
This section is normative for the use of DTLS over SMS. Timer recommendations are already outlined in Section 11 and also applicable to the transport of DTLS over SMS.
本节是通过SMS使用DTL的规范。计时器建议已在第11节中概述，并且也适用于通过SMS传输DTL。
This section requires readers to be familiar with the terminology and concepts described in [GSM-SMS] and [WAP-WDP].
本节要求读者熟悉[GSM-SMS]和[WAP-WDP]中描述的术语和概念。
The remainder of this section assumes Mobile Stations are capable of producing and consuming Transport Protocol Data Units (TPDUs) encoded as 8-bit binary data.
本节其余部分假设移动站能够生成和使用编码为8位二进制数据的传输协议数据单元（TPDU）。
DTLS adds an additional round-trip to the TLS [RFC5246] handshake to serve as a return-routability test for protection against certain types of DoS attacks. Thus, a full-blown DTLS handshake comprises up to 6 "flights" (i.e., logical message exchanges), each of which is then mapped on to one or more DTLS records using the segmentation and reassembly (SaR) scheme described in Section 4.2.3 of [RFC6347]. The overhead for said scheme is 6 bytes per handshake message which, given a realistic 10+ messages handshake, would amount to around 60 bytes across the whole handshake sequence.
DTLS在TLS[RFC5246]握手中增加了一个额外的往返，作为针对特定类型DoS攻击的保护返回路由性测试。因此，一个完整的DTLS握手包括多达6个“航班”（即逻辑消息交换），然后使用[RFC6347]第4.2.3节中描述的分段和重组（SaR）方案将每个航班映射到一个或多个DTLS记录。所述方案的开销是每个握手消息6字节，如果实际的10+个消息握手，则整个握手序列的开销将达到约60字节。
Note that the DTLS SaR scheme is defined for handshake messages only. In fact, DTLS records are never fragmented and MUST fit within a single transport layer datagram.
请注意，DTLS SaR方案仅为握手消息定义。事实上，DTLS记录从来都不是碎片化的，必须适合于单个传输层数据报。
SMS provides an optional segmentation and reassembly scheme as well, known as Concatenated short messages (see Section 9.2.3.24.1 of [GSM-SMS]). However, since the SaR scheme in DTLS cannot be circumvented, the Concatenated short messages mechanism SHOULD NOT be used during handshake to avoid redundant overhead. Before starting the handshake phase (either actively or passively), the DTLS implementation MUST be explicitly configured with the Path MTU (PMTU) of the SMS transport in order to correctly instrument its SaR function. The PMTU SHALL be 133 bytes if multiplexing based on the Wireless Datagram Protocol (WDP) is used (see Appendix A.3); 140 bytes otherwise.
SMS还提供可选的分段和重组方案，称为串联短消息（见[GSM-SMS]第9.2.3.24.1节）。然而，由于DTLS中的SaR方案无法规避，因此在握手期间不应使用级联短消息机制以避免冗余开销。在开始握手阶段（主动或被动）之前，必须使用SMS传输的路径MTU（PMTU）明确配置DTLS实现，以便正确地检测其SaR功能。如果使用基于无线数据报协议（WDP）的多路复用，则PMTU应为133字节（见附录A.3）；否则为140字节。
It is RECOMMENDED that the established security context over the longest possible period be used (possibly until a Closure Alert message is received or after a very long inactivity timeout) to avoid the expensive re-establishment of the security association.
建议在尽可能长的时间内使用已建立的安全上下文（可能在收到关闭警报消息之前或在很长的非活动超时之后），以避免代价高昂的重新建立安全关联。
The content of an SMS message is carried in the TP-UserData field, and its size may be up to 140 bytes. As already mentioned in Appendix A.1, longer (i.e., up to 34170 bytes) messages can be sent using Concatenated SMS.
SMS消息的内容包含在TP UserData字段中，其大小可能高达140字节。正如附录A.1中已经提到的，更长（即最多34170字节）的消息可以使用串联SMS发送。
This scheme consumes 6-7 bytes (depending on whether the short or long segmentation format is used) of the TP-UserData field, thus reducing the space available for the actual content of the SMS message to 133-134 bytes per TPDU.
此方案消耗TP UserData字段的6-7字节（取决于使用的是短分段格式还是长分段格式），从而将SMS消息的实际内容的可用空间减少到每个TPDU 133-134字节。
Though in principle a PMTU value higher than 140 bytes could be used, which may look like an appealing option given its more efficient use of the transport, there are disadvantages to consider. First, there is an additional overhead of 7 bytes per TPDU to be paid to the SaR function (which is in addition to the overhead introduced by the DTLS SaR mechanism. Second, some networks only partially support the Concatenated SMS function, and others do not support it at all.
虽然原则上可以使用高于140字节的PMTU值，但考虑到其更有效地使用传输，这可能看起来是一个吸引人的选择，但有一些缺点需要考虑。首先，每个TPDU要向SaR功能支付7字节的额外开销（这是DTLS SaR机制引入的开销之外的开销）。其次，一些网络仅部分支持串联SMS功能，而其他网络则根本不支持它。
For these reasons, the Concatenated short messages mechanism SHOULD NOT be used, and it is RECOMMENDED to leave the same PMTU settings used during the handshake phase, i.e., 133 bytes if WDP-based multiplexing is enabled; 140 bytes otherwise.
出于这些原因，不应使用级联短消息机制，建议保留握手阶段使用的相同PMTU设置，即，如果启用基于WDP的多路复用，则为133字节；否则为140字节。
Note that, after the DTLS handshake has completed, any fragmentation and reassembly logic that pertains the application layer (e.g., segmenting CoAP messages into DTLS records and reassembling them after the crypto operations have been successfully performed) needs to be handled by the application that uses the established DTLS tunnel.
请注意，在DTLS握手完成后，属于应用层的任何分段和重新组装逻辑（例如，将CoAP消息分段为DTLS记录，并在成功执行加密操作后重新组装）都需要由使用已建立DTLS隧道的应用程序处理。
Unlike IPsec Encapsulating Security Payload (ESP) / Authentication Header (AH), DTLS records do not contain any association identifiers. Applications must arrange to multiplex between associations on the same endpoint which, when using UDP/IP, is usually done with the host/port number.
与IPsec封装安全负载（ESP）/身份验证头（AH）不同，DTLS记录不包含任何关联标识符。应用程序必须安排在同一端点上的关联之间进行多路复用，这在使用UDP/IP时通常是通过主机/端口号完成的。
If the DTLS server allows more than one client to be active at any given time, then the Wireless Application Protocol (WAP) User Datagram Protocol [WAP-WDP] can be used to achieve multiplexing of the different security associations. (The use of WDP provides the additional benefit that upper-layer protocols can operate independently of the underlying wireless network, hence achieving application-agnostic transport handover.)
如果DTLS服务器允许多个客户端在任何给定时间处于活动状态，则可以使用无线应用协议（WAP）用户数据报协议[WAP-WDP]来实现不同安全关联的多路复用。（WDP的使用提供了额外的好处，即上层协议可以独立于底层无线网络运行，从而实现应用程序无关的传输切换。）
The total overhead cost for encoding the WDP source and destination ports is either 5 or 7 bytes out of the total available for the SMS content depending on if 1-byte or 2-byte port identifiers are used, as shown in Figures 13 and 14.
编码WDP源端口和目标端口的总开销成本是SMS内容可用总开销的5或7字节，具体取决于使用的是1字节或2字节端口标识符，如图13和14所示。
0 1 2 3 4
+--------+--------+--------+--------+--------+
| ... | 0x04 | 2 | ... | ... |
+--------+--------+--------+--------+--------+
UDH IEI IE Dest Source
Length Length Port Port
0 1 2 3 4
+--------+--------+--------+--------+--------+
| ... | 0x04 | 2 | ... | ... |
+--------+--------+--------+--------+--------+
UDH IEI IE Dest Source
Length Length Port Port
Legend: UDH = user data header IEI = information element identifier
图例：UDH=用户数据头IEI=信息元素标识符
Figure 13: Application Port Addressing Scheme (8-Bit Address)
图13：应用程序端口寻址方案（8位地址）
0 1 2 3 4 5 6
+--------+--------+--------+--------+--------+--------+--------+
| ... | 0x05 | 4 | ... | ... |
+--------+--------+--------+--------+--------+--------+--------+
UDH IEI IE Dest Source
Length Length Port Port
0 1 2 3 4 5 6
+--------+--------+--------+--------+--------+--------+--------+
| ... | 0x05 | 4 | ... | ... |
+--------+--------+--------+--------+--------+--------+--------+
UDH IEI IE Dest Source
Length Length Port Port
Figure 14: Application Port Addressing Scheme (16-Bit Address)
图14：应用程序端口寻址方案（16位地址）
The receiving side of the communication gets the source address from the originator address (TP-OA) field of the SMS-DELIVER TPDU. This way, a unique 4-tuple identifying the security association can be reconstructed at both ends. (When replying to its DTLS peer, the sender will swap the TP-OA and destination address (TP-DA) parameters and the source and destination ports in the WDP.)
通信的接收端从SMS-DELIVER TPDU的发起者地址（TP-OA）字段获取源地址。这样，可以在两端重建标识安全关联的唯一4元组。（应答DTLS对等方时，发送方将交换TP-OA和目标地址（TP-DA）参数以及WDP中的源端口和目标端口。）
If SMS-STATUS-REPORT messages are enabled, their receipt is not to be interpreted as the signal that the specific handshake message has been acted upon by the receiving party. Therefore, it MUST NOT be taken into account by the DTLS timeout and retransmission function.
如果启用了SMS-STATUS-REPORT消息，则其接收不会被解释为接收方已对特定握手消息采取行动的信号。因此，DTLS超时和重传功能不能将其考虑在内。
Handshake messages MUST carry a validity period (TP-VP parameter in a SMS-SUBMIT TPDU) that is not less than the current value of the retransmission timeout. In order to avoid persisting messages in the network that will be discarded by the receiving party, handshake messages SHOULD carry a validity period that is the same as, or just slightly higher than, the current value of the retransmission timeout.
握手消息的有效期（SMS-SUBMIT TPDU中的TP-VP参数）必须不小于重传超时的当前值。为了避免在网络中持久化将被接收方丢弃的消息，握手消息的有效期应与重传超时的当前值相同或略高。
Figure 15 shows the overhead for the DTLS record layer for protecting data traffic when AES-128-CCM with an 8-octet Integrity Check Value (ICV) is used.
图15显示了当使用具有8个八位组完整性检查值（ICV）的AES-128-CCM时，用于保护数据流量的DTLS记录层的开销。
DTLS Record Layer Header................13 bytes
Nonce (Explicit).........................8 bytes
ICV..................................... 8 bytes
------------------------------------------------
Overhead................................29 bytes
------------------------------------------------
DTLS Record Layer Header................13 bytes
Nonce (Explicit).........................8 bytes
ICV..................................... 8 bytes
------------------------------------------------
Overhead................................29 bytes
------------------------------------------------
Figure 15: AES-128-CCM-8 DTLS Record Layer Per-Packet Overhead
图15:AES-128-CCM-8每个数据包开销的DTLS记录层
The DTLS record layer header has 13 octets and consists of:
DTLS记录层标头有13个八位字节，包括：
o 1-octet content type field,
o 1-八位字节内容类型字段，
o 2-octet version field,
o 2-八位字节版本字段，
o 2-octet epoch field,
o 2-octet历元字段，
o 6-octet sequence number, and
o 6-八位组序列号，以及
o 2-octet length field.
o 2-八位组长度字段。
The "nonce" input to the AEAD algorithm is exactly that of [RFC5288], i.e., 12 bytes long. It consists of two values, namely a 4-octet salt and an 8-octet nonce_explicit:
AEAD算法的“nonce”输入正好是[RFC5288]的输入，即12字节长。它由两个值组成，即4-八位元盐和8-八位元非显式：
The salt is the "implicit" part and is not sent in the packet. Instead, the salt is generated as part of the handshake process.
盐是“隐含”部分，不在包中发送。相反，盐是作为握手过程的一部分生成的。
The nonce_explicit value is 8 octets long and it is chosen by the sender and carried in each TLS record. RFC 6655 [RFC6655] allows the nonce_explicit to be a sequence number or something else. This document makes this use more restrictive for use with DTLS: the 64-bit none_explicit value MUST be the 16-bit epoch concatenated with the 48-bit seq_num. The sequence number component of the nonce_explicit field at the AES-CCM layer is an exact copy of the sequence number in the record layer header field. This leads to a duplication of 8-bytes per record.
nonce_显式值的长度为8个八位字节，由发送方选择并携带在每个TLS记录中。RFC 6655[RFC6655]允许nonce_显式为序列号或其他内容。本文档对DTL的使用更具限制性：64位none_显式值必须是16位历元，并与48位seq_num串联。AES-CCM层nonce_显式字段的序列号组件是记录层标头字段中序列号的精确副本。这会导致每个记录重复8个字节。
To avoid this 8-byte duplication, RFC 7400 [RFC7400] provides help with the use of the generic header compression technique for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs). Note that this header compression technique is not available when DTLS
为了避免这种8字节的重复，RFC 7400[RFC7400]提供了在低功耗无线个人区域网络（6LoWPANs）上使用IPv6通用报头压缩技术的帮助。请注意，当DTLS出现时，此标头压缩技术不可用
is exchanged over transports that do not use IPv6 or 6LoWPAN, such as the SMS transport described in Appendix A of this document.
通过不使用IPv6或6LoWPAN的传输进行交换，如本文档附录A中所述的SMS传输。
Section 4.2.3 of [RFC6347] advises DTLS implementations to not produce overlapping fragments. However, it requires receivers to be able to cope with them. The need for the latter requisite is explained in Section 4.1.1.1 of [RFC6347]: accurate PMTU estimation may be traded for shorter handshake completion time.
[RFC6347]第4.2.3节建议DTLS实现不要产生重叠片段。然而，它要求接收者能够处理这些问题。[RFC6347]第4.1.1.1节解释了后一个必要条件的必要性：准确的PMTU估计值可以换取更短的握手完成时间。
In many cases, the cost of handling fragment overlaps has proved to be unaffordable for constrained implementations, particularly because of the increased complexity in buffer management.
在许多情况下，处理片段重叠的成本对于受约束的实现来说是无法承受的，特别是因为缓冲区管理的复杂性增加了。
In order to reduce the likelihood of producing different fragment sizes and consequent overlaps within the same handshake, this document RECOMMENDs:
为了减少在同一握手中产生不同片段大小和随后重叠的可能性，本文件建议：
o clients (handshake initiators) to use reliable PMTU information for the intended destination; and
o 客户端（握手发起者）为预期目的地使用可靠的PMTU信息；和
o servers to mirror the fragment size selected by their clients.
o 服务器镜像其客户端选择的片段大小。
The PMTU information comes from either a "fresh enough" discovery performed by the client [RFC1981] [RFC4821] or some other reliable out-of-band channel.
PMTU信息来自客户机[RFC1981][RFC4821]执行的“足够新鲜”的发现或其他可靠的带外信道。
Acknowledgments
致谢
Thanks to Derek Atkins, Paul Bakker, Olaf Bergmann, Carsten Bormann, Ben Campbell, Brian Carpenter, Robert Cragie, Spencer Dawkins, Russ Housley, Rene Hummen, Jayaraghavendran K, Sye Loong Keoh, Matthias Kovatsch, Sandeep Kumar, Barry Leiba, Simon Lemay, Alexey Melnikov, Gabriel Montenegro, Manuel Pegourie-Gonnard, Akbar Rahman, Eric Rescorla, Michael Richardson, Ludwig Seitz, Zach Shelby, Michael StJohns, Rene Struik, Tina Tsou, and Sean Turner for their helpful comments and discussions that have shaped the document.
感谢德里克·阿特金斯、保罗·巴克尔、奥拉夫·伯格曼、卡斯滕·鲍曼、本·坎贝尔、布莱恩·卡彭特、罗伯特·克雷吉、斯宾塞·道金斯、罗斯·霍斯利、雷内·哈门、贾亚拉格汉德兰·K、赛隆·基奥、马蒂亚斯·科瓦奇、桑德普·库马尔、巴里·莱巴、西蒙·勒梅、阿列克谢·梅尔尼科夫、加布里埃尔·黑山、曼努埃尔·佩古里·冈纳德、阿克巴·拉赫曼、埃里克·雷索拉，Michael Richardson、Ludwig Seitz、Zach Shelby、Michael StJohns、Rene Struik、Tina Tsou和Sean Turner对形成该文件的有益评论和讨论表示感谢。
A big thanks also to Klaus Hartke, who wrote the initial draft version of this document.
还要感谢克劳斯·哈特克，他编写了这份文件的初稿。
Finally, we would like to thank our area director (Stephen Farrell) and our working group chairs (Zach Shelby and Dorothy Gellert) for their support.
最后，我们要感谢我们的区域主任（Stephen Farrell）和工作组主席（Zach Shelby和Dorothy Gellert）的支持。
Authors' Addresses
作者地址
Hannes Tschofenig (editor) ARM Ltd. 110 Fulbourn Rd Cambridge CB1 9NJ United Kingdom
Hannes Tschofenig（编辑）ARM有限公司位于英国剑桥CB1 9NJ富尔伯恩路110号
Email: Hannes.tschofenig@gmx.net
URI: http://www.tschofenig.priv.at
Email: Hannes.tschofenig@gmx.net
URI: http://www.tschofenig.priv.at
Thomas Fossati Nokia 3 Ely Road Milton, Cambridge CB24 6DD United Kingdom
英国剑桥CB24 6DD米尔顿伊利路3号托马斯·福萨蒂诺基亚
Email: thomas.fossati@nokia.com
Email: thomas.fossati@nokia.com