--- /dev/null
+
+
+
+TLS Working Group J. Salowey
+Internet-Draft A. Choudhury
+Intended status: Standards Track D. McGrew
+Expires: August 29, 2007 Cisco Systems, Inc.
+ February 25, 2007
+
+
+ RSA based AES-GCM Cipher Suites for TLS
+ draft-salowey-tls-rsa-aes-gcm-00
+
+Status of this Memo
+
+ By submitting this Internet-Draft, each author represents that any
+ applicable patent or other IPR claims of which he or she is aware
+ have been or will be disclosed, and any of which he or she becomes
+ aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF), its areas, and its working groups. Note that
+ other groups may also distribute working documents as Internet-
+ Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress."
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/ietf/1id-abstracts.txt.
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html.
+
+ This Internet-Draft will expire on August 29, 2007.
+
+Copyright Notice
+
+ Copyright (C) The IETF Trust (2007).
+
+Abstract
+
+ This memo describes the use of the Advanced Encryption Standard (AES)
+ in Galois/Counter Mode (GCM) as a Transport Layer Security (TLS)
+ authenticated encryption operation. GCM provides both
+ confidentiality and data origin authentication, can be efficiently
+ implemented in hardware for speeds of 10 gigabits per second and
+ above, and is also well-suited to software implementations. This
+ memo defines TLS ciphersuites that use AES-GCM with RSA.
+
+
+
+Salowey, et al. Expires August 29, 2007 [Page 1]
+\f
+Internet-Draft RSA AES-GCM Ciphersuites February 2007
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
+
+ 2. Conventions Used In This Document . . . . . . . . . . . . . . . 3
+
+ 3. RSA Based AES-GCM Cipher Suites . . . . . . . . . . . . . . . . 3
+
+ 4. TLS Versions . . . . . . . . . . . . . . . . . . . . . . . . . 4
+
+ 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
+
+ 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
+ 6.1. Perfect Forward Secrecy . . . . . . . . . . . . . . . . . . 5
+ 6.2. Counter Reuse . . . . . . . . . . . . . . . . . . . . . . . 5
+
+ 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5
+
+ 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 8.1. Normative References . . . . . . . . . . . . . . . . . . . 5
+ 8.2. Informative References . . . . . . . . . . . . . . . . . . 6
+
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6
+ Intellectual Property and Copyright Statements . . . . . . . . . . 8
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Salowey, et al. Expires August 29, 2007 [Page 2]
+\f
+Internet-Draft RSA AES-GCM Ciphersuites February 2007
+
+
+1. Introduction
+
+ This document describes the use of AES [AES]in Galois Counter Mode
+ (GCM) [GCM] (AES-GCM) with RSA based key exchange as a ciphersuite
+ for TLS. This mechanism is not only efficient and secure, hardware
+ implementations can achieve high speeds with low cost and low
+ latency, because the mode can be pipelined. Applications like
+ CAPWAP, which uses DTLS, can benefit from the high-speed
+ implementations when wireless termination points (WTPs) and
+ controllers (ACs) have to meet requirements to support higher
+ throughputs in the future. AES-GCM has been specified as a mode that
+ can be used with IPsec ESP [RFC4106] and 802.1AE MAC Security
+ [IEEE8021AE]. It also is part of the NSA suite B ciphersuites for
+ TLS [I-D.rescorla-tls-suiteb]; however in order to meet Suite B
+ requirements these ciphersuites require ECC base key exchange and TLS
+ 1.2. The ciphersuites defined in this document are based on RSA
+ which allows the use of AES-GCM in environments that have not
+ deployed ECC algorithms and do not need to meet NSA Suite B
+ requirements. AES-GCM is an authenticated encryption with associated
+ data (AEAD) operation, as used in TLS 1.2[I-D.ietf-tls-rfc4346-bis].
+ The ciphersuites defined in this draft may be used with DTLS defined
+ in [RFC4347] and [I-D.ietf-tls-ctr]. This memo uses GCM in a way
+ similar to [I-D.rescorla-tls-suiteb].
+
+
+2. Conventions Used In This Document
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in [RFC2119]
+
+
+3. RSA Based AES-GCM Cipher Suites
+
+ The ciphersuites defined in this document are based on the the AES-
+ GCM authenticated encryption with associated data (AEAD) algorithms
+ AEAD_AES_128_GCM and AEAD_AES_256_GCM described in
+ [I-D.mcgrew-auth-enc]. Note that this specification uses a 128-bit
+ authentication tag with GCM. The following ciphersuites are defined:
+
+ CipherSuite TLS_RSA_WITH_AES_128_GCM_SHA256 = {TBD1,TBD1}
+ CipherSuite TLS_RSA_WITH_AES_256_GCM_SHA384 = {TBD2,TBD2}
+ CipherSuite TLS_RSA_DHE_WITH_AES_128_GCM_SHA256 = {TBD3,TBD3}
+ CipherSuite TLS_RSA_DHE_WITH_AES_256_GCM_SHA384 = {TBD4,TBD4}
+
+ These ciphersuites make use of the AEAD capability in TLS 1.2
+ [I-D.ietf-tls-rfc4346-bis]. The "nonce" SHALL be 12 bytes long and
+ constructed from a salt and a counter as follows:
+
+
+
+Salowey, et al. Expires August 29, 2007 [Page 3]
+\f
+Internet-Draft RSA AES-GCM Ciphersuites February 2007
+
+
+ Struct{
+ uint32 salt;
+ uint64 counter;
+ } GCMNonce
+
+ The salt is derived form the TLS key block as follows:
+
+ struct {
+ case client:
+ uint32 client_write_IV; // low order 32-bits
+ case server:
+ uint32 server_write_IV; // low order 32-bits
+ } salt
+
+
+ In the case of TLS the counter is the 64 bit sequence number. In the
+ case of DTLS the counter is formed from the concatenation of the 16-
+ bit epoch with the 48-bit sequence number.
+
+ The RSA and RSA-DHE key exchange is performed as defined in
+ [I-D.ietf-tls-rfc4346-bis].
+
+ Recall that an AEAD operation replaces the use of HMAC as a MAC, but
+ not as a PRF for the purposes of key derivation. Consequently, the
+ hash function for the TLS PRF must be explicitly specified by the
+ ciphersuite. For TLS_RSA_WITH_AES_128_GCM_SHA256 and
+ TLS_RSA_DHE_WITH_AES_128_GCM_SHA256 the hash function is SHA256. For
+ TLS_RSA_WITH_AES_256_GCM_SHA384 and
+ TLS_RSA_DHE_WITH_AES_256_GCM_SHA384 the hash function is SHA384.
+
+
+4. TLS Versions
+
+ These ciphersuites make use of the authenticated encryption with
+ additional data defined in TLS 1.2 [I-D.ietf-tls-rfc4346-bis]. They
+ MUST NOT be negotiated in older versions of TLS. Clients MUST NOT
+ offer these cipher suites if they do not offer TLS 1.2 or later.
+ Servers which select an earlier version of TLS MUST NOT select one of
+ these cipher suites. Because TLS has no way for the client to
+ indicate that it supports TLS 1.2 but not earlier, a non-compliant
+ server might potentially negotiate TLS 1.1 or earlier and select one
+ of the cipher suites in this document. Clients MUST check the TLS
+ version and generate a fatal "illegal_parameter" alert if they detect
+ an incorrect version.
+
+
+
+
+
+
+
+Salowey, et al. Expires August 29, 2007 [Page 4]
+\f
+Internet-Draft RSA AES-GCM Ciphersuites February 2007
+
+
+5. IANA Considerations
+
+ IANA has assigned the following values for the ciphersuites defined
+ in this draft:
+
+ CipherSuite TLS_RSA_WITH_AES_128_GCM_SHA256 = {TBD1,TBD1}
+ CipherSuite TLS_RSA_WITH_AES_256_GCM_SHA384 = {TBD2,TBD2}
+ CipherSuite TLS_RSA_DHE_WITH_AES_128_GCM_SHA256 = {TBD3,TBD3}
+ CipherSuite TLS_RSA_DHE_WITH_AES_256_GCM_SHA384 = {TBD4,TBD4}
+
+
+6. Security Considerations
+
+6.1. Perfect Forward Secrecy
+
+ The perfect forward secrecy properties of RSA based TLS ciphersuites
+ are discussed in the security analysis of [RFC4346]. It should be
+ noted that only the ephemeral Diffie-Hellman based ciphersuites are
+ capable of providing perfect forward secrecy.
+
+6.2. Counter Reuse
+
+ AES-GCM security requires that the counter is never reused. The IV
+ construction in Section 3 is designed to prevent counter reuse.
+
+
+7. Acknowledgements
+
+ This draft borrows heavily from [I-D.ietf-tls-ctr] and
+ [I-D.rescorla-tls-suiteb]
+
+
+8. References
+
+8.1. Normative References
+
+ [AES] National Institute of Standards and Technology,
+ "Specification for the Advanced Encryption Standard
+ (AES)", FIPS 197, November 2001.
+
+ [GCM] National Institute of Standards and Technology,
+ "Recommendation for Block Cipher Modes of Operation:
+ Galois Counter Mode (GCM) for Confidentiality and
+ Authentication", SP 800-38D, April 2006.
+
+ [I-D.ietf-tls-rfc4346-bis]
+ Dierks, T. and E. Rescorla, "The TLS Protocol Version
+ 1.2", draft-ietf-tls-rfc4346-bis-02 (work in progress),
+
+
+
+Salowey, et al. Expires August 29, 2007 [Page 5]
+\f
+Internet-Draft RSA AES-GCM Ciphersuites February 2007
+
+
+ October 2006.
+
+ [I-D.mcgrew-auth-enc]
+ McGrew, D., "An Interface and Algorithms for Authenticated
+ Encryption", draft-mcgrew-auth-enc-01 (work in progress),
+ October 2006.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
+ (TLS) Protocol Version 1.1", RFC 4346, April 2006.
+
+ [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
+ Security", RFC 4347, April 2006.
+
+8.2. Informative References
+
+ [I-D.ietf-tls-ctr]
+ Modadugu, N. and E. Rescorla, "AES Counter Mode Cipher
+ Suites for TLS and DTLS", draft-ietf-tls-ctr-01 (work in
+ progress), June 2006.
+
+ [I-D.rescorla-tls-suiteb]
+ Salter, M. and E. Rescorla, "SuiteB CipherSuites for TLS",
+ draft-rescorla-tls-suiteb-00 (work in progress),
+ December 2006.
+
+ [IEEE8021AE]
+ Institute of Electrical and Electronics Engineers, "Media
+ Access Control Security", IEEE Standard 802.1AE,
+ August 2006.
+
+ [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
+ RFC 2246, January 1999.
+
+ [RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode
+ (GCM) in IPsec Encapsulating Security Payload (ESP)",
+ RFC 4106, June 2005.
+
+
+
+
+
+
+
+
+
+
+
+
+Salowey, et al. Expires August 29, 2007 [Page 6]
+\f
+Internet-Draft RSA AES-GCM Ciphersuites February 2007
+
+
+Authors' Addresses
+
+ Joseph Salowey
+ Cisco Systems, Inc.
+ 2901 3rd. Ave
+ Seattle, WA 98121
+ USA
+
+ Email: jsalowey@cisco.com
+
+
+ Abhijit Choudhury
+ Cisco Systems, Inc.
+ 170 W Tasman Drive
+ San Jose, CA 95134
+ USA
+
+ Email: abhijitc@cisco.com
+
+
+ David McGrew
+ Cisco Systems, Inc.
+ 170 W Tasman Drive
+ San Jose, CA 95134
+ USA
+
+ Email: mcgrew@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Salowey, et al. Expires August 29, 2007 [Page 7]
+\f
+Internet-Draft RSA AES-GCM Ciphersuites February 2007
+
+
+Full Copyright Statement
+
+ Copyright (C) The IETF Trust (2007).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
+ THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
+ OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+ THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+
+Acknowledgment
+
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).
+
+
+
+
+
+Salowey, et al. Expires August 29, 2007 [Page 8]
+\f
projects / thirdparty / gnutls.git / commitdiff
