5. Establishing a Secure Channel (建立安全信道)

交换中的两个端点在 DTLS 握手过程中以证书形式呈现其身份. 本文档中证书的用法与《会话描述协议 (SDP) 中基于面向连接媒体的传输层安全 (TLS) 协议传输》[RFC4572] 中的描述一致.

若使用自签名证书, 证书内 subjectAltName 属性的内容可以使用用户的统一资源标识符 (uniform resource identifier, URI). 这仅便于调试, 并不要求将证书绑定到某一通信端点. 证书的完整性通过 SDP 中的 fingerprint 属性保证. subjectAltName 不是证书验证的重要组成.

公钥/私钥对的生成成本相对较高. 不要求端点为每个会话都生成证书.

[RFC3264] 定义的 offer/answer 模型由会话发起协议 (SIP) [RFC3261] 等协议用于建立多媒体会话. 除常规 SDP [RFC4566] 消息内容外, 每个媒体描述 ("m=" 行及其参数) 还将包含 [RFC5764], [RFC4145] 与 [RFC4572] 规定的若干属性.

当某端点希望与另一端点建立安全媒体会话时, 它通过 SIP 消息向对方发送 offer. 该 offer 在 SDP 载荷中包含该端点拟使用证书的指纹. 端点应当 (SHOULD) 在完整性保护信道上将含 offer 的 SIP 消息发送给 offerer 的 SIP 代理. 代理应当 (SHOULD) 按 [RFC4474] 所述程序添加 Identity 头字段. 含 offer 的 SIP 消息应当 (SHOULD) 在完整性保护信道上发送给 offerer 的 SIP 代理. 远端端点收到 SIP 消息后, 可使用 Identity 头字段验证发送方身份. 由于 Identity 头字段是对若干 SIP 头字段以及 SIP 消息体的数字签名, 接收方还可确信数字签名应用并加入 SIP 消息后消息未被篡改.

远端端点 (answerer) 现在可与 offerer 建立 DTLS 关联; 或者, 它也可以在 answer 中表明由 offerer 发起 TLS 关联. 无论哪种情况, 均使用基于证书的相互 DTLS 认证. DTLS 握手完成后, 关于已认证身份的信息 (包括证书) 将提供给端点应用. answerer 随后可验证 DTLS 握手中用于认证的 offerer 证书能否与 offer 中 SDP 所含证书指纹对应. 此时 answerer 可向最终用户指示媒体已受保护. offerer 对 answerer 证书可能只能暂时接受, 因为可能尚未收到 answerer 的证书指纹.

answerer 接受 offer 时, 向 offerer 返回包含 answerer 证书指纹的 answer. 此时 offerer 可接受或拒绝对等方证书, 并向最终用户指示媒体已受保护.

注意: 保护媒体流量的全部认证与密钥交换均在媒体路径上通过 DTLS 完成. 信令路径仅用于验证对等方证书指纹.

offer 与 answer 必须符合以下要求.

• 端点必须使用 [RFC4145] 定义的 setup 属性. 作为 offerer 的端点必须使用 setup:actpass, 并准备在收到 answer 之前接收 client_hello. answerer 必须使用 setup:active 或 setup:passive. 注意: 若 answerer 使用 setup:passive, 则 DTLS 握手要到 answer 到达后才会开始, 会增加时延. setup:active 允许 answer 与 DTLS 握手并行进行. 因此推荐 (RECOMMENDED) 使用 setup:active. 作为 active 的一方必须在每条流 (主机/端口四元组) 上通过发送 ClientHello 发起 DTLS 握手.

• 端点不得使用 [RFC4145] 定义的 connection 属性.

• 端点必须按 [RFC4572] 使用证书指纹属性.

• DTLS 握手中呈现的证书必须与信令路径 SDP 中交换的指纹一致. 该机制的安全属性见第 8 节.

• 若指纹与哈希后的证书不一致, 端点必须立即拆除媒体会话. 注意: 允许等到收到对方指纹后再建立连接; 但这可能带来不希望的时延影响.