Support RFC 5929 - Channel Bindings for TLS
Categories
(NSS :: Libraries, enhancement, P5)
Tracking
(Not tracked)
People
(Reporter: ryan.sleevi, Unassigned)
References
()
Details
Attachments
(1 file)
19.58 KB,
patch
|
Details | Diff | Splinter Review |
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
Reporter | ||
Comment 1•14 years ago
|
||
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•14 years ago
|
||
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•14 years ago
|
||
I confirm this is an enhancement request. :)
Updated•14 years ago
|
Comment 4•12 years ago
|
||
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.
Updated•12 years ago
|
Comment 5•12 years ago
|
||
draft-altman-tls-channel-bindings has become RFC 5929: Channel Bindings for TLS.
Updated•12 years ago
|
Updated•12 years ago
|
Updated•12 years ago
|
Reporter | ||
Updated•11 years ago
|
Updated•11 years ago
|
Updated•11 years ago
|
Updated•10 years ago
|
Updated•10 years ago
|
Updated•10 years ago
|
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.
Reporter | ||
Comment 7•9 years ago
|
||
Eric: this bug is about channel bindings, which is separate (and standardized) from token bindings (new channel ID)
Comment 8•5 years ago
|
||
Any news on it?
Channel-Binding Support is important.
It is needed for SCRAM-SHA-XXX-PLUS variants
Linked to:
Comment 9•5 years ago
|
||
It is possible to change the "Milestone"?
It is a forgotten ticket I think...
Comment 10•5 years ago
|
||
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:
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:
Comment 11•4 years ago
|
||
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•2 years ago
|
||
It is official, it is here: RFC 9266: Channel Bindings for TLS 1.3:
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
Updated•2 years ago
|
Comment 13•2 years ago
|
||
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.
Updated•1 year ago
|
Comment 15•6 months ago
|
||
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
Description
•