Subject: [Unbearable] PR#54: TBPROTO-09: address implementation/api guidance

From: "Hodges, Jeff" <[email-masked]>
Date: Fri, 22 Jul 2016 09:26:43 +0000

Mike and I have crafted proposed text to resolve #53<https://github.com/TokenBinding/Internet-Drafts/issues/53> "add TB api guidance", as we agreed to do during the working group meeting on Tuesday.   It comprises a new short "Implementation considerations" section and an additional paragraph in the Privacy Considerations section, addressing the request by Stephen Farrell.

thoughts?

thanks, HTH,

=JeffH & Mike Jones

---

From: Leif Johansson <[email-masked]>
Date: Fri, 22 Jul 2016 12:44:10 +0200

On fre, 2016-07-22 at 09:26 +0000, Hodges, Jeff wrote:
> Mike and I have crafted proposed text to resolve #53 "add TB api
> guidance", as we agreed to do during the working group meeting on
> Tuesday.   It comprises a new short "Implementation considerations"
> section and an additional paragraph in the Privacy Considerations
> section, addressing the request by Stephen Farrell.
> 
> thoughts? 
> 
> thanks, HTH, 
> 
> =JeffH & Mike Jones
> 

Thx for this.

I'd like +1s or -1s (with some motivation preferably) from the WG!

---

From: Andrei Popov <[email-masked]>
Date: Fri, 22 Jul 2016 11:27:46 +0000

To restate my position on this, it is great to have API guidance, but TBPROTO is not the appropriate spec for it. TBPROTO describes the fundamental message formats for every kind of application and architecture, from self-contained apps to layered platforms. It's hard to come up with specific API guidelines that are generally applicable. My vote is to correct this text and put it in the OAUTHTB spec, which actually requires these APIs.

Here are the specific issues I have with the proposed text:
1.	“In addition to the functionality to use referred Token Binding IDs…” - the language focuses on the referred Token Bindings, but actually the application API would need to allow the use of any TB types (that the implementer is willing to support and expose), and most certainly provided ones.
2.	“Token Binding implementations providing an Application Programming Interface (API) should provide means for applications to produce Token Binding messages containing Token Binding IDs for application-specified TLS connections”- e.g. in the IDP-first scenarios, the TLS connection to the RP does not exist at the time its TB ID is used in TB messages. All the app can provide in this case is the target RP, or the TB key that will be used with this RP.
3.	“The application needs to be able to denote the Token Binding Type (e.g., provided, referred, etc.) of each specified connection as well as the TLS connection the application intends to send the Token Binding message over” – the API could accept the “TLS connection”, or it could accept the corresponding EKM value… in this low-level spec, we should not prescribe one API design. However, in a higher-level spec, specific API design may be welcome. Hence my preference that this would all be in OAUTHTB.
4.	“The application needs to be able to denote the Token Binding Type (e.g., provided, referred, etc.) of each specified connection…” – I can't parse this because there is no such thing as a "Token Binding Type of a TLS connection".
5.	“… as well as the TLS connection the application intends to send the Token Binding message over” – same comment as ## 2 and 3 above.
6.	“Additionally, the use of Token Binding IDs for other than the provided Token Binding Type gives communicating parties infomation about additional TLS connections of the application.” – apart from the typo, this is not the essence of the issue. The linkability issue exists when an app is able to query TBs that other apps may be using (of any type: provided, referred, ...) Such an app can correlate traffic. Further, depending on the API, such an app may be able to determine what target servers have been visited.
7.	“However, if not, then there is potential for exposing additional information and due caution should be exercised by the application” – this is not an actionable mitigation. Instead, this should be mitigated by isolating keys, as described in section 8.4. “Token Binding Key Sharing Between Applications”.

Cheers,

Andrei

-----Original Message-----
From: Unbearable [mailto:[email-masked]] On Behalf Of Leif Johansson
Sent: Friday, July 22, 2016 12:44 PM
To: Hodges, Jeff <[email-masked]>; Tokbind WG <[email-masked]>
Subject: Re: [Unbearable] PR#54: TBPROTO-09: address implementation/api guidance

Thx for this.

_______________________________________________
Unbearable mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/unbearable

---

From: William Denniss <[email-masked]>
Date: Fri, 22 Jul 2016 15:37:45 +0200

