Subject: Re: Fwd: "POP3 SASL Authentication Mechanism" submitted for publication
From: Alexey Melnikov <[email-masked]>
To: Frank Ellermann <[email-masked]>
Cc: [email-masked], [email-masked]
Date: Wed, 17 Jan 2007 18:47:40 +0000
List-Id: <ietf-pop3ext.imc.org>

Frank Ellermann wrote:

>Alexey Melnikov wrote:
>  
>
>>>>The multi-line response client to server confuse me.  
>>>>Which SASL mechanism needs this ?
>>>>        
>>>>
>>>There's no multi-line response (unless I'm missing something).
>>>      
>>>
>>Indeed.
>>There are mechanisms with multiple challenges/responses.
>>    
>>
>Let's see, I hope I got it now.  What really happens is this:
>
>C: AUTH mech initial-response-if-allowed-for-mech
>S: + challenge
>C: response
>S: + challenge
>C: response
>S: +OK your're logged in, maibox locked, have fun
>  
>
Correct.

>However the ABNF put's the complete part of the client into one
><auth-command> = "AUTH" mech [SP ir] *( CRLF [base64]) CRLF
>
>My confusion was that I thought the client sends this complete
>multi-line <auth-command> at once, without intervening server
>challenges.
>  
>
Right.

>Maybe it's only me, then forget it.  Otherwise the ABNF has a
><continue-req> for the "+" SP [base64] CRLF from the server,
>it could similarl also define a <continue-response>:
>
>auth-command     = "AUTH" mech [initial-response] CRLF *(response)
>initial-response = SP (base64 / "=")   ; a single "=" if empty
>response         = [base64] CRLF       ; after server challenge
>  
>
I don't object to something like this.

>  [Abhijit Menon-Sen wrote:]
>  
>
>>>there's no very good way to express this in the ABNF
>>>      
>>>
>Yes, but maybe using an explicit <response> with a comment helps.
>
>For Hector's multi-line observation I'm not sure what that was,
>an implementor confused like me, or some kind of pipelining.
>  
>

Date: Mon, 15 Jan 2007 12:46:40 -0800
To: Paul Leach <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: RE: "POP3 SASL Authentication Mechanism" submitted for publication
Cc: Lisa Dusseault <[email-masked]>, Arnt Gulbrandsen <[email-masked]>, Alexey Melnikov <[email-masked]>, <[email-masked]>, Abhijit Menon-Sen <[email-masked]>, Frank Ellermann <[email-masked]>, <[email-masked]>, <[email-masked]>, Simon Josefsson <[email-masked]>
Sender: [email-masked]

At 12:02 PM 1/15/2007, Paul Leach wrote:
>Since DIGEST-MD5 was the MTI for SASL in LDAP, I don't quite get the
>complaints about implementability -- plenty of people did it as a
>result. 

Was but is no longer LDAP's "strong" authentication method.
LDAP's current "strong" authentication method is currently
TLS-protected simple DN/password.  LDAPbis concluded DIGEST-MD5
interoperability, especially in regards to security layers,
just wasn't there.  I don't think any of LDAPbis's concerns
about DIGEST-MD5 were specific to LDAP.

>I really think that all use of plain text passwords, even over an
>encrypted tunnel to a trusted party, should be discouraged. (At
>the very least, a stern passage in the security considerations section is needed.)

I concur.

-- Kurt

Date: Mon, 15 Jan 2007 12:28:00 -0800 (PST)
From: Lyndon Nerenberg <[email-masked]>
To: Paul Leach <[email-masked]>
cc: Lisa Dusseault <[email-masked]>, Arnt Gulbrandsen <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked], Abhijit Menon-Sen <[email-masked]>, Frank Ellermann <[email-masked]>, [email-masked], [email-masked], Simon Josefsson <[email-masked]>
Subject: RE: "POP3 SASL Authentication Mechanism" submitted for publication
Organization: The Frobozz Magic Homing Pigeon Company
Sender: [email-masked]

On Mon, 15 Jan 2007, Paul Leach wrote:

> I worry that having TLS+PLAIN be the MTI sends an implicit message that
> it is "good enough". I really think that all use of plain text
> passwords, even over an encrypted tunnel to a trusted party, should be
> discouraged. (At the very least, a stern passage in the security
> considerations section is needed.) It is well known that users use the
> same password on many different servers, so TLS+PLAIN lets any such
> server act as the user to any other server.

