Subject: [OAUTH-WG] MTLS vs. DPOP

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 7 May 2019 08:25:34 +0000

Hi all,

In the OAuth conference call today Vittorio mentioned that some folks are wondering whether DPOP is essentially a superset of MTLS and whether it makes sense to only proceed with one solution rather potentially two.

I was wondering whether others in the group have a few about this aspect?

Ciao
Hannes

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: George Fletcher <[email-masked]>
Date: Tue, 7 May 2019 10:12:54 -0400

I don't see them the same at all. With MTLS, the token is bound to the 
transport layer (and the key used to establish that encrypted 
connection). With DPOP, the token is bound to the private key known to 
the client.

To compromise an MTLS bound token the attacker has to compromise the 
private key. To compromise a DPOP bound token, depending on what HTTP 
request elements are signed, and whether the DPOP is managed as 
one-time-use etc, there are additional attacks. (Ducks head and waits 
for all the real security experts to prove me wrong:)

The deployment models are also different. With MTLS bound tokens the 
clients don't really have to know about the binding because it is 
established at the AS and the deployment of the service manages the cert 
used for the MTLS connection. This is simpler for client development 
(provided the environment is already set up for MTLS everywhere).

I'd strong encourage us to continue supporting both methods.

On 5/7/19 4:25 AM, Hannes Tschofenig wrote:
>
> Hi all,
>
> In the OAuth conference call today Vittorio mentioned that some folks 
> are wondering whether DPOP is essentially a superset of MTLS and 
> whether it makes sense to only proceed with one solution rather 
> potentially two.
>
> IMPORTANT NOTICE: The contents of this email and any attachments are 
> confidential and may also be privileged. If you are not the intended 
> recipient, please notify the sender immediately and do not disclose 
> the contents to any other person, use it for any purpose, or store or 
> copy the information in any medium. Thank you.
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Daniel Fett <[email-masked]>
Date: Tue, 7 May 2019 16:50:31 +0200

> connection). With DPOP, the token is bound to the private key known to

They are certainly not the same, and as you wrote further below, MTLS is
more secure. I also wouldn't call one of them the superset of the other one.

That said, they are similar in their functionality. One could, in
theory, use MTLS on the token endpoint and DPoP for the resource access
and vice-versa.

We could specify both, MTLS and DPoP in a single document. But I am not
sure what the added value of that would be.

Pending good arguments for a merge I would propose to continue the work
on both, MTLS and DPoP. They both have their merits.

- Daniel

---

From: Vittorio Bertocci <[email-masked]>
Date: Tue, 7 May 2019 08:44:36 -0700

To clarify, I wasn’t suggesting we drop one or the other. Both have their
merit and use cases, and both should be developed all the way to standard
IMO. But from some preliminary exploration, it seems unlikely that services
will adopt both at the same time. From the “pr” perspective, having a clear
_default_ answer to the question “how do I add sender constraint
capabilities to my service?” would greatly enhance the chances of getting
something out in the real world quickly, make it possible to interop and
iron out wrinkles, etc etc-
For the general developer populace, at this point “sender constraint”
remains something vaguely exotic and often decisions made on that (like the
ones on the implicit deprecation) are poorly received. Even the ones who
had exposure had been somewhat “burned” by how token binding is going, and
we are in need for something easy to grok and actionable to rekindle
interest IMO. The sooner we can get the concept mainstream the better.

On Tue, May 7, 2019 at 07:13 George Fletcher <gffletch=
[email-masked]> wrote:

> transport layer (and the key used to establish that encrypted connection).
> With DPOP, the token is bound to the private key known to the client.
>
> one-time-use etc, there are additional attacks. (Ducks head and waits for
> all the real security experts to prove me wrong:)
>
> ?
> In the OAuth conference call today Vittorio mentioned that some folks are
> wondering whether DPOP is essentially a superset of MTLS and whether it
> makes sense to only proceed with one solution rather potentially two.
>
> ?
>
> ?
> ?
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
>
> OAuth mailing [email-masked]://www.ietf.org/mailman/listinfo/oauth
>
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 7 May 2019 16:00:26 +0000

George,

> I don't see them the same at all. With MTLS, the token is bound to the transport layer (and the key used to establish that encrypted connection). With DPOP, the token is bound to the private key known to the client.

Strictly speaking both solutions tie the token to the public key and the client needs to demonstrate possession of the private key through some security protocol.

Ciao
Hannes

---

From: Brian Campbell <[email-masked]>
Date: Tue, 7 May 2019 11:18:21 -0600

