Internet DRAFT - draft-ssh-fixed-bandwidth
draft-ssh-fixed-bandwidth
Internet-Draft D. Bider
Expires: August 28, 2016 Bitvise Limited
February 28, 2016
Fixed-Bandwidth Mode for SSH Channels
draft-ssh-fixed-bandwidth-02.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 (milliseconds)
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.2. 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.3. 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.4. 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.5. Encrypted Packet Lengths and Multi-Packet Transmission Targets
A multi-packet 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 multi-packet transmission target may be used ONLY if the session
encryption algorithm uses encrypted packet lengths.
When a multi-packet 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.6. 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.
2.7. Permissive Receiving
A receiver MAY implement logic to verify a sender's conformance to
this specification. If a receiver detects a sender's non-conformance,
it MAY output a diagnostic message, but it MUST NOT disconnect.
Detection of apparent non-conformance is not in itself proof that the
sender is not employing a different, potentially effective strategy.
Bider [Page 4]
Internet-Draft Fixed-Bandwidth Mode for SSH Channels February 2016
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
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]