The HTTPS spec defines the header: "Sec-Token-Binding" which has options
for federated token binding.

Apps that use HTTPS, which includes Browsers, and other Native apps need to
be able to send the Sec-Token-Binding header with a referred token
binding.  That is, they need to be able to set the referred token binding
in the header.

The language in this PR should probably be moved to the HTTPS draft, as it
relates to how an HTTPS library would expose this functionality to native
apps (such as a browser).

On Fri, Jul 22, 2016 at 1:27 PM, Andrei Popov <[email-masked]>
wrote:

> To restate my position on this, it is great to have API guidance, but
> TBPROTO is not the appropriate spec for it. TBPROTO describes the
> fundamental message formats for every kind of application and architecture,
> from self-contained apps to layered platforms. It's hard to come up with
> specific API guidelines that are generally applicable. My vote is to
> correct this text and put it in the OAUTHTB spec, which actually requires
> these APIs.
>
> 1.      “In addition to the functionality to use referred Token Binding
> IDs…” - the language focuses on the referred Token Bindings, but actually
> the application API would need to allow the use of any TB types (that the
> implementer is willing to support and expose), and most certainly provided
> ones.
> 2.      “Token Binding implementations providing an Application
> Programming Interface (API) should provide means for applications to
> produce Token Binding messages containing Token Binding IDs for
> application-specified TLS connections”- e.g. in the IDP-first scenarios,
> the TLS connection to the RP does not exist at the time its TB ID is used
> in TB messages. All the app can provide in this case is the target RP, or
> the TB key that will be used with this RP.
> 3.      “The application needs to be able to denote the Token Binding Type
> (e.g., provided, referred, etc.) of each specified connection as well as
> the TLS connection the application intends to send the Token Binding
> message over” – the API could accept the “TLS connection”, or it could
> accept the corresponding EKM value… in this low-level spec, we should not
> prescribe one API design. However, in a higher-level spec, specific API
> design may be welcome. Hence my preference that this would all be in
> OAUTHTB.
> 4.      “The application needs to be able to denote the Token Binding Type
> (e.g., provided, referred, etc.) of each specified connection…” – I can't
> parse this because there is no such thing as a "Token Binding Type of a TLS
> connection".
> 5.      “… as well as the TLS connection the application intends to send
> the Token Binding message over” – same comment as ## 2 and 3 above.
> 6.      “Additionally, the use of Token Binding IDs for other than the
> provided Token Binding Type gives communicating parties infomation about
> additional TLS connections of the application.” – apart from the typo, this
> is not the essence of the issue. The linkability issue exists when an app
> is able to query TBs that other apps may be using (of any type: provided,
> referred, ...) Such an app can correlate traffic. Further, depending on the
> API, such an app may be able to determine what target servers have been
> visited.
> 7.      “However, if not, then there is potential for exposing additional
> information and due caution should be exercised by the application” – this
> is not an actionable mitigation. Instead, this should be mitigated by
> isolating keys, as described in section 8.4. “Token Binding Key Sharing
> Between Applications”.
>
> Cheers,
>
> Andrei
>
> To: Hodges, Jeff <[email-masked]>; Tokbind WG <[email-masked]
> >

---

From: Andrei Popov <[email-masked]>
Date: Fri, 22 Jul 2016 13:41:49 +0000

Ø  The language in this PR should probably be moved to the HTTPS draft, as it relates to how an HTTPS library would expose this functionality to native apps (such as a browser).
That would be an improvement over putting it in TBPROTO.

From: William Denniss [mailto:[email-masked]]
Sent: Friday, July 22, 2016 3:38 PM
To: Andrei Popov <[email-masked]>
Cc: Leif Johansson <[email-masked]>; Hodges, Jeff <[email-masked]>; Tokbind WG <[email-masked]>
Subject: Re: [Unbearable] PR#54: TBPROTO-09: address implementation/api guidance

The HTTPS spec defines the header: "Sec-Token-Binding" which has options for federated token binding.

Apps that use HTTPS, which includes Browsers, and other Native apps need to be able to send the Sec-Token-Binding header with a referred token binding.  That is, they need to be able to set the referred token binding in the header.

The language in this PR should probably be moved to the HTTPS draft, as it relates to how an HTTPS library would expose this functionality to native apps (such as a browser).

