Re: [OAUTH-WG] MTLS vs. DPOP

[Justin Richer]

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 
mailto:hannes.tschofe...@arm.com>> 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.

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. ___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] MTLS vs. DPOP

[Hannes Tschofenig]

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
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
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] MTLS vs. DPOP

[Torsten Lodderstedt]

Hi Karl,

> On 7. May 2019, at 22:42, Karl McGuinness  wrote:
> 
> 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. 

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.
> 
> 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

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  
>> wrote:
>> 
>> 
>> 
>>> Am 07.05.2019 um 20:09 schrieb Karl McGuinness :
>>> 
>>> 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”..
>> 
>> Can you please share the details of those challenges with us?
>> 
>>> 
>>> 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  
 wrote:
 
 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  
> 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.
> 
> 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. 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
 
 ___
 OAuth mailing list
 OAuth@ietf.org
 https://www.ietf.org/mailman/listinfo/oauth
>>> 
> 



smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing li

Re: [OAUTH-WG] MTLS vs. DPOP

[David Waite]

> On May 7, 2019, at 8:12 AM, George Fletcher 
>  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___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] MTLS vs. DPOP

[Karl McGuinness]

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 
mailto:tors...@lodderstedt.net>> wrote:



Am 07.05.2019 um 20:09 schrieb Karl McGuinness 
mailto:kmcguinn...@okta.com>>:

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”.

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


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 
mailto:tors...@lodderstedt.net>> wrote:

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 
mailto:hannes.tschofe...@arm.com>> 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.

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. ___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] MTLS vs. DPOP

[Torsten Lodderstedt]

> Am 07.05.2019 um 20:09 schrieb Karl McGuinness :
> 
> 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”.

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

> 
> 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  
>> wrote:
>> 
>> 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  
>>> 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.
>>> 
>>> 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. 
>>> ___
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>> 
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
> 


smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] MTLS vs. DPOP

[Karl McGuinness]

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  
> wrote:
> 
> 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  
>> 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.
>> 
>> 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. 
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] MTLS vs. DPOP

[Benjamin Kaduk]

On Tue, May 07, 2019 at 11:18:21AM -0600, Brian Campbell wrote:
> 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

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

> 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.

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] MTLS vs. DPOP

[Torsten Lodderstedt]

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  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.
>  
> 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. 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth



smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] MTLS vs. DPOP

[Brian Campbell]

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  wrote:

> 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  40aol@dmarc.ietf.org> wrote:
>
>> 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.
>>
>> ?
>>
>> 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.
>>
>> ___
>> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth 
>> 
>>
>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

-- 
_CONFIDENTIA

Re: [OAUTH-WG] MTLS vs. DPOP

[Hannes Tschofenig]

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


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
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] MTLS vs. DPOP

[Vittorio Bertocci]

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  wrote:

> 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.
>
> ?
>
> 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.
>
> ___
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] MTLS vs. DPOP

[Daniel Fett]

Am 07.05.19 um 16:12 schrieb George Fletcher:
> 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.

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


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] MTLS vs. DPOP

[George Fletcher]

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.


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.


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth