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

[Ken Murchison]

Jeffrey M. Vinocur wrote:

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

Hmm, I'm not sure that I like allowing a command that isn't advertised, 
even for backwards compatibility.  If the server is going to allow USER, 
then it should advertise it.

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

Yes, EXTERNAL is ideal for this.


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

Then perhaps the answer to Peter's question would be that the client can 
send QUIT if it gets an unexpected 381 to a USER command (which most 
likely means that the OOB authentication failed).

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