idnits 2.17.1 draft-ietf-tls-rsa-aes-gcm-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 349. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 360. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 367. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 373. 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 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 7, 2008) is 5917 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) -- Looks like a reference, but probably isn't: '4' on line 131 -- Looks like a reference, but probably isn't: '8' on line 132 == Unused Reference: 'AES' is defined on line 269, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'AES' -- Possible downref: Non-RFC (?) normative reference: ref. 'GCM' == Outdated reference: A later version (-10) exists of draft-ietf-tls-rfc4346-bis-08 ** Obsolete normative reference: RFC 4347 (Obsoleted by RFC 6347) == Outdated reference: A later version (-07) exists of draft-ietf-tls-ecc-new-mac-02 Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TLS Working Group J. Salowey 3 Internet-Draft A. Choudhury 4 Intended status: Standards Track D. McGrew 5 Expires: August 10, 2008 Cisco Systems, Inc. 6 February 7, 2008 8 AES-GCM Cipher Suites for TLS 9 draft-ietf-tls-rsa-aes-gcm-02 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on August 10, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 This memo describes the use of the Advanced Encryption Standard (AES) 43 in Galois/Counter Mode (GCM) as a Transport Layer Security (TLS) 44 authenticated encryption operation. GCM provides both 45 confidentiality and data origin authentication, can be efficiently 46 implemented in hardware for speeds of 10 gigabits per second and 47 above, and is also well-suited to software implementations. This 48 memo defines TLS ciphersuites that use AES-GCM with RSA, DSS and 49 Diffie-Hellman based key exchange mechanisms. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Conventions Used In This Document . . . . . . . . . . . . . . . 3 57 3. AES-GCM Cipher Suites . . . . . . . . . . . . . . . . . . . . . 3 59 4. TLS Versions . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 63 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 64 6.1. Counter Reuse . . . . . . . . . . . . . . . . . . . . . . . 5 65 6.2. Recommendations for Multiple Encryption Processors . . . . 5 67 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 69 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 71 8.2. Informative References . . . . . . . . . . . . . . . . . . 7 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 74 Intellectual Property and Copyright Statements . . . . . . . . . . 9 76 1. Introduction 78 This document describes the use of AES [AES]in Galois Counter Mode 79 (GCM) [GCM] (AES-GCM) with various key exchange mechanisms as a 80 ciphersuite for TLS. AES-GCM is not only efficient and secure, but 81 hardware implementations can achieve high speeds with low cost and 82 low latency, because the mode can be pipelined. Applications like 83 CAPWAP, which uses DTLS, can benefit from the high-speed 84 implementations when wireless termination points (WTPs) and 85 controllers (ACs) have to meet requirements to support higher 86 throughputs in the future. AES-GCM has been specified as a mode that 87 can be used with IPsec ESP [RFC4106] and 802.1AE MAC Security 88 [IEEE8021AE]. This document defines ciphersutes based on RSA, DSS 89 and Diffie-Hellman key exchanges; ECC based ciphersuites are defined 90 in a separate document [I-D.ietf-tls-ecc-new-mac]. AES-GCM is an 91 authenticated encryption with associated data (AEAD) cipher, as 92 defined in TLS 1.2 [I-D.ietf-tls-rfc4346-bis]. The ciphersuites 93 defined in this draft may be used with Datagram TLS defined in 94 [RFC4347]. This memo uses GCM in a way similar to 95 [I-D.ietf-tls-ecc-new-mac]. 97 2. Conventions Used In This Document 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 101 document are to be interpreted as described in [RFC2119] 103 3. AES-GCM Cipher Suites 105 The following ciphersuites use the new authenticated encryption modes 106 defined in TLS 1.2 with AES in Galois Counter Mode (GCM) [GCM]: 108 CipherSuite TLS_RSA_WITH_AES_128_GCM_SHA256 = {TBD,TBD} 109 CipherSuite TLS_RSA_WITH_AES_256_GCM_SHA384 = {TBD,TBD} 110 CipherSuite TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 = {TBD,TBD} 111 CipherSuite TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 = {TBD,TBD} 112 CipherSuite TLS_DH_RSA_WITH_AES_128_GCM_SHA256 = {TBD,TBD} 113 CipherSuite TLS_DH_RSA_WITH_AES_256_GCM_SHA384 = {TBD,TBD} 114 CipherSuite TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 = {TBD,TBD} 115 CipherSuite TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 = {TBD,TBD} 116 CipherSuite TLS_DH_DSS_WITH_AES_128_GCM_SHA256 = {TBD,TBD} 117 CipherSuite TLS_DH_DSS_WITH_AES_256_GCM_SHA384 = {TBD,TBD} 118 CipherSuite TLS_DH_anon_WITH_AES_128_GCM_SHA256 = {TBD,TBD} 119 CipherSuite TLS_DH_anon_WITH_AES_256_GCM_SHA384 = {TBD,TBD} 121 These ciphersuites use the AES-GCM authenticated encryption with 122 associated data (AEAD) algorithms AEAD_AES_128_GCM and 123 AEAD_AES_256_GCM described in [RFC5116]. Note that each of these 124 AEAD algorithms uses a 128-bit authentication tag with GCM. The 125 "nonce" SHALL be 12 bytes long and it is "partially implicit" (see 126 section 3.2.1 in [RFC5116]). Part of the nonce is generated as part 127 of the handshake process and is static for the entire session and the 128 other part is carried in each packet. 130 Struct{ 131 opaque salt[4]; 132 opaque explicit_nonce_part[8]; 133 } GCMNonce 135 The salt is the "implicit" part of the nonce and is not sent in the 136 packet. It is either the client_write_IV if the client is sending or 137 the server_write_IV if the server is sending. These IVs SHALL be 4 138 bytes long, therefore, for all the algorithms defined in this 139 section, SecurityParameters.fixed_iv_length=4. 141 The explicit_nonce_part is chosen by the sender and included in the 142 packet. Each value of the explicit_nonce_part MUST be distinct for 143 each distinct invocation of GCM encrypt function for any fixed key. 144 Failure to meet this uniqueness requirement can significantly degrade 145 security. The explicit_nonce_part is carried in the IV field of the 146 GenericAEADCipher structure. For all the algorithms defined in this 147 section, SecurityParameters.record_iv_length=8. 149 In the case of TLS the explicit_nonce_part MAY be the 64-bit sequence 150 number. In the case of Datagram TLS [RFC4347] the 151 explicit_nonce_part MAY be formed from the concatenation of the 16- 152 bit epoch with the 48-bit DTLS seq_num. 154 The RSA, DHE_RSA, DH_RSA, DHE_DSS, DH_DSS, and DH_anon key exchanges 155 are performed as defined in [I-D.ietf-tls-rfc4346-bis]. 157 The PRF algorithms SHALL be as follows: 159 For ciphersuites ending in _SHA256 the hash function is SHA256. 161 For ciphersuites ending in _SHA384 the hash function is SHA384. 163 4. TLS Versions 165 These ciphersuites make use of the authenticated encryption with 166 additional data defined in TLS 1.2 [I-D.ietf-tls-rfc4346-bis]. They 167 MUST NOT be negotiated in older versions of TLS. Clients MUST NOT 168 offer these cipher suites if they do not offer TLS 1.2 or later. 170 Servers which select an earlier version of TLS MUST NOT select one of 171 these cipher suites. Because TLS has no way for the client to 172 indicate that it supports TLS 1.2 but not earlier, a non-compliant 173 server might potentially negotiate TLS 1.1 or earlier and select one 174 of the cipher suites in this document. Clients MUST check the TLS 175 version and generate a fatal "illegal_parameter" alert if they detect 176 an incorrect version. 178 5. IANA Considerations 180 IANA has assigned the following values for the ciphersuites defined 181 in this draft: 183 CipherSuite TLS_RSA_WITH_AES_128_GCM_SHA256 = {TBD,TBD} 184 CipherSuite TLS_RSA_WITH_AES_256_GCM_SHA384 = {TBD,TBD} 185 CipherSuite TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 = {TBD,TBD} 186 CipherSuite TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 = {TBD,TBD} 187 CipherSuite TLS_DH_RSA_WITH_AES_128_GCM_SHA256 = {TBD,TBD} 188 CipherSuite TLS_DH_RSA_WITH_AES_256_GCM_SHA384 = {TBD,TBD} 189 CipherSuite TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 = {TBD,TBD} 190 CipherSuite TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 = {TBD,TBD} 191 CipherSuite TLS_DH_DSS_WITH_AES_128_GCM_SHA256 = {TBD,TBD} 192 CipherSuite TLS_DH_DSS_WITH_AES_256_GCM_SHA384 = {TBD,TBD} 193 CipherSuite TLS_DH_anon_WITH_AES_128_GCM_SHA256 = {TBD,TBD} 194 CipherSuite TLS_DH_anon_WITH_AES_256_GCM_SHA384 = {TBD,TBD} 196 6. Security Considerations 198 The security considerations in [I-D.ietf-tls-rfc4346-bis] apply to 199 this document as well. The remainder of this section describes 200 security considerations specific to the cipher suites described in 201 this document. 203 6.1. Counter Reuse 205 AES-GCM security requires that the counter is never reused. The IV 206 construction in Section 3 is designed to prevent counter reuse. 208 6.2. Recommendations for Multiple Encryption Processors 210 If multiple cryptographic processors are in use by the sender, then 211 the sender MUST ensure that, for a particular key, each value of the 212 explicit_nonce_part used with that key is distinct. In this case 213 each encryption processor SHOULD include in the explicit_nonce_part a 214 fixed value that is distinct for each processor. The recommended 215 format is 216 explicit_nonce_part = FixedDistinct || Variable 218 where the FixedDistinct field is distinct for each encryption 219 processor, but is fixed for a given processor, and the Variable field 220 is distinct for each distinct nonce used by a particular encryption 221 processor. When this method is used, the FixedDistinct fields used 222 by the different processors MUST have the same length. 224 In the terms of Figure 2 in [RFC5116], the Salt is the Fixed-Common 225 part of the nonce (it is fixed, and it is common across all 226 encryption processors), the FixedDistinct field exactly corresponds 227 to the Fixed-Distinct field, and the Variable field corresponds to 228 the Counter field, and the explicit part exactly corresponds to the 229 explicit_nonce_part. 231 For clarity, we provide an example for TLS in which there are two 232 distinct encryption processors, each of which uses a one-byte 233 FixedDistinct field: 235 Salt = eedc68dc 236 FixedDistinct = 01 (for the first encryption processor) 237 FixedDistinct = 02 (for the second encryption processor) 239 The GCMnonces generated by the first encryption processor, and their 240 corresponding explicit_nonce_parts, are: 242 GCMNonce explicit_nonce_part 243 ------------------------ ---------------------------- 244 eedc68dc0100000000000000 0100000000000000 245 eedc68dc0100000000000001 0100000000000001 246 eedc68dc0100000000000002 0100000000000002 247 ... 249 The GCMnonces generated by the second encryption processor, and their 250 corresponding explicit_nonce_parts, are 252 GCMNonce explicit_nonce_part 253 ------------------------ ---------------------------- 254 eedc68dc0200000000000000 0200000000000000 255 eedc68dc0200000000000001 0200000000000001 256 eedc68dc0200000000000002 0200000000000002 257 ... 259 7. Acknowledgements 261 This draft borrows heavily from [I-D.ietf-tls-ecc-new-mac]. The 262 authors would like to thank Alex Lam and Pasi Eronen for providing 263 useful comments during the review of this draft. 265 8. References 267 8.1. Normative References 269 [AES] National Institute of Standards and Technology, 270 "Specification for the Advanced Encryption Standard 271 (AES)", FIPS 197, November 2001. 273 [GCM] National Institute of Standards and Technology, 274 "Recommendation for Block Cipher Modes of Operation: 275 Galois Counter Mode (GCM) for Confidentiality and 276 Authentication", SP 800-38D, April 2006. 278 [I-D.ietf-tls-rfc4346-bis] 279 Dierks, T. and E. Rescorla, "The Transport Layer Security 280 (TLS) Protocol Version 1.2", draft-ietf-tls-rfc4346-bis-08 281 (work in progress), January 2008. 283 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 284 Requirement Levels", BCP 14, RFC 2119, March 1997. 286 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 287 Security", RFC 4347, April 2006. 289 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 290 Encryption", RFC 5116, January 2008. 292 8.2. Informative References 294 [I-D.ietf-tls-ecc-new-mac] 295 Rescorla, E., "TLS Elliptic Curve Cipher Suites with SHA- 296 256/384 and AES Galois Counter Mode", 297 draft-ietf-tls-ecc-new-mac-02 (work in progress), 298 December 2007. 300 [IEEE8021AE] 301 Institute of Electrical and Electronics Engineers, "Media 302 Access Control Security", IEEE Standard 802.1AE, 303 August 2006. 305 [RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode 306 (GCM) in IPsec Encapsulating Security Payload (ESP)", 307 RFC 4106, June 2005. 309 Authors' Addresses 311 Joseph Salowey 312 Cisco Systems, Inc. 313 2901 3rd. Ave 314 Seattle, WA 98121 315 USA 317 Email: jsalowey@cisco.com 319 Abhijit Choudhury 320 Cisco Systems, Inc. 321 3625 Cisco Way 322 San Jose, CA 95134 323 USA 325 Email: abhijitc@cisco.com 327 David McGrew 328 Cisco Systems, Inc. 329 170 W Tasman Drive 330 San Jose, CA 95134 331 USA 333 Email: mcgrew@cisco.com 335 Full Copyright Statement 337 Copyright (C) The IETF Trust (2008). 339 This document is subject to the rights, licenses and restrictions 340 contained in BCP 78, and except as set forth therein, the authors 341 retain all their rights. 343 This document and the information contained herein are provided on an 344 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 345 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 346 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 347 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 348 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 349 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 351 Intellectual Property 353 The IETF takes no position regarding the validity or scope of any 354 Intellectual Property Rights or other rights that might be claimed to 355 pertain to the implementation or use of the technology described in 356 this document or the extent to which any license under such rights 357 might or might not be available; nor does it represent that it has 358 made any independent effort to identify any such rights. Information 359 on the procedures with respect to rights in RFC documents can be 360 found in BCP 78 and BCP 79. 362 Copies of IPR disclosures made to the IETF Secretariat and any 363 assurances of licenses to be made available, or the result of an 364 attempt made to obtain a general license or permission for the use of 365 such proprietary rights by implementers or users of this 366 specification can be obtained from the IETF on-line IPR repository at 367 http://www.ietf.org/ipr. 369 The IETF invites any interested party to bring to its attention any 370 copyrights, patents or patent applications, or other proprietary 371 rights that may cover technology that may be required to implement 372 this standard. Please address the information to the IETF at 373 ietf-ipr@ietf.org. 375 Acknowledgment 377 Funding for the RFC Editor function is provided by the IETF 378 Administrative Support Activity (IASA).