RFC 9266: Channel Bindings for TLS 1.3 support

Neustradamus commented 2 years ago

Can you add the support of RFC 9266: Channel Bindings for TLS 1.3?

https://datatracker.ietf.org/doc/html/rfc9266

Channel Bindings for TLS: https://datatracker.ietf.org/doc/html/rfc5929

XEP-0388: Extensible SASL Profile: https://xmpp.org/extensions/xep-0388.html
XEP-0440: SASL Channel-Binding Type Capability: https://xmpp.org/extensions/xep-0440.html
XEP-0474: SASL SCRAM Downgrade Protection: https://xmpp.org/extensions/xep-0474.html
XEP-0480: SASL Upgrade Tasks: https://xmpp.org/extensions/xep-0480.html

Little details, to know easily:

tls-unique for TLS =< 1.2
tls-server-end-point
tls-exporter for TLS = 1.3

I think that you have seen the jabber.ru MITM and Channel Binding is the solution:

Thanks in advance.

Linked to:

Neustradamus commented 1 year ago

Dear @cyrusimap team, @aamelnikov, @ksmurchison, @quanah, @hyc, @bgermann, @dilyanpalauzov, @iboukris, @simo5,

Can you look for Channel Binding for TLS 1.3 support?

There is a recent history with jabber.ru MITM and SCRAM-SHA-*-PLUS is the security solution!

Some sources about jabber.ru:

Thanks in advance.

Linked to:

GuidoKiener commented 10 months ago

@Neustradamus @ksmurchison I will add a merge request that supports channel binding for TLS 1.3 with tls-exporter. Here is the output of the imtest:

guido@debian:~/source/repos/cyrus-imapd$ ./imtest/imtest -s -a cyrus localhost -m SCRAM-SHA-256-PLUS
verify error:num=18:self-signed certificate
TLS connection established: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
S: * OK [CAPABILITY IMAP4rev1 LITERAL+ ID ENABLE AUTH=SCRAM-SHA-512-PLUS AUTH=SCRAM-SHA-512 AUTH=SCRAM-SHA-384-PLUS AUTH=SCRAM-SHA-384 AUTH=SCRAM-SHA-256-PLUS AUTH=SCRAM-SHA-256 AUTH=SCRAM-SHA-224-PLUS AUTH=SCRAM-SHA-224 AUTH=SCRAM-SHA-1-PLUS AUTH=SCRAM-SHA-1 AUTH=DIGEST-MD5 AUTH=NTLM AUTH=CRAM-MD5 AUTH=PLAIN AUTH=LOGIN SASL-IR] debian Cyrus IMAP 3.9.0-alpha0-1-gefcf1df9a server ready
Please enter your password:
C: A01 AUTHENTICATE SCRAM-SHA-256 cD10bHMtZXhwb3J0ZXIsLG49Y3lydXMscj1vZzYxbW5ySm5wbFVxOU4wa3FZVXhUdUxBUjFNV0ZReA==
S: + cj1vZzYxbW5ySm5wbFVxOU4wa3FZVXhUdUxBUjFNV0ZReFVvTCtKMUx5bmpPRTdHclp4SU0vbzNXTUt1dU9PQmNlLHM9aUd1bWMrQjQ5aFRwTHRnSGdDaVNhYTg3SzFMV1RjRkdGN3RELzZhT3RkYz0saT00MDk2
C: Yz1jRDEwYkhNdFpYaHdiM0owWlhJc0xMZFNmMWpReXRtMnQ0NWEyOGFSN01zUEVrdktDUENmWnJpSWFzK1JINlpKLHI9b2c2MW1uckpucGxVcTlOMGtxWVV4VHVMQVIxTVdGUXhVb0wrSjFMeW5qT0U3R3JaeElNL28zV01LdXVPT0JjZSxwPWNxbDQwU3lLV3g3eW9jVzM4VWpKSEQrcWVGYWxXR0EwYk41aGlDWFJXMlk9
S: + dj0wVFlyV0U5eUNObmc1dnIyZnRpRTcvY1owN1NVR3dRVjMrSVdnckpLYkhFPQ==
C:
S: A01 OK [CAPABILITY IMAP4rev1 LITERAL+ ID ENABLE ACL ANNOTATE-EXPERIMENT-1 BINARY CATENATE CHILDREN CONDSTORE CREATE-SPECIAL-USE ESEARCH ESORT LIST-EXTENDED LIST-MYRIGHTS LIST-STATUS MAILBOX-REFERRALS METADATA MOVE MULTIAPPEND MULTISEARCH NAMESPACE OBJECTID PREVIEW QRESYNC QUOTA RIGHTS=kxten SAVEDATE SEARCH=FUZZY SEARCHRES SORT SORT=DISPLAY SPECIAL-USE STATUS=SIZE THREAD=ORDEREDSUBJECT THREAD=REFERENCES UIDPLUS UNSELECT URL-PARTIAL URLAUTH URLAUTH=BINARY WITHIN DIGEST=SHA1 LIST-METADATA NO_ATOMIC_RENAME SCAN SORT=MODSEQ SORT=UID THREAD=REFS X-CREATEDMODSEQ X-REPLICATION X-SIEVE-MAILBOX X-REPLICATION-ARCHIVE XLIST XMOVE LOGINDISABLED UNAUTHENTICATE COMPRESS=DEFLATE X-QUOTA=STORAGE X-QUOTA=MESSAGE X-QUOTA=X-ANNOTATION-STORAGE X-QUOTA=X-NUM-FOLDERS IDLE APPENDLIMIT=2147483647] Success (tls protection) SESSIONID=<cyrus-1702756039-50004-1-6815125373968846408>
Authenticated.
Security strength factor: 256

