Internet DRAFT - draft-sgtatham-secsh-closure-race
draft-sgtatham-secsh-closure-race
Network Working Group S. Tatham
Internet-Draft PuTTY
Intended status: Standards Track D. Miller
Expires: November 4, 2016 OpenSSH
May 3, 2016
Clarification to the channel closure procedure in Secure Shell (SSH)
draft-sgtatham-secsh-closure-race-02
Abstract
This memo identifies an ambiguity in the Secure Shell (SSH)
connection protocol defined by RFC 4254 regarding the handling of
channel closure in combination with channel requests requiring a
reply, and issues a clarification specifying the correct
interpretation of the ambiguous point.
Status of This Memo
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). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on November 4, 2016.
Copyright Notice
Copyright (c) 2016 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
Tatham & Miller Expires November 4, 2016 [Page 1]
Internet-Draft Clarification to channel closure in SSH May 2016
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in this Document . . . . . . . . . . . . . . 3
3. Ambiguity . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Resolution . . . . . . . . . . . . . . . . . . . . . . . . . 3
5. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 4
6. Security Considerations . . . . . . . . . . . . . . . . . . . 5
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
8.1. Normative References . . . . . . . . . . . . . . . . . . 6
8.2. Informative References . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction
The Secure Shell (SSH) connection protocol [RFC4254] multiplexes many
bidirectional communications ('channels') over a single data stream.
In addition to sending data in both directions as a stream of bytes,
these channels also permit the sending of assorted types of 'channel
request' in both directions. Channel request messages have a flag
called 'want reply' which, if set, requires the recipient of the
request to respond with a success or failure message (or some other
specific response message if the request type defines one).
Because channel requests have no identifying number, the only way
that a request sender can identify which response goes with which
request is by their ordering. As a result, it is important that a
request receiver reply to a request if and only if it has the "want
reply" flag set, as required by [RFC4254] section 5.4.
(Implementations have been known to make mistakes on this in the
past.)
Channels may be closed at any time, by sending and receiving the
SSH_MSG_CHANNEL_CLOSE message. After a party has both sent and
received a close message for a channel, that channel is closed from
the point of view of that party, and it may reuse the channel's
identifying number.
The question therefore arises: if a party has initiated channel
closure by sending its close message, and then it receives a channel
request with "want reply" set, should it reply?
Tatham & Miller Expires November 4, 2016 [Page 2]
Internet-Draft Clarification to channel closure in SSH May 2016
2. Conventions Used in this Document
The key phrase "MUST NOT" in this document is to be interpreted as
described in [RFC2119].
3. Ambiguity
The wording of [RFC4254] fails to unambiguously specify what should
be done in this situation.
Section 5.4 states that channel requests must be replied to if they
have "want reply" set, and does not make any exception for channels
in the process of being closed. This suggests that if the request-
recipient does not respond to the request, it is in violation of
section 5.4.
However, suppose the request sender now sends its own channel close
message, having received the close message from the request
recipient. Now the request sender has both sent and received
SSH_MSG_CHANNEL_CLOSE, and according to section 5.3, it is permitted
to reuse the channel number immediately. So if the request
receiver's response now arrives, a sender which has indeed reused the
channel number will not be expecting it. This suggests if the
request recipient does respond to the request, it is potentially in
violation of section 5.3.
In other words, a request recipient placed in this situation has no
viable response which does not violate, or risk violating, one or
other term of [RFC4254]. The specification is thus self-
contradictory, and needs clarification.
4. Resolution
This memo resolves the ambiguity by specifying the correct one of the
above interpretations.
The resolution is as follows: a request recipient MUST NOT send any
response to a channel request if it has already sent
SSH_MSG_CHANNEL_CLOSE on the same channel. This introduces an
exception to section 5.4 of [RFC4254], and preserves the invariant
intended by section 5.3.
Specifically, users of [RFC4254] should replace the first sentence of
the third paragraph of section 5.4:
If 'want reply' is FALSE, no response will be sent to the request.
with the text:
Tatham & Miller Expires November 4, 2016 [Page 3]
Internet-Draft Clarification to channel closure in SSH May 2016
If 'want reply' is FALSE, or if the sender has already sent
SSH_MSG_CHANNEL_CLOSE for the channel, then the sender MUST NOT
send a reply.
5. Rationale
The choice of resolution is based on consensus among SSH
implementors, following a discussion in which several points were
made in favour of this decision:
o If the channel is already in the process of closing, it is likely
that any resources associated with the channel have already been
deleted by the request receiver, so it would be unlikely to be
able to successfully handle any request. Hence, responses to
requests in this situation would almost certainly be
SSH_MSG_REQUEST_FAILURE, and therefore this should simply be
inferred.
o To make the other decision (i.e. requiring recipients to respond
to requests even after channel closure) adds complexity on the
side of the request sender, which now requires an additional state
in its channel state machine for the situation in which
SSH_MSG_CHANNEL_CLOSE has been both sent and received but one or
more "want reply" channel requests are still outstanding.
o The apparent intent of section 5.3 (though not explicitly stated)
is for SSH_MSG_CHANNEL_CLOSE to be the final message sent by each
party in regard to each channel, and the clarification suggested
here preserves that simple property.
The protocol change is believed to eliminate the race condition,
because it bases the decision of whether to send a response on
information both sides can agree on, namely the ordering of two
messages going in the same direction. The request recipient sends a
response to a channel request (which has 'want reply' set) if and
only if it has not sent SSH_MSG_CHANNEL_CLOSE first; therefore, the
request sender knows that it should expect to receive a response if
and only if it does not receive SSH_MSG_CHANNEL_CLOSE first (or
rather, it should wait for either SSH_MSG_CHANNEL_CLOSE or a request
response, whichever comes first). Hence, neither party needs to make
a decision based on the relative ordering of messages sent in
opposite directions (which would risk reintroducing a race, because
the two parties would not necessarily observe those messages in the
same order).
Tatham & Miller Expires November 4, 2016 [Page 4]
Internet-Draft Clarification to channel closure in SSH May 2016
6. Security Considerations
No security issues are believed to be introduced by this change.
The SSH connection protocol is intended to run inside the SSH
transport protocol [RFC4253], which protects the content of the
connection protocol stream against eavesdropping and active
modification by malicious third parties. As a result, changes within
the connection protocol itself need not consider questions of
external interference with the sequence of messages.
One attack still available to a malicious third party able to modify
TCP packets on the way past is to delay one or both directions of the
connection. It is therefore worth asking whether any race conditions
are introduced by this change which such an attacker might
deliberately induce to deny service. However, it is believed not: as
discussed in the previous section, the request sender's decision
about whether or not to expect a response message is based on the
ordering of messages within a single direction of the connection, so
no adjustment of the relative timing of the two directions will
affect that ordering.
(This is not an argument in favour of this particular choice of
resolution to the ambiguity, since a similar and equally good
argument against race conditions would have applied if this memo had
specified the opposite resolution.)
Another threat model worth considering is the one in which the client
and server do not trust one another. No additional security hazards
are believed to be introduced by this clarification in that situation
either: the only possible security effect of altering the legality of
sending a message in a particular stage of the protocol is to enable
or disable one party to confuse the other by sending an illegal
message on purpose - but many other illegal messages still exist
(e.g. referring to a channel number that has never existed) so
neither party's ability to do this has changed.
7. Acknowledgements
The authors are indebted to Matt Johnston, Denis Bider and Niels
Moller for discussion of this question.
This document was written using the xml2rfc tool described in
[RFC2629].
Tatham & Miller Expires November 4, 2016 [Page 5]
Internet-Draft Clarification to channel closure in SSH May 2016
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC4254] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Connection Protocol", RFC 4254, DOI 10.17487/RFC4254,
January 2006, <http://www.rfc-editor.org/info/rfc4254>.
8.2. Informative References
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
DOI 10.17487/RFC2629, June 1999,
<http://www.rfc-editor.org/info/rfc2629>.
[RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253,
January 2006, <http://www.rfc-editor.org/info/rfc4253>.
Authors' Addresses
Simon Tatham
PuTTY
Email: anakin@pobox.com
Damien Miller
OpenSSH
Email: djm@openssh.com
Tatham & Miller Expires November 4, 2016 [Page 6]
