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

[Clive D.W. Feather]

Russ Allbery said:
>> Authenticated state: it's now a bit more complicated. Some servers will
>> only allow you to authenticate once and then you've stuck with it. These
>> would give response [D]. But others might allow you to change your
>> authentication. These then need to decide what to do if the *second* one
>> fails - do they forget the first or do they retain it?
>
> If a server is going to support reauthentication, I think we should
> require that they remember the previous authentication until a new
> authentication is successful.  Otherwise, there are just too many
> headaches, and this way it's easier to explain.

I'm very happy with this approach, and it simplifies the problem somewhat -
the same response can mean "first authentication failed, you're not
authenticated" and "second authentication failed, the first set of
credentials still work".

>> If we want to forbid PASS before USER, then that's fine with
>> me. However, if so then we need a clear response code for this case (I
>> don't think 381 is right)
> What's wrong with 482?  That's what's always been used for this.

Nothing, I think.

>> and it means we are explicitly forbidding PASS-only authentication
>> (where, for example, the user name is deduced from the connecting IP
>> address).
> Right.  I don't have a problem with that, although it does outlaw INN's
> current hack.

Is this the "always return 381 to USER" hack? That would be fine, I think.

Try this wording, based on forbidding PASS-only:

    The AUTHINFO USER and AUTHINFO PASS commands are used to present
    clear text credentials to the server. These credentials consist of
    a username or a username plus a password [1]. The username is
    supplied through the AUTHINFO USER command and the password through
    the AUTHINFO PASS command.

    If the server requires only a username, it MUST NOT give a 381 response
    to AUTHINFO USER and MUST give a 482 response to AUTHINFO PASS.

    If the server requires both username and password, the former MUST
    be sent before the latter. The server will need to cache the username
    until the password is received; it MAY require the password to be
    sent in the immediately next command (in other words, only caching
    the username until the next command is sent). The server:
    - MUST give a 381 response to AUTHINFO USER;
    - MUST give a 482 response to AUTHINFO PASS if there is no cached
      username;
    - MUST use the argument of the most recent AUTHINFO USER for
      authentication;
    - MUST NOT give a 381 response to AUTHINFO PASS [2].

    The server MAY determine whether or not a password is needed based on
    the username. Thus the same server can respond with both 381 and other
    response codes to AUTHINFO USER. See also Security Considerations [3].

[1] At this point you could restore my additional text:

    (the distinction is that a password is expected to be kept secret
    while a username is not; this does not directly affect the protocol
    but may have an impact on user interfaces)

[2] Thus 381 is never a valid response to AUTHINFO PASS; this fact could
instead be indicated in the Usage section.

[3] There may be a Security Consideration in not rejecting unknown users.
But if no password is required for user X, it's not unreasonable to skip
AUTHINFO PASS.

>>>> The server MUST NOT close the connection after a 502. If it wants to
>>>> close the connection, 400 is the correct response.

> 400 in any circumstances other than as an initial greeting has very little
> implementation out in the real world that I've seen.  I'll bet that pretty
> much everyone uses 502 here.

Nevertheless, this is one of the things we cleaned up in the base document.
Let's not break it now (particularly since to do so will require going back
and changing the base document).

>> Yes we do - [NNTP-BASE] 3.1:
> 
>>     The first or only line of the response MUST NOT exceed 512 octets,
>>     which includes the response code and the terminating CRLF pair; an
>>     extension MAY specify a greater maximum for commands that it
>>     defines, but not for any other command.
> 
> So we need to deal with this by explicitly waiving it or increasing it
> somehow.

The AUTHINFO extension could require this maximum to be extended for
clients calling the AUTHINFO SASL command, yes. That would need to be made
explicit.

>>     After a security layer is established, the server MUST still adver-
>>     tise the SASL capability (with the same arguments as previously),
>>     MUST still advertise the AUTHINFO capability (perhaps with zero
>>     arguments), SHOULD NOT advertise SASL as an argument to the
>>     AUTHINFO capability, and SHOULD NOT advertise the STARTTLS [NNTP-
>>     TLS] capability.
> 
>> Firstly, this is talking about security layers (encryption, right?), not
>> authentication. Why should you not advertise SASL but yet advertise what
>> SASL offers?
> 
> Because you can detect a MIM attack that resulted in degraded security if
> you look at the supported SASL mechanisms after the security layer was
> negotiated and it differs from what was available before.

So why shouldn't you advertise SASL?

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