Re: future SFTP version question

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

denis bider wrote:
> > > but I seriously doubt it's worth the
> > > effort; it seems too obscure and specialized.
> >
> > Non-repudiation is a growing demand in the corporate world. 
> > It is inextricably tied into secure file transfers. In a 
> > system which requires non-repudiation, sftp fulfills all the 
> > necessary requirements ( key handling, secure transmission, 
> > validation ) everything, except for the digitally signed 
> > receipt/manifest. 
>
>
> I agree with Jason's assessment and disagree about this extension being "too
> obscure and specialized". It is so simply because there is no simple way of
> doing it. If we come up with an extension that provides a simple way of
> doing it, I believe there will be plenty demand. I would implement it in our
> server.
>
> Someone needs to draft an extension though. That ought to be Jason because
> he has background knowledge about the problem and can likely come up with
> something that will be simple enough yet will work.
>
> I propose this be done here because we've had at least 2 positive responses
> (I don't recall if there were more) and just one negative. If this is an
> optional extension, people who don't want to implement will not be impacted
> by it, whether it's part of SFTP or a separate draft.
>
> What does Joseph as the SFTP draft editor think about making this an
> extension in the SFTP draft, one like MD5 hashes for instance? (which I
> think were an excellent idea btw)
>
> If this is too complex to be an extension in the same draft, I think Jason
> can just go get xml2rfc or a similar utility and write up an Internet-Draft
> for this - am I right? How would he submit it when he writes one?

Well, below is a _very_ rough version of an extension.  I'd be
more than happy to have Jason's expertise to help get this
fleshed out where it will work for him (and us.)

And since non-repudiation has recently whacked me over the head,
I'd agree that I suspect for most of us implementing sftp, it
will probably become non-obscure and not-so-specialized soon, if
it hasn't already.

(One alternate proposal I had was to put together a AS profile for
running of sftp, AS4... but I think that might be _really_
heavy weight, and what Jason seems to be saying is we already
have most of what we need anyway.)

- Joseph

---

9.2  File Signing

   This extension allows a client to request that the server provide a
   signature proving that it has recieve a correct copy of the data.

       byte   SSH_FXP_EXTENDED
       uint32 request-id
       string "sign-filename" / "sign-handle"
       string filename [UTF-8] / file-handle
       string pubkey-algorithm-list [from transport draft]


       byte   SSH_FXP_EXTENDED_REPLY
       uint32 request-id
   	string filename-used-in-signature [UTF8]
       int64  time-of-request
       attrib file-attrib
       string public-key [from transport draft]
       string signature  [from transport draft]

   filename
      Used if 'sign-filename' is specified; indicates the name of the
      file to use.  The hash will be of the file contents as it would
      appear on the wire if the file were opened with no special flags.

   file-handle
      Used if 'sign-handle' is specified; specifies a file handle to
      read the data from.  The handle MUST be a file handle, and
      ACE4_READ_DATA MUST have been included in the desired-access when



Galbraith                Expires April 29, 2005                [Page 46]

Internet-Draft         SSH File Transfer Protocol           October 2004


      the file was opened.

      If this file handle was opened in TEXT mode, the signature must be
      made of the data as it would be sent on the wire.

   pubkey-algorithm-list
      The algorithm list of publickeys the client is capable of
      supporting.  If the server cannot provide a signature using any of
      the  algorithm requested, it should respond with a STATUS
      response, with UNSUPPORTED error code.

      In the case of x509v3 (see below), no attempt is made to negotiate
      which algorithms are supported within the certificate chain.

   filename-used-in-signature
   time-of-request
   file-attrib
      The filename actually used, time-of-request, and file attribute
      structure which were used to make the signature.  The filename, in
      particular, may be difference from that specified if the server
      applied some sort of canonicalization, or may be empty if the
      request was a sign-handle and the server couldn't map from a
      handle to a filename.

   public-key
      The public-key the server used to sign the filename.  This is a
      data structure as specified in the secsh transport specification
      [2].

      This draft specifies an additional public format,
      x509v3%filexfer.secsh.ietf.org@localhost.  The key data in this case is the
      x509v3 certificate DER encoded.  The signature algorithm used for
      this key type is one of three types:

      ssh-dss
         Encoded as per the secsh transport specification [2].

      ssh-rsa
         Encoded as per the secsh transport specification [2].

      pkcs7%filexfer.secsh.ietf.org@localhost
         A DER encoded pkcs #7 signature with detached data, as
         specified by .

         The prefered signature algorithm is pkcs7.






Galbraith                Expires April 29, 2005                [Page 47]

Internet-Draft         SSH File Transfer Protocol           October 2004


   signature
      The signature over the following data, formatted as specified in
      the secsh transport specification [2] or as above.

           string filename [UTF-8]
           string username-of-signature-requestor [UTF-8]
           int64  time-of-request
           attrib file-attrib
           string file-data


      filename
         The filename of the file being signed.  If this is a
         'sign-filename' request, the filename MUST be included,
         although it MAY be canonicalized.  If this is a sign-handle,
         the filename SHOULD be included; however, if the server can not
         map backwards from a handle to a filename, the filename may be
         zero length.

      username-of-signature-requestor
         This is the username by which the client authenticated to the
         system.

      time-of-request
         This is the time that the signature request was made, format as
         described by file attributes. (Section 6.7)

      file-attrib
         File attribute structure describing the attributes of the file.
         The server SHOULD include any fields that it can, even if it
         would not normally retrieve the data.  In particular, the
         server SHOULD include owner, group, acl, permissions, and
         mime-type data if it can support these field.  The size and
         attrib-bits fields SHOULD also be included.

      file-data
         The file data as an SSH string.