datatracker.ietf.org
Sign in
Version 5.6.4.p1, 2014-10-20
Report a bug

The Secure Shell (SSH) Transport Layer Encryption Modes
RFC 4344

Document type: RFC - Proposed Standard (January 2006; No errata)
Document stream: IETF
Last updated: 2013-03-02
Other versions: plain text, pdf, html

IETF State: WG Document
Consensus: Unknown
Document shepherd: No shepherd assigned

IESG State: RFC 4344 (Proposed Standard)
Responsible AD: Sam Hartman
Send notices to: sommerfeld@sun.com

Network Working Group                                         M. Bellare
Request for Comments: 4344                                      T. Kohno
Category: Standards Track                                   UC San Diego
                                                           C. Namprempre
                                                    Thammasat University
                                                            January 2006

        The Secure Shell (SSH) Transport Layer Encryption Modes

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   Researchers have 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
   Secure Shell (SSH) Transport Protocol and gives specific
   recommendations on how frequently SSH implementations should rekey.

Table of Contents

   1. Introduction ....................................................2
   2. Conventions Used in This Document ...............................2
   3. Rekeying ........................................................2
      3.1. First Rekeying Recommendation ..............................3
      3.2. Second Rekeying Recommendation .............................3
   4. Encryption Modes ................................................3
   5. IANA Considerations .............................................6
   6. Security Considerations .........................................6
      6.1. Rekeying Considerations ....................................7
      6.2. Encryption Method Considerations ...........................8
   Normative References ...............................................9
   Informative References ............................................10

Bellare, et al.             Standards Track                     [Page 1]
RFC 4344          SSH Transport Layer Encryption Modes      January 2006

1.  Introduction

   The symmetric portion of the SSH Transport Protocol was designed to
   provide both privacy and integrity of encapsulated data.  Researchers
   ([DAI,BKN1,BKN2]) have, however, identified several security problems
   with the symmetric portion of the SSH Transport Protocol, as
   described in [RFC4253].  For example, the encryption mode specified
   in [RFC4253] 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 [BKN1,BKN2], 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 [BKN1,BKN2].

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
   document [RFC4251].

   The SSH Transport Protocol is specified in the transport document
   [RFC4253].

3.  Rekeying

   Section 9 of [RFC4253] suggests that SSH implementations rekey after
   every gigabyte of transmitted data.  [RFC4253] 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 [RFC4253] by giving firm upper bounds on the
   tolerable number of encryptions between rekeying operations.  In
   Section 6, we discuss the motivation for these rekeying
   recommendations in more detail.

   This section makes two recommendations.  Informally, the first
   recommendation is intended to protect 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

Bellare, et al.             Standards Track                     [Page 2]

[include full document text]