ietf-nntp TLS and AUTHINFO interaction

[Ken Murchison]

Charles Lindsey wrote:
> 
> Authenticated or not authenticated.
> Encrypted or not encrypted (i.e. in TLS state of not in TLS state).
> 
> That gives four possibilities (though not all may be common or allowed).
> 
> Now it seems to be that STARTTLS should be allowed when you are in non-TLS
> state and vice versa. Why should the authentication state come into it?

It doesn't _have_ to, it just makes life easier.  What happens if a
client has already authenticated, and then does STARTTLS with a
certificate whose identity doesn't match the authenticated user?

> And BTW, I hope people will be allowed to re-authenticate (for example, if
> some response tells tham that their present authentication level is
> insufficient for some special purpose).

Previous discussions determined that the client can just reconnect and
authenticate as needed.

I'm not going to argue strongly against any of these points, but I don't
see the need to complicate server implementations (auth, reauth, tls
after auth, etc) just to satisfy some edge cases.  Its seems a hell of a
lot simpler to just disallow then and force the client to reconnect when
necessary.  The cost of a new connection is relatively cheap.

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