draft-ietf-secsh-newmodes-00.txt   draft-ietf-secsh-newmodes-01.txt 
Network Working Group M. Bellare Network Working Group M. Bellare
Internet-Draft T. Kohno Internet-Draft T. Kohno
Expires: September 20, 2003 UC San Diego Expires: April 10, 2004 UC San Diego
C. Namprempre C. Namprempre
Thammasat University Thammasat University
March 20, 2003 October 10, 2003
SSH Transport Layer Encryption Modes SSH Transport Layer Encryption Modes
draft-ietf-secsh-newmodes-00.txt draft-ietf-secsh-newmodes-01.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
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 September 20, 2003. This Internet-Draft will expire on April 10, 2004.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract Abstract
Researchers have recently discovered that the authenticated Researchers have recently discovered that the authenticated
encryption portion of the current SSH Transport Protocol is encryption portion of the current SSH Transport Protocol is
vulnerable to several attacks. vulnerable to several attacks.
This document describes new symmetric encryption methods for the SSH This document describes new symmetric encryption methods for the SSH
Transport Protocol and gives specific recommendations on how Transport Protocol and gives specific recommendations on how
Internet Draft Month, Year
frequently SSH implementations should rekey. frequently SSH implementations should rekey.
Bellare, Kohno, and Namprempre [ACM CCS 2002] prove that if an SSH Bellare, Kohno, and Namprempre [ACM CCS 2002] prove that if an SSH
application implements the modifications described in this document, application implements the modifications described in this document,
then the symmetric cryptographic portion of that application will then the symmetric cryptographic portion of that application will
provably resist chosen-plaintext, chosen-ciphertext, reaction-based provably resist chosen-plaintext, chosen-ciphertext, reaction-based
privacy and integrity/authenticity attacks. privacy and integrity/authenticity attacks.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . 2 2. Conventions Used in This Document . . . . . . . . . . . . . . 2
3. Rekeying . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Rekeying . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1 First Rekeying Recommendation . . . . . . . . . . . . . . . . 3 3.1 First Rekeying Recommendation . . . . . . . . . . . . . . . . 3
3.2 Second Rekeying Recommendation . . . . . . . . . . . . . . . . 3 3.2 Second Rekeying Recommendation . . . . . . . . . . . . . . . . 3
4. Encryption Modes . . . . . . . . . . . . . . . . . . . . . . . 4 4. Encryption Modes . . . . . . . . . . . . . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
5.1 Rekeying Considerations . . . . . . . . . . . . . . . . . . . 7 5.1 Rekeying Considerations . . . . . . . . . . . . . . . . . . . 7
5.2 Encryption Method Considerations . . . . . . . . . . . . . . . 8 5.2 Encryption Method Considerations . . . . . . . . . . . . . . . 8
References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Normative References . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10 Non-Normative References . . . . . . . . . . . . . . . . . . . 9
Authorsどヨ Addresses . . . . . . . . . . . . . . . . . . . . . . 10
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 10 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 10
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,BKN]) have, however, recently identified several security ([DAI,BKN]) have, however, recently identified several security
problems with the symmetric portion of the SSH Transport Protocol as problems with the symmetric portion of the SSH Transport Protocol as
described in [SSH-TRANS]. For example, the encryption mode specified described in [SSH-TRANS]. For example, the encryption mode specified
in [SSH-TRANS] is vulnerable to a chosen-plaintext privacy attack. in [SSH-TRANS] is vulnerable to a chosen-plaintext privacy attack.
skipping to change at page 3, line 4 skipping to change at page 3, line 6
ciphertext, and reaction attacks. This document instantiates the ciphertext, and reaction attacks. This document instantiates the
recommendations described in [BKN]. recommendations described in [BKN].
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
Internet Draft Month, Year
document [SSH-ARCH]. document [SSH-ARCH].
The SSH Transport Protocol is specified in the transport document The SSH Transport Protocol is specified in the transport document
[SSH-TRANS]. [SSH-TRANS].
3. Rekeying 3. Rekeying
Section 7 of [SSH-TRANS] suggests that SSH implementations rekey Section 7 of [SSH-TRANS] suggests that SSH implementations rekey
after every gigabyte of transmitted data. [SSH-TRANS] does not, after every gigabyte of transmitted data. [SSH-TRANS] does not,
however, discuss all the problems that could arise if an SSH however, discuss all the problems that could arise if an SSH
skipping to change at page 3, line 50 skipping to change at page 3, line 49
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 (eg, 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
Internet Draft Month, Year
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 [SSH-TRANS]: rekey at least once every gigabyte of
transmitted data. 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
(eg, Rijndael with 256-bit blocks), then the recommendations in the (e.g., Rijndael with 256-bit blocks), then the recommendations in the
above paragraph may supersede the recommendations in this paragraph above paragraph may supersede the recommendations in this paragraph
(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 4.3 of [SSH-TRANS]. encryption methods described in Section 4.3 of [SSH-TRANS].
Recall from [SSH-TRANS] that the encryption methods in each direction Recall from [SSH-TRANS] 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:
aes128-ctr RECOMMENDED AES (Rijndael) in SDCTR mode, aes128-ctr RECOMMENDED AES (Rijndael) in SDCTR mode,
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 RECOMMENDED Blowfish in SDCTR mode blowfish-ctr OPTIONAL Blowfish in SDCTR mode
twofish128-ctr RECOMMENDED 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 RECOMMENDED Serpent in SDCTR mode, with serpent128-ctr OPTIONAL Serpent in SDCTR mode, with
with 128-bit key with 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
Internet Draft Month, Year
The label <cipher>-ctr means that the block cipher <cipher> is to be The label <cipher>-ctr means that the block cipher <cipher> is to be
used in "stateful-decryption counter" (SDCTR) mode. Let L be the 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 5.2 of [SSH-TRANS]) interpreted as an L-bit computed in Section 5.2 of [SSH-TRANS]) 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
skipping to change at page 6, line 5 skipping to change at page 6, line 8
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 [SCHNEIER]. This algorithm is defined in [SCHNEIER].
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. The block size is 8 bytes.
Internet Draft Month, Year
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 45 skipping to change at page 6, line 46
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 [BKN]. security, appear in the research paper [BKN].
Please note that the notion of "prove" in the context of [BKN] is Please note that the notion of "prove" in the context of [BKN] is
that of practice-oriented reductionist security: if an attacker 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 (eg, a chosen-ciphertext attack), then using a certain type of attack (e.g., a chosen-ciphertext attack),
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 (eg, the underlying block cipher or protocolどヨs underlying components (e.g., the underlying block cipher
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 [BKN] for details. In particular, attacks are not impossible; see [BKN] for details. In particular, attacks are not impossible;
just extremely improbable (unless the building blocks, like AES, are just extremely improbable (unless the building blocks, like AES, are
insecure). insecure).
Internet Draft Month, Year
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.
5.1 Rekeying Considerations 5.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 certain
number of encrypted blocks (eg, 2**(L/4) blocks if the block cipher's number of encrypted blocks (e.g., 2**(L/4) blocks if the block
block length L is at least 128 bits). The motivations for cipherどヨs block length L is at least 128 bits). The motivations for
recommendations (1) and (2) are different, and we consider each 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 (2)
is designed to protect against information leakage through the SSH is designed to protect against information leakage through the SSH
protocol's underlying encryption scheme. Please note that, depending protocolどヨs underlying encryption scheme. Please note that, depending
on the encryption method's block length L and the number of blocks on the encryption methodどヨs block length L and the number of blocks
encrypted per packet, recommendation (1) may supersede recommendation encrypted per packet, recommendation (1) may supersede recommendation
(2) or visa-versa. (2) or visa-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. As [BKN] show, if more than 2**32 least once every 2**32 packets. As [BKN] show, if more than 2**32
packets are encrypted and MACed by the SSH Transport Protocol between packets are encrypted and MACed by the SSH Transport Protocol between
rekeyings, then the SSH Transport Protocol's underlying MAC may begin rekeyings, then the SSH Transport Protocolどヨs underlying MAC may begin
to leak information about the protocol's payload data. In more 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 [SSH-TRANS]); 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. Implementors who decide secure the underlying encryption method is. Implementors who decide
not to rekey at least once every 2**32 packets should understand this not to rekey at least once every 2**32 packets should understand this
issue. issue.
Note that compressing payload data before encrypting and MACing will Note that compressing payload data before encrypting and MACing will
not significantly reduce the risk of information leakage through the not significantly reduce the risk of information leakage through the
underlying MAC. Similarly, the use of random (and unpredictable to underlying MAC. Similarly, the use of random (and unpredictable to
an adversary) padding will not prevent information leakage through an adversary) padding will not prevent information leakage through
the underlying MAC [BKN]. the underlying MAC [BKN].
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
Internet Draft Month, Year
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 version of the SSH protocol. Another alternative to recommendation
(1) would be to switch from HMAC to a privacy-preserving randomized (1) would be to switch from basic HMAC to a privacy-preserving
MAC. randomized MAC, such as a 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 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.
5.2 Encryption Method Considerations 5.2 Encryption Method Considerations
Researchers have recently shown that the original CBC-based Researchers have recently shown that the original CBC-based
encryption methods in [SSH-TRANS] are vulnerable to chosen-plaintext encryption methods in [SSH-TRANS] are vulnerable to chosen-plaintext
privacy attacks [DAI,BKN]. The new stateful-decryption counter mode privacy attacks [DAI,BKN]. The new stateful-decryption counter mode
encryption methods described in Section 4 of this document were encryption methods described in Section 4 of this document were
designed to be secure replacements to the original encryption methods designed to be secure replacements to the original encryption methods
described in [SSH-TRANS]. described in [SSH-TRANS].
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 [BKN]. formalized with proofs of security in [BKN].
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 [SSH-TRANS]) 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 messages to 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 padding to be a multiple
of the block cipher's block length in order to (1) not alter the of the block cipherどヨs block length in order to (1) not alter the
packet description in [SSH-TRANS] and (2) not leak precise packet description in [SSH-TRANS] 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 networks savings for padding to only 8-bytes even there may be some networks savings for 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
Internet Draft Month, Year
make that recommendation here.) make that recommendation here.)
In addition to stateful-decryption counter mode, [BKN] describe other In addition to stateful-decryption counter mode, [BKN] describe other
provably-secure encryption methods for use with the SSH Transport provably-secure encryption methods for use with the SSH Transport
Protocol. The stateful-decryption counter mode methods in Section 4 Protocol. The stateful-decryption counter mode methods in Section 4
are, however, the preferred alternatives to the insecure methods in are, however, the preferred alternatives to the insecure methods in
[SSH-TRANS] because stateful-decryption counter mode is the most [SSH-TRANS] because stateful-decryption counter mode is the most
efficient (both in terms of network consumption and in terms of the efficient (both in terms of network consumption and in terms of the
number of required cryptographic operations per packet). number of required cryptographic operations per packet).
References Normative References
[AES] Daemon, J. and Rijmen, V., "AES Proposal: Rijndael", [AES] Daemon, J. and Rijmen, V., "AES Proposal: Rijndael",
NIST AES Proposal, 1998. NIST AES Proposal, 1998.
[BKN] Bellare, M., Kohno, T., and Namprempre, C.,
"Authenticated Encryption in SSH: Provably Fixing the
SSH Binary Packet Protocol", Ninth ACM Conference on
Computer and Communications Security, 2002.
[BN] Bellare, M. and Namprempre, C., "Authenticated
Encryption: Relations among notions and analysis of
the generic composition paradigm", Asiacrypt 2000.
[DAI] Dai, W., "An Attack Against SSH2 Protocol", Email to
the ietf-ssh@netbsd.org email list, 2002.
[KRAWCZYK] Krawczyk, H., "The Order of Encryption and
Authentication for Protecting Communications (Or: How
secure is SSL?)", Crypto 2001.
[RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2144] Adams, C., "The CAST-128 Encryption Algorithm", RFC [RFC2144] Adams, C., "The CAST-128 Encryption Algorithm", RFC
2144, May 1997. 2144, May 1997.
[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 Proposal, 1998. AES Proposal, 1998.
[SSH-ARCH] Ylonen, T., et. al., "SSH Protocol Architecture", [SSH-ARCH] Ylonen, T., et. al., "SSH Protocol Architecture",
I-D draft-ietf-architecture-12.txt, January 2002. I-D draft-ietf-architecture-12.txt, January 2002.
Internet Draft Month, Year
[SSH-TRANS] Ylonen, T., et. al., "SSH Transport Layer Protocol", [SSH-TRANS] Ylonen, T., et. al., "SSH Transport Layer Protocol",
I-D draft-ietf-transport-14.txt, March 2002. I-D draft-ietf-transport-14.txt, March 2002.
[TWOFISH] Schneier, B., et. al., "The Twofish Encryptions [TWOFISH] Schneier, B., et. al., "The Twofish Encryptions
Algorithm: A 128-bit block cipher, 1st Edition", Algorithm: A 128-bit block cipher, 1st Edition",
Wiley, 1999. Wiley, 1999.
Authors' Addresses: Non-Normative References
[BKN] Bellare, M., Kohno, T., and Namprempre, C.,
"Authenticated Encryption in SSH: Provably Fixing the
SSH Binary Packet Protocol", Ninth ACM Conference on
Computer and Communications Security, 2002.
[BN] Bellare, M. and Namprempre, C., "Authenticated
Encryption: Relations among notions and analysis of
the generic composition paradigm", Asiacrypt 2000.
[DAI] Dai, W., "An Attack Against SSH2 Protocol", Email to
the ietf-ssh@netbsd.org email list, 2002.
[KRAWCZYK] Krawczyk, H., "The Order of Encryption and
Authentication for Protecting Communications (Or: How
secure is SSL?)", Crypto 2001.
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 0114
La Jolla, CA 92093-0114 La Jolla, CA 92093-0114
Phone: +1 858-822-2977 Phone: +1 858-822-2977
EMail: mihir@cs.ucsd.edu EMail: mihir@cs.ucsd.edu
skipping to change at page 11, line 4 skipping to change at page 11, line 10
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet Draft Month, Year
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than followed, or as required to translate it into languages other than
English. English.
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
 End of changes. 

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