[NNTP] draft-ietf-nntpext-authinfo-04

Ken Murchison ken at oceana.com
Wed Sep 29 12:19:45 PDT 2004


Russ Allbery wrote:

> Ken Murchison <ken at oceana.com> writes:
> 
>>Clive D.W. Feather wrote:
> 
> 
>>>So replace these two paragraphs with:
> 
> 
>>>    Note that a successful AUTHINFO command MAY cause the output of
>>>    the LIST EXTENSIONS command to change. However, the AUTHINFO
>>>    capability MUST continue to be listed with the same arguments as
>>>    immediately before the authentication, notwithstanding the fact
>>>    that no further AUTHINFO commands may be issued (this is a superset
>>>    of the recommendation in [SASL] and can help in detecting an active
>>>    down-negotiation attack).
> 
> 
>>>Possibly this can be merged with the previous paragraph ("After an
>>>AUTHINFO command ... 502 response.").
> 
> 
>>>[Note I've deleted the reference to 2.4.2; I can't see any need for it.]
> 
> 
>>Actually, I intended to remove the last paragraph entirely and
>>apparently didn't.  Would removing it be sufficient, or do you still
>>want to address this in some way?
> 
> 
> Removing it entirely would imply that LIST EXTENSIONS should not change
> following a successful AUTHINFO command, yes?

Ugh!  You're right, and I think that we *do* want to allow the 
extensions to change after auth.  I'll go ahead and add wording similar 
to Clive's, but I'll note that continuing to advertise AUTHINFO SASL: is 
only required id a security layer is in place.  Any thoughts on whether 
we should continue to advertise AUTHINFO USER in this case?  (For the 
record, I don't see the point).


>  That seems to fine to me; I
> don't have any trouble requiring that even extensions only usable while
> authenticated should be advertised in the unauthenticated state and just
> return the appropriate error code if used unauthenticated.
> 


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