RE: SFTP version negotiation

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

I think that this would be very unusual, as each new version has been a
superset of protocol of the previous version.

One option that the client could take would be to send an
SSH_MSG_CHANNEL_CLOSE, which will close the SFTP server, then go back to the
sequence of SSH_MSG_CHANNEL_OPEN, SSH_MSG_CHANNEL_REQUEST for the subsystem,
but this time drop the version of SFTP requested to 3 in the SSH_FXP_INIT
packet.  This method of negotiation may not be possible in all
implementations.

Another option, would be to add language to the draft specifying that an
implementation must be able to support all lower version numbers.  This
would require that the draft continue to include sufficient history to allow
developers to keep track of what was added in the various versions.

-----Original Message-----
From: Henrick Hellström [mailto:henrick%streamsec.se@localhost]
Sent: Sunday, October 03, 2004 6:59 AM
To: ietf-ssh%netbsd.org@localhost
Subject: SFTP version negotiation


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.