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