IETF-SSH archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Transport I-D: KEXINIT reserved field needs description
The transport I-D defines the SSH_MSG_KEXINIT message:
     byte      SSH_MSG_KEXINIT
     byte[16]  cookie (random bytes)
     string    kex_algorithms
     string    server_host_key_algorithms
     string    encryption_algorithms_client_to_server
     string    encryption_algorithms_server_to_client
     string    mac_algorithms_client_to_server
     string    mac_algorithms_server_to_client
     string    compression_algorithms_client_to_server
     string    compression_algorithms_server_to_client
     string    languages_client_to_server
     string    languages_server_to_client
     boolean   first_kex_packet_follows
     uint32    0 (reserved for future extension)
Nothing is said about the semantics of the last field.
Can implementors describe how they handle non-zero values for the last
field of SSH_MSG_KEXINIT?
I propose the following change:
 - Name the last field of KEXINIT "extensions":
     byte      SSH_MSG_KEXINIT
     byte[16]  cookie (random bytes)
     string    kex_algorithms
     string    server_host_key_algorithms
     string    encryption_algorithms_client_to_server
     string    encryption_algorithms_server_to_client
     string    mac_algorithms_client_to_server
     string    mac_algorithms_server_to_client
     string    compression_algorithms_client_to_server
     string    compression_algorithms_server_to_client
     string    languages_client_to_server  
     string    languages_server_to_client
     boolean   first_kex_packet_follows 
     uint32    extensions
 - Describe the 'extensions' field and the semantics of extensions
   negotiation:
      extensions
	 Currently MUST always be set to zero (0).  If set to zero this
	 is the last item in this packet.  Future extensions to
	 SSH_MSG_KEXINIT may be defined by IETF RFCs which specify
	 non-zero values for this field and add fields to the end of the
	 packet.  Receipients MUST ignore any items in SSH_MSG_KEXINIT
	 packets past this field that if they do not know the extensions
	 value.
	 ["Implementations must be careful to include the entire
	   SSH_MSG_KEXINIT packets in the session ID hash, not just the
	   fields they know about." ??]
Cheers,
Nico
-- 
Home |
Main Index |
Thread Index |
Old Index