Abstract 抽象

This document defines the use of cipher suites for TLS 1.3 based on Hashed Message Authentication Code (HMAC). Using these cipher suites provides server and, optionally, mutual authentication and data authenticity, but not data confidentiality. Cipher suites with these properties are not of general applicability, but there are use cases, specifically in Internet of Things (IoT) and constrained environments, that do not require confidentiality of exchanged messages while still requiring integrity protection, server authentication, and optional client authentication. This document gives examples of such use cases, with the caveat that prior to using these integrity-only cipher suites, a threat model for the situation at hand is needed, and a threat analysis must be performed within that model to determine whether the use of integrity-only cipher suites is appropriate. The approach described in this document is not endorsed by the IETF and does not have IETF consensus, but it is presented here to enable interoperable implementation of a reduced-security mechanism that provides authentication and message integrity without supporting confidentiality.¶
本文档定义了基于哈希消息身份验证代码 （HMAC） 的 TLS 1.3 密码套件的使用。使用这些密码套件可提供服务器以及（可选）相互身份验证和数据真实性，但不能提供数据机密性。具有这些属性的密码套件并不普遍适用，但存在一些用例，特别是在物联网 （IoT） 和受限环境中，这些用例不需要交换消息的机密性，但仍需要完整性保护、服务器身份验证和可选的客户端身份验证。本文档给出了此类用例的示例，但需要注意的是，在使用这些仅完整性密码套件之前，需要针对当前情况的威胁模型，并且必须在该模型中执行威胁分析，以确定使用仅完整性密码套件是否合适。本文档中描述的方法未得到 IETF 的认可，也没有 IETF 达成共识，但此处介绍它是为了实现可互操作的降低安全性机制，该机制在不支持机密性的情况下提供身份验证和消息完整性。¶

1. Introduction 1. 引言

There are several use cases in which communications privacy is not strictly needed, although authenticity of the communications transport is still very important. For example, within the industrial automation space, there could be TCP or UDP communications that command a robotic arm to move a certain distance at a certain speed. Without authenticity guarantees, an attacker could modify the packets to change the movement of the robotic arm, potentially causing physical damage. However, the motion control commands are not always considered to be sensitive information, and thus there is no requirement to provide confidentiality. Another Internet of Things (IoT) example with no strong requirement for confidentiality is the reporting of weather information; however, message authenticity is required to ensure integrity of the message.¶
在一些用例中，通信隐私并不是严格要求的，尽管通信传输的真实性仍然非常重要。例如，在工业自动化领域，可能存在TCP或UDP通信，这些通信命令机械臂以特定速度移动一定距离。如果没有真实性保证，攻击者可以修改数据包以改变机械臂的运动，从而可能造成物理损坏。但是，运动控制命令并不总是被视为敏感信息，因此不需要提供机密性。另一个对保密性没有严格要求的物联网 （IoT） 示例是天气信息报告;但是，需要消息的真实性来确保消息的完整性。¶

There is no requirement to encrypt messages in environments where the information is not confidential, such as when there is no intellectual property associated with the processes, or where the threat model does not indicate any outsider attacks (such as in a closed system). Note, however, that this situation will not apply equally to all use cases (for example, in one case a robotic arm might be used for a process that does not involve any intellectual property but in another case might be used in a different process that does contain intellectual property). Therefore, it is important that a user or system developer carefully examine both the sensitivity of the data and the system threat model to determine the need for encryption before deploying equipment and security protections.¶
在信息不保密的环境中，例如没有与进程关联的知识产权，或者威胁模型未指示任何外部攻击（例如在封闭系统中），不需要对消息进行加密。但请注意，这种情况并不同样适用于所有用例（例如，在一种情况下，机械臂可能用于不涉及任何知识产权的流程，但在另一种情况下，可能用于包含知识产权的其他流程）。因此，在部署设备和安全保护之前，用户或系统开发人员必须仔细检查数据的敏感性和系统威胁模型，以确定是否需要加密。¶

Besides having a strong need for authenticity and no need for confidentiality, many of these systems also have a strong requirement for low latency. Furthermore, several classes of IoT devices (industrial or otherwise) have limited processing capability. However, these IoT systems still gain great benefit from leveraging TLS 1.3 for secure communications. Given the reduced need for confidentiality, TLS 1.3 cipher suites [RFC8446] that maintain data integrity without confidentiality are described in this document. These cipher suites are not meant for general use, as they do not meet the confidentiality and privacy goals of TLS. They should only be used in cases where confidentiality and privacy are not a concern and there are constraints on using cipher suites that provide the full set of security properties. The approach described in this document is not endorsed by the IETF and does not have IETF consensus, but it is presented here to enable interoperable implementation of a reduced-security mechanism that provides authentication and message integrity with supporting confidentiality.¶
除了对真实性和不需要保密性的强烈需求外，其中许多系统还对低延迟有强烈的要求。此外，几类物联网设备（工业或其他设备）的处理能力有限。但是，这些物联网系统仍然从利用 TLS 1.3 进行安全通信中获益匪浅。鉴于对机密性的需求降低，本文档介绍了在不保密的情况下保持数据完整性的 TLS 1.3 密码套件 [ RFC8446]。这些密码套件不适用于一般用途，因为它们不符合 TLS 的机密性和隐私性目标。它们只应在以下情况下使用：机密性和隐私性不是问题，并且使用提供全套安全属性的密码套件存在限制。本文档中描述的方法未得到 IETF 的认可，也没有 IETF 达成共识，但此处介绍它是为了实现降低安全性的机制的可互操作实现，该机制提供身份验证和消息完整性以及支持的机密性。¶

2. Terminology 2. 术语

This document adopts the conventions for normative language to provide clarity of instructions to the implementer. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
本文档采用规范性语言的约定，为实施者提供清晰的说明。本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应该”、“不应”、“推荐”、“不推荐”、“可以”和“可选”应按照 BCP 14 [ RFC2119][ RFC8174] 中的描述进行解释，当且仅当它们出现在所有大写字母中时，如此处所示。¶

3. Applicability Statement
3. 适用性声明

The two cipher suites defined in this document, which are based on Hashed Message Authentication Code (HMAC) SHAs [RFC6234], are intended for a small limited set of applications where confidentiality requirements are relaxed and the need to minimize the number of cryptographic algorithms is prioritized. This section describes some of those applicable use cases.¶
本文档中定义的两个密码套件基于哈希消息身份验证代码 （HMAC） SHA [RFC6234]，适用于机密性要求放宽且需要最小化加密算法数量的一小部分有限应用程序。本节介绍其中一些适用的用例。¶

Use cases in the industrial automation industry, while requiring data integrity, often do not require confidential communications. Mainly, data communicated to unmanned machines to execute repetitive tasks does not convey private information. For example, there could be a system with a robotic arm that paints the body of a car. This equipment is used within a car manufacturing plant and is just one piece of equipment in a multi-step manufacturing process. The movements of this robotic arm are likely not a trade secret or sensitive intellectual property, although some portions of the manufacturing of the car might very well contain sensitive intellectual property. Even the mixture for the paint itself might be confidential, but the mixing is done by a completely different piece of equipment and therefore communication to/from that equipment can be encrypted without requiring the communication to/from the robotic arm to be encrypted. Modern manufacturing often has segmented equipment with different levels of risk related to intellectual property, although nearly every communication interaction has strong data authenticity requirements.¶
工业自动化行业的用例虽然需要数据完整性，但通常不需要保密通信。主要是，与无人机器通信以执行重复性任务的数据不会传达私人信息。例如，可能有一个带有机械臂的系统，可以对汽车的车身进行涂漆。该设备用于汽车制造厂，只是多步骤制造过程中的一件设备。这种机械臂的运动可能不是商业秘密或敏感的知识产权，尽管汽车制造的某些部分很可能包含敏感的知识产权。即使是油漆本身的混合物也可能是保密的，但混合是由完全不同的设备完成的，因此可以加密与该设备之间的通信，而无需加密与机械臂之间的通信。现代制造业通常具有与知识产权相关的不同风险级别的分段设备，尽管几乎每一次通信交互都有很强的数据真实性要求。¶

Another use case that is closely related is that of fine-grained time updates. Motion systems often rely on time synchronization to ensure proper execution. Time updates are essentially public; there is no threat from an attacker knowing the time update information. This should make intuitive sense to those not familiar with these applications; rarely if ever does time information present a serious attack surface dealing with privacy. However, the authenticity is still quite important. The consequences of maliciously modified time data can vary from mere denial of service to actual physical damage, depending on the particular situation and attacker capability. As these time synchronization updates are very fine-grained, it is again important for latency to be very low.¶
另一个密切相关的用例是细粒度时间更新。运动系统通常依靠时间同步来确保正确执行。时间更新基本上是公开的;知道时间更新信息的攻击者不会构成威胁。对于那些不熟悉这些应用程序的人来说，这应该是直观的;时间信息很少（如果有的话）会成为处理隐私的严重攻击面。但是，真实性仍然非常重要。恶意修改时间数据的后果可能从单纯的拒绝服务到实际的物理损害不等，具体取决于特定情况和攻击者的能力。由于这些时间同步更新非常细粒度，因此延迟非常低也很重要。¶

A third use case deals with data related to alarms. Industrial control sensing equipment can be configured to send alarm information when it meets certain conditions -- for example, temperature goes above or below a given threshold. Oftentimes, this data is used to detect certain out-of-tolerance conditions, allowing an operator or automated system to take corrective action. Once again, in many systems the reading of this data doesn't grant the attacker information that can be exploited; it is generally just information regarding the physical state of the system. At the same time, being able to modify this data would allow an attacker to either trigger alarms falsely or cover up evidence of an attack that might allow for detection of their malicious activity. Furthermore, sensors are often low-powered devices that might struggle to process encrypted and authenticated data. These sensors might be very cost sensitive such that there is not enough processing power for data encryption. Sending data that is just authenticated but not encrypted eases the burden placed on these devices yet still allows the data to be protected against any tampering threats. A user can always choose to pay more for a sensor with encryption capability, but for some, data authenticity will be sufficient.¶
第三个用例处理与警报相关的数据。工业控制传感设备可以配置为在满足特定条件时发送报警信息，例如，温度高于或低于给定阈值。通常，这些数据用于检测某些超出公差的情况，使操作员或自动化系统能够采取纠正措施。同样，在许多系统中，读取此数据不会向攻击者提供可被利用的信息;它通常只是有关系统物理状态的信息。同时，如果能够修改这些数据，攻击者可以错误地触发警报，或者掩盖可能允许检测其恶意活动的攻击证据。此外，传感器通常是低功耗设备，可能难以处理加密和经过身份验证的数据。这些传感器可能对成本非常敏感，因此没有足够的处理能力进行数据加密。发送仅经过身份验证但未加密的数据可以减轻这些设备的负担，但仍可以保护数据免受任何篡改威胁。用户始终可以选择为具有加密功能的传感器支付更多费用，但对于某些人来说，数据真实性就足够了。¶

A fourth use case considers the protection of commands in the railway industry. In railway control systems, no confidentiality requirements are applied for the command exchange between an interlocking controller and a railway equipment controller (for instance, a railway point controller of a tram track where the position of the controlled point is publicly available). However, protecting the integrity and authenticity of those commands is vital; otherwise, an adversary could change the target position of the point by modifying the commands, which consequently could lead to the derailment of a passing train. Furthermore, requirements for providing flight-data recording of the safety-related network traffic can only be fulfilled through using authenticity-only ciphers as, typically, the recording is used by a third party responsible for the analysis after an accident. The analysis requires such third party to extract the safety-related commands from the recording.¶
第四个用例考虑了铁路行业中的命令保护。在铁路控制系统中，联锁控制器和铁路设备控制器（例如，电车轨道的铁路点控制器，其中控制点的位置是公开的）之间的命令交换不适用保密要求。但是，保护这些命令的完整性和真实性至关重要;否则，对手可以通过修改命令来改变该点的目标位置，从而导致经过的火车脱轨。此外，提供与安全相关的网络流量的飞行数据记录的要求只能通过使用仅真实性的密码来满足，因为通常，记录由负责事故后分析的第三方使用。该分析要求此类第三方从录音中提取与安全相关的命令。¶

