ietf-nntp Multiple AUTHINFOs per session

[Russ Allbery]

To summarize my opinion on the previous discussion, I think that we should
either simply prohibit multiple authentication or state that it may not be
supported, with an inclination towards the former.  I think that's
consistent with those servers that currently just ignore all subsequent
AUTHINFO commands while maintaining the same authentication identity.

There seemed to be a few people in news.software.nntp whose software
supported changing the authenticated identity, but no one who seemed
particularly excited about it, and there were some people in
news.software.nntp who thought that it shouldn't be allowed.

I think we're best off prohibiting it in the draft and then seeing if
anyone screams.  We can always change it later; we're just discussing the
draft, after all, not a final RFC (which is still some distance off).

Jeffrey M Vinocur <jeff at litech.org> writes:

> - For internal consistency, I think we would have to prohibt the 480
>   response on already-authenticated connections.  Yes?

Yes.

>   Then we could have the somewhat counterintuitive situation of a
>   resource moving from 480 to 502 as a result of authentication.

I don't think that's counter-intuitive.  I'm pretty comfortable with
that.  480 means "you may be able to access this resource after
authentication" and therefore is not a reasonable return code once
authentication has already occurred.

> - To code on the assumption you mention above requires a somewhat
>   artificial distinction between credentials derived via AUTHINFO
>   and those from other methods (e.g. ident lookups), since after
>   the latter we still permit AUTHINFO, but after the former we
>   would not.

This is true.  That's one thing that's somewhat strange about NNTP, namely
that some sites using NNTP make more use of out-of-band authentication
than is normally seen in other protocols.

> Neither of these strikes me as critical; if there is some consensus here
> I'm certainly willing to prohibit repeated authentication steps.

Does anyone actively object to simply prohibiting reauthentication after a
successful authentication?

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>