draft-ietf-secsh-newmodes-05.txt   rfc4344.txt 
Network Working Group M. Bellare Network Working Group M. Bellare
Internet-Draft T. Kohno Request for Comments: 4344 T. Kohno
Expires: February 18, 2006 UC San Diego Category: Standards Track UC San Diego
C. Namprempre C. Namprempre
Thammasat University Thammasat University
August 18, 2005 January 2006
SSH Transport Layer Encryption Modes
draft-ietf-secsh-newmodes-05.txt
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of Section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with
RFC 3668.
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 The Secure Shell (SSH) Transport Layer Encryption Modes
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on February 18, 2006. Status of This Memo
By submitting this Internet-Draft, each author represents that any This document specifies an Internet standards track protocol for the
applicable patent or other IPR claims of which he or she is aware Internet community, and requests discussion and suggestions for
have been or will be disclosed, and any of which he or she becomes improvements. Please refer to the current edition of the "Internet
aware will be disclosed, in accordance with Section 6 of BCP 79. Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved. Copyright (C) The Internet Society (2006).
Abstract Abstract
Researchers have discovered that the authenticated encryption portion Researchers have discovered that the authenticated encryption portion
of the current SSH Transport Protocol is vulnerable to several of the current SSH Transport Protocol is vulnerable to several
attacks. attacks.
This document describes new symmetric encryption methods for the SSH This document describes new symmetric encryption methods for the
Transport Protocol and gives specific recommendations on how Secure Shell (SSH) Transport Protocol and gives specific
frequently SSH implementations should rekey. recommendations on how frequently SSH implementations should rekey.
In a paper at the Ninth ACM Conference on Computer and Communications
Security, Bellare, Kohno, and Namprempre prove that if an SSH
application implements the modifications described in this document,
then the symmetric cryptographic portion of that application will
provably resist chosen-plaintext, chosen-ciphertext, reaction-based
privacy, and integrity/authenticity attacks.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction ....................................................2
2. Conventions Used in This Document . . . . . . . . . . . . . . 3 2. Conventions Used in This Document ...............................2
3. Rekeying . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Rekeying ........................................................2
3.1 First Rekeying Recommendation . . . . . . . . . . . . . . . . 3 3.1. First Rekeying Recommendation ..............................3
3.2 Second Rekeying Recommendation . . . . . . . . . . . . . . . . 4 3.2. Second Rekeying Recommendation .............................3
4. Encryption Modes . . . . . . . . . . . . . . . . . . . . . . . 4 4. Encryption Modes ................................................3
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations .............................................6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations .........................................6
6.1 Rekeying Considerations . . . . . . . . . . . . . . . . . . . 7 6.1. Rekeying Considerations ....................................7
6.2 Encryption Method Considerations . . . . . . . . . . . . . . . 9 6.2. Encryption Method Considerations ...........................8
Normative References . . . . . . . . . . . . . . . . . . . . . 9 Normative References ...............................................9
Non-Normative References . . . . . . . . . . . . . . . . . . . 10 Informative References ............................................10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11
Intellectual Property Statement . . . . . . . . . . . . . . . 12
Disclaimer of Validity . . . . . . . . . . . . . . . . . . . . 12
Copyright Statement . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
The symmetric portion of the SSH Transport Protocol was designed to The symmetric portion of the SSH Transport Protocol was designed to
provide both privacy and integrity of encapsulated data. Researchers provide both privacy and integrity of encapsulated data. Researchers
([DAI,BKN1,BKN2]) have, however, identified several security problems ([DAI,BKN1,BKN2]) have, however, identified several security problems
with the symmetric portion of the SSH Transport Protocol as described with the symmetric portion of the SSH Transport Protocol, as
in [SSH-TRANS]. For example, the encryption mode specified in [SSH- described in [RFC4253]. For example, the encryption mode specified
TRANS] is vulnerable to a chosen-plaintext privacy attack. in [RFC4253] is vulnerable to a chosen-plaintext privacy attack.
Additionally, if not rekeyed frequently enough, the SSH Transport Additionally, if not rekeyed frequently enough, the SSH Transport
Protocol may leak information about payload data. This latter Protocol may leak information about payload data. This latter
property is true regardless of what encryption mode is used. property is true regardless of what encryption mode is used.
In [BKN1,BKN2] Bellare, Kohno, and Namprempre show how to modify the In [BKN1,BKN2], Bellare, Kohno, and Namprempre show how to modify the
symmetric portion of the SSH Transport Protocol so that it provably symmetric portion of the SSH Transport Protocol so that it provably
preserves privacy and integrity against chosen-plaintext, chosen- preserves privacy and integrity against chosen-plaintext, chosen-
ciphertext, and reaction attacks. This document instantiates the ciphertext, and reaction attacks. This document instantiates the
recommendations described in [BKN1,BKN2]. recommendations described in [BKN1,BKN2].
2. Conventions Used in This Document 2. 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 [RFC2119]. document are to be interpreted as described in [RFC2119].
The used data types and terminology are specified in the architecture The used data types and terminology are specified in the architecture
document [SSH-ARCH]. document [RFC4251].
The SSH Transport Protocol is specified in the transport document The SSH Transport Protocol is specified in the transport document
[SSH-TRANS]. [RFC4253].
3. Rekeying 3. Rekeying
Section 9 of [SSH-TRANS] suggests that SSH implementations rekey Section 9 of [RFC4253] suggests that SSH implementations rekey after
after every gigabyte of transmitted data. [SSH-TRANS] does not, every gigabyte of transmitted data. [RFC4253] does not, however,
however, discuss all the problems that could arise if an SSH discuss all the problems that could arise if an SSH implementation
implementation does not rekey frequently enough. This section serves does not rekey frequently enough. This section serves to strengthen
to strengthen the suggestion in [SSH-TRANS] by giving firm upper the suggestion in [RFC4253] by giving firm upper bounds on the
bounds on the tolerable number of encryptions between rekeying tolerable number of encryptions between rekeying operations. In
operations. In Section 6 we discuss the motivation for these Section 6, we discuss the motivation for these rekeying
rekeying recommendations in more detail. recommendations in more detail.
This section makes two recommendations. Informally, the first This section makes two recommendations. Informally, the first
recommendation is intended to protects against possible information recommendation is intended to protect against possible information
leakage through the MAC tag and the second recommendation is intended leakage through the MAC tag, and the second recommendation is
to protect against possible information leakage through the block intended to protect against possible information leakage through the
cipher. Note that, depending on the block length of the underlying block cipher. Note that, depending on the block length of the
block cipher and the length of the encrypted packets, the first underlying block cipher and the length of the encrypted packets, the
recommendation may supersede the second recommendation, or vice first recommendation may supersede the second recommendation, or vice
versa. versa.
3.1 First Rekeying Recommendation 3.1. First Rekeying Recommendation
Because of possible information leakage through the MAC tag, SSH Because of possible information leakage through the MAC tag, SSH
implementations SHOULD rekey at least once every 2**32 outgoing implementations SHOULD rekey at least once every 2**32 outgoing
packets. More explicitly, after a key exchange an SSH implementation packets. More explicitly, after a key exchange, an SSH
SHOULD NOT send more than 2**32 packets before rekeying again. implementation SHOULD NOT send more than 2**32 packets before
rekeying again.
SSH implementations SHOULD also attempt to rekey before receiving SSH implementations SHOULD also attempt to rekey before receiving
more than 2**32 packets since the last rekey operation. The more than 2**32 packets since the last rekey operation. The
preferred way to do this is to rekey after receiving more than 2**31 preferred way to do this is to rekey after receiving more than 2**31
packets since the last rekey operation. packets since the last rekey operation.
3.2 Second Rekeying Recommendation 3.2. Second Rekeying Recommendation
Because of a birthday property of block ciphers and some modes of Because of a birthday property of block ciphers and some modes of
operation, implementations must be careful not to encrypt too many operation, implementations must be careful not to encrypt too many
blocks with the same encryption key. blocks with the same encryption key.
Let L be the block length (in bits) of an SSH encryption method's Let L be the block length (in bits) of an SSH encryption method's
block cipher (e.g., 128 for AES). If L is at least 128 then, after block cipher (e.g., 128 for AES). If L is at least 128, then, after
rekeying, an SSH implementation SHOULD NOT encrypt more than 2**(L/4) rekeying, an SSH implementation SHOULD NOT encrypt more than 2**(L/4)
blocks before rekeying again. If L is at least 128, then SSH blocks before rekeying again. If L is at least 128, then SSH
implementations should also attempt to force a rekey before receiving implementations should also attempt to force a rekey before receiving
more than 2**(L/4) blocks. If L is less than 128 (which is the case more than 2**(L/4) blocks. If L is less than 128 (which is the case
for older ciphers such as 3DES, Blowfish, CAST-128, and IDEA), then, for older ciphers such as 3DES, Blowfish, CAST-128, and IDEA), then,
although it may be too expensive to rekey every 2**(L/4) blocks, it although it may be too expensive to rekey every 2**(L/4) blocks, it
is still advisable for SSH implementations to follow the original is still advisable for SSH implementations to follow the original
recommendation in [SSH-TRANS]: rekey at least once every gigabyte of recommendation in [RFC4253]: rekey at least once for every gigabyte
transmitted data. of transmitted data.
Note that if L is less than or equal to 128, then the recommendation Note that if L is less than or equal to 128, then the recommendation
in this subsection supersedes the recommendation in Section 3.1. If in this subsection supersedes the recommendation in Section 3.1. If
an SSH implementation uses a block cipher with a larger block size an SSH implementation uses a block cipher with a larger block size
(e.g., Rijndael with 256-bit blocks), then the recommendations in the (e.g., Rijndael with 256-bit blocks), then the recommendations in
above paragraph may supersede the recommendations in this paragraph Section 3.1 may supersede the recommendations in this subsection
(depending on the lengths of the packets). (depending on the lengths of the packets).
4. Encryption Modes 4. Encryption Modes
This document describes new encryption methods for use with the SSH This document describes new encryption methods for use with the SSH
Transport Protocol. These encryption methods are in addition to the Transport Protocol. These encryption methods are in addition to the
encryption methods described in Section 6.3 of [SSH-TRANS]. encryption methods described in Section 6.3 of [RFC4253].
Recall from [SSH-TRANS] that the encryption methods in each direction Recall from [RFC4253] that the encryption methods in each direction
of an SSH connection MUST run independently of each other and that, of an SSH connection MUST run independently of each other and that,
when encryption is in effect, the packet length, padding length, when encryption is in effect, the packet length, padding length,
payload, and padding fields of each packet MUST be encrypted with the payload, and padding fields of each packet MUST be encrypted with the
chosen method. Further recall that the total length of the chosen method. Further recall that the total length of the
concatenation of the packet length, padding length, payload, and concatenation of the packet length, padding length, payload, and
padding MUST be a multiple of the cipher's block size when the padding MUST be a multiple of the cipher's block size when the
cipher's block size is greater than or equal to 8 bytes (which is the cipher's block size is greater than or equal to 8 bytes (which is the
case for all of the following methods). case for all of the following methods).
This document describes the following new methods: This document describes the following new methods:
skipping to change at page 5, line 16 skipping to change at page 4, line 28
with 128-bit key with 128-bit key
aes192-ctr RECOMMENDED AES with 192-bit key aes192-ctr RECOMMENDED AES with 192-bit key
aes256-ctr RECOMMENDED AES with 256-bit key aes256-ctr RECOMMENDED AES with 256-bit key
3des-ctr RECOMMENDED Three-key 3DES in SDCTR mode 3des-ctr RECOMMENDED Three-key 3DES in SDCTR mode
blowfish-ctr OPTIONAL Blowfish in SDCTR mode blowfish-ctr OPTIONAL Blowfish in SDCTR mode
twofish128-ctr OPTIONAL Twofish in SDCTR mode, twofish128-ctr OPTIONAL Twofish in SDCTR mode,
with 128-bit key with 128-bit key
twofish192-ctr OPTIONAL Twofish with 192-bit key twofish192-ctr OPTIONAL Twofish with 192-bit key
twofish256-ctr OPTIONAL Twofish with 256-bit key twofish256-ctr OPTIONAL Twofish with 256-bit key
serpent128-ctr OPTIONAL Serpent in SDCTR mode, with serpent128-ctr OPTIONAL Serpent in SDCTR mode, with
with 128-bit key 128-bit key
serpent192-ctr OPTIONAL Serpent with 192-bit key serpent192-ctr OPTIONAL Serpent with 192-bit key
serpent256-ctr OPTIONAL Serpent with 256-bit key serpent256-ctr OPTIONAL Serpent with 256-bit key
idea-ctr OPTIONAL IDEA in SDCTR mode idea-ctr OPTIONAL IDEA in SDCTR mode
cast128-ctr OPTIONAL CAST-128 in SDCTR mode, cast128-ctr OPTIONAL CAST-128 in SDCTR mode,
with 128-bit key with 128-bit key
The label <cipher>-ctr means that the block cipher <cipher> is to be The label <cipher>-ctr indicates that the block cipher <cipher> is to
used in "stateful-decryption counter" (SDCTR) mode. Let L be the be used in "stateful-decryption counter" (SDCTR) mode. Let L be the
block length of <cipher> in bits. In stateful-decryption counter block length of <cipher> in bits. In stateful-decryption counter
mode both the sender and the receiver maintain an internal L-bit mode, both the sender and the receiver maintain an internal L-bit
counter X. The initial value of X should be the initial IV (as counter X. The initial value of X should be the initial IV (as
computed in Section 7.2 of [SSH-TRANS]) interpreted as an L-bit computed in Section 7.2 of [RFC4253]) interpreted as an L-bit
unsigned integer in network-byte-order. If X=(2**L)-1, then unsigned integer in network-byte-order. If X=(2**L)-1, then
"increment X" has the traditional semantics of "set X to 0." We use "increment X" has the traditional semantics of "set X to 0." We use
the notation <X> to mean "convert X to an L-bit string in network- the notation <X> to mean "convert X to an L-bit string in network-
byte-order." Naturally, implementations may differ in how the byte-order." Naturally, implementations may differ in how the
internal value X is stored. For example, implementations may store X internal value X is stored. For example, implementations may store X
as multiple unsigned 32-bit counters. as multiple unsigned 32-bit counters.
To encrypt a packet P=P1||P2||...||Pn (where P1, P2, ..., Pn are each To encrypt a packet P=P1||P2||...||Pn (where P1, P2, ..., Pn are each
blocks of length L), the encryptor first encrypts <X> with <cipher> blocks of length L), the encryptor first encrypts <X> with <cipher>
to obtain a block B1. The block B1 is then XORed with P1 to generate to obtain a block B1. The block B1 is then XORed with P1 to generate
the ciphertext block C1. The counter X is then incremented and the the ciphertext block C1. The counter X is then incremented, and the
process is repeated for each subsequent block in order to generate process is repeated for each subsequent block in order to generate
the entire ciphertext C=C1||C2||...||Cn corresponding to the packet the entire ciphertext C=C1||C2||...||Cn corresponding to the packet
P. Note that the counter X is not included in the ciphertext. Also P. Note that the counter X is not included in the ciphertext. Also
note that the keystream can be pre-computed and that encryption is note that the keystream can be pre-computed and that encryption is
parallelizable. parallelizable.
To decrypt a ciphertext C=C1||C2||...||Cn, the decryptor (who also To decrypt a ciphertext C=C1||C2||...||Cn, the decryptor (who also
maintains its own copy of X), first encrypts its copy of <X> with maintains its own copy of X) first encrypts its copy of <X> with
<cipher> to generate a block B1 and then XORs B1 to C1 to get P1. <cipher> to generate a block B1 and then XORs B1 to C1 to get P1.
The decryptor then increments its copy of the counter X and repeats The decryptor then increments its copy of the counter X and repeats
the above process for each block to obtain the plaintext packet the above process for each block to obtain the plaintext packet
P=P1||P2||...||Pn. As before, the keystream can be pre-computed and P=P1||P2||...||Pn. As before, the keystream can be pre-computed, and
decryption is parallelizable. decryption is parallelizable.
The "aes128-ctr" method uses AES (the Advanced Encryption Standard, The "aes128-ctr" method uses AES (the Advanced Encryption Standard,
formerly Rijndael) with 128-bit keys [AES]. The block size is 16 formerly Rijndael) with 128-bit keys [AES]. The block size is 16
bytes. bytes.
At this time, it appears likely that a future specification will
promote aes128-ctr to be REQUIRED; implementation of this
algorithm is very strongly encouraged.
The "aes192-ctr" method uses AES with 192-bit keys. The "aes192-ctr" method uses AES with 192-bit keys.
The "aes256-ctr" method uses AES with 256-bit keys. The "aes256-ctr" method uses AES with 256-bit keys.
The "3des-ctr" method uses three-key triple-DES (encrypt-decrypt- The "3des-ctr" method uses three-key triple-DES (encrypt-decrypt-
encrypt), where the first 8 bytes of the key are used for the first encrypt), where the first 8 bytes of the key are used for the first
encryption, the next 8 bytes for the decryption, and the following 8 encryption, the next 8 bytes for the decryption, and the following 8
bytes for the final encryption. This requires 24 bytes of key data bytes for the final encryption. This requires 24 bytes of key data
(of which 168 bits are actually used). The block size is 8 bytes. (of which 168 bits are actually used). The block size is 8 bytes.
This algorithm is defined in [DES]. This algorithm is defined in [DES].
The "blowfish-ctr" method uses Blowfish with 256-bit keys [SCHNEIER]. The "blowfish-ctr" method uses Blowfish with 256-bit keys [SCHNEIER].
The block size is 8 bytes. (Note that "blowfish-cbc" from [SSH- The block size is 8 bytes. (Note that "blowfish-cbc" from [RFC4253]
TRANS] uses 128-bit keys.) uses 128-bit keys.)
The "twofish128-ctr" method uses Twofish with 128-bit keys [TWOFISH]. The "twofish128-ctr" method uses Twofish with 128-bit keys [TWOFISH].
The block size is 16 bytes. The block size is 16 bytes.
The "twofish192-ctr" method uses Twofish with 192-bit keys. The "twofish192-ctr" method uses Twofish with 192-bit keys.
The "twofish256-ctr" method uses Twofish with 256-bit keys. The "twofish256-ctr" method uses Twofish with 256-bit keys.
The "serpent128-ctr" method uses the Serpent block cipher [SERPENT] The "serpent128-ctr" method uses the Serpent block cipher [SERPENT]
with 128-bit keys. The block size is 16 bytes. with 128-bit keys. The block size is 16 bytes.
skipping to change at page 6, line 46 skipping to change at page 6, line 15
The "serpent256-ctr" method uses Serpent with 256-bit keys. The "serpent256-ctr" method uses Serpent with 256-bit keys.
The "idea-ctr" method uses the IDEA cipher [SCHNEIER]. The block The "idea-ctr" method uses the IDEA cipher [SCHNEIER]. The block
size is 8 bytes. size is 8 bytes.
The "cast128-ctr" method uses the CAST-128 cipher with 128-bit keys The "cast128-ctr" method uses the CAST-128 cipher with 128-bit keys
[RFC2144]. The block size is 8 bytes. [RFC2144]. The block size is 8 bytes.
5. IANA Considerations 5. IANA Considerations
The twelve encryption algorithm names defined in Section 4 are to be The thirteen encryption algorithm names defined in Section 4 have
added to the Secure Shell Encryption Algorithm Name registry been added to the Secure Shell Encryption Algorithm Name registry
established by Section 4.11.1 of [SSH-IANA]. established by Section 4.11.1 of [RFC4250].
6. Security Considerations 6. Security Considerations
This document describes additional encryption methods and This document describes additional encryption methods and
recommendations for the SSH Transport Protocol [SSH-TRANS]. recommendations for the SSH Transport Protocol [RFC4253].
[BKN1,BKN2] prove that if an SSH application incorporates the methods [BKN1,BKN2] prove that if an SSH application incorporates the methods
and recommendations described in this document, then the symmetric and recommendations described in this document, then the symmetric
cryptographic portion of that application will resist a large class cryptographic portion of that application will resist a large class
of privacy and integrity attacks. of privacy and integrity attacks.
This section is designed to help implementors understand the This section is designed to help implementors understand the
security-related motivations for, as well as possible consequences of security-related motivations for, as well as possible consequences of
deviating from, the methods and recommendations described in this deviating from, the methods and recommendations described in this
document. Additional motivation and discussion, as well as proofs of document. Additional motivation and discussion, as well as proofs of
security, appear in the research paper [BKN1,BKN2]. security, appear in the research papers [BKN1,BKN2].
Please note that the notion of "prove" in the context of [BKN1,BKN2] Please note that the notion of "prove" in the context of [BKN1,BKN2]
is that of practice-oriented reductionist security: if an attacker is is that of practice-oriented reductionist security: if an attacker is
able to break the symmetric portion of the SSH Transport Protocol able to break the symmetric portion of the SSH Transport Protocol
using a certain type of attack (e.g., a chosen-ciphertext attack), using a certain type of attack (e.g., a chosen-ciphertext attack),
then the attacker will also be able to break one of the transport then the attacker will also be able to break one of the transport
protocol's underlying components (e.g., the underlying block cipher protocol's underlying components (e.g., the underlying block cipher
or MAC). If we make the reasonable assumption that the underlying or MAC). If we make the reasonable assumption that the underlying
components (such as AES and HMAC-SHA1) are secure, then the attacker components (such as AES and HMAC-SHA1) are secure, then the attacker
against the symmetric portion of the SSH protocol cannot be very against the symmetric portion of the SSH protocol cannot be very
successful (since otherwise there would be a contradiction). Please successful (since otherwise there would be a contradiction). Please
see [BKN1,BKN2] for details. In particular, attacks are not see [BKN1,BKN2] for details. In particular, attacks are not
impossible; just extremely improbable (unless the building blocks, impossible, just extremely improbable (unless the building blocks,
like AES, are insecure). like AES, are insecure).
Note also that cryptography often plays only a small (but critical) Note also that cryptography often plays only a small (but critical)
role in an application's overall security. In the case of the SSH role in an application's overall security. In the case of the SSH
Transport Protocol, even though an application might implement the Transport Protocol, even though an application might implement the
symmetric portion of the SSH protocol exactly as described in this symmetric portion of the SSH protocol exactly as described in this
document, the application may still be vulnerable to non-protocol- document, the application may still be vulnerable to non-protocol-
based attacks (as an egregious example, an application might save based attacks (as an egregious example, an application might save
cryptographic keys in cleartext to an unprotected file). cryptographic keys in cleartext to an unprotected file).
Consequently, even though the methods described herein come with Consequently, even though the methods described herein come with
proofs of security, developers must still execute caution when proofs of security, developers must still execute caution when
developing applications that implement these methods. developing applications that implement these methods.
6.1 Rekeying Considerations 6.1. Rekeying Considerations
Section 3 of this document makes two rekeying recommendations: (1) Section 3 of this document makes two rekeying recommendations: (1)
rekey at least once every 2**32 packets and (2) rekey after a certain rekey at least once every 2**32 packets, and (2) rekey after a
number of encrypted blocks (e.g., 2**(L/4) blocks if the block certain number of encrypted blocks (e.g., 2**(L/4) blocks if the
cipher's block length L is at least 128 bits). The motivations for block cipher's block length L is at least 128 bits). The motivations
recommendations (1) and (2) are different, and we consider each for recommendations (1) and (2) are different, and we consider each
recommendation in turn. Briefly, (1) is designed to protect against recommendation in turn. Briefly, (1) is designed to protect against
information leakage through the SSH protocol's underlying MAC and (2) information leakage through the SSH protocol's underlying MAC, and
is designed to protect against information leakage through the SSH (2) is designed to protect against information leakage through the
protocol's underlying encryption scheme. Please note that, depending SSH protocol's underlying encryption scheme. Please note that,
on the encryption method's block length L and the number of blocks depending on the encryption method's block length L and the number of
encrypted per packet, recommendation (1) may supersede recommendation blocks encrypted per packet, recommendation (1) may supersede
(2) or vice versa. recommendation (2) or vice versa.
Recommendation (1) states that SSH implementations should rekey at Recommendation (1) states that SSH implementations should rekey at
least once every 2**32 packets. If more than 2**32 packets are least once every 2**32 packets. If more than 2**32 packets are
encrypted and MACed by the SSH Transport Protocol between rekeyings, encrypted and MACed by the SSH Transport Protocol between rekeyings,
then the SSH Transport Protocol may become vulnerable to replay and then the SSH Transport Protocol may become vulnerable to replay and
re-ordering attacks, meaning that an adversary may be able to re-ordering attacks. This means that an adversary may be able to
convince the receiver to accept the same message more than once or to convince the receiver to accept the same message more than once or to
accept messages out of order. Additionally, the underlying MAC may accept messages out of order. Additionally, the underlying MAC may
begin to leak information about the protocol's payload data. In more begin to leak information about the protocol's payload data. In more
detail, an adversary looks for a collision between the MACs detail, an adversary looks for a collision between the MACs
associated to two packets that were MACed with the same 32-bit associated to two packets that were MACed with the same 32-bit
sequence number (see Section 4.4 of [SSH-TRANS]); if a collision is sequence number (see Section 4.4 of [RFC4253]). If a collision is
found, then the payload data associated with those two ciphertexts is found, then the payload data associated with those two ciphertexts is
probably identical. Note that this problem occurs regardless of how probably identical. Note that this problem occurs regardless of how
secure the underlying encryption method is. Also note that although secure the underlying encryption method is. Also note that although
compressing payload data before encrypting and MACing and the use of compressing payload data before encrypting and MACing and the use of
random padding may reduce the risk of information leakage through the random padding may reduce the risk of information leakage through the
underlying MAC, compression and the use of random padding will not underlying MAC, compression and the use of random padding will not
prevent information leakage. Implementors who decide not to rekey at prevent information leakage. Implementors who decide not to rekey at
least once every 2**32 packets should understand these issues. These least once every 2**32 packets should understand these issues. These
issues are discussed further in [BKN1,BKN2]. issues are discussed further in [BKN1,BKN2].
One alternative to recommendation (1) would be to make the SSH One alternative to recommendation (1) would be to make the SSH
Transport Protocol's sequence number more than 32 bits long. This Transport Protocol's sequence number more than 32 bits long. This
document does not suggest increasing the length of the sequence document does not suggest increasing the length of the sequence
number because doing so could hinder interoperability with older number because doing so could hinder interoperability with older
version of the SSH protocol. Another alternative to recommendation versions of the SSH protocol. Another alternative to recommendation
(1) would be to switch from basic HMAC to a another MAC, such as a (1) would be to switch from basic HMAC to a another MAC, such as a
MAC that has its own internal counter (because of the 32-bit counter MAC that has its own internal counter. Because of the 32-bit counter
already present in the protocol, such a counter would only need to be already present in the protocol, such a counter would only need to be
incremented once every 2**32 packets). incremented once every 2**32 packets.
Recommendation (2) states that SSH implementations should rekey Recommendation (2) states that SSH implementations should rekey
before encrypting more than 2**(L/4) blocks with the same key before encrypting more than 2**(L/4) blocks with the same key
(assuming L is at least 128). This recommendation is designed to (assuming L is at least 128). This recommendation is designed to
minimize the risk of birthday attacks against the encryption method's minimize the risk of birthday attacks against the encryption method's
underlying block cipher. For example, there is a theoretical privacy underlying block cipher. For example, there is a theoretical privacy
attack against stateful-decryption counter mode if an adversary is attack against stateful-decryption counter mode if an adversary is
allowed to encrypt approximately 2**(L/2) messages with the same key. allowed to encrypt approximately 2**(L/2) messages with the same key.
It is because of these birthday attacks that implementors are highly It is because of these birthday attacks that implementors are highly
encouraged to use secure block ciphers with large block lengths. encouraged to use secure block ciphers with large block lengths.
Additionally, recommendation (2) is designed to protect an encryptor Additionally, recommendation (2) is designed to protect an encryptor
from encrypting more than 2**L blocks with the same key. The from encrypting more than 2**L blocks with the same key. The
motivation here is that, if an encryptor were to use SDCTR mode to motivation here is that, if an encryptor were to use SDCTR mode to
encrypt more than 2**L blocks with the same key, then the encryptor encrypt more than 2**L blocks with the same key, then the encryptor
would reuse keystream, and the reuse of keystream can lead to serious would reuse keystream, and the reuse of keystream can lead to serious
privacy attacks [SCHNEIER]. privacy attacks [SCHNEIER].
6.2 Encryption Method Considerations 6.2. Encryption Method Considerations
Researchers have shown that the original CBC-based encryption methods Researchers have shown that the original CBC-based encryption methods
in [SSH-TRANS] are vulnerable to chosen-plaintext privacy attacks in [RFC4253] are vulnerable to chosen-plaintext privacy attacks
[DAI,BKN1,BKN2]. The new stateful-decryption counter mode encryption [DAI,BKN1,BKN2]. The new stateful-decryption counter mode encryption
methods described in Section 4 of this document were designed to be methods described in Section 4 of this document were designed to be
secure replacements to the original encryption methods described in secure replacements to the original encryption methods described in
[SSH-TRANS]. [RFC4253].
Many people shy away from counter mode-based encryption schemes Many people shy away from counter mode-based encryption schemes
because, when used incorrectly (such as when the keystream is allowed because, when used incorrectly (such as when the keystream is allowed
to repeat), counter mode can be very insecure. Fortunately, the to repeat), counter mode can be very insecure. Fortunately, the
common concerns with counter mode do not apply to SSH because of the common concerns with counter mode do not apply to SSH because of the
rekeying recommendations and because of the additional protection rekeying recommendations and because of the additional protection
provided by the transport protocol's MAC. This discussion is provided by the transport protocol's MAC. This discussion is
formalized with proofs of security in [BKN1,BKN2]. formalized with proofs of security in [BKN1,BKN2].
As an additional note, when one of the stateful-decryption counter As an additional note, when one of the stateful-decryption counter
mode encryption methods (Section 4) is used, then the padding mode encryption methods (Section 4) is used, then the padding
included in an SSH packet (Section 4 of [SSH-TRANS]) need not be (but included in an SSH packet (Section 4 of [RFC4253]) need not be (but
can still be) random. This eliminates the need to generate can still be) random. This eliminates the need to generate
cryptographically-secure pseudorandom bytes for each packet. cryptographically secure pseudorandom bytes for each packet.
One property of counter mode encryption is that it does not require One property of counter mode encryption is that it does not require
messages to be padded to a multiple of the block cipher's block that messages be padded to a multiple of the block cipher's block
length. Although not padding messages can reduce the protocol's length. Although not padding messages can reduce the protocol's
network consumption, this document requires padding to be a multiple network consumption, this document requires that padding be a
of the block cipher's block length in order to (1) not alter the multiple of the block cipher's block length in order to (1) not alter
packet description in [SSH-TRANS] and (2) not leak precise the packet description in [RFC4253] and (2) not leak precise
information about the length of the packet's payload data. (Although information about the length of the packet's payload data. (Although
there may be some network savings from padding to only 8-bytes even there may be some network savings from padding to only 8-bytes even
if the block cipher uses 16-byte blocks, because of (1) we do not if the block cipher uses 16-byte blocks, because of (1) we do not
make that recommendation here.) make that recommendation here.)
In addition to stateful-decryption counter mode, [BKN1,BKN2] describe In addition to stateful-decryption counter mode, [BKN1,BKN2] describe
other provably-secure encryption methods for use with the SSH other provably secure encryption methods for use with the SSH
Transport Protocol. The stateful-decryption counter mode methods in Transport Protocol. The stateful-decryption counter mode methods in
Section 4 are, however, the preferred alternatives to the insecure Section 4 are, however, the preferred alternatives to the insecure
methods in [SSH-TRANS] because stateful-decryption counter mode is methods in [RFC4253] because stateful-decryption counter mode is the
the most efficient (both in terms of network consumption and in terms most efficient (in terms of both network consumption and the number
of the number of required cryptographic operations per packet). of required cryptographic operations per packet).
Normative References Normative References
[AES] National Institute of Standards and Technology, [AES] National Institute of Standards and Technology, "Advanced
"Advanced Encryption Standard (AES)", Federal Encryption Standard (AES)", Federal Information
Information Processing Standards Publication 197, Processing Standards Publication 197, November 2001.
November 2001.
[DES] National Institute of Standards and Technology, [DES] National Institute of Standards and Technology, "Data
"Data Encryption Standard (DES)", Federal Information Encryption Standard (DES)", Federal Information
Processing Standards Publication 46-3, October 1999. Processing Standards Publication 46-3, October 1999.
[RFC2144] Adams, C., "The CAST-128 Encryption Algorithm", RFC [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
2144, May 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2144] Adams, C., "The CAST-128 Encryption Algorithm", RFC 2144,
May 1997.
[RFC4250] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH)
Protocol Assigned Numbers", RFC 4250, January 2006.
[RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Protocol Architecture", RFC 4251, January 2006.
[RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Transport Layer Protocol", RFC 4253, January 2006.
[SCHNEIER] Schneier, B., "Applied Cryptography Second Edition: [SCHNEIER] Schneier, B., "Applied Cryptography Second Edition:
Protocols algorithms and source in code in C", Wiley, Protocols algorithms and source in code in C", Wiley,
1996. 1996.
[SERPENT] Anderson, R., Biham, E., and Knudsen, L., "Serpent: A [SERPENT] Anderson, R., Biham, E., and Knudsen, L., "Serpent: A
proposal for the Advanced Encryption Standard", NIST proposal for the Advanced Encryption Standard", NIST AES
AES Proposal, 1998. Proposal, 1998.
[SSH-ARCH] Ylonen, T. and Lonvick, C., "SSH Protocol
Architecture", I-D
draft-ietf-secsh-architecture-22.txt, March 2005.
[SSH-IANA] Lehtinen, S. and Lonvick, C., "SSH Protocol Assigned
Numbers", I-D
draft-ietf-secsh-assignednumbers-12.txt, March 2005.
[SSH-TRANS] Ylonen, T. and Lonvick, C., "SSH Transport Layer
Protocol", I-D draft-ietf-secsh-transport-24.txt,
March 2005.
[TWOFISH] Schneier, B., et. al., "The Twofish Encryptions [TWOFISH] Schneier, B., et al., "The Twofish Encryptions Algorithm:
Algorithm: A 128-bit block cipher, 1st Edition", A 128-bit block cipher, 1st Edition", Wiley, 1999.
Wiley, 1999.
Non-Normative References Informative References
[BKN1] Bellare, M., Kohno, T., and Namprempre, C., [BKN1] Bellare, M., Kohno, T., and Namprempre, C.,
"Authenticated Encryption in SSH: Provably Fixing the "Authenticated Encryption in SSH: Provably Fixing the SSH
SSH Binary Packet Protocol", Ninth ACM Conference on Binary Packet Protocol", Ninth ACM Conference on Computer
Computer and Communications Security, 2002. and Communications Security, 2002.
[BKN2] Bellare, M., Kohno, T., and Namprempre, C., [BKN2] Bellare, M., Kohno, T., and Namprempre, C., "Breaking and
"Breaking and Provably Repairing the SSH Provably Repairing the SSH Authenticated Encryption
Authenticated Encryption Scheme: A Case Study of the Scheme: A Case Study of the Encode-then-Encrypt-and-MAC
Encode-then-Encrypt-and-MAC Paradigm", Paradigm", ACM Transactions on Information and System
ACM Transactions on Information and System Security, Security, 7(2), May 2004.
7(2), May 2004.
[DAI] Dai, W., "An Attack Against SSH2 Protocol", Email to [DAI] Dai, W., "An Attack Against SSH2 Protocol", Email to the
the ietf-ssh@netbsd.org email list, 2002. ietf-ssh@netbsd.org email list, 2002.
Authors' Addresses: Authors' Addresses
Mihir Bellare Mihir Bellare
Department of Computer Science and Engineering Department of Computer Science and Engineering
University of California at San Diego University of California at San Diego
9500 Gilman Drive, MC 0114 9500 Gilman Drive, MC 0404
La Jolla, CA 92093-0114 La Jolla, CA 92093-0404
Phone: +1 858-822-2977 Phone: +1 858-534-8833
EMail: mihir@cs.ucsd.edu EMail: mihir@cs.ucsd.edu
Tadayoshi Kohno Tadayoshi Kohno
Department of Computer Science and Engineering Department of Computer Science and Engineering
University of California at San Diego University of California at San Diego
9500 Gilman Drive, MC 0114 9500 Gilman Drive, MC 0404
La Jolla, CA 92093-0114 La Jolla, CA 92093-0404
Phone: +1 858-822-2977 Phone: +1 858-534-8833
EMail: tkohno@cs.ucsd.edu EMail: tkohno@cs.ucsd.edu
Chanathip Namprempre Chanathip Namprempre
Thammasat University Thammasat University
Faculty of Engineering Faculty of Engineering
Electrical Engineering Department Electrical Engineering Department
Rangsit Campus, Klong Luang Rangsit Campus, Klong Luang
Pathumthani, Thailand 12121 Pathumthani, Thailand 12121
EMail: meaw@alum.mit.edu EMail: meaw@alum.mit.edu
Intellectual Property Statement Full 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.
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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an 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 attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf- this standard. Please address the information to the IETF at
ipr@ietf.org. 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 (2005). 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.
Acknowledgments Acknowledgement
Mihir Bellare and Chanathip Namprempre were supported by NSF Grant Funding for the RFC Editor function is provided by the IETF
CCR-0098123, NSF Grant ANR-0129617 and an IBM Faculty Partnership Administrative Support Activity (IASA).
Development Award. Tadayoshi Kohno was supported by a National
Defense Science and Engineering Graduate Fellowship and an IBM Ph.D.
Fellowship.
 End of changes. 70 change blocks. 
204 lines changed or deleted 168 lines changed or added

This html diff was produced by rfcdiff 1.28, available from http://www.levkowetz.com/ietf/tools/rfcdiff/