idnits 2.17.1 draft-mcgrew-tls-aes-ccm-00.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 (June 10, 2010) is 5069 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: December 12, 2010 RSA, the Security Division of EMC 6 June 10, 2010 8 AES-CCM Cipher Suites for TLS 9 draft-mcgrew-tls-aes-ccm-00 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 December 12, 2010. 36 Copyright Notice 38 Copyright (c) 2010 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 ICV . . . . . . . . . . . . . . 5 65 6.2. AES-256-CCM with a 8-octet 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 makes it useful in 89 constrained environments. The use of AES-CCM has been specified for 90 use with IPsec ESP [RFC4309] and 802.15.4 wireless networks 91 [IEEE802154]. 93 Authenticated encryption, in addition to providing confidentiality 94 for the plaintext that is encrypted, provides a way to check its 95 integrity and authenticity. Authenticated Encryption with Associated 96 Data, or AEAD [RFC5116], adds the ability to check the integrity and 97 authenticity of some associated data that is not encrypted. This 98 note utilizes the AEAD facility within TLS 1.2 [RFC5246] and the AES- 99 CCM-based AEAD algorithms defined in [RFC5116]. Additional AEAD 100 algorithms are defined, which use AES-CCM but which have shorter 101 authentication tags, and therefore are more suitable for use across 102 networks in which bandwidth is constrained and message sizes may be 103 small. 105 The ciphersuites defined in this document use RSA or Pre-Shared Key 106 (PSK) as their key establishment mechanism; these ciphersuites can be 107 used with DTLS [RFC4347]. 109 2. Conventions Used In This Document 111 he key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in [RFC2119] 115 3. RSA Based AES-CCM Cipher Suites 117 The ciphersuites defined in this document are based on the the AES- 118 CCM authenticated encryption with associated data (AEAD) algorithms 119 AEAD_AES_128_CCM and AEAD_AES_256_CCM described in [RFC5116]. The 120 following RSA-based ciphersuites are defined: 122 CipherSuite TLS_RSA_WITH_AES_128_CCM = {TBD1,TBD1} 123 CipherSuite TLS_RSA_WITH_AES_256_CCM = {TBD2,TBD2) 124 CipherSuite TLS_RSA_DHE_WITH_AES_128_CCM = {TBD3,TBD3} 125 CipherSuite TLS_RSA_DHE_WITH_AES_256_CCM = {TBD4,TBD4} 126 CipherSuite TLS_RSA_WITH_AES_128_CCM_8 = {TBD5,TBD5} 127 CipherSuite TLS_RSA_WITH_AES_256_CCM_8 = {TBD6,TBD6) 128 CipherSuite TLS_RSA_DHE_WITH_AES_128_CCM_8 = {TBD7,TBD7} 129 CipherSuite TLS_RSA_DHE_WITH_AES_256_CCM_8 = {TBD8,TBD8} 131 These ciphersuites make use of the AEAD capability in TLS 1.2 132 [RFC5246]. Note that each of these AEAD algorithms uses a 128-bit 133 authentication tag with CCM. 135 The HMAC truncation option described in Section 3.5 of [RFC4366] 136 (which negotiates the "truncated_hmac" TLS extension) does not have 137 an effect on cipher suites that do not use HMAC. 139 The "nonce" input to the AEAD algorithm is exactly that of [RFC5288]: 140 the "nonce" SHALL be 12 bytes long and is constructed as follows: 142 struct { 143 case client: 144 uint32 client_write_IV; // low order 32-bits 145 case server: 146 uint32 server_write_IV; // low order 32-bits 147 uint64 seq_num; 148 } CCMNonce. 150 In DTLS, the 64-bit seq_num is the 16-bit epoch concatenated with the 151 48-bit seq_num. 153 These ciphersuites make use of the default TLS 1.2 Pseudorandom 154 Function (PRF), which uses HMAC with the SHA-256 hash function. The 155 RSA and RSA-DHE key exchange is performed as defined in [RFC5288]. 157 4. PSK Based AES-CCM Cipher Suites 159 As in Section Section 3, these ciphersuites follow [RFC5116]. The 160 following ciphersuites are defined: 162 CipherSuite TLS_PSK_WITH_AES_128_CCM = {TBD9,TBD9} 163 CipherSuite TLS_PSK_WITH_AES_256_CCM = {TBD10,TBD10) 164 CipherSuite TLS_PSK_DHE_WITH_AES_128_CCM = {TBD11,TBD11} 165 CipherSuite TLS_PSK_DHE_WITH_AES_256_CCM = {TBD12,TBD12} 166 CipherSuite TLS_PSK_WITH_AES_128_CCM_8 = {TBD13,TBD13} 167 CipherSuite TLS_PSK_WITH_AES_256_CCM_8 = {TBD14,TBD14) 168 CipherSuite TLS_PSK_DHE_WITH_AES_128_CCM_8 = {TBD15,TBD15} 169 CipherSuite TLS_PSK_DHE_WITH_AES_256_CCM_8 = {TBD16,TBD16} 171 The "nonce" input to the AEAD algorithm is defined as in Section 172 Section 3. 174 These ciphersuites make use of the default TLS 1.2 Pseudorandom 175 Function (PRF), which uses HMAC with the SHA-256 hash function. The 176 PSK and PSK-DHE key exchange is performed as defined in [RFC5487]. 178 5. TLS Versions 180 These ciphersuites make use of the authenticated encryption with 181 additional data defined in TLS 1.2 [RFC5288]. They MUST NOT be 182 negotiated in older versions of TLS. Clients MUST NOT offer these 183 cipher suites if they do not offer TLS 1.2 or later. Servers which 184 select an earlier version of TLS MUST NOT select one of these cipher 185 suites. Because TLS has no way for the client to indicate that it 186 supports TLS 1.2 but not earlier, a non-compliant server might 187 potentially negotiate TLS 1.1 or earlier and select one of the cipher 188 suites in this document. Clients MUST check the TLS version and 189 generate a fatal "illegal_parameter" alert if they detect an 190 incorrect version. 192 6. New AEAD algorithms 194 The following AEAD algorithms are defined: 195 AEAD_AES_128_CCM_8 = TBD17 196 AEAD_AES_256_CCM_8 = TBD18 197 AEAD_AES_128_CCM_12 = TBD19 198 AEAD_AES_256_CCM_12 = TBD20 200 6.1. AES-128-CCM with an 8-octet ICV 202 The AEAD_AES_128_CCM_8 authenticated encryption algorithm is 203 identical to the AEAD_AES_128_CCM algorithm (see Section 5.3 of 204 [RFC5116]), except that it uses eight octets for authentication, 205 instead of the full sixteen octets used by AEAD_AES_128_CCM. The 206 AEAD_AES_128_CCM_8 ciphertext consists of the ciphertext output of 207 the CCM encryption operation concatenated with the 8-octet 208 authentication tag output of the CCM encryption operation. Test 209 cases are provided in [CCM]. The input and output lengths are as for 210 AEAD_AES_128_CCM. An AEAD_AES_128_CCM_8 ciphertext is exactly 8 211 octets longer than its corresponding plaintext. 213 6.2. AES-256-CCM with a 8-octet ICV 215 The AEAD_AES_256_CCM_8 authenticated encryption algorithm is 216 identical to the AEAD_AES_256_CCM algorithm (see Section 5.4 of 217 [RFC5116]), except that it uses eight octets for authentication, 218 instead of the full sixteen octets used by AEAD_AES_256_CCM. The 219 AEAD_AES_256_CCM_8 ciphertext consists of the ciphertext output of 220 the CCM encryption operation concatenated with the 8-octet 221 authentication tag output of the CCM encryption operation. Test 222 cases are provided in [CCM]. The input and output lengths are as as 223 for AEAD_AES_128_CCM. An AEAD_AES_128_CCM_8 ciphertext is exactly 8 224 octets longer than its corresponding plaintext. 226 7. IANA Considerations 228 IANA has assigned the values for the ciphersuites defined in 229 Section 3 and Section 4 and the values of the AEAD algorithms defined 230 in Section 6. 232 8. Security Considerations 234 8.1. Perfect Forward Secrecy 236 The perfect forward secrecy properties of RSA based TLS ciphersuites 237 are discussed in the security analysis of [RFC4346]. It should be 238 noted that only the ephemeral Diffie-Hellman based ciphersuites are 239 capable of providing perfect forward secrecy. 241 8.2. Counter Reuse 243 AES-CCM security requires that the counter is never reused. The IV 244 construction in Section 3 is designed to prevent counter reuse. 246 9. Acknowledgements 248 This draft borrows heavily from [RFC5288]. 250 10. References 252 10.1. Normative References 254 [AES] National Institute of Standards and Technology, 255 "Specification for the Advanced Encryption Standard 256 (AES)", FIPS 197, November 2001. 258 [CCM] National Institute of Standards and Technology, 259 "Recommendation for Block Cipher Modes of Operation: The 260 CCM Mode for Authentication and Confidentiality", SP 800- 261 38C, May 2004. 263 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 264 Requirement Levels", BCP 14, RFC 2119, March 1997. 266 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 267 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 269 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 270 Security", RFC 4347, April 2006. 272 [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 273 and T. Wright, "Transport Layer Security (TLS) 274 Extensions", RFC 4366, April 2006. 276 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 277 Encryption", RFC 5116, January 2008. 279 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 280 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 282 [RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois 283 Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, 284 August 2008. 286 [RFC5487] Badra, M., "Pre-Shared Key Cipher Suites for TLS with SHA- 287 256/384 and AES Galois Counter Mode", RFC 5487, 288 March 2009. 290 10.2. Informative References 292 [IEEE802154] 293 Institute of Electrical and Electronics Engineers, 294 "Wireless Personal Area Networks", IEEE Standard 802.15.4- 295 2006, 2006. 297 [RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM 298 Mode with IPsec Encapsulating Security Payload (ESP)", 299 RFC 4309, December 2005. 301 Authors' Addresses 303 David McGrew 304 Cisco Systems, Inc. 305 170 W Tasman Drive 306 San Jose, CA 95134 307 USA 309 Email: mcgrew@cisco.com 310 Daniel V. Bailey 311 RSA, the Security Division of EMC 312 174 Middlesex Tpke. 313 Bedford, MA 01463 314 USA 316 Email: dbailey@rsa.com