--On Monday, 06 June, 2005 19:03 -0400 Sam Hartman
<hartmans-ietf(_at_)mit(_dot_)edu> wrote:
...
Dave> 2. Taking note of the exact language used in the
sentence Dave> citing MD5 -- specifically the "may be
sufficient", please Dave> supply alternative language.
That sentence recommends both cram-md5 and digest-md5. I think
digest-md5 is fine; I think cram-md5 is not. I'd like to ask
that you simply drop the word cram-md5 and appropriate
conjunctions.
...
Sam,
With the understanding that CRAM-MD5 was originally specified as
a quick hack to provide a low-infrastructure alternative to
clear-text passwords --a sort of "better than nothing
authentication" in its time and that I'm not especially attached
to it despite having my name on the RFC...
This business of comfort with digest-md5 and discomfort with
cram-md5 comes up regularly. So, far, each time it has been
probed, the answer has ended up being that the added security
associated with the digest form is, in practice as distinct from
theory, fairly marginal. That might be uninteresting were it
not for another, possibly inconvenient, observation: I don't
have hard data on this but my subjective impression from having
watched the market is that CRAM-MD5 is much more widely
supported in both SMTP authentication and in its POP3 and IMAP
variations than the digest form.
I don't pretend to be a security expert, so let me describe the
situation as I think it has been explained to me in the hope
that you (and others) will comment in somewhat more precise
technical depth than "...I think cram-md5 is not".
In a more perfect world, we wouldn't use shared secret
authentication models at all. Regardless of how the secrets are
exchanged or verified, they have a number of weaknesses as
compared to, say, systems based on good PKI environments, good
certification and trust models, close binding of user identities
with credentials, users who understand how to manage private
keys (and passphrases, etc.) and never lose them or handle them
in ways that could create doubts about the control and ownership
of such keys, and so on. Those PKI-based and similar strategies
would, of course, be easy to implement in a secure way and would
not add significant code footprint, execution time, or
operational or implementation complexity to either the relevant
clients or servers.
I hope we can agree that the world is not that perfect or, at
least, that we aren't there yet. Perhaps someday.
Until we get there, we are stuck in the world of shared secrets,
whether in the form of passwords or something more complex. At
least to some of us who are outside the security community, that
world involves a rather simple tradeoff:
* If the server host is more trusted than the network,
then we prefer "prove that you know the secret"
approaches that avoid transmission of the secret itself
across the untrusted network. Most of those "prove that
you know the secret" approaches depend on hashes of more
or less complicated strings. They also require that the
server, as well as the user, have the secret more or
less in clear text in order that those hashes can be
computed. There are methods around that use different
approaches, but they increase either complexity or the
number of handshakes significantly.
* If the network is more trusted than the server, then
we are, surprisingly, better off with passwords than
with hash/ "proving" techniques, since the version of
the secret on the server can then be protected by
aggressive one-way hashing or encryption. Within this
framework, we can try to make the network even more
trusted, but the really effective ways to do that
require either that the client machine already know, and
know securely, the key arrangements of the server
(impractical for email and many other applications) or
we end up back into the PKI problem and ideal worlds.
Curiously, at least one popular way to protect network traffic
and make the network more trusted illustrates the problem:
classic uses of SSH give the user (or system administrator) a
choice between using key arrangements that must be known in
advance on both machines and which create a vunerability if the
client machine and keys fall into the wrong hands or use of a
password-like arrangement that is more easily guessed than a
long key (the tunnel that protects the password is not a useful
defense against password-guessing attacks). I think even many
of us non-experts at least understand the issue and tradeoff.
Supposing that I'm designing an application and I decide that
the public key route is not appropriate for my environment. I
also decide --correctly or not-- that I trust my servers
significantly more than I trust the network. So I decide to go
with a shared-secret plan that doesn't involve transmitting the
secret across the network in clear.
Now I have two problems. The first is whether the mechanism I
use to test knowledge of the server across the network is good
enough. There, picking up on Dave's note, the key is MD5
itself. We were told when we did CRAM-MD5 that using a keyed
model would provide significantly more security than the basic
hash, with small incremental computational cost. Paul Krumviede
understood that argument and agreed with it; I really didn't,
but I trusted both the advice and Paul. The digest approach
came onto the radar for this purpose a bit later, but, if I
recall, we never got an argument that it was significantly more
secure in terms of protecting the network transmission (and Paul
is, unfortunately, not around to participate in that
evaluation). RFC 2617 does state that the digest method is
"significantly stronger than CRAM-MD5", but it is a little short
on explanation of attacks, metrics, etc., by which that
assertion can be judged. If the digest-based technique isn't a
_lot_ better than simple keyed-MD5, then perhaps it is time that
you folks tell us what we should be using instead of MD5-based
approaches and we should be working together to get it
deployed... as long as it doesn't require extra turnarounds or
public key utopia.
My other problem is what I do to protect the secret on my
server. Now remember that, in getting this far, I have already
decided I'm willing to trust my server more than I trust the
network. There are a number of interesting things I can do,
some of which may be operationally very effective and none of
which are visible in the protocol (which means an attacker has
the added problem of figuring out just what I am doing): I'd
need to be pretty overconfident, and pretty stupid, to put a
collection of name-value pairs in
/etc/cram-md5-cleartext-secret-file.
As the abstract to RFC 2617 puts it, "As with most other
authentication protocols, the greatest sources of risks are
usually found not in the core protocol itself but in policies
and procedures surrounding its use." It is my suspicion that
the differential potential for risk associated with the protocol
nature of these two methods is overwhelmed by the potential
risks associated with poor operational decisions... and that the
IETF community has not been especially helpful about making
recommendation for good operational policies with either.
If we look further at that server vunerability, the digest
method permits the password file, if stored locally, to utilize
an application-specific or server-specific realm. The "plain"
keyed-MD5 method doesn't require the realm, but is
(deliberately) defined broadly enough in terms of what happens
on the server host to permit a wide range of alternatives. Both
methods ultimately require that the secret be stored in a state
that is close enough to clear to make the list of secrets
vunerable if the server is compromised.
Now, again, I'm not particularly attached to CRAM-MD5. It
served its purpose by providing an implemented and deployed
demonstration that one could avoid the "clear text password over
the network" trap with little marginal overhead in applications
or servers. If there is community consensus that the digest
approach is better, or that it is time to start migrating to
MD-2005, I'll back that as strongly as I can. But I do have a
strong preference for standards that will actually be deployed
and used. To the extent to which the current draft is useful,
we are much more likely to see effective deployment if we keep
the number of changes required in clients and servers to the
minimum number needed to carry out the intent of the spec. In
the case of a spec like this one, which is intended to improve
the security and reliability of the email environment as seen by
the user, the question "will this make things better" is at
least as important as "will this make things ideal or provide a
perfect solution".
To that end, since CRAM-MD5 is very widely deployed, I'd like to
see a much stronger justification for removing it than matters
of taste.
On the other hand, if your and your colleagues have concluded
that CRAM-MD5 is inherently dangerous or harmful, I think it is
about time we see an RFC that documents that reasons for that
conclusion, approved through a community consensus process, and
containing recommendations for phasing CRAM-MD5 out, just as the
IETF has previously recommended phasing out clear text passwords.
regards,
john
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf