Internet DRAFT - draft-ssh-global-requests-ok
draft-ssh-global-requests-ok
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
global requests during key re-exchange, they MAY defer processing them
and responding until key re-exchange has completed.
2.1. Security Consideration
A server that chooses to handle SSH_MSG_GLOBAL_REQUEST before it has
sent SSH_MSG_USERAUTH_SUCCESS MUST apply precautions which take into
account that the client has not yet authenticated.
3. "global-requests-ok" Extension
SSH software that implements [RFC8308] MAY include the following
extension when sending an SSH_MSG_EXT_INFO message:
string extension-name = "global-requests-ok"
string extension-value = ""
The sender MUST send an empty extension value. A receiver that does
not expect an extension value MUST ignore it. A receiver MUST tolerate
and ignore non-printable binary characters in the extension value.
Future specifications MAY define meanings for this value.
A receiver SHOULD assume, if the remote party includes this extension
in its SSH_MSG_EXT_INFO, that the remote will handle global requests
as required by this document, regardless of any heuristic knowledge
the receiver may have about the remote party's software and version.
The receiver SHOULD enable any functionality that relies on global
requests if this extension is received.
4. Practical Uses of Global Requests
The following are some uses of the SSH_MSG_GLOBAL_REQUEST message
which are prevented or made difficult by software which incorrectly
disconnects when receiving a global request:
4.1. Active Keep-Alive
Network connections can terminate in ways that prevent SSH software
from immediately detecting the disconnection. The TCP stack might not
report the disconnection for minutes. Meanwhile resources used by the
previous session, such as port numbers for TCP forwarding, may remain
in use so that a reconnected client cannot resume its functions.
A common strategy to detect if the remote party is still connected is
to send a global request which the remote does not have to recognize,
only reply to. For example:
byte SSH_MSG_GLOBAL_REQUEST
string request-name = "keep-alive@implementation.example.com"
boolean want-reply = true
This requires the remote party to reply with SSH_MSG_REQUEST_FAILURE,
which is sufficient to confirm the connection is still active.
This strategy cannot be used if the remote party might disconnect on
receiving a global request.
4.2. Host Key Synchronization
A practical deficiency of SSH as standardized and widely used is that
it provides no mechanism for host key rollover. A server that wishes
to migrate its host key from e.g. DSA to RSA, or from RSA to
Curve25519, or from 1024-bit RSA to 3072-bit RSA, has no automated
way of informing clients of the intended new host key. Instead, server
administrators must contact all clients - which sometimes number in
thousands - where host key information must be updated manually. The
common result is that servers rarely change host keys until forced.
OpenSSH supports and documents an extension ([OPENSSH]) which uses a
global request named "hostkeys-00@openssh.com" to synchronize host
keys. After successful authentication, the server sends this request
to the client, listing all of the server's host keys. The client can
respond with a further request for the server to prove possession of
those host keys.
This mechanism cannot be used if the remote party might disconnect on
receiving a global request.
5. IANA Considerations
IANA is requested to update the "Secure Shell (SSH) Protocol
Parameters" registry established with [RFC4250], adding the following
entry in the table Extension Names [IANA-EXT]:
Extension Name Reference Note
global-requests-ok [this document] Section 3
6. Security Considerations
Security considerations appear where applicable in the document.
The security considerations of [RFC4251] also apply to this document.
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4251] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH)
Protocol Architecture", RFC 4251, January 2006.
[RFC4252] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Authentication Protocol", RFC 4252, January 2006.
[RFC4254] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Connection Protocol", RFC 4254, January 2006.
[RFC8308] Bider, D., "Extension Negotiation in the Secure Shell
(SSH) Protocol", RFC 8308, March 2018.
7.2. Informative References
[RFC4250] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH)
Protocol Assigned Numbers", RFC 4250, January 2006.
[OPENSSH] "OpenSSH deviations and extensions to the published SSH
protocol", <https://cvsweb.openbsd.org/src/usr.bin/ssh/
PROTOCOL?annotate=HEAD>.
[IANA-EXT] "Secure Shell (SSH) Protocol Parameters",
<https://www.iana.org/assignments/ssh-parameters/
ssh-parameters.xhtml#extension-names>.
Author's Address
Denis Bider
Bitvise Limited
4105 Lombardy Court
Colleyville, Texas 76034
United States of America
Email: ietf-ssh3@denisbider.com
URI: https://www.bitvise.com/
