Sending and Handling of Global Requests in Secure Shell (SSH)
draft-ssh-global-requests-ok-00

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 00

Internet-Draft                                                  D. Bider
Updates: 4254 (if approved)                              Bitvise Limited
Intended status: Standards Track                       December 18, 2018
Expires: May 18, 2019

     Sending and Handling of Global Requests in Secure Shell (SSH)
                   draft-ssh-global-requests-ok-00.txt

Abstract

  This memo updates RFC 4254 to clarify when global requests can be sent
  or received and provides a mechanism for SSH software to indicate it
  will accept global requests according to this requirement.

Status

  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
  http://www.ietf.org/1id-abstracts.html
  
  The list of Internet-Draft Shadow Directories can be accessed at
  http://www.ietf.org/shadow.html

Copyright

  Copyright (c) 2018 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           Global Requests in SSH            December 2018

1.  Overview and Rationale

  Secure Shell (SSH) is a common protocol for secure communication on
  the Internet. [RFC4254] requires both clients and servers to correctly
  handle messages of type SSH_MSG_GLOBAL_REQUEST received at any time.
  In practice, several client implementations and some servers mishandle
  this requirement. This discourages implementations from deploying
  protocol enhancements including host key synchronization and active
  keep-alives. Software that uses such enhancements must rely on remote
  version information to decide if global requests are safe to use.
  However, this is not accurate as to the remote party's capabilities.
  
  This memo updates RFC 4254 to clarify when software may send and must
  accept global requests. An [RFC8308] extension is defined allowing
  SSH software to indicate it complies with this requirement.

1.1.  Requirements Terminology

  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].

1.2.  Wire Encoding Terminology

  The wire encoding types in this document - "string", "byte" and
  "boolean" - have meanings as described in [RFC4251].

2.  Global Request Sending and Handling

  The requirement in [RFC4254], which states that both a client and a
  server must correctly handle global requests at any time, is replaced
  as defined in this section.
  
  A server MAY send a message of type SSH_MSG_GLOBAL_REQUEST at any time
  after it has sent the message SSH_MSG_USERAUTH_SUCCESS (defined in
  [RFC4252]), including immediately following that message. A server
  MUST NOT send SSH_MSG_GLOBAL_REQUEST before it has sent
  SSH_MSG_USERAUTH_SUCCESS.
  
  A client MAY send a message of type SSH_MSG_GLOBAL_REQUEST at any time
  after it has received SSH_MSG_USERAUTH_SUCCESS from the server. A
  client MUST NOT send SSH_MSG_GLOBAL_REQUEST before it has received
  SSH_MSG_USERAUTH_SUCCESS.
  
  A server MUST handle correctly - as defined in [RFC4254] - any message
  of type SSH_MSG_GLOBAL_REQUEST received after the server has sent
  SSH_MSG_USERAUTH_SUCCESS. A server MAY implement arbitrary behavior
  for global requests received before this. However, see Section 2.1
  (Security Consideration).
  
  A client MUST handle correctly - as defined in [RFC4254] - any message
  of type SSH_MSG_GLOBAL_REQUEST received after it has received
  SSH_MSG_USERAUTH_SUCCESS from the server. A client MAY implement
  arbitrary behavior for global requests received before this.
  
  Implementations MUST correctly handle SSH_MSG_GLOBAL_REQUEST messages
  received during SSH key re-exchange. When implementations receive