[NNTP] Comments on draft-...-authinfo-03

[Ken Murchison]

Clive D.W. Feather wrote:
> Mostly nitpicks:

Thanks for the feedback.


> I suggest that the text at the start of section 2 be called section 2.1.
> Title perhaps "General concepts".

Where exactly are you suggesting a split?  Are you saying that 
everything before the current 2.1 should be 2.1 and there would be no 
text directly under 2.?


> Page 4, "The server may list ...". Is the server required to reject any
> AUTHINFO command that is then received? The purpose of this paragraph isn't
> clear to me.

I believe the purpose is to prevent clients which are capable of 
AUTHINFO USER from attempting to use it if the server explicitly states 
that its not available.


> Page 4 last para: a 480 indicates that the client must authorise, and
> AUTHINFO is a way to do this, but it doesn't mean that AUTHINFO MUST be
> used.

I changed this to read:

"When an NNTP server responds to a client command with a 480 response,
this indicates the client MUST authenticate and/or authorize in order
to use that command or access the indicated resource.  Use of the
AUTHINFO command as described below is one such way that a client can
authenticate/authorize to the server."


> Page 7 para 2: s/compliant/conforming/ perhaps?

Done.



> Page 7 para 3: s/and client/and a client/

Done



> Section 2.2.2 first para: I'm not sure if this belongs here. Why forbid a
> server from offering GENERIC as well, since there's no clash of names?
> If GENERIC in [NNTP-COMMON] is deprecated, we just end up with no
> definition of it at all; how does that help?
> 
> Perhaps a better approach is to replace the paragraph with:
> 
>     The use of AUTHINFO GENERIC [NNTP-COMMON] is deprecated in favour
>     of AUTHINFO SASL. A server SHOULD NOT report AUTHINFO GENERIC
>     in the list returned by LIST EXTENSIONS.

This replacement text look fine to me.  I'm curious what other opinions are.


> I still think it belongs somewhere else, such as the general part of 2 (the
> bit I think should be 2.1).

We already state that its deprecated in Section 1, so maybe restating it 
here *is* redundant.  I'm not sure if we need to state that GENERIC 
SHOULD NOT be in LIST EXTENSIONS.


> Section 2.2.2 para 4: delete the stuff after ("="). Or replace the entire
> sentence with:
> 
>     A server challenge that has zero length MUST be sent as a single
>     equals sign ("=") and not omitted.

What is the problem with the existing text?  The only reason we are 
requiring "=" at all in this case *is* to distinguish any empty 
challenge from any trailing junk.  All of the other messaging protocols 
simply allow an empty string (no "=") because they don't allow trailing 
junk.


> Page 9 last (part) para: calling the argument a "response" when it's the
> very first thing in the exchange sounds odd. Perhaps rather than
> "challenge" and "response" this text should just talk about "data" or
> "words" or "negotiations".

Its called an initial response both in [SASL] and the IMAP, POP3 and 
SMTP SASL profile documents.  I'd like to stay consistent.


> Page 10 first (part) para: I don't think "defined to be the same as" is
> right; perhaps:
> 
>     In NNTP, an empty server challenge and one of zero length are the
>     same thing, encoded as a single equals sign.

How about this:

"In NNTP, a server challenge that contains no data is
equivalent to a zero length challenge and is encoded as a single
equals sign ("=")."


> 2.2.2 para "After a security layer ...": why must the SASL mechanism list
> be the same? Why can't new ones be added? 

This is to help detect man in the middle attacks.  Its possible for an 
active attacker to change the list of mechanisms that the client is 
presented.  When a security layer is negotiated (assuming its not 
incredibly weak), the client can compare the lists before and after SASL 
to see if they changed.  If the server unilaterally changed the list, 
then the client may think the connection is compromised.  I've change 
the paragraph to the following:

"After a security layer is established, the server MUST continue to
advertise the AUTHINFO capability and "SASL:" argument (with the same
mechanism list as before authentication) to help detect active
attacks.  In addition the server SHOULD NOT advertise the STARTTLS
[NNTP-TLS] capability (as STARTTLS is not allowed after
authentication)."


Note that this is also addressed in Section 6.


> Why is STARTTLS forbidden?

Because of the nesting of encryption layers.  The document (as well as 
IMAP, POP3, and SMTP) all require TLS before any SASL security layer. 
That being said, if the client has already negotiated encryption via a 
SASL mech, why would it then proceed to initiate TLS?


> 3.5: I would remove the comment, since it just duplicates the syntax.

Done.


> 5 para 2: s/posted articles, or by/posted articles or by/

Done.


> 8.2 [UTF-8]: s/Novermber/November/

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