Subject: [GNAP] MTLS and GNAP

From: Tom Jones <[email-masked]>
Date: Tue, 8 Dec 2020 09:47:44 -0800

Before I pull the plug on this spec, I would like to check that my
understanding is correct.

Section 2.3.2 seems to say that the RC key used for signing is the TLS key.
IE token binding is built into the core of the spec.

I have made my feelings clear about token binding here
https://tcwiki.azurewebsites.net/index.php?title=Token_Binding

I will not use nor recommend the use of any spec that requires token
binding.

Peace ..tom

---

From: Justin Richer <[email-masked]>
Date: Tue, 8 Dec 2020 13:07:57 -0500

Hi Tom,

Your reading is partially correct but has several fundamental misconceptions that I hope I can help clear up. 

First: the key used is not assumed to always be the client software’s TLS key. Token binding is not required.

Most keep proofing methods, all defined in section 8, happen up at the application and HTTP layer. For these, you’d expect the key to be different from anything on the TLS layer. 

The one exception is the Mutual TLS key proofing method in section 8.3, but importantly, this does not use “token binding” in the way that your linked web page talks about and doesn’t use any of the token binding suite of TLS and HTTP extensions. It doesn’t require any special support in browsers or libraries. Instead, it works like the OAuth 2 Mutual TLS (RFC 8705) spec: the client simply presents its key at the TLS layer and presents the token at the application layer. Then it’s up to the AS or RS to determine if the presented token is tied to the same key used in TLS. This is a drastically simplified pattern compared to Token Binding and it’s seen success in deployments because of that.

The market failure of Token Binding, as referenced on your webpage, therefore has no bearing on the method used here.

And more importantly: support for multiple key proofing mechanisms is fundamentally important enough to this group that it’s in the charter several times as a major topic. MTLS makes sense for some deployments, and really doesn’t for others. For example if you’ve got browser-based client software, MTLS is a horrible choice for both support and usability. But if you’ve got tightly controlled back-end systems talking to each other, MTLS becomes a lot more reasonable. We see the same patterns and the need for choice in the OAuth world as well, and so mandating that everybody use one key proofing mechanism would be a deep failure of this protocol.

 — Justin

> On Dec 8, 2020, at 12:47 PM, Tom Jones <[email-masked]> wrote:
> 
> Before I pull the plug on this spec, I would like to check that my understanding is correct.
> 
> Section 2.3.2 seems to say that the RC key used for signing is the TLS key. IE token binding is built into the core of the spec.
> 
> I have made my feelings clear about token binding here https://tcwiki.azurewebsites.net/index.php?title=Token_Binding <https://tcwiki.azurewebsites.net/index.php?title=Token_Binding>
> 
> I will not use nor recommend the use of any spec that requires token binding.
> 
> Peace ..tom
> -- 
> TXAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/txauth

---

From: Fabien Imbault <[email-masked]>
Date: Tue, 8 Dec 2020 19:38:25 +0100

Hi there,

Please also keep in mind that section 8 is still to be investigated in
full. So in case you have different opinions, you'll be able to provide
your inputs.
It seems quite clear that different use cases (as documented on the wiki)
require different key proofing mechanisms, and the fact that GNAP makes it
flexible should ease your concerns.

Cheers
Fabien

On Tue, Dec 8, 2020 at 7:08 PM Justin Richer <[email-masked]> wrote:

> Hi Tom,
>
> Your reading is partially correct but has several fundamental
> misconceptions that I hope I can help clear up.
>
> Most keep proofing methods, all defined in section 8, happen up at the
> application and HTTP layer. For these, you’d expect the key to be different
> from anything on the TLS layer.
>
> The one exception is the Mutual TLS key proofing method in section 8.3,
> but importantly, this does not use “token binding” in the way that your
> linked web page talks about and doesn’t use any of the token binding suite
> of TLS and HTTP extensions. It doesn’t require any special support in
> browsers or libraries. Instead, it works like the OAuth 2 Mutual TLS (RFC
> 8705) spec: the client simply presents its key at the TLS layer and
> presents the token at the application layer. Then it’s up to the AS or RS
> to determine if the presented token is tied to the same key used in TLS.
> This is a drastically simplified pattern compared to Token Binding and it’s
> seen success in deployments because of that.
>
> The market failure of Token Binding, as referenced on your webpage,
> therefore has no bearing on the method used here.
>
> And more importantly: support for multiple key proofing mechanisms is
> fundamentally important enough to this group that it’s in the charter
> several times as a major topic. MTLS makes sense for some deployments, and
> really doesn’t for others. For example if you’ve got browser-based client
> software, MTLS is a horrible choice for both support and usability. But if
> you’ve got tightly controlled back-end systems talking to each other, MTLS
> becomes a lot more reasonable. We see the same patterns and the need for
> choice in the OAuth world as well, and so mandating that everybody use one
> key proofing mechanism would be a deep failure of this protocol.
>
>  — Justin
>
> Section 2.3.2 seems to say that the RC key used for signing is the TLS
> key. IE token binding is built into the core of the spec.
>