[NNTP] LIST EXTENSIONS (again)

Ken Murchison ken at oceana.com
Tue Nov 9 07:11:27 PST 2004


Clive D.W. Feather wrote:

> Ken Murchison said:
> 
>>>Um, just out of interest, doesn't this mean that the argument of a 283
>>>response is insecure as well?
>>
>>Yes.  Its designed this way because the client may not yet know what 
>>security layer(s) the server has selected.  Just like TLS, the security 
>>layer can't take effect until negotiation has completed.
> 
> 
> But that's nothing to do with the content of the 283, is it?

It may.  The last server "challenge" is more than a "negotiation 
complete" message.  Its typically used for the server to authenticate 
itself to the client, but *could* be used to say "here's the cipher/MAC 
that I've agreed to use for the rest of the session".

>>We'd be straying from the beaten path (IMAP, POP, SMTP) with this 
>>proposal which is something that I'd personally like to avoid.
> 
> 
> Though Mark says that this is the way he wished he'd done it in IMAP.
> Are we never allowed to learn from our predecessors' mistakes?

Actually, now that I think about it none of IMAP, POP or SMTP support 
"success data" in the response.  Only newer SASL-enabled protocols 
(LDAP, BEEP?) support this in their SASL profiles.  Nonetheless, the 
SASL spec states:

"The security layer takes effect immediately following the last response 
of the authentication exchange for data sent by the client and the 
completion indication for data sent by the server."

I guess the term "completion indication" could be somewhat misleading, 
but I *think* this is pretty clear that the "success data" response 
should NOT be encrypted in any way.

-- 
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



More information about the ietf-nntp mailing list