idnits 2.17.1 draft-mcgrew-tls-aes-ccm-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 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 14, 2011) is 4789 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'AES' -- Possible downref: Non-RFC (?) normative reference: ref. 'CCM' ** Obsolete normative reference: RFC 4346 (Obsoleted by RFC 5246) ** Obsolete normative reference: RFC 4347 (Obsoleted by RFC 6347) ** Obsolete normative reference: RFC 4366 (Obsoleted by RFC 5246, RFC 6066) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TLS Working Group D. McGrew 3 Internet-Draft Cisco Systems, Inc. 4 Intended status: Standards Track D. Bailey 5 Expires: September 15, 2011 RSA, the Security Division of EMC 6 March 14, 2011 8 AES-CCM Cipher Suites for TLS 9 draft-mcgrew-tls-aes-ccm-01 11 Abstract 13 This memo describes the use of the Advanced Encryption Standard (AES) 14 in the Counter and CBC-MAC Mode (CCM) of operation within Transport 15 Layer Security (TLS) to provide confidentiality and data origin 16 authentication. The AES-CCM algorithm is amenable to compact 17 implementations, making it suitable for constrained environments. 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 http://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 September 15, 2011. 36 Copyright Notice 38 Copyright (c) 2011 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 (http://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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Conventions Used In This Document . . . . . . . . . . . . . . . 3 57 3. RSA Based AES-CCM Cipher Suites . . . . . . . . . . . . . . . . 3 59 4. PSK Based AES-CCM Cipher Suites . . . . . . . . . . . . . . . . 4 61 5. TLS Versions . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 6. New AEAD algorithms . . . . . . . . . . . . . . . . . . . . . . 5 64 6.1. AES-128-CCM with an 8-octet Integrity Check Value (ICV) . . 5 65 6.2. AES-256-CCM with a 8-octet Integrity Check Value (ICV) . . 5 67 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 69 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 70 8.1. Perfect Forward Secrecy . . . . . . . . . . . . . . . . . . 6 71 8.2. Counter Reuse . . . . . . . . . . . . . . . . . . . . . . . 6 73 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 75 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 76 10.1. Normative References . . . . . . . . . . . . . . . . . . . 6 77 10.2. Informative References . . . . . . . . . . . . . . . . . . 7 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 81 1. Introduction 83 This document describes the use of Advanced Encryption Standard (AES) 84 [AES] in Counter with CBC-MAC Mode (CCM) [CCM] in several TLS 85 ciphersuites. AES-CCM provides both authentication and 86 confidentiality and uses as its only primitive the AES encrypt 87 operation (the AES decrypt operation is not needed). This makes it 88 amenable to compact implementations, which is advantageous in 89 constrained environments. The use of AES-CCM has been specified for 90 IPsec ESP [RFC4309] and 802.15.4 wireless networks [IEEE802154]. 92 Authenticated encryption, in addition to providing confidentiality 93 for the plaintext that is encrypted, provides a way to check its 94 integrity and authenticity. Authenticated Encryption with Associated 95 Data, or AEAD [RFC5116], adds the ability to check the integrity and 96 authenticity of some associated data that is not encrypted. This 97 note utilizes the AEAD facility within TLS 1.2 [RFC5246] and the AES- 98 CCM-based AEAD algorithms defined in [RFC5116]. Additional AEAD 99 algorithms are defined, which use AES-CCM but which have shorter 100 authentication tags, and therefore are more suitable for use across 101 networks in which bandwidth is constrained and message sizes may be 102 small. 104 The ciphersuites defined in this document use RSA or Pre-Shared Key 105 (PSK) as their key establishment mechanism; these ciphersuites can be 106 used with DTLS [RFC4347]. 108 2. Conventions Used In This Document 110 he key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in [RFC2119] 114 3. RSA Based AES-CCM Cipher Suites 116 The ciphersuites defined in this document are based on the the AES- 117 CCM authenticated encryption with associated data (AEAD) algorithms 118 AEAD_AES_128_CCM and AEAD_AES_256_CCM described in [RFC5116]. The 119 following RSA-based ciphersuites are defined: 121 CipherSuite TLS_RSA_WITH_AES_128_CCM = {TBD1,TBD1} 122 CipherSuite TLS_RSA_WITH_AES_256_CCM = {TBD2,TBD2) 123 CipherSuite TLS_RSA_DHE_WITH_AES_128_CCM = {TBD3,TBD3} 124 CipherSuite TLS_RSA_DHE_WITH_AES_256_CCM = {TBD4,TBD4} 125 CipherSuite TLS_RSA_WITH_AES_128_CCM_8 = {TBD5,TBD5} 126 CipherSuite TLS_RSA_WITH_AES_256_CCM_8 = {TBD6,TBD6) 127 CipherSuite TLS_RSA_DHE_WITH_AES_128_CCM_8 = {TBD7,TBD7} 128 CipherSuite TLS_RSA_DHE_WITH_AES_256_CCM_8 = {TBD8,TBD8} 130 These ciphersuites make use of the AEAD capability in TLS 1.2 131 [RFC5246]. Note that each of these AEAD algorithms uses a 128-bit 132 authentication tag with CCM. 134 The HMAC truncation option described in Section 3.5 of [RFC4366] 135 (which negotiates the "truncated_hmac" TLS extension) does not have 136 an effect on cipher suites that do not use HMAC. 138 The "nonce" input to the AEAD algorithm is exactly that of [RFC5288]: 139 the "nonce" SHALL be 12 bytes long and is constructed as follows: 141 struct { 142 case client: 143 uint32 client_write_IV; // low order 32-bits 144 case server: 145 uint32 server_write_IV; // low order 32-bits 146 uint64 seq_num; 147 } CCMNonce. 149 In DTLS, the 64-bit seq_num is the 16-bit epoch concatenated with the 150 48-bit seq_num. 152 These ciphersuites make use of the default TLS 1.2 Pseudorandom 153 Function (PRF), which uses HMAC with the SHA-256 hash function. The 154 RSA and RSA-DHE key exchange is performed as defined in [RFC5288]. 156 4. PSK Based AES-CCM Cipher Suites 158 As in Section Section 3, these ciphersuites follow [RFC5116]. The 159 following ciphersuites are defined: 161 CipherSuite TLS_PSK_WITH_AES_128_CCM = {TBD9,TBD9} 162 CipherSuite TLS_PSK_WITH_AES_256_CCM = {TBD10,TBD10) 163 CipherSuite TLS_PSK_DHE_WITH_AES_128_CCM = {TBD11,TBD11} 164 CipherSuite TLS_PSK_DHE_WITH_AES_256_CCM = {TBD12,TBD12} 165 CipherSuite TLS_PSK_WITH_AES_128_CCM_8 = {TBD13,TBD13} 166 CipherSuite TLS_PSK_WITH_AES_256_CCM_8 = {TBD14,TBD14) 167 CipherSuite TLS_PSK_DHE_WITH_AES_128_CCM_8 = {TBD15,TBD15} 168 CipherSuite TLS_PSK_DHE_WITH_AES_256_CCM_8 = {TBD16,TBD16} 170 The "nonce" input to the AEAD algorithm is defined as in Section 171 Section 3. 173 These ciphersuites make use of the default TLS 1.2 Pseudorandom 174 Function (PRF), which uses HMAC with the SHA-256 hash function. The 175 PSK and PSK-DHE key exchange is performed as defined in [RFC5487]. 177 5. TLS Versions 179 These ciphersuites make use of the authenticated encryption with 180 additional data defined in TLS 1.2 [RFC5288]. They MUST NOT be 181 negotiated in older versions of TLS. Clients MUST NOT offer these 182 cipher suites if they do not offer TLS 1.2 or later. Servers which 183 select an earlier version of TLS MUST NOT select one of these cipher 184 suites. Because TLS has no way for the client to indicate that it 185 supports TLS 1.2 but not earlier, a non-compliant server might 186 potentially negotiate TLS 1.1 or earlier and select one of the cipher 187 suites in this document. Clients MUST check the TLS version and 188 generate a fatal "illegal_parameter" alert if they detect an 189 incorrect version. 191 6. New AEAD algorithms 193 The following AEAD algorithms are defined: 194 AEAD_AES_128_CCM_8 = TBD17 195 AEAD_AES_256_CCM_8 = TBD18 196 AEAD_AES_128_CCM_12 = TBD19 197 AEAD_AES_256_CCM_12 = TBD20 199 6.1. AES-128-CCM with an 8-octet Integrity Check Value (ICV) 201 The AEAD_AES_128_CCM_8 authenticated encryption algorithm is 202 identical to the AEAD_AES_128_CCM algorithm (see Section 5.3 of 203 [RFC5116]), except that it uses eight octets for authentication, 204 instead of the full sixteen octets used by AEAD_AES_128_CCM. The 205 AEAD_AES_128_CCM_8 ciphertext consists of the ciphertext output of 206 the CCM encryption operation concatenated with the 8-octet 207 authentication tag output of the CCM encryption operation. Test 208 cases are provided in [CCM]. The input and output lengths are as for 209 AEAD_AES_128_CCM. An AEAD_AES_128_CCM_8 ciphertext is exactly 8 210 octets longer than its corresponding plaintext. 212 6.2. AES-256-CCM with a 8-octet Integrity Check Value (ICV) 214 The AEAD_AES_256_CCM_8 authenticated encryption algorithm is 215 identical to the AEAD_AES_256_CCM algorithm (see Section 5.4 of 216 [RFC5116]), except that it uses eight octets for authentication, 217 instead of the full sixteen octets used by AEAD_AES_256_CCM. The 218 AEAD_AES_256_CCM_8 ciphertext consists of the ciphertext output of 219 the CCM encryption operation concatenated with the 8-octet 220 authentication tag output of the CCM encryption operation. Test 221 cases are provided in [CCM]. The input and output lengths are as as 222 for AEAD_AES_128_CCM. An AEAD_AES_128_CCM_8 ciphertext is exactly 8 223 octets longer than its corresponding plaintext. 225 7. IANA Considerations 227 IANA has assigned the values for the ciphersuites defined in 228 Section 3 and Section 4 and the values of the AEAD algorithms defined 229 in Section 6. 231 8. Security Considerations 233 8.1. Perfect Forward Secrecy 235 The perfect forward secrecy properties of RSA based TLS ciphersuites 236 are discussed in the security analysis of [RFC4346]. It should be 237 noted that only the ephemeral Diffie-Hellman based ciphersuites are 238 capable of providing perfect forward secrecy. 240 8.2. Counter Reuse 242 AES-CCM security requires that the counter is never reused. The IV 243 construction in Section 3 is designed to prevent counter reuse. 245 9. Acknowledgements 247 This draft borrows heavily from [RFC5288]. 249 10. References 251 10.1. Normative References 253 [AES] National Institute of Standards and Technology, 254 "Specification for the Advanced Encryption Standard 255 (AES)", FIPS 197, November 2001. 257 [CCM] National Institute of Standards and Technology, 258 "Recommendation for Block Cipher Modes of Operation: The 259 CCM Mode for Authentication and Confidentiality", SP 800- 260 38C, May 2004. 262 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 263 Requirement Levels", BCP 14, RFC 2119, March 1997. 265 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 266 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 268 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 269 Security", RFC 4347, April 2006. 271 [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 272 and T. Wright, "Transport Layer Security (TLS) 273 Extensions", RFC 4366, April 2006. 275 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 276 Encryption", RFC 5116, January 2008. 278 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 279 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 281 [RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois 282 Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, 283 August 2008. 285 [RFC5487] Badra, M., "Pre-Shared Key Cipher Suites for TLS with SHA- 286 256/384 and AES Galois Counter Mode", RFC 5487, 287 March 2009. 289 10.2. Informative References 291 [IEEE802154] 292 Institute of Electrical and Electronics Engineers, 293 "Wireless Personal Area Networks", IEEE Standard 802.15.4- 294 2006, 2006. 296 [RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM 297 Mode with IPsec Encapsulating Security Payload (ESP)", 298 RFC 4309, December 2005. 300 Authors' Addresses 302 David McGrew 303 Cisco Systems, Inc. 304 170 W Tasman Drive 305 San Jose, CA 95134 306 USA 308 Email: mcgrew@cisco.com 309 Daniel V. Bailey 310 RSA, the Security Division of EMC 311 174 Middlesex Tpke. 312 Bedford, MA 01463 313 USA 315 Email: dbailey@rsa.com