ietf-nntp Multiple AUTHINFOs per session

[Ken Murchison]

Russ Allbery wrote:
> 
> 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).

OK.  Based on current deployment, there's probably no way to get around
having pre-authd connections.


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

Never mind.  It probably is not a good fit for NNTP.


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

Glad to hear it.  ;)


> > and the current discussion over on ietf-822.
> 
> That's the Usenet article format, which is a whole different ballgame

True.  But I detect some of the same reluctance to change inertia on
both lists (you and Jeff notwithstanding).


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

Exactly!  I tried to make this point in some of my early SASL posts and
was slapped back by the "its not NNTP-like" responses.  At least I know
that you and Jeff were listening and tend to agree.  ;)


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