[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