]> Bitvise Limited

4105 Lombardy Court Colleyville, Texas 76034 United States of America ietf-ssh3@denisbider.com https://www.bitvise.com/

This memo updates RFC 4252, RFC 4253, and RFC 4254 to define a mechanism for SSH clients and servers to exchange information about supported protocol extensions confidentially after SSH key exchange.

Secure Shell (SSH) is a common protocol for secure communication on the Internet. The original design of the SSH transport layer lacks proper extension negotiation. Meanwhile, diverse implementations take steps to ensure that known message types contain no unrecognized information. This makes it difficult for implementations to signal capabilities and negotiate extensions without risking disconnection. This obstacle has been recognized in relationship with , where the need arises for a client to discover public key algorithms a server accepts, to avoid authentication penalties and trial-and-error. This memo updates RFC 4252, RFC 4253, and RFC 4254.

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 .

The wire encoding types in this document - "byte", "uint32", "string", "boolean", "name-list" - have meanings as described in .

Applications implementing this mechanism MUST add one of the following indicator names to the field "kex_algorithms" in the SSH_MSG_KEXINIT message sent by the application in the first key exchange: When acting as server: "ext-info-s" When acting as client: "ext-info-c" The indicator name is added without quotes, and MAY be added at any position in the name-list, subject to proper separation from other names as per name-list conventions. The names are added to the "kex_algorithms" field because this is one of two name-list fields in SSH_MSG_KEXINIT that do not have a separate copy for each data direction. The indicator names inserted by the client and server are different to ensure these names will not produce a match, and therefore not affect the algorithm chosen in key exchange algorithm negotiation. The inclusion of textual indicator names is intended to provide a clue for implementers to discover this mechanism.

If a client or server offers "ext-info-c" or "ext-info-s" respectively, it MUST be prepared to accept an SSH_MSG_EXT_INFO message from the peer. A server only needs to send "ext-info-s" if it intends to process SSH_MSG_EXT_INFO from the client. A client only needs to send "ext-info-c" if it plans to process SSH_MSG_EXT_INFO from the server. If a server receives an "ext-info-c", or a client receives an "ext-info-s", it MAY send an SSH_MSG_EXT_INFO message, but is not required to do so. Neither party needs to wait for the other's SSH_MSG_KEXINIT in order to decide whether to send the appropriate indicator in its own SSH_MSG_KEXINIT. Implementations MUST NOT send an incorrect indicator name for their role. Implementations MAY disconnect if the counter-party sends an incorrect indicator. If "ext-info-c" or "ext-info-s" ends up being negotiated as a key exchange method, the parties MUST disconnect.

A party that received the "ext-info-c" or "ext-info-s" indicator MAY send the following message:

Implementers' attention is called to ., in particular the requirement to tolerate any sequence of bytes - including null bytes at any position - in an unknown extension's extension-value.

If a client sends SSH_MSG_EXT_INFO, it MUST send it as the next packet following the client's first SSH_MSG_NEWKEYS message to the server. If a server sends SSH_MSG_EXT_INFO, it MAY send it at zero, one, or both of the following opportunities: As the next packet following the server's first SSH_MSG_NEWKEYS. Where clients need information in the server's SSH_MSG_EXT_INFO to authenticate, it is helpful if the server sends its SSH_MSG_EXT_INFO not only as next packet after SSH_MSG_NEWKEYS, but without delay. Clients cannot rely on this because the server is not required to send the message at this time; and if sent, it may be delayed by the network. However, if a timely SSH_MSG_EXT_INFO is received, a client can pipeline an authentication request after its SSH_MSG_SERVICE_REQUEST, even when it needs extension information. Immediately preceding the server's SSH_MSG_USERAUTH_SUCCESS, as defined in . The server MAY send SSH_MSG_EXT_INFO at this second opportunity, whether or not it sent it at the first. A client that sent "ext-info-c" MUST accept a server's SSH_MSG_EXT_INFO at both opportunities, but MUST NOT require it. This allows a server to reveal support for additional extensions that it was unwilling to reveal to an unauthenticated client. If a server sends a second SSH_MSG_EXT_INFO, this replaces any initial one, and both the client and the server re-evaluate extensions in effect. The server's second SSH_MSG_EXT_INFO is matched against the client's original. The timing of the second opportunity is chosen for the following reasons. If the message was sent earlier, it would not allow the server to withhold information until the client has authenticated. If it was sent later, a client that needs information from the second SSH_MSG_EXT_INFO immediately after it authenticates would have no way to reliably know whether to expect the message.

Each extension is identified by its extension-name, and defines the conditions under which the extension is considered to be in effect. Applications MUST ignore unrecognized extension-names. An extension MAY dictate, where it is specified, that in order to take effect, both parties must include it in their SSH_MSG_EXT_INFO; or it can be sufficient that only one party includes it; or other rules MAY be specified. The relative order in which extensions appear in an SSH_MSG_EXT_INFO message MUST be ignored. Extension-value fields are interpreted as defined by their respective extension. This field MAY be empty if permitted by the extension. Applications that do not implement or recognize an extension MUST ignore its extension-value, regardless of its size or content. Applications MUST tolerate any sequence of bytes - including null bytes at any position - in an unknown extension's extension-value. The cumulative size of an SSH_MSG_EXT_INFO message is limited only by the maximum packet length that an implementation may apply in accordance with . Implementations MUST accept well-formed SSH_MSG_EXT_INFO messages up to the maximum packet length they accept.

string "server-sig-algs" name-list public-key-algorithms-accepted The name-list type is a strict subset of the string type, and is thus permissible as an extension-value. See for more information. This extension is sent by the server, and contains a list of public key algorithms that the server is able to process as part of a "publickey" authentication request. If a client sends this extension, the server MAY ignore it, and MAY disconnect. In this extension, a server MUST enumerate all public key algorithms it might accept during user authentication. However, there exist early server implementations which do not enumerate all accepted algorithms. For this reason, a client MAY send a user authentication request using a public key algorithm not included in "server-sig-algs". A client that wishes to proceed with public key authentication MAY wait for the server's SSH_MSG_EXT_INFO so it can send a "publickey" authentication request with an appropriate public key algorithm, rather than resorting to trial and error. Servers that implement public key authentication SHOULD implement this extension. If a server does not send this extension, a client MUST NOT make any assumptions about the server's public key algorithm support, and MAY proceed with authentication requests using trial and error. Note that implementations are known to exist that apply authentication penalties (*) if the client attempts to use an unexpected public key algorithm. (*) Authentication penalties are applied by servers to deter brute force password guessing, username enumeration, and other types of behavior deemed suspicious by server administrators or implementers. Penalties may include automatic IP address throttling or blocking, and may trigger email alerts or auditing.

The extension-value is a string that encodes two name-lists. The name-lists themselves have the encoding of strings. For example: to indicate a preference for algorithms "foo,bar" in the client-to-server direction, and "bar,baz" in the server-to-client direction, a sender encodes the extension-value as follows (including its length): 00000016 00000007 666f6f2c626172 00000007 6261722c62617a This same encoding could be sent by either party - client or server. This extension allows the server and client to renegotiate compression algorithm support without having to conduct a key re-exchange, putting new algorithms into effect immediately upon successful authentication. This extension takes effect only if both parties send it. Name-lists MAY include any compression algorithm that could have been negotiated in SSH_MSG_KEXINIT, except algorithms that define their own delayed compression semantics. This means "zlib,none" is a valid algorithm list in this context; but "zlib@openssh.com" is not. If both parties send this extension, but the name-lists do not contain a common algorithm in either direction, the parties MUST disconnect in the same way as if negotiation failed as part of SSH_MSG_KEXINIT. If this extension takes effect, the renegotiated compression algorithm is activated for the very next SSH message after the trigger message: - Sent by the server, the trigger message is SSH_MSG_USERAUTH_SUCCESS. - Sent by the client, the trigger message is SSH_MSG_NEWCOMPRESS. If this extension takes effect, the client MUST send the following message within a reasonable number of outgoing SSH messages after receiving SSH_MSG_USERAUTH_SUCCESS - but not necessarily as the first such outgoing message: SSH_MSG_NEWCOMPRESS (value 8) The purpose of SSH_MSG_NEWCOMPRESS is to avoid a race condition where the server cannot reliably know whether a message sent by the client was sent before or after receiving the server's SSH_MSG_USERAUTH_SUCCESS. For example, clients may send keep-alive messages during logon processing. As is the case for all extensions unless otherwise noted, the server MAY delay including this extension until its secondary SSH_MSG_EXT_INFO, sent before SSH_MSG_USERAUTH_SUCCESS. This allows the server to avoid advertising compression until the client has authenticated. If the parties re-negotiate compression using this extension in a session where compression is already enabled; and the re-negotiated algorithm is the same in one or both directions; then the internal compression state MUST be reset for each direction at the time the re-negotiated algorithm takes effect.

