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

[Ken Murchison]

Peter Robinson wrote:

Editorial nits committed to the source, thanks.

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


> 
>>     The server may list the AUTHINFO capability with no arguments,
>>     which indicates that it complies with this draft and does not per-
>>     mit any authentication commands in its current state.  In this
>>     case, the client MUST NOT attempt to utilize any AUTHINFO commands,
>>     [...]
> 
> 
> So a client can sometimes tell that authentication is definitely
> inappropriate.  That's a welcome improvement.

I'm not sure that "inappropriate" captures the full meaning.  If 
authentication has not yet been attempted or been successful, then an 
empty AUTHINFO capability means that AUTHINFO USER/PASS is not allowed 
in the current state (e.g. no security layer) or not at all and that 
AUTHINFO SASL isn't supported.

If authentication has already be successful, then the empty AUTHINFO 
capability means that the AUTHINFO command is no longer supported.  We 
leave the SASL capability so that the client may check for any changes 
in the mechanism list to detect a MIM attack.


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


> 
>>     A client MAY attempt the first step of authentication at any time
>>     during a session to acquire additional privileges without receiving
>>     a 480 response [...]
> 
> 
> This is a welcome improvement documenting widespread existing practise.
> 
> But how about
> 
> '...without first receiving a 480 response...'?
>             ^^^^^
> to emphasize to a first-time reader who doesn't understand 480 out of
> context that we're talking about the response to a previous command, not
> the response to a client's "first step of authentication".

Hmm, I see what you're driving at.  I'm not sure I'm happy with the 
existing text or your suggestion.  I'm open to further suggestions.


> 
>>     [...] (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.



>>     If a client attempts to reauthenticate, the server may permit the
> 
>                                                           MAY ?
> 
>>     attempt, or may return 502 response indicating that the new authen-
> 
>                    MAY ?
> 
>>     tication data is rejected by the server.
> 
> 
> 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?


>>     Should the server request a password using the 381
>>     response, the client will send AUTHINFO PASS followed by a password
>>     [...]
> 
> 
> What should the client do if it was expecting 281 after AUTHINFO USER?
> AUTHINFO PASS *?  '*' ought not to be anyone's password and that would
> be inline with SASL further down.
> 
> This 'username only' authentication is interesting functionality.  Is it
> in use at all?  In principle it's just as secure as AUTHINFO USER+PASS
> if combined with encryption, but if the client thinks of the AUTHINFO
> USER parameter as a username rather than a password, it might store it
> in logs in the clear and echo it on screen etc. which would be bad.
> This functionality does complicate things a little.  Can it be dropped?

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

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp