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

[Clive D.W. Feather]

Ken Murchison said:
>> 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)."

I remain confused.

Firstly, why won't an active attacker just present the old list anyway?
It's no skin off his nose to do it.

<later>
After much reading, I'm beginning to understand some of it (but still not
the Man in the Middle bit). But I think the draft needs to explain it all
much better.

After a successful AUTHINFO SASL, the client MUST NOT issue another
AUTHINFO command and, if it does, the server MUST respond with a 502.
Therefore the contents of the LIST EXTENSIONS response AUTHINFO line is
largely academic; its only use is as information to the client as to what
*was* available. This doesn't just apply to SASL, it applies to all
authorisation mechanisms.

Okay, here's what I suggest. Replace the last three paragraphs of section 2
("After an AUTHINFO command ... section 2.2.2.") with:

     A server MUST NOT under any circumstances reply to an AUTHINFO
     command with a 480 response.

     After an AUTHINFO command has been successfully completed, no more
     AUTHINFO commands may be issued in the same session and a server
     server MUST reject any further AUTHINFO commands with a 502 response.
     For this reason, once authentication has happened the AUTHINFO line
     in the results of LIST EXTENSIONS is effectively irrelevant. In order
     to allow the client to determine what options were available, the
     server MUST return the same arguments in this line as it would have
     done immediately before the successful authentication.

Possibly add an example, or extend the first example of 2.2.3.

The text in question in 2.2.2 ("After a security layer ...") can then be
removed as unneeded.

Question to the group: would it be worth adding a flag to show that
authentication is no longer possible? Something like:

    AUTHINFO - USER SASL:EXTERNAL

?

> Note that this is also addressed in Section 6.

Where?

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

Okay, that makes sense, but again the document doesn't explain it well
(I'm sure I won't be the last person to get confused). I would suggest
dropping the "and SHOULD NOT ..." text and modifying the next paragraph
instead.

     When both TLS [NNTP-TLS] and SASL security layers are in effect,
     the TLS encoding MUST be applied after the SASL encoding. For this
     reason (maintaining the correct layering), when an SASL security
     layer is in effect then the client MUST reject the STARTTLS command
     (with the 502 response code) and MUST NOT advertise the STARTTLS
     capability in the results of LIST EXTENSIONS.

Um, I've just realized that the first sentence isn't that clear either; I
presume you mean that the TLS stream is encoding the results of the SASL
encoding, but it could be read as that SASL must be activated first (that's
how I read it the first time). Can I suggest:

     When both TLS [NNTP-TLS] and SASL security layers are in effect,
     the TLS encoding MUST be applied to the results of the SASL encoding
     of the plaintext messages, not the other way round.

-- 
Clive D.W. Feather  | Work:  <clive at demon.net>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <clive at davros.org>  | Fax:    +44 870 051 9937
Demon Internet      | WWW: http://www.davros.org | Mobile: +44 7973 377646
Thus plc            |                            |