indimail / indimail-mta

qmail fork with IPV6, TLS, DANE, DKIM, SRS2, SPF, daemontools, qmailanalog, mess822, & ucspi-tcp
https://github.com/indimail/indimail-mta/wiki/0-IndiMail-Wiki
GNU General Public License v3.0
12 stars 2 forks source link

Add Channel binding support for SCRAM-*-PLUS variants. #33

Closed mbhangui closed 1 year ago

mbhangui commented 1 year ago
  1. Add support for tls-unique channel binding using SSL_get_peer_finished()
  2. Add support for tls-exporter channel binding using SSL_export_keying_material()
  3. Handle GSASL_CB_TLS_UNIQUE, GSASL_CB_TLS_EXPORTER in gs_callback()
mbhangui commented 1 year ago

@Neustradamus FYI. This PR adds SCRAM-SHA-1-PLUS and SCRAM-SHA-256-PLUS in smtpd.c using gsasl and also uses the latest tls-exporter channel binding added recently by @jas4711.

I will merge this PR into master when tls-exporter cb becomes available in the mainstream gsasl downloads (i'm guessing, most probably gsasl-2.0.2).

Neustradamus commented 1 year ago

@mbhangui: Excellent, good job! :)

cc: @jas4711.

mbhangui commented 1 year ago

@Neustradamus, If possible can you help me with this confusion

RFC 5802 isn't explicit on what to do when the client supports channel binding but the server does not.

I did some more reading on this and found this draft submitted to ietf document. I have no idea of the status of this document.

Section 2 of the above document clearly says

The client MUST NOT use channel binding if it lists the server's mechanisms and does not find a suitable mechanism that supports channelbinding in that list.

gsasl client terminates the connection if the server doesn't advertise the PLUS variants. Just want to know if this behaviour is correct or it should attempt the connection. I have already submitted a patch to the help-gsasl list, but I'm not sure if my assumptions are correct.

https://lists.gnu.org/archive/html/help-gsasl/2022-08/msg00002.html

Neustradamus commented 1 year ago

@mbhangui: It is a good point but I prefer to keep an answer from an expert ^^

Good to see your messages here, hope that @jas4711 will reply:

About it, there is a new Draft ID but it is not an RFC:

To compare 02 and 03: https://www5.aptest.com/standards/htmldiff/htmldiff.pl?oldfile=https://datatracker.ietf.org/doc/html/draft-ietf-sasl-channel-bindings-02&newfile=https://datatracker.ietf.org/doc/html/draft-ietf-sasl-channel-bindings-03

The author of this Draft-ID (which has not been an RFC) is https://www.google.com/search?q=Nicolas.Williams+sun.com (he has changed of company, @nicowilliams).

It was to update RFC4422 (https://tools.ietf.org/html/RFC4422) from Alexey Melnikov (alexey.melnikov@isode.com, @aamelnikov) and Kurt D. Zeilenga (kurt@openldap.org).

Official RFCs about Channel Binding are:

There is an old IETF mailinglist:

mbhangui commented 1 year ago

I got a reply from Simon and it is all good. I just need to pass --no-cb argument to gsasl and it works.