ietf-nntp Multiple AUTHINFOs per session

[Jeffrey M. Vinocur]

On 6 Jan 2003, Andrew Gierth wrote:

> >>>>> "Jeffrey" == Jeffrey M Vinocur <jeff at litech.org> writes:
> 
>  Jeffrey> - If an AUTHINFO fails, the client should be able to retry
>  Jeffrey> (unless the server has chosen to close the connection).
>  Jeffrey> Agreed?
> 
> The usual case on failed authentication is to send the 502 response and
> close the connection.

This is certainly what INN does -- yet it is not required.


> There seems to be no obvious reason to allow clients to retry a failed
> authentication.

Well, most protocols do, don't they?  I can't actually think of one that 
doesn't, offhand.


> in many cases it's awkward to actually change the credentials
> associated with the session. 

I can imagine this in some implementations.


> I know that some servers will accept and
> ignore subsequent AUTHINFO commands once the user is authorised (either
> by IP or by previous AUTHINFO command).

Hum!

Accept and ignore.  Really?

How interesting.


> I've not heard of any client legitimately trying to do this.
>
> The usual (almost universal) assumption is that authentication is for
> a whole session, that it's done once either by the client at session
> startup or in response to the first 480 error.

And yet there are two issues that come to mind if we were to prohibit 
reauthenticating:

- For internal consistency, I think we would have to prohibt the 480
  response on already-authenticated connections.  Yes?  Then we could
  have the somewhat counterintuitive situation of a resource moving
  from 480 to 502 as a result of authentication.

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

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


-- 
Jeffrey M. Vinocur
jeff at litech.org