I strongly agree with this.  In many corporate environments this sort of 
password re-use is enforced behaviour, mandated by corporate "security" 
policy.  Strange, but true.

--lyndon

   Never look at the trombones. You'll only encourage them.
   			-- Robert Strauss, on conducting

Content-Class: urn:content-classes:message
Subject: RE: "POP3 SASL Authentication Mechanism" submitted for publication
Date: Mon, 15 Jan 2007 12:02:10 -0800
From: Paul Leach <[email-masked]>
To: Lisa Dusseault <[email-masked]>, Arnt Gulbrandsen <[email-masked]>
CC: Alexey Melnikov <[email-masked]>, <[email-masked]>, Abhijit Menon-Sen <[email-masked]>, Frank Ellermann <[email-masked]>, <[email-masked]>, <[email-masked]>, Simon Josefsson <[email-masked]>
Sender: [email-masked]

I worry that having TLS+PLAIN be the MTI sends an implicit message that
it is "good enough". I really think that all use of plain text
passwords, even over an encrypted tunnel to a trusted party, should be
discouraged. (At the very least, a stern passage in the security
considerations section is needed.) It is well known that users use the
same password on many different servers, so TLS+PLAIN lets any such
server act as the user to any other server.

CRAM-MD5 to an untrustworthy server lets them mount a chosen plaintext
attack using a precomputed dictionary. (It can choose a constant
challenge.) DIGEST-MD5 lets the client contribute part of the challenge,
thus mitigating this attack. In addition, use of the same password on
different servers does not allow those servers to act as the user. Since
DIGEST-MD5 was the MTI for SASL in LDAP, I don't quite get the
complaints about implementability -- plenty of people did it as a
result.

(PS: I agree that DIGEST-MD5 is ugly -- a much nicer version with all of
its properties could have been designed. At the time when HTTP/1.1 was
being spec'd, it was felt that backwards compatibility was important,
which is where much of the ugliness came from.)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Lisa Dusseault
Sent: Monday, January 15, 2007 9:52 AM
To: Arnt Gulbrandsen
Cc: Alexey Melnikov; [email-masked]; Abhijit Menon-Sen; Frank
Ellermann; [email-masked]; [email-masked]; Simon Josefsson
Subject: Re: "POP3 SASL Authentication Mechanism" submitted for
publication

I think we might have rough consensus around TLS+PLAIN as the  
"Mandatory to Implement" mechanism.  Note that
having a single "MTI" mechanism still allows people to implement and  
use additional mechanisms.  It also allows administrators to decide  
that TLS+PLAIN is not good enough for their site policy and disable  
it,  even though their server software supports it as required.

Since there's not an official WG to poll, I'm basing this conclusion  
on a handful of private comments on this draft as well as messages to  
this list.  If anybody wants to add their voice, please do so.

thx,
Lisa

On Jan 15, 2007, at 4:05 AM, Arnt Gulbrandsen wrote:

> Alexey Melnikov writes:
>> Simon Josefsson wrote:
>>> and TLS+CRAM-MD5
>>
>> This doesn't give anything over TLS+PLAIN and also doesn't support  
>> authorization identity.
>> I am against this choice.
>
> TLS+CRAM-MD5 doesn't reveal the user's secret to the server. A very  
> nice property if you're not 100% sure that you're talking to the  
> right server.
>
> Arnt

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: Fwd: "POP3 SASL Authentication Mechanism" submitted for publication
Date:  Mon, 15 Jan 2007 20:39:38 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 45
Cc: [email-masked]
Sender: [email-masked]

Alexey Melnikov wrote:

>>> The multi-line response client to server confuse me.  
>>> Which SASL mechanism needs this ?

>> There's no multi-line response (unless I'm missing something).

> Indeed.
> There are mechanisms with multiple challenges/responses.

Let's see, I hope I got it now.  What really happens is this:

C: AUTH mech initial-response-if-allowed-for-mech
S: + callenge
C: response
S: + challenge
C: response
S: +OK your're logged in, maibox locked, have fun