The fifth use case deals with data related to civil aviation airplanes and ground communication. Pilots can send and receive messages to/from ground control, such as airplane route-of-flight updates, weather information, controller and pilot communication, and airline back-office communication. Similarly, the Air Traffic Control (ATC) service uses air-to-ground communication to receive the surveillance data that relies on (is dependent on) downlink reports from an airplane's avionics. This communication occurs automatically in accordance with contracts established between the ATC ground system and the airplane's avionics. Reports can be sent whenever specific events occur or specific time intervals are reached. In many systems, the reading of this data doesn't grant the attacker information that can be exploited; it is generally just information regarding the states of the airplane, controller pilot communication, meteorological information, etc. At the same time, being able to modify this data would allow an attacker to either put aircraft in the wrong flight trajectory or provide false information to ground control that might delay flights, damage property, or harm life. Sending data that is not encrypted but is authenticated allows the data to be protected against any tampering threats. Data authenticity is sufficient for the air traffic, weather, and surveillance information exchanges between airplanes and the ground systems.¶
第五个用例涉及与民用航空、飞机和地面通信相关的数据。飞行员可以向地面控制发送和接收消息，例如飞机飞行路线更新、天气信息、管制员和飞行员通信以及航空公司后台通信。同样，空中交通管制 （ATC） 服务使用空对地通信来接收依赖于（依赖于）来自飞机航空电子设备的下行链路报告的监视数据。这种通信是根据ATC地面系统与飞机航空电子设备之间建立的合同自动进行的。每当发生特定事件或达到特定时间间隔时，都可以发送报告。在许多系统中，读取此数据不会向攻击者授予可利用的信息;它通常只是有关飞机状态、管制员飞行员通信、气象信息等的信息。同时，能够修改这些数据将允许攻击者将飞机置于错误的飞行轨迹或向地面控制提供虚假信息，从而可能延误航班、损坏财产或伤害生命。发送未加密但经过身份验证的数据可以保护数据免受任何篡改威胁。数据真实性足以满足飞机和地面系统之间的空中交通、天气和监视信息交换。¶

The above use cases describe the requirements where confidentiality is not needed and/or interferes with other requirements. Some of these use cases are based on devices that come with a small runtime memory footprint and reduced processing power; therefore, the need to minimize the number of cryptographic algorithms used is a priority. Despite this, it is noted that memory, performance, and processing power implications of any given algorithm or set of algorithms are highly dependent on hardware and software architecture. Therefore, although these cipher suites may provide performance benefits, they will not necessarily provide these benefits in all cases on all platforms. Furthermore, in some use cases, third-party inspection of data is specifically needed, which is also supported through the lack of confidentiality mechanisms.¶
上述用例描述了不需要保密和/或干扰其他要求的要求。其中一些用例基于运行时内存占用小且处理能力降低的设备;因此，当务之急是尽量减少使用的加密算法的数量。尽管如此，需要注意的是，任何给定算法或一组算法的内存、性能和处理能力影响都高度依赖于硬件和软件架构。因此，尽管这些密码套件可能会提供性能优势，但它们不一定在所有平台上的所有情况下都提供这些优势。此外，在某些用例中，特别需要第三方检查数据，这也通过缺乏保密机制得到支持。¶

4. Cryptographic Negotiation Using Integrity-Only Cipher Suites
4. 使用仅完整性密码套件进行加密协商

The cryptographic negotiation as specified in [RFC8446], Section 4.1.1 remains the same, with the inclusion of the following cipher suites:¶
[ RFC8446] 第 4.1.1 节中指定的加密协商保持不变，但包含以下密码套件： ¶

• TLS_SHA256_SHA256 {0xC0,0xB4}¶
• TLS_SHA384_SHA384 {0xC0,0xB5}¶

As defined in [RFC8446], TLS 1.3 cipher suites denote the Authenticated Encryption with Associated Data (AEAD) algorithm for record protection and the hash algorithm to use with the HMAC-based Key Derivation Function (HKDF). The cipher suites provided by this document are defined in a similar way, but they use the HMAC authentication tag to model the AEAD interface, as only an HMAC is provided for record protection (without encryption). These cipher suites allow the use of SHA-256 or SHA-384 as the HMAC for data integrity protection as well as its use for the HKDF. The authentication mechanisms remain unchanged with the intent to only update the cipher suites to relax the need for confidentiality.¶
如 [ RFC8446] 中所定义，TLS 1.3 密码套件表示用于记录保护的带关联数据的身份验证加密 （AEAD） 算法，以及用于基于 HMAC 的密钥派生函数 （HKDF） 的哈希算法。本文档提供的密码套件以类似的方式定义，但它们使用 HMAC 身份验证标记对 AEAD 接口进行建模，因为仅提供 HMAC 用于记录保护（不加密）。这些密码套件允许使用 SHA-256 或 SHA-384 作为 HMAC 来保护数据完整性，并将其用于 HKDF。身份验证机制保持不变，目的是仅更新密码套件以放宽对机密性的需求。¶

Given that these cipher suites do not support confidentiality, they MUST NOT be used with authentication and key exchange methods that rely on confidentiality.¶
鉴于这些密码套件不支持机密性，因此不得将它们与依赖于机密性的身份验证和密钥交换方法一起使用。¶

5. Record Payload Protection for Integrity-Only Cipher Suites
5. 记录仅完整性密码套件的有效负载保护

Record payload protection as defined in [RFC8446] is retained in modified form when integrity-only cipher suites are used. Note that due to the purposeful use of hash algorithms, instead of AEAD algorithms, confidentiality protection of the record payload is not provided. This section describes the mapping of record payload structures when integrity-only cipher suites are employed.¶
当使用仅完整性密码套件时，[ RFC8446] 中定义的记录有效负载保护将以修改后的形式保留。请注意，由于有目的地使用哈希算法而不是 AEAD 算法，因此不提供记录有效负载的机密性保护。本节介绍使用仅完整性密码套件时记录有效负载结构的映射。¶

Given that there is no encryption to be done at the record layer, the operations "Protect" and "Unprotect" take the place of "AEAD-Encrypt" and "AEAD-Decrypt" [RFC8446], respectively.¶
鉴于在记录层没有加密，操作“保护”和“取消保护”分别取代了“AEAD-Encrypt”和“AEAD-Decrypt”[RFC8446]。¶

As integrity protection is provided over the full record, the encrypted_record in the TLSCiphertext along with the additional_data input to protected_data (termed AEADEncrypted data in [RFC8446]) as defined in Section 5.2 of [RFC8446] remain the same. The TLSCiphertext.length for the integrity cipher suites will be:¶
由于在整个记录上提供了完整性保护，因此 TLSCiphertext 中的encrypted_record以及 [ RFC8446] 第 5.2 节中定义的 protected_data additional_data输入（在 [ RFC8446] 中称为 AEADEncrypted 数据）保持不变。完整性密码套件的 TLSCiphertext.length 将为： ¶

TLS_SHA256_SHA256:
   TLSCiphertext.length = TLSInnerPlaintext_length + 32
TLS_SHA256_SHA256：TLSCiphertext.length = TLSInnerPlaintext_length + 32
TLS_SHA384_SHA384:
   TLSCiphertext.length = TLSInnerPlaintext_length + 48

TLS_SHA384_SHA384：TLSCiphertext.length = TLSInnerPlaintext_length + 48

Note that TLSInnerPlaintext_length is not defined as an explicit field in [RFC8446]; this refers to the length of the encoded TLSInnerPlaintext structure.¶
请注意，TLSInnerPlaintext_length 未在 [ RFC8446] 中定义为显式字段;这是指编码的 TLSInnerPlaintext 结构的长度。¶

The resulting protected_record is the concatenation of the TLSInnerPlaintext with the resulting HMAC. Note that this is analogous to the "encrypted_record" as defined in [RFC8446], although it is referred to as a "protected_record" because of the lack of confidentiality via encryption. With this mapping, the record validation order as defined in Section 5.2 of [RFC8446] remains the same. That is, the encrypted_record field of TLSCiphertext is set to:¶
生成的protected_record是 TLSInnerPlaintext 与生成的 HMAC 的串联。请注意，这类似于 [ RFC8446] 中定义的“encrypted_record”，尽管它被称为“protected_record”，因为缺乏加密的机密性。使用此映射，[ RFC8446] 第 5.2 节中定义的记录验证顺序保持不变。也就是说，TLSCiphertext 的 encrypted_record 字段设置为： ¶

   encrypted_record = TLS13-HMAC-Protected = TLSInnerPlaintext ||
   HMAC(write_key, nonce || additional_data || TLSInnerPlaintext)

