[NNTP] Notes on auxiliary documents

[Charles Lindsey]

In <20041117102357.GC67699 at finch-staff-1.thus.net> "Clive D.W. Feather" <clive at demon.net> writes:

>Charles Lindsey said:
>>>> Sections 2.4.2 and 6: we say that the server MUST discard all knowledge. 
>>>> Does this include NNTP state?

>I see that the current wording (06pre1) says that it does.

>> Suppose you are in Group A, happily reading articles. Suppose you now
>> encounter an article cross-posted to the restricted group B. The server
>> invites you to authenticate, which you do. You would now like to be in the
>> same NNTP state as before, still in Group A with the crossposted article
>> still the current article, so you can now read it.

>Very true. This suggests that the state should *not* be reset.

I think before we go any further we need to understand _why_
authentication might be needed in various cases, and the first question is
"for whose benefit is it?" Consider the general case of a server and a
client.

Model 1. The server provides the same service/data to all of its clients.
It wants to exclude non-paying customers. Or to exclude customers that it
cannot get back at if they abuse their privileges. So the _server_
requires its clients to authenticate (the clients could not really care
less, and tend to use rather weak passwords/whatever).

Model 2. The server provides a different service/data to each client. The
client does not want other clients to access his private service/data, so
the _client_ insists on having authentication performed before his private
service/data is accessed. The server could not really care less - if
clients are happy to work without authentication, or to use weak
passwords/whatever, then it is they who are going to lose out.

NNTP is a typical example of Model 1. The same data and services are
available to all customers (or, perhaps some data/etc is free and some is
restricted as in my example above, perhaps attracting a higher fee). No
harm arises if server state before authentication is maintained after
authentication (it might arise if state could be maintained after
de-authentication, but I don't think we are proposing to provide that).
And whatever harm does arrise is harm to the server, not harm to the
client.

An online bank is a typical example of Model 2. If some imposter can
access my account, then it is I (the client) who suffers, not the bank (at
least not directly). If the imposter can set up some state without
authenticating, which I inherit upon authentication, then I may well be in
trouble, so in model 2 it is indeed right that state should be cleared
entirely upon authentication.

Of course, there may be applcations that have a bit of both models in them
- those are just the extreme cases. But I think the writers of the SASL
and TLS standards had Model 2 primarily in mind (and I think there are
likely more Model 2 applications out there than Model 1). Hence the hard
rule that authentication clears state.

But my point is that the somewhat rarer Model 1 case has been overlooked,
in which that rule is too severe (and even undesirable, as in the example I
quoted).

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