On Fri, Jul 22, 2016 at 1:27 PM, Andrei Popov <[email-masked]<mailto:[email-masked]>> wrote:
To restate my position on this, it is great to have API guidance, but TBPROTO is not the appropriate spec for it. TBPROTO describes the fundamental message formats for every kind of application and architecture, from self-contained apps to layered platforms. It's hard to come up with specific API guidelines that are generally applicable. My vote is to correct this text and put it in the OAUTHTB spec, which actually requires these APIs.

Cheers,

Andrei

-----Original Message-----
From: Unbearable [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Leif Johansson
Sent: Friday, July 22, 2016 12:44 PM
To: Hodges, Jeff <[email-masked]<mailto:[email-masked]>>; Tokbind WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Unbearable] PR#54: TBPROTO-09: address implementation/api guidance

Thx for this.

_______________________________________________
Unbearable mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/unbearable
_______________________________________________
Unbearable mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/unbearable

---

From: Brian Campbell <[email-masked]>
Date: Fri, 22 Jul 2016 15:45:42 +0200

I agree with William's characterization of this and think the guidance
belongs in HTTPSTB.

On Fri, Jul 22, 2016 at 3:41 PM, Andrei Popov <[email-masked]>
wrote:

> Ø  The language in this PR should probably be moved to the HTTPS draft,
> as it relates to how an HTTPS library would expose this functionality to
> native apps (such as a browser).
>
> *From:* William Denniss [mailto:[email-masked]]
> *Sent:* Friday, July 22, 2016 3:38 PM
> *To:* Andrei Popov <[email-masked]>
> *Cc:* Leif Johansson <[email-masked]>; Hodges, Jeff <
> [email-masked]>; Tokbind WG <[email-masked]>
>
> *Subject:* Re: [Unbearable] PR#54: TBPROTO-09: address implementation/api
> guidance
>
>
>
> Apps that use HTTPS, which includes Browsers, and other Native apps need
> to be able to send the Sec-Token-Binding header with a referred token

-- 
 <https://www.pingidentity.com>
<https://www.pingidentity.com>
Brian Campbell
Distinguished Engineer
[email-masked]
w: +1 720.317.2061
c: +1 303.918.9415
Connect with us: 
<https://www.glassdoor.com/Overview/Working-at-Ping-Identity-EI_IE380907.11,24.htm>
[image:
LinkedIn logo] <https://www.linkedin.com/company/21870> [image: twitter
logo] <https://twitter.com/pingidentity> 
<https://www.facebook.com/pingidentitypage> 
<https://www.youtube.com/user/PingIdentityTV> 
<https://plus.google.com/u/0/114266977739397708540> 
<https://www.pingidentity.com/en/blog.html>

---

From: Dirk Balfanz <[email-masked]>
Date: Fri, 22 Jul 2016 16:03:11 +0000

+1 to the language in the PR (modulo some nits below). Thanks for doing
this!

But like William, I wonder whether this belongs in the HTTPS draft. It says
that you're giving the API Considerations for apps that don't want to use
HTTPS, but really I think what you're trying to say is that you're giving
guidance for applications that use HTTPS, but that aren't browsers. After
all, we haven't specified anywhere how you would transport a Token Binding
message over anything other than HTTPS.

If you insist on leaving it in this doc, I would change the language to
something like:

<t><xref target="I-D.ietf-tokbind-https"/> gives guidance to User Agents
about the use of referred Token Binding IDs, but the
ability to provide referred and other Token Binding Types is also intended
to be made available to
applications not using <xref target="I-D.ietf-tokbind-https"/>.</t>

What do you think?

Dirk.

On Fri, Jul 22, 2016 at 3:38 PM William Denniss <[email-masked]> wrote:

>> 3.      “The application needs to be able to denote the Token Binding
>> Type (e.g., provided, referred, etc.) of each specified connection as well
>> as the TLS connection the application intends to send the Token Binding
>> 4.      “The application needs to be able to denote the Token Binding
>> Type (e.g., provided, referred, etc.) of each specified connection…” – I
>> can't parse this because there is no such thing as a "Token Binding Type of
>> a TLS connection".

---

From: Mike Jones <[email-masked]>
Date: Fri, 22 Jul 2016 16:25:22 +0000

Thanks, Andrei, William, Brian, and Dirk.  Reading all of your feedback, I think it makes sense to move the guidance to the HTTPS draft.  I’ll plan to work with Jeff to revise the pull request accordingly.

                                                       -- Mike

