Re: SFTP version negotiation

[Joseph Galbraith <galb-list%vandyke.com@localhost>]

Henrick Hellström wrote:
> Just a thought...
>
> What happens if a SFTP server supports v3 and v4, and a client that 
> supports v3 and v6 only connects?
>
> According to the latest draft, they are supposed to start v4, since the 
> client will send v6 and the server supports at most v4, and v4 is the 
> least of these two numbers.
>
> Quoted from draft 05:
>
> 4. Protocol Initialization
>
>    When the file transfer protocol starts, the client first sends a
>    SSH_FXP_INIT (including its version number) packet to the server. The
>    server responds with a SSH_FXP_VERSION packet, supplying the lowest
>    of its own and the client's version number.  Both parties should from
>    then on adhere to particular version of the protocol.

This has been a concern of mine for a while.  The best solution I've 
been able to come up with (better than closing channel, I think) is this:

> If the client supports non-contigous version, for example,
> versions 2,3, and 6, then the INIT/VERSION negotiation
> is insufficient.  In order to gaurentee a successful
> connection, the MUST send the highest version for which
> it supports all previos version (because the server
> might pick the version the client sends or any
> previous version.)
>
> However, in order to work around this limit in the
> deployed protocol implementations, after the
> INIT/VERSION exchange is complete, if the version
> negotiated is at least 3, the version where extensions was
> introduced, the client MAY send the following extension
> to attempt to negotiate a higher version:
>
>   byte SSH_FXP_EXTENDED
>   uint32 request-id
>   string "version-negotiate"
>   uint32 highest version-supported
>   uint32 2nd highest version-supported
>   ...
>   uint32 lowest version-supported
>
> The client must not send any other packets after sending
> this extension until it recieves the response.  The server
> responds with a similar response:
>
> The server then responds with:
>
>   byte SSH_FXP_EXTENDED_REPLY
>   uint32 request-id
>   uint32 highest version-supported
>   uint32 2nd highest version-supported
>   ...
>   uint32 lowest version-supported
>
> The new negotiated version to use is the
> first value that appears on both list, or,
> in other words, the highest version supported
> by both the client and the server.  This
> version MUST be at least as high as the
> previous negotiated version.
>
> The next packet sent after the "version-negotiate"
> request by the client, and the next packet sent
> by the server after the reply will conform to
> the new version.
>
> The server includes it's entire list of supported
> versions rather than just the negotiated version
> in order to assist in trouble shooting on the
> client side.

I believe this mechanism maintains backwards compatibility
and gives us the version exchange we now wish we'd had
originally :-)

Thanks,

Joseph