Re: Fwd: "POP3 SASL Authentication Mechanism" submitted for publication

[Frank Ellermann <nobody@xxxxxxxxxxxxxxxxx>]

Lisa Dusseault wrote:

> Any comments on the document, its intended publication status or current
> implementation status, are welcome.

It won't surprise anybody that I don't like DIGEST-MD5, and consider the
idea to make it mandatory for POP3 as completely wrong.  None of the POP3
servers I know support SASL, let alone DIGEST-MD5.

A mandatory CRAM-MD5 as recommended in BCP 46 could make sense, after all
it's better than APOP, and wrt security almost as good as DIGEST-MD5 for
authentication, but far easier to implement.

Other nits / questions about the -08 draft:

RFC 1734  had "AUTH" 1*WSP auth_type *(CRLF base64) CRLF
The draft has "AUTH" SP sasl-mech [SP (base64 / "=" )] *(CRLF [base64]) CRLF

1: Why was 1*WSP replaced by a single SP ?
2: What's the idea of *(CRLF [base64]) instead of *(CRLF base64) ?

3: A bare "=" is an empty initial response.  A clearer syntax might be:

  auth-command     = "AUTH" SP sasl-mech [SP initial-resonse] CRLF
  initial-response = "=" / (base64 *(CRLF base64))

The syntax as is allows AUTH mech =<crlf>base64<crlf>crlf>base64<crlf>

4: How does the server determine the end of an <initial-response> ?

The added DIGEST-MD5 example (thanks!) uses an RFC 4422 "empty response"
at the end:

    S: + cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZA==
    C:
    S: +OK Maildrop locked and ready

5: Why is an empty response no "=" as in the <initial-response> ?

The syntax for <continue-req> requires a trailing space if it's empty.

    continue-req    = "+" SP [base64] CRLF

6: Could the draft also get away with "+" [SP [base64]] CRLF ?  Or for
   consistency with the "=", how about "+" SP (base64 / "=") CRLF ?

   In RFC 1734 that used to be "+" SP base64 CRLF, but of course this
   is a backwards compatibility issue, no matter what RFC 1734 said.

7: Why is the POP3 DIGEST-MD5 digest-uri="imap/elwood.innosoft.com" ?
   If it's supposed to be the concatenation of "pop/" and <realm>
   the draft needs to say so because 2831bis doesn't allow "pop3/".

8: What is the meaning of a <realm> wrt POP3 ?  Can servers pick what
   they like ?   What's the definition of <authzid> wrt POP3 ?  If it
   isn't allowed the draft should mention this.

9: RFC 2831 requires that the size of a digest-response is less than
   4096 bytes.  4*4095/3=5460, the draft should state this limit for
   a DIGEST-MD5 response, it's more than the 40 guaranteed in RFC 1939.

10: Is it okay if the server offers no <qop> ?  The digest calculation
    is then different.

11: Can the client indicate its <maxbuf>, and what would servers do
    with it ?  Do all clients support the default 64 KB ?  Wrt POP3 is
    a <maxbuf> the maximal line lenght, or the combined multi-line
    lenght (i.e. message size) ?

12: The password for the example is "secret", the draft should mention
    it.  But the <serv-type> has to be fixed anyway.

Frank