--- /dev/null
+
+
+
+Network Working Group N. Modadugu
+Internet-Draft Stanford University
+Expires: December 15, 2006 E. Rescorla
+ Network Resonance
+ June 13, 2006
+
+
+ AES Counter Mode Cipher Suites for TLS and DTLS
+ draft-ietf-tls-ctr-01.txt
+
+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 December 15, 2006.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2006).
+
+Abstract
+
+ This document describes the use of the Advanced Encryption Standard
+ (AES) Counter Mode for use as a Transport Layer Security (TLS) and
+ Datagram Transport Layer Security (DTLS) confidentiality mechanism.
+
+
+
+
+
+
+
+Modadugu & Rescorla Expires December 15, 2006 [Page 1]
+\f
+Internet-Draft TLS/DTLS AES-CTR June 2006
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 1.1. Conventions Used In This Document . . . . . . . . . . . . 3
+ 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 3. Encrypting Records with AES Counter Mode . . . . . . . . . . . 4
+ 3.1. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 3.1.1. Encryption . . . . . . . . . . . . . . . . . . . . . . 4
+ 3.1.2. Decryption . . . . . . . . . . . . . . . . . . . . . . 5
+ 3.1.3. Counter Block Construction . . . . . . . . . . . . . . 5
+ 3.2. DTLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
+ 3.3. Padding . . . . . . . . . . . . . . . . . . . . . . . . . 7
+ 3.4. Session Resumption . . . . . . . . . . . . . . . . . . . . 7
+ 4. Design Rationale . . . . . . . . . . . . . . . . . . . . . . . 7
+ 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
+ 5.1. Maximum Key Lifetime . . . . . . . . . . . . . . . . . . . 8
+ 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
+ 7. Normative References . . . . . . . . . . . . . . . . . . . . . 8
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
+ Intellectual Property and Copyright Statements . . . . . . . . . . 10
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Modadugu & Rescorla Expires December 15, 2006 [Page 2]
+\f
+Internet-Draft TLS/DTLS AES-CTR June 2006
+
+
+1. Introduction
+
+ Transport Layer Security [3] provides channel-oriented security for
+ application layer protocols. In TLS, cryptographic algorithms are
+ specified in "Cipher Suites, which consist of a group of algorithms
+ to be used together."
+
+ Cipher suites supported by TLS are divided into stream and block
+ ciphers. Counter mode ciphers behave like stream ciphers, but are
+ constructed based on a block cipher primitive (that is, counter mode
+ operation of a block cipher results in a stream cipher.) This
+ specification is limited to discussion of the operation of AES in
+ counter mode (AES-CTR.)
+
+ Counter mode ciphers (CTR) offer a number of attractive features over
+ other block cipher modes and stream ciphers such as RC4:
+
+ Low Bandwidth: AES-CTR provides a saving of 17-32 bytes per record
+ compared to AES-CBC as used in TLS 1.1 and DTLS. 16 bytes are
+ saved from not having to transmit an explicit IV, and another 1-16
+ bytes are saved from the absence of the padding block.
+
+ Random Access: AES-CTR is capable of random access within the key
+ stream. For DTLS, this implies that records can be processed out
+ of order without dependency on packet arrival order, and also
+ without keystream buffering.
+
+ Parallelizable: As a consequence of AES-CTR supporting random access
+ within the key stream, making the cipher amenable to parallelizing
+ and pipelining in hardware.
+
+ Multiple mode support: AES-CTR support in TLS/DTLS allows for
+ implementator to support both a stream (CTR) and block (CBC)
+ cipher through the implementation of a single symmetric algorithm.
+
+1.1. 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 [1].
+
+
+2. Terminology
+
+ This document reuses some terminology introduced in [2] and [3]. The
+ term 'counter block' has the same meaning as used in [2]. However,
+ the term 'IV' in this document, holds the meaning defined in [3].
+
+
+
+
+Modadugu & Rescorla Expires December 15, 2006 [Page 3]
+\f
+Internet-Draft TLS/DTLS AES-CTR June 2006
+
+
+3. Encrypting Records with AES Counter Mode
+
+ AES-CTR is functionally equivalent to a stream cipher; it generates a
+ pseudo-random cipher stream that is XORed into the plaintext to form
+ ciphertext.
+
+ The cipher stream is generated by applying the AES encrypt operation
+ on a sequence of 128-bit counter blocks. Counter blocks, in turn,
+ are generated based on record sequence numbers (in the case of TLS),
+ or a combination of record sequence and epoch numbers (in the case of
+ DTLS.)
+
+ It should be noted that although the client and server use the same
+ sequence number space, they use different write keys and counter
+ blocks.
+
+ There is one important constraint on the use of counter mode ciphers:
+ for a given key, a counter block value MUST never be used more than
+ once.
+
+ This constraint is required because a given key and counter block
+ value completely specify a portion of the cipher stream. Hence, a
+ particular counter block value when used (with a given key) to
+ generate more than one ciphertext leaks information about the
+ corresponding plaintexts. For a detailed explanation, see Section 7
+ of [2].
+
+ Given this constraint, the challenge then is in the design of the
+ counter block. We describe the construction of the counter block in
+ the following sections.
+
+ TLS/DTLS records encrypted with AES-CTR mode use a
+ CipherSpec.cipher_type of GenericStreamCipher (Section 6.2.3 of [3]).
+
+3.1. TLS
+
+ AES counter mode requires the encryptor and decryptor to share a per-
+ record unique counter block. As previously stated, a given counter
+ block MUST never be used more than once with the same key. The
+ following description of AES-CTR mode has been adapted from [2].
+
+3.1.1. Encryption
+
+ To encrypt a payload with AES-CTR, the encryptor sequentially
+ partitions the plaintext (PT) into 128-bit blocks. The final PT
+ block MAY be less than 128-bits. This partitioning is denoted as:
+
+ PT = PT[1] PT[2] ... PT[n]
+
+
+
+Modadugu & Rescorla Expires December 15, 2006 [Page 4]
+\f
+Internet-Draft TLS/DTLS AES-CTR June 2006
+
+
+ In order to encrypt, each PT block is XORed with a block of the key
+ stream to generate the ciphertext (CT.) The keystream is generated
+ via the AES encryption of each counter block value, with each
+ encryption operation producing 128-bits of key stream.
+
+ The encryption operation is performed as follows:
+
+
+ FOR i := 1 to n-1 DO
+ CT[i] := PT[i] XOR AES(CtrBlk)
+ CtrBlk := CtrBlk + 1
+ END
+ CT[n] := PT[n] XOR TRUNC(AES(CtrBlk))
+
+ The AES() function performs AES encryption with the fresh key.
+
+ The TRUNC() function truncates the output of the AES encrypt
+ operation to the same length as the final plaintext block, returning
+ the leftmost bits.
+
+3.1.2. Decryption
+
+ Decryption is similar to encryption. The decryption of n ciphertext
+ blocks is performed as follows:
+
+
+ FOR i := 1 to n-1 DO
+ PT[i] := CT[i] XOR AES(CtrBlk)
+ CtrBlk := CtrBlk + 1
+ END
+ PT[n] := CT[n] XOR TRUNC(AES(CtrBlk))
+
+ The AES() and TRUNC() operate identically as in the case of
+ encryption.
+
+3.1.3. Counter Block Construction
+
+ To construct the counter block, the leftmost 48-bits of the counter
+ block are set to the rightmost 48-bits of the client_write_IV (for
+ the half-duplex stream originated by the client) or the rightmost 48-
+ bits of the server_write_IV (for the half-duplex stream originated by
+ the server.) The following 64-bits of the counter block are set to
+ record sequence number, and the remaining 16-bits function as the
+ block counter. The block counter is a 16-bit unsigned integer in
+ network byte order (i.e. big-endien). The block counter is initially
+ set to one, and is incremented by one to generate subsequent counter
+ blocks, each resulting in another 128-bits of key stream.
+
+
+
+
+Modadugu & Rescorla Expires December 15, 2006 [Page 5]
+\f
+Internet-Draft TLS/DTLS AES-CTR June 2006
+
+
+ The structure of the counter block is depicted below:
+
+ struct {
+ case client:
+ uint48 client_write_IV; // low order 48-bits
+ case server:
+ uint48 server_write_IV; // low order 48-bits
+ uint64 seq_num;
+ uint16 blk_ctr;
+ } CtrBlk;
+
+ The seq_num and blk_ctr fields of the counter block are initialized
+ for each record processed, while the IV is initialized immediately
+ after a key calculation is made (key calculations are made whenever a
+ TLS/DTLS handshake, either full or abbreviated, is executed.) seq_num
+ is set to the sequence number of the record, and blk_ctr is
+ initialized to 1.
+
+ Note that the block counter does not overflow since the maximum size
+ of input to the record payload protection layer in TLS or DTLS
+ (TLSCompressed.length) is 2^14 + 1024 octets, and 16 bits of blk_ctr
+ allow the generation of 2^20 octets (2^16 AES blocks) of keying
+ material per record.
+
+ Note that for TLS, no part of the counter block need be transmitted,
+ since the client_write_IV and server_write_IV are derived during the
+ key calculation phase, and the record sequence number is implicit.
+
+3.2. DTLS
+
+ The operation of AES-CTR in DTLS is the same as in TLS, with the only
+ difference being the inclusion of the epoch in the counter block.
+ The counter block is constructed as follows for DTLS:
+
+ struct {
+ case client:
+ uint48 client_write_IV; // low order 48-bits
+ case server:
+ uint48 server_write_IV; // low order 48-bits
+ uint16 epoch;
+ uint48 seq_num;
+ uint16 blk_ctr;
+ } CtrBlk;
+
+ For decryption, the epoch and seq_num fields are initialized based on
+ the corresponding values in a received record.
+
+
+
+
+
+Modadugu & Rescorla Expires December 15, 2006 [Page 6]
+\f
+Internet-Draft TLS/DTLS AES-CTR June 2006
+
+
+3.3. Padding
+
+ Stream ciphers in TLS and DTLS do not require plaintext padding.
+
+3.4. Session Resumption
+
+ TLS supports session resumption via caching of session ID's and
+ connection parameters on both client and server. While resumed
+ sessions use the same master secret that was originally negotiated, a
+ resumed session uses new keys that are derived, in part, using fresh
+ client_random and server_random parameters. As a result resumed
+ sessions do not use the same encryption keys or IV's as the original
+ session.
+
+
+4. Design Rationale
+
+ An alternate design for the construction of the counter block would
+ be the use of an explicit 'record tag' (as a substitute for the
+ implicit record sequence number) that could potentially be generated
+ via an LFSR. Such a design, however, suffers a major drawback when
+ used in the TLS or DTLS protocol, without offering any significant
+ benefit: in both TLS and DTLS inclusion of such a tag would incur a
+ bandwidth cost.
+
+
+5. Security Considerations
+
+ The security considerations for the use of AES-CTR in TLS/DTLS are
+ specified below. The below text is based heavily on that for AES-CTR
+ in IPsec [2].
+
+ o Counter blocks must not be used more than once with a given key.
+ Doing so allows a passive attacker to determine the XOR of the
+ affected plain text blocks. Extracting two plaintexts from their
+ XOR is a relatively straightforward operation. Because the
+ counter block is derived from the per-record sequence, this means
+ that sequence numbers MUST never be re-used with different data.
+ Note, however, that retransmitting the same record in DTLS is
+ safe.
+ o AES-CTR can be used in pre-shared key mode, since session keys and
+ not pre-shared keys are used for ciphering. Also, since separate
+ read and write keys are generated, counter blocks generated by
+ client and server can safely overlap.
+ o As with other stream ciphers, data forgery is trivial if no
+ message integrity mechanism is employed. This threat is of no
+ concern in TLS/DTLS since all ciphersuites that support encryption
+ also employ message integrity.
+
+
+
+Modadugu & Rescorla Expires December 15, 2006 [Page 7]
+\f
+Internet-Draft TLS/DTLS AES-CTR June 2006
+
+
+5.1. Maximum Key Lifetime
+
+ TLS/DTLS sessions employing AES-CTR MUST be renegotiated before
+ sequence numbers repeat. In the case of TLS, this implies a maximum
+ of 2^64 records per session, while for DTLS the maximum is 2^48 (with
+ the remaining bits reserved for epoch.)
+
+
+6. IANA Considerations
+
+ IANA has assigned the following values for AES-CTR mode ciphers:
+
+ CipherSuite TLS_RSA_WITH_AES_128_CTR_SHA = { 0xXX, 0xXX };
+ CipherSuite TLS_DH_DSS_WITH_AES_128_CTR_SHA = { 0xXX, 0xXX };
+ CipherSuite TLS_DH_RSA_WITH_AES_128_CTR_SHA = { 0xXX, 0xXX };
+ CipherSuite TLS_DHE_DSS_WITH_AES_128_CTR_SHA = { 0xXX, 0xXX };
+ CipherSuite TLS_DHE_RSA_WITH_AES_128_CTR_SHA = { 0xXX, 0xXX };
+ CipherSuite TLS_DH_anon_WITH_AES_128_CTR_SHA = { 0xXX, 0xXX };
+
+ CipherSuite TLS_RSA_WITH_AES_256_CTR_SHA = { 0xXX, 0xXX };
+ CipherSuite TLS_DH_DSS_WITH_AES_256_CTR_SHA = { 0xXX, 0xXX };
+ CipherSuite TLS_DH_RSA_WITH_AES_256_CTR_SHA = { 0xXX, 0xXX };
+ CipherSuite TLS_DHE_DSS_WITH_AES_256_CTR_SHA = { 0xXX, 0xXX };
+ CipherSuite TLS_DHE_RSA_WITH_AES_256_CTR_SHA = { 0xXX, 0xXX };
+ CipherSuite TLS_DH_anon_WITH_AES_256_CTR_SHA = { 0xXX, 0xXX };
+
+7. Normative References
+
+ [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, March 1997.
+
+ [2] Housley, R., "Using Advanced Encryption Standard (AES) Counter
+ Mode With IPsec Encapsulating Security Payload (ESP)", RFC 3686,
+ January 2004.
+
+ [3] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)
+ Protocol Version 1.1", RFC 4346, April 2006.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Modadugu & Rescorla Expires December 15, 2006 [Page 8]
+\f
+Internet-Draft TLS/DTLS AES-CTR June 2006
+
+
+Authors' Addresses
+
+ Nagendra Modadugu
+ Stanford University
+ 353 Serra Mall
+ Stanford, CA 94305
+ USA
+
+ Email: nagendra@cs.stanford.edu
+
+
+ Eric Rescorla
+ Network Resonance
+ 2483 E. Bayshore Rd., #212
+ Palo Alto, CA 94303
+ USA
+
+ Email: ekr@networkresonance.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Modadugu & Rescorla Expires December 15, 2006 [Page 9]
+\f
+Internet-Draft TLS/DTLS AES-CTR June 2006
+
+
+Intellectual Property Statement
+
+ 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.
+
+
+Disclaimer of Validity
+
+ 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 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.
+
+
+Copyright Statement
+
+ Copyright (C) The Internet Society (2006). 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.
+
+
+Acknowledgment
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+Modadugu & Rescorla Expires December 15, 2006 [Page 10]
+\f
+
projects / thirdparty / gnutls.git / commitdiff
