On Tue Sep 11 17:20:24 2007, Ian Paterson wrote:
Peter Saint-Andre wrote:
Back in August I emailed about this issue [1] with the IETF area
directors for applications and security, relevant WG chairs, and
interested others. The conclusion was that in rfc3920bis we would make
the following changes to the mandatory-to-implement technologies:

1. Remove DIGEST-MD5


FWIW, I would say that we should try to keep DIGEST-MD5 mentioned prominently.

LDAP has done this change, I believe, so I'll ask Kurt what was done there. SMTP AUTH had the interesting case where CRAM-MD5 was popular, but it had *no* MTI, so the new SMTP AUTH, although with the now traditional MTI of TLS+PLAIN, has an informative "MAY implement CRAM-MD5", with the CRAM-MD5 as an informative reference.

There's also the downref experiment, whereby we could raise DIGEST-MD5 to a SHOULD, and a normative reference, which is also an option. It requires more process wonkage, though, but the APPS ADs should be able to help there.


I strongly disagree. Restrained (Web) clients can't implement TLS over TCP/IP. So without DIGEST-MD5 the passwords would end up being transmitted in the clear!


Yes, but they're not acting as fully conformant RFC3920bis implementations, then. :-)


Even where TLS is available, SASL PLAIN requires server operators to keep copies of all users' passwords. This is a serious (and often unnecessary) security weakness.


No, it doesn't. You can implement SASL PLAIN by comparing hashes internally, that's fine. No need to have a plaintext equivalent, let alone a cleartext password, on the server.

You do have to send the password clear to the server, so there are potential MITM issues - you don't want to be sending your password unless you really know you're talking to the right endpoint. Hopefully TLS certificate validation provides sufficient server authentication that you'll avoid this, but it still unnerves me.


TLS + DIGEST-MD5 is stronger than TLS + SASL PLAIN


Yes, but it's harder to implement, etc.

If I ruled the world, I'd mandate TLS+SCRAM, and have a SHOULD for TLS+YAP (the latter being plaintext-equiv on the server, but only a single round-trip, so great for mobiles).

Dave.
--
Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED]
 - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
 - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

Reply via email to