My personal view (e.g., SASL chair hat off) is that CRAM-MD5
use on the Internet should be limited. It fails to provide
any form of data security itself. The lack of integrity
protection means sessions are subject to hijacking. While
this inadequacy can be addressed by protecting the session
with TLS, if TLS is used then it becomes a real toss-up
between CRAM-MD5 and PLAIN. While CRAM-MD5 might be viewed
by some as better, I note that PLAIN provides for better
interoperability in systems involving external password
stores (especially in face of string preparation requirements
to be added in revisions of PLAIN and CRAM-MD5 specifications),
and provides support for proxy authorization (identity
assumption).
It is my recommendation that the mandatory-to-implement
"strong" authentication mechanism for this protocol be either:
DIGEST-MD5 (with a mandate that implementations
support its data security layers)
TLS+PLAIN (with a recommendation that PLAIN not
be used when TLS is not in use).
I have slight preference for the latter.
Kurt
At 03:52 PM 6/8/2005, Sam Hartman wrote:
>Hi. I'm not in a good position to write a long response now; let me
>know if you do end up wanting a longer response and you'll get it in a
>week or so.
>
>I don't think cram-md5 is a reasonable best current practice. I think
>it is accurate to describe it as a common practice.
>
>It's my recollection that cram-md5 is vulnerable to man-in-the-middle
>attacks but digest-md5 is not. It's also my recollection that
>digest-md5 will do a much better job of supporting servers that do not
>want to store plaintext equivalents than cram-md5. The server will
>store a secret that is sufficient to log into that server but may not
>be sufficient to log into other servers.
>
>
>Digest-md5 also supports an integrity and confidentiality layer.
>
>I think all of the above are significant advantages over cram-md5.
>
>If you are concerned that digest-md5 is not sufficiently widely
>implemented then let's recommend plain+tls and digest-md5. I think
>those are two low-infrastructure protocols in wide use.
>
>_______________________________________________
>Ietf mailing list
>Ietf@xxxxxxxx
>https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf