ietf-nntp Multiple AUTHINFOs per session

[Russ Allbery]

Ken Murchison <ken at oceana.com> writes:
> Russ Allbery wrote:

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

> Hmm.  Once again I guess I'm not completely up to speed on NNTP
> deployment.  So, when using the IP, are you just auth'ing the host?

Right.

To give an example, Stanford's news servers first check to see if the
client connection is from one of the personal workstations of the system
administrators, and if so grants access to all groups.  If not, it checks
to see if the connection is from one of Stanford's networks, and if so it
grants access to all groups except for our internal gateways of role
addresses and control.cancel.  If both of those fail, it attempts to do an
S/Ident callback and uses the results of that callback to establish an
identity, granting access to all groups for administrators (so that we can
read them from home) and otherwise granting access to all groups except
the internal ones if the user successfully authenticates.

S/Ident is bolted on the side, and I'd of course rather replace that part
with something that does real SASL authentication in-band, since the
S/Ident callback mechanism doesn't work through firewalls or NAT.
However, the reason why we developed S/Ident in the first place is because
it can be added to arbitrary protocols without requiring client support,
and since we use Kerberos exclusively as an authentication mechanism, the
chances of the average news reader supporting our authentication mechanism
even via SASL is somewhat low.

We don't support AUTHINFO over unencrypted connections for obvious
reasons.  If the user connects via SSL, then they're required to
authenticate with their Kerberos username and password (at the moment
using AUTHINFO USER / AUTHINFO PASS).

> My understanding of the use of EXTERNAL, is that the client tells the
> server to go ahead and use whatever credentials it derived from the out
> of band facility, instead of the server automatically using
> them.

I'm not sure I understand the purpose served by this, rather than letting
the server default to using the permissions that it obtained from other
sources but allowing the client to override with AUTHINFO.

> If the client is able to override the automatic pre-auth by issuing
> AUTHINFO xxx, then I guess its just an matter of semantics.

Oh, certainly, I think that would be a requirement.

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

> Most specifically, the previous discussions of SASL syntax

Oh, that was just us trying to get up to speed on the best way of doing
this.  The SASL RFC doesn't make it at all clear what the recommended way
of handling the protocol exchange is.  I have no problem imitating SMTP,
now that I understand the issues better.

> and the current discussion over on ietf-822.

That's the Usenet article format, which is a whole different ballgame
entirely.  NNTP is quite a bit saner; it's a pretty straightforward
network protocol that has a few old warts, but for the most part isn't
that different than SMTP or POP3 (and is actually more regular than SMTP
in some ways).

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