IETF-SSH archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
preliminary version of counter mode draft
This is a preliminary version of a counter mode + transport fixes
draft prepared by some of the folks who recently did a security
analysis of the protocol..
The authors have the following questions for the WG:
1) The transport ID says messages should be padded to a length a
multiple of the block cipher's block size. That is not necessary if
we use CTR mode (ie, we can pad to a multiple of 8 bytes even if the
block ciphers uses 16 byte blocks). Do people think we should
"break" compliance with the transport spec and just pad to a
multiple of 8 bytes (to help with performance on slow links). (Of
course, the less padding we use, the more information we leak about
the length of the payload. But implementations can always add more
than the minimum amount of padding if they want to.)
2) How should we handle the recommendation: the receiver should
rekey before receiving 2**32 packets since the last rekey
operation? The solution we currently have is to require (ie, say
SHOULD) implementations to rekey after receiving more than 2**31
packets since the last rekey operation?
3) Which ciphers do people want to use (AES, 3DES, Twofish, etc.)?
We'll discuss these in the meeting and follow up on the list..
Network Working Group M. Bellare
Internet-Draft T. Kohno
Expires: [[Month Day, Year]] UC San Diego
C. Namprempre
Thammasat University
[[Date]]
SSH Transport Layer Encryption Modes
draft-ietf-secsh-newmodes-00.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on [[Month Day, Year]].
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
Researchers have recently discovered that the authenticated
encryption portion of the current SSH Transport Protocol is
vulnerable to several attacks.
This document describes new symmetric encryption methods for the SSH
Transport Protocol and gives specific recommendations on how
Bellare, Kohno, and Namprempre [Page 1]
Internet Draft Month, Year
frequently SSH implementations should rekey.
Bellare, Kohno, and Namprempre [ACM CCS 2002] 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
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . X
2. Conventions Used in This Document . . . . . . . . . . . . . . X
3. Rekeying . . . . . . . . . . . . . . . . . . . . . . . . . . . X
3.1 First Rekeying Recommendation . . . . . . . . . . . . . . . . X
3.2 Second Rekeying Recommendation . . . . . . . . . . . . . . . . X
4. Encryption Modes . . . . . . . . . . . . . . . . . . . . . . . X
5. Security Considerations . . . . . . . . . . . . . . . . . . . X
5.1 Rekeying Considerations . . . . . . . . . . . . . . . . . . . X
5.2 Encryption Method Considerations . . . . . . . . . . . . . . . X
References . . . . . . . . . . . . . . . . . . . . . . . . . . X
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . X
Full Copyright Statement . . . . . . . . . . . . . . . . . . . X
1. Introduction
The symmetric portion of the SSH Transport Protocol was designed to
provide both privacy and integrity of encapsulated data. Researchers
([DAI,BKN]) have, however, recently identified several security
problems with the symmetric portion of the SSH Transport Protocol as
described in [SSH-TRANS]. For example, the encryption mode specified
in [SSH-TRANS] is vulnerable to a chosen-plaintext privacy attack.
Additionally, if not rekeyed frequently enough, the SSH Transport
Protocol may leak information about payload data. This latter
property is true regardless of what encryption mode is used.
In [BKN] Bellare, Kohno, and Namprempre show how to modify the
symmetric portion of the SSH Transport Protocol so that it provably
preserves privacy and integrity against chosen-plaintext, chosen-
ciphertext, and reaction attacks. This document instantiates the
recommendations described in [BKN].
2. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
The used data types and terminology are specified in the architecture
Bellare, Kohno, and Namprempre [Page 2]
Internet Draft Month, Year
document [SSH-ARCH].
The SSH Transport Protocol is specified in the transport document
[SSH-TRANS].
3. Rekeying
Section 7 of [SSH-TRANS] suggests that SSH implementations rekey
after every gigabyte of transmitted data. [SSH-TRANS] does not,
however, discuss all the problems that could arise if an SSH
implementation does not rekey frequently enough. This section serves
to strengthen the suggestion in [SSH-TRANS] by giving firm upper
bounds on the tolerable number of encryptions between rekeying
operations. In Section 5 we discuss the motivation for these
rekeying recommendations in more detail.
This section makes two recommendations. Informally, the first
recommendation is intended to protects against possible information
leakage through the MAC tag and the second recommendation is intended
to protect against possible information leakage through the block
cipher. Note that, depending on the block length of the underlying
block cipher and the length of the encrypted packets, the first
recommendation may supersede the second recommendation, or visa-
versa.
3.1 First Rekeying Recommendation
Because of possible information leakage through the MAC tag, SSH
implementations SHOULD rekey at least once every 2**32 outgoing
packets. More explicitly, after a key exchange an SSH implementation
SHOULD NOT send more than 2**32 packets before rekeying again.
SSH implementations SHOULD also attempt to rekey before receiving
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
packets since the last rekey operation.
3.2 Second Rekeying Recommendation
Because of a birthday property of block ciphers and some modes of
operation, implementations must be careful not to encrypt too many
blocks with the same encryption key.
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
rekeying, an SSH implementation SHOULD NOT encrypt more than 2**(L/4)
blocks before rekeying again. If L is at least 128, then SSH
implementations should also attempt to force a rekey before receiving
Bellare, Kohno, and Namprempre [Page 3]
Internet Draft Month, Year
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,
although it may be too expensive to rekey every 2**(L/4) blocks, it
is still advisable for SSH implementations to follow the original
recommendation in [SSH-TRANS]: rekey at least once every gigabyte of
transmitted data.
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
an SSH implementation uses a block cipher with a larger block size
(eg, Rijndael with 256-bit blocks), then the recommendations in the
above paragraph may supersede the recommendations in this paragraph
(depending on the lengths of the packets).
4. Encryption Modes
This document describes new encryption methods for use with the SSH
Transport Protocol. These encryption methods are in addition to the
encryption methods described in Section 4.3 of [SSH-TRANS].
Recall from [SSH-TRANS] that the encryption methods in each direction
of an SSH connection MUST run independently of each other and that,
when encryption is in effect, the packet length, padding length,
payload, and padding fields of each packet MUST be encrypted with the
chosen method. Further recall that the total length of the
concatenation of the packet length, padding length, payload, and
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
case for all of the following methods).
This document describes the following new methods:
aes128-ctr RECOMMENDED AES (Rijndael) in SDCTR mode,
with 128-bit key
aes192-ctr RECOMMENDED AES with 192-bit key
aes256-ctr RECOMMENDED AES with 256-bit key
3des-ctr RECOMMENDED Three-key 3DES in SDCTR mode
blowfish-ctr RECOMMENDED Blowfish in SDCTR mode
twofish128-ctr RECOMMENDED Twofish in SDCTR mode,
with 128-bit key
twofish192-ctr OPTIONAL Twofish with 192-bit key
twofish256-ctr OPTIONAL Twofish with 256-bit key
serpent128-ctr RECOMMENDED Serpent in SDCTR mode, with
with 128-bit key
serpent192-ctr OPTIONAL Serpent with 192-bit key
serpent256-ctr OPTIONAL Serpent with 256-bit key
idea-ctr OPTIONAL IDEA in SDCTR mode
cast128-ctr OPTIONAL CAST-128 in SDCTR mode
Bellare, Kohno, and Namprempre [Page 4]
Internet Draft Month, Year
The label <cipher>-ctr means that the block cipher <cipher> is to be
used in "stateful-decryption counter" (SDCTR) mode. Let L be the
block length of <cipher> in bits. In stateful-decryption counter
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
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
"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-
byte-order." Naturally, implementations may differ in how the
internal value X is stored. For example, implementations may store X
as multiple unsigned 32-bit counters.
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>
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
process is repeated for each subsequent block in order to generate
the entire ciphertext C=C1||C2||...||Cn corresponding to the packet
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
parallelizable.
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
<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 above process for each block to obtain the plaintext packet
P=P1||P2||...||Pn. As before, the keystream can be pre-computed and
decryption is parallelizable.
The "aes128-ctr" method uses AES (the Advanced Encryption Standard,
formerly Rijndael) with 128-bit keys [AES]. The block size is 16
bytes.
The "aes192-ctr" method uses AES with 192-bit keys.
The "aes256-ctr" method uses AES with 256-bit keys.
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
encryption, the next 8 bytes for the decryption, and the following 8
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.
This algorithm is defined in [SCHNEIER].
The "blowfish-ctr" method uses Blowfish with 256 bit keys [SCHNEIER].
The block size is 8 bytes.
Bellare, Kohno, and Namprempre [Page 5]
Internet Draft Month, Year
The "twofish128-ctr" method uses Twofish with 128-bit keys [TWOFISH].
The block size is 16 bytes.
The "twofish192-ctr" method uses Twofish with 192-bit keys.
The "twofish256-ctr" method uses Twofish with 256-bit keys.
The "serpent128-ctr" method uses the Serpent block cipher [SERPENT]
with 128-bit keys. The block size is 16 bytes.
The "serpent192-ctr" method uses Serpent with 192-bit keys.
The "serpent256-ctr" method uses Serpent with 256-bit keys.
The "idea-ctr" method uses the IDEA cipher [SCHNEIER]. IDEA is
patented by Ascom AG. The block size is 8 bytes.
The "cast128-ctr" method uses the CAST-128 cipher [RFC2144]. The
block size is 8 bytes.
5. Security Considerations
This document describes additional encryption methods and
recommendations for the SSH Transport Protocol [SSH-TRANS]. [BKN]
prove that if an SSH application incorporates the methods and
recommendations described in this document, then the symmetric
cryptographic portion of that application will resist a large class
of privacy and integrity attacks.
This section is designed to help implementors understand the
security-related motivations for, as well as possible consequences of
deviating from, the methods and recommendations described in this
document. Additional motivation and discussion, as well as proofs of
security, appear in the research paper [BKN].
Please note that the notion of "prove" in the context of [BKN] is
that of practice-oriented reductionist security: if an attacker is
able to break the symmetric portion of the SSH Transport Protocol
using a certain type of attack (eg, a chosen-ciphertext attack), then
the attacker will also be able to break one of the transport
protocol's underlying components (eg, the underlying block cipher or
MAC). If we make the reasonable assumption that the underlying
components (such as AES and HMAC-SHA1) are secure, then the attacker
against the symmetric portion of the SSH protocol cannot be very
successful (since otherwise there would be a contradiction). Please
see [BKN] for details. In particular, attacks are not impossible;
just extremely improbable (unless the building blocks, like AES, are
insecure).
Bellare, Kohno, and Namprempre [Page 6]
Internet Draft Month, Year
Note also that cryptography often plays only a small (but critical)
role in an application's overall security. In the case of the SSH
Transport Protocol, even though an application might implement the
symmetric portion of the SSH protocol exactly as described in this
document, the application may still be vulnerable to non-protocol-
based attacks (as an egregious example, an application might save
cryptographic keys in cleartext to an unprotected file).
Consequently, even though the methods described herein come with
proofs of security, developers must still execute caution when
developing applications that implement these methods.
5.1 Rekeying Considerations
Section 3 of this document makes two rekeying recommendations: (1)
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
block length L is at least 128 bits). The motivations for
recommendations (1) and (2) are different, and we consider each
recommendation in turn. Briefly, (1) is designed to protect against
information leakage through the SSH protocol's underlying MAC and (2)
is designed to protect against information leakage through the SSH
protocol's underlying encryption scheme. Please note that, depending
on the encryption method's block length L and the number of blocks
encrypted per packet, recommendation (1) may supersede recommendation
(2) or visa-versa.
Recommendation (1) states that SSH implementations should rekey at
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
rekeyings, then the SSH Transport Protocol's underlying MAC may begin
to leak information about the protocol's payload data. In more
detail, an adversary looks for a collision between the MACs
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
found, then the payload data associated with those two ciphertexts is
probably identical. Note that this problem occurs regardless of how
secure the underlying encryption method is. Implementors who decide
not to rekey at least once every 2**32 packets should understand this
issue.
Note that compressing payload data before encrypting and MACing will
not significantly reduce the risk of information leakage through the
underlying MAC. Similarly, the use of random (and unpredictable to
an adversary) padding will not prevent information leakage through
the underlying MAC [BKN].
One alternative to recommendation (1) would be to make the SSH
Transport Protocol's sequence number more than 32 bits long. This
Bellare, Kohno, and Namprempre [Page 7]
Internet Draft Month, Year
document does not suggest increasing the length of the sequence
number because doing so could hinder interoperability with older
version of the SSH protocol. Another alternative to recommendation
(1) would be to switch from HMAC to a privacy-preserving randomized
MAC.
Recommendation (2) states that SSH implementations should rekey
before encrypting more than 2**(L/4) blocks with the same key
(assuming L is at least 128). This recommendation is designed to
minimize the risk of birthday attacks against the encryption method's
underlying block cipher. For example, there is a theoretical privacy
attack against stateful-decryption counter mode if an adversary is
allowed to encrypt approximately 2**(L/2) messages with the same key.
It is because of these birthday attacks that implementors are highly
encouraged to use secure block ciphers with large block lengths.
5.2 Encryption Method Considerations
Researchers have recently shown that the original CBC-based
encryption methods in [SSH-TRANS] are vulnerable to chosen-plaintext
privacy attacks [DAI,BKN]. The new stateful-decryption counter mode
encryption methods described in Section 4 of this document were
designed to be secure replacements to the original encryption methods
described in [SSH-TRANS].
Many people shy away from counter mode-based encryption schemes
because, when used incorrectly (such as when the keystream is allowed
to repeat), counter mode can be very insecure. Fortunately, the
common concerns with counter mode do not apply to SSH because of the
rekeying recommendations and because of the additional protection
provided by the transport protocol's MAC. This discussion is
formalized with proofs of security in [BKN].
As an additional note, when one of the stateful-decryption counter
mode encryption methods (Section 4) is used, then the padding
included in an SSH packet (Section 4 of [SSH-TRANS]) need not be (but
can still be) random. This eliminates the need to generate
cryptographically-secure pseudorandom bytes for each packet.
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
length. Although not padding messages can reduce the protocol's
network consumption, this document requires padding to be a multiple
of the block cipher's block length in order to (1) not alter the
packet description in [SSH-TRANS] and (2) not leak precise
information about the length of the packet's payload data. (Although
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
Bellare, Kohno, and Namprempre [Page 8]
Internet Draft Month, Year
make that recommendation here.)
In addition to stateful-decryption counter mode, [BKN] describe other
provably-secure encryption methods for use with the SSH Transport
Protocol. The stateful-decryption counter mode methods in Section 4
are, however, the preferred alternatives to the insecure methods in
[SSH-TRANS] because stateful-decryption counter mode is the most
efficient (both in terms of network consumption and in terms of the
number of required cryptographic operations per packet).
References
[AES] Daemon, J. and Rijmen, V., "AES Proposal: Rijndael",
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@localhost 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
2144, May 1997.
[SCHNEIER] Schneier, B., "Applied Cryptography Second Edition:
Protocols algorithms and source in code in C", Wiley,
1996.
[SERPENT] Anderson, R., Biham, E., and Knudsen, L. "Serpent: A
proposal for the Advanced Encryption Standard", NIST
AES Proposal, 1998.
[SSH-ARCH] Ylonen, T., et. al., "SSH Protocol Architecture",
I-D draft-ietf-architecture-12.txt, January 2002.
Bellare, Kohno, and Namprempre [Page 9]
Internet Draft Month, Year
[SSH-TRANS] Ylonen, T., et. al., "SSH Transport Layer Protocol",
I-D draft-ietf-transport-14.txt, March 2002.
[TWOFISH] Schneier, B., et. al., "The Twofish Encryptions
Algorithm: A 128-bit block cipher, 1st Edition",
Wiley, 1999.
Authors' Addresses:
Mihir Bellare
Department of Computer Science and Engineering
University of California at San Diego
9500 Gilman Drive, MC 0114
La Jolla, CA 92093-0114
Phone: +1 858-822-2977
EMail: mihir%cs.ucsd.edu@localhost
Tadayoshi Kohno
Department of Computer Science and Engineering
University of California at San Diego
9500 Gilman Drive, MC 0114
La Jolla, CA 92093-0114
Phone: +1 858-822-2977
EMail: tkohno%cs.ucsd.edu@localhost
Chanathip Namprempre
Thammasat University
Faculty of Engineering
Electrical Engineering Department
Rangsit Campus, Klong Luang
Pathumthani, Thailand 12121
EMail: meaw%alum.mit.edu@localhost
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Bellare, Kohno, and Namprempre [Page 10]
Internet Draft Month, Year
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Acknowledgments
The first and third author were supported by NSF Grant CCR-0098123,
NSF Grant ANR-0129617 and an IBM Faculty Partnership Development
Award. The second author was supported by a National Defense Science
and Engineering Fellowship.
Bellare, Kohno, and Namprempre [Page 11]
Home |
Main Index |
Thread Index |
Old Index