Why not PLAIN?

It would be remiss not to mention that the simplest solution to this problem is to use the PLAIN SASL method in conjunction with SSL. Clients configured in this way will work with the new services just like they have previously, with similar security properties.

While it is not my goal to convince you PLAIN is insufficient, there is benefit in using a SASL method other than PLAIN in a defense-in-depth sort of way. Should the SSL stream become compromised in some manner, PLAIN would make obtaining a user’s password as easy as forcing a reconnect, while the other mechanisms provide additional layers of security.

Use SSL!

Regardless of the SASL method being used, if you’re bothering with any of this the first and most effective step to securing your IRC connection is using SSL. SSL is supported by virtually all IRC networks and requires only trivial configuration in most clients.

Be sure your client validates the server’s certificate properly (strict SSL) or your connection is trivially vulnerable to MITM [6] attacks.

Why SASL in addition to SSL

Common implementations give SASL users one benefit not generally available to other users: with SASL, network services recognize you before you even are active on the network, which can be useful when making use of services like a hostname cloak or automatically joining channels only open to invited accounts.

As an aside, as far as I can tell client-side certificates (like those used with CertFP [7] identification) could be used to provide similar benefits but this doesn’t seem to be done on any network I’m familiar with. One possible explanation is that since CertFP doesn’t work with Tor (I believe?), implementation efforts focus on SASL which is available to all users.

Other reasons include additional layers of security in terms of protecting the account password, and policies such as freenode’s requirement of SASL when connecting over Tor [8].

1) Install ecdsatool

First, download and build a copy of ecdsatool [9]. This wasn’t available as a package for my server’s distribution, so I built is as follows:

$ git clone https://github.com/atheme/ecdsatool.git
$ cd ecdsatool
$ ./autogen.sh
$ ./configure --prefix=$HOME/local
$ make -j
$ make install

Standard build recipe, tweak as you see fit.

Afterwards, be sure the resulting ecdsatool utility is available on your shell’s PATH so the irssi script we configure later will be able to find and use it.

2) Generate key pair

Next, use ecdsatool to generate a key pair for SASL use:

$ mkdir -p ~/.irssi/certs
$ ecdsatool keygen ~/.irssi/certs/freenode.pem

I keep my IRC-related certificates in ~/.irssi/certs, personal preference.

3) Install cap_sasl script

Next, grab a copy of the cap_sasl.pl script shipped in the ecdsatool repository:

$ mkdir -p ~/.irssi/scripts
$ wget https://raw.githubusercontent.com/atheme/ecdsatool/master/cap_sasl.pl -O ~/.irssi/scripts/cap_sasl.pl

Additionally you likely want to have the script loaded when irssi starts:

$ mkdir -p ~/.irssi/scripts/autorun
$ ln -s ../cap_sasl.pl ~/.irssi/scripts/autorun/

4) Configure SASL for freenode

From within irssi, use the /sasl set command to indicate what username and certificate to use for your IRC network:

$ irssi
...

/sasl set freenode username /full/path/to/freenode.pem ECDSA-NIST256P-CHALLENGE

Replacing freenode with the network name your configured in irssi, username with your freenode account name, and the path with a full path to the key pair generated earlier.

Afterwards, be sure to save this information for future use:

/sasl save

The result should be an entry in ~/.irssi/sasl.auth that looks something like this:

freenode dtzWill /home/will/.irssi/certs/freenode.pem ECDSA-NIST256P-CHALLENGE

5) Register Public Key with NickServ

Almost there! Final step is to give NickServ the public key portion of our key pair so it can recognize your client and associate it with your account.

First, grab the pubkey from the key pair:

$ ecdsatool pubkey ~/.irssi/certs/freenode.pem

Next, connect to freenode and identify yourself as you would usually.

Finally, tell NickServ about your public key:

/msg nickserv set property pubkey ArRZ4XCwSFYhT7RH5Ms7dosJEm8OYLO3gWSSGQCsYOCk

Replacing the example public key with what was printed by ecdsatool in the previous step.

6) Done! Reconnect and Test

At this point you have all the pieces required to use SASL with the ECDSA-NIST256P-CHALLENGE mechanism to connect to freenode. Disconnect from freenode and reconnect to try it out!

If successful, you should see something like this:

14:50 -!- Irssi: CLICAP: supported by server: account-notify extended-join identify-msg multi-prefix sasl
14:50 -!- Irssi: CLICAP: requesting: multi-prefix sasl
14:50 -!- Irssi: CLICAP: now enabled: multi-prefix sasl
14:50 -!- will!will@unaffiliated/dtzwill dtzWill You are now logged in as dtzWill.
14:50 -!- Irssi: SASL authentication successful

(Update: March 03, 2015)

Jesper Freesbug from the comments was kind enough to share his experiences and provide a walkthrough of the setup process when using this approach. I’ve featured this comment below and recommend taking a look if you’re interested in this solution.

In addition to the FreeBSD package he mentions, it seems other systems also provide the required perl module as part of a cryptx package. For example, on Arch it’s available as an AUR package named perl-cryptx. Hopefully the module is made more universally available in the future.