Practically speaking there's the MTLS draft, which has been sent to the
IESG for publication, has commercial and opensource implementations as well
as production deployments, and is referenced by other prospective standards
and profiles. It's not uncommon to receive off list inquires about the
document status from people involved in those things asking when it will be
"finished". Which is to say that there's a good amount of interest from the
community at large in seeing the MTLS document go to RFC. And it's
relatively close to doing so (as these things go anyway). The DPoP
document, on the other hand, is currently an individual draft submission.
And while it has generated some good interest and discussion, it is only an
individual draft submission and carries the same authority as any other
individual draft submission (see
https://tools.ietf.org/html/draft-abr-twitter-reply-00 for example). I
believe that the MTLS draft should continue on the it's course. And am
interested in seeing where we can take the DPoP work and if the WG wants to
take it on.

Your point about the "PR" perspective is taken. And I probably shouldn't
even bring these up but that whole situation is exacerbated by the
expired/dormant WG documents like draft-ietf-oauth-token-binding and
draft-ietf-oauth-signed-http-request. Some organizations out there touting
their support for RFC 7800 as a complete solution in the
pop/sender-constrained space aren't helping matters either. So while I
think I hear what you are saying, I don't personally see much of anything
reasonable or actionable that can done about it.

On Tue, May 7, 2019 at 9:45 AM Vittorio Bertocci <Vittorio=
[email-masked]> wrote:

>> OAuth mailing [email-masked]://www.ietf.org/mailman/listinfo/oauth <https://www..ietf.org/mailman/listinfo/oauth>
>>
>>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._

---

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 7 May 2019 19:43:37 +0200

Hi, 

mTLS is dead simple to use, secure, is used and can be used on a broad basis (in contrast to the token binding stuff). I also like the fact it provides both client authentication and sender-constraining.

We started the work on DPoP for the simple reason that SPAs don’t work well with mTLS and we want to provide a solution with somehow limited capabilities, e.g. regarding replay protection (see DPoP introduction). 

If someone asks me for the default solution, it’s simple: use mTLS. And if you build a SPA and want to do really security sensitive things, implement your OAuth stuff and the RS interactions in the backend of your application. 

DPoP is in a really early stage, let’s see where it will go.

best regards,
Torsten. 

> On 7. May 2019, at 10:25, Hannes Tschofenig <[email-masked]> wrote:
> 
> Hi all,
>  
> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. _______________________________________________
> OAuth mailing list
> [email-masked]

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 7 May 2019 12:59:55 -0500

> draft-ietf-oauth-signed-http-request. Some organizations out there touting

I've forgotten the details of those two documents, but in the general case,
if there's a WG document that is no longer actively being worked on (or is
now believed to be a bad idea), the chairs can pretty easily get a new rev
posted that has a "tombstone" notice, like "this document is no longer
being worked on" or similar, which may help clarify the situation to
external parties without much investment on time or tooling.

-Ben

---

From: Karl McGuinness <[email-masked]>
Date: Tue, 7 May 2019 18:09:57 +0000

mTLS has significant challenges at scale in a multi-tenant SaaS deployment on public clouds using modern edge technologies/services.  Applications are increasingly being built using Function-as-a-Service/ephemeral workloads as well.  Additional complexity increases if you also want to support "bring your own CA”.

DPoP enables application level deployment model independent of how one’s edge or runtime is deployed/managed.  This is very valuable for SaaS providers.  We expect to eventually deploy a DPoP like solution for all client models and not just SPA. 

-Karl

> On May 7, 2019, at 10:43 AM, Torsten Lodderstedt <[email-masked]> wrote:
> 
> Hi, 
>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 7 May 2019 20:17:25 +0200

> Am 07.05.2019 um 20:09 schrieb Karl McGuinness <[email-masked]>:
> 

Can you please share the details of those challenges with us?

---

From: Karl McGuinness <[email-masked]>
Date: Tue, 7 May 2019 20:42:19 +0000

1) You often need to deploy your cloud edge load balancer in TCP mode and handle your own TLS termination if you want client authentication.
2) There are often many intermediates between your edge where client TLS is terminated and your actual service.  You need to forward cert context from the edge as protected headers to your AS.
3) It's not easy to use different trust roots per tenant for client authentication.  SNI is not supported as a selector via off the shelf solutions and requires a software defined network (SDN) solution.

On the FaaS side client complexity is there especially with OpenSSL bindings

1) https://medium.com/@vaneek/using-mutual-tls-authentication-in-a-serverless-world-3afd19a6fe70

-Karl

On May 7, 2019, at 11:17 AM, Torsten Lodderstedt <[email-masked]<mailto:[email-masked]>> wrote:

Am 07.05.2019 um 20:09 schrieb Karl McGuinness <[email-masked]<mailto:[email-masked]>>:

-Karl

On May 7, 2019, at 10:43 AM, Torsten Lodderstedt <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

best regards,
Torsten.

On 7. May 2019, at 10:25, Hannes Tschofenig <[email-masked]<mailto:[email-masked]>> wrote:

Hi all,

Ciao
Hannes

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. _______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

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

---

From: David Waite <[email-masked]>
Date: Tue, 7 May 2019 23:55:54 -0600

