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

[Peter Robinson]

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