Subject: Re: [NNTP] Notes on auxiliary documents

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 18 Nov 2004 16:17:21 GMT

In <[email-masked]> "Clive D.W. Feather" <[email-masked]> 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: [email-masked]      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

---

From: Russ Allbery <[email-masked]>
Date: Tue, 30 Nov 2004 19:40:38 -0800

Ken Murchison <[email-masked]> writes:
> Clive D.W. Feather wrote:

>> Section 2.3.2 gives too much emphasis on non-conforming
>> implementations. Replace it completely with something very similar to:

>>     On a server which conforms to this specification, the MODE STREAM
>>     command MUST return a 203 response (or 501 if an argument is given)
>>     and MUST NOT have any other effect.

>>     Historic note: some old server implementations did not advertise
>>     streaming in the response to LIST EXTENSIONS but provided CHECK and
>>     TAKETHIS commands similar or identical to those in this document.
>>     Clients could test for this by issuing the MODE STREAM command; if
>>     it succeeded, pipelining was possible. However, even if the command
>>     succeeded it does not mean that the CHECK and TAKETHIS commands
>>     conform to this specification. Clients SHOULD use the CAPABILITY
>>     command to determine server capabilities.

> First off, I think Russ signed off on the current text, but I'm willing
> to clarify if needed.  In fact, I like most of what you have above.

> This is a similar situation to MODE READER.  We are trying to steer new
> implementations away from MODE STREAM but document its prior use.

> Russ, can you provide some guidance?

MODE STREAM is different than MODE READER; MODE READER is something that
we don't yet have a way of getting rid of entirely (unless you all have
come up with something; I'm massively behind but trying to catch up
tonight).  MODE STREAM, on the other hand, we're explicitly making
obsolete.  The only reason why it's included at all is for
interoperability with existing deployed servers.  As soon as everyone
updates to NNTPv2 servers, it can be dropped completely.

>> In the following paragraph, surely "MUST discard" should be "SHOULD NOT
>> rely on", since the client can still make heuristic decisions.

> I'm not sure about this.  Based on Mark's comments from the MODE READER
> thread, I *think* that this is almost a requirement of TLS (whether
> implicitly or explicity, I don't know).

> Russ, guidance?

How about MUST NOT rely on?  I think we're just trying to find wording
here that doesn't get us into trouble.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

---

From: Russ Allbery <[email-masked]>
Date: Tue, 30 Nov 2004 19:46:01 -0800

Clive D W Feather <[email-masked]> writes:
> Ken Murchison said:

>> I don't *think* that server has to go back to the "unselected group"
>> state after auth, but my guess is that if the client authenticates in
>> the middle of a session its because they are trying to access a group
>> that returned a 480 and therefore will be changing groups immediately
>> after auth.

> Well, yes, but we can't guarantee it and so can't rely on it. There may
> also be other server state either now or in the future.

> I don't mind whether it's "server must forget all state", or "server
> must retain all NNTP state", but we need to be absolutely clear. Oh, and
> TLS needs to be consistent with SASL on this.

> [I'd prefer "retain state", because it may not be obvious to the main
> NNTP engine in the client whether a security layer was negotiated or not
> by some other module, and therefore whether the state was retained or
> not.]

I agree that we need to be very clear.

I would lean towards forgetting all state, since that's the obviously safe
thing to do from a security standpoint.  I can't figure out the parameters
of an attack that would exploit this, but I know that it can't be
exploited if we forget state.

However, there's MODE READER, and we can't forget that state,
unfortunately; Mark made that point, and it's accurate.  That state I can
argue doesn't pose any security issues, however, other than a DoS attack
(which is generally uninteresting).  I can't make a similar argument about
all server state.

It seems to be more in the general spirit of SASL and TLS to discard all
state after negotiating a security layer.

---

From: Russ Allbery <[email-masked]>
Date: Tue, 30 Nov 2004 19:48:23 -0800

Jeffrey M Vinocur <[email-masked]> writes:

> Y'know, there's a subtly here I can't quite wrap my head around.
> Everyone seems to like the "advertising AUTHINFO is enough to
> effectively eliminate the 480 response" idea, if I'm reading the list
> right.  But have we come to a conclusion that reactive authentication is
> bad?  I mean, what if the server advertises AUTHINFO because some users
> can authenticate, but most users won't need to.  Then the client
> software still has no way to know if it should prompt the user for
> authentication parameters or not.  So I guess we still need 480.

I think we still need 480.

It's not at all clear to me how useful it really will be going forward,
but this seems to be something we can let the marketplace decide.  If in
five years everyone is just authing on initial connection, we could look
at getting rid of it.

> I think it would be hard to do so as well.  But in the "current
> practice" realm, the client has no way of telling if the server supports
> AUTHINFO at all, and so it might appear as a "failure of unsolicited
> authentication" in that case.  If you think we don't need to document
> this, I certainly don't feel strongly about it...the existing text reads
> as it does really by accident.

Yeah, I wouldn't worry about this.  I think we can safely require the
server to accept AUTHINFO at any point until the client has authenticated.