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

[Russ Allbery]

Ken Murchison <ken at oceana.com> writes:
> Peter Robinson wrote:

>>> 2. The AUTHINFO Extension

>>>     [...] The "USER" argument
>>>     MUST NOT be advertised unless a strong encryption layer (e.g. TLS
>>>     [NNTP-TLS]) is in use or backward compatibility dictates otherwise.

>> By saying "... MUST NOT be *advertised* ...", this could be read as
>> allowing a server to lie by omission in LIST EXTENSIONS (i.e. to
>> support AUTHINFO USER but not advertise it).  Is that the intent?

> No.  If the server doesn't advertise a plaintext mechanism, then a
> client SHOULD NOT attempt to use it and the server MUST NOT allow it.

I think adding "or provided" after "be advertised" would be good for
clarity there, since I don't think everyone will realize that.

>>>     An NNTP server MAY respond to any client command other than HELP,
>>>     LIST EXTENSIONS, AUTHINFO, or QUIT with a 480 response.

>> This doesn't explicitly say that the server can't respond with 480 for
>> those four commands, though I assume that's the intent.  Certainly
>> responding with 480 to AUTHINFO could cause a serious problem for a
>> badly written client, but doing so for the others would also be pretty
>> stupid.

> Correct, do you have better wording that you can suggest?

I think s/other than/except/ would make it sufficiently strong.  In a
standard English reading, MAY ... except ... implies that one can't do the
action in the circumstances specified in the exception.

>>>     [...] (this is a change to the previous specification in
>>>     [NNTP-COMMON]).

>> Is it necessary to include this remark?  "[NNTP-COMMON]" wasn't exactly
>> clear on this point, and many client and servers already do this
>> perfectly happily.  In any case any client author reading this spec
>> will be prepared for it to fail.

> I'll let other more "hard-core" NNTP folks comment on whether this is
> necessary.

I would omit that.  In practice, everyone supports sending authentication
information right away.

>> Is the server allowed to close the connection immediately in this case?
>> AIUI 502 in this context has its generic meaning of 'not possible on
>> this connection, may be possible on a new connection' and not
>> 'permission denied, go away' as it usually means in this document.
>> This draft's wording only hints that getting a 502 after trying to
>> *re*authenticate might mean that the client should try again.  You
>> could add "The client MAY then attempt to reauthenticate on a new
>> connection."  or words to that effect.

> Yeah, I'm still not in favor of allowing reauthentication at all, so I'd
> prefer that this just be "invalid command".  Can those that are in favor
> of reauthentication suggest what a server which doesn't support it
> return when a client attempts it?

It should return the same thing that a server should return when it
advertises AUTHINFO without any parameters in LIST EXTENSIONS, indicating
no authentication commands are available.  It's the same situation.

> I agree.  This is crufty behavior and if there isn't a compelling reason
> for it, we should remove it.

INN doesn't support user-only authentication; there's never been a request
for it that I can recall.  I vote for removing it.

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