Internet-Draft D. Bider Expires: August 28, 2016 Bitvise Limited February 28, 2016 Fixed-Bandwidth Mode for SSH Channels draft-ssh-fixed-bandwidth-01.txt Abstract This memo defines a mechanism for SSH clients and servers to counter some types of traffic analysis, especially keystroke analysis, in SSH terminal session channels. 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) 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. Bider [Page 1] Internet-Draft Fixed-Bandwidth Mode for SSH Channels February 2016 1. Overview and Rationale Secure Shell (SSH) is a common protocol for secure communication on the Internet. Despite encryption, naive SSH terminal implementations are vulnerable to keystroke traffic analysis. When a user is typing, each keystroke results in a small packet sent to the server, and the server echoes the key back. The sizes and timings of packets betray how many keys the user has pressed, as well as what key combinations are most likely, because different key combinations cause subtle but consistently different delays. It is also possible to analyze non-keystroke traffic in the direction from the server to client. When a client makes a directory listing, the resulting encrypted TCP stream is distinguishable from viewing a man page, or running a SQL statement. This memo defines a mechanism intended to counter keystroke analysis, and to generally improve terminal session privacy. 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]. 2. Mechanism 2.1. Entering Fixed-Bandwidth Mode Because the SSH server will generally echo received keystrokes to the client, defending against keystroke analysis requires cooperation between the client and server. To enable fixed-bandwidth mode, the client sends the following channel request at any point after opening the channel [RFC4254]: byte SSH_MSG_CHANNEL_REQUEST uint32 remoteChannelNr string "fixed-bandwidth" bool wantReply uint32 burstWindowSeconds uint32 msBetweenTransmissions uint32 bytesPerTransmission This mechanism is mainly intended for channels of type "session" that are used for interactive terminal, but a client MAY use it for other channels. A server that responds positively to this request MUST enable fixed-bandwidth mode for that channel. A server MAY internally constrain parameters of this request to values it deems sensible. Bider [Page 2] Internet-Draft Fixed-Bandwidth Mode for SSH Channels February 2016 If a server responds negatively to this request, a client MAY still enter fixed-bandwidth mode for data sent in the direction from client-to-server. However, such a server is likely to echo keystrokes back to the client, defeating the effort. When fixed-bandwidth mode is requested by the client and confirmed by the server, the channel starts in the resting state. 2.1. Resting State In resting state, the channel waits either for an outgoing channel message to send, or for an incoming channel message received. Each of these is a triggering event. When a triggering event occurs - either a channel message is ready to send, or a channel message is received - this causes the channel to enter two or more consecutive burst windows. 2.2. Burst Window When a triggering event occurs, the channel enters a burst window of duration burstWindowSeconds. A channel returns to resting state at the end of a burst window - if, and only if, no triggering event occurred during the last burst window. If any channel message was sent or received during a burst window; even if this was only the initial event that started the burst; then the channel continues with another burst window of duration burstWindowSeconds. When the channel is in a burst window; instead of sending messages as it would outside this mechanism; the channel operates as follows: (1) The SSH implementation operates a timer. It checks if a message should be sent on the channel every msBetweenTransmissions. (2) If a channel message is to be sent, the implementation sends it as a transmission of size bytesPerTransmission; exceeding that size only if a message cannot be broken apart. Any further channel messages or data are left in queue until next sending opportunity. (3) If no channel message is to be sent, the implementation sends a transmission based on SSH_MSG_IGNORE of size bytesPerTransmission. The preceding treatment is applied to the following channel messages: SSH_MSG_CHANNEL_DATA SSH_MSG_CHANNEL_EXTENDED_DATA SSH_MSG_CHANNEL_WINDOW_ADJUST SSH_MSG_CHANNEL_REQUEST SSH_MSG_CHANNEL_SUCCESS SSH_MSG_CHANNEL_FAILURE SSH_MSG_CHANNEL_EOF SSH_MSG_CHANNEL_CLOSE Bider [Page 3] Internet-Draft Fixed-Bandwidth Mode for SSH Channels February 2016 2.3. Unencrypted Packet Lengths and Small Transmission Targets A small transmission target is a bytesPerTransmission parameter which does not exceed the maximum empty packet length currently achievable using maximum padding and respecting any block alignment requirements. When the session encryption algorithm uses unencrypted packet lengths, the parameter bytesPerTransmission MUST be coerced, each time at the point where it is used, to a small transmission target. When a small transmission target is in use, each transmission consists of a single packet; either SSH_MSG_IGNORE or a payload packet; padded to the transmission size, while respecting any block alignment. 2.4. Encrypted Packet Lengths and Non-Small Transmission Targets A non-small transmission target is a bytesPerTransmission parameter which DOES exceed the maximum empty packet length currently achievable using maximum padding and respecting any block alignment requirements. A non-small transmission target may be used ONLY if the session encryption algorithm uses encrypted packet lengths. When a non-small transmission target is in use, each transmission consists of two packets sent back-to-back. The first packet is either SSH_MSG_IGNORE, or a payload packet with minimal padding, respecting any block alignment. The second packet is an SSH_MSG_IGNORE such that total size reaches transmission size, subject to any block alignment. It is important that the encrypted back-to-back packets are delivered to the TCP layer as a single chunk. 2.5. Key Re-Exchange Key re-exchange may change session encryption parameters, including block alignment, MAC size, and whether packet lengths are encrypted. Key re-exchange may therefore change the way transmissions are sent, and the way bytesPerTransmission is interpreted by both parties. 3. IANA Considerations 3.1. Additions to existing tables IANA is requested to insert the following entry into the table Connection Protocol Channel Request Names under Secure Shell (SSH) Protocol Parameters [RFC4250]: Request Type Reference Note fixed-bandwidth [this document] Section 2.1 Bider [Page 4] Internet-Draft Fixed-Bandwidth Mode for SSH Channels February 2016 4. References 4.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4250] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH) Protocol Assigned Numbers", RFC 4250, January 2006. [RFC4254] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Connection Protocol", RFC 4254, January 2006. Bider [Page 5] Internet-Draft Fixed-Bandwidth Mode for SSH Channels February 2016 Author's Address Denis Bider Bitvise Limited Suites 41/42, Victoria House 26 Main Street GI Phone: +506 8315 6519 EMail: ietf-ssh3@denisbider.com URI: https://www.bitvise.com/ Bider [Page 6]