ietf-nntp TLS and AUTHINFO interaction

[Charles Lindsey]

In <3E78BAE0.BC6825F at oceana.com> Ken Murchison <ken at oceana.com> writes:

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

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

Confusing two issues I think. STARTTLS when already authenticated is a
policy issue (maybe it is disallowed by our standard, or maybe it is left
to site policy, or maybe it automatically causes the authenticated status
to be lost).

Whereas turning STARTTLS off (as seen in LIST EXTENSIONS) is surely a
protocol (not a policy) issue - it is plain ridiculous to START it again
when you are already in TLS state.

And consider the following scenario.

	Command		State
1.	STATTLS		TLS
2.	AUTHINFO	TLS+AUTH
3.	Drop TLS	AUTH
4.	(re)STARTTLS	TLS (+AUTH maybe)

Your rule seems to forbid restarting TLS (for whatever reason) after it
has been dropped.

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

Seems a messy way of doing things, particularly if a brand new TLS state
has to be set up.

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