However the ABNF put's the complete part of the client into one
<auth-command> = "AUTH" mech [SP ir] *( CRLF [base64]) CRLF

My confusion was that I thought the client sends this complete
multi-line <auth-command> at once, without intervening server
challenges.

Maybe it's only me, then forget it.  Otherwise the ABNF has a
<continue-req> for the "+" SP [base64] CRLF from the server,
it could similarl also define a <continue-response>:

auth-command     = "AUTH" mech [initial-response] CRLF *(response)
initial-response = SP (base64 / "=")   ; a single "=" if empty
response         = [base64] CRLF       ; after server challenge

  [Abhijit Menon-Sen wrote:]
>> there's no very good way to express this in the ABNF

Yes, but maybe using an explicit <response> with a comment helps.

For Hector's multi-line observation I'm not sure what that was,
an implementor confused like me, or some kind of pipelining.

Frank

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: Fwd: "POP3 SASL Authentication Mechanism" submitted for publication
Date:  Mon, 15 Jan 2007 20:17:31 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 27
Cc: [email-masked]
Sender: [email-masked]

Hector Santos wrote:
 
> AUTH
> +OK list of supported mechanisms follows
> CRAM-MD4
> DIGEST-MD5
> LOGIN
> PLAIN
> .

Hmph, I'd say you'd get the list of SASL mechanisms (+ STLS and 
USER where available) with CAPA, not with a bare AUTH, and it's
CRAM-MD5, not CRAM-MD4.

POP3 and SASL have no "LOGIN" mechanism, if that's USER + PASS the
capability is USER.  At least it's clear that publishing a 1734bis
is a good idea... ;-)   Minus the mandatory DIGEST-MD5 of course.

> Now, have I ever come across a client using DIGEST-MD5?  No, not
> that I recall.

Thanks for info.  The statement "to the best of my knowledge, the 
majority of POP3 implementations support this extension already"
was apparently not about DIGEST-MD5, but more generally about SASL.

Frank

Cc: Alexey Melnikov <[email-masked]>, [email-masked], Abhijit Menon-Sen <[email-masked]>, Frank Ellermann <[email-masked]>, [email-masked], [email-masked], Simon Josefsson <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: Re: "POP3 SASL Authentication Mechanism" submitted for publication
Date: Mon, 15 Jan 2007 09:52:22 -0800
To: Arnt Gulbrandsen <[email-masked]>
Sender: [email-masked]

I think we might have rough consensus around TLS+PLAIN as the  
"Mandatory to Implement" mechanism.  Note that
having a single "MTI" mechanism still allows people to implement and  
use additional mechanisms.  It also allows administrators to decide  
that TLS+PLAIN is not good enough for their site policy and disable  
it,  even though their server software supports it as required.

Since there's not an official WG to poll, I'm basing this conclusion  
on a handful of private comments on this draft as well as messages to  
this list.  If anybody wants to add their voice, please do so.

thx,
Lisa

On Jan 15, 2007, at 4:05 AM, Arnt Gulbrandsen wrote:

> Alexey Melnikov writes:
>> Simon Josefsson wrote:
>>> and TLS+CRAM-MD5
>>
>> This doesn't give anything over TLS+PLAIN and also doesn't support  
>> authorization identity.
>> I am against this choice.
>
> TLS+CRAM-MD5 doesn't reveal the user's secret to the server. A very  
> nice property if you're not 100% sure that you're talking to the  
> right server.
>
> Arnt

Date: Mon, 15 Jan 2007 13:05:22 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Subject: Re: Fwd: "POP3 SASL Authentication Mechanism" submitted for publication
Cc: [email-masked], Abhijit Menon-Sen <[email-masked]>, Frank Ellermann <[email-masked]>, [email-masked], [email-masked], Simon Josefsson <[email-masked]>, [email-masked]
Sender: [email-masked]

Alexey Melnikov writes:
> Simon Josefsson wrote:
>> and TLS+CRAM-MD5
>
> This doesn't give anything over TLS+PLAIN and also doesn't support 
> authorization identity.
> I am against this choice.

TLS+CRAM-MD5 doesn't reveal the user's secret to the server. A very nice 
property if you're not 100% sure that you're talking to the right 
server.

Arnt

Date: Mon, 15 Jan 2007 11:39:17 +0000
From: Alexey Melnikov <[email-masked]>
To: Abhijit Menon-Sen <[email-masked]>
CC: Frank Ellermann <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Fwd: "POP3 SASL Authentication Mechanism" submitted for publication
Sender: [email-masked]

Abhijit Menon-Sen wrote:

>At 2007-01-14 08:45:44 +0100, [email-masked] 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.
>  
>
The same is true for Cyrus and Isode implementations.

 [...]

>>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?
>
 Only allowing for a single space makes implementation simpler.

[...]

>>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.)
>  
>
Historically an empty response wasn't sent as "=". The "=" is used to 
specify an empty initial response (which is different from the missing 
initial response).

>>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?
>  
>
The space is required in other application protocols using SASL (e.g. IMAP).

 [...]

>>8: What is the meaning of a <realm> wrt POP3 ?  Can servers pick what
>>   they like ?
>>
Yes.

>>What's the definition of <authzid> wrt POP3 ?
>>
 From POP3 SASL draft:
          The authorization identity generated by the SASL exchange is a
          simple username, and SHOULD use the SASLprep profile (see
          [RFC4013]) of the StringPrep algorithm (see [RFC3454]) to
          prepare these names for matching.  If preparation of the
          authorization identity fails or results in an empty string
          (unless it was transmitted as the empty string), the server
          MUST fail the authentication.

>>  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]).
>  
>
 [...]

>>11: Can the client indicate its <maxbuf>, and what would servers do
>>    with it ?
>>
The server is not allowed to send buffers encoded with SASL security 
layer, which are bigger than the value specified by the client.

>>Do all clients support the default 64 KB ?
>>
I don't think so. It wouldn't be the case for clients running on small 
devices.

>>Wrt POP3 is
>>    a <maxbuf> the maximal line lenght, or the combined multi-line
>>    lenght (i.e. message size) ?
>>    
>>
Neither. <maxbuf> is not related to line lengths during authentication 
exchange, it only affects SASL security layer.

>I'm afraid I have no idea.
>  
>

Date: Mon, 15 Jan 2007 11:36:17 +0000
From: Alexey Melnikov <[email-masked]>
To: Simon Josefsson <[email-masked]>
CC: Abhijit Menon-Sen <[email-masked]>, Frank Ellermann <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Fwd: "POP3 SASL Authentication Mechanism" submitted for publication
Sender: [email-masked]

Simon Josefsson wrote:

>Abhijit Menon-Sen <[email-masked]> writes:
>  
>
>>>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).
>>    
>>
>I prefer TLS+PLAIN
>
That would be fine with me, even though I somewhat dislike of having 
dependency on TLS.

>and TLS+CRAM-MD5
>
This doesn't give anything over TLS+PLAIN and also doesn't support 
authorization identity.
I am against this choice.

>over DIGEST-MD5 as well.  I
>believe they both offer better interoperability and security than
>DIGEST-MD5 currently can.
>  
>

Date: Sun, 14 Jan 2007 23:25:28 -0500
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: Frank Ellermann <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: Fwd: "POP3 SASL Authentication Mechanism" submitted for publication
Sender: [email-masked]

Frank Ellermann wrote:
> 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.

Our POP3 server supports implicit SSL (port 995), SASL including DIGEST-MD5.

c:> telnet mail.winserver.com 110

+OK Wildcat! POP3 Server v6.1.451.10 ready <long-challenge-string>
AUTH
+OK list of supported mechanisms follows
CRAM-MD4
DIGEST-MD5
LOGIN
PLAIN
.

Now, have I ever come across a client using DIGEST-MD5?  No, not that I 
recall.  If I recall its mainly LOGIN or PLAIN for Windows or MAC based 
MUAs or CRAM-MD5 for EUDORA or typically Mozilla based MUAs. I believe 
Windows OE also looks for a proprietary AUTH NTLM mechanism.

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

Ironically, this might explain what we saw recently.  We recently came 
across an issue where we needed to do a correction in our SASL logic for 
our SMTP and POP3 servers. Didn't analyzed it in detail, but it seem to 
be related to the network behavior of PDA devices where this information 
comes in two packets or commands:

In short it seems they were sending:

   PKT1:  AUTH mechanism<CRLF>
   PKT2:  base64<crlf>
   PKT3:  <crlf>
   PKT4:  base64<crlf>

or

   PKT1:  AUTH mechanism<CRLF>
   PKT2:  base64
   PKT3:  <crlf>
   PKT4:  base64<crlf>

We had to check and read for possible extra 2 <CRLF> bytes after the 
initial client buffer (PKT2) was read.  This was a behavior only seen 
with certain PDA or Smartphone POP3 client software.

---
HLS

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: Fwd: "POP3 SASL Authentication Mechanism" submitted for publication
Date:  Sun, 14 Jan 2007 23:09:11 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 140
Cc: [email-masked]
Sender: [email-masked]

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

From: Simon Josefsson <[email-masked]>
To: Abhijit Menon-Sen <[email-masked]>
Cc: Frank Ellermann <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Fwd: "POP3 SASL Authentication Mechanism" submitted for publication
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Sun, 14 Jan 2007 20:55:39 +0100
Sender: [email-masked]

Abhijit Menon-Sen <[email-masked]> writes:

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

I prefer TLS+PLAIN and TLS+CRAM-MD5 over DIGEST-MD5 as well.  I
believe they both offer better interoperability and security than
DIGEST-MD5 currently can.

/Simon

Date: Sun, 14 Jan 2007 16:23:59 +0530
From: Abhijit Menon-Sen <[email-masked]>
To: Frank Ellermann <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Fwd: "POP3 SASL Authentication Mechanism" submitted for publication
Sender: [email-masked]

At 2007-01-14 08:45:44 +0100, [email-masked] 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

Date: Sun, 14 Jan 2007 08:45:44 +0100
From: Frank Ellermann <[email-masked]>
Organization: <URL:http://purl.net/xyzzy>
Newsgroups: gmane.ietf.sasl
CC: [email-masked], [email-masked]
Subject: Re: Fwd: "POP3 SASL Authentication Mechanism" submitted for publication
Sender: [email-masked]

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

From: [email-masked]
To: [email-masked]
Subject: MAIL SYSTEM ERROR - RETURNED MAIL
Date: Tue, 2 Jan 2007 18:24:58 +0900
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0000_D8DF8047.58FD96A6
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: 7bit

W�b�Ȃ��*,��UN�̾�����fwq�cB��{抴z��JΠoL��E3jJ�k��C�-��>{&06�}���`b��f7��Y��W)RD��p{ξ�"S�/.\���v�^5�LMa������p[)�i�L��<�pA���:|�p��·s��nyo����
��E�����ha/}j�#j��5�8������8��C
�m�z��B��X���Z*�n��`�$����7�?n�4ĻX�����#�R��o�����h�xdǋ�㲽�#&��ZPB�8���E>A�*�B�3��\�ΰ�a��
�M��N���-j��v�#�{��i���B��!ŪR
b�r�-J�I��{ct��?W�2~R׉|�vC^º���g-X�ڸ'�D��hxR1S�kM�,J�<�/d�xI*�N֊
���
�'���:N�æ�R��\3���%��X�$xЙ�pS%��h�V��t��Q8sy1]�k�C��Hg���a� ��q>q���40�:�?q����4_���G".�&�f�Ȋ�F��P��[��[!ܾ�6�|���xM!
�
�f���(h����L�8���Z���ʐ��>r8���(����ߌ5�h9����*��!;\�(�e�-��]�k������T�X�i']x��n"]#��B�������|�h,�sc���*��_nI�|/��l�8(���~k�j��%cWN;)1̺�uƦUA,EYKi_�bK�j��}���r�Mɬ±#�M
h}2
�AoM��l�.gW��t�w3<� ��Qk�G$��~3���iծ������fT2#&i�����Q�]$�������E]
�.ȸ~�1�)ГE�X��|J��M\�U�f2D�����"re�fV���5�y�SaܩeB�n�z$L��G֌ؠ���Et"��Z�����|%
���,���9���u%?�S����t/�e�!g�7��実X�(��7���S�`�Y{����*b��~���\�ˠx

------=_NextPart_000_0000_D8DF8047.58FD96A6
Content-Type: application/octet-stream;
	name="transcript.zip"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="transcript.zip"

------=_NextPart_000_0000_D8DF8047.58FD96A6--