Network Working Group                                        N. Modadugu
Internet-Draft                                       Stanford University
Expires: August 30, December 15, 2006                                   E. Rescorla
                                                       Network Resonance
                                                       February 26,
                                                           June 13, 2006

            AES Counter Mode Cipher Suites for TLS and DTLS

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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on August 30, December 15, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).


   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.

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.  AES Counter Mode  Encryption . . . . . . . . . . . . . . . . . . . . . .  4
       3.1.2.  Decryption . . . . . . . . . . . . . . . . . . . . . .  5
       3.1.3.  Counter Block Construction . . . . . . . . . . . . . .  5
     3.2.  DTLS . . . . . . . . . . . . . . . . . . . . . . . . . . .  6
     3.3.  Padding  . . . . . . . . . . . . . . . . . . . . . . . . . . 6  7
     3.4.  Session Resumption . . . . . . . . . . . . . . . . . . . . 6  7
   4.  Design Rationale . . . . . . . . . . . . . . . . . . . . . . . 6  7
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . .  7
     5.1.  Maximum Key Lifetime . . . . . . . . . . . . . . . . . . . 7  8
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . . 7  8
   7.  Normative References . . . . . . . . . . . . . . . . . . . . . 7  8
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8  9
   Intellectual Property and Copyright Statements . . . . . . . . . . 9 10

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 can be easily parallelized. 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 implemention implementation of a single symmetric algorithm.

1.1.  Conventions Used In This Document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   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 RFC3686,
   however, [2].  However,
   the term 'IV', 'IV' in this document, holds the meaning defined in [3].

3.  Encrypting Records with AES Counter Mode

   The use of

   AES-CTR in TLS/DTLS turns out is functionally equivalent to be fairly
   straightforward, with the additional benefit a stream cipher; it generates a
   pseudo-random cipher stream that is XORed into the method of plaintext to form

   The cipher stream is generated by applying the AES encrypt operation
   on a sequence of 128-bit counter blocks.  Counter blocks, in TLS/DTLS mimics, to turn,
   are generated based on record sequence numbers (in the case of TLS),
   or a large extent, combination of record sequence and epoch numbers (in the case of

   It should be noted that in IPsec.  The
   primary although the client and server use the same
   sequence number space, they use different write keys and counter

   There is one important constraint on the use of counter mode ciphers is that ciphers:
   for a given key, a counter block value MUST never be used more than once
   (see Section 7

   This constraint is required because a given key and counter block
   value completely specify a portion of [2] for the cipher stream.  Hence, a detailed explanation.)  In TLS/DTLS
   ensuring that
   particular counter block values never repeat during value when used (with a given
   session 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 straightforward as explained 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

   The cipher stream generated by AES-CTR is much like the cipher stream
   generated by stream ciphers like RC4.  For reasons described in
   Section 7 of [2], a counter block value MUST never be used more than
   once with a given key.  This is achieved by having part of the per-
   record IV determined by the record sequence number.  Although the
   client and server use the same sequence number space, they use
   different keys and IVs.

3.1.1.  AES Counter Mode


   AES counter mode requires the encryptor and decryptor to share a per-
   record unique counter block.  A  As previously stated, a given counter
   block MUST never be used more than once with the same key.  For a more in-depth
   discussion of AES-CTR operation, refer to Section 2.1 of [2].  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, plaintext (PT) into 128-bit blocks.  The final PT
   block MAY be less than
   128 bits. 128-bits.  This partitioning is denoted as:

   PT = PT[1] PT[2] ...  PT[n]

   In order to encrypt, each PT block is XORed with a block of the key
   stream to generate the
   ciphertext, CT. ciphertext (CT.)  The keystream is generated
   via the AES encryption of each counter block results in
   128 bits 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
         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
         PT[n] := CT[n] XOR TRUNC(AES(CtrBlk))

   The AES() and TRUNC() operate identically as in the case of

3.1.3.  Counter Block Construction

   To construct the counter block, the most significant 48 bits leftmost 48-bits of the counter
   block are set to the 48 low order bits rightmost 48-bits of the client_write_IV (for
   the half-duplex stream originated by the client) or the 48 low
   order rightmost 48-
   bits of the server_write_IV (for the half-duplex stream originated by
   the server.)  The following 64 bits 64-bits of the counter block are set to
   record sequence number, and the remaining 16 bits 16-bits function as the
   block counter.  The least significant bit of 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.  This counter value one, and is incremented by one to generate subsequent counter
   blocks, each resulting in another 128 bits 128-bits of key stream.

   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 whenver 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 TLS/
   DTLS record size
   of input to the record payload protection layer in TLS or DTLS
   (TLSCompressed.length) is 14 KB 2^14 + 1024 octets, and 16 bits of blk_ctr
   allow the generation of 1MB 2^20 octets (2^16 AES blocks) of keying
   material per record.

   The encryption of n plaintext blocks can be summarized as:

         FOR i := 1 to n-1 DO
           CT[i] := PT[i] XOR AES(CtrBlk)
           CtrBlk := CtrBlk + 1
         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 most significant bits.

   Decryption is similar.  The decryption of n ciphertext blocks can be
   summarized as:

         FOR i := 1 to n-1 DO
           PT[i] := CT[i] XOR AES(CtrBlk)
           CtrBlk := CtrBlk + 1
         PT[n] := CT[n] XOR TRUNC(AES(CtrBlk))

   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 record sequence number used for generating the counter
   block seq_num fields are extracted from initialized based on
   the corresponding values in a received record.

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 IVs IV's as the original

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 two a major drawbacks drawback when
   used in the TLS or DTLS protocol, without offering any significant
   benefit: (1) in both TLS and DTLS inclusion of such a tag would incur a
   bandwidth cost, (2) all TLS and DTLS associations have 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 which MUST never be re-used with different data.
      Note, however, that retransmitting the same record in DTLS is
   o  AES-CTR can be used to ensure 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

5.  Security Considerations

   See Section 7. 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 [2]. no
      concern in TLS/DTLS since all ciphersuites that support encryption
      also employ message integrity.

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 TLS Transport Layer Security (TLS)
        Protocol Version 1.1",
        draft-ietf-tls-rfc2246-bis-13 (work in progress), June 2005. RFC 4346, April 2006.

Authors' Addresses

   Nagendra Modadugu
   Stanford University
   353 Serra Mall
   Stanford, CA  94305


   Eric Rescorla
   Network Resonance
   2483 E. Bayshore Rd., #212
   Palo Alto, CA  94303


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

   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

Disclaimer of Validity

   This document and the information contained herein are provided on an

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.


   Funding for the RFC Editor function is currently provided by the
   Internet Society.