idnits 2.17.1 draft-mcgrew-tls-aes-ccm-03.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 (February 13, 2012) is 4449 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 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) Summary: 2 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: August 16, 2012 RSA, the Security Division of EMC 6 February 13, 2012 8 AES-CCM Cipher Suites for TLS 9 draft-mcgrew-tls-aes-ccm-03 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) and Datagram TLS (DTLS) to provide 16 confidentiality and data origin authentication. The AES-CCM 17 algorithm is amenable to compact implementations, making it suitable 18 for constrained environments. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on August 16, 2012. 37 Copyright Notice 39 Copyright (c) 2012 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Conventions Used In This Document . . . . . . . . . . . . . . . 3 58 3. RSA Based AES-CCM Cipher Suites . . . . . . . . . . . . . . . . 3 60 4. PSK Based AES-CCM Cipher Suites . . . . . . . . . . . . . . . . 4 62 5. TLS Versions . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 6. New AEAD algorithms . . . . . . . . . . . . . . . . . . . . . . 5 65 6.1. AES-128-CCM with an 8-octet Integrity Check Value (ICV) . . 5 66 6.2. AES-256-CCM with a 8-octet Integrity Check Value (ICV) . . 6 68 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 70 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 71 8.1. Perfect Forward Secrecy . . . . . . . . . . . . . . . . . . 6 72 8.2. Counter Reuse . . . . . . . . . . . . . . . . . . . . . . . 6 74 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 76 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 77 10.1. Normative References . . . . . . . . . . . . . . . . . . . 7 78 10.2. Informative References . . . . . . . . . . . . . . . . . . 7 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 82 1. Introduction 84 This document describes the use of Advanced Encryption Standard (AES) 85 [AES] in Counter with CBC-MAC Mode (CCM) [CCM] in several TLS 86 ciphersuites. AES-CCM provides both authentication and 87 confidentiality and uses as its only primitive the AES encrypt 88 operation (the AES decrypt operation is not needed). This makes it 89 amenable to compact implementations, which is advantageous in 90 constrained environments. The use of AES-CCM has been specified for 91 IPsec ESP [RFC4309] and 802.15.4 wireless networks [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 [RFC6347]. Since the abiltiy to use AEAD ciphers was 108 introduced in DTLS version 1.2, the ciphersuites defined in this note 109 cannot be used with earlier versions of that protocol. 111 2. Conventions Used In This Document 113 he key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in [RFC2119] 117 3. RSA Based AES-CCM Cipher Suites 119 The ciphersuites defined in this document are based on the the AES- 120 CCM authenticated encryption with associated data (AEAD) algorithms 121 AEAD_AES_128_CCM and AEAD_AES_256_CCM described in [RFC5116]. The 122 following RSA-based ciphersuites are defined: 124 CipherSuite TLS_RSA_WITH_AES_128_CCM = {TBD1,TBD1} 125 CipherSuite TLS_RSA_WITH_AES_256_CCM = {TBD2,TBD2) 126 CipherSuite TLS_RSA_DHE_WITH_AES_128_CCM = {TBD3,TBD3} 127 CipherSuite TLS_RSA_DHE_WITH_AES_256_CCM = {TBD4,TBD4} 128 CipherSuite TLS_RSA_WITH_AES_128_CCM_8 = {TBD5,TBD5} 129 CipherSuite TLS_RSA_WITH_AES_256_CCM_8 = {TBD6,TBD6) 130 CipherSuite TLS_RSA_DHE_WITH_AES_128_CCM_8 = {TBD7,TBD7} 131 CipherSuite TLS_RSA_DHE_WITH_AES_256_CCM_8 = {TBD8,TBD8} 133 These ciphersuites make use of the AEAD capability in TLS 1.2 134 [RFC5246]. Each uses AES-CCM; those that end in "_8" have an 8-octet 135 authentication tag, while the other ciphersuites have 16-octet 136 authentication tags. 138 The HMAC truncation option described in Section 7 of [RFC6066] (which 139 negotiates the "truncated_hmac" TLS extension) does not have an 140 effect on cipher suites that do not use HMAC. 142 The "nonce" input to the AEAD algorithm is exactly that of [RFC5288]: 143 the "nonce" SHALL be 12 bytes long and is constructed as follows: 145 struct { 146 case client: 147 uint32 client_write_IV; // low order 32-bits 148 case server: 149 uint32 server_write_IV; // low order 32-bits 150 uint64 seq_num; 151 } CCMNonce. 153 In DTLS, the 64-bit seq_num is the 16-bit epoch concatenated with the 154 48-bit seq_num. 156 These ciphersuites make use of the default TLS 1.2 Pseudorandom 157 Function (PRF), which uses HMAC with the SHA-256 hash function. The 158 RSA and RSA-DHE key exchange is performed as defined in [RFC5288]. 160 4. PSK Based AES-CCM Cipher Suites 162 As in Section Section 3, these ciphersuites follow [RFC5116]. The 163 following ciphersuites are defined: 165 CipherSuite TLS_PSK_WITH_AES_128_CCM = {TBD9,TBD9} 166 CipherSuite TLS_PSK_WITH_AES_256_CCM = {TBD10,TBD10) 167 CipherSuite TLS_PSK_DHE_WITH_AES_128_CCM = {TBD11,TBD11} 168 CipherSuite TLS_PSK_DHE_WITH_AES_256_CCM = {TBD12,TBD12} 169 CipherSuite TLS_PSK_WITH_AES_128_CCM_8 = {TBD13,TBD13} 170 CipherSuite TLS_PSK_WITH_AES_256_CCM_8 = {TBD14,TBD14) 171 CipherSuite TLS_PSK_DHE_WITH_AES_128_CCM_8 = {TBD15,TBD15} 172 CipherSuite TLS_PSK_DHE_WITH_AES_256_CCM_8 = {TBD16,TBD16} 174 The "nonce" input to the AEAD algorithm is defined as in Section 175 Section 3. 177 These ciphersuites make use of the default TLS 1.2 Pseudorandom 178 Function (PRF), which uses HMAC with the SHA-256 hash function. The 179 PSK and PSK-DHE key exchange is performed as defined in [RFC5487]. 181 5. TLS Versions 183 These ciphersuites make use of the authenticated encryption with 184 additional data defined in TLS 1.2 [RFC5288]. They MUST NOT be 185 negotiated in older versions of TLS. Clients MUST NOT offer these 186 cipher suites if they do not offer TLS 1.2 or later. Servers which 187 select an earlier version of TLS MUST NOT select one of these cipher 188 suites. Because TLS has no way for the client to indicate that it 189 supports TLS 1.2 but not earlier, a non-compliant server might 190 potentially negotiate TLS 1.1 or earlier and select one of the cipher 191 suites in this document. Clients MUST check the TLS version and 192 generate a fatal "illegal_parameter" alert if they detect an 193 incorrect version. 195 6. New AEAD algorithms 197 The following AEAD algorithms are defined: 198 AEAD_AES_128_CCM_8 = TBD17 199 AEAD_AES_256_CCM_8 = TBD18 201 6.1. AES-128-CCM with an 8-octet Integrity Check Value (ICV) 203 The AEAD_AES_128_CCM_8 authenticated encryption algorithm is 204 identical to the AEAD_AES_128_CCM algorithm (see Section 5.3 of 205 [RFC5116]), except that it uses eight octets for authentication, 206 instead of the full sixteen octets used by AEAD_AES_128_CCM. The 207 AEAD_AES_128_CCM_8 ciphertext consists of the ciphertext output of 208 the CCM encryption operation concatenated with the 8-octet 209 authentication tag output of the CCM encryption operation. Test 210 cases are provided in [CCM]. The input and output lengths are as for 211 AEAD_AES_128_CCM. An AEAD_AES_128_CCM_8 ciphertext is exactly 8 212 octets longer than its corresponding plaintext. 214 6.2. AES-256-CCM with a 8-octet Integrity Check Value (ICV) 216 The AEAD_AES_256_CCM_8 authenticated encryption algorithm is 217 identical to the AEAD_AES_256_CCM algorithm (see Section 5.4 of 218 [RFC5116]), except that it uses eight octets for authentication, 219 instead of the full sixteen octets used by AEAD_AES_256_CCM. The 220 AEAD_AES_256_CCM_8 ciphertext consists of the ciphertext output of 221 the CCM encryption operation concatenated with the 8-octet 222 authentication tag output of the CCM encryption operation. Test 223 cases are provided in [CCM]. The input and output lengths are as as 224 for AEAD_AES_128_CCM. An AEAD_AES_128_CCM_8 ciphertext is exactly 8 225 octets longer than its corresponding plaintext. 227 7. IANA Considerations 229 IANA is requested to assign the values for the ciphersuites defined 230 in Section 3 and Section 4 from the TLS and DTLS CipherSuite 231 registries, and the values of the AEAD algorithms defined in 232 Section 6 from the AEAD algorithm registry. IANA, please note that 233 the DTLS-OK column should be marked as "Y" for each of these 234 algorithms. 236 8. Security Considerations 238 8.1. Perfect Forward Secrecy 240 The perfect forward secrecy properties of RSA based TLS ciphersuites 241 are discussed in the security analysis of [RFC5246]. It should be 242 noted that only the ephemeral Diffie-Hellman based ciphersuites are 243 capable of providing perfect forward secrecy. 245 8.2. Counter Reuse 247 AES-CCM security requires that the counter is never reused. The IV 248 construction in Section 3 is designed to prevent counter reuse. 250 9. Acknowledgements 252 This draft borrows heavily from [RFC5288]. 254 10. References 255 10.1. Normative References 257 [AES] National Institute of Standards and Technology, 258 "Specification for the Advanced Encryption Standard 259 (AES)", FIPS 197, November 2001. 261 [CCM] National Institute of Standards and Technology, 262 "Recommendation for Block Cipher Modes of Operation: The 263 CCM Mode for Authentication and Confidentiality", SP 800- 264 38C, May 2004. 266 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 267 Requirement Levels", BCP 14, RFC 2119, March 1997. 269 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 270 Encryption", RFC 5116, January 2008. 272 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 273 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 275 [RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois 276 Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, 277 August 2008. 279 [RFC5487] Badra, M., "Pre-Shared Key Cipher Suites for TLS with SHA- 280 256/384 and AES Galois Counter Mode", RFC 5487, 281 March 2009. 283 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: 284 Extension Definitions", RFC 6066, January 2011. 286 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 287 Security Version 1.2", RFC 6347, January 2012. 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 304 13600 Dulles Technology Drive 305 Herndon, VA 20171 306 USA 308 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