View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0006539 | unreal | ircd | public | 2025-07-31 06:56 | 2025-09-04 06:54 |
| Reporter | Neustradamus | Assigned To | syzop | ||
| Priority | normal | Severity | feature | Reproducibility | always |
| Status | closed | Resolution | no change required | ||
| Product Version | 6.2.0-beta2 | ||||
| Summary | 0006539: IRCv3 SASL Mechanisms: SCRAM-SHA-*(-PLUS) supports | ||||
| Description | Dear @UnrealIRCd team, I contact you about "IRCv3 SASL Mechanisms": - https://ircv3.net/docs/sasl-mechs Can you add supports of: - SCRAM-SHA-256 - SCRAM-SHA-256-PLUS You can add too: - SCRAM-SHA-1 - SCRAM-SHA-1-PLUS - SCRAM-SHA-512 - SCRAM-SHA-512-PLUS - SCRAM-SHA3-512 - SCRAM-SHA3-512-PLUS Thanks in advance. I send you a lot of informations about it: "When using the SASL SCRAM mechanism, the SCRAM-SHA-256-PLUS variant SHOULD be preferred over the SCRAM-SHA-256 variant, and SHA-256 variants [RFC7677] SHOULD be preferred over SHA-1 variants [RFC5802]". - SCRAM-SHA-1(-PLUS): -- https://tools.ietf.org/html/rfc5802 -- https://tools.ietf.org/html/rfc6120 - SCRAM-SHA-256(-PLUS): -- https://tools.ietf.org/html/rfc7677 since 2015-11-02 -- https://tools.ietf.org/html/rfc8600 since 2019-06-21: https://mailarchive.ietf.org/arch/msg/ietf-announce/suJMmeMhuAOmGn_PJYgX5Vm8lNA - SCRAM-SHA-512(-PLUS): -- https://tools.ietf.org/html/draft-melnikov-scram-sha-512 - SCRAM-SHA3-512(-PLUS): -- https://tools.ietf.org/html/draft-melnikov-scram-sha3-512 - SCRAM BIS: Salted Challenge Response Authentication Mechanism (SCRAM) SASL and GSS-API Mechanisms: -- https://tools.ietf.org/html/draft-melnikov-scram-bis https://xmpp.org/extensions/inbox/hash-recommendations.html -PLUS variants: - RFC5056: On the Use of Channel Bindings to Secure Channels: https://tools.ietf.org/html/rfc5056 - RFC5929: Channel Bindings for TLS: https://tools.ietf.org/html/rfc5929 - Channel-Binding Types: https://www.iana.org/assignments/channel-binding-types/channel-binding-types.xhtml - RFC 9266: Channel Bindings for TLS 1.3: https://tools.ietf.org/html/rfc9266 IMAP: - RFC9051: Internet Message Access Protocol (IMAP) - Version 4rev2: https://tools.ietf.org/html/rfc9051 LDAP: - RFC5803: Lightweight Directory Access Protocol (LDAP) Schema for Storing Salted: Challenge Response Authentication Mechanism (SCRAM) Secrets: https://tools.ietf.org/html/rfc5803 HTTP: - RFC7804: Salted Challenge Response HTTP Authentication Mechanism: https://tools.ietf.org/html/rfc7804 2FA: - Extensions to Salted Challenge Response (SCRAM) for 2 factor authentication: https://datatracker.ietf.org/doc/html/draft-ietf-kitten-scram-2fa IANA: - Simple Authentication and Security Layer (SASL) Mechanisms: https://www.iana.org/assignments/sasl-mechanisms/sasl-mechanisms.xhtml Linked to: - https://github.com/scram-xmpp/info/issues/1 | ||||
| Tags | No tags attached. | ||||
| 3rd party modules | |||||
|
|
As mentioned by grawity in https://github.com/ircv3/ircv3-ideas/issues/130#issuecomment-3131164559 this does not seem applicable to IRC w/services. In the IRC world the SSL/TLS connection is between the IRC server and IRC client, and the SASL authentication goes towards "Services" which is another IRC Server linked to the IRC Server. Closing. |
|
|
Sorry but it is not supported by UnrealIRCd: - https://github.com/search?q=repo%3Aunrealircd%2Funrealircd+scram&type=code You mix SCRAM-SHA-256 (base) and SCRAM-SHA-256-PLUS (Channel Binding). SCRAM-SHA-256 is in IRCv3 specification: - https://ircv3.net/docs/sasl-mechs - https://github.com/search?q=org%3Aircv3+scram&type=code The specified ticket https://github.com/ircv3/ircv3-ideas/issues/130 is about Channel Binding, the second part from RFC 7677: https://datatracker.ietf.org/doc/html/rfc7677. Please reopen it. Thanks in advance. |
|
|
As for the PLUS variant, i explained in previous comment why this is not a thing. I never said it was implemented. For SCRAM-SHA-* (the non PLUS variant) we don't need any source code changes in UnrealIRCd. That's up to Services to implement, or not. When Services enable it, it magically appears on the IRCd side as well, just like all other SASL mechanisms. So yeah, this can be closed again. Nothing to be changed on our end. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2025-07-31 06:56 | Neustradamus | New Issue | |
| 2025-07-31 15:46 | syzop | Priority | high => normal |
| 2025-08-30 09:11 | syzop | Assigned To | => syzop |
| 2025-08-30 09:11 | syzop | Status | new => closed |
| 2025-08-30 09:11 | syzop | Resolution | open => no change required |
| 2025-08-30 09:11 | syzop | Note Added: 0023484 | |
| 2025-09-01 01:51 | Neustradamus | Status | closed => feedback |
| 2025-09-01 01:51 | Neustradamus | Resolution | no change required => reopened |
| 2025-09-01 01:51 | Neustradamus | Note Added: 0023485 | |
| 2025-09-04 06:53 | syzop | Status | feedback => closed |
| 2025-09-04 06:53 | syzop | Note Added: 0023488 | |
| 2025-09-04 06:54 | syzop | Severity | major => feature |
| 2025-09-04 06:54 | syzop | Resolution | reopened => no change required |
