trusted local ident for authentication

[slingamn]

There are some ircds where all traffic eventually goes over the loopback adapter, for example, a shared shell host where the ircd only listens on 127.0.0.1:6667 and remote connections require an ssh tunnel.

In such a context, it would be interesting to run an identd that only listens on localhost, and then trust the replies from that identd to authenticate users.

This gets into similar issues as with #690 and #414 in terms of automatically creating accounts (or dealing with name conflicts, if a name was already registered through the native account creation system).

[slingamn]

Unix domain sockets make this possible even without ident; we should support both methods.

ssh lets you forward a local TCP port to a remote Unix domain socket.

[slingamn]

This is not of sufficiently general interest to schedule for 2.1.

[diodelass]

As you know, we use oragono as our local server on tilde.town. A few hours ago, someone used our server as a launchpad for an attack on tilde.team, and without identd, we had no way to identify who they were. While the specific event is of course out of scope for this venue (it didn't involve our ircd), it's troubling to note that we would not have been in any better position to deal with this if they had been directing their efforts locally. The takeaways from this are mainly that local deployments with relatively small, closed user communities are not immune to abuse and do need methods of ensuring user accountability.

I want to emphasize that I am certainly not trying to place any kind of blame on you or your project, either for the aforementioned incident or for our ongoing vulnerability to similar issues; these things are very much our own responsibility to address, and you've already been extremely helpful to us on that front. Nevertheless, I do want to go on-record here and challenge the assertion that this functionality is of insufficient general interest. I would venture to say that running a local identd (or a well-established and documented alternative) ought to be generally considered mandatory for ircd deployments where more than one user connects from local user accounts; the alternative is a near-total inability to hold local users accountable for their actions without radical changes to the way the underlying system operates.

[slingamn]

Thanks, that's interesting news.

The language of this issue is confusing; I intended "authenticate" to refer narrowly to the use of an identd to log people into ircd user accounts (i.e., the role normally played by SASL or /msg nickserv identify). We already have support for querying an identd and using the response to set the user/ident field of the NUH (i.e., the nick!user@host identifier). I believe this would provide most of the accountability you're looking for.

In terms of the larger IRC ecosystem, I'm trying to overturn some of the core design assumptions of IRC. In particular, IP cloaking, "always-on", and CHATHISTORY are intended to eliminate the need for shared shell hosts (instead, users should be able to connect directly to ircds from their endpoint machines with minimal friction).

In terms of private servers, I've been working on more flexible mechanisms to authenticate people, in particular auth-script, which lets Oragono talk to arbitrary external authentication systems. Hashbang is planning to set this up (they're going to generate a client certificate for everyone, store the fingerprint in their userdb, then use auth-script to verify it on connect). Hashbang isn't private (I think they intend to allow anonymous connections from the public Internet indefinitely), but a fully private server could then use sasl-required to restrict connections to people with an current record in their user database (and in such a context, force-nick-equals-account ensures that the nickname itself is trusted data). Even on Hashbang, a channel operator could institute this using the +R registered-only mode.