draft-ietf-secsh-newmodes-04.txt   draft-ietf-secsh-newmodes-05.txt 
Network Working Group M. Bellare Network Working Group M. Bellare
Internet-Draft T. Kohno Internet-Draft T. Kohno
Expires: October 8, 2005 UC San Diego Expires: February 18, 2006 UC San Diego
C. Namprempre C. Namprempre
Thammasat University Thammasat University
April 8, 2005 August 18, 2005
SSH Transport Layer Encryption Modes SSH Transport Layer Encryption Modes
draft-ietf-secsh-newmodes-04.txt draft-ietf-secsh-newmodes-05.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions This document is an Internet-Draft and is subject to all provisions
of Section 3 of RFC 3667. By submitting this Internet-Draft, each of Section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of 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 is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with which he or she become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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 October 8, 2005. This Internet-Draft will expire on February 18, 2006.
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved. Copyright (C) The Internet Society (2005). All Rights Reserved.
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 SSH
Transport Protocol and gives specific recommendations on how Transport Protocol and gives specific recommendations on how
frequently SSH implementations should rekey. frequently SSH implementations should rekey.
Bellare, Kohno, and Namprempre [ACM CCS 2002] prove that if an SSH 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, 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 . . . . . . . . . . . . . . 3 2. Conventions Used in This Document . . . . . . . . . . . . . . 3
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 . . . . . . . . . . . . . . . . 4
4. Encryption Modes . . . . . . . . . . . . . . . . . . . . . . . 4 4. Encryption Modes . . . . . . . . . . . . . . . . . . . . . . . 4
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 . . . . . . . . . . . . . . . 8 6.2 Encryption Method Considerations . . . . . . . . . . . . . . . 9
Normative References . . . . . . . . . . . . . . . . . . . . . 9 Normative References . . . . . . . . . . . . . . . . . . . . . 9
Non-Normative References . . . . . . . . . . . . . . . . . . . 10 Non-Normative References . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11
Intellectual Property Statement . . . . . . . . . . . . . . . 12 Intellectual Property Statement . . . . . . . . . . . . . . . 12
Disclaimer of Validity . . . . . . . . . . . . . . . . . . . . 12 Disclaimer of Validity . . . . . . . . . . . . . . . . . . . . 12
Copyright Statement . . . . . . . . . . . . . . . . . . . . . 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 described
skipping to change at page 5, line 10 skipping to change at page 5, line 20
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 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,
with 128-bit key
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 7.2 of [SSH-TRANS]) interpreted as an L-bit computed in Section 7.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-
skipping to change at page 6, line 28 skipping to change at page 6, line 38
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.
The "serpent192-ctr" method uses Serpent with 192-bit keys. The "serpent192-ctr" method uses Serpent with 192-bit keys.
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 "idea-ctr" method uses the IDEA cipher [SCHNEIER]. The block
size is 8 bytes.
The "cast128-ctr" method uses the CAST-128 cipher [RFC2144]. The The "cast128-ctr" method uses the CAST-128 cipher with 128-bit keys
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 twelve encryption algorithm names defined in Section 4 are to be
added to the Secure Shell Encryption Algorithm Name registry 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 [SSH-IANA].
6. Security Considerations 6. Security Considerations
This document describes additional encryption methods and This document describes additional encryption methods and
skipping to change at page 8, line 38 skipping to change at page 8, line 48
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
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
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
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 [SSH-TRANS] 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]. [SSH-TRANS].
skipping to change at page 9, line 21 skipping to change at page 9, line 37
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 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 [SSH-TRANS] because stateful-decryption counter mode is
the most efficient (both in terms of network consumption and in terms the most efficient (both in terms of network consumption and in terms
of the number of required cryptographic operations per packet). of the number of required cryptographic operations per packet).
 End of changes. 

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