ietf-nntp TLS cipher renegotation to NULL cipher

[Ken Murchison]

"Jeffrey M. Vinocur" wrote:
> 
> On Sun, 5 Jan 2003, Ken Murchison wrote:
> 
> > "Jeffrey M. Vinocur" wrote:
> > > if a server admin wants to allow users to protect their entire connection,
> > > but wants most of them to drop to the NULL cipher after authentication?
> >
> > Per RFC 2246 both the client and server can request a reneg anytime, and
> > either are free to refuse to do so if they wish.  So, I think there is
> > already enough controls to configure the client/server policy.
> 
> Well, in the scenario above, it doesn't seem like the client can
> distinguish between the server saying "renegotiate to NULL or I'm
> disconnecting you" and "I'd like NULL but you don't have to".  But I guess
> this could be implemented by the server requesting NULL, the client
> complying, and then the client requesting encryption again and seeing if
> it succeeds.
> 
> Or maybe this is an absurd situation?  I'm hoping to hear back from e.g.
> Andrew about what might actually occur.

I'm not sure what type of configs you're looking for, some I'm a little
confused.  Maybe a little background on how TLS negotiation works might
help clarify (caveat: I'm not expert either).  In a normal scenario, the
client presents a list of ciphers that it is willing to use to the
server.  The server then picks one and tells the client whcih one to
use.  This is the same in a renegotiation case as well.  A client
initiated reneg looks essentially the same as a initial negotiation.  In
a server initiated reneg, the server simply tells the client to start a
negotiation.  This is why a server can't force the client to use the
NULL cipher, it can only select it if presented by the client.  In my
reading of the OpenSSL docs, it _might_ be possible to have the server
present the client with a list of ciphers, but I haven't investigated
further.

> 
> > >     - client authors will provide the NULL cipher
> >
> > I'd make this a SHOULD, with the caveat that it MUST not be available
> > until after authentication.  Some clients/users may _always_ want the
> > complete session protected.
> 
> (Your second sentence there indicates possible confusion -- I was saying
> above that clients should implement the NULL cipher, not that they always
> have to be willing to renegotiate to it.)

OK.  That's fine.


> > >     - client software will be configurable as to whether to use encryption
> > >       only for authentication or all the time (implemented by attempting
> > >       renegotiation to NULL after authentication is complete, and again
> >
> > I'd say MAY.  I'd be interested in hearing when the client would want to
> > initiate a downgrade, rather than the server requesting it.  Would this
> > just be for performance reasons?
> 
> I can't think of any other reason offhand, but performance is definitely
> important to users.
> 
> > >       back to a real cipher before beginning any subsequent
> > >       authentication steps)
> >
> > What subsequent authentication steps?  I don't think that multiple
> > AUTHINFOs should be allowed in a single session.
> 
> *blink*  Ok, I'll raise this in a separate post.
> 
> >                                                   The same can be said
> > about STARTTLS for that matter.
> 
> Well that's definitely true, and there is text to that effect in the
> draft.  I will emphasize it, however.
> 
> > server should not request a reneg using the NULL cipher until after
> > authentication.
> 
> Well sure, but should this be mandated by the spec?

Not mandated, but discussed in the security considerations section.


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