RE: future SFTP version question

["denis bider" <ietf-ssh%denisbider.com@localhost>]

Technically speaking, an extension to the SFTP protocol could be implemented
in which the server would testify (with a digital signature) that a file of
a certain name, attributes and contents existed on the server at a certain
time.

Whether or not this file was uploaded entirely by a certain user would be a
more complex challenge because SFTP has no such concept as "uploading" or
"downloading" a whole file. You have random access and you can pretty much
scratch anywhere you want in the remote filesystem.

An extension that would produce a certificate of a file's existence at a
certain time would be fairly straightforward. Provide an extension request
type for requesting the certificate, and define the contents of a receipt.

If providing a certificate of the file's existence on the server is
insufficient, and you must really provide a receipt which includes
information about the act of uploading, this could be done, too. For
example, a file for which you require an upload receipt must be opened with
a certain flag or set of flags which signal that you're going to do
receipted-uploading. When you open the file, you are allowed to append to
the file only (like uploading in TEXT mode). When you close it, the server
sends a RECEIPT message rather than STATUS. The format of the RECEIPT
message is what needs to be defined.

Whether or not this is something for a separate Internet-Draft (documenting
the SFTP extension) or something that can be added to SFTP itself as an
optional feature is, I guess, up for the workgroup or the SFTP draft editor
to decide. In my view, the first solution type (certificate of file's
existence) would be more apt for a separate draft because it is fairly
orthogonal to existing functionality. The second solution type (certificate
of the upload act with special flags for opening the file) might be better
documented in SFTP itself because of the flag's definition.

If the 2nd solution (upload receipt) is required, a question to answer is:
what if the user needs to upload an extremely large file and the connection
breaks? Should the "upload receipt" process allow for a file to be resumed?
If so, how do you know that the file being resumed is one that was actually
uploaded in a previous session by the same user, and that it wasn't lying
there on the server belonging to someone else?

denis


> -----Original Message-----
> From: ietf-ssh-owner%NetBSD.org@localhost 
> [mailto:ietf-ssh-owner%NetBSD.org@localhost] On Behalf Of jason bailey
> Sent: Wednesday, October 27, 2004 14:10
> To: Jon Bright
> Cc: ietf-ssh%NetBSD.org@localhost
> Subject: Re: future SFTP version question
> 
> 
> Exactly. 
> 
> A receipt provides proof that a given file was delivered at a 
> specific time.
> 
> Receipts usually contains information like file name, a 
> fingerprint(hash), and a time stamp which is then signed by 
> the servers private key. It's part of a non-repudiation process.
> 
> To give an example. I deal with the transfer of data from my 
> companies production network to a variety of third party 
> organizations. For the majority of file transfers SFTP fits 
> my needs. However there are occasions where the data is 
> sensitive enough, or we have some sort of time based 
> contractual obligation, where it is necessary for us to get a 
> receipt of transfer.
> 
> Right now my options are to go with some heavy weight B2B 
> protocol which requires a team of engineers and an architect 
> to get set up properly. Or implement our own solution, which 
> inevitably results in placing some form of server (of our 
> devising) on another companies network. This tends to make 
> their network people very antsy.
> 
> If I could get a receipt capability into a standard like 
> SFTP. It would allow me promote SFTP over all the other 
> options. It would make my management happy, and would make my 
> company dealings with other companies a lot smoother.
> 
> Jason
> 
> 
> On Wed, 2004-10-27 at 02:16, Jon Bright wrote:
> > Hi,
> > 
> > jason bailey wrote:
> > > Would it be within scope to suggest that a future version of the 
> > > SFTP server provide a signed receipt of the file transfer(on 
> > > request)?
> > > 
> > > This feature, would do much to alleviate a lot of our issues with 
> > > secure file transfers.
> > 
> > I'm not in a position to answer your question wrt. scope, but I'm
> > curious as to what exactly the signature would signify?  
> That the server 
> > has definitely received the file at a given time?
> 
>