idnits 2.17.1 draft-mcgrew-tls-aes-ccm-02.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 (October 31, 2011) is 4532 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 4 Intended status: Standards Track D. Bailey 5 Expires: May 3, 2012 RSA, the Security Division of EMC 6 October 31, 2011 8 AES-CCM Cipher Suites for TLS 9 draft-mcgrew-tls-aes-ccm-02 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 May 3, 2012. 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 197 6.1. AES-128-CCM with an 8-octet Integrity Check Value (ICV) 199 The AEAD_AES_128_CCM_8 authenticated encryption algorithm is 200 identical to the AEAD_AES_128_CCM algorithm (see Section 5.3 of 201 [RFC5116]), except that it uses eight octets for authentication, 202 instead of the full sixteen octets used by AEAD_AES_128_CCM. The 203 AEAD_AES_128_CCM_8 ciphertext consists of the ciphertext output of 204 the CCM encryption operation concatenated with the 8-octet 205 authentication tag output of the CCM encryption operation. Test 206 cases are provided in [CCM]. The input and output lengths are as for 207 AEAD_AES_128_CCM. An AEAD_AES_128_CCM_8 ciphertext is exactly 8 208 octets longer than its corresponding plaintext. 210 6.2. AES-256-CCM with a 8-octet Integrity Check Value (ICV) 212 The AEAD_AES_256_CCM_8 authenticated encryption algorithm is 213 identical to the AEAD_AES_256_CCM algorithm (see Section 5.4 of 214 [RFC5116]), except that it uses eight octets for authentication, 215 instead of the full sixteen octets used by AEAD_AES_256_CCM. The 216 AEAD_AES_256_CCM_8 ciphertext consists of the ciphertext output of 217 the CCM encryption operation concatenated with the 8-octet 218 authentication tag output of the CCM encryption operation. Test 219 cases are provided in [CCM]. The input and output lengths are as as 220 for AEAD_AES_128_CCM. An AEAD_AES_128_CCM_8 ciphertext is exactly 8 221 octets longer than its corresponding plaintext. 223 7. IANA Considerations 225 IANA has assigned the values for the ciphersuites defined in 226 Section 3 and Section 4 and the values of the AEAD algorithms defined 227 in Section 6. 229 8. Security Considerations 231 8.1. Perfect Forward Secrecy 233 The perfect forward secrecy properties of RSA based TLS ciphersuites 234 are discussed in the security analysis of [RFC4346]. It should be 235 noted that only the ephemeral Diffie-Hellman based ciphersuites are 236 capable of providing perfect forward secrecy. 238 8.2. Counter Reuse 240 AES-CCM security requires that the counter is never reused. The IV 241 construction in Section 3 is designed to prevent counter reuse. 243 9. Acknowledgements 245 This draft borrows heavily from [RFC5288]. 247 10. References 249 10.1. Normative References 251 [AES] National Institute of Standards and Technology, 252 "Specification for the Advanced Encryption Standard 253 (AES)", FIPS 197, November 2001. 255 [CCM] National Institute of Standards and Technology, 256 "Recommendation for Block Cipher Modes of Operation: The 257 CCM Mode for Authentication and Confidentiality", SP 800- 258 38C, May 2004. 260 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 261 Requirement Levels", BCP 14, RFC 2119, March 1997. 263 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 264 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 266 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 267 Security", RFC 4347, April 2006. 269 [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 270 and T. Wright, "Transport Layer Security (TLS) 271 Extensions", RFC 4366, April 2006. 273 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 274 Encryption", RFC 5116, January 2008. 276 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 277 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 279 [RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois 280 Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, 281 August 2008. 283 [RFC5487] Badra, M., "Pre-Shared Key Cipher Suites for TLS with SHA- 284 256/384 and AES Galois Counter Mode", RFC 5487, 285 March 2009. 287 10.2. Informative References 289 [IEEE802154] 290 Institute of Electrical and Electronics Engineers, 291 "Wireless Personal Area Networks", IEEE Standard 802.15.4- 292 2006, 2006. 294 [RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM 295 Mode with IPsec Encapsulating Security Payload (ESP)", 296 RFC 4309, December 2005. 298 Authors' Addresses 300 David McGrew 301 Cisco Systems 302 13600 Dulles Technology Drive 303 Herndon, VA 20171 304 USA 306 Email: mcgrew@cisco.com 307 Daniel V. Bailey 308 RSA, the Security Division of EMC 309 174 Middlesex Tpke. 310 Bedford, MA 01463 311 USA 313 Email: dbailey@rsa.com