Clarification to the channel closure procedure in Secure Shell (SSH)
draft-sgtatham-secsh-closure-race-01

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 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 2. Conventions Used in this Document
• 3. Ambiguity
• 4. Resolution
• 5. Rationale
• 6. Security Considerations
• 7. Acknowledgements
• 8. References
• 8.1. Normative References
• 8.2. Informative References
• Authors' Addresses

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?

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:

• 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:

• 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.
• 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.
• 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).

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 author is indebted to Matt Johnston, Denis Bider, Niels Moller, and Damien Miller for discussion of this question.

This document was written using the xml2rfc tool described in [RFC2629].

8. References

8.1. Normative References

8.2. Informative References

Authors' Addresses