Robert A. Rosenberg wrote:
At 23:57 -0400 on 06/15/2005, Keith Moore wrote about Re: request
discussion of two documents on SMTP relaying:
regarding cram-md5: anything that does challenge-response without
changing the key each time is easy to break independent of what hash
algorithm is used, especially in the case of a wireless network where
it's very easy to impersonate a server and mount a man-in-the-middle
attack. one time passwords (s/key) work okay, but not
challenge-response. this implicates cram-md5, and also APOP (not that
this is relevant to message submission), and some other things too.
It was my impression (possibly in error) that SMTP AUTH CRAM-MD5 and
POP's APOP Handshakes encrypt a string that includes a timestamp (and
thus changes each time) so the encrypted reply is unique and one-time
(and thus immune to replay attacks) so they are safe from monitoring and
man-in-the-middle.
No. See RFC 2195 for a description. N.B. "impersonating a server". The
attacker can simply claim to be a particular server and send the "ready
response". It then collects the client string which can be analyzed at
leisure. Another type of man-in-the-middle attack is to allow the client
to connect to and authenticate to the "real" server, while collecting the
authentication transaction for later analysis. A third type of
man-in-the-middle attack is to allow the client to connect to and
authenticate to the "real" server, but to then substitute MAIL FROM,
RCPT TO, and DATA commands of the attackers choice.
Note that the key (the "shared secret" of 2195) is not changed. In addition
to particular hashing scheme weaknesses, the key can be determined (as the
attacker knows the cleartext (the "ready response" of 2195), the hash
algorithm, and the encrypted text) by many methods, including dictionary
attacks or by guessing values based on the (N.B.) cleartext user name
supplied by the client.
Keith is correct that failure to change the key makes the mechanism
susceptible to attacks involving determination of the key (which can be
used at any time).
However, even one-time keys cannot prevent the sort of attack involving
attacker substitution of SMTP session commands. TLS won't protect
against impersonation of a server (the attacker can easily choose to
accept the client certificates and supply session keys, using TLS as if
it were the server it is impersonating; it can then collect client
authentication transactions and/or forward certificates and session
packets to the "real" server, passing responses back to the client and/or
substituting SMTP commands and data of the attacker's choice). Full-blown
VPN might help, but might not have been thoroughly analyzed w.r.t. the
type of attacks discussed above.
Much of the above is not SMTP-specific. However SMTP AUTH is asymmetric;
it provides for the client to authenticate itself to a server but provides
no mechanism for a client to determine the authenticity of the server. It
is that weakness which allows for impersonating a server as described above.
That fundamental weakness is not addressed by either of the two documents
under discussion.