A party that has signaled, or intends to signal, support for this extension in an SSH session, MUST NOT initiate key re-exchange in that session until either of the following occurs: This extension was negotiated, and the party that's about to start key re-exchange already sent its trigger message for compression. The party has sent (if server) or received (if client) the message SSH_MSG_USERAUTH_SUCCESS, and this extension was not negotiated. If a party violates this rule, the other party MAY disconnect. In general, parties SHOULD NOT start key re-exchange before successful user authentication, but MAY tolerate it if not using this extension.

In subsequent key re-exchanges that unambiguously begin after the compression trigger messages, the compression algorithms negotiated in re-exchange override the algorithms negotiated with this extension.

This extension uses a binary extension-value encoding. OpenSSH clients up to and including version 7.5 advertise support to receive SSH_MSG_EXT_INFO, but disconnect on receipt of an extension-value containing null bytes. This is an error fixed in OpenSSH version 7.6. Implementations that wish to interoperate with OpenSSH 7.5 and earlier are advised to check the remote party's SSH version string, and omit this extension if an affected version is detected. Affected versions do not implement this extension, so there is no harm in omitting it. The extension SHOULD NOT be omitted if the detected OpenSSH version is 7.6 or higher. This would make it harder for the OpenSSH project to implement this extension in a higher version.

string "no-flow-control" string choice of: "p" for preferred | "s" for supported A party SHOULD send "s" if it supports "no-flow-control", but does not prefer to enable it. A party SHOULD send "p" if it prefers to enable the extension if the other party supports it. Parties MAY disconnect if they receive a different extension value. To take effect, this extension MUST be: Sent by both parties. At least one party MUST have sent the value "p" (preferred). If this extension takes effect, the "initial window size" fields in SSH_MSG_CHANNEL_OPEN and SSH_MSG_CHANNEL_OPEN_CONFIRMATION, as defined in , become meaningless. The values of these fields MUST be ignored, and a channel behaves as if all window sizes are infinite. Neither side is required to send any SSH_MSG_CHANNEL_WINDOW_ADJUST messages, and if received, such messages MUST be ignored. This extension is intended, but not limited to, use by file transfer applications that are only going to use one channel, and for which the flow control provided by SSH is an impediment, rather than a feature. Implementations MUST refuse to open more than one simultaneous channel when this extension is in effect. Nevertheless, server implementations SHOULD support clients opening more than one non-simultaneous channel.

Before this extension, some applications would simply not implement SSH flow control, sending an initial channel window size of 2^32 - 1. Applications SHOULD NOT do this for the following reasons: It is plausible to transfer more than 2^32 bytes over a channel. Such a channel will hang if the other party implements SSH flow control according to . There exist implementations which cannot handle large channel window sizes, and can exhibit non-graceful behaviors, including disconnect.

The terms "elevation" and "elevated" refer to an operating system mechanism where an administrator user's logon session is associated with two security contexts: one limited, and one with administrative rights. To "elevate" such a session is to activate the security context with full administrative rights. For more information about this mechanism on Windows, see also and .

A client sends "y" to indicate its preference that the session should be elevated; "n" to not be elevated; and "d" for the server to use its default behavior. The server MAY disconnect if it receives a different extension value. If a client does not send the "elevation" extension, the server SHOULD act as if "d" was sent. If a client has included this extension, then after authentication, a server that supports this extension SHOULD indicate to the client whether elevation was done by sending the following global request:

Clients that implement this extension help reduce attack surface for Windows servers that handle administrative logins. Where clients do not support this extension, servers must elevate sessions to allow full access by administrative users always. Where clients support this extension, sessions can be created without elevation unless requested.

IANA is requested to insert the following entries into the table Message Numbers under Secure Shell (SSH) Protocol Parameters :

IANA is requested to insert the following entries into the table Key Exchange Method Names :

Also under Secure Shell (SSH) Protocol Parameters, IANA is requested to create a new table, Extension Names, with initial content:

Names in the Extension Names table MUST follow the Conventions for Names defined in , Section 4.6.1. Requests for assignments of new non-local names in the Extension Names table (i.e. names not including the '@' character) MUST be done through the IETF CONSENSUS method, as described in .

Security considerations are discussed throughout this document. This document updates the SSH protocol as defined in and related documents. The security considerations of apply.

&RFC2119; &RFC4250; &RFC4251; &RFC4252; &RFC4253; &RFC4254; &RFC8126;

Thanks to Markus Friedl and Damien Miller for comments and initial implementation. Thanks to Peter Gutmann, Roumen Petrov, Mark D. Baushke, Daniel Migault, Eric Rescorla, Matthew A. Miller, Mirja Kuehlewind, Adam Roach, Spencer Dawkins, Alexey Melnikov, and Ben Campbell for reviews and feedback.