[ietf-nntp] Re: I-D ACTION:draft-ietf-nntpext-authinfo-00.txt
Peter Robinson
pmrobinson at gmx.net
Sun May 16 02:27:20 PDT 2004
Ken Murchison <ken at oceana.com> wrote:
> 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 the kind of thing I was wondering about.
> 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.
I agree. Either way, I think the text should be clarified to remove all
doubt.
> >>>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.
[re-ordered]
> 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).
Yes, it can certainly do that, though one could argue that this violates
the following SHOULD NOT:
| A client SHOULD NOT issue unrelated commands (e.g. HELP or
| commands related to reading articles) in the middle of AUTHINFO
| USER/PASS commands, however a server MAY handle such commands if
| it wishes.
> >>>This 'username only' authentication is interesting functionality. Is it
> >>>in use at all? [...]
> >
> > 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.
How about a note in the text explaining that bare AUTHINFO USER
sometimes initiates OOB authentication, and suggesting the use of SASL
instead.
> > I think the above is not a compelling reason to remove the
> > 281-without-password.
Agreed.
> > 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.
That's good.
Peter
More information about the ietf-nntp
mailing list