Encrypt-then-MAC 在 tls与Dtls
简介
本文档描述了在（TLS）和（DTLS）中使用EtM安全机制代替现有的MtE机制的
一种协商使用的方法。MtE机制在多年的时间里一直是许多安全漏洞的主题。
此备忘录的状态
这是一个互联网标准跟踪文档。
本文档是互联网工程任务组（IETF）的产品。
它代表了IETF社群的共识。
它已经接受公众审查，并已获得互联网工程指导小组（IESG）的批准。
有关互联网标准的更多信息，请参见RFC 5741的第2节。
有关本文档的当前状态，任何勘误以及如何提供反馈的信息，
请访问。
版权声明
版权所有（c）2014 IETF信托和被识别为文档作者的人。 版权所有。
本文件受BCP 78和IETF信托有关IETF文件的法律规定（）的约束，
在本文件发布之日生效。 请仔细阅读这些文档，因为它们描述了您对本文档的权利和限制。
从本文档提取的代码组件必须包括简化BSD许可证文本，如信托法律规定的第4.e节所述，
并且不提供简化BSD许可证中所述的保证。
Gutmann Standards Track [Page 1]
--------------------------------------------------------------------------------
RFC 7366 Encrypt-then-MAC for TLS and DTLS September 2014
Table of Contents
1. 介绍 . . . . . . . . . . . . . . . . . 2
1.1. 本文档中使用的约定 . . . . . . . . . 2
2. EtM协商 . . . . . . . . . . . . . . . . 2
2.1. 理由 . . . . . . . . . . . . . . . . 3
3. EtM 应用. . . . . . . . . . . . . . . . 3
3.1. 重握手问题 . . . . . . .. . . . . . 5
4. 安全注意事项 . . . . . . . . . . . . . . 6
5. IANA 注意事项 . . . . . . . . . . . . . 6
6. 致谢 . . . . . . . . . . . . . . . . . 7
7. 参考 . . . . . . . . . . . . . . . . . 7
7.1. 规范性参考文献 . . . . . . . . . . . 7
7.2. 参考文献 . . . . . . . . . . . . . 7
1.介绍
TLS [2]和DTLS [4]使用MtE结构，这在20世纪90年代中期指定（SSL）协议时被认为是安全的，
但不再被认为是安全的 [5] [6]。 如在TLS和以后的DTLS中使用的MtE结构，长时间内
已经成为许多安全漏洞与攻击的主题。作为TLS / DTLS握手的一部分，该文档规定了切
换到更安全的EtM结构的方法，用以替代当前的MtE结构。
（在本文档中，“MAC”是指“消息验证码”。）
1.1。 本文档中使用的约定
本文档中的关键词“MUST”，“MUST NOT”，“REQUIRED”，“SHALL”，“SHALL NOT”，“SHOULD”，
“SHOULD NOT”，“RECOMMENDED”，“MAY”和“OPTIONAL” 解释如[1]中所述。
2.协商EtM
EtM的使用通过如TLS [2]中定义的TLS / DTLS扩展来协商。
在连接时，如果客户端希望使用encrypt-then-MAC而不是默认的MAC-then-encrypt，
则客户端在其client_hello中包含encrypt_then_mac扩展。
如果服务器能够满足这个要求，它会回应一个encrypt_then_mac在其server_hello。
此扩展的“extension_type”值应为22（0x16），并且此扩展的“extension_data”字段应为空。
客户端和服务器不得使用encrypt-then-MAC，除非双方已成功交换encrypt_then_mac扩展。
Gutmann Standards Track [Page 2]
--------------------------------------------------------------------------------
RFC 7366 Encrypt-then-MAC for TLS and DTLS September 2014
2.1。理由
使用TLS / DTLS扩展来协商整体交换机比定义新的密码套件更可取，
因为后者会导致套件的笛卡尔爆炸，可能需要用新的使用加密然后MAC的套件复制每个现有的套件。
相比之下，这里提出的方法只需要一个新的扩展类型，
具有由客户端和服务器发送的对应的最小长度扩展。
引入encrypt-then-MAC的另一种可能性是使其成为TLS 1.3的一部分;
然而，这将需要所有的TLS 1.2实现和部署，只是为了支持按照加密和MAC的顺序进行简单的代码更改。
相反，通过TLS / DTLS扩展机制部署encrypt-then-MAC需要在一个实现中更改少于十几行代码
（不包括新扩展类型的处理，这是另外50行代码行）。
扩展的使用排除了与SSL 3.0的使用，但是很可能仍然使用该协议的任何数量的其他攻击几乎已经有二十年了，所以似乎没有什么意义，
容纳SSL 3.0。
3. 应用 Encrypt-then-MAC
一旦使用encrypt-then-MAC已经协商，处理
TLS / DTLS数据包的从标准：
encrypt（data|| MAC || pad）
切换到新：
encrypt（data || pad）|| MAC
其中MAC覆盖整个分组直到MAC值的开始。
在TLS [2]符号中，没有显式初始化向量（IV）的TLS 1.0的MAC计算是：
MAC（MAC_write_key，seq_num +
TLSCipherText.type +
TLSCipherText.version +
TLSCipherText.length +
ENC（content + padding + padding_length））;
Gutmann Standards Track [Page 3]
--------------------------------------------------------------------------------
RFC 7366 Encrypt-then-MAC for TLS and DTLS September 2014
对于TLS 1.1和更高版本中带有明确的IV是：
MAC(MAC_write_key, seq_num +
TLSCipherText.type +
TLSCipherText.version +
TLSCipherText.length +
IV +
ENC(content + padding + padding_length));
（对于DTLS，序列号由根据DTLS [4]的组合历元和序列号替换。）
然后将最终MAC值附加到加密数据和填充之后。
该计算与现有计算相同，除了MAC计算是在有效载荷密文（TLSCipherText PDU）上运行，
而不是明文（TLSCompressed PDU）。
所有的TLS报文[2]如下:
struct {
ContentType type;
ProtocolVersion version;
uint16 length;
GenericBlockCipher fragment;
opaque MAC;
} TLSCiphertext;
同样DTLS报文[4]如下:
struct {
ContentType type;
ProtocolVersion version;
uint16 epoch;
uint48 sequence_number;
uint16 length;
GenericBlockCipher fragment;
opaque MAC;
} TLSCiphertext;
这与现有的TLS/DTLS布局相同，唯一的区别是MAC值被移到加密数据之外。
从GenericBlockCipher注释中注意到，这仅适用于具有不同加密和MAC操作的标准块密码。
它不适用于GenericStreamCiphers或已经包含使用密码的完整性保护的GenericAEADCiphers。
如果服务器从客户端接收到加密然后MAC请求扩展，然后选择流或带有关联数据（AEAD）密码组的已认证加密，
则它不得向客户端发送加密然后MAC响应扩展。
Gutmann Standards Track [Page 4]
--------------------------------------------------------------------------------
RFC 7366 Encrypt-then-MAC for TLS and DTLS September 2014
解密反转此处理。 在执行任何进一步处理（例如解密）之前，MAC应被评估，并且如果MAC验证失败，
则处理应立即终止。 对于TLS，必须生成致命的bad_record_mac [2]。
对于DTLS，记录必须被丢弃，并且可以生成致命的bad_record_mac [4]。
对坏MAC的这种立即响应消除了可能通过使用操纵的分组数据可用的任何定时信道。
一些实现可能倾向于使用截断的MAC而不是全长的MAC。
在这种情况下，他们可以通过TLS truncate_hmac扩展协议使用截断的MAC，
如TLS-Ext [3]中定义的。
3.1. Rehandshake Issues
EtMAC与MtE的状态可能在一次或多次重新握手期间改变。
实现应该保留该会话的所有重新握手的当前会话状态。
（换句话说，如果当前会话的机制是X，则重新协商的会话也应该使用X.）
实现不应该在重新握手期间改变状态，如果他们希望更灵活，那么以下规则适用：
+------------------+---------------------+--------------------------+
| Current Session | Renegotiated | Action to take |
| | Session | |
+------------------+---------------------+--------------------------+
| MAC-then-encrypt | MAC-then-encrypt | No change |
| | | |
| MAC-then-encrypt | Encrypt-then-MAC | Upgrade to |
| | | Encrypt-then-MAC |
| | | |
| Encrypt-then-MAC | MAC-then-encrypt | Error |
| | | |
| Encrypt-then-MAC | Encrypt-then-MAC | No change |
+------------------+---------------------+--------------------------+
Table 1: Encrypt-then-MAC with Renegotiation
如上表所指出的，实现不能重新协商从EtM到MtE的降级。
注意，不希望实现重新握手期间机制变化能力的客户端或服务器（作为客户端）不请求机制改变和
（作为服务器）拒绝机制改变。
Gutmann Standards Track [Page 5]
--------------------------------------------------------------------------------
RFC 7366 Encrypt-then-MAC for TLS and DTLS September 2014
请注意，这些规则适用于潜在的许多重新手动。
例如，如果会话处于EtM状态，并且重新握手选择了GenericAEADCiphers密码组和随后的重新握手，
然后选择MtE密码组，则这将是一个错误，因为重新协商过程导致降级从EtM到MtE（通过AEAD密码组）。
（正如上面的文本已经指出的，
实现应该避免通过保留所有重新手写的初始协商的机制来处理这些密码体验）。
如果根据上表中的第二行协商从MAC-then-encrypt到encrypt-then-MAC的升级，
则改变将在改变密码规范（CCS）消息之后的第一消息中发生。
换句话说，直到和包括CCS的所有消息将使用MAC-then-encrypt，
然后下面的消息将继续EtM。
4. Security Considerations
本文档定义了encrypt-then-MAC，一种改进的安全机制来替换当前MAC-then-encrypt。
Encrypt-then-MAC被认为比当前机制[5] [6]更安全，并且应该减轻或消除对当前机制的许多攻击，
前提是应用了第3节中给出的MAC处理的指令。
可以模拟具有扩展不容忍的客户端或服务器的主动攻击者可能导致一些实现回退到不支持扩展的旧协议版本，这将反过来强制回退到非加密然后MAC行为。一个
对这个问题的简单解决方案是避免回退到较旧的，较不安全的协议版本。如果后备行为不可避免，则解决此问题的机制（其影响通过TLS扩展协商的所有功能）正在
由TLS工作组开发[7]。任何关注这种类型攻击的人都应参考TLS工作组文件，了解有关适当防御机制的指导。
5. IANA Considerations
IANA has added the extension code point 22 (0x16) for the
encrypt_then_mac extension to the TLS "ExtensionType Values" registry
as specified in TLS [2].
阅读(2136) | 评论(0) | 转发(0) |
