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

Abhijit Menon-Sen wrote:

> My POP3 server has supported SASL for a long time.

The four or five I've seen unfortunately don't, otherwise I'd
add it to my client script.     

> This draft (and rfc2554bis, which Alexey is editing) were
> both changed to use DIGEST-MD5 based on concerns about 
> security.

If it's about "we can do better than APOP" CRAM-MD5 is better.

If the security concerns are that DIGEST-MD5 is again "better",
then it's utter dubious, the only difference for qop=auth I'm
aware of is the cnonce, CRAM-MD5 has no cnonce.

The goal should be to get rid of USER:PASS and APOP, not to
promote DIGEST-MD5 if folks won't implement it, because it's 
too complex with its more than ten parameter.  Getting worse
if you've seen the 2831bis drafts.

If you decide to use it anyway you could wait until 2831bis
is ready, using a new SASLPREP example with "prep" parameter.

> I'll change it only if there's clear consensus about the 
> preferred replacement.

IMO there's no consensus for a mandatory DIGEST-MD5, and the
MUST in 2554bis will go.  CRAM-MD5 *is* the common mechanism
for ESMTPA, and if MUAs support it anyway for ESMTPA they can
also support it for POP3.

Users wanting something better should use ESMTPSA and STLS.

> 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

+1 (I didn't try the server side)

> I gather CRAM-MD5 is frowned upon in that regard

Implementors normally prefer KISS if there's a choice.  Offer
them APOP or DIGEST-MD5, and they use APOP.  Offer them APOP
or CRAM-MD5, and they might try CRAM-MD5 if we're lucky.  My
(very unreliable) crystal ball says.

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

> That some client responses may be empty.

The multi-line response client to server confuse me.  Which SASL
mechanism needs this ?  If the server always knows how many lines
to expect I'd see how it works.    

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

Okay, the following lines are additional responses.  An empty ir is
given as "=", all other empty response lines are just empty.  

But when the client sends AUTH there were no prior server challenges,
where do the additional responses come from ?  For APOP there is a
prior challenge in the greeting, how does that work for SASL ?

> I must admit I'm not looking forward to having to put together a 
> valid DIGEST-MD5 example.

Apparently we agree that DIGEST-MD5 is one of the worse mechanisms 
You could keep the challenge as is (copied from 2831):

        C: AUTH DIGEST-MD5
        S: + cmVhbG09ImVsd29vZC5pbm5vc29mdC5jb20iLG5vbmNlPSJPQTZNRzl0
             RVFHbTJoaCIscW9wPSJhdXRoIixhbGdvcml0aG09bWQ1LXNlc3MsY2hh
             cnNldD11dGYtOA==

In the response replace "imap" by "pop", the resulting digest is then
b0d56d2f054c24b62072322106468db9, and the complete response would be:

        C: Y2hhcnNldD11dGYtOCx1c2VybmFtZT0iY2hyaXMiLHJlYWxtPSJlbHdvb2
           QuaW5ub3NvZnQuY29tIixub25jZT0iT0E2TUc5dEVRR20yaGgiLG5jPTAw
           MDAwMDAxLGNub25jZT0iT0E2TUhYaDZWcVRyUmsiLGRpZ2VzdC11cmk9In
           BvcC9lbHdvb2QuaW5ub3NvZnQuY29tIixyZXNwb25zZT1iMGQ1NmQyZjA1
           NGMyNGI2MjA3MjMyMjEwNjQ2OGRiOSxxb3A9YXV0aA==

For the resulting rspauth=0b971462cef5e8f930db9a33b02fc9a0 I get:

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

Insert standard disclaimer.  

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

That's not very clear, 2449 chapter 4 says:

   Servers which support the CAPA command MUST support commands up to
   255 octets.  Servers MUST also support the largest maximum command
   length specified by any supported capability.

Apparently servers MUST support any valid initial response in an AUTH,
otherwise they shouldn't offer the corresponding SASL mechanism.  But
your text continues:
>                                                                 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]).

I'd interpret 2449 in a way that this can't happen.  Apparently your
interpretation is "limit 255".  If that's the case please mention 255
in your text directly, the quoted RFC 2449 clause is somewhat obscure.

 [<maxbuf> question]
> I'm afraid I have no idea.

Sorry, I forgot to check 2831bis:  Alexey fixed it already, the client
<maxbuf> only affects auth-int or auth-conf.  For the server <maxbuf>
it was already clear in RFC 2831.

All other questions answered, thanks.

 Frank