the new makeinfo sets the FLOAT_NAME by default.
[gnutls.git] / doc / protocol / draft-salowey-tls-rsa-aes-gcm-00.txt
blob7acd83e1d6a2ce0debf8f75ea4b225b23da389b8
4 TLS Working Group                                             J. Salowey
5 Internet-Draft                                              A. Choudhury
6 Intended status: Standards Track                               D. McGrew
7 Expires: August 29, 2007                             Cisco Systems, Inc.
8                                                        February 25, 2007
11                 RSA based AES-GCM Cipher Suites for TLS
12                     draft-salowey-tls-rsa-aes-gcm-00
14 Status of this Memo
16    By submitting this Internet-Draft, each author represents that any
17    applicable patent or other IPR claims of which he or she is aware
18    have been or will be disclosed, and any of which he or she becomes
19    aware will be disclosed, in accordance with Section 6 of BCP 79.
21    Internet-Drafts are working documents of the Internet Engineering
22    Task Force (IETF), its areas, and its working groups.  Note that
23    other groups may also distribute working documents as Internet-
24    Drafts.
26    Internet-Drafts are draft documents valid for a maximum of six months
27    and may be updated, replaced, or obsoleted by other documents at any
28    time.  It is inappropriate to use Internet-Drafts as reference
29    material or to cite them other than as "work in progress."
31    The list of current Internet-Drafts can be accessed at
32    http://www.ietf.org/ietf/1id-abstracts.txt.
34    The list of Internet-Draft Shadow Directories can be accessed at
35    http://www.ietf.org/shadow.html.
37    This Internet-Draft will expire on August 29, 2007.
39 Copyright Notice
41    Copyright (C) The IETF Trust (2007).
43 Abstract
45    This memo describes the use of the Advanced Encryption Standard (AES)
46    in Galois/Counter Mode (GCM) as a Transport Layer Security (TLS)
47    authenticated encryption operation.  GCM provides both
48    confidentiality and data origin authentication, can be efficiently
49    implemented in hardware for speeds of 10 gigabits per second and
50    above, and is also well-suited to software implementations.  This
51    memo defines TLS ciphersuites that use AES-GCM with RSA.
55 Salowey, et al.          Expires August 29, 2007                [Page 1]
57 Internet-Draft          RSA AES-GCM Ciphersuites           February 2007
60 Table of Contents
62    1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
64    2.  Conventions Used In This Document . . . . . . . . . . . . . . . 3
66    3.  RSA Based AES-GCM Cipher Suites . . . . . . . . . . . . . . . . 3
68    4.  TLS Versions  . . . . . . . . . . . . . . . . . . . . . . . . . 4
70    5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
72    6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
73      6.1.  Perfect Forward Secrecy . . . . . . . . . . . . . . . . . . 5
74      6.2.  Counter Reuse . . . . . . . . . . . . . . . . . . . . . . . 5
76    7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 5
78    8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 5
79      8.1.  Normative References  . . . . . . . . . . . . . . . . . . . 5
80      8.2.  Informative References  . . . . . . . . . . . . . . . . . . 6
82    Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 6
83    Intellectual Property and Copyright Statements  . . . . . . . . . . 8
111 Salowey, et al.          Expires August 29, 2007                [Page 2]
113 Internet-Draft          RSA AES-GCM Ciphersuites           February 2007
116 1.  Introduction
118    This document describes the use of AES [AES]in Galois Counter Mode
119    (GCM) [GCM] (AES-GCM) with RSA based key exchange as a ciphersuite
120    for TLS.  This mechanism is not only efficient and secure, hardware
121    implementations can achieve high speeds with low cost and low
122    latency, because the mode can be pipelined.  Applications like
123    CAPWAP, which uses DTLS, can benefit from the high-speed
124    implementations when wireless termination points (WTPs) and
125    controllers (ACs) have to meet requirements to support higher
126    throughputs in the future.  AES-GCM has been specified as a mode that
127    can be used with IPsec ESP [RFC4106] and 802.1AE MAC Security
128    [IEEE8021AE].  It also is part of the NSA suite B ciphersuites for
129    TLS [I-D.rescorla-tls-suiteb]; however in order to meet Suite B
130    requirements these ciphersuites require ECC base key exchange and TLS
131    1.2.  The ciphersuites defined in this document are based on RSA
132    which allows the use of AES-GCM in environments that have not
133    deployed ECC algorithms and do not need to meet NSA Suite B
134    requirements.  AES-GCM is an authenticated encryption with associated
135    data (AEAD) operation, as used in TLS 1.2[I-D.ietf-tls-rfc4346-bis].
136    The ciphersuites defined in this draft may be used with DTLS defined
137    in [RFC4347] and [I-D.ietf-tls-ctr].  This memo uses GCM in a way
138    similar to [I-D.rescorla-tls-suiteb].
141 2.  Conventions Used In This Document
143    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
144    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
145    document are to be interpreted as described in [RFC2119]
148 3.  RSA Based AES-GCM Cipher Suites
150    The ciphersuites defined in this document are based on the the AES-
151    GCM authenticated encryption with associated data (AEAD) algorithms
152    AEAD_AES_128_GCM and AEAD_AES_256_GCM described in
153    [I-D.mcgrew-auth-enc].  Note that this specification uses a 128-bit
154    authentication tag with GCM.  The following ciphersuites are defined:
156       CipherSuite TLS_RSA_WITH_AES_128_GCM_SHA256 = {TBD1,TBD1}
157       CipherSuite TLS_RSA_WITH_AES_256_GCM_SHA384 = {TBD2,TBD2}
158       CipherSuite TLS_RSA_DHE_WITH_AES_128_GCM_SHA256 = {TBD3,TBD3}
159       CipherSuite TLS_RSA_DHE_WITH_AES_256_GCM_SHA384 = {TBD4,TBD4}
161    These ciphersuites make use of the AEAD capability in TLS 1.2
162    [I-D.ietf-tls-rfc4346-bis].  The "nonce" SHALL be 12 bytes long and
163    constructed from a salt and a counter as follows:
167 Salowey, et al.          Expires August 29, 2007                [Page 3]
169 Internet-Draft          RSA AES-GCM Ciphersuites           February 2007
172              Struct{
173                 uint32 salt;
174                 uint64 counter;
175              } GCMNonce
177    The salt is derived form the TLS key block as follows:
179             struct {
180                case client:
181                   uint32 client_write_IV;  // low order 32-bits
182                case server:
183                   uint32 server_write_IV;  // low order 32-bits
184             } salt
187    In the case of TLS the counter is the 64 bit sequence number.  In the
188    case of DTLS the counter is formed from the concatenation of the 16-
189    bit epoch with the 48-bit sequence number.
191    The RSA and RSA-DHE key exchange is performed as defined in
192    [I-D.ietf-tls-rfc4346-bis].
194    Recall that an AEAD operation replaces the use of HMAC as a MAC, but
195    not as a PRF for the purposes of key derivation.  Consequently, the
196    hash function for the TLS PRF must be explicitly specified by the
197    ciphersuite.  For TLS_RSA_WITH_AES_128_GCM_SHA256 and
198    TLS_RSA_DHE_WITH_AES_128_GCM_SHA256 the hash function is SHA256.  For
199    TLS_RSA_WITH_AES_256_GCM_SHA384 and
200    TLS_RSA_DHE_WITH_AES_256_GCM_SHA384 the hash function is SHA384.
203 4.  TLS Versions
205    These ciphersuites make use of the authenticated encryption with
206    additional data defined in TLS 1.2 [I-D.ietf-tls-rfc4346-bis].  They
207    MUST NOT be negotiated in older versions of TLS.  Clients MUST NOT
208    offer these cipher suites if they do not offer TLS 1.2 or later.
209    Servers which select an earlier version of TLS MUST NOT select one of
210    these cipher suites.  Because TLS has no way for the client to
211    indicate that it supports TLS 1.2 but not earlier, a non-compliant
212    server might potentially negotiate TLS 1.1 or earlier and select one
213    of the cipher suites in this document.  Clients MUST check the TLS
214    version and generate a fatal "illegal_parameter" alert if they detect
215    an incorrect version.
223 Salowey, et al.          Expires August 29, 2007                [Page 4]
225 Internet-Draft          RSA AES-GCM Ciphersuites           February 2007
228 5.  IANA Considerations
230    IANA has assigned the following values for the ciphersuites defined
231    in this draft:
233       CipherSuite TLS_RSA_WITH_AES_128_GCM_SHA256 = {TBD1,TBD1}
234       CipherSuite TLS_RSA_WITH_AES_256_GCM_SHA384 = {TBD2,TBD2}
235       CipherSuite TLS_RSA_DHE_WITH_AES_128_GCM_SHA256 = {TBD3,TBD3}
236       CipherSuite TLS_RSA_DHE_WITH_AES_256_GCM_SHA384 = {TBD4,TBD4}
239 6.  Security Considerations
241 6.1.  Perfect Forward Secrecy
243    The perfect forward secrecy properties of RSA based TLS ciphersuites
244    are discussed in the security analysis of [RFC4346].  It should be
245    noted that only the ephemeral Diffie-Hellman based ciphersuites are
246    capable of providing perfect forward secrecy.
248 6.2.  Counter Reuse
250    AES-GCM security requires that the counter is never reused.  The IV
251    construction in Section 3 is designed to prevent counter reuse.
254 7.  Acknowledgements
256    This draft borrows heavily from [I-D.ietf-tls-ctr] and
257    [I-D.rescorla-tls-suiteb]
260 8.  References
262 8.1.  Normative References
264    [AES]      National Institute of Standards and Technology,
265               "Specification for the Advanced Encryption Standard
266               (AES)", FIPS 197, November 2001.
268    [GCM]      National Institute of Standards and Technology,
269               "Recommendation for Block Cipher Modes of Operation:
270               Galois Counter Mode (GCM) for Confidentiality and
271               Authentication", SP 800-38D, April 2006.
273    [I-D.ietf-tls-rfc4346-bis]
274               Dierks, T. and E. Rescorla, "The TLS Protocol Version
275               1.2", draft-ietf-tls-rfc4346-bis-02 (work in progress),
279 Salowey, et al.          Expires August 29, 2007                [Page 5]
281 Internet-Draft          RSA AES-GCM Ciphersuites           February 2007
284               October 2006.
286    [I-D.mcgrew-auth-enc]
287               McGrew, D., "An Interface and Algorithms for Authenticated
288               Encryption", draft-mcgrew-auth-enc-01 (work in progress),
289               October 2006.
291    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
292               Requirement Levels", BCP 14, RFC 2119, March 1997.
294    [RFC4346]  Dierks, T. and E. Rescorla, "The Transport Layer Security
295               (TLS) Protocol Version 1.1", RFC 4346, April 2006.
297    [RFC4347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
298               Security", RFC 4347, April 2006.
300 8.2.  Informative References
302    [I-D.ietf-tls-ctr]
303               Modadugu, N. and E. Rescorla, "AES Counter Mode Cipher
304               Suites for TLS and DTLS", draft-ietf-tls-ctr-01 (work in
305               progress), June 2006.
307    [I-D.rescorla-tls-suiteb]
308               Salter, M. and E. Rescorla, "SuiteB CipherSuites for TLS",
309               draft-rescorla-tls-suiteb-00 (work in progress),
310               December 2006.
312    [IEEE8021AE]
313               Institute of Electrical and Electronics Engineers, "Media
314               Access Control Security", IEEE Standard 802.1AE,
315               August 2006.
317    [RFC2246]  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
318               RFC 2246, January 1999.
320    [RFC4106]  Viega, J. and D. McGrew, "The Use of Galois/Counter Mode
321               (GCM) in IPsec Encapsulating Security Payload (ESP)",
322               RFC 4106, June 2005.
335 Salowey, et al.          Expires August 29, 2007                [Page 6]
337 Internet-Draft          RSA AES-GCM Ciphersuites           February 2007
340 Authors' Addresses
342    Joseph Salowey
343    Cisco Systems, Inc.
344    2901 3rd. Ave
345    Seattle, WA  98121
346    USA
348    Email: jsalowey@cisco.com
351    Abhijit Choudhury
352    Cisco Systems, Inc.
353    170 W Tasman Drive
354    San Jose, CA  95134
355    USA
357    Email: abhijitc@cisco.com
360    David McGrew
361    Cisco Systems, Inc.
362    170 W Tasman Drive
363    San Jose, CA  95134
364    USA
366    Email: mcgrew@cisco.com
391 Salowey, et al.          Expires August 29, 2007                [Page 7]
393 Internet-Draft          RSA AES-GCM Ciphersuites           February 2007
396 Full Copyright Statement
398    Copyright (C) The IETF Trust (2007).
400    This document is subject to the rights, licenses and restrictions
401    contained in BCP 78, and except as set forth therein, the authors
402    retain all their rights.
404    This document and the information contained herein are provided on an
405    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
406    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
407    THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
408    OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
409    THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
410    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
413 Intellectual Property
415    The IETF takes no position regarding the validity or scope of any
416    Intellectual Property Rights or other rights that might be claimed to
417    pertain to the implementation or use of the technology described in
418    this document or the extent to which any license under such rights
419    might or might not be available; nor does it represent that it has
420    made any independent effort to identify any such rights.  Information
421    on the procedures with respect to rights in RFC documents can be
422    found in BCP 78 and BCP 79.
424    Copies of IPR disclosures made to the IETF Secretariat and any
425    assurances of licenses to be made available, or the result of an
426    attempt made to obtain a general license or permission for the use of
427    such proprietary rights by implementers or users of this
428    specification can be obtained from the IETF on-line IPR repository at
429    http://www.ietf.org/ipr.
431    The IETF invites any interested party to bring to its attention any
432    copyrights, patents or patent applications, or other proprietary
433    rights that may cover technology that may be required to implement
434    this standard.  Please address the information to the IETF at
435    ietf-ipr@ietf.org.
438 Acknowledgment
440    Funding for the RFC Editor function is provided by the IETF
441    Administrative Support Activity (IASA).
447 Salowey, et al.          Expires August 29, 2007                [Page 8]