From: Unbearable [mailto:[email-masked]] On Behalf Of Dirk Balfanz
Sent: Friday, July 22, 2016 6:03 PM
To: William Denniss <[email-masked]>; Andrei Popov <[email-masked]>
Cc: Tokbind WG <[email-masked]>; Leif Johansson <[email-masked]>; Hodges, Jeff <[email-masked]>
Subject: Re: [Unbearable] PR#54: TBPROTO-09: address implementation/api guidance

+1 to the language in the PR (modulo some nits below). Thanks for doing this!

But like William, I wonder whether this belongs in the HTTPS draft. It says that you're giving the API Considerations for apps that don't want to use HTTPS, but really I think what you're trying to say is that you're giving guidance for applications that use HTTPS, but that aren't browsers. After all, we haven't specified anywhere how you would transport a Token Binding message over anything other than HTTPS.

If you insist on leaving it in this doc, I would change the language to something like:

<t><xref target="I-D.ietf-tokbind-https"/> gives guidance to User Agents about the use of referred Token Binding IDs, but the
ability to provide referred and other Token Binding Types is also intended to be made available to
applications not using <xref target="I-D.ietf-tokbind-https"/>.</t>

What do you think?

Dirk.

On Fri, Jul 22, 2016 at 3:38 PM William Denniss <[email-masked]<mailto:[email-masked]>> wrote:
The HTTPS spec defines the header: "Sec-Token-Binding" which has options for federated token binding.

Cheers,

Andrei

-----Original Message-----
From: Unbearable [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Leif Johansson
Sent: Friday, July 22, 2016 12:44 PM
To: Hodges, Jeff <[email-masked]<mailto:[email-masked]>>; Tokbind WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Unbearable] PR#54: TBPROTO-09: address implementation/api guidance

Thx for this.

---

From: [email-masked]
Date: Sat, 23 Jul 2016 02:54:26 -0600

Quoting Mike Jones <[email-masked]>:
> Thanks, Andrei, William, Brian, and Dirk.  Reading all of your  
> feedback, I think it makes sense to move the guidance to the HTTPS  
> draft.  I’ll plan to work with Jeff to revise the pull request  
> accordingly.

Yep, works for me.

=JeffH

---

From: Nick Harper <[email-masked]>
Date: Mon, 25 Jul 2016 15:21:15 -0700

I'm still concerned that the privacy concerns are not being addressed with
this proposal. Section 4.1 of the HTTPS draft states that the common idea
among the federation mechanisms is that the server signals to the client to
reveal its provided TBID to another server (with the
Include-Referred-Token-Binding-ID header being one such mechanism).
However, the wording in this pull request makes no indication that the use
of this API to set referred TBIDs would be limited to when the referring
server indicates to do so.

The new section in "Privacy Considerations" is missing some of the cases of
correlation that could happen. Suppose Example App decides to send a
referred TBID (for its connection to example.com) on every HTTPS request it
makes, and it happens to make requests to evil1.com and evil2.com (whose
operators are trying to correlate traffic between them). This referred TBID
is the same on both requests, and the site operators can now correlate
requests, whereas if the app didn't (mis)use the API for setting referred
TBIDs, the site operators wouldn't have been able to use Token Binding to
correlate the requests. I think this example contradicts the wording that
states "If the application is already aware of these other connections to
these endpoints, then no additional information is being exposed." In this
case, the application is aware of the connections (to evil1.com and
evil2.com), yet the referred TBIDs that it sends can be used for
correlation, which is additional information being exposed.

My preference is that this API guidance not be included in these drafts,
and that it can go in whichever draft defines an alternate mechanism for a
server indicating to the client to reveal its TBID to another server. I
also wouldn't mind the Privacy Considerations section reiterating the point
that a referred TBID should only be sent when indicated to do so by the
referring server.

On Sat, Jul 23, 2016 at 1:54 AM, <[email-masked]> wrote:

>> Thanks, Andrei, William, Brian, and Dirk.  Reading all of your feedback,
>> I think it makes sense to move the guidance to the HTTPS draft.  I’ll plan
>> to work with Jeff to revise the pull request accordingly.
>>
>
> Yep, works for me.
>
> =JeffH
>
>
>