ietf-nntp Multiple AUTHINFOs per session

Ken Murchison ken at oceana.com
Sun Jan 5 19:11:19 PST 2003


"Jeffrey M. Vinocur" wrote:
> 
> 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.

How would this be used?  And couldn't this been done by creating a new
session?


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

Deriving authentication credentials from some out of band channel (TLS,
IPsec, ident) is fine, but shouldn't teh client still be required to
authenticate via AUTHINFO SASL EXTERNAL in order to use these
credentials?  This eliminates any ambiguity.  Based on my experience
with SMTP/LMTP and IMAP, if a client doesn't explicity authenticate,
then its treated as "anonymous".

Of course NNTP seems to be highly allergic to conforming to what has
already been done by other protocols.  ;)
-- 
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