add sasl authentication

[zabbal]

Emacs have built-in sasl library and freenode supports sasl authentication (mandates it in some cases in fact). It would be great to use those features. Especially considering that it might save user from dealing with nickserv authentication for example.

[jorgenschaefer]

Do you have more info on that for freenode? Thanks!

[zabbal]

https://freenode.net/sasl/

[zabbal]

Note: for Tor and some ISP with many clients behind single NAT ip this authentication is mandatory. For those lucky enough to get real ip it's an option to improve security and get extra features like #80.

[zabbal]

Another addition would be https://freenode.net/certfp/ but that's less common amongst other irc clients.

[jorgenschaefer]

As far as I understood, this requires two semi-related protocol extensions.

1) Use the CAP extension to figure out if the server supports SASL.

First, use CAP LS to see if the server supports sasl at all. Then use CAP REQ sasl to require that extension.

> CAP LS
< :weber.freenode.net CAP * LS :account-notify extended-join identify-msg multi-prefix sasl
> CAP REQ sasl
< :weber.freenode.net CAP * ACK :sasl 
> CAP END

The server does not respond to CAP END at all.

2) Use the SASL authentication extension to authenticate with freenode.

The client needs to send an AUTHENTICATE command to establish which SASL mechanism to use. The server will respond with a 904 numeric if it does not support that mechanism. The client can try again, until the server responds with AUTHENTICATE + (note the lack of a prefix). Currently, Freenode seems to support only PLAIN (which means we should never use SASL outside of TLS).

> AUTHENTICATE CRAM-MD5
< :morgan.freenode.net 904 * :SASL authentication failed
> AUTHENTICATE PLAIN
< AUTHENTICATE +

The client then sends another AUTHENTICATE command with the SASL secret.

The AUTHENTICATE command should be issued before CAP END. Apparently, also the initial NICK and USER commands should be sent before CAP END, as CAP END terminates the initial authentication.

A full protocol excerpt (from the second link):

C: CAP LS
C: NICK jilles
C: USER jilles cheetah.stack.nl 1 :Jilles Tjoelker
S: NOTICE AUTH :*** Processing connection to jaguar.test
S: NOTICE AUTH :*** Looking up your hostname...
S: NOTICE AUTH :*** Checking Ident
S: NOTICE AUTH :*** No Ident response
S: NOTICE AUTH :*** Found your hostname
S: :jaguar.test CAP * LS :multi-prefix sasl
C: CAP REQ :multi-prefix sasl
S: :jaguar.test CAP jilles ACK :multi-prefix sasl 
C: AUTHENTICATE PLAIN
S: AUTHENTICATE +
C: AUTHENTICATE amlsbGVzAGppbGxlcwBzZXNhbWU=
S: :jaguar.test 900 jilles jilles!jilles@localhost.stack.nl jilles :You are now logged in as jilles.
S: :jaguar.test 903 jilles :SASL authentication successful
C: CAP END
S: :jaguar.test 001 jilles :Welcome to the jillestest Internet Relay Chat Network jilles

The secret is username\x00username\x00password.

I have no idea why this would be preferable over simply using the standard IRC password mechanism if all they support is PLAIN.

[jorgenschaefer]

There's an ERC plugin for SASL which only supports PLAIN and does not even use the built-in sasl library.

I could not get the built-in sasl library to work, either. The arguments to sasl-make-client are pretty much undocumented, and (let ((client (sasl-make-client "PLAIN" "foo" "irc" "irc.freenode.net"))) (sasl-next-step client nil)) throws an error. So I guess implementing our own SASL is the way to go, too.

(Security, yay …)

[zabbal]

Filing bugreport about disfunctional built-in sasl in emacs might be a viable option too: this would help to decrease code duplication provided erc would switch to using it as well.

[zabbal]

SASL might be preferable over irc password because:

• other irc networks might support digest in addition or instead of plain
• it helps to remove lag for cloak application

[jorgenschaefer]

it helps to remove lag for cloak application

I am not sure about that at all. Have you actually tried that? (I'm not talking about nickserv authentication, but IRC authentication; that prevents other types of lagged information, too.)

[zabbal]

I've tried nickserv auth - lag is there. I've tried sasl auth - no lag.

[jorgenschaefer]

I've tried nickserv auth - lag is there. I've tried sasl auth - no lag.

Yes. Have you tried IRC auth?

In Circe, you can do this by using a circe-network-options setting for Freenode like this:

("Freenode"
  :host "irc.freenode.net" :port 6697 :tls t
  :nick "forcer"
  :pass "topsecretpassword")

Note that this uses :pass, not :nickserv-password.

[jorgenschaefer]

legoscia kindly pointed me to emacs-jabber's sasl implementation, which details the use of Emacs' sasl library.

[zabbal]

Using irc auth proposed above is not a valid workaround: it's just another way to supply your password to nickserv so the lag is still there. It might get smaller so it might work for some particular cases (depending on network latencies and number of channels to join) but the race condition is still there. Besides sasl is the recommended way foe authentication anyway regardless if you're using cloak or not. See http://freenode.net/faq.shtml#nicksetup for details.

[jorgenschaefer]

Apparently, freenode removed the blowfish method, still allowing for PLAIN, but recommending ECSD. They provide a command line tool to do this signing:

https://github.com/atheme/ecdsatool

Yay …

[wasamasa]

@Earnestly pointed me to an useful Gist that explains the protocol details in a bit more detail.

[jorgenschaefer]

Small update here: The new irc.el code actually supports SASL authentication, but the current bridging code does not support passing the relevant options yet. This should be a feature of Circe 1.7, though.