RFC 4253, "The Secure Shell (SSH) Transport Layer Protocol", January 2006Source of RFC: secsh (sec)
See Also: RFC 4253 w/ inline errata
Errata ID: 4533
Publication Format(s) : TEXT
Reported By: denis bider
Date Reported: 2015-11-13
Verifier Name: Paul Wouters
Date Verified: 2023-07-28
Section 7.1 says:
[[ A paragraph is missing in this section to clarify implementation requirements for the reserved field. This paragraph could suitably be inserted after the description of first_kex_packet_follows. ]]
It should say:
(reserved field) Servers and clients may or may not be aware of a future extension to this RFC that specifies a use for this field. Servers and clients that are NOT aware of such an extension: - MUST send this field with value zero; - MUST NOT act on any value of this field when received, whether the received value is zero or non-zero; - in key exchange, MUST properly hash the actual received value of this field. This behavior is REQUIRED to allow use of this field in future protocol extension.
RFC 4253 defines the KEXINIT reserved field as follows:
uint32 0 (reserved for future extension)
This has in practice not been sufficient for developers to understand the requirements for sending and handling this field.
At least one common implementation will currently fail key exchange if the field is non-zero, because it forgets to decode it, and just assumes it is always zero.
At least one other implementation will currently disconnect if the field is non-zero, because it takes the above definition to mean that the field must be zero when received.
The above paragraph clarifies the correct treatment of this field. This has been discussed during November 2015 with other implementers on the "email@example.com" mailing list. There appears to be consensus that the above is the correct treatment.