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

U2F: Add TLS Channel ID Binding #160

Open
Fred2seul opened this Issue Feb 16, 2016 · 14 comments

Comments

Projects
None yet
4 participants
@Fred2seul

Fred2seul commented Feb 16, 2016

TLS Channel ID support is missing (Channel Binding)

Channel Binding is a great protection against MITM attack.
Implemeting TLS Channel ID binding is an official recommendation inside FIDO specifications (but not mandatory).

On the client Side there is a built-in support inside Chrome browser.
It would be great if Gluu can implement this protection. (This would make Gluu as the most secure FIDO U2F server implementation I know)

Overview

Search for "MitM protection" inside:
https://developers.yubico.com/U2F/Protocol_details/Overview.html
You can see that channel ID is part of the hashed info that is signed by the U2F device.
This is a really great way to reinforce the initial TLS Channel Binding protection that can be implemented outside FIDO U2F.

Official specification

Search for [SM-12] inside:
https://fidoalliance.org/specs/fido-u2f-v1.0-nfc-bt-amendment-20150514/fido-security-ref.html
It is not mandatory but makes a real difference regarding security.
(i.e. This option is activated for High Profile google users on their own authentication portal.)

Server Side

You can see the patches against OpenSSL to implement TLS channel ID here:

https://chromium.googlesource.com/chromium/deps/openssl/+/7e6e6256e2a7c6fd7530394a851c6c656829d00d/openssl/patches/channelid.patch

Frédéric Martin
System and Security Architect

@Fred2seul Fred2seul changed the title from TLS Channel ID support is missing to TLS Channel ID support is missing (Channel Binding) Feb 16, 2016

@nynymike nynymike added this to the CE 2.4.3 milestone Feb 16, 2016

@Fred2seul

This comment has been minimized.

Fred2seul commented Feb 18, 2016

Updated issue description text to add the link to openssl patch

@Fred2seul Fred2seul changed the title from TLS Channel ID support is missing (Channel Binding) to [FIDO U2F] TLS Channel ID support is missing (Channel Binding) Feb 22, 2016

@yurem yurem modified the milestones: CE 2.4.3, CE 2.4.5 Jul 19, 2016

@nynymike nynymike modified the milestones: CE 3.1.0, CE 3.0.0 Nov 29, 2016

@nynymike nynymike changed the title from [FIDO U2F] TLS Channel ID support is missing (Channel Binding) to U2F: Add TLS Channel ID Binding Nov 29, 2016

@nynymike nynymike modified the milestones: 3.2.0, CE 3.1.0 Apr 7, 2017

@willow9886 willow9886 modified the milestones: 3.2.0, CE 3.2.0 Apr 10, 2017

@nynymike nynymike modified the milestones: 4.0, 3.1.4 Jul 2, 2018

@yurem

This comment has been minimized.

Contributor

yurem commented Jul 30, 2018

TLS Channel ID is not widely supported even after 2 years:

  • Edge: not supported
  • Firefox: not supported
  • Safari: not supported

Moreover TLS Channel ID is not standardized yet. Only Google supports it. That's why there is reference in U2F client data.

Server side also should support it. There is the path for apache2. But it's not activated yet. And it's not provide Channel ID either via headers or environment variables. Hence we have no proper server side support yet,

Here is very interesting discussion in Chrome forum https://groups.google.com/a/chromium.org/forum/#!topic/net-dev/AjFQjBmaEQE It's looks like they are going to remove it support.

@nynymike

This comment has been minimized.

Contributor

nynymike commented Jul 30, 2018

Agreed, but support for this is important to FAPI certification.

@yurem

This comment has been minimized.

Contributor

yurem commented Jul 30, 2018

Instead of TLS Channel ID I offer to use Token Binding

@yurem

This comment has been minimized.

Contributor

yurem commented Jul 30, 2018

image

Here is what we can implement:

title Super Gluu with Token Binding support

Browser->RP: 1. Access resource (TB1)
RP->Browser: 2. Authentication Redirect
Browser->oxAuth: 3. Process AuthN & AuthZ (TB1+TB2)
note over oxAuth: 4. Store TB2 in session (we can get from Apache via Header)
oxAuth->Super Gluu: 5. Send Auth request (Push Message + TB2)
Super Gluu->oxAuth: 6. Sent auth response with cid_pubkey (TB2)
note over oxAuth: 7. Validate TB2 in session with hash of TB2 in Fido U2F auth reponse
note over oxAuth, Super Gluu: oxAuth send base64url encoding of the SHA-256 hash of a TB2
oxAuth->Browser: 8. Return code
note over RP: Request id_token with TB1 (openid-connect-token-bound-authentication)
@yurem

This comment has been minimized.

Contributor

yurem commented Jul 30, 2018

For adding token Token Binding support we have both sides:

  1. There is module which add to apache2 it support. I open issue to build it for CE.
  2. Chrome and Edge has support of it.
@yurem

This comment has been minimized.

Contributor

yurem commented Jul 30, 2018

Where is FAPI spec? There is no java library which support either Channel ID or Token Binding. There is approach which override system classes. But it's not very good to override java classes.

