diff options
Diffstat (limited to 'doc/protocol/draft-ietf-tls-rsa-aes-gcm-01.txt')
-rw-r--r-- | doc/protocol/draft-ietf-tls-rsa-aes-gcm-01.txt | 504 |
1 files changed, 0 insertions, 504 deletions
diff --git a/doc/protocol/draft-ietf-tls-rsa-aes-gcm-01.txt b/doc/protocol/draft-ietf-tls-rsa-aes-gcm-01.txt deleted file mode 100644 index baddf1ea57..0000000000 --- a/doc/protocol/draft-ietf-tls-rsa-aes-gcm-01.txt +++ /dev/null @@ -1,504 +0,0 @@ - - - -TLS Working Group J. Salowey -Internet-Draft A. Choudhury -Intended status: Standards Track D. McGrew -Expires: July 16, 2008 Cisco Systems, Inc. - January 13, 2008 - - - RSA based AES-GCM Cipher Suites for TLS - draft-ietf-tls-rsa-aes-gcm-01 - -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 July 16, 2008. - -Copyright Notice - - Copyright (C) The IETF Trust (2008). - -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 July 16, 2008 [Page 1] - -Internet-Draft RSA AES-GCM Ciphersuites January 2008 - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - - 2. Conventions Used In This Document . . . . . . . . . . . . . . . 3 - - 3. RSA Based AES-GCM Cipher Suites . . . . . . . . . . . . . . . . 3 - 3.1. Recommendations for Multiple Cryptographic Processors . . . 4 - - 4. TLS Versions . . . . . . . . . . . . . . . . . . . . . . . . . 5 - - 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 - - 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 - 6.1. Perfect Forward Secrecy . . . . . . . . . . . . . . . . . . 6 - 6.2. Counter Reuse . . . . . . . . . . . . . . . . . . . . . . . 6 - - 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 - - 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 - 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 - 8.2. Informative References . . . . . . . . . . . . . . . . . . 7 - - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 - Intellectual Property and Copyright Statements . . . . . . . . . . 9 - - - - - - - - - - - - - - - - - - - - - - - - - - -Salowey, et al. Expires July 16, 2008 [Page 2] - -Internet-Draft RSA AES-GCM Ciphersuites January 2008 - - -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) cipher, as defined in TLS 1.2[I-D.ietf-tls-rfc4346-bis]. - The ciphersuites defined in this draft may be used with Datagram TLS - defined in [RFC4347]. This memo uses GCM in a way similar to - [I-D.ietf-tls-ecc-new-mac]. - - -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 following ciphersuites use the new authenticated encryption modes - defined in TLS 1.2 with AES in Galois Counter Mode (GCM) [GCM]: - - 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 use 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 - "nonce" SHALL be 12 bytes long and it is "partially implicit" (see - section 3.2.1 in [I-D.mcgrew-auth-enc]). Part of the nonce is - - - -Salowey, et al. Expires July 16, 2008 [Page 3] - -Internet-Draft RSA AES-GCM Ciphersuites January 2008 - - - generated as part of the handshake process and is static for the - entire session and part is carried in each packet. - - Struct{ - opaque salt[4]; - opaque explicit_nonce_part[8]; - } GCMNonce - - The salt is the "implicit" part of the nonce and is not sent in the - packet. It is either the client_write_IV if the client is sending or - the server_write_IV if the server is sending. These IVs SHALL be 4 - bytes long. - - The explicit_nonce_part is chosen by the sender and included in the - packet. Each value of the explicit_nonce_part MUST be distinct for - each distinct invocation of GCM encrypt function for any fixed key. - Failure to meet this uniqueness requirement can significantly degrade - security. The explicit_nonce_part is carried in the IV field of the - GenericAEADCipher structure. Therefore, for all the algorithms - defined in this section, SecurityParameters.iv_length=8. - - In the case of TLS the explicit_nonce_part MAY be the 64-bit sequence - number. In the case of Datagram TLS [RFC4347] the - explicit_nonce_part MAY be formed from the concatenation of the 16- - bit epoch with the 48-bit DTLS seq_num. - - The RSA and RSA-DHE key exchange is performed as defined in - [I-D.ietf-tls-rfc4346-bis]. - - The PRF algorithms SHALL be as follows: - - 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. - -3.1. Recommendations for Multiple Cryptographic Processors - - If multiple cryptographic processors are in use by the sender, then - the sender MUST ensure that each value of the explicit_nonce_part - that is used by each processor is distinct. In this case each - encryption processor SHOULD include in the explicit_nonce_part a a - fixed value that is distinct for each processor. The recommended - format is - - explicit_nonce_part = FixedDistinct || Variable - - - - -Salowey, et al. Expires July 16, 2008 [Page 4] - -Internet-Draft RSA AES-GCM Ciphersuites January 2008 - - - where the FixedDistinct field is distinct for each encryption - processor, but is fixed for a given processor, and the Variable field - is distinct for each distinct nonce used by a particular encryption - processor. When this method is used, the FixedDistinct fields used - by the different processors MUST have the same length. - - In the terms of Figure 2 in [I-D.mcgrew-auth-enc], the Salt is the - Fixed-Common part of the nonce (it is fixed, and it is common across - all encryption processors), the FixedDistinct field exactly - corresponds to the Fixed-Distinct field, and the Variable field - corresponds to the Counter field, and the explicit part exactly - corresponds to the explicit_nonce_part. - - For clarity, we provide an example for TLS in which there are two - distinct encryption processors, each of which uses a one-byte - FixedDistinct field: - - Salt = eedc68dc - FixedDistinct = 01 (for the first encryption processor) - FixedDistinct = 02 (for the second encryption processor) - - The GCMnonces generated by the first encryption processor, and their - corresponding explicit_nonce_parts, are: - - GCMNonce explicit_nonce_part - ------------------------ ---------------------------- - eedc68dc0100000000000000 0100000000000000 - eedc68dc0100000000000001 0100000000000001 - eedc68dc0100000000000002 0100000000000002 - ... - - The GCMnonces generated by the second encryption processor, and their - corresponding explicit_nonce_parts, are - - GCMNonce explicit_nonce_part - ------------------------ ---------------------------- - eedc68dc0200000000000000 0200000000000000 - eedc68dc0200000000000001 0200000000000001 - eedc68dc0200000000000002 0200000000000002 - ... - - - -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 - - - -Salowey, et al. Expires July 16, 2008 [Page 5] - -Internet-Draft RSA AES-GCM Ciphersuites January 2008 - - - 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. - - -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 - - The security considerations in [I-D.ietf-tls-rfc4346-bis] apply to - this document as well. The remainder of this section describes - security considerations specific to the cipher suites described in - this document. - -6.1. Perfect Forward Secrecy - - The perfect forward secrecy properties of RSA based TLS ciphersuites - are discussed in the security analysis of [I-D.ietf-tls-rfc4346-bis]. - It should be noted that only the ephemeral Diffie-Hellman based - ciphersuites (RSA_DHE) 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-ecc-new-mac]. - - -8. References - - - -Salowey, et al. Expires July 16, 2008 [Page 6] - -Internet-Draft RSA AES-GCM Ciphersuites January 2008 - - -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 Transport Layer Security - (TLS) Protocol Version 1.2", draft-ietf-tls-rfc4346-bis-07 - (work in progress), November 2007. - - [I-D.mcgrew-auth-enc] - McGrew, D., "An Interface and Algorithms for Authenticated - Encryption", draft-mcgrew-auth-enc-05 (work in progress), - November 2007. - - [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-ecc-new-mac] - Rescorla, E., "TLS Elliptic Curve Cipher Suites with SHA- - 256/384 and AES Galois Counter Mode", - draft-ietf-tls-ecc-new-mac-02 (work in progress), - December 2007. - - [I-D.rescorla-tls-suiteb] - Salter, M. and E. Rescorla, "Suite B Cipher Suites for - TLS", draft-rescorla-tls-suiteb-01 (work in progress), - June 2007. - - [IEEE8021AE] - Institute of Electrical and Electronics Engineers, "Media - Access Control Security", IEEE Standard 802.1AE, - August 2006. - - - - -Salowey, et al. Expires July 16, 2008 [Page 7] - -Internet-Draft RSA AES-GCM Ciphersuites January 2008 - - - [RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode - (GCM) in IPsec Encapsulating Security Payload (ESP)", - RFC 4106, June 2005. - - -Authors' Addresses - - Joseph Salowey - Cisco Systems, Inc. - 2901 3rd. Ave - Seattle, WA 98121 - USA - - Email: jsalowey@cisco.com - - - Abhijit Choudhury - Cisco Systems, Inc. - 3625 Cisco Way - 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 July 16, 2008 [Page 8] - -Internet-Draft RSA AES-GCM Ciphersuites January 2008 - - -Full Copyright Statement - - Copyright (C) The IETF Trust (2008). - - 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 July 16, 2008 [Page 9] - |