ietf-smtp
[Top] [All Lists]

Re: request discussion of two documents on SMTP relaying

2005-06-16 07:50:31

> 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