encrypted_record=TLS13-HMAC-Protected=TLSInnerPlaintext||
HMAC（write_key， 随机数 || additional_data ||TLSInnerPlaintext）

Here, "nonce" refers to the per-record nonce described in Section 5.3 of [RFC8446].¶
在这里，“nonce”是指 [ RFC8446] 的第 5.3 节中描述的每条记录的随机数。¶

For DTLS 1.3, the DTLSCiphertext is set to:¶
对于 DTLS 1.3，DTLSCiphertext 设置为： ¶

   encrypted_record = DTLS13-HMAC-Protected = DTLSInnerPlaintext ||
   HMAC(write_key, nonce || additional_data || DTLSInnerPlaintext)

encrypted_record=DTLS13-HMAC-Protected=DTLSInnerPlaintext||
HMAC（write_key， 随机数 || additional_data ||DTLSInnerPlaintext）

The DTLS "nonce" refers to the per-record nonce described in Section 4.2.2 of [DTLS13].¶
DTLS“随机数”是指 [ DTLS13] 第 4.2.2 节中描述的每条记录随机数。¶

The Protect and Unprotect operations provide the integrity protection using HMAC SHA-256 or HMAC SHA-384 as described in [RFC6234].¶
“保护”和“取消保护”操作使用 HMAC SHA-256 或 HMAC SHA-384 提供完整性保护，如 [ RFC6234] 中所述。¶

Due to the lack of encryption of the plaintext, record padding does not provide any obfuscation as to the plaintext size, although it can be optionally included.¶
由于缺乏对明文的加密，记录填充不会对明文大小进行任何混淆，尽管它可以选择包含。¶

6. Key Schedule when Using Integrity-Only Cipher Suites
6. 使用仅完整性密码套件时的密钥调度

The key derivation process for integrity-only cipher suites remains the same as that defined in [RFC8446]. The only difference is that the keys used to protect the tunnel apply to the negotiated HMAC SHA-256 or HMAC SHA-384 ciphers. Note that the traffic key material (client_write_key, client_write_iv, server_write_key, and server_write_iv) MUST be calculated as per [RFC8446], Section 7.3. The key lengths and Initialization Vectors (IVs) for these cipher suites are according to the hash output lengths. In other words, the following key lengths and IV lengths SHALL be:¶
仅完整性密码套件的密钥派生过程与 [ RFC8446] 中定义的过程相同。唯一的区别是，用于保护隧道的密钥适用于协商的 HMAC SHA-256 或 HMAC SHA-384 密码。请注意，流量密钥材料（client_write_key、client_write_iv、server_write_key 和 server_write_iv）必须按照 [ RFC8446] 第 7.3 节进行计算。这些密码套件的密钥长度和初始化向量 （IV） 取决于哈希输出长度。换言之，以下密钥长度和 IV 长度应为： ¶

7. Error Alerts
7. 错误警报

The error alerts as defined by [RFC8446] remain the same; in particular:¶
[ RFC8446] 定义的错误警报保持不变;特别是： ¶

bad_record_mac: bad_record_mac：

This alert can also occur for a record whose message authentication code cannot be validated. Since these cipher suites do not involve record encryption, this alert will only occur when the HMAC fails to verify.¶
对于无法验证消息身份验证代码的记录，也可能发生此警报。由于这些密码套件不涉及记录加密，因此仅当 HMAC 无法验证时才会发生此警报。¶

decrypt_error: decrypt_error：

This alert, as described in [RFC8446], Section 6.2, occurs when the signature or message authentication code cannot be validated. Note that this error is only sent during the handshake, not for an error in validating record HMACs.¶
如 [ RFC8446]， 第 6.2 节所述，当无法验证签名或消息身份验证代码时，会发生此警报。请注意，此错误仅在握手期间发送，而不是在验证记录 HMAC 时出错。¶

10. References 10. 参考资料