[ietf-nntp] Re: SASL capability

Rob Siemborski rjs3 at andrew.cmu.edu
Wed May 19 06:49:20 PDT 2004


On Tue, 18 May 2004, Russ Allbery wrote:

> Ken Murchison <ken at oceana.com> writes:
>
> > The one issue which we would need to address if we remove the standalone
> > SASL capability is whether or not we continue to return it after
> > authentication.

As it turns out, the new SASL draft requires this (or atleast highly
recommends it).

> I don't know very much at all about the theory there in detecting MITM
> attacks.  Do you know how important that's considered?  Is it just a
> possibly nice feature, or is it something that SASL protocols are strongly
> recommended to do?

The theory goes something like:

Client asks for mechanism list
Client picks "Best" mechanism, and authenticates
If client now has a protection layer (integrity or encryption), it can ask
 for the list of mechanisms again.
If there is now a stronger mechanism available, then presumably you've
 detected a MITM (note, there may be a weaker mechanism available as well,
 but generally the idea is that the list shouldn't change at all).

Really, a MITM attack should be defeated when the client picks its
mechanism, because the client shouldn't pick a mechanism it is unwilling
to use -- so this isn't to *defeat* a MITM attack, it just potentially
detects it.

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * rjs3 at 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+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y?
------END GEEK CODE BLOCK-----




More information about the ietf-nntp mailing list