idnits 2.17.1 draft-ietf-tls-ecdhe-psk-aead-04.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 date (May 18, 2017) is 2535 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-28) exists of draft-ietf-tls-tls13-20 ** Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 4346 (Obsoleted by RFC 5246) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) -- Obsolete informational reference (is this intentional?): RFC 4492 (Obsoleted by RFC 8422) -- Obsolete informational reference (is this intentional?): RFC 7525 (Obsoleted by RFC 9325) -- Obsolete informational reference (is this intentional?): RFC 7540 (Obsoleted by RFC 9113) Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Mattsson 3 Internet-Draft D. Migault 4 Intended status: Standards Track Ericsson 5 Expires: November 19, 2017 May 18, 2017 7 ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for Transport Layer 8 Security (TLS) 9 draft-ietf-tls-ecdhe-psk-aead-04 11 Abstract 13 This document defines several new cipher suites for the Transport 14 Layer Security (TLS) protocol. The cipher suites are all based on 15 the Ephemeral Elliptic Curve Diffie-Hellman with Pre-Shared Key 16 (ECDHE_PSK) key exchange together with the Authenticated Encryption 17 with Associated Data (AEAD) algorithms AES-GCM and AES-CCM. PSK 18 provides light and efficient authentication, ECDHE provides forward 19 secrecy, and AES-GCM and AES-CCM provides encryption and integrity 20 protection. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on November 19, 2017. 39 Copyright Notice 41 Copyright (c) 2017 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 2 57 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 3. ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites . . . . . . 3 59 4. Applicable TLS Versions . . . . . . . . . . . . . . . . . . . 3 60 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 61 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 62 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 63 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 65 8.2. Informative References . . . . . . . . . . . . . . . . . 7 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 68 1. Requirements notation 70 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 71 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 72 document are to be interpreted as described in [RFC2119]. 74 2. Introduction 76 This document defines new cipher suites that provide Pre-Shared Key 77 (PSK) authentication, Perfect Forward Secrecy (PFS), and 78 Authenticated Encryption with Associated Data (AEAD). The cipher 79 suites are defined for version 1.2 of the Transport Layer Security 80 (TLS) [RFC5246] protocol, version 1.2 of the Datagram Transport Layer 81 Security (DTLS) protocol [RFC6347], as well as version 1.3 of TLS 82 [I-D.ietf-tls-tls13]. 84 Pre-Shared Key (PSK) Authentication is widely used in many scenarios. 85 One deployment is 3GPP networks where pre-shared keys are used to 86 authenticate both subscriber and network. Another deployment is 87 Internet of Things where PSK authentication is often preferred for 88 performance and energy efficiency reasons. In both scenarios the 89 endpoints are owned/controlled by a party that provisions the pre- 90 shared keys and makes sure that they provide a high level of entropy. 92 Perfect Forward Secrecy (PFS) is a strongly recommended feature in 93 security protocol design and can be accomplished by using an 94 ephemeral Diffie-Hellman key exchange method. Ephemeral Elliptic 95 Curve Diffie-Hellman (ECDHE) provides PFS with excellent performance 96 and small key sizes. ECDHE is mandatory to implement in both HTTP/2 97 [RFC7540] and CoAP [RFC7252]. 99 AEAD algorithms that combine encryption and integrity protection are 100 strongly recommended for (D)TLS [RFC7525] and non-AEAD algorithms are 101 forbidden to use in TLS 1.3 [I-D.ietf-tls-tls13]. The AEAD 102 algorithms considered in this document are AES-GCM and AES-CCM. The 103 use of AES-GCM in TLS is defined in [RFC5288] and the use of AES-CCM 104 is defined in [RFC6655]. 106 [RFC4279] defines Pre-Shared Key (PSK) cipher suites for TLS but does 107 not consider Elliptic Curve Cryptography. [RFC4492] introduces 108 Elliptic Curve Cryptography for TLS but does not consider PSK 109 authentication. [RFC5487] describes the use of AES-GCM in 110 combination with PSK authentication, but does not consider ECDHE. 111 [RFC5489] describes the use of PSK in combination with ECDHE but does 112 not consider AES-GCM or AES-CCM. 114 3. ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites 116 The cipher suites defined in this document are based on the AES-GCM 117 and AES-CCM Authenticated Encryption with Associated Data (AEAD) 118 algorithms AEAD_AES_128_GCM, AEAD_AES_256_GCM and AEAD_AES_128_CCM 119 defined in [RFC5116], and AEAD_AES_128_CCM_8 defined in [RFC6655]. 121 Messages and pre-master secret construction in this document are 122 defined in [RFC5489]. The ServerKeyExchange and ClientKeyExchange 123 messages are used and the pre-master secret is computed as for the 124 ECDHE_PSK key exchange. The elliptic curve parameters used in in the 125 Diffie-Hellman parameters are negotiated using extensions defined in 126 [I-D.ietf-tls-rfc4492bis]. 128 For TLS 1.2, the following cipher suites are defined: 130 TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 = {0xTBD,0xTBD}; 131 TLS_ECDHE_PSK_WITH_AES_256_GCM_SHA384 = {0xTBD,0xTBD}; 132 TLS_ECDHE_PSK_WITH_AES_128_CCM_8_SHA256 = {0xTBD,0xTBD}; 133 TLS_ECDHE_PSK_WITH_AES_128_CCM_SHA256 = {0xTBD,0xTBD}; 135 The assigned code points can only be used for TLS 1.2. 137 4. Applicable TLS Versions 139 The cipher suites defined in this document MUST NOT be negotiated for 140 any version of (D)TLS other than TLS 1.2. 142 TLS version 1.3 and later negotiate these features in a different 143 manner. Unlike TLS 1.2, TLS 1.3 separates authentication and cipher 144 suite negotiation [I-D.ietf-tls-tls13] Section 1.2. TLS 1.3 supports 145 PSK with ECDHE key exchange and the cipher suites 146 TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, 147 TLS_AES_128_CCM_8_SHA256 and TLS_AES_128_CCM_SHA256 are part of the 148 specification. As a result, TLS 1.3 and higher versions, negotiate 149 and support these cipher suites in a different way. 151 The cipher suites defined in this document make use of the 152 authenticated encryption with additional data (AEAD) defined in TLS 153 1.2 [RFC5246] and DTLS 1.2 [RFC6347]. Earlier versions of TLS do not 154 have support for AEAD and consequently, the cipher suites defined in 155 this document MUST NOT be negotiated in TLS versions prior to 1.2. 156 In addition, it is worth noting that TLS 1.0 [RFC2246] and TL1.2 157 [RFC4346] splits the pre-master in two parts. The PRF results from 158 mixing the two pseudorandom streams with distinct hash functions (MD5 159 and SHA-1) by exclusive-ORing them together. In the case of 160 ECDHE_PSK authentication, the PSK and pre-master are treated by 161 distinct hash function with distinct properties. This may introduce 162 vulnerabilities over the expected security provided by the 163 constructed pre-master. As such TLS 1.0 and TLS 1.1 should not be 164 used with ECDHE_PSK. 166 A client that offers the cipher suites from this document in 167 ClientHello.cipher_suites in combination with (3,1) "TLS 1.0" or 168 (3,2) "TLS 1.1" in ClientHello.client_version MUST support TLS 1.2 169 and MUST accept the server to negotiate TLS 1.2 for the current 170 session. If the client does not support TLS 1.2 or is not willing to 171 negotiate TLS 1.2, then this client MUST NOT offer any of these 172 cipher suites with a lower protocol version than (3,3) "TLS 1.2" in 173 ClientHello.client_version. 175 A server receiving a ClientHello and a client_version indicating 176 (3,1) "TLS 1.0" or (3,2) "TLS 1.1" and any of the cipher suites from 177 this document in ClientHello.cipher_suites can safely assume that the 178 client supports TLS 1.2 and is willing to use it. The server MUST 179 NOT negotiate these cipher suites with TLS protocol versions earlier 180 than TLS 1.2. Not requiring clients to indicate their support for 181 TLS 1.2 cipher suites exclusively through ClientHello.client_hello 182 improves the interoperability in the installed base and use of TLS 183 1.2 AEAD cipher suites without upsetting the installed base of 184 version-intolerant TLS servers, results in more TLS handshakes 185 succeeding and obviates fallback mechanisms. 187 5. IANA Considerations 189 This document defines the following new cipher suites, whose values 190 have been assigned in the TLS Cipher Suite Registry defined by 191 [RFC5246]. 193 TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 = {0xTBD; 0xTBD} {0xD0,0x01}; 194 TLS_ECDHE_PSK_WITH_AES_256_GCM_SHA384 = {0xTBD; 0xTBD} {0xD0,0x02}; 195 TLS_ECDHE_PSK_WITH_AES_128_CCM_8_SHA256 = {0xTBD; 0xTBD} {0xD0,0x03}; 196 TLS_ECDHE_PSK_WITH_AES_128_CCM_SHA256 = {0xTBD; 0xTBD} {0xD0,0x05}; 198 NOTE TO THE RFC EDITOR: PLEASE REMOVE THIS PARAGRAPH. The cipher 199 suite numbers listed in the last column are numbers used for cipher 200 suite interoperability testing and it's suggested that IANA use these 201 values for assignment. 203 6. Security Considerations 205 The security considerations in TLS 1.2 [RFC5246], DTLS 1.2 [RFC6347], 206 TLS 1.3 [I-D.ietf-tls-tls13], ECDHE_PSK [RFC5489], AES-GCM [RFC5288], 207 and AES-CCM [RFC6655] apply to this document as well. 209 All the cipher suites defined in this document provide 210 confidentiality, mutual authentication, and forward secrecy. The 211 AES-128 cipher suites provide 128-bit security and the AES-256 cipher 212 suites provide at least 192-bit security. However, AES_128_CCM_8 213 only provides 64-bit security against message forgery. 215 Use of Pre-Shared Keys of limited entropy may allow an active 216 attacker attempts to connect to the server and try different keys. 217 For example, limited entropy may be provided by using a short PSK in 218 which case an attacker may perform a brute-force attack. Another 219 example includes the use of a PSK chosen by a human which thus may be 220 exposed to dictionary attacks. 222 The Pre-Shared Keys used for authentication MUST have a security 223 level equal or higher than the cipher suite used, i.e., at least 224 128-bit for the AES-128 cipher suites and at least 192-bit for the 225 AES-256 cipher suites. 227 GCM or CCM encryption - even of different clear text - re-using a 228 nonce with a same key undermines the security of GCM and CCM. As a 229 result, GCM and CCM MUST only be used with a system guaranteeing 230 nonce uniqueness [RFC5116]. 232 7. Acknowledgements 234 The authors would like to thank Ilari Liusvaara, Eric Rescorla, Dan 235 Harkins, Russ Housley, Dan Harkins, Martin Thomson, Nikos 236 Mavrogiannopoulos, Peter Dettman, Xiaoyin Liu, Joseph Salowey, Sean 237 Turner Dave Garrett, Martin Rex and Kathleen Moriarty for their 238 valuable comments and feedback. 240 8. References 242 8.1. Normative References 244 [I-D.ietf-tls-rfc4492bis] 245 Nir, Y., Josefsson, S., and M. Pegourie-Gonnard, "Elliptic 246 Curve Cryptography (ECC) Cipher Suites for Transport Layer 247 Security (TLS) Versions 1.2 and Earlier", draft-ietf-tls- 248 rfc4492bis-17 (work in progress), May 2017. 250 [I-D.ietf-tls-tls13] 251 Rescorla, E., "The Transport Layer Security (TLS) Protocol 252 Version 1.3", draft-ietf-tls-tls13-20 (work in progress), 253 April 2017. 255 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 256 Requirement Levels", BCP 14, RFC 2119, 257 DOI 10.17487/RFC2119, March 1997, 258 . 260 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 261 RFC 2246, DOI 10.17487/RFC2246, January 1999, 262 . 264 [RFC4279] Eronen, P., Ed. and H. Tschofenig, Ed., "Pre-Shared Key 265 Ciphersuites for Transport Layer Security (TLS)", 266 RFC 4279, DOI 10.17487/RFC4279, December 2005, 267 . 269 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 270 (TLS) Protocol Version 1.1", RFC 4346, 271 DOI 10.17487/RFC4346, April 2006, 272 . 274 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 275 Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, 276 . 278 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 279 (TLS) Protocol Version 1.2", RFC 5246, 280 DOI 10.17487/RFC5246, August 2008, 281 . 283 [RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois 284 Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, 285 DOI 10.17487/RFC5288, August 2008, 286 . 288 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 289 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 290 January 2012, . 292 [RFC6655] McGrew, D. and D. Bailey, "AES-CCM Cipher Suites for 293 Transport Layer Security (TLS)", RFC 6655, 294 DOI 10.17487/RFC6655, July 2012, 295 . 297 8.2. Informative References 299 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. 300 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites 301 for Transport Layer Security (TLS)", RFC 4492, 302 DOI 10.17487/RFC4492, May 2006, 303 . 305 [RFC5487] Badra, M., "Pre-Shared Key Cipher Suites for TLS with SHA- 306 256/384 and AES Galois Counter Mode", RFC 5487, 307 DOI 10.17487/RFC5487, March 2009, 308 . 310 [RFC5489] Badra, M. and I. Hajjeh, "ECDHE_PSK Cipher Suites for 311 Transport Layer Security (TLS)", RFC 5489, 312 DOI 10.17487/RFC5489, March 2009, 313 . 315 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 316 Application Protocol (CoAP)", RFC 7252, 317 DOI 10.17487/RFC7252, June 2014, 318 . 320 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 321 "Recommendations for Secure Use of Transport Layer 322 Security (TLS) and Datagram Transport Layer Security 323 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 324 2015, . 326 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 327 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 328 DOI 10.17487/RFC7540, May 2015, 329 . 331 Authors' Addresses 332 John Mattsson 333 Ericsson AB 334 SE-164 80 Stockholm 335 Sweden 337 Phone: +46 76 115 35 01 338 Email: john.mattsson@ericsson.com 340 Daniel Migault 341 Ericsson 342 8400 boulevard Decarie 343 Montreal, QC H4P 2N2 344 Canada 346 Phone: +1 514-452-2160 347 Email: daniel.migault@ericsson.com