Extension Negotiation in Secure Shell (SSH)

The information below is for an old version of the document
Document Type Active Internet-Draft (curdle WG)
Author denis bider 
Last updated 2016-09-05
Replaces draft-ssh-ext-info
Stream Internent Engineering Task Force (IETF)
Formats pdf htmlized (tools) htmlized bibtex
Stream WG state WG Document
Document shepherd No shepherd assigned
IESG IESG state I-D Exists
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
Internet-Draft                                                  D. Bider
Updates: 4252, 4253, 4254 (if approved)                  Bitvise Limited
Intended status: Standards Track                       September 5, 2016
Expires: March 5, 2017

               Extension Negotiation in Secure Shell (SSH)


  This memo defines a mechanism for SSH clients and servers to exchange
  information about supported protocol extensions confidentially after
  completed key exchange.


  This Internet-Draft is submitted in full conformance with the
  provisions of BCP 78 and BCP 79.

  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
  The list of Internet-Draft Shadow Directories can be accessed at


  Copyright (c) 2015 IETF Trust and the persons identified as the
  document authors.  All rights reserved.

  This document is subject to BCP 78 and the IETF Trust's Legal
  Provisions Relating to IETF Documents
  (http://trustee.ietf.org/license-info) in effect on the date of
  publication of this document.  Please review these documents
  carefully, as they describe your rights and restrictions with respect
  to this document.  Code Components extracted from this document must
  include Simplified BSD License text as described in Section 4.e of
  the Trust Legal Provisions and are provided without warranty as
  described in the Simplified BSD License.

Bider                                                           [Page 1]
Internet-Draft        Extension Negotiation in SSH            March 2016

1.  Overview and Rationale

  Secure Shell (SSH) is a common protocol for secure communication on
  the Internet. The original design of the SSH transport layer [RFC4253]
  lacks proper extension negotiation. Meanwhile, diverse implementations
  take steps to ensure that known message types contain no unrecognized
  information. This makes it difficult for implementations to signal
  capabilities and negotiate extensions without risking disconnection.
  This obstacle has been recognized in relationship with [SSH-RSA-SHA2],
  where the need arises for a client to discover signature algorithms a
  server accepts, to avoid authentication penalties and trial-and-error.

1.1.  Requirements Terminology

  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  document are to be interpreted as described in [RFC2119].

2.  Extension Negotiation Mechanism
2.1.  Signaling of Extension Negotiation in KEXINIT
  Applications implementing this mechanism MUST add to the field
  "kex_algorithms", in their KEXINIT packet sent for the first key
  exchange, one of the following indicator names:
  - When acting as server: "ext-info-s"
  - When acting as client: "ext-info-c"

  The indicator name is added without quotes, and MAY be added at any
  position in the name-list, subject to proper separation from other
  names as per name-list conventions.
  The names are added to the "kex_algorithms" field because this is one
  of two name-list fields in KEXINIT that do not have a separate copy
  for each data direction.
  The indicator names inserted by the client and server are different to
  ensure that these names will not produce a match, and will be neutral
  with respect to key exchange algorithm negotiation.
  The inclusion of textual indicator names is intended to provide a clue
  for implementers to discover this mechanism.
2.2.  Enabling Criteria

  If a client or server offers "ext-info-c" or "ext-info-s"
  respectively, it must be prepared to accept an SSH_MSG_EXT_INFO
  message from the peer.

Bider                                                           [Page 2]
Internet-Draft        Extension Negotiation in SSH            March 2016

  Thus a server only needs to send "ext-info-s" if it intends to process
  SSH_MSG_EXT_INFO from the client.

  If a server receives an "ext-info-c", it MAY send an SSH_MSG_EXT_INFO
  message, but is not required to do so.

  If an SSH_MSG_EXT_INFO message is sent, then it MUST be the first
  message after the initial SSH_MSG_NEWKEYS. 

  Implementations MUST NOT send an incorrect indicator name for their
  role. Implementations MAY disconnect if the counter-party sends an
Show full document text