RE: "POP3 SASL Authentication Mechanism" submitted for publication
Paul Leach <[email protected]> Mon, 15 Jan 2007 12:02:10 -0800
| Newsgroups | gmane.ietf.pop3ext,gmane.ietf.sasl |
|---|---|
| Message-ID | <76323E9F0A911944A4E9225FACFC55BA0352C8B5@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com> |
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 protected] [mailto:[email protected]] On Behalf Of Lisa Dusseault Sent: Monday, January 15, 2007 9:52 AM To: Arnt Gulbrandsen Cc: Alexey Melnikov; [email protected]; Abhijit Menon-Sen; Frank Ellermann; [email protected]; [email protected]; 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