[NNTP] Comments on draft-...-authinfo-03

[Ken Murchison]

Clive D.W. Feather wrote:

> Ken Murchison said:
> 
>>>2.2.2 para "After a security layer ...": why must the SASL mechanism list
>>>be the same? Why can't new ones be added? 
>>
>>This is to help detect man in the middle attacks.  Its possible for an 
>>active attacker to change the list of mechanisms that the client is 
>>presented.  When a security layer is negotiated (assuming its not 
>>incredibly weak), the client can compare the lists before and after SASL 
>>to see if they changed.  If the server unilaterally changed the list, 
>>then the client may think the connection is compromised.  I've change 
>>the paragraph to the following:
>>
>>"After a security layer is established, the server MUST continue to
>>advertise the AUTHINFO capability and "SASL:" argument (with the same
>>mechanism list as before authentication) to help detect active
>>attacks.  In addition the server SHOULD NOT advertise the STARTTLS
>>[NNTP-TLS] capability (as STARTTLS is not allowed after
>>authentication)."
> 
> 
> I remain confused.
> 
> Firstly, why won't an active attacker just present the old list anyway?
> It's no skin off his nose to do it.

Presumably if a security layer is negotiated, the attacker can no longer 
hijack the connection, thus can't change the list.


> <later>
> After much reading, I'm beginning to understand some of it (but still not
> the Man in the Middle bit). But I think the draft needs to explain it all
> much better.

Anyone implementing this extension will have to read RFC 2222bis, so I 
don't want to repeat what is already dicussed there:

    In order to detect Man-in-the-middle (MITM) attacks the client MAY
    list available SASL mechanisms both before and after the SASL
    security layer is negotiated.  This allows the client to detect
    active attacks that remove mechanisms from the server's list of
    supported mechanisms, and allows the client to ensure that it is
    using the best mechanism supported by both client and server.  New
    protocol profiles SHOULD require servers to make the list of SASL
    mechanisms available for the initial authentication available to the
    client after security layers are established.  Some older protocols
    do not require this (or don't support listing of SASL mechanisms once
    authentication is complete); for these protocols clients MUST NOT
    treat an empty list of SASL mechanisms after authentication as a MITM
    attack.

I suppose a reference to this text wouldn't hurt however.


> 
> Question to the group: would it be worth adding a flag to show that
> authentication is no longer possible? Something like:
> 
>     AUTHINFO - USER SASL:EXTERNAL


Or we could just ignore a SHOULD in RFC 2222bis and not display the 
AUTHINFO capability at all after authentication.  But I don't think this 
is a good idea.


> 
> ?
> 
> 
>>Note that this is also addressed in Section 6.
> 
> 
> Where?

My mistake.  I got myself confused between documents.


-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp