Subject: [Uta] Token Binding

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 11 Nov 2014 22:40:38 +0100

I was unable to attend the UTA meeting today but I had a chance to look
at the slides.

To my surprise I had to notice that the authors have re-created a number
of mechanisms we created in OAuth.

I am wondering whether the authors are aware of this or whether this
re-design (with just minor variations) is intentional.

In either case it isn't great and I encourage the authors to take a look
at already ongoing efforts.

Ciao
Hannes

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Tue, 11 Nov 2014 16:50:33 -0700

> at already ongoing efforts.

Well, OAuth is just Kerberos for the Web, right? ;-)

It *could* be (I haven't looked at the slides) that the same underlying 
pattern from Kerberos and OAuth/OAuth2 can be applied to UTA in new and 
different and interesting ways.

But in general I'd agree that it's a bit early to be building something 
completely new, given that OAuth is of recent vintage.

Peter

-- 
Peter Saint-Andre
https://andyet.com/

---

From: Watson Ladd <[email-masked]>
Date: Tue, 11 Nov 2014 16:36:26 -0800

> completely new, given that OAuth is of recent vintage.

What exactly is being copied? RFC 6749 doesn't provide a way to ensure
cookie stealing doesn't happen. Access tokens aren't bound, so a
mechanism needs to be provided to bind them. I don't see where the
conflict with OAuth is.

Sincerely,
Watson Ladd

>
> Peter
>
> --
> Peter Saint-Andre
> https://andyet.com/
>
> _______________________________________________
> Uta mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uta

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 12 Nov 2014 02:32:37 +0100

Watson,

> mechanism needs to be provided to bind them. I don't see where the

The work to look at is called 'proof-of-possession':
http://datatracker.ietf.org/wg/oauth/documents/

A good starting point is this document:
http://datatracker.ietf.org/doc/draft-ietf-oauth-pop-architecture/

Ciao
Hannes

---

From: Andrei Popov <[email-masked]>
Date: Wed, 12 Nov 2014 22:03:31 +0000

Hi Hannes,

Thanks for pointing out the specific documents that you have in mind.

Token Binding can be used with any application protocols that use security tokens, and OAuth is one example. We can certainly talk about the use of the Token Binding protocol with OAuth tokens.

Cheers,

Andrei

-----Original Message-----
From: Uta [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
Sent: Tuesday, November 11, 2014 3:33 PM
To: Watson Ladd; Peter Saint-Andre - &yet
Cc: [email-masked]
Subject: Re: [Uta] Token Binding

Watson,

Ciao
Hannes

---

From: Bodo Moeller <[email-masked]>
Date: Fri, 14 Nov 2014 10:03:23 +0100

Hannes Tschofenig <[email-masked]>:

> at already ongoing efforts.

Token Binding has different objectives and is located at a different level
(*between* TLS and HTTP authorization). Still it's reasonable to see if
mechanisms could be reused. (While draft-ietf-oauth-pop-architecture-00
does mention TLS channel binding support as one of the use cases for OAuth
proof-of-possession, I haven't been able to locate a specific mechanism
supporting that goal. Quite possibly I just didn't look at the right place
-- can you help?)

The Token Binding protocol (draft-popov-token-binding-00) inherently
depends on TSL but not on HTTP, so it's natural for it to be based on
TLS-style data structures (not JSON Web Tokens as in
draft-ietf-oauth-proof-of-possession-00). What else is there that you think
should be considered to avoid duplication?

I do have some complaints about draft-popov-token-binding-00
and draft-balfanz-https-token-binding-00, though, and possibly they just
aren't as clear as they should, thus making it harder to figure out these
things:

- draft-popov-token-binding-00 IANA Considerations register ALPN protocol
IDs such as "http/1.1_tb_p256", with "Specification: this document". In
reality, it appears that draft-balfanz-https-token-binding-00 specifies
these protocols (and should be requesting IANA registration), based on
draft-popov-token-binding-00. The relationship between the documents
appears convoluted: draft-balfanz-https-token-binding-00 shouldn't have to
be a normative reference in draft-popov-token-binding-00.

- draft-popov-token-binding-00 uses "application protocol messages" but
doesn't say what these are. (I think this refers to TLS application data,
but TLS application data is not structured into messages. Presumably the
idea is that the TLS-style token binding protocol message be prepended to
the TLS application data stream, but the specification needs to be more
explicit about that, and probably should show a concrete example.)

- draft-popov-token-binding-00 nominally specifies "The Token Binding
Protocol Version 1.0", but there's no indication of that version number in
the ALPN protocol registrations -- neither in the IDs (such as
"http/1.1_tb_p256") nor in the descriptions (such as "HTTP/1.1 with Token
Binding using ECDSA key and NIST P256 curve").

- draft-popov-token-binding-00 and draft-balfanz-https-token-binding-00
both include normative language saying that TLS extended master secrets are
required. This doesn't make sense. This should be normative only in
draft-popov-token-binding-00. (Also, it doesn't seem right to specifically
require the Extended Master Secret TLS *extension* as the documents do. If
a new version of TLS fixes the master secret computation without requiring
an extension for this, this unncessarily precludes using Token Binding with
that TLS version.)

- draft-popov-token-binding-00 should be clearer about what of it is a
framework that still needs to be instantiated and what of it is the actual
protocol. The actual "tokens" supposed to be bound feature in the
introduction and in the overview only: I haven't found guidance that says
explicitly that higher layers will have to do certain steps (with
illustrative examples?).

In short, if I didn't already have an idea of what these specifications are
all about, I'm not sure I could figure it out just from reading them.

So I'd suggest we first get these specifications cleared up significantly
before for start to look at the protocol mechanisms in detail.

Bodo

---

From: Bodo Moeller <[email-masked]>
Date: Fri, 14 Nov 2014 10:30:01 +0100

> explicit about that, and probably should show a concrete example.)

Um, no. I don't actually think that. This is one of the cases where
draft-popov-token-binding-00 might have to be clearer about what of it is a
framework to be instantiated at a higher level, and what is concrete. (Of
course, in the HTTP case, the application protocol message in question is
the HTTP request, which will contain the TokenBindingMessage in the
Token-Binding header field -- which arguably should be called
"Token-Bindings" because the TokenBindingMessage is a sequence of
TokenBinding messages.)

Bodo

---

From: Bodo Moeller <[email-masked]>
Date: Fri, 14 Nov 2014 10:48:14 +0100

Bodo