SASL

[patrick-irc]

Preparatory work

• moved uid from struct User to Client to allow a service to communicate with an user that is not connected/registered yet
• fixed ENCAP

Documentation:

• SASL in general: sasl_original.md
• our implementation: sasl.md

Further information:

• In this first implementation the SASL account name is not propagated to other servers and shown in WHOIS only to opers on the same server.
• Support for cloak comes in a separate pull request

17

[patrick-irc]

SASL mechanisms like SCRAM-SHA-* are very CPU intensive. We cannot use the ircd for it. Also it require much overhead to store the users and their encryption keys, synchronize them. The ircd is not suitable for this task.

I have already developed an IRC service that syncs with the cloak website and offers various mechanisms. Services can also be redundant, the closest one to the user will handle the request.

[eaescob]

I'm not sure a network of a few thousand users is that CPU intensive and storing a credentials file isn't that much of a burden. I think the approach here to think about is maybe making hubs that SASL service. That way we can maintain the hub<>servers independence.

[pvaldes]

I have to agree with @eaescob, hubs do not handle any user connections, making them a great candidate to handle credentials and allowing each of them to maintain independence. I also expect user connections to continue to drop in the next few years, so it shouldn't become a future problem either.

[patrick-irc]

I'm not sure a network of a few thousand users is that CPU intensive I also expect user connections to continue to drop in the next few years

This never justifies a bad software design.

storing a credentials file isn't that much of a burden.

That supports PLAIN SCRAM-SHA-1 SCRAM-SHA-256 SCRAM-SHA-512 and ECDSA-NIST256P-CHALLENGE? How do you even get these information from a user into that file?

Please do not think a service has to be global, like NickServ is. A service can exist only for 1 server or for a group of servers (current approach: distribution masks [see SERVICE.txt], possible further approach: a list of SIDs). Then there is no difference between: a) hub's ircd handles the authentication for his leafs b) a SASL service running on the hub handles the authentication for the hub and its leafs

b) is a microservice approach with all the known benefits:

• separation of concerns
• scalability
• we can use an different language and their libraries (Java, C#) for encryption, webservice sync etc

and btw. these things have been coded 3 years ago already, the service included - and run on IRCnet2.

See also: https://github.com/ircnet/ircd/blob/master/doc/SERVICE.txt

[patrick-irc]

@eaescob @pvaldes

As described in #24: By configuring an S-Line the leaf can select which SASL Service(s) it uses.

Example ircd.conf of a leaf:

S|||SASLServ@hub1.ircnet.com|0x00800000|
S|||SASLServ@hub2.ircnet.com|0x00800000|

If there is more than one, the closest one (hopcount) will be used. Other SASLServices on the network, which are not configured by S-Line, will be ignored.