idnits 2.17.1 draft-ietf-tls-rsa-aes-gcm-01.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 352. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 363. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 370. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 376. 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 (January 13, 2008) is 5941 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 126 -- Looks like a reference, but probably isn't: '8' on line 127 == Unused Reference: 'AES' is defined on line 262, but no explicit reference was found in the text == Unused Reference: 'RFC4346' is defined on line 284, 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-07 ** Obsolete normative reference: RFC 4346 (Obsoleted by RFC 5246) ** Obsolete normative reference: RFC 4347 (Obsoleted by RFC 6347) == Outdated reference: A later version (-07) exists of draft-ietf-tls-ecc-new-mac-02 == Outdated reference: A later version (-11) exists of draft-rescorla-tls-suiteb-01 Summary: 3 errors (**), 0 flaws (~~), 7 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: July 16, 2008 Cisco Systems, Inc. 6 January 13, 2008 8 RSA based AES-GCM Cipher Suites for TLS 9 draft-ietf-tls-rsa-aes-gcm-01 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 July 16, 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. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Conventions Used In This Document . . . . . . . . . . . . . . . 3 56 3. RSA Based AES-GCM Cipher Suites . . . . . . . . . . . . . . . . 3 57 3.1. Recommendations for Multiple Cryptographic Processors . . . 4 59 4. TLS Versions . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 63 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 64 6.1. Perfect Forward Secrecy . . . . . . . . . . . . . . . . . . 6 65 6.2. Counter Reuse . . . . . . . . . . . . . . . . . . . . . . . 6 67 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 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 RSA based key exchange as a ciphersuite 80 for TLS. This mechanism is not only efficient and secure, hardware 81 implementations can achieve high speeds with low cost and low 82 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]. It also is part of the NSA suite B ciphersuites for 89 TLS [I-D.rescorla-tls-suiteb]; however in order to meet Suite B 90 requirements these ciphersuites require ECC base key exchange and TLS 91 1.2. The ciphersuites defined in this document are based on RSA 92 which allows the use of AES-GCM in environments that have not 93 deployed ECC algorithms and do not need to meet NSA Suite B 94 requirements. AES-GCM is an authenticated encryption with associated 95 data (AEAD) cipher, as defined in TLS 1.2[I-D.ietf-tls-rfc4346-bis]. 96 The ciphersuites defined in this draft may be used with Datagram TLS 97 defined in [RFC4347]. This memo uses GCM in a way similar to 98 [I-D.ietf-tls-ecc-new-mac]. 100 2. Conventions Used In This Document 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 104 document are to be interpreted as described in [RFC2119] 106 3. RSA Based AES-GCM Cipher Suites 108 The following ciphersuites use the new authenticated encryption modes 109 defined in TLS 1.2 with AES in Galois Counter Mode (GCM) [GCM]: 111 CipherSuite TLS_RSA_WITH_AES_128_GCM_SHA256 = {TBD1,TBD1} 112 CipherSuite TLS_RSA_WITH_AES_256_GCM_SHA384 = {TBD2,TBD2} 113 CipherSuite TLS_RSA_DHE_WITH_AES_128_GCM_SHA256 = {TBD3,TBD3} 114 CipherSuite TLS_RSA_DHE_WITH_AES_256_GCM_SHA384 = {TBD4,TBD4} 116 These ciphersuites use the AES-GCM authenticated encryption with 117 associated data (AEAD) algorithms AEAD_AES_128_GCM and 118 AEAD_AES_256_GCM described in [I-D.mcgrew-auth-enc]. Note that this 119 specification uses a 128-bit authentication tag with GCM. The 120 "nonce" SHALL be 12 bytes long and it is "partially implicit" (see 121 section 3.2.1 in [I-D.mcgrew-auth-enc]). Part of the nonce is 122 generated as part of the handshake process and is static for the 123 entire session and part is carried in each packet. 125 Struct{ 126 opaque salt[4]; 127 opaque explicit_nonce_part[8]; 128 } GCMNonce 130 The salt is the "implicit" part of the nonce and is not sent in the 131 packet. It is either the client_write_IV if the client is sending or 132 the server_write_IV if the server is sending. These IVs SHALL be 4 133 bytes long. 135 The explicit_nonce_part is chosen by the sender and included in the 136 packet. Each value of the explicit_nonce_part MUST be distinct for 137 each distinct invocation of GCM encrypt function for any fixed key. 138 Failure to meet this uniqueness requirement can significantly degrade 139 security. The explicit_nonce_part is carried in the IV field of the 140 GenericAEADCipher structure. Therefore, for all the algorithms 141 defined in this section, SecurityParameters.iv_length=8. 143 In the case of TLS the explicit_nonce_part MAY be the 64-bit sequence 144 number. In the case of Datagram TLS [RFC4347] the 145 explicit_nonce_part MAY be formed from the concatenation of the 16- 146 bit epoch with the 48-bit DTLS seq_num. 148 The RSA and RSA-DHE key exchange is performed as defined in 149 [I-D.ietf-tls-rfc4346-bis]. 151 The PRF algorithms SHALL be as follows: 153 For TLS_RSA_WITH_AES_128_GCM_SHA256 and 154 TLS_RSA_DHE_WITH_AES_128_GCM_SHA256 the hash function is SHA256. 156 For TLS_RSA_WITH_AES_256_GCM_SHA384 and 157 TLS_RSA_DHE_WITH_AES_256_GCM_SHA384 the hash function is SHA384. 159 3.1. Recommendations for Multiple Cryptographic Processors 161 If multiple cryptographic processors are in use by the sender, then 162 the sender MUST ensure that each value of the explicit_nonce_part 163 that is used by each processor is distinct. In this case each 164 encryption processor SHOULD include in the explicit_nonce_part a a 165 fixed value that is distinct for each processor. The recommended 166 format is 168 explicit_nonce_part = FixedDistinct || Variable 170 where the FixedDistinct field is distinct for each encryption 171 processor, but is fixed for a given processor, and the Variable field 172 is distinct for each distinct nonce used by a particular encryption 173 processor. When this method is used, the FixedDistinct fields used 174 by the different processors MUST have the same length. 176 In the terms of Figure 2 in [I-D.mcgrew-auth-enc], the Salt is the 177 Fixed-Common part of the nonce (it is fixed, and it is common across 178 all encryption processors), the FixedDistinct field exactly 179 corresponds to the Fixed-Distinct field, and the Variable field 180 corresponds to the Counter field, and the explicit part exactly 181 corresponds to the explicit_nonce_part. 183 For clarity, we provide an example for TLS in which there are two 184 distinct encryption processors, each of which uses a one-byte 185 FixedDistinct field: 187 Salt = eedc68dc 188 FixedDistinct = 01 (for the first encryption processor) 189 FixedDistinct = 02 (for the second encryption processor) 191 The GCMnonces generated by the first encryption processor, and their 192 corresponding explicit_nonce_parts, are: 194 GCMNonce explicit_nonce_part 195 ------------------------ ---------------------------- 196 eedc68dc0100000000000000 0100000000000000 197 eedc68dc0100000000000001 0100000000000001 198 eedc68dc0100000000000002 0100000000000002 199 ... 201 The GCMnonces generated by the second encryption processor, and their 202 corresponding explicit_nonce_parts, are 204 GCMNonce explicit_nonce_part 205 ------------------------ ---------------------------- 206 eedc68dc0200000000000000 0200000000000000 207 eedc68dc0200000000000001 0200000000000001 208 eedc68dc0200000000000002 0200000000000002 209 ... 211 4. TLS Versions 213 These ciphersuites make use of the authenticated encryption with 214 additional data defined in TLS 1.2 [I-D.ietf-tls-rfc4346-bis]. They 215 MUST NOT be negotiated in older versions of TLS. Clients MUST NOT 216 offer these cipher suites if they do not offer TLS 1.2 or later. 217 Servers which select an earlier version of TLS MUST NOT select one of 218 these cipher suites. Because TLS has no way for the client to 219 indicate that it supports TLS 1.2 but not earlier, a non-compliant 220 server might potentially negotiate TLS 1.1 or earlier and select one 221 of the cipher suites in this document. Clients MUST check the TLS 222 version and generate a fatal "illegal_parameter" alert if they detect 223 an incorrect version. 225 5. IANA Considerations 227 IANA has assigned the following values for the ciphersuites defined 228 in this draft: 230 CipherSuite TLS_RSA_WITH_AES_128_GCM_SHA256 = {TBD1,TBD1} 231 CipherSuite TLS_RSA_WITH_AES_256_GCM_SHA384 = {TBD2,TBD2} 232 CipherSuite TLS_RSA_DHE_WITH_AES_128_GCM_SHA256 = {TBD3,TBD3} 233 CipherSuite TLS_RSA_DHE_WITH_AES_256_GCM_SHA384 = {TBD4,TBD4} 235 6. Security Considerations 237 The security considerations in [I-D.ietf-tls-rfc4346-bis] apply to 238 this document as well. The remainder of this section describes 239 security considerations specific to the cipher suites described in 240 this document. 242 6.1. Perfect Forward Secrecy 244 The perfect forward secrecy properties of RSA based TLS ciphersuites 245 are discussed in the security analysis of [I-D.ietf-tls-rfc4346-bis]. 246 It should be noted that only the ephemeral Diffie-Hellman based 247 ciphersuites (RSA_DHE) are capable of providing perfect forward 248 secrecy. 250 6.2. Counter Reuse 252 AES-GCM security requires that the counter is never reused. The IV 253 construction in Section 3 is designed to prevent counter reuse. 255 7. Acknowledgements 257 This draft borrows heavily from [I-D.ietf-tls-ecc-new-mac]. 259 8. References 260 8.1. Normative References 262 [AES] National Institute of Standards and Technology, 263 "Specification for the Advanced Encryption Standard 264 (AES)", FIPS 197, November 2001. 266 [GCM] National Institute of Standards and Technology, 267 "Recommendation for Block Cipher Modes of Operation: 268 Galois Counter Mode (GCM) for Confidentiality and 269 Authentication", SP 800-38D, April 2006. 271 [I-D.ietf-tls-rfc4346-bis] 272 Dierks, T. and E. Rescorla, "The Transport Layer Security 273 (TLS) Protocol Version 1.2", draft-ietf-tls-rfc4346-bis-07 274 (work in progress), November 2007. 276 [I-D.mcgrew-auth-enc] 277 McGrew, D., "An Interface and Algorithms for Authenticated 278 Encryption", draft-mcgrew-auth-enc-05 (work in progress), 279 November 2007. 281 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 282 Requirement Levels", BCP 14, RFC 2119, March 1997. 284 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 285 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 287 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 288 Security", RFC 4347, April 2006. 290 8.2. Informative References 292 [I-D.ietf-tls-ecc-new-mac] 293 Rescorla, E., "TLS Elliptic Curve Cipher Suites with SHA- 294 256/384 and AES Galois Counter Mode", 295 draft-ietf-tls-ecc-new-mac-02 (work in progress), 296 December 2007. 298 [I-D.rescorla-tls-suiteb] 299 Salter, M. and E. Rescorla, "Suite B Cipher Suites for 300 TLS", draft-rescorla-tls-suiteb-01 (work in progress), 301 June 2007. 303 [IEEE8021AE] 304 Institute of Electrical and Electronics Engineers, "Media 305 Access Control Security", IEEE Standard 802.1AE, 306 August 2006. 308 [RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode 309 (GCM) in IPsec Encapsulating Security Payload (ESP)", 310 RFC 4106, June 2005. 312 Authors' Addresses 314 Joseph Salowey 315 Cisco Systems, Inc. 316 2901 3rd. Ave 317 Seattle, WA 98121 318 USA 320 Email: jsalowey@cisco.com 322 Abhijit Choudhury 323 Cisco Systems, Inc. 324 3625 Cisco Way 325 San Jose, CA 95134 326 USA 328 Email: abhijitc@cisco.com 330 David McGrew 331 Cisco Systems, Inc. 332 170 W Tasman Drive 333 San Jose, CA 95134 334 USA 336 Email: mcgrew@cisco.com 338 Full Copyright Statement 340 Copyright (C) The IETF Trust (2008). 342 This document is subject to the rights, licenses and restrictions 343 contained in BCP 78, and except as set forth therein, the authors 344 retain all their rights. 346 This document and the information contained herein are provided on an 347 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 348 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 349 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 350 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 351 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 352 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 354 Intellectual Property 356 The IETF takes no position regarding the validity or scope of any 357 Intellectual Property Rights or other rights that might be claimed to 358 pertain to the implementation or use of the technology described in 359 this document or the extent to which any license under such rights 360 might or might not be available; nor does it represent that it has 361 made any independent effort to identify any such rights. Information 362 on the procedures with respect to rights in RFC documents can be 363 found in BCP 78 and BCP 79. 365 Copies of IPR disclosures made to the IETF Secretariat and any 366 assurances of licenses to be made available, or the result of an 367 attempt made to obtain a general license or permission for the use of 368 such proprietary rights by implementers or users of this 369 specification can be obtained from the IETF on-line IPR repository at 370 http://www.ietf.org/ipr. 372 The IETF invites any interested party to bring to its attention any 373 copyrights, patents or patent applications, or other proprietary 374 rights that may cover technology that may be required to implement 375 this standard. Please address the information to the IETF at 376 ietf-ipr@ietf.org. 378 Acknowledgment 380 Funding for the RFC Editor function is provided by the IETF 381 Administrative Support Activity (IASA).