ChannelID what specification is used

[Per Ahlbom]

I'm doing my master thesis about using fido U2F compared to other two factor authentications. The specification mention the ChannelID extension to provide extra security. The Yubicon developer page redirect to the wikipage of ChannelID :  https://en.wikipedia.org/wiki/Transport_Layer_Security_Channel_ID. The Wikipage reference the working draft http://tools.ietf.org/html/draft-balfanz-tls-channelid-01. The working draft says that it expired in 2013. 

So my questions are:

 Is there any new specification that describes the ChannelID in TLS?
 If not, why use a specification that is not finished?

--

Per Ahlbom
E-mail: per.wj...@gmail.com
Tel: 0702615439

[Dirk Balfanz]

Hi Per, 

the new spec that replaces ChannelID is called "Token Binding", and is in the process of being standardized by the IETF (https://datatracker.ietf.org/wg/tokbind/documents/).

It turns out that as far as FIDO is concerned, a Token Binding key or a ChannelID key are really the same thing: it's a public key that will be included in the client data and signed by the Authenticator. So while you're correct in pointing out that it's a bit weird that FIDO should reference a non-standard, other than changing a few words here and there I don't expect any changes to the FIDO specs once the Token Binding drafts have become standards.

Dirk.

[Fred Le Tamanoir (NEOWAVE.FR)]

Hi Dirk, 

thanx for your quick answer and thanx for all your amazing work related to TLS Channel ID.

I am very pleased with TLS Channel ID protection, at least on paper... but I suspect there is something wrong with its current use/implementation/association with FIDO U2F.

Are official Google authentication servers actually using TLS Channel ID when I am using a FIDO U2F token ?

Do you have a link to another FIDO U2F compatible authentication server/service with TLS Channel ID protection too ?

Thanx

--

Frederic 

[Per Ahlbom]

How is the token bound when FIDO is used. Is the token bound to the FIDO device or the web browser. If it is bound to the web browser how do FIDO handle that the user uses different browsers? 

--
You received this message because you are subscribed to the Google Groups "FIDO Dev (fido-dev)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fido-dev+u...@fidoalliance.org.
To post to this group, send email to fido...@fidoalliance.org.
Visit this group at https://groups.google.com/a/fidoalliance.org/group/fido-dev/.
To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/5a9f61fa-f85e-4f97-a9b0-32778508fde0%40fidoalliance.org.

[Juan Lang]

Hi Per,

TLS channel ID binding in U2F is described in the overview document, https://fidoalliance.org/specs/fido-u2f-v1.0-nfc-bt-amendment-20150514/fido-u2f-overview.html#man-in-the-middle-protections-during-authentication. The "token" in token binding replaces the "channel ID" in TLS channel ID.

I hope that helps. Let us know if you have more questions.

--Juan

To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/CAK2136_4s7DLe-2%3DSP5H%2BYz%3DFGj-rLczrJMDQKBk0gEvLojxpw%40mail.gmail.com.

[Per Ahlbom]

Sorry do not quiet understand how it works.

Suppose that I that I have registered my account from my home computer and then want to authenticate on my work computer how do the server know what channel id/token binding it should be using? If the token binding only exist between the home computers browser and the server should not the authentication be stopped because the token/channel id are wrong. If this is wrong how do the new browser know which channel id/ token it should use to avoid the failure?

[Fred Le Tamanoir]

Hi, Channel ID binding is a protection against MITM attacks. It is just used during an ongoing request, to verify that the server challenge is signed by the U2F device and returned using the same shared TLS session.

See "2. Phishing and MitM protection" on this page : https://developers.yubico.com/U2F/Protocol_details/Overview.html

To this day, 

- on the client side, it is compatible with chrome/chromium only

- on the server side, it is not used on already publicly deployed U2F compatible services, but it is activated on the google appspot demo (https://crxjs-dot-u2fdemo.appspot.com)

I do like this feature and I am trying to promote it everywhere but it seems rather hard to find a server side implementation, available on the shelf, to use it on your own server/services.

Gluu main developer recently had it on its roadmap (for a future release)

--

Fred