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

[Jeffrey M. Vinocur]

On Sep 17, 2004, at 8:40 AM, 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.  [...]
>
> 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.
>
> <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. [...]

Let me take a stab it this, for completeness.  Assuming I've understood 
it correctly.

(I think this is one of those things that doesn't need to be completely 
explained in the protocol, actually.  I mean, a programmer implementing 
a spec doesn't have to explain exactly what went in to every design 
decision, and at some point the sheer quantity of explanatory material 
makes the overall task -more- complicated.)

You should keep in mind a couple underlying assumptions that are true 
in other SASL-using protocols perhaps more than NNTP.  One is that the 
client may have some way to verify the server's identity after the 
connection is established.  Another is that the data passing over the 
connection is more valuable than the user's password itself.

In the kind of attack being considered, an attacker has the ability to 
snoop on the (initially unencrypted) connection, and to forge packets 
appearing to come from the server.  At some point the client sends LIST 
EXTENSIONS, and the attacker forges a response in which the list of 
available SASL mechanisms has been altered.  In particular, the 
strongest mechanisms have been removed from the list.  So the client 
sees the altered list, and selects one of the (weak) available 
mechanisms, even if the client would have preferred something else that 
might have been in the unaltered list.  When the server's LIST 
EXTENSIONS response arrives, the client TCP stack discards it as a 
duplicate.  The client and server proceed with the SASL negotiation 
(the server having no idea the client hasn't chosen its ideal 
mechanism), and establish a SASL layer.  Keep in mind that it's the 
true server (and the client has perhaps verified this  during the 
exchange in a way the attacker couldn't forge); the attacker is not 
forging any packets during the negotiation.  So the attacker has 
"successfully" caused the established layer to be weaker than 
otherwise, and now a second attack has to be used -- but perhaps an 
attack is known against the weaker mechanism now in use.


> 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

This seems decent at first glance, actually.  (Although I don't know 
how I feel about the "-" as a special parameter.)


-- 
Jeffrey M. Vinocur
jeff at litech.org