ietf-nntp TLS and AUTHINFO interaction

[Jeffrey M. Vinocur]

On Wed, 19 Mar 2003, Charles Lindsey wrote:
> 
> 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?

I get the impression that the normal TLS thing is to discard all 
pre-TLS (ie, untrusted) information immediately upon establishing the TLS 
layer.  In which case the user would have to authenticate again...so 
certainly if we're disallowing repeat authentication, it makes sense to 
consider this case.

(I don't have a strong opinion.)


> >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).
> 
> That seems a perfectly realistic scenario to me.

Oh, we all agree it's realistic.  The question is whether the complexity 
is justified when reconnecting (which happens all the time anyway) would 
make it irrelevant.

On the one hand the reconnection solution isn't particularly elegant, but 
it may be more pragmatic to linearize the possible stages of connection.


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

Again, this certainly has appeal.  But it seems that in the real world, 
this just isn't a feature that's really needed at present.

I'm open to more discussion about this, especially since we're considering 
adding support for authentication more along these lines to INN.  (For 
example, right now there's no way to have INN include a group in the 
result of LIST ACTIVE but return 480 if the client actually attempts to 
access it.  This is something that I believe people would find useful, 
though, and in that capacity it makes some sense to permit 
reauthentication.)

-- 
Jeffrey M. Vinocur
jeff at litech.org