Subject: Re: [Unbearable] Referred token binding IDs

From: Brian Campbell <[email-masked]>
Date: Mon, 4 Apr 2016 07:57:46 -0300

+1 to HTTPSTB indicating that servers identified by IP addresses will get
keys scoped to that exact IP address.

On Mon, Mar 21, 2016 at 3:03 AM, Dirk Balfanz <[email-masked]> wrote:

>
> I'd say that servers identified by IP addresses will get keys scoped to
> that exact IP address - just like cookies. I think it belongs in HTTPSTB as
> a SHOULD for web browsers.
>
> Dirk
>

---

From: Brian Campbell <[email-masked]>
Date: Mon, 4 Apr 2016 08:42:39 -0300

On Tue, Mar 29, 2016 at 2:26 PM, Nick Harper <[email-masked]> wrote:

> On Tue, Mar 29, 2016 at 8:46 AM, =JeffH <[email-masked]>
> wrote:
>
>>
>> I was toying with a similar idea and it seemed to me that the set of TBIDs
>> conveyed in the TBMSG to whatever server could possibly grow unbounded...
>>
>> This won't grow more than whatever the browser's redirect limit is (in
> Chrome this is 20), since this would only apply for a single chain of
> redirects.
>

Still, a TokenBindingMessage with 20 TokenBindings could be rather large
(especially if some/many of the TokenBindingIDs are RSA keys) and enough to
cause or exacerbate issues with header size limits in some servers.

---

From: Brian Campbell <[email-masked]>
Date: Mon, 4 Apr 2016 11:53:31 -0300

(I said this in the meeting today too but was 1/2 way though writing this
when the meeting started so figured I'd just finish it and send anyway)

There's at least one flexibility mismatch that, I think, will be
unavoidable. An "IDP-initiated" or "unsolicited" SSO starts at the IDP and
delivers a federated token to the RP without the user/user agent previously
or recently interacting with RP.

So I don't know that it's possible to have an exact match between what's
possible at the different layers.  And I think I'm siding with Dirk,
Andrei, et al. here that a single referred TB is good enough. Some
deployments may have to adjust their flow to fit within that, if they wish
to leverage TB. But that should be a minority and I think that's okay.
Trying to accommodate a bunch of different use cases and flows of starting
at one place and ending at another will add a lot of complexity that I
don't think is worth it as it may impede implementation and significantly
expand the attack surface.

On Tue, Mar 29, 2016 at 1:30 PM, =JeffH <[email-masked]>
wrote:

> Andrei wrote:
> > If we wanted to short-circuit the return path, so that IDP2 can redirect
> > back to the RP, then indeed we’d need to convey TBID_RP to IDP2,
>
> given the flexibility extant in federation frameworks, not facilitating
> the above will yield a flexibility mismatch between the latter and
> tokbind-https.
>
> we /can/ say "that's the way it is, live with it", or we can work to
> address it.
>
> in any case, I've posted a plea for review & feedback to a federation
> deployment mailing list, we'll see whether they have any cycles to
> contribute.
>
>
> =JeffH
>
>
>
>
> _______________________________________________
> Unbearable mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/unbearable
>