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

[Russ Allbery]

Clive D W Feather <clive at demon.net> writes:
> Russ Allbery said:

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

Hm.  RFC 2222 doesn't actually say that, so maybe I'm wrong.

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

You have a point there.  RFC 1734 doesn't require sending any sort of
capability command (it predates the CAPA command for POP), and reading
over RFC 3501, while there are some implications that most clients are
going to want to send the CAPABILITY command, I don't see any actual
requirement that a client do so before beginning AUTHENTICATE.

Ken?

It does make sense to me that a client that only has one authentication
mechanism that it considers to be of appropriate strength and is willing
to use has no real use of LIST EXTENSIONS prior to authentication (since
it must discard the output after authentication anyway).

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

I think you may be right.

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

I don't think it does require a change there.  You're just saying that the
client MUST be prepared to receive a 480 response in places where it
doesn't make sense, but we're separately saying that sending it doesn't
make any sense and the server MUST NOT send it.  There's no actual
conflict there, just some potentially unnecessary error case handling in
the client that you probably want to have for robustness of implementation
anyway.

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

MUST NOT is valid for security issues ("to limit behavior which has
potential for causing harm").  I don't think we should defer all security
issues to a separate section when we can put the restrictions about
certain commands all in the same place.

> Surely MUST NOT is the wrong wording. In particular, pipelining is safe
> if TLS is in place.

I think safe is overstating it.  You're still exposing the password to the
server; if the user entered the wrong username/password pair, refusing to
pipeline AUTHINFO will mean not exposing that invalid password to the
server.

I realize that this is all edge case stuff, but there's simply no good
reason to pipeline AUTHINFO and it's actually a potential security risk in
some circumstances.  One in general does not pipeline authentication even
in protocols that support pipelining explicitly; note that it's not
allowed to pipeline the AUTH command in SMTP.

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

Security issues frequently use MUST.

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

Sounds fine to me.

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

In the middle of the negotiation, empty data and no data are the same
thing, or rather, there's no way for SASL to return no data in the middle
of a negotiation (since SASL allows for an implementation that doesn't add
any status codes to the beginning of the data replies).

It's only potentially ambiguous at the end of the negotiation.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>