> On May 7, 2019, at 8:12 AM, George Fletcher <gffletch=[email-masked]> wrote:
> 
> To compromise an MTLS bound token the attacker has to compromise the private key. To compromise a DPOP bound token, depending on what HTTP request elements are signed, and whether the DPOP is managed as one-time-use etc, there are additional attacks. (Ducks head and waits for all the real security experts to prove me wrong:)

Both should wind up supporting either longer-term, issued keys or ephemeral keys - and either exportable or not.

Off the top of my head, if your application is compromised I can’t think of a difference in the kinds of abuse that could be performed with equivalent policies and key protections.

-DW

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 8 May 2019 09:32:46 +0200

Hi Karl,

> On 7. May 2019, at 22:42, Karl McGuinness <[email-masked]> wrote:
> 

I like that option since it gives end2end transport security for your application. Unfortunately, that’s not supported by all cloud platforms. 

> 2) There are often many intermediates between your edge where client TLS is terminated and your actual service.  You need to forward cert context from the edge as protected headers to your AS.

That’s certainly true. The mTLS implementations I know all support passing the certificate from the TLS handshake via header parameter. Brian Campbell wrote a draft about this topic for token binding (https://tools.ietf.org/html/draft-ietf-tokbind-ttrp), but conceptually the same holds true for mTLS. 

Clearly, authenticity and integrity of the request between proxy and consuming service must be ensured, TLS in conjunction with shared secrets or TLS Client authentication could be used for that purpose or even network mechanisms. 

> 3) It's not easy to use different trust roots per tenant for client authentication.  

That’s required if you use the PKI mode. I would recommend to use the self-signed mode (in combination with the optional_no_ca setting at your TLS terminating proxy), which does not require any trust root. Given you consider using DPoP, which uses raw keys, self-signed should be fine for you as well.  

> SNI is not supported as a selector via off the shelf solutions and requires a software defined network (SDN) solution.
> 

As far as I understand this article, it’s mainly about PKI. So again, use mTLS in conjunction with self-signed certs and optional_no_ca.

kind regards,
Torsten.  

> 
> -Karl
> 
>> On May 7, 2019, at 11:17 AM, Torsten Lodderstedt <[email-masked]> wrote:
>> 
>> 
>>

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 8 May 2019 08:15:49 +0000

Hi Ben,

> I've forgotten the details of those two documents, but in the general case, if there's a WG document that is no longer actively being worked on (or is now believed to be a bad idea), the chairs can pretty easily get a new rev posted that has a "tombstone" notice, like "this document is no longer being worked on" or similar, which may help clarify the situation to external parties without much investment on time or tooling.

When we started the work on the PoP tokens we were ahead of the OAuth deployment because many developers didn't see the need to switch from the bearer tokens to the proof-of-possession tokens. Hence, the work progressed very slowly.

Now, the situation has changed with OAuth being used in use cases where there are higher security concerns, for example in the financial sector.

There are, however, also technical challenges with the PoP token approach and we ran into one of them with the HTTP signing and also deployment challenges (see token binding). I believe many people want such a PoP solution but there are just cases where it does not work. For HTTP signing we have at least two solutions in the IETF right now, namely  https://tools.ietf.org/html/draft-ietf-oauth-signed-http-request-03 and https://tools.ietf.org/html/draft-cavage-http-signatures-11

DPoP does not address the issue of how the request from the Client to the RS is actually protected. It only hints to it. If you want to get this to work you have to use one of the above documents or come up with yet another method.

Additionally, DPoP overlaps an already existing working group item, which we had planned to sent to the IESG soon: https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-07
One of the differences between DPoP and PoP key distribution is the question whether the client always needs to demonstrate possession of the private to the AS. As you remember I took the action item to work on a formal analysis, which I posted to the list.

Why the extra DPoP functionality has not been incorporated into the already chartered working group item is not entirely clear to me.

Ciao
Hannes

---

From: Justin Richer <[email-masked]>
Date: Wed, 15 May 2019 21:07:07 +0000

For what it’s worth, if we think of things a little bit differently, we can support both types of key presentation and possession proofs in parallel. My thinking was that in both the MTLS and DPoP cases, the client proves that it has access to a key and then uses that key with the RS in the same way it uses it with the AS. The format of the key and its presentation mechanism differ, but otherwise there really are a lot of parallels. This is how I’ve been thinking of it in the XYZ project:

https://oauth.xyz/keys/

It’s still very-drafty at the moment, but it follows as an abstraction to this thinking. In XYZ this is a bit simplified because the client always starts at the backchannel endpoint (equivalent to the token endpoint). In OAuth2, this would happen during the call to the token endpoint, as in the DPoP and MTLS drafts.

— Justin

On May 7, 2019, at 4:25 AM, Hannes Tschofenig <[email-masked]<mailto:[email-masked]>> wrote:

Hi all,

Ciao
Hannes