RFC Errata

Errata Search

Source of RFC  
Summary Table Full Records

RFC 4253, "The Secure Shell (SSH) Transport Layer Protocol", January 2006

Note: This RFC has been updated by RFC 6668, RFC 8268, RFC 8308, RFC 8332, RFC 8709, RFC 8758, RFC 9142

Source of RFC: secsh (sec)
See Also: RFC 4253 w/ inline errata

Errata ID: 4533
Status: Verified
Type: Technical
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 "ietf-ssh@netbsd.org" mailing list. There appears to be consensus that the above is the correct treatment.

Report New Errata

Advanced Search