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

[Jeffrey M. Vinocur]

On Mon, 10 May 2004, Ken Murchison wrote:

> Peter Robinson wrote:
> 
> >>     [...] 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.

That's the behavior expected of a client compliant with this draft.

One can imagine a situation where the admin wants his server to advertise
AUTHINFO SASL for "updated" clients, carefully doesn't advertise AUTHINFO
USER as directed above, but still wants the server to accept plaintext
authentication from legacy clients.  That's sort of the situation you 
describe, although it would also fall under the "backward compatibility" 
clause.
 

> >>     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.  [...]
>
> Correct, do you have better wording that you can suggest?

Perhaps we actually need this clarified in the base draft if it's not too 
late; since we're not per se introducing 480 here I'm not sure how much we 
can officially legislate its use.


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

Perhaps "...without having received a 480 response" is subtly better?


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

Especially given that it's quite common for clients to support a "send 
password always" configuration option as is.  On the other hand, I don't 
think any harm is done by clarifying, and it may be of note for some 
client author.


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

(I continue not to have a strong feeling here, so I'll defer.)


> > What should the client do if it was expecting 281 after AUTHINFO USER?
> > AUTHINFO PASS *?  [...and it receives a 381] '*' 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.

I have seen this behavior used in existing practice.  In particular, if
there's an out-of-band authentication mechanism (e.g. one like "identd" or
certain kerberos implementations where the server queries back via a new
TCP connection to the original host), the client sends AUTHINFO USER in 
order to suggest to the server which username it expects.  Certainly this 
behavior is now better done with SASL, but that's true of all of AUTHINFO 
USER; thus I think the above is not a compelling reason to remove the 
281-without-password.

I don't think there was any intent that this be used as a single-step 
authentication process where the "username" is a secure token, and I've 
never heard of anyone using it that way.


-- 
Jeffrey M. Vinocur
jeff at litech.org