Subject: CAT-WG Last-Call: draft-ietf-cat-ftpdsaauth-00.txt

From: "Linn, John" <[email-masked]>
Date: Tue, 6 Jan 1998 23:44:38 -0500

CAT/FTPsec fanciers:

Per discussion at the DC IETF, this message is to open a CAT-WG
Last-Call on draft-ietf-cat-ftpdsaauth-00.txt, "FTP Authentication using
DSA", which profiles the use of FTP Security Extensions (RFC-2228) with
DSA and SHA-1 algorithms.  Please send any discussion or comments on
this draft and its prospective recommendation for advancement to
Proposed Standard to the CAT-WG list NLT Tuesday, 3 February 1998.  

Note: Per RFC-2026 ("The Internet Standards Process - Revision 3"), sec.
4.1.1, IESG Proposed Standard advancement decisions require that a
document has received significant community review and apparent
community interest, and discussion of this draft has so far been
relatively quiet.  To aid in supporting this document's progression per
the RFC-2026 criteria, it would be helpful if readers and reviewers of
draft-ietf-cat-ftpdsaauth-00 were to identify themselves to the list
during the WG Last-Call even if no comments need be made against the
draft's content.

Thanks, ...

--jl

---

From: "Martin Carpenter" <[email-masked]>
Date: Thu, 15 Jan 1998 07:39:46 EST

> Proposed Standard to the CAT-WG list NLT Tuesday, 3 February 1998.

Okay, here are mine.  My concerns are listed below in the order that I
found them as I read the draft.  Apologies, as ever, for my slow
response.

1. "* server authentication -- normally done in conjunction with user
   authentication;". I object to the clause after "--" (and pick nits
   for England).  Anonymous FTP, anyone?

2. "PROT commands may be sent on a transfer-by-transfer basis,
   however, the session parameters may not be changed within a
   session.".

   What about successive AUTH commands within one session? From RFC 2228:

      Some servers will allow the AUTH command to be reissued in order
      to establish new authentication.  The AUTH command, if accepted,
      removes any state associated with prior FTP Security commands.
      The server must also require that the user reauthorize (that is,
      reissue some or all of the USER, PASS, and ACCT commands) in this
      case (see section 4 for an explanation of "authorize" in this
      context).

   Or is the draft meant to say something like "the session parameters
   may not be altered during an existent data interchange such as to
   effect the mechanism being employed for that interchange."? (I'm
   thinking of a server happily accepting new AUTH commands on the
   control connection whilst it's still sending/receiving stuff on the
   data connection; perhaps I'm just not clear about the definition of
   the word "session").

3. The example exchange:

    MIC Base64(Sign("PBSZ 65535"))      -->
                                           <-- 200 PBSZ=32767
    MIC Base64(Sign("USER yee"))        -->
                                           <-- 331

   and the accompanying text:

   "Specifically, the file is broken up into blocks of data of less
   than the negotiated protection buffer size (32768 bytes in the
   example exchanges).".

   Unless I've missed something subtle in the RFC, shouldn't this latter
   paragraph read "...  (32767 bytes in the example exchanges)."?  Yes,
   I am aware that number of bytes of file data sent per block will be
   "less than" the negotiated PBSZ value, but won't the number of bytes
   in any buffer that is sent in a block be "less than or equal" to the
   negotiated PBSZ value (of 32767 in the example above)?  I *think* that
   the author wanted to link the "32768 bytes" with the "less than" (to
   get "less than or equal to 32767"), but I think that what it
   *actually* says is that 32768 bytes was the negotiated buffer size,
   which it wasn't.

   And I'm not entirely happy with "...  the file is broken up...".
   Perhaps: "...  the *encrypted* file" is broken up..." maybe, or
   "... the file is broken up into blocks of data such that when
   encrypted, the encrypted block size is less than or equal to the
   negotiated protection buffer size".  *Phew* that took much longer to
   say than I thought it would :-)

Regards,

Martin.

Martin Carpenter                            Tie  7-664834
IBM Global Network                         NOSS  CARPEMJ@NHBVM9
EDI Dev & Spt, Warwick, UK                Notes  CARPEMJ@IBMGB
Tel +44 (0)1926 464834                    email  [email-masked]

---

From: Russ Housley <[email-masked]>
Date: Sun, 01 Feb 1998 02:31:59 -0500

>   for England).  Anonymous FTP, anyone?

Clearly, Anonymous FTP is the exception.  We will gladly reword this phrase
to accomodate Anonymus FTP.

>   data connection; perhaps I'm just not clear about the definition of

How about the following: "PROT commands may be sent on a
transfer-by-transfer basis; however, the session parameters may not be
changed without sending another AUTH command."

>   *actually* says is that 32768 bytes was the negotiated buffer size,

We will gladly correct the typo.  We will make the values in the figure and
the text match.

>   say than I thought it would :-)

The file is not encrypted.  Each block is signed (with SHA-1 and DSS).
Is it not clear that the file block plus the signature overhead must
be less than or equal to the PBSZ?

Russ

---

From: "Martin Carpenter" <[email-masked]>
Date: Fri, 06 Feb 1998 11:01:19 EST

Russ,

 Thanks for the agreed changes.

 >>   negotiated protection buffer size".  *Phew* that took much longer
 >>   to say than I thought it would :-)
 >

 Yep, you're absolutely right. I'm going to have to upgrade from instant
 coffee :-)

 > be less than or equal to the PBSZ?

 I'd say that it's clear to anyone familiar that is familiar with RFC
 2228, but not otherwise.  However, given the trailing "Each protection
 buffer contains..." clause, I'm happy to concede this point.

 Regards,

 Martin.