563276 - Support RFC 5929 - Channel Bindings for TLS

Status: NEW

(NSS :: Libraries, enhancement, P5)

Description

[Ryan Sleevi]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/533.2 (KHTML, like Gecko) Chrome/5.0.342.9 Safari/533.2
Build Identifier: 

While draft-altman-tls-channel-bindings is not yet a finalized RFC, the functionality is currently deployed by Microsoft as part of their SChannel SSPI, as it's necessary to implement "Integrated Windows Authentication with Enhanced Protection" ( http://msdn.microsoft.com/en-us/library/dd639324(VS.90).aspx ).

Further, the tls-channel-bindings are referenced by a number of RFCs currently in progress ( http://www.fenron.net/~fenner/ietf/deps/index.cgi?dep=draft-altman-tls-channel-bindings )

The current version is -10, and is on track to be finalized soon ( https://datatracker.ietf.org/doc/draft-altman-tls-channel-bindings/ )

Reproducible: Always

Comment 1

[Ryan Sleevi]

Attachment: Patch against 3.12.6 adding support

One new public enum is exported by this patch:

SSLChannelBindingType

Two new public API calls are exposed:

SSL_GetChannelBinding
SEC_DecodeSignatureAlgorithmOidTag

I was uncertain whether it would be more appropriate to use a dynamic array for returning the types of supported channel bindings (similar to how cipher suites are supported), to facilitate protocols that may be able to negotiate amongst multiple types of bindings that may be added later, or whether to use the currently hard-coded list. Given that the selection of channel binding type may affect the strength of security offered, it seemed more appropriate to require application developers specify the type of binding they intend to request.

Absent of any specific NSS coding guidelines I could find, I've attempted to adhere to http://www.mozilla.org/projects/nspr/eng-process/contributors.html . Though most of the code appeared a mix between tabs and spaces, all of the new code contained is standardized on a four-space indent style.

Outputs were added to vfyserv and selfserv to output all of the available channel bindings during connection, when appropriate. I've cross-referenced the results with the Microsoft SChannel provider to verify compatibility, and will be happy to attach a patch to the Platform SDK Web Server sample code if necessary.

No new unit tests were added to this code.

Comment 2

[Nelson Bolyard (seldom reads bugmail)]

Comment on attachment 443031 [details] [diff] [review]
Patch against 3.12.6 adding support

Wan-Teh has encouraged me to review this patch.

Comment 3

[Nelson Bolyard (seldom reads bugmail)]

I confirm this is an enhancement request. :)

Comment 4

[Adam Langley]

We had need of the tls-unique binding and so there's a Chromium patch here:

http://src.chromium.org/viewvc/chrome/trunk/src/net/third_party/nss/patches/tlsunique.patch?view=markup

I wasn't aware of this bug when writing it and I'm not claiming that it's superiour.

Comment 5

[Wan-Teh Chang]

draft-altman-tls-channel-bindings has become RFC 5929:
Channel Bindings for TLS.

Comment 6

[Eric Mill]

Are there any plans to add TLS Channel ID support to NSS? Is that the only route to support in Firefox? Looks like this one's been sitting for quite some time.

Comment 7

[Ryan Sleevi]

Eric: this bug is about channel bindings, which is separate (and standardized) from token bindings (new channel ID)

Comment 8

[Neustradamus]

Any news on it?
Channel-Binding Support is important.
It is needed for SCRAM-SHA-XXX-PLUS variants

Linked to:

• XMPP: https://bugzilla.mozilla.org/show_bug.cgi?id=1577688
• MAIL: https://bugzilla.mozilla.org/show_bug.cgi?id=1503382

Comment 9

[Neustradamus]

It is possible to change the "Milestone"?
It is a forgotten ticket I think...

Comment 10

[Neustradamus]

It is already done for XMPP:

• SCRAM-SHA-1: https://bugzilla.mozilla.org/show_bug.cgi?id=1267649
• SCRAM-SHA-256: https://bugzilla.mozilla.org/show_bug.cgi?id=1577688

SCRAM-SHA-1-PLUS and SCRAM-SHA-256-PLUS are missing because https://bugzilla.mozilla.org/show_bug.cgi?id=563276
This ticket, people can look?

Tickets:

• For IMAP: https://bugzilla.mozilla.org/show_bug.cgi?id=1503382
• For POP: https://bugzilla.mozilla.org/show_bug.cgi?id=1597102
• For SMTP: https://bugzilla.mozilla.org/show_bug.cgi?id=1597103
• For LDAP: https://bugzilla.mozilla.org/show_bug.cgi?id=1597106
  People can look?

RFCs:

• RFC5802: Salted Challenge Response Authentication Mechanism (SCRAM) SASL and GSS-API Mechanisms: https://tools.ietf.org/html/rfc5802
• RFC7677: SCRAM-SHA-256 and SCRAM-SHA-256-PLUS Simple Authentication and Security Layer (SASL) Mechanisms: https://tools.ietf.org/html/rfc7677 - since 2015-11-02
• 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
• RFC5803: Lightweight Directory Access Protocol (LDAP) Schema for Storing Salted: Challenge Response Authentication Mechanism (SCRAM) Secrets: https://tools.ietf.org/html/rfc5803
• RFC7804: Salted Challenge Response HTTP Authentication Mechanism: https://tools.ietf.org/html/rfc7804

IANA:

• Simple Authentication and Security Layer (SASL) Mechanisms: https://www.iana.org/assignments/sasl-mechanisms/sasl-mechanisms.xhtml
• Channel-Binding Types: https://www.iana.org/assignments/channel-binding-types/channel-binding-types.xhtml

Cyrus SASL supports:

• SCRAM-SHA-1
• SCRAM-SHA-1-PLUS
• SCRAM-SHA-224
• SCRAM-SHA-224-PLUS
• SCRAM-SHA-256
• SCRAM-SHA-256-PLUS
• SCRAM-SHA-384
• SCRAM-SHA-384-PLUS
• SCRAM-SHA-512
• SCRAM-SHA-512-PLUS
  -> https://cyrusimap.org/sasl/sasl/authentication_mechanisms.html
  -> https://github.com/cyrusimap/cyrus-sasl/commits/master

Dovecot SASL supports:

• SCRAM-SHA-1
  -> https://doc.dovecot.org/configuration_manual/authentication/password_schemes/

GNU SASL supports:

• SCRAM-SHA-1
• SCRAM-SHA-1-PLUS
  -> http://www.gnu.org/software/gsasl/

CRAM-MD5 to Historic:

• https://tools.ietf.org/html/draft-ietf-sasl-crammd5-to-historic-00 // 20 November 2008

RFC6331: Moving DIGEST-MD5 to Historic

• https://tools.ietf.org/html/rfc6331 since July 2011

More informations:

• https://github.com/scram-xmpp/info/issues/1

Comment 11

[Neustradamus]

After old TLS version, for TLS 1.3, there is: https://tools.ietf.org/html/draft-ietf-kitten-tls-channel-bindings-for-tls13

And there are other SCRAM too:

• 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
• Extensions to Salted Challenge Response (SCRAM) for 2 factor authentication: https://tools.ietf.org/html/draft-melnikov-scram-2fa

Comment 12

[Neustradamus]

It is official, it is here: RFC 9266: Channel Bindings for TLS 1.3:

• https://tools.ietf.org/html/rfc9266

Little details, to know easily:

• tls-unique for TLS =< 1.2
• tls-exporter for TLS = 1.3

Can you add the support?

---

SCRAM-BIS: https://tools.ietf.org/html/draft-melnikov-scram-bis

Comment 13

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee is inactive on Bugzilla, and this bug has priority 'P1'.
:beurdouche, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 14

[Dennis Jackson]

See the comment on status here.

Comment 15

[Neustradamus]

There was a jabber.ru (and xmpp.ru) MITM. Security is important and Channel Binding is the solution.

Can you add the support to have SCRAM-SHA-*-PLUS?
It is for all protocols.

Some sources:

• https://notes.valdikss.org.ru/jabber.ru-mitm/
• https://snikket.org/blog/on-the-jabber-ru-mitm/
• https://www.devever.net/~hl/xmpp-incident
• https://blog.jmp.chat/b/certwatch

Thanks in advance.

Linked to:

• https://bugzilla.mozilla.org/show_bug.cgi?id=563276
• https://bugzilla.mozilla.org/show_bug.cgi?id=1267649
• https://bugzilla.mozilla.org/show_bug.cgi?id=1577688
• https://bugzilla.mozilla.org/show_bug.cgi?id=1579638
• https://bugzilla.mozilla.org/show_bug.cgi?id=1597102
• https://bugzilla.mozilla.org/show_bug.cgi?id=1597103
• https://bugzilla.mozilla.org/show_bug.cgi?id=1597106
• https://bugzilla.mozilla.org/show_bug.cgi?id=1597113
• https://bugzilla.mozilla.org/show_bug.cgi?id=1807870
• https://bugzilla.mozilla.org/show_bug.cgi?id=1862728
• https://bugzilla.mozilla.org/show_bug.cgi?id=1862729

Comment 16

[Neustradamus]

Dear Mozilla Team,

Good news, the recent Dovecot 2.4.0 has SCRAM-SHA-1-PLUS/SCRAM-SHA-256-PLUS supports in more SCRAM-SHA-1/SCRAM-SHA-256. It arrives after Exim, indimail-mta, msmtp, mpop, ...

After, several years, can you add Channel Binding for TLS support?
Thunderbird Mobile / K-9 Mail included of course.

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

All list is here:

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

Thanks in advance.