RE: SFTP version negotiation

[Richard Whalen <Whalenr%process.com@localhost>]

We have not implemented version 5, and though I currently do not foresee
implementing version 6, the proposed version negotiation scheme based
upon the extended command could facilitate our implementation of
version 6 as the channel closing scheme that I mentioned would not
work with our implementation.  Because of this I favor this mechanism
of re-negotiating the version.

Richard Whalen

-----Original Message-----
From: Joseph Galbraith [mailto:galb-list%vandyke.com@localhost]
Sent: Tuesday, October 05, 2004 11:20 AM
To: Henrick Hellström
Cc: ietf-ssh%netbsd.org@localhost
Subject: Re: SFTP version negotiation


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