At 07:33 -0700 on 06/16/2005, Ned Freed wrote about Re: request
discussion of two documents on SMTP relaying:
> 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.
The point that I was trying to make with my TimeStamp comment is that
every connection that I make to the POP Server will supply a unique
string to encrypt (due to the clock value in the string) so it will
be immune to replays (although a MitM could hijack the session or add
its own messages if it were acting as a proxy to the original session
setup.
> 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.
My point was that since XTND XMIT turns the POP Server into a MSA, so
long as this is a APOP as opposed to Plain-Text logon Session APOP
can have a relevancy to Message Submission. I was not addressing any
problems with its use (or are you saying that using XTND XMIT to
submit your messages has a different result from using SMTP to a MSA
Server?).
Ned