SASL EXTERNAL (SRP) login option

[SoniEx2]

https://tools.ietf.org/html/rfc5054

SRP is a PAKE, the main benefit of a PAKE is that the password gets used as part of the key exchange protocol, authenticating both the client and the server simultaneously. TLS-SRP combines SRP with TLS, and can be deployed today.

More specifically, the benefits are:

1. An active attacker (such as may happen with a self-signed server certificate) doesn't get any information about the password. Not the password itself (as with SASL PLAIN), not the password hash (as with SCRAM). It is completely zero-knowledge to an active attacker.
2. An active attacker will cause the TLS connection to be closed. The key exchange will fail, and without a successful key exchange, there's no TLS connection.
3. It is highly beneficial for a server to properly hash its passwords when using TLS-SRP. Encouraging TLS-SRP support would also encourage proper password handling.

TLS-SRP does have some drawbacks, tho: it has been broken quite a few times in the past, and is up to version 6a nowadays(!). However, I strongly feel like the benefits far outweigh the risks. Additionally, we can deprecate TLS-SRP when TLS-OPAQUE comes out.

See also https://blog.cryptographyengineering.com/2018/10/19/lets-talk-about-pake/

[wodim]

What networks support SASL EXTERNAL (SRP) login?

[SoniEx2]

many networks support SASL EXTERNAL. whether they'll take SRP or CertFP is another story, and not defined by any RFCs. (neither IRCv3 nor SASL EXTERNAL define it.)

I strongly recommend supporting TLS-SRP with SASL EXTERNAL. The existing SASL EXTERNAL should then be renamed to SASL EXTERNAL (Client Cert).

[Stanzilla]

Patches welcome