Server-Led Algorithm Preference in the Secure Shell (SSH) Protocol

Introduction SSH transport algorithm negotiation normally gives priority to the client's ordering of mutually supported algorithms . A server can limit the algorithms it offers, but ordering its offer does not normally determine which mutually supported algorithm is selected. This document defines an optional mechanism by which the client and server agree to use the server's preference order for a particular key exchange round. This permits a server to express preferences among its allowed algorithms without removing the alternatives from its offer. Where many clients connect to a server, this allows a server administrator to control algorithm preference at the server, instead of configuring many clients. The mechanism uses role-specific indicators in the kex_algorithms field of SSH_MSG_KEXINIT. This signaling approach follows the precedent established by . The mechanism defined here requires an indicator from both peers. It does not require SSH_MSG_EXT_INFO or either of the ext-info-c and ext-info-s indicators. This extension changes algorithm preference and specifies related host key synchronization requirements. It does not define new cryptographic algorithms or add messages. Agreement in the initial exchange also governs the negotiations described in .

Conventions and Terminology This document uses MUST, MUST NOT, SHOULD, and MAY as requirement terms with the meanings defined by BCP 14 ( and ). These meanings apply only to uppercase occurrences. The name-list data type is defined in . Field names in this document refer to the SSH_MSG_KEXINIT message defined in Section 7.1 of . A key exchange round consists of the client's and server's corresponding SSH_MSG_KEXINIT messages and the key exchange performed using those messages. This includes both the initial key exchange and each subsequent key re-exchange. The terms client and server retain their SSH connection roles. These roles do not depend on which peer initiates a key re-exchange or sends SSH_MSG_KEXINIT first.

Extension Negotiation

Indicators A client willing to use this extension for a key exchange round MAY include the name "server-algs-c" in the kex_algorithms field of its SSH_MSG_KEXINIT message. A server willing to use this extension for a key exchange round MAY include the name "server-algs-s" in the kex_algorithms field of its SSH_MSG_KEXINIT message. Sending an indicator expresses agreement to use server preference for the algorithm lists in the current exchange if the peer sends its corresponding indicator. In the initial exchange, this agreement also covers . It is not merely an announcement that the implementation understands the extension. A client MUST NOT send "server-algs-s", and a server MUST NOT send "server-algs-c". An implementation MAY disconnect upon receiving an indicator that is incorrect for the peer's role. An incorrect indicator does not satisfy either enabling condition in . The indicators are name-list entries, without quotation marks. Their position does not affect whether this extension is enabled. Implementations MUST recognize the appropriate indicator at ANY POSITION in the peer's kex_algorithms list. Implementations MUST accept any ordering relative to other indicators which are not key exchange method names, such as "ext-info-c" and "ext-info-s" (). This draft recommends that senders place their indicator after all actual key exchange method names; and before "ext-info-c" or "ext-info-s", if one is present. Neither indicator identifies a key exchange method. Implementations MUST NOT select either indicator as a key exchange method or use either indicator as the method of a guessed key exchange packet.

Enabling Conditions This extension is enabled for a key exchange round if and only if both of the following conditions hold:

The client's SSH_MSG_KEXINIT for that round contains "server-algs-c" in kex_algorithms.
The server's SSH_MSG_KEXINIT for that round contains "server-algs-s" in kex_algorithms.

When both conditions hold, both peers MUST use the selection rule in . Otherwise, this extension is not enabled and MUST NOT change the negotiation rules for that round. Only the two SSH_MSG_KEXINIT messages belonging to the current round are considered. An indicator sent in another round, knowledge of the peer's implementation, or cached knowledge of the peer's capabilities MUST NOT substitute for either enabling condition. Neither peer needs to wait for the other's SSH_MSG_KEXINIT before deciding whether to include its indicator.

Algorithm Selection When this extension is enabled, both peers MUST apply the algorithm negotiation procedure in Section 7.1 of with the server's preference order replacing the client's preference order. This replacement applies to each of the following fields:

kex_algorithms
server_host_key_algorithms
encryption_algorithms_client_to_server
encryption_algorithms_server_to_client
mac_algorithms_client_to_server
mac_algorithms_server_to_client
compression_algorithms_client_to_server
compression_algorithms_server_to_client

