idnits 2.17.1 draft-camwinget-tls-ts13-macciphersuites-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (June 8, 2020) is 1418 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TLS N. Cam-Winget 3 Internet-Draft Cisco Systems 4 Intended status: Informational J. Visoky 5 Expires: December 10, 2020 ODVA 6 June 8, 2020 8 TLS 1.3 Authentication and Integrity only Cipher Suites 9 draft-camwinget-tls-ts13-macciphersuites-06 11 Abstract 13 There are use cases, specifically in Internet of Things (IoT) and 14 constrained environments that do not require confidentiality, though 15 mutual authentication during tunnel establishment and message 16 integrity is still mandated. This document defines the use of HMAC 17 only cipher suites for TLS 1.3. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on December 10, 2020. 36 Copyright Notice 38 Copyright (c) 2020 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 3 56 4. Cryptographic Negotiation Using Integrity only Cipher Suites 4 57 5. Record Payload Protection for Integrity only Cipher Suites . 5 58 6. Key Schedule when using Integrity only Cipher Suites . . . . 6 59 7. Error Alerts . . . . . . . . . . . . . . . . . . . . . . . . 6 60 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 61 9. Security and Privacy Considerations . . . . . . . . . . . . . 7 62 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 63 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 11.1. Normative References . . . . . . . . . . . . . . . . . . 7 65 11.2. Informative Reference . . . . . . . . . . . . . . . . . 8 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 68 1. Introduction 70 There are several use cases in which communications privacy is not 71 strictly needed, although authenticity of the communications 72 transport is still very important. For example, within the 73 Industrial Automation space there could be TCP or UDP communications 74 which command a robotic arm to move a certain distance at a certain 75 speed. Without authenticity guarantees an attacker could modify the 76 packets to change the movement of the robotic arm, potentially 77 causing physical damage. However, the motion control commands are 78 not considered to be sensitive information and thus there is no 79 requirement to provide confidentiality. Another IoT example with no 80 strong requirement for confidentiality is the reporting of weather 81 information; however, message authenticity is required to ensure 82 integrity of the message.. 84 Besides having a strong need for authenticity and a weak need for 85 confidentiality, many of these systems also have serious latency 86 requirements. Furthermore, several IoT devices (industrial or 87 otherwise) have limited processing capability. However, these IoT 88 systems still gain great benefit from leveraging TLS 1.3 for secure 89 communications. Given the reduced need for confidentiality TLS 1.3 90 [RFC8446] cipher suites that maintain data integrity without 91 confidentiality are described in this document. 93 2. Terminology 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in BCP 14 [RFC2119] 98 [RFC8174] when, and only when, they appear in all capitals, as shown 99 here. 101 3. Applicability Statement 103 The cipher suites defined in this document are intended for a small 104 limited set of applications where confidentiality requirements are 105 relaxed and the need to minimize the cryptographic algorithms are 106 prioritized. This section describes some of those applicable use 107 cases. 109 Use cases in the industrial automation industry, while requiring data 110 integrity, relax the confidential communications requirement. 111 Mainly, information communicated to unmanned machines to execute 112 repetitive tasks do not convey private information. For example, 113 there could be a system with a robotic arm that is doing high speed 114 pick-and-place of materials. The position synchronization data and 115 motion commands are required to have very low latency, as the process 116 needs to be done at high speed on a compute and memory constrained 117 device. However, information such as the position, speed, 118 acceleration of the robotic arm or other material in the system is 119 not confidential. That is, while an attacker can determine the 120 behavioral aspects and task of the device; no intellectual property 121 concerns or data privacy concerns exist for these communications. 122 However, data integrity is required as being able to modify this data 123 would be a threat that an attacker might seek to exploit with serious 124 consequences; the attacker could modify the motion information in 125 order to cause physical damage to the equipment. 127 Another use case which is closely related is that of fine grained 128 time updates. Motion systems often rely on time synchronization to 129 ensure proper execution. Time updates are essentially public, there 130 is no threat from an attacker knowing the time update information. 131 This should make intuitive sense to those not familiar with these 132 applications; rarely if ever does time information present a serious 133 attack surface dealing with privacy. However the authenticity is 134 still quite important. Modification of the data can at best lead to 135 a denial-of-service attack, although a more intelligent threat actor 136 might be able to cause actual physical damage. As these time 137 synchronization updates are very fine-grained, it is again important 138 for latency to be very low. 140 A third use case deals with Alarming data. Industrial control 141 sensing equipment can be configured to send alarm information when it 142 meets certain conditions. Often times this data is used to detect 143 certain out-of-tolerance conditions, allowing an operator or 144 automated system to take corrective action. Once again, in many 145 systems the reading of this data doesn't grant the attacker 146 information that can be exploited, it is generally just information 147 regarding the physical state of the system. At the same time, being 148 able to modify this data would allow an attacker to either trigger 149 alarms falsely or to cover up evidence of an attack that might allow 150 for detection of their malicious activity. Furthermore, sensors are 151 often low powered devices that might struggle to process encrypted 152 and authenticated data. Sending data that is just authenticated 153 significantly eases the burden placed on these devices, yet still 154 allows the data to be protected against any tampering threats. 156 A fourth use case considers the protection of commands in the railway 157 industry. In railway control systems, no confidentiality 158 requirements are applied for the command exchange between an 159 interlocking controller and a railway equipment controller (for 160 instance, a railway point controller of a tram track where the 161 position of the controlled point is publicly available). However, 162 protecting integrity of those commands is vital, otherwise, an 163 adversary could change the target position of the point by modifying 164 the commands, which consequently could lead to the derailment of a 165 passing train. Furthermore, requirements for providing blackbox 166 recording of the safety related network traffic can only be fulfilled 167 through using integrity only ciphers, to be able to provide the 168 safety related commands to a third party, which is responsible for 169 the analysis after an accident. 171 The above use cases describe the relaxed requirements to provide 172 confidentiality, and as these devices come with a small runtime 173 memory footprint and reduced processing power, the need to minimize 174 the number of cryptographic algorithms used is prioritized. 176 4. Cryptographic Negotiation Using Integrity only Cipher Suites 178 The cryptographic negotiation as specified in [RFC8446] Section 4.1.1 179 remains the same, with the inclusion of the following cipher suites: 181 TLS_SHA256_SHA256 {0xC0, 0xB4} 183 TLS_SHA384_SHA384 {0xC0, 0xB5} 185 These cipher suites allow the use of SHA-256 or SHA-384 as the HMACs 186 for data integrity protection as well as its use for HKDF. The 187 authentication mechanisms remain unchanged with the intent to only 188 update the cipher suites to relax the need for confidentiality. 190 Given that these cipher suites do not support confidentiality, they 191 MUST only be used with certificate-based authentication and Diffie- 192 Hellman key exchange. 194 5. Record Payload Protection for Integrity only Cipher Suites 196 Given that there is no encryption to be done at the record layer, the 197 operations "Protect" and "Unprotect" take the place of "AEAD-Encrypt" 198 and "AEAD-Decrypt", respectively. 200 The record payload protection as defined in [RFC8446] can be retained 201 when integrity only cipher suites are used. This section describes 202 the mapping of record payload structures when integrity only cipher 203 suites are employed. 205 As integrity is provided with protection over the full record, the 206 encrypted_record in the TLSCiphertext along with the additional_data 207 input to protected_data (termed AEADEncrypted data in [RFC8446]) as 208 defined in Section 5.2 [RFC8446] remains the same. The 209 TLSCiphertext.length for the integrity cipher suites will be: 211 TLS_SHA256_SHA256: TLSCiphertext.length = TLSPlaintext.length + 1 212 (type field) + length_of_padding + 32 (HMAC) = 213 TLSInnerPlaintext_length + 32 (HMAC) 215 TLS_SHA384_SHA384: TLSCiphertext.length = TLSPlaintext.length + 1 216 (type field) + length_of_padding + 48 (HMAC) = 217 TLSInnerPlaintext_length + 48 (HMAC) 219 Note that TLSInnerPlaintext_length is not defined as an explicit 220 field in [RFC8446], this refers to the length of the 221 TLSInnterPlaintext structure 223 The resulting protected_record is the concatenation of the 224 TLSInnerPlaintext with the resulting HMAC. With this mapping, the 225 record validation order as defined in Section 5.2 of [RFC8446] 226 remains the same. That is, encrypted_record field of TLSCiphertext 227 is set to: 229 TLSCiphertext = TLS13-HMAC-Protected = TLSInnerPlaintext || 230 HMAC(write_key, nonce || additional_data || TLSInnerPlaintext) 232 Here "nonce" refers to the per-record nonce described in section 5.3 233 of [RFC8446]. 235 The Protect and Unprotect operations provide the integrity protection 236 using HMAC SHA-256 or SHA-384 as described in [RFC6234]. 238 Due to the lack of encryption of the plaintext, record padding is not 239 needed, although it can be optionally included. 241 6. Key Schedule when using Integrity only Cipher Suites 243 The key derivation process for Integrity only Cipher Suites remains 244 the same as defined in [RFC8446]. The only difference is that the 245 keys used to protect the tunnel applies to the negotiated HMAC 246 SHA-256 or HMAC SHA-384 ciphers. Note that the traffic key material 247 (client_write_key, client_write_iv, server_write_key and 248 server_write_iv) MUST be calculated as per RFC 8446, section 7.3. 249 The key lengths and IVs for these cipher suites are according to the 250 hash lenghts. In other words, the following key lenghts and IV 251 lengths SHALL be: 253 +-------------------+------------+-----------+ 254 | Cipher Suite | Key Length | IV Length | 255 +-------------------+------------+-----------+ 256 | TLS_SHA256_SHA256 | 32 Bytes | 32 Bytes | 257 | TLS_SHA384_SHA384 | 48 Bytes | 48 Bytes | 258 +-------------------+------------+-----------+ 260 7. Error Alerts 262 The error alerts as defined by [RFC8446] remains the same, in 263 particular: 265 bad_record_mac: This alert can also occur for a record whose message 266 authentication code can not be validated. Since these cipher suites 267 do not involve record encryption this alert will only occur when the 268 HMAC fails to verify. 270 decrypt_error: This alert as described in [RFC8446] Section 6.2 271 occurs when the signature or message authentication code can not be 272 validated. 274 8. IANA Considerations 276 IANA has granted registration the following specifically for this 277 document: 279 TLS_SHA256_SHA256 {0xC0, 0xB4} cipher suite and TLS_SHA384_SHA384 280 {0xC0, 0xB5} cipher suite. 282 Note that both of these cipher suites are registered with the DTLS-OK 283 column set to Y and the Recommneded column set to N 285 9. Security and Privacy Considerations 287 In general, with the exception of confidentiality and privacy, the 288 security considerations detailed in [RFC8446] and in [RFC5246] apply 289 to this document. Furthermore, as the cipher suites described in 290 this document do not provide any confidentiality, it is important 291 that they only be used in cases where there are no confidentiality or 292 privacy requirements and concerns; and the runtime memory 293 requirements can accommodate support for more cryptographic 294 constructs. 296 With the lack of data encryption specified in this draft, no 297 confidentiality or privacy is provided for the data transported via 298 the TLS session. To highlight the loss of privacy, the information 299 carried in the TLS handshake, which includes both the Server and 300 Client certificates, while integrity protected, will be sent 301 unencrypted. Similarly, other TLS extensions that may be carried in 302 the Server's EncryptedExtensions message will only be integrity 303 protected without provisions for confidentiality. Furthermore, with 304 this lack of confidentiality, PSK data MUST NOT be sent in the 305 handshake while using these cipher suites. 307 Given the lack of confidentiality, it is of the utmost importance 308 that these cipher suites never be enabled by default. As these 309 cipher suites are meant to serve the IoT market, it is important that 310 any IoT endpoint that uses them be explicitly configured with a 311 policy of non-confidential communications. 313 10. Acknowledgements 315 The authors would like to acknowledge the work done by Industrial 316 Communications Standards Groups (such as ODVA) as the motivation for 317 this document. We would also like to thank Steffen Fries for 318 providing a fourth use case. In addition, we are grateful for the 319 advice and feedback from Joe Salowey, Blake Anderson, David McGrew, 320 Clement Zeller, and Peter Wu. 322 11. References 324 11.1. Normative References 326 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 327 Requirement Levels", BCP 14, RFC 2119, 328 DOI 10.17487/RFC2119, March 1997, 329 . 331 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 332 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 333 DOI 10.17487/RFC6234, May 2011, 334 . 336 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 337 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 338 May 2017, . 340 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 341 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 342 . 344 11.2. Informative Reference 346 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 347 (TLS) Protocol Version 1.2", RFC 5246, 348 DOI 10.17487/RFC5246, August 2008, 349 . 351 Authors' Addresses 353 Nancy Cam-Winget 354 Cisco Systems 355 3550 Cisco Way 356 San Jose, CA 95134 357 USA 359 Email: ncamwing@cisco.com 361 Jack Visoky 362 ODVA 363 1 Allen Bradley Dr 364 Mayfield Heights, OH 44124 365 USA 367 Email: jmvisoky@ra.rockwell.com