ietf-nntp TLS and AUTHINFO interaction

[Ken Murchison]

Russ Allbery wrote:
> 
> Jeffrey M Vinocur <jeff at litech.org> writes:
> > On Mon, 3 Mar 2003, Ken Murchison wrote:
> 
> >> - section 4.3:  Instead of flushing the authentication info, why not
> >> just say that the STARTTLS command is only valid in the
> >> non-authenticated state (didn't we already decide that we shouldn't
> >> allow multiple authentications)?  RFC 2595 does this.
> 
> > People?
> 
> I generally agree with Ken, but there's one problem that comes to mind.
> 
> Suppose that a server generally requires authentication for everyone.  It
> also has a particular newsgroup that requires transport security (maybe it
> contains confidential corporate information or something).
> 
> What happens when someone connects, authenticates as normal, reads some
> Big Eight news without encryption (since it's all public data anyway), and
> then tries to read that private internal group?
> 
> If we disallow STARTTLS after authentication, that client would have to
> disconnect and then reconnect with STARTTLS at first.
> 
> I don't think this is that common of a problem, but on the other hand it
> does seem like we could allow for it by flushing the authentication data
> after STARTTLS.  But I don't feel strongly about it.

Yeah, I think this a solution looking for a problem.  It seems to add
more complexity to implementations with very little benefit.  This would
be the first protocol that I'm aware of that would have STARTTLS and
authentication interaction like this.  You know what they say about
pioneers  ;)

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