The first client message (Base64 decoded) is: p=tls-exporter,,n=cyrus,r=og61mnrJnplUq9N0kqYUxTuLAR1MWFQx

The patch will ensure to use the correct Export Keying Material (EKM) according to RFC 9266 Section 2. Nevertheless I see some more open issues:

Compatibility with mail clients supporting SCRAM is not tested (https://en.wikipedia.org/wiki/Comparison_of_email_clients)
Only SCRAM-SHA-1(-PLUS) and SCRAM-SHA-265(-PLUS) and not SHA-224/384/512 should be offered by a mail server.
Instructions how to setup security (e.g. using options: pwcheck_method=auxprop,scram_secret_generate=y)
Optional: cyrus-sasl repo needs an additional property (e.g. sasl_setprop(conn, SASL_CHANNEL_BINDING2, &cb)) to set alternate channel binding data e.g. for "tls-server-end-point". Thus the SCRAM-*-PLUS or GS2-KRB5-PLUS mechanism can select the desired channel binding type of the client.

Neustradamus commented 10 months ago

@GuidoKiener: Nice, good job! :)

Can you look for "tls-server-end-point" too?

GuidoKiener commented 10 months ago

@GuidoKiener: Nice, good job! :) Can you look for "tls-server-end-point" too?

It's possible to add "tls-server-end-point", however this requires some patches in cyrusimap/cyrus-sasl and cyrusimap/cyrus-imapd. Are there any plans that someone wants to use it? It's only useful for mail clients that cannot create the "tls-exporter" or "tls-unique" channel binding data. I didn't quickly find a mail client that is using the SCRAM-SHA-256-PLUS mechanism at all. Before I start to create patches I would like to know if there is a need to support it.

Neustradamus commented 10 months ago

@GuidoKiener: It must be added in cyrus-sasl and cyrus-imapd to be use in other projects/softwares...

Example, it is in SASL2 I-D:

Extensible Simple Authentication and Security Layer (SASL): https://datatracker.ietf.org/doc/html/draft-melnikov-sasl2

It is in several XEPs too:

XEP-0388: Extensible SASL Profile: https://xmpp.org/extensions/xep-0388.html
XEP-0440: SASL Channel-Binding Type Capability: https://xmpp.org/extensions/xep-0440.html
XEP-0474: SASL SCRAM Downgrade Protection: https://xmpp.org/extensions/xep-0474.html
XEP-0480: SASL Upgrade Tasks: https://xmpp.org/extensions/xep-0480.html

Neustradamus commented 10 months ago

@GuidoKiener: For example, Psi/Psi+ uses Cyrus SASL via QCA:

https://github.com/KDE/qca

It is needed for -PLUS variants ^^

More details about SCRAM and -PLUS variants:

https://github.com/scram-sasl/info/issues/1

cyrusimap / cyrus-imapd

RFC 9266: Channel Bindings for TLS 1.3 support #4191