begin quotation by Lyndon Nerenberg on 2002/5/30 11:06 -0600:
> If the requirement is strictly for the "can interoperate" checkbox
> then that list should contain only CRAM-MD5.
I'm generally opposed to including CRAM-MD5 as a mandatory to implement,
even as a SHOULD. While it's widely implemented in IMAP software, it is
not widely used. Even more important, it is not implemented and likely
never will be in most other Internet applications. A mandatory to
implement mechanism should store password verifiers in a format that's
suitable for use by the Internet application suite. Otherwise we're just
creating deployment problems. As far as I'm concerned, DIGEST-MD5 has made
CRAM-MD5 obsolete.
> I'm firmly against
> mandating code bloat and complexity solely for political reasons.
While this issue is political, there is a very serious technical
requirement behind it. Right now I'd estimate that at least 90% of
authentication on the Internet is done using unencrypted plain text
passwords. That's a security nightmare and a technical embarrassment for
the Internet standards community. The IESG decided that had to stop and
created a rule which has the real-world effect that any two products that
comply with recent IETF standards can be configured to authenticate to each
other using something other than unencrypted plaintext passwords. That may
not be enough to fix the underlying real-world problem, but it's a big step
in the right direction. I find the requirement incredibly frustrating
because there's no 100% right choice, but it's a sound technical
requirement.
> And really, *requiring* that something like a very lightweight
> "check-for-new-mail" type client implement TLS when it will never be
> used (by the target market for the client) is just silly.
The realistic question is: what is the minimal code bloat necessary for
that client which is _likely_ to prevent spewing unencrypted plain text
passwords around the network?
When I ask that question, I find that STARTTLS + plaintext password is the
# 1 answer. Yes, TLS is a _huge_ amount of code. But at this stage every
useful Internet device needs TLS support and most of them already have it,
often as an OS-provided library, so the effective code bloat for your
client is pretty small.
DIGEST-MD5 is a distant second choice on the practicality scale (it's
viable across the application protocol suite, but the tools to manage
DIGEST-MD5 users in LDAP just aren't there yet) and everything else I've
studied (CRAM-MD5, Kerberos, SRP, OTP, X.509) is impractical for one reason
or another.
- Chris
---------- End Forwarded Message ----------
