9. 安全 (Security)
下层协议最终可能为 RTP 应用的各类需求提供全部所需的安全服务, 包括认证 (authentication)、完整性 (integrity) 和机密性 (confidentiality)。这些服务已在 [27] 中为 IP 做了规定。由于最初使用 RTP 的音频和视频应用, 在 IP 层提供此类服务之前就需要机密性服务, 因此在下一节中为该服务定义了与 RTP 和 RTCP 一起使用的机密性服务。此处包含该描述以将现有实践编入规范。RTP 的新应用 MAY 为了实现向后兼容性而实现此 RTP 特定的机密性服务, 和/或 MAY 实现替代的安全服务。该机密性服务在 RTP 协议上的开销很低, 因此即便将来该服务被其他服务废弃, 代价也会很小。
或者, 将来也可以为 RTP 定义其他服务、其他服务的实现以及其他算法。特别是, 一个名为安全实时传输协议 (Secure Real-time Transport Protocol, SRTP) [28] 的 RTP 配置文件正在制定中, 用于在保持 RTP 头部明文的同时提供 RTP 负载的机密性, 以便链路级头部压缩算法仍能运作。预期 SRTP 将成为许多应用的正确选择。SRTP 基于高级加密标准 (Advanced Encryption Standard, AES), 并提供比此处所述服务更强的安全性。本文不声称此处所给出的方法适合某种特定的安全需求。一个配置文件可以规定应用应当提供哪些服务和算法, 并可就它们的恰当使用提供指导。
密钥分发与证书不在本文档范围内。
9.1 机密性 (Confidentiality)
机密性意味着只有预期的接收方才能解码所接收到的包; 对于其他人, 该包不含任何有用信息。内容的机密性通过加密实现。
当希望按照本节所规定的方法对 RTP 或 RTCP 进行加密时, 所有将被封装以便在一个单个下层包中传输的字节 (octet), 都作为一个单元被加密。对于 RTCP, 必须为每个单元重新抽取一个 32 位随机数, 并在加密前作为前缀附加到该单元之前。对于 RTP, 不附加前缀; 取而代之, 序列号和时间戳字段以随机偏移进行初始化。这被认为是一个较弱的初始化向量 (initialization vector, IV), 因为其随机性特性较差。此外, 如果紧随其后的 SSRC 字段可以被敌方操纵, 该加密方法还会进一步变弱。
对于 RTCP, 一种实现 MAY 将复合 RTCP 包中的各个 RTCP 包分隔为两个独立的复合 RTCP 包, 一个加密, 一个以明文发送。例如, SDES 信息可以被加密, 而接收报告以明文发送, 以适应那些未掌握加密密钥的第三方监视器。在图 4 所描绘的示例中, SDES 信息 MUST 被附加到一个不含报告的 RR 包 (以及随机数) 之后, 以满足所有复合 RTCP 包都以 SR 或 RR 包开头的要求。SDES CNAME 项在加密或非加密包中都需要, 但不需要同时出现在两者中。相同的 SDES 信息 SHOULD NOT 同时携带于两个包中, 因为这样可能破坏加密。
UDP packet UDP packet
[random][RR][SDES #CNAME ...] [SR #senderinfo #site1 #site2]
encrypted not encrypted
#: SSRC identifier
Figure 4: Encrypted and non-encrypted RTCP packets
加密的存在以及对正确密钥的使用, 由接收方通过头部或负载的有效性检查来确认。RTP 和 RTCP 头部此类有效性检查的示例见附录 A.1 和 A.2。
为了与 RFC 1889 中 RTP 初始规范的现有实现保持一致, 默认的加密算法是密码块链接 (cipher block chaining, CBC) 模式下的数据加密标准 (Data Encryption Standard, DES) 算法, 如 RFC 1423 [29] 第 1.1 节所述, 但填充到 8 字节的整数倍按第 5.1 节中针对 P 位所描述的方式指示。初始化向量为零, 因为随机值在 RTP 头部中给出, 或在复合 RTCP 包中由随机前缀给出。关于 CBC 初始化向量使用的详细信息, 见 [30]。
支持此处所规定加密方法的实现, SHOULD 始终支持 CBC 模式下的 DES 算法作为该方法的默认密码, 以最大化互操作性。选择该方法是因为它已被证明在 Internet 上运行的实验性音频和视频工具中易于且实用。然而, 此后 DES 被发现过于容易被破解。
RECOMMENDED 使用更强的加密算法 (如三重 DES (Triple-DES)) 来替代默认算法。此外, 安全的 CBC 模式要求每个包的第一个块都与一个大小等于密码块尺寸的随机、独立的 IV 进行异或。对于 RTCP, 这 (部分地) 通过给每个包附加一个 32 位随机数 (为每个包独立选取) 来实现。对于 RTP, 时间戳和序列号从随机值开始, 但连续的包不会被独立随机化。应当注意, 两种情形 (RTP 和 RTCP) 下的随机性都是有限的。高安全性应用 SHOULD 考虑其他更常规的保护手段。其他加密算法 MAY 由非 RTP 手段为某个会话动态地规定。特别是, 基于 AES 的 SRTP 配置文件 [28] 正在制定中, 以考虑已知的明文和 CBC 明文操纵问题, 并且将来会是正确的选择。
作为上述 IP 层或 RTP 层加密的一种替代, 配置文件 MAY 为加密后的编码定义额外的负载类型。这些编码 MUST 规定如何处理填充以及加密的其他方面。此方法允许只加密数据, 而将头部保留为明文, 适用于需要如此的应用。对于那些既要处理解密又要处理解码的硬件设备, 它可能特别有用。对于那些希望进行 RTP 与下层头部的链路级压缩、并且负载 (而非地址) 的机密性已足够 (因为加密头部会妨碍压缩) 的应用, 它也很有价值。
9.2 认证与消息完整性 (Authentication and Message Integrity)
RTP 层面未定义认证和消息完整性服务, 因为若没有密钥管理基础设施, 这些服务将无法直接实现。预期认证和完整性服务将由下层协议提供。