Built-in SASL authentication (IRCv3.1)

[dequis]

SASL based authentication is a required extension for IRCv3 compliance (CAP and multi-prefix are required too). This approach solves many of the caveats of methods like "nickserv", and is required in some cases, such as connecting to freenode through tor.

This is currently implemented with third party scripts. I believe it should be a built-in feature (or at the very least, include the script with the default distribution)

Description of the current script based approach: https://freenode.net/sasl/sasl-irssi.shtml

The script itself: https://freenode.net/sasl/cap_sasl.pl

Spec: http://ircv3.org/extensions/sasl-3.1

IRCv3 general information: http://ircv3.org/ (irssi is notably missing from the "Compliant Software" section)

[ahf]

Agreed. We need this.

[ghost]

As for what mechanisms to implement, I'd suggest looking at what mechanisms Atheme implements, as it's the de-facto reference implementation (see https://github.com/atheme/atheme/tree/master/modules/saslserv). Furthermore, according to http://ircv3.atheme.org/documentation/sasl-dh-blowfish, the DH-BLOWFISH method is deprecated, so I'd suggest dropping it unless there are excess resources to allocate to SASL handling.

I'd suggest that the following mechanisms be implemented:

• PLAIN: for compatibility with custom SASL implementations that never bothered with the more advanced mechanisms
• DH-AES: for the sake of simplicity, albeit it also suffers from security weaknesses in terms of not verifying the other side according to http://ircv3.atheme.org/documentation/sasl-dh-aes)
• ECDSA-NIST256p-CHALLENGE: for the sake of security; see also: https://github.com/atheme/ecdsatool which contains an irssi script to look at

[ahf]

@culex is this something you would have an interest in looking into? :-)

[ghost]

I'm completely unfamiliar with the irssi codebase and have only limited time right now. If nobody's done anything until the 7th of July, I'll see what I can do. SASL is a relatively complex matter to implement correctly, and we don't even have CAP support from what I can tell, which is a requirement for handling SASL.

Given that IRCv3 is starting to become relatively ubiquitous, for better or for worse, I'd suggest that CAP support be done in a correct and proper way. To be honest, I'm hoping for someone with previous experience of implementing IRCv3 features to handle it.

[ahf]

Cool, I will leave this assigned to me for now. I will continue to focus on the migration stuff and getting all the patches for 0.8.17 in.

[xnite]

😺

[ghost]

I doubt I'll get around to implementing this. I'd suggest someone else pick this up.

[ahf]

@culex Thanks for letting us know! :-)

[Mikaela]

