[ietf-nntp] I-D ACTION:draft-ietf-nntpext-authinfo-00.txt

[Clive D.W. Feather]

Russ Allbery said:
>> Section 2#8: as elsewhere, I object to the "SHOULD use LIST EXTENSIONS
>> first" concept. A client should always be able to "suck it and see",
>> testing the response code.

> On the other hand, I think the client MUST send LIST EXTENSIONS before
> doing AUTHINFO SASL.  After all, determining the list of SASL mechs is
> part of the protocol.

Is it?

Dynamic discovery of what mechanisms are available is one possibility. But
it's not the only one. I could decide, when setting up my client for use
with the server I use every day, that only DIGEST-MD5 is acceptable. If so,
I don't need to faff about seeing what's there: AUTHINFO SASL DIGEST-MD5
either works or fails. In fact, doing a LIST EXTENSIONS just wastes a round
trip, since I won't be using any mechanism *except* DIGEST-MD5.

So I think it's a MAY, not a SHOULD or MUST.

>> I would drop the bit about 480, which contradicts the base
>> document. Apart from QUIT, a server *can* give 480 to anything,
>> including HELP. At least, the client shouldn't fall over if it gets a
>> 480, and we've previously suggested 480-to-everything as meaning "you
>> need to log in".
> I think we need to forbid it for QUIT, AUTHINFO, and LIST EXTENSIONS for
> protocol reasons.

That requires a change to the base document. Um:

    The client MUST be prepared to receive any of these responses for any
    command (except, of course, that the server MUST NOT generate a 500
    response code for mandatory commands). 

becomes:

    The client MUST be prepared to receive any of these responses for any
    command, except:
    - the server MUST NOT generate a 500 response code to those commands
      that are mandatory;
    - the server MUST generate either a 205 or 501 response code to the
      QUIT command;
    - the server MUST NOT generate the "not authorised" (401, 480, 483,
      and 502) response codes to the LIST EXTENSIONS command.

    In addition, an extension MAY also forbid a server from generating
    the following responses to some or all of the additional commands it
    defines:
    - the 401 response when naming that extension;
    - the 480 response, if the extension is an authentication extension;
    - the 483 response, if the extension is a privacy extension;
    - the 502 response.

[A bit wordy, I'm afraid.]

>> Section 2.1: there's no reason to forbid pipelining.
> I disagree.  We forbid pipelining because the client MUST NOT send the
> user's password if the server returns 502 in response to AUTHINFO USER.

That's a Security Consideration, not an interoperability one. Surely MUST
NOT is the wrong wording. In particular, pipelining is safe if TLS is in
place.

>> The server MUST NOT close the connection after a 502. If it wants to
>> close the connection, 400 is the correct response.
> I don't think we can get away with that here.
> 
> INN has been returning 502 in this situation since the beginning of time,
> and has never returned 400 here (or, for that matter, anywhere other than
> as the initial greeting).  If we switch suddenly to 400 from 502 here, I'm
> afraid that we're going to cause interoperability problems (in particular,
> clients popping up their generic "unknown response from server" errors
> rather than the tailored "bad password" ones).
> 
> The server can close the connection at any time anyway.

This disagrees with the text we agreed in the base document. I'm very
unhappy about revisiting it at this late date.

>> Surely the MUST NOT in #3 should be SHOULD NOT?
> I think we can get away with saying MUST NOT here; more and more clients
> support nntps, and I think it will make the IETF quite a bit happier.
> This is a pretty big change to what's expected of clients, since we're
> trying to solve the clear-text problem.

Again, it's a best practice matter rather than an interoperability, so
surely MUST is the wrong word?

>> I'm not clear that there's a benefit to requiring UTF-8.
> We said that everything else is UTF-8, and it's consistent.  And treating
> it as opaque data doesn't necessarily work either, depending on the input
> mechanisms available to the user.

In fact, the present syntax requires UTF-8 for all extension commands, and
the text requires it for all commands. So the solution is to change this
paragraph from:

    Usernames and passwords use the UTF-8 [UTF-8] character set.
    Servers SHOULD validate that correct UTF-8 syntax is used.  (An
    option to disable this facility is appropriate to support legacy
    authentication databases).  Clients which permit non-US-ASCII input
    MUST convert any localized character set to UTF-8 by default.

to:

    Usernames and passwords MUST use the UTF-8 [UTF-8] character set,
    and clients MUST convert any user input to UTF-8 if necessary.
 
>> #6 is just conceptually wrong, since it will look to a generic parser
>> like no arguments (our generic syntax allows trailing junk). Rather, use
>> "*" for this case.
> Using "=" for this case would be better.  Isn't that okay in SASL?

Doesn't that mean "empty data"? Cf:

>> Rather than two separate responses (281 and 283), wouldn't it be better
>> if the final success response had a "=" argument if there's no data
>> returned?
> I think that means something different, doesn't it?

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