Subject: [OAUTH-WG] DPoP and MTLS - friends or foes?

From: Dmitry Telegin <[email-masked]>
Date: Fri, 12 Nov 2021 19:37:57 +0300

As an implementer of one binding mechanism (DPoP) for the AS (Keycloak)
that already features another (MTLS), I'm running into the question whether
we should allow those two to be used simultaneously (which could be of
course extrapolated to other hypothetical mechanisms). By "simultaneously"
I mean binding a single token using both methods given that the material
for both has been provided with the request.

I guess currently mutual exclusivity is implied. Though in theory the "cnf"
section of the AT could contain both "jkt" and "x5t#S256", the mechanisms
are using different values for "token_type" and authentication scheme
("DPoP" for DPoP, "Bearer" for MTLS, though the latter might change to
"MTLS" in the future) and we define no mechanism to combine them (could be
"Bearer+DPoP" or "DPoP+MTLS" for example, which would be valid as per RFCs
7230 and 7235).

I apologize if the question has been asked before; didn't find anything
relevant in the ML. The implementer of MTLS for Keycloak also voted for
mutually exclusive behavior.

- Dmitry
Backbase / Keycloak

---

From: Brian Campbell <[email-masked]>
Date: Fri, 12 Nov 2021 14:59:46 -0700

I think Neil commented once somewhere about maybe seeing value in both at
the same time. He's smarter than me so I don't like to contradict him. But
I've always thought of them as mutually exclusive. And
practically/pragmatically I think it really is one or the other.

On Fri, Nov 12, 2021 at 9:39 AM Dmitry Telegin <dmitryt=
[email-masked]> wrote:

> I guess currently mutual exclusivity is implied. Though in theory the
> "cnf" section of the AT could contain both "jkt" and "x5t#S256", the
> mechanisms are using different values for "token_type" and authentication
> scheme ("DPoP" for DPoP, "Bearer" for MTLS, though the latter might change
> to "MTLS" in the future) and we define no mechanism to combine them (could
> be "Bearer+DPoP" or "DPoP+MTLS" for example, which would be valid as per
> RFCs 7230 and 7235).
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> 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: Justin Richer <[email-masked]>
Date: Mon, 15 Nov 2021 11:18:52 -0500

I would expect them to be able to co-exist in an implementation, but not both be used on the same token. One of the implementations that I work on supports both DPoP and MTLS on access tokens (as well as bearer tokens), and we use metadata stored in the token objects to switch between these.

 — Justin

> On Nov 12, 2021, at 11:37 AM, Dmitry Telegin <dmitryt=[email-masked]> wrote:
> 
> As an implementer of one binding mechanism (DPoP) for the AS (Keycloak) that already features another (MTLS), I'm running into the question whether we should allow those two to be used simultaneously (which could be of course extrapolated to other hypothetical mechanisms). By "simultaneously" I mean binding a single token using both methods given that the material for both has been provided with the request.
> 
> I guess currently mutual exclusivity is implied. Though in theory the "cnf" section of the AT could contain both "jkt" and "x5t#S256", the mechanisms are using different values for "token_type" and authentication scheme ("DPoP" for DPoP, "Bearer" for MTLS, though the latter might change to "MTLS" in the future) and we define no mechanism to combine them (could be "Bearer+DPoP" or "DPoP+MTLS" for example, which would be valid as per RFCs 7230 and 7235).
> 
> I apologize if the question has been asked before; didn't find anything relevant in the ML. The implementer of MTLS for Keycloak also voted for mutually exclusive behavior.
> 
> - Dmitry
> Backbase / Keycloak
>

---

From: Neil Madden <[email-masked]>
Date: Mon, 15 Nov 2021 17:52:16 +0000

I’m not smart enough to remember in what context I might have said this, but I’d hazard a guess it was somehow related to service mesh. 

Generally, we allow both to be specified largely because of our support for macaroon access tokens: a proxy could transparently add a mtls binding (for ex) to an AT as a macaroon caveat. If it first had to check whether there was some other type of binding on it then that would make it more awkward.

So we have an implementation where there can be any number of bindings associated with an AT and we loop through the set of keys in the “cnf” object and ensure that each one is satisfied. (We also currently reject unrecognised confirmation methods, I believe - on the assumption that they are all critical. I think the specs are currently silent on what to do with an unrecognised “cnf” value). 

Macaroon ATs somewhat break the whole token_type field, as an AT can start off as a pure bearer token and later become bound by a caveat.

— Neil 

> On 12 Nov 2021, at 22:00, Brian Campbell <bcampbell=[email-masked]> wrote:
> 
> 
> I think Neil commented once somewhere about maybe seeing value in both at the same time. He's smarter than me so I don't like to contradict him. But I've always thought of them as mutually exclusive. And practically/pragmatically I think it really is one or the other.  
> 
>> On Fri, Nov 12, 2021 at 9:39 AM Dmitry Telegin <dmitryt=[email-masked]> wrote:
> 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._______________________________________________
> OAuth mailing list
> [email-masked]