用于封装安全载荷 (ESP) 中的基于计数器的密码的隐式初始化向量 (IV)

RFC8750：Implicit Initialization Vector (IV) for Counter-Based Ciphers in Encapsulating Security Payload (ESP)，March 2020

梗概

封装安全载荷 (Encapsulating Security Payload，ESP) 在每个数据包中发送一个初始化向量 (initialization vector，IV)。IV 的大小取决于应用的变换，对于编写本文档时定义的变换，通常为 8 或 16 个八位字节。与 IPsec 一起使用时，一些算法，例如 AES-GCM、AES-CCM 和 ChaCha20-Poly1305，采用 IV 生成一个随机数，用作加密和解密的输入参数。这个 IV 必须是唯一的，但可以预测。因此，可以使用 ESP 序列号 (Sequence Number，SN) 中提供的值来生成随机数。在 AES-GCM、AES-CCM 和 ChaCha20-Poly1305 的情况下，这避免了发送 IV 本身并为每个数据包节省 8 个八位字节。本文档介绍了如何执行此操作。

本备忘录的状态

这是一个 Internet 标准跟踪文档。

本文档是 Internet 工程任务组 (IETF) 的产品。它代表了 IETF 社区的共识。它已接受公众审查，并已被互联网工程指导小组 (IESG) 批准出版。有关 Internet 标准的更多信息，请参见 RFC 7841 的第 2 节。

有关本文档当前状态、任何勘误以及如何提供反馈的信息，请访问 https://www.rfc-editor.org/info/rfc8750。

版权声明

版权所有 (c) 2020 IETF Trust 和确定为文档作者的人员。版权所有。

