Kurt and Sam,
I hope someone else will pick up this discussion, as I'm not the
right person to lead it. I would encourage you to read and
react to Simon's comments as a start. However, let me make a
couple of additional observations:
* CRAM-MD5 was caused because folks in the security area said
"no more clear text passwords" to applications folks, then more
or less stepped away. Whatever the strengths or weaknesses of
either clear text passwords or CRAM-MD5, it was considered an
advantage at the time that they provided authentication, and
authentication only. In particular, an authentication-only
model, with no attempt or pretense at privacy or integrity
protection for message content, avoids entanglements with any
national or trans-border restrictions that might exist (or be
imagined) on encryption, law enforcement access to keys, etc.
Now sometimes that is ok, and sometimes it isn't. I am often
reminded of a conversation with an MIT senior faculty member
some years ago about exposure of information in a
generally-accessible shared-printer environment. Her response
to my concern was that, if someone decided to pull her material
off the printer and read it, maybe they would learn something
and that was what she and the Institute were all about. It all
depends on the circumstances.
* There is a huge difference between telling a user or
implementer, in a Security Considerations section or otherwise,
"hey, CRAM-MD5 just provides authentication and no privacy or
integrity protection, if you need either of those, you need to
use it with something else or use something else entirely" and
saying "we have decided, in our wisdom, that authentication-only
solutions are inadequate for you and should be discouraged".
The claims about man-in-the-middle attacks are another matter.
When the analysis was done in 1996, the conclusion was that such
attacks were not possible unless either the secrets were already
known to the attacker or there was a plausible attack on
HMAC-MD5 itself. If such attacks are now seen to be plausible,
or if post-authentication session hijacking has become a
dominant concern in practice, it is, as I indicated in my
earlier note, time to document that and to use the documentation
as the basis for explicitly deprecating CRAM-MD5 (or HMAC-MD5
itself if necessary). Similarly, if there is really consensus
in the IETF community that authentication without message
integrity protection, etc., are useless or worse, then it is
time to document that opinion and the associated consensus and
see if we can start persuading implementers and the marketplace
to move on.
But, in the presence of a fairly broad installed base and
interoperable implementations, I suggest that far more is needed
that the personal preferences of the two of you, or even the
personal preferences of the entire security community, before it
is reasonable to start recommending against the continued use of
a widely-deployed practice. IMO, such a recommendation has to
be considered a very serious step, especially when the practice
was started as the consequence of some rather specific IETF
recommendations. We should consider "never mind what we said
a decade ago about clear text passwords, protected or not; we
now prefer such passwords when sent through encrypted tunnels to
be preferable to challenge-response models" to be a fairly
serious step in terms of IETF credibility if nothing else and
should not take it unless we have clear documentation and clear
consensus, not just changes in taste.
john
--On Thursday, 09 June, 2005 06:36 -0700 "Kurt D. Zeilenga"
<Kurt@xxxxxxxxxxxx> wrote:
> 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