diff options
Diffstat (limited to 'doc/protocol/draft-ietf-tls-rsa-aes-gcm-02.txt')
| -rw-r--r-- | doc/protocol/draft-ietf-tls-rsa-aes-gcm-02.txt | 504 |
1 files changed, 0 insertions, 504 deletions
diff --git a/doc/protocol/draft-ietf-tls-rsa-aes-gcm-02.txt b/doc/protocol/draft-ietf-tls-rsa-aes-gcm-02.txt deleted file mode 100644 index 671bf846b2..0000000000 --- a/doc/protocol/draft-ietf-tls-rsa-aes-gcm-02.txt +++ /dev/null @@ -1,504 +0,0 @@ -
-
-
-TLS Working Group J. Salowey
-Internet-Draft A. Choudhury
-Intended status: Standards Track D. McGrew
-Expires: August 10, 2008 Cisco Systems, Inc.
- February 7, 2008
-
-
- AES-GCM Cipher Suites for TLS
- draft-ietf-tls-rsa-aes-gcm-02
-
-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 10, 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, DSS and
-
-
-
-Salowey, et al. Expires August 10, 2008 [Page 1]
-
-Internet-Draft AES-GCM Ciphersuites February 2008
-
-
- Diffie-Hellman based key exchange mechanisms.
-
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
-
- 2. Conventions Used In This Document . . . . . . . . . . . . . . . 3
-
- 3. AES-GCM Cipher Suites . . . . . . . . . . . . . . . . . . . . . 3
-
- 4. TLS Versions . . . . . . . . . . . . . . . . . . . . . . . . . 4
-
- 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
-
- 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
- 6.1. Counter Reuse . . . . . . . . . . . . . . . . . . . . . . . 5
- 6.2. Recommendations for Multiple Encryption Processors . . . . 5
-
- 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
-
- 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 August 10, 2008 [Page 2]
-
-Internet-Draft AES-GCM Ciphersuites February 2008
-
-
-1. Introduction
-
- This document describes the use of AES [AES]in Galois Counter Mode
- (GCM) [GCM] (AES-GCM) with various key exchange mechanisms as a
- ciphersuite for TLS. AES-GCM is not only efficient and secure, but
- 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]. This document defines ciphersutes based on RSA, DSS
- and Diffie-Hellman key exchanges; ECC based ciphersuites are defined
- in a separate document [I-D.ietf-tls-ecc-new-mac]. 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. 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 = {TBD,TBD}
- CipherSuite TLS_RSA_WITH_AES_256_GCM_SHA384 = {TBD,TBD}
- CipherSuite TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 = {TBD,TBD}
- CipherSuite TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 = {TBD,TBD}
- CipherSuite TLS_DH_RSA_WITH_AES_128_GCM_SHA256 = {TBD,TBD}
- CipherSuite TLS_DH_RSA_WITH_AES_256_GCM_SHA384 = {TBD,TBD}
- CipherSuite TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 = {TBD,TBD}
- CipherSuite TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 = {TBD,TBD}
- CipherSuite TLS_DH_DSS_WITH_AES_128_GCM_SHA256 = {TBD,TBD}
- CipherSuite TLS_DH_DSS_WITH_AES_256_GCM_SHA384 = {TBD,TBD}
- CipherSuite TLS_DH_anon_WITH_AES_128_GCM_SHA256 = {TBD,TBD}
- CipherSuite TLS_DH_anon_WITH_AES_256_GCM_SHA384 = {TBD,TBD}
-
- These ciphersuites use the AES-GCM authenticated encryption with
-
-
-
-Salowey, et al. Expires August 10, 2008 [Page 3]
-
-Internet-Draft AES-GCM Ciphersuites February 2008
-
-
- associated data (AEAD) algorithms AEAD_AES_128_GCM and
- AEAD_AES_256_GCM described in [RFC5116]. Note that each of these
- AEAD algorithms 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 [RFC5116]). Part of the nonce is generated as part
- of the handshake process and is static for the entire session and the
- other 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, therefore, for all the algorithms defined in this
- section, SecurityParameters.fixed_iv_length=4.
-
- 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. For all the algorithms defined in this
- section, SecurityParameters.record_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, DHE_RSA, DH_RSA, DHE_DSS, DH_DSS, and DH_anon key exchanges
- are performed as defined in [I-D.ietf-tls-rfc4346-bis].
-
- The PRF algorithms SHALL be as follows:
-
- For ciphersuites ending in _SHA256 the hash function is SHA256.
-
- For ciphersuites ending in _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.
-
-
-
-Salowey, et al. Expires August 10, 2008 [Page 4]
-
-Internet-Draft AES-GCM Ciphersuites February 2008
-
-
- 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 = {TBD,TBD}
- CipherSuite TLS_RSA_WITH_AES_256_GCM_SHA384 = {TBD,TBD}
- CipherSuite TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 = {TBD,TBD}
- CipherSuite TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 = {TBD,TBD}
- CipherSuite TLS_DH_RSA_WITH_AES_128_GCM_SHA256 = {TBD,TBD}
- CipherSuite TLS_DH_RSA_WITH_AES_256_GCM_SHA384 = {TBD,TBD}
- CipherSuite TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 = {TBD,TBD}
- CipherSuite TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 = {TBD,TBD}
- CipherSuite TLS_DH_DSS_WITH_AES_128_GCM_SHA256 = {TBD,TBD}
- CipherSuite TLS_DH_DSS_WITH_AES_256_GCM_SHA384 = {TBD,TBD}
- CipherSuite TLS_DH_anon_WITH_AES_128_GCM_SHA256 = {TBD,TBD}
- CipherSuite TLS_DH_anon_WITH_AES_256_GCM_SHA384 = {TBD,TBD}
-
-
-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. Counter Reuse
-
- AES-GCM security requires that the counter is never reused. The IV
- construction in Section 3 is designed to prevent counter reuse.
-
-6.2. Recommendations for Multiple Encryption Processors
-
- If multiple cryptographic processors are in use by the sender, then
- the sender MUST ensure that, for a particular key, each value of the
- explicit_nonce_part used with that key is distinct. In this case
- each encryption processor SHOULD include in the explicit_nonce_part a
- fixed value that is distinct for each processor. The recommended
- format is
-
-
-
-Salowey, et al. Expires August 10, 2008 [Page 5]
-
-Internet-Draft AES-GCM Ciphersuites February 2008
-
-
- explicit_nonce_part = FixedDistinct || Variable
-
- 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 [RFC5116], 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
- ...
-
-
-
-
-
-
-
-
-
-Salowey, et al. Expires August 10, 2008 [Page 6]
-
-Internet-Draft AES-GCM Ciphersuites February 2008
-
-
-7. Acknowledgements
-
- This draft borrows heavily from [I-D.ietf-tls-ecc-new-mac]. The
- authors would like to thank Alex Lam and Pasi Eronen for providing
- useful comments during the review of this draft.
-
-
-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 Transport Layer Security
- (TLS) Protocol Version 1.2", draft-ietf-tls-rfc4346-bis-08
- (work in progress), January 2008.
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
- Security", RFC 4347, April 2006.
-
- [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated
- Encryption", RFC 5116, January 2008.
-
-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.
-
- [IEEE8021AE]
- Institute of Electrical and Electronics Engineers, "Media
- Access Control Security", IEEE Standard 802.1AE,
- August 2006.
-
- [RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode
-
-
-
-Salowey, et al. Expires August 10, 2008 [Page 7]
-
-Internet-Draft AES-GCM Ciphersuites February 2008
-
-
- (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 August 10, 2008 [Page 8]
-
-Internet-Draft AES-GCM Ciphersuites February 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 August 10, 2008 [Page 9]
-
|