> 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.
timestamps would not prevent MitM attacks, because the attacker can
intercept communications quickly enough that the timestamps are still
valid. I believe timestamps can deter replay attacks if they're
implemented correctly.
Both CRAM-MD5 and DIGEST-MD% employ nonces, not timestamps, in their challenges
and responses. Both are therefore vulnerable to MITM attacks, although
DIGEST-MD5's use of both client and server nonces prevents an attacker from
using a precomputed dictionary that corresponds to a known challenge.
And although APOP uses something called a "timestamp", it does not define a
specific format that would allow a client to check and see if the time is
within a valid range. Even the suggested format of
<process-ID(_dot_)clock(_at_)hostname>
is only a suggestion, and even if it were a requirement the lack of a precise
definition of the "clock" part makes it impossible for a client to check and
see if the time is within a particular window. So APOP also ends up using
something that's effectively a nonce, not a timestamp.
> As to APOP not being relevant to message submission, it CAN BE if the
> POP session that was initiated via APOP then has XTND XMIT commands
> submitted (to have the POP Server act as a MSA for relating to a MTA).
Good point.
I'm not sure XTND XMIT is particularly relevant - it has so many
problems of its own that the added issue of dragging POP authentication
matters into the MSA realm seems rather trivial.
POP-before-SMTP, OTOH, is very common, and that makes POP authentication very
relevant indeed. POP-before-SMTP also carries with it an additional, unique set
of security risks. Do we need to document them as well?
Ned