[NNTP] Extension snapshots 2

[Russ Allbery]

Ken Murchison <ken at oceana.com> writes:

> OK, here's the current AUTHINFO passages w.r.t. MODE READER.  Comments? 
> I'll make similar changes to STARTTLS once we can agree on some text.

> Section 2.1 ("Advertising the AUTHINFO Extension")

> "A server MUST implement at least one of the AUTHINFO USER or AUTHINFO
> SASL commands in order to advertise the AUTHINFO capability in the
> response to the CAPABILITIES command.  However, this capability is not
> advertised after successful authentication (see section 2.2).  This
> capability MAY be advertised both before and after any use of MODE
> READER, with the same semantics."

I don't think this requires any changes.

> Section 2.2 ("Authenticating with the AUTHINFO Extension")

> "After a successful authentication, the client MUST NOT issue another
> AUTHINFO command or a MODE READER command in the same session.  A server
> MUST NOT return the AUTHINFO or MODE_READER capabilities in response to
> a CAPABILITIES command and a server MUST reject any subsequent AUTHINFO
> or MODE READER commands with a 502 response.  In agreement with [SASL],
> if a security layer is established as part of the authentication, the
> server MUST continue to advertise the SASL capability in response to a
> CAPABILITIES command with the same list of SASL mechanisms as before
> authentication (thereby enabling the client to detect a possible active
> down-negotiation attack)."

I would leave MODE READER out of the server MUST reject part, to leave the
door open for non-mode-switching servers that want to just always return
200 to MODE READER all the time.  I guess that's what you were driving at
with your original question.  I do agree that the MODE_READER capability
MUST NOT be advertised (since that invites clients to use it), and the
client language looks right to me.

> Section 2.4 ("AUTHINFO SASL Command")

> "When a security layer takes effect, the NNTP protocol is reset to the
> state immediately after the most recent MODE READER response (see 5.3 or
> [NNTP]) or initial greeting response (see 5.1 of [NNTP]) has been sent.

This sounds a little odd to me, since it sort of implies that MODE READER
creates a state "checkpoint" that you then revert back to.  It's partly
taken care of by the next sentence:

> The server MUST discard any knowledge obtained from the client, such as
> the current newsgroup and article number, that was not obtained from the
> SASL negotiation itself.

but it still leaves me feeling a bit uncomfortable.

I wonder if we can avoid that by being more explicit, saying something
like:

   When a security layer takes effect, the NNTP protocol is reset to the
   state immediately after the initial greeting response (see 5.1 of
   [NNTP]) has been sent, with the exception that if a MODE READER command
   has been issued, the effects of it (if any) are not reversed.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>