ietf-nntp Multiple AUTHINFOs per session

Russ Allbery rra at stanford.edu
Sun Jan 5 20:13:40 PST 2003


Ken Murchison <ken at oceana.com> writes:

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

That defeats the whole point of using out of band channels in some cases,
since the goal is single sign-on and seamless authentication.  For
example, at Stanford we use a modified ident responder that establishes
Kerberos credentials; that exchange happens automatically at the beginning
of a connection from an off-campus IP address, and if it succeeds the
client identity is established.

I don't see what purpose is served in forcing clients to send a command to
establish authentication when their authentication is already established
on connect.  Bear in mind that the common case for NNTP is still to
authenticate by IP address.

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

I'm not sure that concept makes a lot of sense on Usenet.  Other than
fully public servers for particular hierarchies (which isn't the common
case, although it's growing), there really isn't a notion of anonymous
users to NNTP servers, but similarly there tends not to be a lot of worry
at *most* sites about establishing a specific identity.  Instead, some
precaution is taken to ensure that the user is within a large group of
authorized users and then it's left at that.

(This *isn't* true for commercial NSPs as much; they more frequently want
an actual identity.  I'm thinking about the typical organizational NNTP
server, or the NNTP server someone runs on their own system.)

> Of course NNTP seems to be highly allergic to conforming to what has
> already been done by other protocols.  ;)

Hm.  I'm not sure I agree, and I'm not sure what you're thinking about.

But in this case, there's a very good reason for why NNTP is different.
It's not protecting per-user data, and it's normally not protecting
anything very valuable.  Certainly, for private internal hierarchies you
want to clearly establish authentication, but for public hierarchies the
only real purpose of authentication is to prevent abuse of server
resources and to avoid being vulnerable to spam, not to actually try to
protect the data to any huge degree.  So a very weak form of
authentication like IP-based access controls is sufficient since it's
highly unlikely someone's going to bother trying to spoof IP addresses
just to post spam.

That doesn't apply necessarily to the concerns of applying SASL to NNTP;
I'm just pointing out that while having SASL in NNTP is useful when you
need authentication, lots and *lots* of servers are not and never will
ever bother with it because they don't need that sort of authentication,
and requiring that users send SASL commands anyway seems like a waste.

Maybe I'm misunderstanding.

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



More information about the ietf-nntp mailing list