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

[Clive D.W. Feather]

Russ Allbery said:
>>>> 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.

I think we're interpreting words in slightly different ways. For AUTHINFO,
we can say in this document that the server MUST NOT send 480.

However, I can see nothing that forbids the server responding 480 to QUIT
or LIST EXTENSIONS. We need to change the base document to address that.

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

Oh. Okay.

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

Not if the server requires the password before checking, which is after all
considered Best Practice (so as not to allow people to determine valid user
names)!

[I'm now happy for it not to be pipelined, but I think there's an
inconsistency between "don't expose password unnecessarily" and "don't
verify user name until password received".]

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