ietf-nntp TLS and AUTHINFO interaction

Charles Lindsey chl at clw.cs.man.ac.uk
Wed Mar 19 04:15:21 PST 2003


In <yl3clmlai1.fsf at windlord.stanford.edu> Russ Allbery <rra at stanford.edu> writes:

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

That seems to me totally wrong. There are the following possible states
for a session:

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?

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

That seems a perfectly realistic scenario to me.

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

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: chl at clw.cs.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5



More information about the ietf-nntp mailing list