Re: [xmppwg] Major SASL issues (was Re: Last Call: 'XMPP Core' to Proposed Standard)

[Rob Siemborski <rjs3@andrew.cmu.edu>]

On Wed, 8 Oct 2003, Peter Saint-Andre wrote:

> > Other protocols (IMAP/SMTP/POP) list available SASL mechanisms after a
> > successful SASL authentication.
> > Some of them require that the client compares the list of the advertised
> > mechanism with the one before the authentication.

This claim isn't true.  SMTP has a MAY for this, the other protocols don't
express an opinion one way or the other.  I know some IMAP and POP
implementations remove the capability after a successful authentication
(to indicate that the AUTHENTICATE/AUTH command is no longer valid)

> > This is done to prevent man-in-the-middle attacks when an attacker
> > removes strong SASL mechanisms from the list of supported mechanisms.
> > (Whether this check is useful in practice is another matter. I am not
> > sure whether anybody implements it).
>
> OK, I'll look at what those other protocols require, and how they word
> the requirement. It seems good to have this check in place.

I'm not sure its terribly useful, since the real way to prevent this MitM
attack is that a client should not use a mechanism that does not support
its minimum security requirements, not find out after the fact that you
have an active attacker.

I will also be posting IDs within the next few days that are revisions to
RFC 1734 (and the SASL bits of RFC 2449) and RFC 2554, which may also be
useful to look at (hopefully they will be clearer).

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K-
w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y?
------END GEEK CODE BLOCK-----