本文档受 BCP 78 和 IETF 信托与 IETF 文档相关的法律规定 (https://trustee.ietf.org/license-info) 的约束，该条款自本文档发布之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文档中提取的代码组件必须包含 Trust Legal Provisions 第 4.e 节中所述的简化 BSD 许可文本，并且不提供如简化 BSD 许可中所述的保证。

1、 介绍

基于计数器的 AES 操作模式，例如 AES-CCM [RFC4309] 和 AES-GCM [RFC4106]，需要为每个 ESP 数据包指定一个随机数。这同样适用于 ChaCha20-Poly1305 [RFC7634]。目前，由于每个 ESP 数据包 [RFC4303] 中提供的初始化向量 (IV)，生成此随机数。这种做法在本文件中被指定为“显式 IV”。

在某些情况下，例如物联网 (Internet of Things，IoT)，最好避免携带与 IV 关联的额外字节，而是在每个对等体本地生成它。IV 的本地生成在本文档中被指定为“隐式 IV”。

这个 IV 的大小取决于具体的算法，但上面提到的所有算法都采用 8 个八位字节的 IV。

本文档定义了在隐式时如何在本地计算 IV。它还指定了对等方如何同意 Internet 密钥交换版本 2 (IKEv2) [RFC7296] 关于使用隐式 IV 与显式 IV。

本文档将其范围限制为上述算法。其他具有类似属性的算法可能会在以后定义为使用类似的机制。

本文档不考虑 AES-CBC [RFC3602]，因为 AES-CBC 要求 IV 不可预测。如下所述直接从数据包计数器中获取它是不安全的，如 [RFC3602] 的第 6 节所述，并导致了现实世界中选择的明文攻击，例如 BEAST [BEAST]。

本文档不考虑 AES-CTR [RFC3686]，因为它侧重于 [RFC8221] 中提供的推荐的带有关联数据的身份验证加密 (Authenticated Encryption with Associated Data，AEAD) 套件。

2、 需求符号

关键词“MUST”、“MUST NOT”、“REQUIRED”、“SHALL”、“SHALL NOT”、“SHOULD”、“SHOULD NOT”、“RECOMMENDED”、“NOT RECOMMENDED”、“MAY”和“OPTIONAL” 当且仅当它们以所有大写字母出现时，本文档中的内容将按照 BCP 14 [RFC2119] [RFC8174] 中的描述进行解释，如此处所示。

3、 术语

IoT：Internet of Things，物联网

IV：Initialization Vector，初始化向量

IIV：Implicit Initialization Vector，隐式初始化向量

Nonce：固定大小的八位字节字符串，只使用一次。在本文档中，IV 用于生成加密/解密的随机数输入。

4、 隐式 IV

对于第 1 节中列出的算法，对于给定的密钥，8 字节的 IV 不得重复。ESP 数据包与其 IV 之间的绑定是使用序列号或扩展序列号提供的。图 1 和图 2 分别表示具有常规 4 字节序列号和 8 字节扩展序列号的 IV。

图 1：具有 4 字节序列号的隐式 IV

Sequence Number：序列号，ESP 数据包中携带的 4 字节序列号。

Zero：零，所有位都设置为零的 4 字节数组。

图 2：具有 8 字节扩展序列号的隐式 IV

Extended Sequence Number：扩展序列号，安全联盟的 8 字节扩展序列号。ESP 数据包中携带四个低位字节。

本文档仅定义了 AES-GCM 的[RFC4106]、AES-CCM 的[RFC4309]和ChaCha20-Poly1305 的[RFC7634]中定义的算法的IV 生成。这些算法的所有其他方面和参数都保持不变，并按照各自规范中的定义使用。

5、 IKEv2 发起者行为

支持此功能的发起者应该在 IKEv2 交换中的安全联盟 (Security Association，SA) 载荷内的提议子结构的转换类型 1（加密算法）子结构中提议隐式 IV（IIV）算法。为了促进与非支持对等体的向后兼容性，发起者还应该包括那些具有显式 IV 的相同算法作为单独的转换。

6、 IKEv2 响应者行为

SA 载荷处理的规则要求响应者从发起者发送的提议中选择其算法，从而确保响应者永远不会将包含 IIV 变换的 SA 载荷发送给未提出它的发起者。

7、 安全考虑

这些算法的随机数生成尚未明确定义。只要满足某些安全要求，它就留给了实现。通常，对于 AES-GCM、AES-CCM 和 ChaCha20-Poly1305，不允许对一个特定密钥重复 IV。本文档提供了一种明确且规范的方式来生成 IV。本文档中描述的机制满足所有相关算法的 IV 安全要求。

由于当使用计数器模式密码时，IV 不得为一个 SA 重复，因此本文档中描述的隐式 IV 不得用于设置中，序列号可能与一个 SA 重叠。对于不使用扩展序列号的 SA，在传输第 2^32 个数据包之前，以及在传输使用扩展序列号的 SA 的第 2^64 个数据包。这可以防止普通点对点情况下的序列号重叠。[RFC5374]、[RFC6407] 和 [G-IKEv2] 中描述的组播是一个突出的例子，其中许多发送者共享一个密钥，因此共享一个 SA。因此，如果采用了一些机制来防止序列号对于一个 SA 重叠，则隐式 IV 只能与组播一起使用；否则，隐式 IV 不得与组播一起使用。

本文档定义了三个使用隐式 IV 的新加密转换。与迄今为止定义的大多数加密转换（可同时用于 ESP 和 IKEv2）不同，这些转换仅针对 ESP 定义，不能在 IKEv2 中使用。原因是 IKEv2 消息不包含可用于 IV 生成的每个消息的唯一值。IKEv2 头中的 Message-ID 字段类似于 ESP 头中的 SN 字段，但最近的 IKEv2 扩展 [RFC6311] [RFC7383] 确实允许它重复，因此没有一种简单的方法可以从 IKEv2 头中导出唯一的 IV领域。

8、 IANA 考虑

IANA 已更新“互联网密钥交换版本 2 (Internet Key Exchange Version 2，IKEv2) 参数”注册表 [RFC7296]，将以下新代码点添加到“转换类型值”注册表 [IANA] 下的“转换类型 1 - 加密算法转换 ID”子注册表中：

表 1：对“转换类型 1 - 加密算法转换 ID”注册表的添加

9、 参考文献

9.1、 规范参考

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher Algorithm and Its Use with IPsec", RFC 3602, DOI 10.17487/RFC3602, September 2003, <https://www.rfc-editor.org/info/rfc3602>.
[RFC3686] Housley, R., "Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP)", RFC 3686, DOI 10.17487/RFC3686, January 2004, <https://www.rfc-editor.org/info/rfc3686>.
[RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)", RFC 4106, DOI 10.17487/RFC4106, June 2005, <https://www.rfc-editor.org/info/rfc4106>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, DOI 10.17487/RFC4303, December 2005, <https://www.rfc-editor.org/info/rfc4303>.
[RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload (ESP)", RFC 4309, DOI 10.17487/RFC4309, December 2005, <https://www.rfc-editor.org/info/rfc4309>.
[RFC5374] Weis, B., Gross, G., and D. Ignjatic, "Multicast Extensions to the Security Architecture for the Internet Protocol", RFC 5374, DOI 10.17487/RFC5374, November 2008, <https://www.rfc-editor.org/info/rfc5374>.
[RFC6311] Singh, R., Ed., Kalyani, G., Nir, Y., Sheffer, Y., and D. Zhang, "Protocol Support for High Availability of IKEv2/IPsec", RFC 6311, DOI 10.17487/RFC6311, July 2011, <https://www.rfc-editor.org/info/rfc6311>.
[RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain of Interpretation", RFC 6407, DOI 10.17487/RFC6407, October 2011, <https://www.rfc-editor.org/info/rfc6407>.
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2014, <https://www.rfc-editor.org/info/rfc7296>.
[RFC7383] Smyslov, V., "Internet Key Exchange Protocol Version 2 (IKEv2) Message Fragmentation", RFC 7383, DOI 10.17487/RFC7383, November 2014, <https://www.rfc-editor.org/info/rfc7383>.
[RFC7634] Nir, Y., "ChaCha20, Poly1305, and Their Use in the Internet Key Exchange Protocol (IKE) and IPsec", RFC 7634, DOI 10.17487/RFC7634, August 2015, <https://www.rfc-editor.org/info/rfc7634>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8221] Wouters, P., Migault, D., Mattsson, J., Nir, Y., and T. Kivinen, "Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 8221, DOI 10.17487/RFC8221, October 2017, <https://www.rfc-editor.org/info/rfc8221>.

9.2、 参考资料

[BEAST] Duong, T. and J. Rizzo, "Here Come The xor Ninjas", May 2011, <https://www.researchgate.net/publication/266529975_Here_Come_The_Ninjas>.
[G-IKEv2] Weis, B. and V. Smyslov, "Group Key Management using IKEv2", Work in Progress, Internet-Draft, draft-ietf-ipsecme-g-ikev2-00, 8 January 2020, <https://tools.ietf.org/html/draft-ietf-ipsecme-g-ikev2-00>.
[IANA] IANA, "Internet Key Exchange Version 2 (IKEv2) Parameters", <https://www.iana.org/assignments/ikev2-parameters>.

致谢

我们要感谢 Valery Smyslov、Éric Vyncke、Alexey Melnikov、Adam Roach 和 Magnus Nyström（安全局）以及我们的三个安全 AD——Eric Rescorla、Benjamin Kaduk 和 Roman Danyliw——的宝贵意见。我们还要感谢 David Schinazi 的实施以及 Tero Kivinen 和 David Waltermire（IPSECME 主席）推动这项工作。