Christian,
Thanks.
This is, IMO, _exactly_ the sort of explanation and
recommendation that needs to be turned into an I-D titled
something like "Challenge-response over unprotected channels no
longer adequate" and published as a BCP. It didn't require
very many paragraphs of explanation, it is quite clear, and it
is hugely more helpful than what end up sounding like personal
authority statements of the "I don't like it so you shouldn't
use it" variety.
It may be just my ignorance, but this does raise, for me, some
additional issues. Perhaps they should be put on the agenda for
discussion in the Apps Area meeting (assuming on is held) in
Paris, since this impacts not just email but just about every
application we have:
(1) Given the problem you describe, then the key feature
of digest-MD5 is not the difference in algorithm, but
the fact that it uses a privacy layer. That should
probably be much more clear than it has been in most of
the "digest-MD5 is better" discussions.
(2) If the key issue is "be sure you are talking to the
right server", then one could still use a
challenge-response mechanism as long as the server were
properly verified to the client. Presumably that could
be accomplished by client possession and verification of
a server key or by an extra secret and handshake. That
would presumably be "good enough" unless we also have a
significant concern about sessions being hijacked once
they have been properly initiated. I don't know the
degree to which that is a practical concern (remember
that SMTP sessions, especially pipelined ones, are
typically pretty short and that, e.g., IMAP has
provisions for in-session reverification although I
believe they are still not intensively used).
Conversely, if the server identity is not verified, or
is verified only by the luser's receiving an
incomprehensible warning message and clicking "accept"
every time, then even encryption wouldn't seem to help
much.
(3) I may no longer fully understand the implications of
"dictionary attack" and suspect that at least some
application writers understand it even less well that I
do. But, if my understanding is correct, it seems to me
that, if passwords or passphrases are readily vunerable
to dictionary attacks, there are other problems and the
presence of encryption would pose an inconvenience, not
an obstacle, for the attacker.
Is that correct?
john
--On Saturday, 11 June, 2005 00:04 -0700 Christian Huitema
<huitema(_at_)windows(_dot_)microsoft(_dot_)com> wrote:
(1) "known weaknesses [citations]" is significantly different
from "we don't like it" or "we assert it is bad" or even "we
don't like things unless they contain several additional
layers". The third of these might be a reasonable statement,
but would require even more justification because...
Times change. Today, using challenge response mechanisms such
as CRAM-MD5 over un-encrypted channels is not much more secure
than sending password in clear text. If a third party can
listen to the challenge and response, and then mount a
dictionary attack.
Steve Bellovin was alluding to the "evil twin" attack on
wireless network. Allow me to elaborate.
The technique allows an attacker to lure unsuspecting
travelers to connect to an un-protected wireless network under
the attacker control. Very often, laptops are programmed to
fetch pending e-mail as soon as they connect to a network. The
laptop will try resolve "mail.example.com", and start a POP3
or IMAP exchange. The attacker controls the DNS service on the
wireless network, and will easily spoof the server. It will
then respond to the connection with a CRAM-MD5 challenge, and
harvest the e-mail address of the victim as well as the answer
to the challenge. The attacker is now in a position to obtain
the e-mail and password pair for the victim. The attack lasts
a few seconds, and may not require any particular action by
the victim.
IETF protocols should not endorse the use of unprotected
challenge-response mechanism. They certainly should not lure
clients to accept challenges from unauthenticated servers.
-- Christian Huitema
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf