idnits 2.17.1 draft-schmertmann-dice-ccm-psk-pfs-01.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 (August 15, 2014) is 3540 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4492 (Obsoleted by RFC 8422) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Schmertmann 3 Internet-Draft C. Bormann, Ed. 4 Intended status: Informational Universitaet Bremen TZI 5 Expires: February 16, 2015 August 15, 2014 7 ECDHE-PSK AES-CCM Cipher Suites with Forward Secrecy 8 for Transport Layer Security (TLS) 9 draft-schmertmann-dice-ccm-psk-pfs-01 11 Abstract 13 RFC 6655 describes the use of the Advanced Encryption Standard (AES) 14 in the Counter with Cipher Block Chaining - Message Authentication 15 Code (CBC-MAC) Mode (CCM) of operation within Transport Layer 16 Security (TLS) and Datagram TLS (DTLS) to provide confidentiality and 17 data origin authentication. The AES-CCM algorithm is amenable to 18 compact implementations, making it suitable for constrained 19 environments. It has been chosen as one of the preferred cipher 20 suites for use with DTLS in the Constrained Application Protocol, 21 CoAP. 23 The present document defines additional cipher suites that provide 24 forward secrecy. It also discusses an option to replace the Hash- 25 based PRF in RFC 6655 by CMAC, reducing the number of cryptographic 26 primitives required for implementation. (The intention is that the 27 option is either chosen or not chosen before this document is agreed, 28 not that both options are defined.) 30 This document is initially addressed at the DICE working group in 31 order to build consensus that there is an actual gap to be filled and 32 about the technical parameters of a solution for that gap. Once this 33 is agreed, the usual path for agreeing a cipher suite will need to be 34 taken. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at http://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on February 16, 2015. 53 Copyright Notice 55 Copyright (c) 2014 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 71 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 72 2. AES-CCM Cipher Suites with Forward Secrecy . . . . . . . . . 3 73 3. Option: Replacing the SHA-256 PRF with a CMAC-based PRF . . . 3 74 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 75 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 76 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 77 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 78 7.1. Normative References . . . . . . . . . . . . . . . . . . 5 79 7.2. Informative References . . . . . . . . . . . . . . . . . 6 80 Appendix A. Recommended Curves and Algorithms . . . . . . . . . 6 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 83 1. Introduction 85 [RFC6655] describes the use of Advanced Encryption Standard (AES) 86 [AES] in Counter with CBC-MAC Mode (CCM) [CCM] in several TLS cipher 87 suites. AES-CCM provides both authentication and confidentiality and 88 uses as its only primitive the AES encrypt operation (the AES decrypt 89 operation is not needed). This makes it amenable to compact 90 implementations, which is advantageous in constrained environments. 91 For instance, the use of AES-CCM has been specified for IPsec 92 Encapsulating Security Payload (ESP) [RFC4309] and 802.15.4 wireless 93 networks [IEEE802154]. 95 One of the cipher suites defined in RFC 6655, 96 TLS_PSK_WITH_AES_128_CCM_8, has been made one of the preferred cipher 97 suites for use with DTLS in CoAP, [RFC7252]. 99 The cipher suites defined in RFC 6655 do not provide forward secrecy 100 (see [RFC4949] for a definition). 102 The cipher suites defined in this document use Ephemeral Elliptic 103 Curve Diffie-Hellman (ECDHE) as their key establishment mechanism; 104 these cipher suites can be used with DTLS [RFC6347]. 106 Similar to the way [RFC5489] defines ECDHE_PSK cipher suites for RC4, 107 3DES, and AES, the present document defines equivalents of the cipher 108 suites defined in RFC 6655 (Table 1). 110 +----------------------------+----------------------------------+ 111 | RFC 6655 | Forward Secrecy (new) | 112 +----------------------------+----------------------------------+ 113 | TLS_PSK_WITH_AES_128_CCM | TLS_ECDHE_PSK_WITH_AES_128_CCM | 114 | | | 115 | TLS_PSK_WITH_AES_128_CCM_8 | TLS_ECDHE_PSK_WITH_AES_128_CCM_8 | 116 +----------------------------+----------------------------------+ 118 Table 1: new ECDHE_PSK ciphersuites using AES-CCM 120 These cipher suites are only defined for use with TLS version 1.2 and 121 above. They are DTLS-OK. 123 1.1. Terminology 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 127 document are to be interpreted as described in RFC 2119 [RFC2119]. 129 2. AES-CCM Cipher Suites with Forward Secrecy 131 The cipher suites defined in this document operate exactly like the 132 equivalent cipher suites defined in [RFC6655], except that the 133 ECDHE_PSK Key Exchange Algorithm from [RFC5489] is used for forming 134 the premaster secret. 136 3. Option: Replacing the SHA-256 PRF with a CMAC-based PRF 138 For both the cipher suites defined in RFC 6655 and the ones defined 139 in the previous section, the PRF is the TLS PRF [RFC5246] with 140 SHA-256 as the hash function. 142 This means that, besides AES encryption and ECDHE, implementations 143 have to provide SHA-256. The option discussed in this section would, 144 if taken, replace the SHA-256-based hash function with an AES-based 145 PRF. 147 In this section, we propose examining the use of AES-CMAC [RFC4493] 148 as the function underlying the TLS PRF, based on the recommendations 149 in [NISTKDF]. One way to do this (patterned somewhat after 150 [RFC4615], but with a counter that attempts to preserve more of the 151 entropy) is shown in Figure 1. 153 PRF(secret, label, seed) = P_CMAC(secret, label || seed) 155 P_CMAC(secret, seed) = STEP(0, 0, secret, A(1) || seed) || 156 STEP(0, 1, secret, A(2) || seed) || 157 STEP(0, 2, secret, A(3) || seed) || ... 158 A(0) = seed 159 A(i) = STEP(1, i, secret, A(i-1)) 161 STEP(v, i, secret, seed) = AES-CMAC(K(v, i, secret), seed) 163 K(v, i, secret) = AES-CMAC((v || 0^127) + i, secret) 164 (note that the + is addition) 166 Figure 1: CMAC-based PRF for TLS 168 P_CMAC can be iterated as many times as necessary to produce the 169 required quantity of data. 171 Defining such an alternative PRF requires security analysis that is 172 not provided in the present version of this document. 174 4. IANA Considerations 176 IANA is requested to assign values for the new ciphersuites defined 177 in Table 1 from the "TLS Cipher Suite" registry. 179 5. Security Considerations 181 The security considerations of [RFC5489] and [RFC6655] apply. 183 If the option to define a CMAC-based PRF is chosen, this section will 184 need to discuss its security considerations. 186 6. Acknowledgements 188 This document borrows heavily from RFC 6655. 190 7. References 192 7.1. Normative References 194 [AES] National Institute of Standards and Technology, 195 "Specification for the Advanced Encryption Standard 196 (AES)", FIPS 197, November 2001. 198 [CCM] National Institute of Standards and Technology, 199 "Recommendation for Block Cipher Modes of Operation: The 200 CCM Mode for Authentication and Confidentiality", SP 201 800-38C, May 2004. 203 [NISTKDF] Chen, L., "Recommendation for Key Derivation Using 204 Pseudorandom Functions", NIST Special Publication 800-108, 205 n.d.. 207 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 208 Requirement Levels", BCP 14, RFC 2119, March 1997. 210 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. 211 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites 212 for Transport Layer Security (TLS)", RFC 4492, May 2006. 214 [RFC4493] Song, JH., Poovendran, R., Lee, J., and T. Iwata, "The 215 AES-CMAC Algorithm", RFC 4493, June 2006. 217 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 218 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 220 [RFC5489] Badra, M. and I. Hajjeh, "ECDHE_PSK Cipher Suites for 221 Transport Layer Security (TLS)", RFC 5489, March 2009. 223 [RFC5639] Lochter, M. and J. Merkle, "Elliptic Curve Cryptography 224 (ECC) Brainpool Standard Curves and Curve Generation", RFC 225 5639, March 2010. 227 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 228 Security Version 1.2", RFC 6347, January 2012. 230 [RFC6655] McGrew, D. and D. Bailey, "AES-CCM Cipher Suites for 231 Transport Layer Security (TLS)", RFC 6655, July 2012. 233 7.2. Informative References 235 [IEEE802154] 236 Institute of Electrical and Electronics Engineers, 237 "Wireless Personal Area Networks", IEEE Standard 238 802.15.4-2006, 2006. 240 [RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM 241 Mode with IPsec Encapsulating Security Payload (ESP)", RFC 242 4309, December 2005. 244 [RFC4615] Song, J., Poovendran, R., Lee, J., and T. Iwata, "The 245 Advanced Encryption Standard-Cipher-based Message 246 Authentication Code-Pseudo-Random Function-128 (AES-CMAC- 247 PRF-128) Algorithm for the Internet Key Exchange Protocol 248 (IKE)", RFC 4615, August 2006. 250 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 251 4949, August 2007. 253 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 254 Application Protocol (CoAP)", RFC 7252, June 2014. 256 Appendix A. Recommended Curves and Algorithms 258 This memo does not mandate any particular elliptic curves or 259 cryptographic algorithms, for the sake of flexibility. However, 260 since the main motivation for the AES-CCM-ECC cipher suites is their 261 suitability for constrained environments, it is valuable to identify 262 a particular suitable set of curves and algorithms. 264 This appendix identifies a set of elliptic curves and cryptographic 265 algorithms that meet the requirements of this note, which are widely 266 supported and believed to be secure. 268 Where the following recommendations mention a hash function, the hash 269 function does not apply if the option to use CMAC as a PRF is chosen. 271 The curves and hash algorithms recommended for each cipher suite are: 273 An implementation that includes either 274 TLS_ECDHE_PSK_WITH_AES_128_CCM or 275 TLS_ECDHE_PSK_WITH_AES_128_CCM_8 SHOULD support the secp256r1 276 curve and the SHA-256 hash function. 278 More information about the secp256r1, secp384r1, and secp521r1 curves 279 is available in Appendix A of [RFC4492]. 281 It is not necessary to implement the above curves and hash functions 282 in order to conform to this specification. Other elliptic curves, 283 such as the Brainpool curves [RFC5639] for example, meet the criteria 284 laid out in this memo. 286 Authors' Addresses 288 Lars Schmertmann 289 Universitaet Bremen TZI 290 Postfach 330440 291 Bremen D-28359 292 Germany 294 Email: lars@tzi.de 296 Carsten Bormann (editor) 297 Universitaet Bremen TZI 298 Postfach 330440 299 Bremen D-28359 300 Germany 302 Phone: +49-421-218-63921 303 Email: cabo@tzi.org