diff options
Diffstat (limited to 'doc/protocol/draft-salowey-tls-rsa-aes-gcm-00.txt')
-rw-r--r-- | doc/protocol/draft-salowey-tls-rsa-aes-gcm-00.txt | 448 |
1 files changed, 0 insertions, 448 deletions
diff --git a/doc/protocol/draft-salowey-tls-rsa-aes-gcm-00.txt b/doc/protocol/draft-salowey-tls-rsa-aes-gcm-00.txt deleted file mode 100644 index 7acd83e1d6..0000000000 --- a/doc/protocol/draft-salowey-tls-rsa-aes-gcm-00.txt +++ /dev/null @@ -1,448 +0,0 @@ - - - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - |