idnits 2.17.1 draft-camwinget-tls-ts13-macciphersuites-09.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. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (March 26, 2021) is 1120 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: September 27, 2021 ODVA 6 March 26, 2021 8 TLS 1.3 Authentication and Integrity only Cipher Suites 9 draft-camwinget-tls-ts13-macciphersuites-09 11 Abstract 13 There are use cases, specifically in Internet of Things (IoT) and 14 constrained environments that do not require confidentiality, though 15 message integrity for all communications and at least server, if not 16 mutual authentication during tunnel establishment are both still 17 mandated. Examples of such use cases are given, although a threat 18 model is necessary to determine whether or not a given situation 19 falls into this catergory of use cases. In order to serve these use 20 cases, this document defines the use of HMAC only cipher suites for 21 TLS 1.3, which provides server and optionally mutual authentication 22 and data authenticity, but not data confidentiality. The approach 23 described in this document is not endorsed by the IETF and does not 24 have IETF consensus, but is presented here to enable interoperable 25 implementation of a reduced security mechanism that provides 26 authentication and message integrity without supporting 27 confidentiality. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on September 27, 2021. 46 Copyright Notice 48 Copyright (c) 2021 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 3 66 4. Cryptographic Negotiation Using Integrity only Cipher Suites 6 67 5. Record Payload Protection for Integrity only Cipher Suites . 6 68 6. Key Schedule when using Integrity only Cipher Suites . . . . 7 69 7. Error Alerts . . . . . . . . . . . . . . . . . . . . . . . . 8 70 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 71 9. Security and Privacy Considerations . . . . . . . . . . . . . 8 72 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 73 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 74 11.1. Normative References . . . . . . . . . . . . . . . . . . 9 75 11.2. Informative Reference . . . . . . . . . . . . . . . . . 10 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 78 1. Introduction 80 There are several use cases in which communications privacy is not 81 strictly needed, although authenticity of the communications 82 transport is still very important. For example, within the 83 Industrial Automation space there could be TCP or UDP communications 84 which command a robotic arm to move a certain distance at a certain 85 speed. Without authenticity guarantees, an attacker could modify the 86 packets to change the movement of the robotic arm, potentially 87 causing physical damage. However, the motion control commands are 88 not considered to be sensitive information and thus there is no 89 requirement to provide confidentiality. Another IoT example with no 90 strong requirement for confidentiality is the reporting of weather 91 information; however, message authenticity is required to ensure 92 integrity of the message. 94 There is no requirement to encrypt messages in environments where the 95 information is not confidential; such as when there is no 96 intellectual property associated with the processes, or where the 97 threat model does not indicate any outsider attacks (such as in a 98 closed system). Note however, this situation will not apply equally 99 to all use cases (for example, a robotic arm might be used in one 100 case for a process that does not involve any intellectual property, 101 but in another case that does). Therefore, it is important that a 102 user or system developer carefully examine both the sensitivity of 103 the data and the system threat model to determine the need for 104 encryption before deploying equipment 106 Besides having a strong need for authenticity and no need for 107 confidentiality, many of these systems also have a strong requirement 108 for low latency. Furthermore, several classes of IoT device 109 (industrial or otherwise) have limited processing capability. 110 However, these IoT systems still gain great benefit from leveraging 111 TLS 1.3 for secure communications. Given the reduced need for 112 confidentiality TLS 1.3 [RFC8446] cipher suites that maintain data 113 integrity without confidentiality are described in this document. 114 These ciphersuites are not meant for general use as they do not meet 115 the confidentiality and privacy goals of TLS. They should only be 116 used in cases where confidentiality and privacy is not a concern and 117 there are constraints on using ciphersuites that provide the full set 118 of security properties. The approach described in this document is 119 not endorsed by the IETF and does not have IETF consensus, but is 120 presented here to enable interoperable implementation of a reduced 121 security mechanism that provides authentication and message integrity 122 with supporting confidentiality. 124 2. Terminology 126 Although this document is not an IETF Standards Track publication it 127 adopts the conventions for normatve language to provide clarity of 128 instructions to the implementer. The key words "MUST", "MUST NOT", 129 "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", 130 "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be 131 interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only 132 when, they appear in all capitals, as shown here. 134 3. Applicability Statement 136 The two HMAC SHA [RFC6234] based cipher suites referenced in this 137 document are intended for a small limited set of applications where 138 confidentiality requirements are relaxed and the need to minimize the 139 cryptographic algorithms are prioritized. This section describes 140 some of those applicable use cases. 142 Use cases in the industrial automation industry, while requiring data 143 integrity, often do not require confidential communications. Mainly, 144 information communicated to unmanned machines to execute repetitive 145 tasks does not convey private information. For example, there could 146 be a system with a robotic arm that paints the body of a car. This 147 equipment is used within a car manufacturing plant, and is just one 148 piece of equipment in a multi-step manufacturing process. The 149 movements of this robotic arm are likely not a trade secret or 150 sensitive intellectual property, although some portions of the 151 manufacturing of the car might very well contain sesitivie 152 intellectual property. Even the mixture for the paint itself might 153 be confidential, but the mixing is done by a completely different 154 piece of equipment and therefore communciation to/from that equipment 155 can be encrypted without requiring the communication to/from the 156 robotic arm to be encrypted. Modern manufacturing often has 157 segmented equipment with different levels of risk on intellectual 158 property, although nearly every communciation interaction has strong 159 data authenticity requirements. 161 Another use case which is closely related is that of fine grained 162 time updates. Motion systems often rely on time synchronization to 163 ensure proper execution. Time updates are essentially public, there 164 is no threat from an attacker knowing the time update information. 165 This should make intuitive sense to those not familiar with these 166 applications; rarely if ever does time information present a serious 167 attack surface dealing with privacy. However the authenticity is 168 still quite important. Modification of the data can at best lead to 169 a denial-of-service attack, although a more intelligent threat actor 170 might be able to cause actual physical damage. As these time 171 synchronization updates are very fine-grained, it is again important 172 for latency to be very low. 174 A third use case deals with data related to alarms. Industrial 175 control sensing equipment can be configured to send alarm information 176 when it meets certain conditions, for example, temperature goes above 177 or below a given threshhold. Often times this data is used to detect 178 certain out-of-tolerance conditions, allowing an operator or 179 automated system to take corrective action. Once again, in many 180 systems the reading of this data doesn't grant the attacker 181 information that can be exploited, it is generally just information 182 regarding the physical state of the system. At the same time, being 183 able to modify this data would allow an attacker to either trigger 184 alarms falsely or to cover up evidence of an attack that might allow 185 for detection of their malicious activity. Furthermore, sensors are 186 often low powered devices that might struggle to process encrypted 187 and authenticated data. These sensors might be very cost sensitive 188 such that there is not enough processing power for data encryption. 189 Sending data that is just authenticated significantly eases the 190 burden placed on these devices, yet still allows the data to be 191 protected against any tampering threats. A user can always chose to 192 pay more for a sensor with encryption capability, but for some data 193 authenticity will be sufficient. 195 A fourth use case considers the protection of commands in the railway 196 industry. In railway control systems, no confidentiality 197 requirements are applied for the command exchange between an 198 interlocking controller and a railway equipment controller (for 199 instance, a railway point controller of a tram track where the 200 position of the controlled point is publicly available). However, 201 protecting integrity of those commands is vital, otherwise, an 202 adversary could change the target position of the point by modifying 203 the commands, which consequently could lead to the derailment of a 204 passing train. Furthermore, requirements for providing blackbox 205 recording of the safety related network traffic can only be fulfilled 206 through using integrity only ciphers, to be able to provide the 207 safety related commands to a third party, which is responsible for 208 the analysis after an accident. 210 The fifth use case deals with data related to civil aviation 211 airplanes and ground communication. Pilots can send and receive 212 messages to/from ground such as airplane route of flight update, 213 weather information, controller and pilot communication, and airline 214 back office communication. Similarly, the Air Traffic Control 215 Centers (ATC) use air to ground communication to receive the 216 surveillance data that relies on (is dependent on) downlink reports 217 from an airplane's avionics that occur automatically in accordance 218 with contracts established between the ATC ground system and the 219 airplane's avionics. Reports can be sent whenever specific events 220 occur, or specific time intervals are reached. In many systems the 221 reading of this data doesn't grant the attacker information that can 222 be exploited, it is generally just information regarding the airplane 223 states, controller pilot communication, meteorological information 224 etc. At the same time, being able to modify this data would allow an 225 attacker to either put aircraft in the wrong flight trajectory or to 226 provide false information to ground that might delay flight and 227 damage properties or harm life. Sending data that is just 228 authenticated allows the data to be protected against any tampering 229 threats. Data authenticity is sufficient for the air traffic, 230 weather and surveillance information exchange between airplanes and 231 the ground systems. 233 The above use cases describe the relaxed requirements to provide 234 confidentiality, and as these devices come with a small runtime 235 memory footprint and reduced processing power, the need to minimize 236 the number of cryptographic algorithms used is prioritized. Despite 237 this, it is noted that memory, performance, and processing power 238 implications of any given algorithm or set of algorithms is highly 239 dependent on hardware and software achitecture. Therefore, although 240 these cipher suites may provide performance benefits, they will not 241 necessarily provide these benefits in all cases on all platforms. 242 Furthermore, in some use cases third party inspection of data is 243 specifically needed, which is also supported through the lack of 244 confidentiality mechanisms. 246 4. Cryptographic Negotiation Using Integrity only Cipher Suites 248 The cryptographic negotiation as specified in [RFC8446] Section 4.1.1 249 remains the same, with the inclusion of the following cipher suites: 251 TLS_SHA256_SHA256 {0xC0, 0xB4} 253 TLS_SHA384_SHA384 {0xC0, 0xB5} 255 These cipher suites allow the use of SHA-256 or SHA-384 as the HMACs 256 for data integrity protection as well as its use for HKDF. The 257 authentication mechanisms remain unchanged with the intent to only 258 update the cipher suites to relax the need for confidentiality. 260 Given that these cipher suites do not support confidentiality, they 261 MUST only be used with certificate-based authentication and Diffie- 262 Hellman key exchange. 264 5. Record Payload Protection for Integrity only Cipher Suites 266 The record payload protection as defined in [RFC8446] can be retained 267 when integrity only cipher suites are used. Note that due to the 268 purposeful use of hash algorithms, instead of AEAD algorithms, the 269 confidentiality protection of the record payload cannot be provided. 270 This section describes the mapping of record payload structures when 271 integrity only cipher suites are employed. 273 Given that there is no encryption to be done at the record layer, the 274 operations "Protect" and "Unprotect" take the place of "AEAD-Encrypt" 275 and "AEAD-Decrypt", respectively, as referenced in [RFC8446] 277 As integrity is provided with protection over the full record, the 278 encrypted_record in the TLSCiphertext along with the additional_data 279 input to protected_data (termed AEADEncrypted data in [RFC8446]) as 280 defined in Section 5.2 of [RFC8446] remains the same. The 281 TLSCiphertext.length for the integrity cipher suites will be: 283 TLS_SHA256_SHA256: TLSCiphertext.length = TLSPlaintext.length + 1 284 (type field) + length_of_padding + 32 (HMAC) = 285 TLSInnerPlaintext_length + 32 (HMAC) 287 TLS_SHA384_SHA384: TLSCiphertext.length = TLSPlaintext.length + 1 288 (type field) + length_of_padding + 48 (HMAC) = 289 TLSInnerPlaintext_length + 48 (HMAC) 291 Note that TLSInnerPlaintext_length is not defined as an explicit 292 field in [RFC8446], this refers to the length of the 293 TLSInnterPlaintext structure 295 The resulting protected_record is the concatenation of the 296 TLSInnerPlaintext with the resulting HMAC. With this mapping, the 297 record validation order as defined in Section 5.2 of [RFC8446] 298 remains the same. That is, encrypted_record field of TLSCiphertext 299 is set to: 301 TLSCiphertext = TLS13-HMAC-Protected = TLSInnerPlaintext || 302 HMAC(write_key, nonce || additional_data || TLSInnerPlaintext) 304 Here "nonce" refers to the per-record nonce described in section 5.3 305 of [RFC8446]. 307 For DTLS 1.3, the DTLSCiphertext is set to: 309 DTLSCiphertext = DTLS13-HMAC-Protected = DTLSInnerPlaintext || 310 HMAC(write_key, nonce || additional_data || DTLSInnerPlaintext) 312 The DTLS "nonce" refers to the per-record nonce described in section 313 4.2.2 of [DTLS13]. 315 The Protect and Unprotect operations provide the integrity protection 316 using HMAC SHA-256 or HMAC SHA-384 as described in [RFC6234]. 318 Due to the lack of encryption of the plaintext, record padding is not 319 needed, although it can be optionally included. 321 6. Key Schedule when using Integrity only Cipher Suites 323 The key derivation process for Integrity only Cipher Suites remains 324 the same as defined in [RFC8446]. The only difference is that the 325 keys used to protect the tunnel apply to the negotiated HMAC SHA-256 326 or HMAC SHA-384 ciphers. Note that the traffic key material 327 (client_write_key, client_write_iv, server_write_key and 328 server_write_iv) MUST be calculated as per RFC 8446, section 7.3. 329 The key lengths and IVs for these cipher suites are according to the 330 hash lenghts. In other words, the following key lenghts and IV 331 lengths SHALL be: 333 +-------------------+------------+-----------+ 334 | Cipher Suite | Key Length | IV Length | 335 +-------------------+------------+-----------+ 336 | TLS_SHA256_SHA256 | 32 Bytes | 32 Bytes | 337 | TLS_SHA384_SHA384 | 48 Bytes | 48 Bytes | 338 +-------------------+------------+-----------+ 340 7. Error Alerts 342 The error alerts as defined by [RFC8446] remains the same, in 343 particular: 345 bad_record_mac: This alert can also occur for a record whose message 346 authentication code can not be validated. Since these cipher suites 347 do not involve record encryption this alert will only occur when the 348 HMAC fails to verify. 350 decrypt_error: This alert as described in [RFC8446] Section 6.2 351 occurs when the signature or message authentication code can not be 352 validated. 354 8. IANA Considerations 356 IANA has granted registration the following specifically for this 357 document within the TLS Cipher Suites Registry: 359 TLS_SHA256_SHA256 {0xC0, 0xB4} cipher suite and TLS_SHA384_SHA384 360 {0xC0, 0xB5} cipher suite. 362 Note that both of these cipher suites are registered with the DTLS-OK 363 column set to Y and the Recommended column set to N 365 No further IANA action is requested by this document. 367 9. Security and Privacy Considerations 369 In general, with the exception of confidentiality and privacy, the 370 security considerations detailed in [RFC8446] and in [RFC5246] apply 371 to this document. Furthermore, as the cipher suites described in 372 this document do not provide any confidentiality, it is important 373 that they only be used in cases where there are no confidentiality or 374 privacy requirements and concerns; and the runtime memory 375 requirements can accommodate support for more cryptographic 376 constructs. 378 With the lack of data encryption specified in this draft, no 379 confidentiality or privacy is provided for the data transported via 380 the TLS session. That is, the record layer is NOT encrypted when 381 using these cipehr suite, and the handshake also is NOT encrypted. 382 To highlight the loss of privacy, the information carried in the TLS 383 handshake, which includes both the Server and Client certificates, 384 while integrity protected, will be sent unencrypted. Similarly, 385 other TLS extensions that may be carried in the Server's 386 EncryptedExtensions message will only be integrity protected without 387 provisions for confidentiality. Furthermore, with this lack of 388 confidentiality, any private PSK data MUST NOT be sent in the 389 handshake while using these cipher suites. 391 Given the lack of confidentiality, these cipher suites MUST NOT be 392 enabled by default. As these cipher suites are meant to serve the 393 IoT market, it is important that any IoT endpoint that uses them be 394 explicitly configured with a policy of non-confidential 395 communications. 397 10. Acknowledgements 399 The authors would like to acknowledge the work done by Industrial 400 Communications Standards Groups (such as ODVA) as the motivation for 401 this document. We would also like to thank Steffen Fries for 402 providing a fourth use case. In addition, we are grateful for the 403 advice and feedback from Joe Salowey, Blake Anderson, David McGrew, 404 Clement Zeller, and Peter Wu. 406 11. References 408 11.1. Normative References 410 [DTLS13] IETF Internet Drafts editor, 411 "https://tools.ietf.org/id/draft-ietf-tls-dtls13-38.txt". 413 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 414 Requirement Levels", BCP 14, RFC 2119, 415 DOI 10.17487/RFC2119, March 1997, 416 . 418 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 419 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 420 DOI 10.17487/RFC6234, May 2011, 421 . 423 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 424 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 425 May 2017, . 427 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 428 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 429 . 431 11.2. Informative Reference 433 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 434 (TLS) Protocol Version 1.2", RFC 5246, 435 DOI 10.17487/RFC5246, August 2008, 436 . 438 Authors' Addresses 440 Nancy Cam-Winget 441 Cisco Systems 442 3550 Cisco Way 443 San Jose, CA 95134 444 USA 446 Email: ncamwing@cisco.com 448 Jack Visoky 449 ODVA 450 1 Allen Bradley Dr 451 Mayfield Heights, OH 44124 452 USA 454 Email: jmvisoky@ra.rockwell.com