draft-ietf-tls-ctr-00.txt   draft-ietf-tls-ctr-01.txt 
Network Working Group N. Modadugu Network Working Group N. Modadugu
Internet-Draft Stanford University Internet-Draft Stanford University
Expires: August 30, 2006 E. Rescorla Expires: December 15, 2006 E. Rescorla
Network Resonance Network Resonance
February 26, 2006 June 13, 2006
AES Counter Mode Cipher Suites for TLS and DTLS AES Counter Mode Cipher Suites for TLS and DTLS
draft-ietf-tls-ctr-00.txt draft-ietf-tls-ctr-01.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 30, 2006. This Internet-Draft will expire on December 15, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
This document describes the use of the Advanced Encryption Standard This document describes the use of the Advanced Encryption Standard
(AES) Counter Mode for use as a Transport Layer Security (TLS) and (AES) Counter Mode for use as a Transport Layer Security (TLS) and
Datagram Transport Layer Security (DTLS) confidentiality mechanism. Datagram Transport Layer Security (DTLS) confidentiality mechanism.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions Used In This Document . . . . . . . . . . . . . 3 1.1. Conventions Used In This Document . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Encrypting Records with AES Counter Mode . . . . . . . . . . . 4 3. Encrypting Records with AES Counter Mode . . . . . . . . . . . 4
3.1. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1.1. AES Counter Mode . . . . . . . . . . . . . . . . . . . 4 3.1.1. Encryption . . . . . . . . . . . . . . . . . . . . . . 4
3.1.2. Decryption . . . . . . . . . . . . . . . . . . . . . . 5
3.1.3. Counter Block Construction . . . . . . . . . . . . . . 5
3.2. DTLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. DTLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.3. Padding . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.3. Padding . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.4. Session Resumption . . . . . . . . . . . . . . . . . . . . 6 3.4. Session Resumption . . . . . . . . . . . . . . . . . . . . 7
4. Design Rationale . . . . . . . . . . . . . . . . . . . . . . . 6 4. Design Rationale . . . . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
5.1. Maximum Key Lifetime . . . . . . . . . . . . . . . . . . . 7 5.1. Maximum Key Lifetime . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7. Normative References . . . . . . . . . . . . . . . . . . . . . 7 7. Normative References . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . . . . 9 Intellectual Property and Copyright Statements . . . . . . . . . . 10
1. Introduction 1. Introduction
Transport Layer Security [3] provides channel-oriented security for Transport Layer Security [3] provides channel-oriented security for
application layer protocols. In TLS, cryptographic algorithms are application layer protocols. In TLS, cryptographic algorithms are
specified in "Cipher Suites, which consist of a group of algorithms specified in "Cipher Suites, which consist of a group of algorithms
to be used together." to be used together."
Cipher suites supported by TLS are divided into stream and block Cipher suites supported by TLS are divided into stream and block
ciphers. Counter mode ciphers behave like stream ciphers, but are ciphers. Counter mode ciphers behave like stream ciphers, but are
skipping to change at page 3, line 33 skipping to change at page 3, line 33
compared to AES-CBC as used in TLS 1.1 and DTLS. 16 bytes are 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 saved from not having to transmit an explicit IV, and another 1-16
bytes are saved from the absence of the padding block. bytes are saved from the absence of the padding block.
Random Access: AES-CTR is capable of random access within the key Random Access: AES-CTR is capable of random access within the key
stream. For DTLS, this implies that records can be processed out stream. For DTLS, this implies that records can be processed out
of order without dependency on packet arrival order, and also of order without dependency on packet arrival order, and also
without keystream buffering. without keystream buffering.
Parallelizable: As a consequence of AES-CTR supporting random access Parallelizable: As a consequence of AES-CTR supporting random access
within the key stream, the cipher can be easily parallelized. 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 Multiple mode support: AES-CTR support in TLS/DTLS allows for
implementator to support both a stream (CTR) and block (CBC) implementator to support both a stream (CTR) and block (CBC)
cipher through the implemention of a single symmetric algorithm. cipher through the implementation of a single symmetric algorithm.
1.1. Conventions Used In This Document 1.1. Conventions Used In This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [1]. document are to be interpreted as described in [1].
2. Terminology 2. Terminology
This document reuses some terminology introduced in [2] and [3]. The This document reuses some terminology introduced in [2] and [3]. The
term 'counter block' has the same meaning as used in RFC3686, term 'counter block' has the same meaning as used in [2]. However,
however, the term 'IV', in this document, holds the meaning defined the term 'IV' in this document, holds the meaning defined in [3].
in [3].
3. Encrypting Records with AES Counter Mode 3. Encrypting Records with AES Counter Mode
The use of AES-CTR in TLS/DTLS turns out to be fairly AES-CTR is functionally equivalent to a stream cipher; it generates a
straightforward, with the additional benefit that the method of pseudo-random cipher stream that is XORed into the plaintext to form
operation in TLS/DTLS mimics, to a large extent, that in IPsec. The ciphertext.
primary constraint on the use of counter mode ciphers is that for a
given key, a counter block value MUST never be used more than once
(see Section 7 of [2] for a detailed explanation.) In TLS/DTLS
ensuring that counter block values never repeat during a given
session is straightforward as explained in the following sections.
SSL/TLS 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 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.)
The cipher stream generated by AES-CTR is much like the cipher stream It should be noted that although the client and server use the same
generated by stream ciphers like RC4. For reasons described in sequence number space, they use different write keys and counter
Section 7 of [2], a counter block value MUST never be used more than blocks.
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 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.
AES counter mode requires the encryptor and decryptor to share a per- This constraint is required because a given key and counter block
record unique counter block. A given counter block MUST never be value completely specify a portion of the cipher stream. Hence, a
used more than once with the same key. For a more in-depth particular counter block value when used (with a given key) to
discussion of AES-CTR operation, refer to Section 2.1 of [2]. The generate more than one ciphertext leaks information about the
following description of AES-CTR mode has been adapted from [2]. corresponding plaintexts. For a detailed explanation, see Section 7
of [2].
To encrypt a payload with AES-CTR, the encryptor partitions the Given this constraint, the challenge then is in the design of the
plaintext, PT, into 128-bit blocks. The final block MAY be less than counter block. We describe the construction of the counter block in
128 bits. the following sections.
PT = PT[1] PT[2] ... PT[n] TLS/DTLS records encrypted with AES-CTR mode use a
CipherSpec.cipher_type of GenericStreamCipher (Section 6.2.3 of [3]).
Each PT block is XORed with a block of the key stream to generate the 3.1. TLS
ciphertext, CT. The AES encryption of each counter block results in
128 bits of key stream.
To construct the counter block, the most significant 48 bits of the AES counter mode requires the encryptor and decryptor to share a per-
counter block are set to the 48 low order bits of the client_write_IV record unique counter block. As previously stated, a given counter
(for the half-duplex stream originated by the client) or the 48 low block MUST never be used more than once with the same key. The
order bits of the server_write_IV (for the half-duplex stream following description of AES-CTR mode has been adapted from [2].
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 least significant bit of the
counter block is initially set to one. This counter value is
incremented by one to generate subsequent counter blocks, each
resulting in another 128 bits of key stream.
struct { 3.1.1. Encryption
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 To encrypt a payload with AES-CTR, the encryptor sequentially
for each record processed, while the IV is initialized immediately partitions the plaintext (PT) into 128-bit blocks. The final PT
after a key calculation is made (key calculations are made whenver a block MAY be less than 128-bits. This partitioning is denoted as:
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/ PT = PT[1] PT[2] ... PT[n]
DTLS record size is 14 KB and 16 bits of blk_ctr allow the generation In order to encrypt, each PT block is XORed with a block of the key
of 1MB of keying material per record. 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 of n plaintext blocks can be summarized as: The encryption operation is performed as follows:
FOR i := 1 to n-1 DO FOR i := 1 to n-1 DO
CT[i] := PT[i] XOR AES(CtrBlk) CT[i] := PT[i] XOR AES(CtrBlk)
CtrBlk := CtrBlk + 1 CtrBlk := CtrBlk + 1
END END
CT[n] := PT[n] XOR TRUNC(AES(CtrBlk)) CT[n] := PT[n] XOR TRUNC(AES(CtrBlk))
The AES() function performs AES encryption with the fresh key. The AES() function performs AES encryption with the fresh key.
The TRUNC() function truncates the output of the AES encrypt The TRUNC() function truncates the output of the AES encrypt
operation to the same length as the final plaintext block, returning operation to the same length as the final plaintext block, returning
the most significant bits. the leftmost bits.
Decryption is similar. The decryption of n ciphertext blocks can be 3.1.2. Decryption
summarized as:
Decryption is similar to encryption. The decryption of n ciphertext
blocks is performed as follows:
FOR i := 1 to n-1 DO FOR i := 1 to n-1 DO
PT[i] := CT[i] XOR AES(CtrBlk) PT[i] := CT[i] XOR AES(CtrBlk)
CtrBlk := CtrBlk + 1 CtrBlk := CtrBlk + 1
END END
PT[n] := CT[n] XOR TRUNC(AES(CtrBlk)) PT[n] := CT[n] XOR TRUNC(AES(CtrBlk))
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 The AES() and TRUNC() operate identically as in the case of
calculation phase, and the record sequence number is implicit. 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.
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 3.2. DTLS
The operation of AES-CTR in DTLS is the same as in TLS, with the only 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. difference being the inclusion of the epoch in the counter block.
The counter block is constructed as follows for DTLS: The counter block is constructed as follows for DTLS:
struct { struct {
case client: case client:
uint48 client_write_IV; // low order 48-bits uint48 client_write_IV; // low order 48-bits
case server: case server:
uint48 server_write_IV; // low order 48-bits uint48 server_write_IV; // low order 48-bits
uint16 epoch; uint16 epoch;
uint48 seq_num; uint48 seq_num;
uint16 blk_ctr; uint16 blk_ctr;
} CtrBlk; } CtrBlk;
The epoch and record sequence number used for generating the counter For decryption, the epoch and seq_num fields are initialized based on
block are extracted from the received record. the corresponding values in a received record.
3.3. Padding 3.3. Padding
Stream ciphers in TLS and DTLS do not require plaintext padding. Stream ciphers in TLS and DTLS do not require plaintext padding.
3.4. Session Resumption 3.4. Session Resumption
TLS supports session resumption via caching of session ID's and TLS supports session resumption via caching of session ID's and
connection parameters on both client and server. While resumed connection parameters on both client and server. While resumed
sessions use the same master secret that was originally negotiated, a sessions use the same master secret that was originally negotiated, a
resumed session uses new keys that are derived, in part, using fresh resumed session uses new keys that are derived, in part, using fresh
client_random and server_random parameters. As a result resumed client_random and server_random parameters. As a result resumed
sessions do not use the same encryption keys or IVs as the original sessions do not use the same encryption keys or IV's as the original
session. session.
4. Design Rationale 4. Design Rationale
An alternate design for the construction of the counter block would An alternate design for the construction of the counter block would
be the use of an explicit 'record tag' (as a substitute for the be the use of an explicit 'record tag' (as a substitute for the
implicit record sequence number) that could potentially be generated implicit record sequence number) that could potentially be generated
via an LFSR. Such a design, however, suffers two major drawbacks via an LFSR. Such a design, however, suffers a major drawback when
when used in the TLS or DTLS protocol, without offering any used in the TLS or DTLS protocol, without offering any significant
significant benefit: (1) in both TLS and DTLS inclusion of such a tag benefit: in both TLS and DTLS inclusion of such a tag would incur a
would incur a bandwidth cost, (2) all TLS and DTLS associations have bandwidth cost.
per-record sequence numbers which can be used to ensure counter
uniqueness.
5. Security Considerations 5. Security Considerations
See Section 7. of [2]. 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.
5.1. Maximum Key Lifetime 5.1. Maximum Key Lifetime
TLS/DTLS sessions employing AES-CTR MUST be renegotiated before TLS/DTLS sessions employing AES-CTR MUST be renegotiated before
sequence numbers repeat. In the case of TLS, this implies a maximum 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 of 2^64 records per session, while for DTLS the maximum is 2^48 (with
the remaining bits reserved for epoch.) the remaining bits reserved for epoch.)
6. IANA Considerations 6. IANA Considerations
skipping to change at page 7, line 44 skipping to change at page 8, line 39
7. Normative References 7. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[2] Housley, R., "Using Advanced Encryption Standard (AES) Counter [2] Housley, R., "Using Advanced Encryption Standard (AES) Counter
Mode With IPsec Encapsulating Security Payload (ESP)", RFC 3686, Mode With IPsec Encapsulating Security Payload (ESP)", RFC 3686,
January 2004. January 2004.
[3] Dierks, T. and E. Rescorla, "The TLS Protocol Version 1.1", [3] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)
draft-ietf-tls-rfc2246-bis-13 (work in progress), June 2005. Protocol Version 1.1", RFC 4346, April 2006.
Authors' Addresses Authors' Addresses
Nagendra Modadugu Nagendra Modadugu
Stanford University Stanford University
353 Serra Mall 353 Serra Mall
Stanford, CA 94305 Stanford, CA 94305
USA USA
Email: nagendra@cs.stanford.edu Email: nagendra@cs.stanford.edu
 End of changes. 31 change blocks. 
100 lines changed or deleted 142 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/