[NNTP] Extension snapshots 2

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


Russ Allbery wrote:

> Yeah, that would work.  I don't know if there's merit in just restating
> the point briefly in a sentence or two, just to make sure that
> implementors don't miss it by not reading the generic section of the base
> document.

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


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


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.  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.  Likewise, the client
SHOULD discard and MUST NOT rely on any knowledge obtained from the
server, such as the capability list, that was not obtained from the
SASL negotiation itself.  (Note that a client MAY compare the
advertised SASL mechanisms before and after authentication in order to
detect an active down-negotiation attack.)"


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