[NNTP] Extension snapshots 2

Ken Murchison ken at oceana.com
Tue Jan 4 11:59:01 PST 2005


Russ Allbery wrote:

> Ken Murchison <ken at oceana.com> writes:
> 

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

OK, given that all we care about is the advertising of the capability, 
can we just rely on the base doc and remind people with my alternative text:

"The capability list returned in response to a CAPABILITIES command
received after authentication MAY be different that the list returned
before authentication.  For example an NNTP server may not want to
advertise support for a specific extension unless a client has been
authenticated.  Likewise, servers are not permitted to advertise the 
MODE_READER capability after authentication (see X.X of [NNTP])."


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

This works for me.  I might replace "reversed" with "reset" or "undone".

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp



More information about the ietf-nntp mailing list