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

[Jeffrey M. Vinocur]

On Sep 22, 2004, at 10:28 AM, Clive D.W. Feather wrote:

> Jeffrey M. Vinocur said:
>
>> (I think this is one of those things that doesn't need to be 
>> completely
>> explained in the protocol, actually.  [...]
>
> I appreciate your point there.
>
> The problem in this case is that the requirement is apparently 
> nonsense and
> self-contradictory: after establishing a security layer:
> * you MUST advertise AUTHINFO even though you can't use it;
> * you MUST NOT advertise STARTTLS *because* you can't use it.
> Plus the mention of an "active down-negotiation attack" without 
> explaining
> how this prevents/detects it.

Point.


>> 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.
>
> External to the link or internal?

I was purposefully vague because I didn't want to look up specifics, 
but in principle the SASL negotiation can be bidirectional, similar to 
the way a web browser would verify a TLS server certificate.


>> Another is that the data passing over the
>> connection is more valuable than the user's password itself.
>
> Hmm. Surely if you've got the password then you have access to the 
> data at
> your leisure?

Not if it's a one-time pad or a challenge-response mechanism :-)


> Ah. This is *not* what "man in the middle" means to me. [...]

Yeah, I'm not sure if there's a different attack that I haven't thought 
of, or if it's just a terminology problem.


>> [...] So the client [...] selects one of the (weak) available
>> mechanisms, even if the client would have preferred something else 
>> that
>> might have been in the unaltered list.
>
> Okay. I'm not sure how much of a threat that is, but ...

Seems contrived to me too :-)


>> When the server's LIST
>> EXTENSIONS response arrives, the client TCP stack discards it as a
>> duplicate.
>
> Only if it's exactly the same length. If it isn't, the two ends will 
> now
> be out of sync.
>
>     Attacker sends  "AUTHINFO SASL:WEAK" as the last item in the 
> response.
>     Server sends "AUTHINFO SASL:WEAK,MEDIUM,STRONG" as the last item.

*shrug*  So the attacker sends "AUTHINFO SASL:WEAK FOOBAR GZNORT" 
instead, and the client (appropriately, kinda) ignores FOOBAR and 
GZNORT think that they're new authentication types it doesn't 
recognize.


> I follow this, though if SASL:WEAK isn't strong enough the client 
> shouldn't
> be using it.

Fair enough, but with the eternal luggage of backwards compatibility, I 
wouldn't be surprised if a client will at least have to option to fall 
back to anything that might work rather than give up the connection.


>>> 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.)
>
> Better something like that than "DONTUSE". I would have suggested
> "-AUTHINFO USER SASL:EXTERNAL" except that the first word has to be all
> uppercase.

*nod*

It's a bit more of a change late in the game, but what do you think 
about putting the - before each of the forbidden auth types?  Say, 
"AUTHINFO -USER -SASL:EXTERNAL".

-- 
Jeffrey M. Vinocur
jeff at litech.org