[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: "POP3 SASL Authentication Mechanism" submitted for publication
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: owner-ietf-sasl@xxxxxxxxxxxx [mailto:owner-ietf-sasl@xxxxxxxxxxxx]
On Behalf Of Lisa Dusseault
Sent: Monday, January 15, 2007 9:52 AM
To: Arnt Gulbrandsen
Cc: Alexey Melnikov; robsiemb@xxxxxxxxxx; Abhijit Menon-Sen; Frank
Ellermann; ietf-pop3ext@xxxxxxx; ietf-sasl@xxxxxxx; 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