incoming.conf length limits

[Russ Allbery]

Okay, here's how I would implement what you're doing at Cornell using a
current version of INN.  The hard part is CUSSP; everything else is pretty
straightforward.  The problem with CUSSP is that right now external
authenticators can't return a list of groups that someone is allowed to
read, only return an identity, so for a pure implementation with no code
changes, you'd have to duplicate the CUSSP information in readers.conf.

The basics look like this:

    auth outside-sidecar {
        hosts: *
        res: sidecar
        auth: auth_krb5
        default-domain: cornell.invalid
    }

    auth inside-sidecar {
        # Use either a host pattern or IP patterns or CIDR blocks.
        hosts: *.cornell.edu
        res: sidecar
        auth: auth_krb5
        default: <ANON>
        default-domain: cornell.invalid
    }

    access {
        users: "*@cornell.invalid,!<ANON>*"
        # Insert your standard set of newsgroups here.
        newsgroups: *
        nnrpdauthsender: true
    }

    access {
        users: <ANON>@cornell.invalid
        # Insert your standard set of newsgroups here for read.
        read: *
        post: !*
    }

This implements checking, on initial connection, whether Sidecar can
authenticate the user.  If not, the user can use NNTP authentication
later, using the auth_krb5 authenticator in CURRENT to check their
password against Kerberos.  You may want to require SSL in order for the
auth_krb5 authenticator to work (which would require duplicating those
auth blocks, removing auth: from the normal ones, and adding the flag to
require SSL to the ones that have auth:, IIRC).

User identities are assigned as "user at cornell.invalid" like you have now,
and setting nnrpdauthsender to true adds this to the headers on post.  The
default of <ANON> gets assigned to on-campus users who haven't
authenticated, an they're not allowed to post.  Off-campus users without
Sidecar won't be able to do much except authenticate.

What's missing is this part:

Todd Olson <tco2 at cornell.edu> writes:

>     d) when authentication occurs the id is checked
>        and certain id's are given access to additional groups
>        that are not normally accessible  (this feature is used
>        but not as widely as originally intended).  This is done
>        by checking against the 'permit server' (CUSSP protocol).

There are two ways that you could add this.  One would be to use the Perl
authenticators instead of the above and use a Perl interface to CUSSP (or
Python, if you want).  They can do the same logic as above, but you'd have
to write a bit of Perl code to do that.  That may actually be an easier
approach for you, since you have some interesting edge cases that you want
to deal with.  With the Perl or Python authentication hooks, you mostly
wouldn't use readers.conf and instead just handle this logic in Perl or
Python.

The other way to add this would be to hack nnrpd/perm.c to insert a call
to CUSSP after the readers.conf authentication finishes and replace the
newsgroup lists returned there with the results of CUSSP if relevant.  I
think this would be a fairly small patch; it's just a matter of finding
the right spot in nnrpd/perm.c.

>             (note: being able to transmit Kerberos via nntp
>                    would be neat, as it would eliminate the need for sidecar
>                    and thus NATs would stop being a problem
>             )

This is the stuff that Jeff's working on right now.  We're facing the same
problem, as I believe your Sidecar system is very similar to our S/Ident
system (see <http://www.eyrie.org/~eagle/software/sident/>).  I just added
support for authentication via AUTHINFO, but only over SSL, to our server.

Having SASL will be really nice, particularly if clients will start
supporting it.

>            (problems are that if sidecar is not reachable
>            (there is a noticable delay at the start of the connection
>            (as the sidecar attempt times out (15sec)

Yeah, you want to time out fast if you get an unreachable error, but
people behind firewalls that just drop packets do hit a delay.

>     2) Changed the CMDtable[] array in nnrpd.c so only
>        'post' and 'ihave' require authentication ( set TRUE)
>        no other commands require authentication (set FALSE)

This sort of modification shouldn't be required any more, since nnrpd now
separates the concepts of reader authentication and post authentication.

>     3) post.c is modified to set the Sender: to netid at cornell.invalid
>        This becomes the one thing the poster can not influence in
>        there posting, thus it is known who made the post

nnrpd now has native support for this.

>     4) commands.c is modified so that when an nntp auth command
>        is received
>             a) nnrpd first attempts to contact sidecar
>                if sidecar available succeed or fail based on it
>             b) if sidecar not available, then do nntp auth
>                and check against kerberos as a proxy
>                     (temporary tickets are left lying in /tmp
>                     (and have to be cleaned up with cron
>                     (... shows just how poor the hack is
>             c) in all cases that authentication succeeds
>                use permit server (really should be come the ldap server)
>                to see if there are any groups to add for this netid
>          note there is great controversy on whether to let nntp auth
>          override sidecar, or the other way round, so at the moment
>          if this is more than one auth, the connection is closed

The CUSSP isn't implemented by the readers.conf above, as mentioned.  Note
that auth_krb5 as comes with INN doesn't do what you describe; in other
words, it doesn't retry Sidecar before doing password authentication.  I'd
re-evaluate whether you need to do that; after all, you're doing Sidecar
right away, it's not clear to me why you'd want to try Sidecar again when
the client starts authenticating.

> Sadly there are many warts on this system.  The most obvious wart is
> that the only news reader we have at Cornell that successfully handles
> the 480 is MT-NewsWatcher (and related).  For the M$ windows crowd they
> just get an error message (and it is really awkward to get the details
> of the error message) and they have to figure out what to do.  Thus our
> support documentation instructs window's users to configure there reader
> to authenticate on initial connection.

This is interesting, and touches on another recent thread.  It sounds like
it may not a good idea to just start returning 480 responses to POST
because a lot of clients can't handle it.  (Although it may not be any
worse behavior than sending 440....)

> Interestingly MT-NewsWatcher claims to have a plugging to do Kerberos
> authentication, but I've not tested it because our server would not know
> what to do ...

I wonder what it would try to do.

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

    Please send questions to the list rather than mailing me directly.
     <http://www.eyrie.org/~eagle/faqs/questions.html> explains why.