idnits 2.17.1 draft-salowey-tls-rsa-aes-gcm-00.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 290. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 301. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 308. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 314. 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 25, 2007) is 6242 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) == Unused Reference: 'AES' is defined on line 198, but no explicit reference was found in the text == Unused Reference: 'RFC2246' is defined on line 243, 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-02 == Outdated reference: A later version (-05) exists of draft-mcgrew-auth-enc-01 ** Obsolete normative reference: RFC 4346 (Obsoleted by RFC 5246) ** Obsolete normative reference: RFC 4347 (Obsoleted by RFC 6347) == Outdated reference: A later version (-11) exists of draft-rescorla-tls-suiteb-00 -- Obsolete informational reference (is this intentional?): RFC 2246 (Obsoleted by RFC 4346) Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 10 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 29, 2007 Cisco Systems, Inc. 6 February 25, 2007 8 RSA based AES-GCM Cipher Suites for TLS 9 draft-salowey-tls-rsa-aes-gcm-00 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 29, 2007. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 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 58 4. TLS Versions . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 62 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 63 6.1. Perfect Forward Secrecy . . . . . . . . . . . . . . . . . . 5 64 6.2. Counter Reuse . . . . . . . . . . . . . . . . . . . . . . . 5 66 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 68 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 8.1. Normative References . . . . . . . . . . . . . . . . . . . 5 70 8.2. Informative References . . . . . . . . . . . . . . . . . . 6 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 73 Intellectual Property and Copyright Statements . . . . . . . . . . 8 75 1. Introduction 77 This document describes the use of AES [AES]in Galois Counter Mode 78 (GCM) [GCM] (AES-GCM) with RSA based key exchange as a ciphersuite 79 for TLS. This mechanism is not only efficient and secure, hardware 80 implementations can achieve high speeds with low cost and low 81 latency, because the mode can be pipelined. Applications like 82 CAPWAP, which uses DTLS, can benefit from the high-speed 83 implementations when wireless termination points (WTPs) and 84 controllers (ACs) have to meet requirements to support higher 85 throughputs in the future. AES-GCM has been specified as a mode that 86 can be used with IPsec ESP [RFC4106] and 802.1AE MAC Security 87 [IEEE8021AE]. It also is part of the NSA suite B ciphersuites for 88 TLS [I-D.rescorla-tls-suiteb]; however in order to meet Suite B 89 requirements these ciphersuites require ECC base key exchange and TLS 90 1.2. The ciphersuites defined in this document are based on RSA 91 which allows the use of AES-GCM in environments that have not 92 deployed ECC algorithms and do not need to meet NSA Suite B 93 requirements. AES-GCM is an authenticated encryption with associated 94 data (AEAD) operation, as used in TLS 1.2[I-D.ietf-tls-rfc4346-bis]. 95 The ciphersuites defined in this draft may be used with DTLS defined 96 in [RFC4347] and [I-D.ietf-tls-ctr]. This memo uses GCM in a way 97 similar to [I-D.rescorla-tls-suiteb]. 99 2. Conventions Used In This Document 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 103 document are to be interpreted as described in [RFC2119] 105 3. RSA Based AES-GCM Cipher Suites 107 The ciphersuites defined in this document are based on the the AES- 108 GCM authenticated encryption with associated data (AEAD) algorithms 109 AEAD_AES_128_GCM and AEAD_AES_256_GCM described in 110 [I-D.mcgrew-auth-enc]. Note that this specification uses a 128-bit 111 authentication tag with GCM. The following ciphersuites are defined: 113 CipherSuite TLS_RSA_WITH_AES_128_GCM_SHA256 = {TBD1,TBD1} 114 CipherSuite TLS_RSA_WITH_AES_256_GCM_SHA384 = {TBD2,TBD2} 115 CipherSuite TLS_RSA_DHE_WITH_AES_128_GCM_SHA256 = {TBD3,TBD3} 116 CipherSuite TLS_RSA_DHE_WITH_AES_256_GCM_SHA384 = {TBD4,TBD4} 118 These ciphersuites make use of the AEAD capability in TLS 1.2 119 [I-D.ietf-tls-rfc4346-bis]. The "nonce" SHALL be 12 bytes long and 120 constructed from a salt and a counter as follows: 122 Struct{ 123 uint32 salt; 124 uint64 counter; 125 } GCMNonce 127 The salt is derived form the TLS key block as follows: 129 struct { 130 case client: 131 uint32 client_write_IV; // low order 32-bits 132 case server: 133 uint32 server_write_IV; // low order 32-bits 134 } salt 136 In the case of TLS the counter is the 64 bit sequence number. In the 137 case of DTLS the counter is formed from the concatenation of the 16- 138 bit epoch with the 48-bit sequence number. 140 The RSA and RSA-DHE key exchange is performed as defined in 141 [I-D.ietf-tls-rfc4346-bis]. 143 Recall that an AEAD operation replaces the use of HMAC as a MAC, but 144 not as a PRF for the purposes of key derivation. Consequently, the 145 hash function for the TLS PRF must be explicitly specified by the 146 ciphersuite. For TLS_RSA_WITH_AES_128_GCM_SHA256 and 147 TLS_RSA_DHE_WITH_AES_128_GCM_SHA256 the hash function is SHA256. For 148 TLS_RSA_WITH_AES_256_GCM_SHA384 and 149 TLS_RSA_DHE_WITH_AES_256_GCM_SHA384 the hash function is SHA384. 151 4. TLS Versions 153 These ciphersuites make use of the authenticated encryption with 154 additional data defined in TLS 1.2 [I-D.ietf-tls-rfc4346-bis]. They 155 MUST NOT be negotiated in older versions of TLS. Clients MUST NOT 156 offer these cipher suites if they do not offer TLS 1.2 or later. 157 Servers which select an earlier version of TLS MUST NOT select one of 158 these cipher suites. Because TLS has no way for the client to 159 indicate that it supports TLS 1.2 but not earlier, a non-compliant 160 server might potentially negotiate TLS 1.1 or earlier and select one 161 of the cipher suites in this document. Clients MUST check the TLS 162 version and generate a fatal "illegal_parameter" alert if they detect 163 an incorrect version. 165 5. IANA Considerations 167 IANA has assigned the following values for the ciphersuites defined 168 in this draft: 170 CipherSuite TLS_RSA_WITH_AES_128_GCM_SHA256 = {TBD1,TBD1} 171 CipherSuite TLS_RSA_WITH_AES_256_GCM_SHA384 = {TBD2,TBD2} 172 CipherSuite TLS_RSA_DHE_WITH_AES_128_GCM_SHA256 = {TBD3,TBD3} 173 CipherSuite TLS_RSA_DHE_WITH_AES_256_GCM_SHA384 = {TBD4,TBD4} 175 6. Security Considerations 177 6.1. Perfect Forward Secrecy 179 The perfect forward secrecy properties of RSA based TLS ciphersuites 180 are discussed in the security analysis of [RFC4346]. It should be 181 noted that only the ephemeral Diffie-Hellman based ciphersuites are 182 capable of providing perfect forward secrecy. 184 6.2. Counter Reuse 186 AES-GCM security requires that the counter is never reused. The IV 187 construction in Section 3 is designed to prevent counter reuse. 189 7. Acknowledgements 191 This draft borrows heavily from [I-D.ietf-tls-ctr] and 192 [I-D.rescorla-tls-suiteb] 194 8. References 196 8.1. Normative References 198 [AES] National Institute of Standards and Technology, 199 "Specification for the Advanced Encryption Standard 200 (AES)", FIPS 197, November 2001. 202 [GCM] National Institute of Standards and Technology, 203 "Recommendation for Block Cipher Modes of Operation: 204 Galois Counter Mode (GCM) for Confidentiality and 205 Authentication", SP 800-38D, April 2006. 207 [I-D.ietf-tls-rfc4346-bis] 208 Dierks, T. and E. Rescorla, "The TLS Protocol Version 209 1.2", draft-ietf-tls-rfc4346-bis-02 (work in progress), 210 October 2006. 212 [I-D.mcgrew-auth-enc] 213 McGrew, D., "An Interface and Algorithms for Authenticated 214 Encryption", draft-mcgrew-auth-enc-01 (work in progress), 215 October 2006. 217 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 218 Requirement Levels", BCP 14, RFC 2119, March 1997. 220 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 221 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 223 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 224 Security", RFC 4347, April 2006. 226 8.2. Informative References 228 [I-D.ietf-tls-ctr] 229 Modadugu, N. and E. Rescorla, "AES Counter Mode Cipher 230 Suites for TLS and DTLS", draft-ietf-tls-ctr-01 (work in 231 progress), June 2006. 233 [I-D.rescorla-tls-suiteb] 234 Salter, M. and E. Rescorla, "SuiteB CipherSuites for TLS", 235 draft-rescorla-tls-suiteb-00 (work in progress), 236 December 2006. 238 [IEEE8021AE] 239 Institute of Electrical and Electronics Engineers, "Media 240 Access Control Security", IEEE Standard 802.1AE, 241 August 2006. 243 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 244 RFC 2246, January 1999. 246 [RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode 247 (GCM) in IPsec Encapsulating Security Payload (ESP)", 248 RFC 4106, June 2005. 250 Authors' Addresses 252 Joseph Salowey 253 Cisco Systems, Inc. 254 2901 3rd. Ave 255 Seattle, WA 98121 256 USA 258 Email: jsalowey@cisco.com 260 Abhijit Choudhury 261 Cisco Systems, Inc. 262 170 W Tasman Drive 263 San Jose, CA 95134 264 USA 266 Email: abhijitc@cisco.com 268 David McGrew 269 Cisco Systems, Inc. 270 170 W Tasman Drive 271 San Jose, CA 95134 272 USA 274 Email: mcgrew@cisco.com 276 Full Copyright Statement 278 Copyright (C) The IETF Trust (2007). 280 This document is subject to the rights, licenses and restrictions 281 contained in BCP 78, and except as set forth therein, the authors 282 retain all their rights. 284 This document and the information contained herein are provided on an 285 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 286 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 287 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 288 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 289 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 290 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 292 Intellectual Property 294 The IETF takes no position regarding the validity or scope of any 295 Intellectual Property Rights or other rights that might be claimed to 296 pertain to the implementation or use of the technology described in 297 this document or the extent to which any license under such rights 298 might or might not be available; nor does it represent that it has 299 made any independent effort to identify any such rights. Information 300 on the procedures with respect to rights in RFC documents can be 301 found in BCP 78 and BCP 79. 303 Copies of IPR disclosures made to the IETF Secretariat and any 304 assurances of licenses to be made available, or the result of an 305 attempt made to obtain a general license or permission for the use of 306 such proprietary rights by implementers or users of this 307 specification can be obtained from the IETF on-line IPR repository at 308 http://www.ietf.org/ipr. 310 The IETF invites any interested party to bring to its attention any 311 copyrights, patents or patent applications, or other proprietary 312 rights that may cover technology that may be required to implement 313 this standard. Please address the information to the IETF at 314 ietf-ipr@ietf.org. 316 Acknowledgment 318 Funding for the RFC Editor function is provided by the IETF 319 Administrative Support Activity (IASA).