Irssi really needs this feature as SASL is widely agreed as the best method to identify to services and some networks have difficulties, because some people (Finns who mainly use IRCnet) don't ever identify or register channels and then go to complain to operators when they have lost ops on unregistered channels. CertFP isn't an option (yet(#188).

The mechanisms that I would support are:

• PLAIN which works everywhere unless the network is doing something wrong.
• EXTERNAL that means sending (certfp) certificate fingerprint with SASL and doesn't require password.
  • it would be even better if this was always attempted when certfp is configured (Limnoria does this).
• ECDSA-NIST256p-CHALLENGE new mechanism that isn't so widely used yet, but it's replacement for DH-AES and DH-BLOWFISH.

As you can see, I removed DH-AES @culex list because it was dropped from Atheme atheme/atheme@15f6d84 and added EXTERNAL which was forgotten from that list. EXTERNAL requires support from IRCd in addition to services and is supported on most of networks that I am on that support SASL with the exception of freenode's ircd-seven as they haven't merged that feature from Charybdis yet (freenode/ircd-seven#1).

There is also issue of Atheme discontinuing, because Atheme hosted the script before and now it will be at all repositories of Atheme forks and some networks like freenode are hosting different versions of the script.

[ghost]

@Mkaysi While I concur that I forgot SASL EXTERNAL, I'd strongly plead for keeping DH-AES or DH-BLOWFISH. While indeed, Atheme has removed DH-AES, Anope 2.0 (anope/anope) has no support for ECDSA-NIST256p-CHALLENGE but does support DH-AES (and DH-BLOWFISH).

As http://ircv3.atheme.org/documentation/sasl-dh-aes and http://ircv3.atheme.org/documentation/sasl-dh-blowfish state, the mechanisms are still vulnerable to MITM attacks. However, Anope 2.0 administrators may enable DH-AES or DH-BLOWFISH exclusively, thinking it is secure. From my undestanding of the DH-AES mechanism, it is secure in some constellations, particularly over SSL where the user may not wish/is unable to to use a client certificate for whatever reason, or where an attacker can only listen to the plain-text conversation (for example, via strace) but not create a layer inbetween. In that sense DH-AES is a step up from PLAIN, even if it is not an ideal solution.

[grawity]

Being able to use strace usually implies being able to attach a debugger like gdb, since they both use the same ptrace() function. (setuid /usr/bin/strace is an exception, but it doesn't change much as written below.)

Also, strace generally wouldn't show the plain-text conversation, since it only shows syscalls, and clients don't output the plain-text that way – they only call into the kernel in the end, to send encrypted TLS records. (One very rare exception is hardware crypto accelerators.)

On the other hand, you could see what data is being read from .irssi/sasl.auth or .weechat/irc.conf regardless of the mechanism – this would include plain-text passwords for DH-*.

[ghost]

@grawity The strace scenario and the SSL/TLS scenario I came up with are separate.

That said, having only strace and no gdb is indeed a rare scenario, but doesn't change the fact that there may be misguided Anope 2.0 admins who believe DH-{AES,BLOWFISH} are still appropriate over plaintext IRC.

[dequis]

or where an attacker can only listen to the plain-text conversation (for example, via strace)

If you consider the root user to be an attacker, I think you've got bigger problems.

From my undestanding of the DH-AES mechanism, it is secure in some constellations, particularly over SSL where the user may not wish/is unable to to use a client certificate for whatever reason

DH-AES over SSL is as secure as PLAIN over SSL. And I'm not saying PLAIN over SSL is bad, it's actually quite decent thanks to SSL.

But once you've got decent crypto at the transport level, what kind of attackers are you protecting against? (with something like DH-AES, that is)

[grawity]

Well, I imagine it might help against passive monitoring done by a server's operators (who could technically see all messages passing through it, including SASL commands). But they could rather easily MITM it anyway.

[Mikaela]

Status update on DH-AES and DH-BLOWFISH: freenode upgraded Atheme and support for these two mechanisms was dropped there.

[Mikaela]

That said, having only strace and no gdb is indeed a rare scenario, but doesn't change the fact that there may be misguided Anope 2.0 admins who believe DH-{AES,BLOWFISH} are still appropriate over plaintext IRC.

I asked from one Anope 2 admin and they said that they think that SASL PLAIN and EXTERNAL are in code and cannot be disabled.

EDIT: They checked it.

SASL PLAIN and EXTERNAL are parts of their core SASL solution and thus cannot be disabled without editing the code and losing Anope support. https://github.com/anope/anope/blob/2.0/modules/m_sasl.cpp

[kaniini]

@culex DH-AES/DH-BLOWFISH should be dropped from Anope 2 as they were in Atheme. They are dangerous to have enabled as the DH component is used with insecure parameters, which means the key used to encrypt the ciphertext is extremely weak (DH can only provide strong security for half the size of the DH parameters).

I would not advise that Irssi implement these mechanisms, as their use should be actively discouraged.

[LemonBoy]

As of today, with the deprecation of the DH-{AES,BLOWFISH} and the introduction (?) of SCRAM-SHA-256, what is the minimum set of mechanisms to support that provides the most compatibility and security ?
For the simplicity sake I'd say that PLAIN over SSL is enough for most, if not all, the use cases, but I'm not a security expert nor very knowledgeable about the recent SASL developments so my word should be taken with a grain of salt.

[Mikaela]

I have no idea what is SCRAM-SHA-256 (apparently something that has appeared at the SASL mechanisms page), but currently Atheme supports

• SASL PLAIN
• SASL EXTERNAL
• SASL ECDSA256-CHALLENGEAUTH
  • but on #irc3 kaniini has said that it's already dead and that is why znc won't be implementing it if I understood correctly.

There is also already IRCv3.2 SASL which features SASL REAUTH which allows SASL to be used after the initial connection e.g. when you have connected to splitted servers or services were down. Before it the only way to automatically identify in that case was CertFP. I think that irssi should also get it implemented.

[LemonBoy]

Well, IRCv3.2 isn't a priority right now since not even IRCv3.1 is supported, getting in some solid CAP and SASL support is a big step in the right direction (and it's being done in #222).
I was referring to this[1] which is listed here[2] among the other "common" mechanisms, while the ECDSA256-CHALLENGEAUTH isn't listed at all, this makes me question the usefulness of that list.
But since you state the aforementioned mechanism is 'dead' I'm inclined to add support for PLAIN and EXTERNAL only since it's a safe bet those won't go away anytime soon

[1] https://tools.ietf.org/html/draft-hansen-scram-sha256-02
[2] http://ircv3.net/docs/sasl-mechs.html

[kaniini]

What she is saying is that SASL REAUTH should be considered for implementation at the same time as the rest of it to ensure it actually gets done. REAUTH is essentially just a clarification that authentication could be implemented after registration, and can be done on 3.1 servers (assuming that they have gotten patched to allow it).

[dequis]

#278 is now merged, with SASL PLAIN and EXTERNAL support. Huge thanks to @LemonBoy for contributing this and addressing the issues that were brought up during the review... some of which may have been a bit nitpicky.

Things left out of the scope of that pull request, to be addressed before the release:

• Signals to allow scripts to implement additional mechanisms (such as the ECDSA one)
• Compatibility with the existing cap_sasl.pl script (bug Do something about cap_sasl.pl conflicting with the new CAP code #279)
• SASL REAUTH. That would require something like a command to manually reauthenticate, the current implementation only does it automatically during connection registration.
• sasl-3.2 (and cap-3.2 / cap-notify), and SASL REAUTH through CAP NEW

[Mikaela]

(such as the ECDSA one)

A little offtopic, but in case you are interested, ZNC won't be implementing it, because of the log at znc/znc#746 (comment).

[dequis]

That's good to know. Basically the same reason ahf doesn't want it, nist curves. But still good to allow scripts to implement it since some people currently use it through cap_sasl.pl.

[Neustradamus]

Dear all,

I wish you a Happy New Year 2025!

Good news to all: @patrick-irc has added the SCRAM supports, thanks a lot!

It is not a joke: "Posted on April 1st 2024"

• https://irssi.org/2024/04/01/sasl-scram-sha-support/

It solves my initial request done 2020-04-20:

• SCRAM-SHA-1-PLUS + SCRAM-SHA-256(-PLUS) + SCRAM-SHA-512(-PLUS) supports #1178

Merged PR:

• Added support for SCRAM-SHA-1, SCRAM-SHA-256 and SCRAM-SHA-512 #1500

Merged commits:

• b18832b
• f2b9763
• irssi/irssi.github.io@e54ff06

Linked to:

• State of Play scram-sasl/info#1
• Built-in SASL authentication (IRCv3.1) #4
• SASL mechanism: SCRAM-SHA-256 #1331

cc: @dequis, @ircnet-com.