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

[Abhijit Menon-Sen <[e-mail]>]

At 2007-01-14 08:45:44 +0100, [e-mail] wrote:
>
> None of the POP3 servers I know support SASL, let alone DIGEST-MD5.

Just a note: My POP3 server has supported SASL for a long time.

> A mandatory CRAM-MD5 as recommended in BCP 46 could make sense

This draft (and rfc2554bis, which Alexey is editing) were both changed
to use DIGEST-MD5 based on concerns about security. That's the way it
was when I started editing it, so I'll change it only if there's clear
consensus about the preferred replacement.

Having implemented both client and server sides of DIGEST-MD5, I can't
say I'm very fond of it either. Personally, I'd be happy with TLS+PLAIN
or CRAM-MD5 (or whatever else makes everyone happy without a significant
security penalty; and I gather CRAM-MD5 is frowned upon in that regard).

> 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 ?

I don't know (happened before I inherited the draft). Rob?

> 2: What's the idea of *(CRLF [base64]) instead of *(CRLF base64) ?

That some client responses may be empty.

> 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))

That's wrong. The initial-response would be:

    initial-response = "=" / base64

The ABNF is defining the AUTH command as the first "AUTH mech ir" line
followed by a series of (possibly empty) responses to server challenges.

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

Right. "AUTH mech =" followed by a base64 response, followed by an empty
response, followed by another base64 response.

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

CRLF.

> 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> ?

Because it's not an initial response. (The "=" encoding for an empty
SASL initial response is taken from Rob's IMAP SASL-IR draft.)

> The syntax for <continue-req> requires a trailing space if it's empty.
> 
>     continue-req    = "+" SP [base64] CRLF

That's consistent with IMAP.

I notice the following:

    Additionally, the ABNF specified in [RFC2449] is updated as follows:

          challenge      /= continue-req

But the ABNF specified in RFC2449 (pop3 extension mechanism) doesn't
actually define a "challenge" at all (and that /= should be =/ in any
case). I can't find anything that seems to define challenge in a way
relevant to POP3. (1734 doesn't define challenge at all.)

Rob? Do you remember what the intent was here?

> 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/".

Because I was lazy enough to cut and paste the example from 2831. I'll
fix that (though I must admit I'm not looking forward to having to put
together a valid DIGEST-MD5 example).

> 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.

That depends entirely on the server implementation, I'd say.

> 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.

I don't think it's really necessary. The length limitation, so far as it
applies to the initial-response, is described already:

          For the purposes of the initial client response, the line
          length limitation defined in [RFC2449] still applies.  If a
          client initial send would cause the AUTH command to exceed
          this length, the client MUST NOT use the initial response
          parameter (and must proceed instead by sending its initial
          response after an empty challenge from the server, as in
          section 3 of [RFC4422]).

> 10: Is it okay if the server offers no <qop> ?

The qop is optional, and is assumed to be "auth" if not specified (2831,
2.1.1)

> 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) ?

I'm afraid I have no idea.

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

OK.

Thanks for your comments.

-- ams