[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