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

[Ken Murchison]

Clive D.W. Feather wrote:
> Russ Allbery said:
> 
>>>I just submitted the -04 revision of AUTHINFO which can be previewed
>>>here:
>>
>>>http://www.oceana.com/ftp/drafts/draft-ietf-nntpext-authinfo-04.txt
>>
>>Excellent!  Please, everyone, look this over and see if there are any
>>major issues left.  If no one objects, I will advance this to IETF Last
>>Call on Thursday or Friday.
> 
> 
> Not a major issue, but I don't think the last two paragraphs of 2.2
> correctly reflect the discussions we've had.
> 
> Since you can only ever do one successful AUTHINFO, the capability isn't
> available *at all* afterwards. Therefore the options are either:
> * don't show AUTHINFO, matching reality
> * show AUTHINFO, matching [SASL].
> Since we've already agreed on the latter, let's require the entire AUTHINFO
> capability to be the same as before authorisation - that way, if the
> information *is* of use in detecting attacks, it's there.

Actually, since this is a SASL-only issue I didn't feel that it made any 
sense to continue to list USER.  That being said, I won't argue strongly 
either way.  Opinions?


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


> 2.4.2 "When both TLS ..."; I said in a previous message that this could be
> re-read, and suggested other wording for it.

Sorry, I missed that.  I just found and read your previous comments on 
this.  I agree with your text which further clarifies the ordering of 
the TLS and SASL security layers and I've added it.  As for your other 
point, I'm going to take this to a separate post.


> 2.4.3 third and fourth examples: change "base64-encoded data is sent" to
> "base64-encoded data is actually sent".

Done.


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