9 安全CoAP

本章节定义CoAP中的DTLS绑定。 在配置阶段，要为CoAP设备提供它需要的安全信息，包括密钥卡片和访问控制表。本规范在9.1.3.2.1中定义了RawPublicKey模式下的配置。在配置的最后阶段，设备会处于下面四种安全模式下的一种，并带有模式的附属信息。本规范中NoSec和RawPublicKey模式都是强制执行的。

• NoSec：没有协议层的安全(禁用DTLS)。合适的情况下，应当使用其他技术来提供底层的安全机制。在[IPsec-CoAP]中讨论IPsec的使用。某些使用受限节点的链路层也提供链路层安全机制，它可能适用于合适的密钥管理。

• PreSharedKey：DTLS被启用，有一个预先共享的密钥列表[RFC4279]，而且每个密钥都包括节点列表(参见9.1.3.1节)。极端情况下，一个密钥对应一个节点(1:1 node/key比例)。如果两个以上的实体共享一个特定的预先共享密钥，那么该密钥只把实体认证为那个组的成员，而不是单独的一个对象。

• RawPublicKey：DTLS被启用，设备有一个非对称密匙对，但是没有证书（一个原始公钥），它是使用out-of-band机制[RFC7250]来验证的，如9.1.3.2节中所述。该设备也有一个从公钥计算来的身份和一个可以沟通的节点的身份列表。

• Certificate:DTLS被启用，设备有一个带有X.509证书[RFC5280]的非对称密钥对，与它的目录绑定，并由一些常见的受信任的根证书颁发机构颁发，如9.1.3.3节所述。设备也有根信任锚的列表，可用于验证证书。

在“NoSec”模式下，系统只需向某个IP和端口发送带"coap" scheme头的UDP数据包即可。但只有当攻击者不能利用CoAP节点收发包时才是安全的；在11.5节中有关于这个问题的附加描述。

另外3种安全模式都利用DTLS实现，并且由“coaps” scheme和DTLS下的CoAP默认端口标识。这是是一个能用于认证(带有安全模型的限制)的安全关联，基于这个认证，可以授权其他的通信端。CoAP本身不提供用于认证或者授权的协议原语；当需要的时候，由通信安全(比如IPSec或DTLS)或者对象安全(带有负载)提供。在特定操作需要认证的设备通常使用这两种安全方式。在涉及中间人的地方，只有当中间人是信任体系中的一部分时才能保证通信安全。CoAP并没有提供一种方法来转发不同级别的授权，客户端可能与其他中间人或原始服务器有这些授权，因此可能需要在第一个中间人的时候就要执行所有授权。