| blob | 671bf846b271d595e68d40fd308a21c425b05791 |
1 \r
2 \r
3 \r
4 TLS Working Group J. Salowey\r
5 Internet-Draft A. Choudhury\r
6 Intended status: Standards Track D. McGrew\r
7 Expires: August 10, 2008 Cisco Systems, Inc.\r
8 February 7, 2008\r
9 \r
10 \r
11 AES-GCM Cipher Suites for TLS\r
12 draft-ietf-tls-rsa-aes-gcm-02\r
13 \r
14 Status of this Memo\r
15 \r
16 By submitting this Internet-Draft, each author represents that any\r
17 applicable patent or other IPR claims of which he or she is aware\r
18 have been or will be disclosed, and any of which he or she becomes\r
19 aware will be disclosed, in accordance with Section 6 of BCP 79.\r
20 \r
21 Internet-Drafts are working documents of the Internet Engineering\r
22 Task Force (IETF), its areas, and its working groups. Note that\r
23 other groups may also distribute working documents as Internet-\r
24 Drafts.\r
25 \r
26 Internet-Drafts are draft documents valid for a maximum of six months\r
27 and may be updated, replaced, or obsoleted by other documents at any\r
28 time. It is inappropriate to use Internet-Drafts as reference\r
29 material or to cite them other than as "work in progress."\r
30 \r
31 The list of current Internet-Drafts can be accessed at\r
32 http://www.ietf.org/ietf/1id-abstracts.txt.\r
33 \r
34 The list of Internet-Draft Shadow Directories can be accessed at\r
35 http://www.ietf.org/shadow.html.\r
36 \r
37 This Internet-Draft will expire on August 10, 2008.\r
38 \r
39 Copyright Notice\r
40 \r
41 Copyright (C) The IETF Trust (2008).\r
42 \r
43 Abstract\r
44 \r
45 This memo describes the use of the Advanced Encryption Standard (AES)\r
46 in Galois/Counter Mode (GCM) as a Transport Layer Security (TLS)\r
47 authenticated encryption operation. GCM provides both\r
48 confidentiality and data origin authentication, can be efficiently\r
49 implemented in hardware for speeds of 10 gigabits per second and\r
50 above, and is also well-suited to software implementations. This\r
51 memo defines TLS ciphersuites that use AES-GCM with RSA, DSS and\r
52 \r
53 \r
54 \r
55 Salowey, et al. Expires August 10, 2008 [Page 1]\r
57 Internet-Draft AES-GCM Ciphersuites February 2008\r
58 \r
59 \r
60 Diffie-Hellman based key exchange mechanisms.\r
61 \r
62 \r
63 Table of Contents\r
64 \r
65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3\r
66 \r
67 2. Conventions Used In This Document . . . . . . . . . . . . . . . 3\r
68 \r
69 3. AES-GCM Cipher Suites . . . . . . . . . . . . . . . . . . . . . 3\r
70 \r
71 4. TLS Versions . . . . . . . . . . . . . . . . . . . . . . . . . 4\r
72 \r
73 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5\r
74 \r
75 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5\r
76 6.1. Counter Reuse . . . . . . . . . . . . . . . . . . . . . . . 5\r
77 6.2. Recommendations for Multiple Encryption Processors . . . . 5\r
78 \r
79 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7\r
80 \r
81 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7\r
82 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7\r
83 8.2. Informative References . . . . . . . . . . . . . . . . . . 7\r
84 \r
85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8\r
86 Intellectual Property and Copyright Statements . . . . . . . . . . 9\r
87 \r
88 \r
89 \r
90 \r
91 \r
92 \r
93 \r
94 \r
95 \r
96 \r
97 \r
98 \r
99 \r
100 \r
101 \r
102 \r
103 \r
104 \r
105 \r
106 \r
107 \r
108 \r
109 \r
110 \r
111 Salowey, et al. Expires August 10, 2008 [Page 2]\r
113 Internet-Draft AES-GCM Ciphersuites February 2008\r
114 \r
115 \r
116 1. Introduction\r
117 \r
118 This document describes the use of AES [AES]in Galois Counter Mode\r
119 (GCM) [GCM] (AES-GCM) with various key exchange mechanisms as a\r
120 ciphersuite for TLS. AES-GCM is not only efficient and secure, but\r
121 hardware implementations can achieve high speeds with low cost and\r
122 low latency, because the mode can be pipelined. Applications like\r
123 CAPWAP, which uses DTLS, can benefit from the high-speed\r
124 implementations when wireless termination points (WTPs) and\r
125 controllers (ACs) have to meet requirements to support higher\r
126 throughputs in the future. AES-GCM has been specified as a mode that\r
127 can be used with IPsec ESP [RFC4106] and 802.1AE MAC Security\r
128 [IEEE8021AE]. This document defines ciphersutes based on RSA, DSS\r
129 and Diffie-Hellman key exchanges; ECC based ciphersuites are defined\r
130 in a separate document [I-D.ietf-tls-ecc-new-mac]. AES-GCM is an\r
131 authenticated encryption with associated data (AEAD) cipher, as\r
132 defined in TLS 1.2 [I-D.ietf-tls-rfc4346-bis]. The ciphersuites\r
133 defined in this draft may be used with Datagram TLS defined in\r
134 [RFC4347]. This memo uses GCM in a way similar to\r
135 [I-D.ietf-tls-ecc-new-mac].\r
136 \r
137 \r
138 2. Conventions Used In This Document\r
139 \r
140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",\r
141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this\r
142 document are to be interpreted as described in [RFC2119]\r
143 \r
144 \r
145 3. AES-GCM Cipher Suites\r
146 \r
147 The following ciphersuites use the new authenticated encryption modes\r
148 defined in TLS 1.2 with AES in Galois Counter Mode (GCM) [GCM]:\r
149 \r
150 CipherSuite TLS_RSA_WITH_AES_128_GCM_SHA256 = {TBD,TBD}\r
151 CipherSuite TLS_RSA_WITH_AES_256_GCM_SHA384 = {TBD,TBD}\r
152 CipherSuite TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 = {TBD,TBD}\r
153 CipherSuite TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 = {TBD,TBD}\r
154 CipherSuite TLS_DH_RSA_WITH_AES_128_GCM_SHA256 = {TBD,TBD}\r
155 CipherSuite TLS_DH_RSA_WITH_AES_256_GCM_SHA384 = {TBD,TBD}\r
156 CipherSuite TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 = {TBD,TBD}\r
157 CipherSuite TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 = {TBD,TBD}\r
158 CipherSuite TLS_DH_DSS_WITH_AES_128_GCM_SHA256 = {TBD,TBD}\r
159 CipherSuite TLS_DH_DSS_WITH_AES_256_GCM_SHA384 = {TBD,TBD}\r
160 CipherSuite TLS_DH_anon_WITH_AES_128_GCM_SHA256 = {TBD,TBD}\r
161 CipherSuite TLS_DH_anon_WITH_AES_256_GCM_SHA384 = {TBD,TBD}\r
162 \r
163 These ciphersuites use the AES-GCM authenticated encryption with\r
164 \r
165 \r
166 \r
167 Salowey, et al. Expires August 10, 2008 [Page 3]\r
169 Internet-Draft AES-GCM Ciphersuites February 2008\r
170 \r
171 \r
172 associated data (AEAD) algorithms AEAD_AES_128_GCM and\r
173 AEAD_AES_256_GCM described in [RFC5116]. Note that each of these\r
174 AEAD algorithms uses a 128-bit authentication tag with GCM. The\r
175 "nonce" SHALL be 12 bytes long and it is "partially implicit" (see\r
176 section 3.2.1 in [RFC5116]). Part of the nonce is generated as part\r
177 of the handshake process and is static for the entire session and the\r
178 other part is carried in each packet.\r
179 \r
180 Struct{\r
181 opaque salt[4];\r
182 opaque explicit_nonce_part[8];\r
183 } GCMNonce\r
184 \r
185 The salt is the "implicit" part of the nonce and is not sent in the\r
186 packet. It is either the client_write_IV if the client is sending or\r
187 the server_write_IV if the server is sending. These IVs SHALL be 4\r
188 bytes long, therefore, for all the algorithms defined in this\r
189 section, SecurityParameters.fixed_iv_length=4.\r
190 \r
191 The explicit_nonce_part is chosen by the sender and included in the\r
192 packet. Each value of the explicit_nonce_part MUST be distinct for\r
193 each distinct invocation of GCM encrypt function for any fixed key.\r
194 Failure to meet this uniqueness requirement can significantly degrade\r
195 security. The explicit_nonce_part is carried in the IV field of the\r
196 GenericAEADCipher structure. For all the algorithms defined in this\r
197 section, SecurityParameters.record_iv_length=8.\r
198 \r
199 In the case of TLS the explicit_nonce_part MAY be the 64-bit sequence\r
200 number. In the case of Datagram TLS [RFC4347] the\r
201 explicit_nonce_part MAY be formed from the concatenation of the 16-\r
202 bit epoch with the 48-bit DTLS seq_num.\r
203 \r
204 The RSA, DHE_RSA, DH_RSA, DHE_DSS, DH_DSS, and DH_anon key exchanges\r
205 are performed as defined in [I-D.ietf-tls-rfc4346-bis].\r
206 \r
207 The PRF algorithms SHALL be as follows:\r
208 \r
209 For ciphersuites ending in _SHA256 the hash function is SHA256.\r
210 \r
211 For ciphersuites ending in _SHA384 the hash function is SHA384.\r
212 \r
213 \r
214 4. TLS Versions\r
215 \r
216 These ciphersuites make use of the authenticated encryption with\r
217 additional data defined in TLS 1.2 [I-D.ietf-tls-rfc4346-bis]. They\r
218 MUST NOT be negotiated in older versions of TLS. Clients MUST NOT\r
219 offer these cipher suites if they do not offer TLS 1.2 or later.\r
220 \r
221 \r
222 \r
223 Salowey, et al. Expires August 10, 2008 [Page 4]\r
225 Internet-Draft AES-GCM Ciphersuites February 2008\r
226 \r
227 \r
228 Servers which select an earlier version of TLS MUST NOT select one of\r
229 these cipher suites. Because TLS has no way for the client to\r
230 indicate that it supports TLS 1.2 but not earlier, a non-compliant\r
231 server might potentially negotiate TLS 1.1 or earlier and select one\r
232 of the cipher suites in this document. Clients MUST check the TLS\r
233 version and generate a fatal "illegal_parameter" alert if they detect\r
234 an incorrect version.\r
235 \r
236 \r
237 5. IANA Considerations\r
238 \r
239 IANA has assigned the following values for the ciphersuites defined\r
240 in this draft:\r
241 \r
242 CipherSuite TLS_RSA_WITH_AES_128_GCM_SHA256 = {TBD,TBD}\r
243 CipherSuite TLS_RSA_WITH_AES_256_GCM_SHA384 = {TBD,TBD}\r
244 CipherSuite TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 = {TBD,TBD}\r
245 CipherSuite TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 = {TBD,TBD}\r
246 CipherSuite TLS_DH_RSA_WITH_AES_128_GCM_SHA256 = {TBD,TBD}\r
247 CipherSuite TLS_DH_RSA_WITH_AES_256_GCM_SHA384 = {TBD,TBD}\r
248 CipherSuite TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 = {TBD,TBD}\r
249 CipherSuite TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 = {TBD,TBD}\r
250 CipherSuite TLS_DH_DSS_WITH_AES_128_GCM_SHA256 = {TBD,TBD}\r
251 CipherSuite TLS_DH_DSS_WITH_AES_256_GCM_SHA384 = {TBD,TBD}\r
252 CipherSuite TLS_DH_anon_WITH_AES_128_GCM_SHA256 = {TBD,TBD}\r
253 CipherSuite TLS_DH_anon_WITH_AES_256_GCM_SHA384 = {TBD,TBD}\r
254 \r
255 \r
256 6. Security Considerations\r
257 \r
258 The security considerations in [I-D.ietf-tls-rfc4346-bis] apply to\r
259 this document as well. The remainder of this section describes\r
260 security considerations specific to the cipher suites described in\r
261 this document.\r
262 \r
263 6.1. Counter Reuse\r
264 \r
265 AES-GCM security requires that the counter is never reused. The IV\r
266 construction in Section 3 is designed to prevent counter reuse.\r
267 \r
268 6.2. Recommendations for Multiple Encryption Processors\r
269 \r
270 If multiple cryptographic processors are in use by the sender, then\r
271 the sender MUST ensure that, for a particular key, each value of the\r
272 explicit_nonce_part used with that key is distinct. In this case\r
273 each encryption processor SHOULD include in the explicit_nonce_part a\r
274 fixed value that is distinct for each processor. The recommended\r
275 format is\r
276 \r
277 \r
278 \r
279 Salowey, et al. Expires August 10, 2008 [Page 5]\r
281 Internet-Draft AES-GCM Ciphersuites February 2008\r
282 \r
283 \r
284 explicit_nonce_part = FixedDistinct || Variable\r
285 \r
286 where the FixedDistinct field is distinct for each encryption\r
287 processor, but is fixed for a given processor, and the Variable field\r
288 is distinct for each distinct nonce used by a particular encryption\r
289 processor. When this method is used, the FixedDistinct fields used\r
290 by the different processors MUST have the same length.\r
291 \r
292 In the terms of Figure 2 in [RFC5116], the Salt is the Fixed-Common\r
293 part of the nonce (it is fixed, and it is common across all\r
294 encryption processors), the FixedDistinct field exactly corresponds\r
295 to the Fixed-Distinct field, and the Variable field corresponds to\r
296 the Counter field, and the explicit part exactly corresponds to the\r
297 explicit_nonce_part.\r
298 \r
299 For clarity, we provide an example for TLS in which there are two\r
300 distinct encryption processors, each of which uses a one-byte\r
301 FixedDistinct field:\r
302 \r
303 Salt = eedc68dc\r
304 FixedDistinct = 01 (for the first encryption processor)\r
305 FixedDistinct = 02 (for the second encryption processor)\r
306 \r
307 The GCMnonces generated by the first encryption processor, and their\r
308 corresponding explicit_nonce_parts, are:\r
309 \r
310 GCMNonce explicit_nonce_part\r
311 ------------------------ ----------------------------\r
312 eedc68dc0100000000000000 0100000000000000\r
313 eedc68dc0100000000000001 0100000000000001\r
314 eedc68dc0100000000000002 0100000000000002\r
315 ...\r
316 \r
317 The GCMnonces generated by the second encryption processor, and their\r
318 corresponding explicit_nonce_parts, are\r
319 \r
320 GCMNonce explicit_nonce_part\r
321 ------------------------ ----------------------------\r
322 eedc68dc0200000000000000 0200000000000000\r
323 eedc68dc0200000000000001 0200000000000001\r
324 eedc68dc0200000000000002 0200000000000002\r
325 ...\r
326 \r
327 \r
328 \r
329 \r
330 \r
331 \r
332 \r
333 \r
334 \r
335 Salowey, et al. Expires August 10, 2008 [Page 6]\r
337 Internet-Draft AES-GCM Ciphersuites February 2008\r
338 \r
339 \r
340 7. Acknowledgements\r
341 \r
342 This draft borrows heavily from [I-D.ietf-tls-ecc-new-mac]. The\r
343 authors would like to thank Alex Lam and Pasi Eronen for providing\r
344 useful comments during the review of this draft.\r
345 \r
346 \r
347 8. References\r
348 \r
349 8.1. Normative References\r
350 \r
351 [AES] National Institute of Standards and Technology,\r
352 "Specification for the Advanced Encryption Standard\r
353 (AES)", FIPS 197, November 2001.\r
354 \r
355 [GCM] National Institute of Standards and Technology,\r
356 "Recommendation for Block Cipher Modes of Operation:\r
357 Galois Counter Mode (GCM) for Confidentiality and\r
358 Authentication", SP 800-38D, April 2006.\r
359 \r
360 [I-D.ietf-tls-rfc4346-bis]\r
361 Dierks, T. and E. Rescorla, "The Transport Layer Security\r
362 (TLS) Protocol Version 1.2", draft-ietf-tls-rfc4346-bis-08\r
363 (work in progress), January 2008.\r
364 \r
365 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate\r
366 Requirement Levels", BCP 14, RFC 2119, March 1997.\r
367 \r
368 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer\r
369 Security", RFC 4347, April 2006.\r
370 \r
371 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated\r
372 Encryption", RFC 5116, January 2008.\r
373 \r
374 8.2. Informative References\r
375 \r
376 [I-D.ietf-tls-ecc-new-mac]\r
377 Rescorla, E., "TLS Elliptic Curve Cipher Suites with SHA-\r
378 256/384 and AES Galois Counter Mode",\r
379 draft-ietf-tls-ecc-new-mac-02 (work in progress),\r
380 December 2007.\r
381 \r
382 [IEEE8021AE]\r
383 Institute of Electrical and Electronics Engineers, "Media\r
384 Access Control Security", IEEE Standard 802.1AE,\r
385 August 2006.\r
386 \r
387 [RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode\r
388 \r
389 \r
390 \r
391 Salowey, et al. Expires August 10, 2008 [Page 7]\r
393 Internet-Draft AES-GCM Ciphersuites February 2008\r
394 \r
395 \r
396 (GCM) in IPsec Encapsulating Security Payload (ESP)",\r
397 RFC 4106, June 2005.\r
398 \r
399 \r
400 Authors' Addresses\r
401 \r
402 Joseph Salowey\r
403 Cisco Systems, Inc.\r
404 2901 3rd. Ave\r
405 Seattle, WA 98121\r
406 USA\r
407 \r
408 Email: jsalowey@cisco.com\r
409 \r
410 \r
411 Abhijit Choudhury\r
412 Cisco Systems, Inc.\r
413 3625 Cisco Way\r
414 San Jose, CA 95134\r
415 USA\r
416 \r
417 Email: abhijitc@cisco.com\r
418 \r
419 \r
420 David McGrew\r
421 Cisco Systems, Inc.\r
422 170 W Tasman Drive\r
423 San Jose, CA 95134\r
424 USA\r
425 \r
426 Email: mcgrew@cisco.com\r
427 \r
428 \r
429 \r
430 \r
431 \r
432 \r
433 \r
434 \r
435 \r
436 \r
437 \r
438 \r
439 \r
440 \r
441 \r
442 \r
443 \r
444 \r
445 \r
446 \r
447 Salowey, et al. Expires August 10, 2008 [Page 8]\r
449 Internet-Draft AES-GCM Ciphersuites February 2008\r
450 \r
451 \r
452 Full Copyright Statement\r
453 \r
454 Copyright (C) The IETF Trust (2008).\r
455 \r
456 This document is subject to the rights, licenses and restrictions\r
457 contained in BCP 78, and except as set forth therein, the authors\r
458 retain all their rights.\r
459 \r
460 This document and the information contained herein are provided on an\r
461 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS\r
462 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND\r
463 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS\r
464 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF\r
465 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED\r
466 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.\r
467 \r
468 \r
469 Intellectual Property\r
470 \r
471 The IETF takes no position regarding the validity or scope of any\r
472 Intellectual Property Rights or other rights that might be claimed to\r
473 pertain to the implementation or use of the technology described in\r
474 this document or the extent to which any license under such rights\r
475 might or might not be available; nor does it represent that it has\r
476 made any independent effort to identify any such rights. Information\r
477 on the procedures with respect to rights in RFC documents can be\r
478 found in BCP 78 and BCP 79.\r
479 \r
480 Copies of IPR disclosures made to the IETF Secretariat and any\r
481 assurances of licenses to be made available, or the result of an\r
482 attempt made to obtain a general license or permission for the use of\r
483 such proprietary rights by implementers or users of this\r
484 specification can be obtained from the IETF on-line IPR repository at\r
485 http://www.ietf.org/ipr.\r
486 \r
487 The IETF invites any interested party to bring to its attention any\r
488 copyrights, patents or patent applications, or other proprietary\r
489 rights that may cover technology that may be required to implement\r
490 this standard. Please address the information to the IETF at\r
491 ietf-ipr@ietf.org.\r
492 \r
493 \r
494 Acknowledgment\r
495 \r
496 Funding for the RFC Editor function is provided by the IETF\r
497 Administrative Support Activity (IASA).\r
498 \r
499 \r
500 \r
501 \r
502 \r
503 Salowey, et al. Expires August 10, 2008 [Page 9]\r