Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFC 9266: Channel Bindings for TLS 1.3 support #4191

Open
Neustradamus opened this issue Jul 27, 2022 · 7 comments
Open

RFC 9266: Channel Bindings for TLS 1.3 support #4191

Neustradamus opened this issue Jul 27, 2022 · 7 comments

Comments

@Neustradamus
Copy link

Neustradamus commented Jul 27, 2022

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

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

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:

@GuidoKiener
Copy link

@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.

GuidoKiener added a commit to GuidoKiener/cyrus-imapd that referenced this issue Dec 16, 2023
TLS connections of the IMAPD service provide channel binding data
for the SASL authentication layer. The current implementation
sets the correct "tls-unique" channel binding data for TLS
versions 1.2 and lower, however not for TLS version 1.3.

TLS version 1.3 requires using specific exporter keying material
(EKM) according to RFC 9266 Section 2:
Label:      "EXPORTER-Channel-Binding"
Context:    Zero-length string
Key Length: 32 bytes

Signed-off-by: Guido Kiener <guido@kiener-muenchen.de>
GuidoKiener added a commit to GuidoKiener/cyrus-imapd that referenced this issue Dec 18, 2023
TLS connections of the IMAPD service provide channel binding data
for the SASL authentication layer. The current implementation
sets the correct "tls-unique" channel binding data for TLS
versions 1.2 and lower, however not for TLS version 1.3.

TLS version 1.3 requires using specific exporter keying material
(EKM) according to RFC 9266 Section 2:
Label:      "EXPORTER-Channel-Binding"
Context:    Zero-length string
Key Length: 32 bytes

Signed-off-by: Guido Kiener <guido@kiener-muenchen.de>
@Neustradamus
Copy link
Author

@GuidoKiener: Nice, good job! :)

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

@GuidoKiener
Copy link

@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
Copy link
Author

Neustradamus commented Dec 22, 2023

@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:

It is in several XEPs too:

@Neustradamus
Copy link
Author

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

It is needed for -PLUS variants ^^

More details about SCRAM and -PLUS variants:

GuidoKiener added a commit to GuidoKiener/cyrus-imapd that referenced this issue Feb 11, 2024
TLS connections of the IMAPD service provide channel binding data
for the SASL authentication layer. The current implementation
sets the correct "tls-unique" channel binding data for TLS
versions 1.2 and lower, however not for TLS version 1.3.

TLS version 1.3 requires using specific exporter keying material
(EKM) according to RFC 9266 Section 2:
Label:      "EXPORTER-Channel-Binding"
Context:    Zero-length string
Key Length: 32 bytes

Signed-off-by: Guido Kiener <guido@kiener-muenchen.de>
rjbs pushed a commit to GuidoKiener/cyrus-imapd that referenced this issue Sep 20, 2024
TLS connections of the IMAPD service provide channel binding data
for the SASL authentication layer. The current implementation
sets the correct "tls-unique" channel binding data for TLS
versions 1.2 and lower, however not for TLS version 1.3.

TLS version 1.3 requires using specific exporter keying material
(EKM) according to RFC 9266 Section 2:
Label:      "EXPORTER-Channel-Binding"
Context:    Zero-length string
Key Length: 32 bytes

Signed-off-by: Guido Kiener <guido@kiener-muenchen.de>
@Neustradamus
Copy link
Author

Dear all,

Have you looked to have a perfect Channel Bindings support?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants