Subject: Re: [Unbearable] Current implementations of token binding spec?

From: Brian Campbell <[email-masked]>
Date: Wed, 3 Aug 2016 09:50:25 -0600

Related to this, I submitted this pull request
<https://github.com/TokenBinding/Internet-Drafts/pull/58/files> for TBNEGO
to use 24 rather than TBD for the ExtensionType Value.

On Tue, Jun 21, 2016 at 3:13 PM, Andrei Popov <[email-masked]>
wrote:

> Hi Brian,
>
>
>
> Early assignment is available; please see attached.
>
>
>
> “24         token_binding (TEMPORARY - registered 2016-02-04, expires
> 2017-02-04)
>
> [draft-ietf-tokbind-negotiation]”
>
>
>
> Cheers,
>
>
>
> Andrei
>
>
>
> *From:* Unbearable [mailto:[email-masked]] *On Behalf Of *Brian
> Campbell
> *Sent:* Tuesday, June 21, 2016 1:48 PM
> *To:* Dave Tonge <[email-masked]>
> *Cc:* John Bradley <[email-masked]>; IETF Tokbind WG <
> [email-masked]>; Bill Cox <[email-masked]>
> *Subject:* Re: [Unbearable] Current implementations of token binding spec?
>
>
>
> In the implementations that are out there now, what value is being used to
> identify the token_binding ExtensionType? TBNEGO just has a TBD
> <https://tools.ietf.org/html/draft-ietf-tokbind-negotiation-02#section-2>
> right now. Is there any work underway towards getting early assignment of a
> ExtensionType Value for TB? Or is that even possible?
>
>
>
> On Tue, Jun 21, 2016 at 10:13 AM, Dave Tonge <[email-masked]>
> wrote:
>
> Thanks Bill and John
>
>
>
> Bill - looking forward to it, I'll give it a try when its released.
>
> John - I'll take a look at the test server in chromium.
>
>
>
> I'm keen to help push forward support, so please let me know if there is
> anything else I can to do to help.
>
>
>
> Thanks
>
>
>
> Dave
>
>
>
> On 21 June 2016 at 16:35, John Bradley <[email-masked]> wrote:
>
> Currently if you are brave, there is a Python test server as part of the
> Chromium project on Github for testing.
>
> https://github.com/chromium/chromium
>
>
>
> Last time I tried it you needed to checkout the whole project to get the
> test server to build.
>
> I think they are working on making that easier.
>
>
>
> Also as part of that project there is the Cronet http/TLS lib that can be
> used on iOS and Android.
>
>
>
> We are hoping to include that as an option in the AppAuth project for
> token binding refresh and access tokens on mobile.
>
>
>
> https://github.com/openid
>
>
>
> We are working/lobbying to get support included in more places such as
> Python and Java.
>
>
>
> I hope you can contribute to the WG and help us move this spec to a RFC
> quickly by showing demand.
>
>
>
> Regards
>
> John B.
>
>
>
>
>
> On Jun 21, 2016, at 10:55 AM, Dave Tonge <[email-masked]>
> wrote:
>
>
>
> Hi
>
>
>
> I'm currently working with the UK Open Banking Standard
> <https://github.com/OpenBankingStandard>and the OpenID Financial API WG
> <http://openid.net/wg/fapi/>.
>
> The issue of token binding is being discussed and I wanted to try out an
> actual real world implementation.
>
> After some research there don't seem to be many implementations in the
> wild (unless I've missed something).
>
>
>
> It is supported in Chrome, but doesn't seem to be supported in OpenSSL yet
> (and therefore not in Node.JS, Python, Ruby, etc.
>
> I've opened an issue on the OpenSSL repo:
> https://github.com/openssl/openssl/issues/1242
>
>
>
> Is my understanding correct? How would you recommend trying out a a live
> implementation of token binding?
>
>
>
> Thanks
>
>
>
> --
>
> *Dave Tonge*
>
> CTO
>
> 10 Temple Back | Bristol | BS1 6FL
>
> *t: *+44 (0)117 280 5120 <%2B44%20%280%29117%20280%205120>
>
> *m: *+44 (0)7577 815570 <%2B44%20%280%297577%20815570>
>
>
>
> Momentum Financial Technology Ltd is authorised and regulated by the
> Financial Conduct Authority (Register number *561538*). Registered in
> England & Wales, company registration number *06909772*. DISCLAIMER: This
> email (including any attachments) is subject to copyright, and the
> information in it is confidential. Use of this email or of any information
> in it other than by the addressee is unauthorised and unlawful. Whilst
> reasonable efforts are made to ensure that any attachments are virus-free,
> it is the recipient's sole responsibility to scan all attachments for
> viruses. All calls and emails to and from this company may be monitored and
> recorded for legitimate purposes relating to this company's business. Any
> opinions expressed in this email (or in any attachments) are those of the
> author and do not necessarily represent the opinions of Momentum Financial
> Technology Ltd or of any other group company.
>
> _______________________________________________
> Unbearable mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/unbearable
>
>
>
>
>
>
>
> --
>
> *Dave Tonge*
>
> CTO
>
> 10 Temple Back | Bristol | BS1 6FL
>
> *t: *+44 (0)117 280 5120 <%2B44%20%280%29117%20280%205120>
>
> *m: *+44 (0)7577 815570 <%2B44%20%280%297577%20815570>
>
>
>
> Momentum Financial Technology Ltd is authorised and regulated by the
> Financial Conduct Authority (Register number *561538*). Registered in
> England & Wales, company registration number *06909772*. DISCLAIMER: This
> email (including any attachments) is subject to copyright, and the
> information in it is confidential. Use of this email or of any information
> in it other than by the addressee is unauthorised and unlawful. Whilst
> reasonable efforts are made to ensure that any attachments are virus-free,
> it is the recipient's sole responsibility to scan all attachments for
> viruses. All calls and emails to and from this company may be monitored and
> recorded for legitimate purposes relating to this company's business. Any
> opinions expressed in this email (or in any attachments) are those of the
> author and do not necessarily represent the opinions of Momentum Financial
> Technology Ltd or of any other group company.
>
>
> _______________________________________________
> Unbearable mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/unbearable
>
>
>
>
> ---------- Forwarded message ----------
> From: Amanda Baber via RT <[email-masked]>
> To:
> Cc: "[email-masked]" <[email-masked]>, "
> [email-masked]" <[email-masked]>, "
> [email-masked]" <
> [email-masked]>
> Date: Fri, 5 Feb 2016 01:30:25 +0000
> Subject: [IANA #890903] Early code point assignment requests for
> "Transport Layer Security (TLS) Extensions" registry
> (draft-ietf-tokbind-negotiation)
> Hi all,
>
> IANA has made the following early allocation in the TLS ExtensionType
> Values registry, in accordance with RFC 7120:
>
> 24      token_binding (TEMPORARY - registered 2016-02-04, expires
> 2017-02-04)
> [draft-ietf-tokbind-negotiation]
>
> When the IESG notifies us that they've approved the document for
> publication, we'll update the reference and remove the "temporary" note. If
> the document hasn't been approved within roughly 60 days of the expiration
> date, we'll ask you whether you want to renew the allocation for one more
> year. (Early allocations can be renewed only once.)
>
> Best regards,
>
> Amanda Baber
> IANA Senior Specialist
> ICANN
>
> On Tue Feb 02 23:50:50 2016, [email-masked] wrote:
> >
> > The Tokbind WG would like to ask for an early allocation of an IANA
> > code point for the "TLS Extension for Token Binding Protocol
> > Negotiation" (
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-ietf-tokbind-&data=01%7c01%7cAndrei.Popov%40microsoft.com%7c5d373707b8d6408f00b908d32dcbf04f%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=HkYLjr%2bpZbts%2fdRKcXSeM1WdO74TsRZMA4bL2WBYlZ8%3d
> > negotiation-02 <
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-ietf-tokbind-&data=01%7c01%7cAndrei.Popov%40microsoft.com%7c5d373707b8d6408f00b908d32dcbf04f%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=HkYLjr%2bpZbts%2fdRKcXSeM1WdO74TsRZMA4bL2WBYlZ8%3d
> > negotiation-02>). This document defines a new TLS extension
> > "token_binding", which needs to be added to the IANA "Transport Layer
> > Security (TLS) Extensions" registry.
> >
> > Please note that this document also seeks to establish a registry for
> > identifiers of Token Binding key parameters entitled "Token Binding
> > Key Parameters" under the "Token Binding Protocol" heading. This new
> > registry is not part of the early assignment request.
> >
> > At this point, authors do not expect major changes in the "TLS
> > Extension for Token Binding Protocol Negotiation" specification. There
> > are at least two prototype implementations of this specification being
> > worked on (by Google and Microsoft). An early IANA code point
> > assignment would facilitate implementation and deployment experience
> > prior to the publication of the RFC.
> >
> > Regards
> > John Bradley
>
>
>
>
>