@yurem

This comment has been minimized.

Contributor

yurem commented Aug 14, 2018

We build CE 3.1.4 beta1 for Ubuntu 18.04. It has enabled token binding module. Now we can resume work on this issue

@yurem

This comment has been minimized.

Contributor

yurem commented Aug 14, 2018

BTW, In Fido 2.0 terminology (I can't find real spec for 2.0) there is reference about using Token Binding too

@nynymike

This comment has been minimized.

Contributor

nynymike commented Aug 14, 2018

Probably referencing the OpenID EAP WG: http://openid.net/wg/eap/

@yurem yurem modified the milestones: 3.1.4, 3.1.5 Aug 22, 2018

@yurem

This comment has been minimized.

Contributor

yurem commented Nov 29, 2018

I think we can close this issue because:

  1. There is no browser which supports it. Even Chrome developers are going to remove it experimental support of it.
  2. There is java libraries which supports it. Also apache2 not supports it.
  3. Token Binding can replace Channel ID and has bigger security protection.

Without browser, java, https proxies support we can add Channel ID support. I offer to move it to 4.0 or close it as Wontfix.

@nynymike

This comment has been minimized.

Contributor

nynymike commented Nov 29, 2018

Don't confuse id_token ssl bonding with FIDO...

@yurem

This comment has been minimized.

Contributor

yurem commented Dec 3, 2018

@nynymike why we need TLS Channel ID Binding ? There is no server/client /browser support of it?

@nynymike

This comment has been minimized.

Contributor

nynymike commented Dec 3, 2018

https://fidoalliance.org/specs/fido-u2f-v1.0-rd-20140209/fido-u2f-overview-v1.0-rd-20140209.pdf

6 Man-In-The-Middle Protections During Authentication
If a man-in-the-middle (MITM) tries to intermediate between the user and the origin during
the authentication process, the U2F device protocol can detect it in most situations.
Say a user has correctly registered a U2F device with an origin and later, a MITM on a
different origin tries to intermediate the authentication. In this case, the user’s U2F device
won’t even respond, since the MITM’s (different) origin name will not match the
Key Handle that the MITM is relaying from the actual origin. U2F can also be leveraged
to detect more sophisticated MITM situations as we shall see below.
As one of the return values of the U2F “sign” call, the browser returns an object which
contains information about what the browser sees about the origin (we will call this the
“client data” object). This “client data” includes:
a) the random challenge sent by the origin,
b) The origin host name seen by the browser for the web page making the
javascript call, and
c) [optionally] if the ChannelID extension to TLS is used, the connection’s channelID
public key.
The browser sends a hash of this “client data” to the U2F device. In addition to the hash
of the “client data”, as discussed earlier, the browser sends the hash of the origin and
the Key Handle as additional inputs to the U2F device.
When the U2F device receives the client data hash, the origin hash and the Key Handle
it proceeds as follows: If it had indeed issued that Key Handle for that origin the U2F device
proceeds to issue a signature across the hashed “client data” which were sent to it.
This signature is returned back as another return value of the U2F “sign” call.
The site’s web page which made the U2F “sign” call sends the return values – both the
“client data” the signature back to the origin site (or equivalently, relying party). On receiving
the “client data” and the signature, the relying party’s first step, of course, is to
verify that the signature matches the data as verified by the user’s origin-specific public
key. Assuming this matches, the relying party can examine the “client data” further to
see if any MITM is present as follows:
● If “client data” shows that an incorrect origin name was seen by the user
○ an MITM is present
○ (albeit a sophisticated MITM which had also intermediated the registration
and thus got the Key Handle issued by the U2F device to match the MITM’s
own origin name, and the MITM is now trying to intermediate an authentication.
As noted earlier, an MITM intermediating only at authentication time and
not at registration would fail since the U2F device would refuse to sign due to
origin mismatch with the Key Handle relayed from the original origin by the
MITM).

● else If “client data” shows a ChannelID OR origin used a ChannelID for the SSL
connection:
○ If ChannelID in “client data” does not match the ChannelID the origin used, an
MITM is present
○ (albeit a very sophisticated MITM which possesses an actual valid SSL cert
for the origin and is thus indistinguishable from an “origin name” perspective)
It is still possible to MITM a user’s authentication to a site if the MITM is
a) able to get a server cert for the actual origin name issued by a valid CA, and
b) ChannelIDs are NOT supported by the browser.
But this is quite a high bar.
An MITM case which the U2F device does NOT protect against is as follows: Consider
an online service or website which accepts plain password but allows users to self-register
and step up to U2F 2nd factor. An MITM with a different origin which is present between
the user and the actual site from the time of registration can register the U2F device
on to itself and not pass this registration to the actual origin, which would still see
the user as just needing a password. Later, for authentications, the MITM can accept
the U2F device and just do an authentication with password to the actual origin.
Assuming the user does not notice the wrong (different) origin in the URL, the user
would think they are logging in to the actual origin with strong authentication and are
thus very secure but in reality, they are actually being MITMed.

Page 12

@willow9886 willow9886 modified the milestones: 3.1.5, 4.0 Dec 6, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment