[ietf-nntp] Re: I-D ACTION:draft-ietf-nntpext-authinfo-00.txt
Ken Murchison
ken at oceana.com
Tue May 11 04:32:01 PDT 2004
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
More information about the ietf-nntp
mailing list