Important considerations apply to server_host_key_algorithms: see . Wherever the applicable negotiation procedure selects among mutually supported algorithms in client preference order, it MUST instead select in server preference order. For an independently negotiated list, this selects the first qualifying algorithm in the server's list that also occurs in the client's corresponding list. All selection conditions other than preference order remain applicable. In particular, the requirements relating the key exchange method to available and acceptable server host-key algorithms remain applicable. Algorithm-specific negotiation rules also remain applicable. These can constrain the combination of encryption and MAC algorithms or provide authentication without selecting a separate MAC algorithm. Server preference applies wherever the applicable procedure consults an algorithm list. It does not introduce a selection step that the procedure otherwise omits. In particular, when an encryption algorithm's specification makes the MAC lists irrelevant, this extension MUST NOT cause a separate MAC selection or a negotiation failure merely because those lists have no common entry. Changing preference order does not exchange client and server roles. The server still offers server host-key algorithms, and the client still states which server host-key algorithms it accepts. Directional fields retain their meanings: a client-to-server field is compared with the peer's client-to-server field, and likewise for server-to-client fields. Existing negotiation failure rules remain applicable. A failure to select the required algorithms MUST NOT cause an implementation to retry the same negotiation using client preference while this extension is enabled. The client continues to list its algorithms in its own preference order. That ordering is needed when this extension is not enabled and remains relevant to guessed-packet processing as described in .

Scope and Lifetime For SSH_MSG_KEXINIT, the preference rule applies to the two messages for the current round. It does not affect the languages_client_to_server or languages_server_to_client fields. Implementations MUST evaluate the enabling conditions anew for every key exchange round. Support or agreement in an earlier round does not carry forward. Either peer can omit its indicator in a later round, in which case this extension is not enabled for that later round. Conversely, the extension MAY be enabled during a key re-exchange even if it was not enabled during the initial key exchange or the immediately preceding round. The lifetime of the selection rule is distinct from the lifetime of the selected algorithms and keys. Algorithms and keys selected in a round are installed and remain in use according to the normal SSH rules. Completion of the round does not undo those selections. The initial exchange determines the preference used by qualifying negotiations outside SSH_MSG_KEXINIT, as specified in . The host key synchronization requirements in also have a connection-wide lifetime. Except for the changes explicitly specified in this document, other SSH extensions retain their enabling conditions, interpretation, and lifetime.

Server Host Key Algorithms A client that advertises "server-algs-c" and already has a basis for authenticating the server SHOULD exclude algorithms from its server_host_key_algorithms for which it has no such basis. This basis may be a trusted host key usable with the algorithm or, for a certificate algorithm, a trusted certification authority authorized to certify host keys for the server. This allows the server's preference to govern the selected host key and signature algorithm while limiting negotiation to algorithms for which the client already has a basis for authenticating the server. This filtering does not replace verification of the host key or certificate actually presented by the server. An algorithm name does not identify an individual host key. If the client's initial SSH_MSG_KEXINIT includes "server-algs-c", a server that recognizes this extension MUST NOT treat the client's server_host_key_algorithms lists as complete lists of supported host key algorithms, or use them to restrict the host keys published through a host key synchronization mechanism. This requirement applies for the rest of the connection, regardless of whether the server advertises "server-algs-s" or later client exchanges omit "server-algs-c". If the client first advertises "server-algs-c" during a later key exchange, the server MAY adopt this behavior for the rest of the connection. The client MUST NOT assume that the server does so. The server is not required to repeat earlier host key synchronization advertisements. Once a client advertises "server-algs-c" in any key exchange, it MUST NOT reject an otherwise valid host key synchronization advertisement solely because it includes keys using algorithms the client does not support or did not offer in server_host_key_algorithms. The client MAY ignore keys using unsupported algorithms or algorithms disallowed by local policy. Accepted keys remain subject to the synchronization mechanism's authentication and verification requirements. These client requirements apply for the rest of the connection, regardless of whether server preference was negotiated or either peer later omits its indicator.

Algorithm Negotiation Outside SSH_MSG_KEXINIT This section applies to bilateral algorithm negotiations with a connection-wide effect in which each peer supplies an ordered name-list and the ordinary selection procedure chooses one qualifying common algorithm in client preference order, as in SSH_MSG_KEXINIT. If both indicators were present in the initial key exchange, both peers MUST instead use server preference for such a negotiation. Otherwise, its ordinary preference rule applies. All other selection conditions remain unchanged. A specification defining such a negotiation MAY explicitly specify a different interaction with this extension. This rule applies to both directional algorithm lists in "delay-compression" (). The initial exchange governs this selection even if a later server SSH_MSG_EXT_INFO replaces its earlier advertisement. Subsequent key exchanges do not change this preference. The rules for activating delayed compression and replacing it with compression negotiated by a subsequent key exchange remain unchanged. The rule does not apply to "server-sig-algs" (), which advertises server capabilities for client public-key authentication rather than negotiating one algorithm from bilateral offers. Other lists that do not meet the conditions above also remain unaffected. Unrecognized extensions MUST continue to be ignored as required by their containing protocol.

Guessed Key Exchange Packets This extension does not change the meaning of first_kex_packet_follows or the rules for accepting or discarding a guessed key exchange packet. Under the rules in Section 7 of , differing first choices of key exchange method or server host-key algorithm still make a guess wrong. A guessed packet does not become acceptable merely because its method happens to equal the method selected using server preference. Any separately negotiated extension that changes guessed-packet processing retains its own rules. Where those rules refer to the negotiated algorithms, they refer to the algorithms selected for the current round, including the effect of this extension when enabled. A sender that sets first_kex_packet_follows to TRUE MUST place an actual key exchange method first in kex_algorithms. Placing the server preference indicator after the actual method names avoids interfering with this requirement.

Example For one traffic direction, suppose the client and server advertise the following encryption algorithm lists. The names "cipher-a" and "cipher-b" are illustrative placeholders, and both algorithms are assumed to satisfy all other selection conditions. If the client advertises "server-algs-c" and the server advertises "server-algs-s" in their respective kex_algorithms lists for this round, the selected encryption algorithm is "cipher-b". If either indicator is absent, the selection remains "cipher-a" under the ordinary client preference rule. If a subsequent round has the same encryption lists but only the server repeats its indicator, that subsequent round selects "cipher-a". The earlier agreement does not affect the subsequent selection.

Security Considerations Server preference can select a different algorithm from the one that client preference would select. It does not establish that the selected algorithm is stronger, faster, or otherwise preferable for the client's purposes. Each peer remains responsible for the algorithms it permits. A client that advertises "server-algs-c" agrees to let the server's ordering determine selection among the qualifying mutually supported algorithms. Algorithms that are unacceptable under the client's security policy must be excluded from its offer; placing them later in the list does not exclude their selection. A client may order server host-key algorithms to favor a key it already trusts. Server preference can result in selection of a different host-key algorithm. This extension does not authorize acceptance of an untrusted server host key or relax server authentication requirements. Implementations MUST preserve the complete, original SSH_MSG_KEXINIT payloads when those payloads are included in the key exchange's authenticated data. In particular, implementations MUST NOT remove these indicators or reorder name-lists in the authenticated representation when applying the selection rule. Authentication of the key exchange transcript protects the indicators and advertised order in the same way as the other SSH_MSG_KEXINIT contents. This extension adds no separate authentication mechanism and does not replace the security requirements of the selected key exchange and transport algorithms.

IANA Considerations The author acknowledges that current procedures for IANA SSH registry additions may require a threshold which this draft does not meet. This draft describes registry additions which would be requested if the required threshold was met. IANA is requested to add the following entries to the "Key Exchange Method Names" registry within the "Secure Shell (SSH) Protocol Parameters" registry group. The existing Expert Review registration policy is specified in . Server Algorithm Preference Indicators

Method Name	Reference	Note	OK to Implement
server-algs-c	This document	Client negotiation indicator; not a key exchange method	MAY
server-algs-s	This document	Server negotiation indicator; not a key exchange method	MAY

IANA is also requested to update the "iana-ssh-key-exchange-algs" YANG module to reflect these registrations, following Section 6.6 of . This document does not request entries in the "Extension Names" registry and does not allocate an SSH message number.

Existing Implementations This extension is being implemented in Bitvise SSH Server versions 9.67 and higher. The extension is initially intended for server-to-server connections, where it is desirable for a central server to govern algorithm preferences for other servers connecting as clients.

AI Disclosure A recent, advanced Large Language Model was used at maximum effort settings to generate the initial version of this draft, and to revise it following review by the author.