[NNTP] Notes on auxiliary documents

Ken Murchison ken at oceana.com
Wed Dec 1 11:37:05 PST 2004


Russ Allbery wrote:

> Charles Lindsey <chl at clerew.man.ac.uk> writes:
> 
> 
>>Yes, but I explained why the usual SASL spirit might not apply to NNTP
>>in my message of Nov 18th.
> 
> 
>>Most SASL application are there to prevent the Bad Guy from stealing MY
>>resources (e.g. money from my bank account). But NNTP is different; SASL
>>is there for protecting the server's resources from being used by the
>>Bad Guy. Preserving state across authentication does no harm in that
>>scenario, whereas _not_ preserving state _does_ do harm in the case I
>>outlined, where I am suddenly asked to authenticate in the middle of
>>reading a group because I suddenly encountered an article cross-posted
>>to some other group with special restrictions on it.
> 
> 
> I'm afraid that I don't find this argument particularly convincing.  The
> point is to preserve the connection from outside tampering, and the reason
> for discarding all state is that any amount of tampering might have
> happened before the security layer was negotiated.
> 
> I'd be inclined to discard all server state except for the mode switch
> when a security layer is negotiated, but I'd love to hear other opinions.

The current STARTTLS and AUTHINFO drafts say the following:

"The server MUST discard any knowledge obtained from the client, such as 
the current newsgroup and article number, that was not obtained from the 
TLS/SASL negotiation itself.  Likewise, the client SHOULD discard and 
MUST NOT rely on any knowledge obtained from the server, such as the 
list of NNTP service extensions, which was not obtained from the 
TLS/SASL negotiation itself."

I don't see where having to reselect the group and article would create 
a great hardship for the client.

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