Closed mbhangui closed 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).
@mbhangui: Excellent, good job! :)
cc: @jas4711.
@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
@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:
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:
I got a reply from Simon and it is all good. I just need to pass --no-cb argument to gsasl and it works.