Subject: [OAUTH-WG] Proposed changes to RFC 8705 (oauth-mtls)

From: Dmitry Telegin <[email-masked]>
Date: Thu, 9 Dec 2021 16:23:16 +0300

There following changes to RFC 8705 have been proposed:
- introduce a new error code (e.g. "invalid_mtls_certificate") to be used
when the certificate is required by the AS/RS, but the underlying stack has
been misconfigured and the client didn't send one;
- for bound token use, change Authorization scheme from Bearer to MTLS;
- for token response returning a bound token, change token_type from Bearer
to MTLS

See discussion:
https://mailarchive.ietf.org/arch/msg/oauth/XfeH2q0Rwa2YocsR484xk-8LMqc/

Accepting the changes would imply a new RFC and the obsolescence of the
current one. Two questions so far:
- what's the group's general stance on this, would that be a welcome change?
- if so, could we also hear from the implementors if there any other issues
/ suggested changes.

Dmitry
Backbase / Keycloak

---

From: Warren Parad <[email-masked]>
Date: Thu, 9 Dec 2021 14:38:17 +0100

Could you share a bit about the security implications that precipitates
needing to change the token type. I.e. what's the attack vector that is
closed by adding this?

Warren Parad

Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress <https://authress.io/>.

On Thu, Dec 9, 2021 at 2:24 PM Dmitry Telegin <dmitryt=
[email-masked]> wrote:

> - for token response returning a bound token, change token_type from
> Bearer to MTLS
>
> See discussion:
> - if so, could we also hear from the implementors if there any other
> issues / suggested changes.
>
> Dmitry
> Backbase / Keycloak
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Neil Madden <[email-masked]>
Date: Thu, 9 Dec 2021 13:52:06 +0000

I don’t mind about a new error code, although I think it’s of limited value - error codes (rather than descriptive error *messages*) imply that the client may be able to dynamically react to the situation and so something different. But TLS client certs are usually configured statically, so it seems highly unlikely that the client could satisfy this requirement on its own. (Especially without all the other hints that would be missing from the TLS layer, like trusted CAs, supported signature algorithms, etc).

I am against changing the token type/scheme from Bearer to MTLS.  Mostly because of backwards compatibility issues - we already have customers that have deployed mTLS widely, but also because of conceptual issues I have generally with distinct token_type/schemes:

1. Whether an access token is mTLS-bound or a pure bearer token is a property of what the RS enforces, not intrinsic to the token. As far as I am aware, there is no spec anywhere that says what an RS should do if it doesn’t understand a particular confirmation method associated with an access token. So you can easily at present have a situation where an AT is valid at multiple RSes, some of which understand mTLS-binding and some of which do not. Indeed, this is very likely (and desirable) when you are in the process of rolling out stronger security mechanisms on an RS-by-RS basis. (And what if you later decide to move from mTLS to DPoP?) IMO requiring that ATs always have one and only one associated PoP mechanism is a recipe for ossification.

2. IMO the “token_type” and Authorization scheme should be primarily about how the AT itself is conveyed to the RS, not about how any associated proof is. Although “Bearer” is not the most appropriate name, I would rather we stuck to that one scheme for conveying ATs regardless of whether they are pure bearer tokens, bound tokens, or whatever. To me, the important part of “Bearer” is that it tells the RS that it can send this token directly to an introspection endpoint (or examine it locally) without first performing some additional processing on it.

3. I am generally in favour of allowing ATs to have 0, 1, 2 or any number of confirmation methods associated with them. If we want to make it easier for a client to figure out which ones an RS supports, I’d rather see this as an enhancement to the Bearer WWW-Authentication challenge - e.g. WWW-Authenticate: Bearer … supported_cnf_methods=mtls,dpop

Anyway, can of worms well and truly opened…

— Neil

> On 9 Dec 2021, at 13:23, Dmitry Telegin <dmitryt=[email-masked]> wrote:
> 
> - introduce a new error code (e.g. "invalid_mtls_certificate") to be used when the certificate is required by the AS/RS, but the underlying stack has been misconfigured and the client didn't send one;
> - for token response returning a bound token, change token_type from Bearer to MTLS
> 
> See discussion: https://mailarchive.ietf.org/arch/msg/oauth/XfeH2q0Rwa2YocsR484xk-8LMqc/ <https://mailarchive.ietf.org/arch/msg/oauth/XfeH2q0Rwa2YocsR484xk-8LMqc/>
> 
> Accepting the changes would imply a new RFC and the obsolescence of the current one. Two questions so far:
> - if so, could we also hear from the implementors if there any other issues / suggested changes.
> 
> Dmitry
> Backbase / Keycloak
>

---

From: Warren Parad <[email-masked]>
Date: Thu, 9 Dec 2021 15:10:18 +0100

This is a great answer.

Warren Parad

Founder, CTO

On Thu, Dec 9, 2021 at 2:52 PM Neil Madden <[email-masked]>
wrote:

> I don’t mind about a new error code, although I think it’s of limited
> value - error codes (rather than descriptive error *messages*) imply that
> the client may be able to dynamically react to the situation and so
> something different. But TLS client certs are usually configured
> statically, so it seems highly unlikely that the client could satisfy this
> requirement on its own. (Especially without all the other hints that would
> be missing from the TLS layer, like trusted CAs, supported signature
> algorithms, etc).
>
> I am against changing the token type/scheme from Bearer to MTLS.  Mostly
> because of backwards compatibility issues - we already have customers that
> have deployed mTLS widely, but also because of conceptual issues I have
> generally with distinct token_type/schemes:
>
> 1. Whether an access token is mTLS-bound or a pure bearer token is a
> property of what the RS enforces, not intrinsic to the token. As far as I
> am aware, there is no spec anywhere that says what an RS should do if it
> doesn’t understand a particular confirmation method associated with an
> access token. So you can easily at present have a situation where an AT is
> valid at multiple RSes, some of which understand mTLS-binding and some of
> which do not. Indeed, this is very likely (and desirable) when you are in
> the process of rolling out stronger security mechanisms on an RS-by-RS
> basis. (And what if you later decide to move from mTLS to DPoP?) IMO
> requiring that ATs always have one and only one associated PoP mechanism is
> a recipe for ossification.
>
> 2. IMO the “token_type” and Authorization scheme should be primarily about
> how the AT itself is conveyed to the RS, not about how any associated proof
> is. Although “Bearer” is not the most appropriate name, I would rather we
> stuck to that one scheme for conveying ATs regardless of whether they are
> pure bearer tokens, bound tokens, or whatever. To me, the important part of
> “Bearer” is that it tells the RS that it can send this token directly to an
> introspection endpoint (or examine it locally) without first performing
> some additional processing on it.
>
> 3. I am generally in favour of allowing ATs to have 0, 1, 2 or any number
> of confirmation methods associated with them. If we want to make it easier
> for a client to figure out which ones an RS supports, I’d rather see this
> as an enhancement to the Bearer WWW-Authentication challenge - e.g.
> WWW-Authenticate: Bearer … supported_cnf_methods=mtls,dpop
>
> On 9 Dec 2021, at 13:23, Dmitry Telegin <
> dmitryt=[email-masked]> wrote:
>

---

From: Justin Richer <[email-masked]>
Date: Thu, 9 Dec 2021 15:36:04 -0500

I disagree with this take. If there are confirmation methods at all, it’s no longer a Bearer token, and pretending that it is doesn’t help anyone. I think combining confirmation methods is interesting, but then you get into a weird space of how to define the combinations, and what to do if one is missing, etc. It opens up a weird space for interop problems. It’s not insurmountable, but I don’t think it’s a trivial as it might look at first.

Plus, the “backwards compatible” argument is what led to the existing RFC using Bearer again. In my view, this actually opens up the possibility of downgrade attacks against the RS, where a lazy RS doesn’t check the binding because it sees “Bearer” and calls it a day. The thing is, turning off that kind of checking is the kind of problem that fails open, like turning off XML signature validation in a SAML environment. The good assertions still pass, and bad assertions happen to also look fine. I don’t think that’s a good space to be in, and re-using “Bearer” like the existing spec does is a problem for that reason.

I would personally love to see a bis of this RFC, but because of inertia around existing deployments, I don’t expect it. I think we’d see a lot of confusion around which version of things to use.

 — Justin

> On Dec 9, 2021, at 8:52 AM, Neil Madden <[email-masked]> wrote:
> 
>> On 9 Dec 2021, at 13:23, Dmitry Telegin <dmitryt=[email-masked] <mailto:dmitryt=[email-masked]>> wrote:
>> 
>> [email-masked] <mailto:[email-masked]>

---

From: Warren Parad <[email-masked]>
Date: Thu, 9 Dec 2021 21:59:58 +0100

So if we are saying that it must be a different value than Bearer because
the RS can be lazy. Well the RS can be lazy even with MTLS and decide not
to validate, so having a different token type just adds complexity without
improving anything. I think we would need to justify a situation where an
RS can have both mTLS clients and non-mTLS clients and would need to know
whether or not to trust tokens coming from a particular client if that
client is using mTLS.

The problem with this is, the RS would need to start making decisions about
access control based on whether or not the client used mTLS to send the
request (otherwise accepting non-mTLS would prevent the benefit of ever
having mTLS). That leads to the issue of different levels of access control
that is not visible for the RS and clients by inspecting a request and/or
token
AND
The RS would need to know during requests whether or not mTLS was used.
That's just bonkers, no one is going to write a service to pass around a
magic flag just so they can do differentiated access control checks based
on whether mTLS was used.

If we want to signal that the token should be used with mTLS and not
without, that to me says "claim" as "*mtls: true"*. Further, Bearer says
"use this as is, it doesn't need to be modified", the token doesn't need to
be modified to use it with mTLS so Bearer is correct.

I really wish we would stop trying to create different token values for the
part of the Authorization header string that comes before the token. Having
DPoP token type is bothering me as well, do we need it there, probably not,
but that's not this discussion. At this point we should consider the
*token_type* functionality fundamentally broken, and realistically a
vestigial piece of OAuth that neither offers value nor should be reasonably
used for any purpose. If so desired, then let's put the mTLS signaling flag
as a claim where anyone and everyone can see it without having to magically
know what protocol was used to convey the HTTP message to the RS.

Warren Parad

Founder, CTO

On Thu, Dec 9, 2021 at 9:36 PM Justin Richer <[email-masked]> wrote:

> I disagree with this take. If there are confirmation methods at all, it’s
> no longer a Bearer token, and pretending that it is doesn’t help anyone. I
> think combining confirmation methods is interesting, but then you get into
> a weird space of how to define the combinations, and what to do if one is
> missing, etc. It opens up a weird space for interop problems. It’s not
> insurmountable, but I don’t think it’s a trivial as it might look at first.
>
> Plus, the “backwards compatible” argument is what led to the existing RFC
> using Bearer again. In my view, this actually opens up the possibility of
> downgrade attacks against the RS, where a lazy RS doesn’t check the binding
> because it sees “Bearer” and calls it a day. The thing is, turning off that
> kind of checking is the kind of problem that fails open, like turning off
> XML signature validation in a SAML environment. The good assertions still
> pass, and bad assertions happen to also look fine. I don’t think that’s a
> good space to be in, and re-using “Bearer” like the existing spec does is a
> problem for that reason.
>
> I would personally love to see a bis of this RFC, but because of inertia
> around existing deployments, I don’t expect it. I think we’d see a lot of
> confusion around which version of things to use.
>
>  — Justin
>

---

From: Neil Madden <[email-masked]>
Date: Thu, 9 Dec 2021 21:35:24 +0000

On 9 Dec 2021, at 20:36, Justin Richer <[email-masked]> wrote:
> Plus, the “backwards compatible” argument is what led to the existing RFC using Bearer again. In my view, this actually opens up the possibility of downgrade attacks against the RS, where a lazy RS doesn’t check the binding because it sees “Bearer” and calls it a day.

I think this actually strongly argues the opposite - it is precisely because the scheme is under attacker control that enables such downgrade attacks. So relying on the scheme to tell you what kind of PoP checks to apply makes these kinds of attacks more likely, not less. I’m suggesting instead that the RS decides what checks to enforce based on the “cnf” content in the token - which is either signed by the AS or retrieved directly from the AS through introspection. On the other hand, the token type is not even defined in the recent RFC 9068 for JWT-based ATs. So an attacker could easily change the scheme from MTLS to Bearer to see if the RS stops performing checks, but they can’t remove a “cnf” claim from the token itself.

In hindsight, “Bearer” might have been better named “AccessToken” or similar, but I don’t think the name matters as much as the semantics.

> The thing is, turning off that kind of checking is the kind of problem that fails open, like turning off XML signature validation in a SAML environment. The good assertions still pass, and bad assertions happen to also look fine. I don’t think that’s a good space to be in, and re-using “Bearer” like the existing spec does is a problem for that reason.
> 
>> On Dec 9, 2021, at 8:52 AM, Neil Madden <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>>

---

From: David Waite <[email-masked]>
Date: Thu, 9 Dec 2021 15:24:53 -0700

> On Dec 9, 2021, at 2:35 PM, Neil Madden <[email-masked]> wrote:
> 
> On 9 Dec 2021, at 20:36, Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
>> 

While I can’t speak for those involved, I suspect there was a desire to carry over OAuth 1 behavior with message signatures at the authorization level. That is to say, I suspect the name Bearer was to distinguish against say a PoP or HttpSig scheme.

In that light, I suspect the separation was not necessarily one trying to capture security semantics, but in understanding the format of the authorization header itself. A PoP scheme might include a signed challenge-response as a mandatory second parameter, or via wrapping the access token into a security structure such as a JWT. Neither of these would be valid for the Bearer authorization header, which is meant to convey an access token and provides for no additional parameters.

MTLS did not change the semantics of the bearer authorization header, since the format/meaning and validation of an access token has always been implementation-defined. Thus, a “MTLS” authentication scheme does not provide meaningful distinction, even ignoring the issues such distinction gives under an attacker model.

-DW

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 11 Dec 2021 17:29:12 -0800

<soapbox warning>

> be modified to use it with mTLS so Bearer is correct.

I can see how you might read Section 7.1 of RFC 6749 as saying that
"bearer" refers soley to "simply including the access token string in the
request".  But if you go follow the reference to RFC 6750, it's right there
in the abstract that:

   [...] Any party in
   possession of a bearer token (a "bearer") can use it to get access to
   the associated resources (without demonstrating possession of a
   cryptographic key).

I.e., if a token requires proof of possession of a cryptographic key in
order to use the token, it's not a bearer token.
So I really don't see any evidence to support a claim that the original
intent was for Bearer to be used even for PoP tokens.
That said...

> know what protocol was used to convey the HTTP message to the RS.

... this part may still be true, in practice, given the current deployed
reality.

-Ben

---

From: Warren Parad <[email-masked]>
Date: Sun, 12 Dec 2021 12:26:43 +0100

Point taken, although we can easily change the language of the original
RFC, what's more important is what we would want it to say, rather than
what it does say. I think in this case, it was an oversight to encourage
deployments to not add/require anything on top of the tokens. But now we
are in the place where we are saying, oh wait that advice was wrong,
deployments should add something on top, but here is what that is. That in
this instance should be the new recommendation.

If there is some technical reason that would break compliant deployments to
use the Bearer with DPoP or mTLS, then the reasonable thing to do, only in
that case, would be release a generic, but consistent, token type:
Bearer_v2. But as this is a requirement provided by RS after the AS
exchange, and the client has to already know about the need before ever
calling the AS if it wants the cfn populated, there is no reason to signal
back to the client nor convey this to the RS.

Warren Parad

Founder, CTO

---

From: Brian Campbell <[email-masked]>
Date: Wed, 22 Dec 2021 17:07:03 -0700

I'd concur with much of what DW said. Also, for what it's worth, RFC 8705
not introducing a new auth scheme or token type was due, in part, to the
hope/expectation that it'd allow for certificate-bound access token support
to be layered on top of existing systems without needing changes to the
software itself. From the deployments I've seen, I think that's played out
pretty well. It might be a little clumsy but the content of RFC 8705 is
intentional and was based on rough consensus. Updating/obsoleting an RFC is
a substantial endeavor with potentially significant and costly
ramifications. I don't see anywhere near sufficient justification to do so
in this case.

On Thu, Dec 9, 2021 at 3:25 PM David Waite <david=
[email-masked]> wrote:

> because it sees “Bearer” and calls it a day.
>
>
> I think this actually strongly argues the opposite - it is precisely
> because the scheme is under attacker control that enables such downgrade
> attacks. So relying on the scheme to tell you what kind of PoP checks to
> apply makes these kinds of attacks more likely, not less. I’m suggesting
> instead that the RS decides what checks to enforce based on the “cnf”
> content in the token - which is either signed by the AS or retrieved
> directly from the AS through introspection. On the other hand, the token
> type is not even defined in the recent RFC 9068 for JWT-based ATs. So an
> attacker could easily change the scheme from MTLS to Bearer to see if the
> RS stops performing checks, but they can’t remove a “cnf” claim from the
> token itself.
>
> In hindsight, “Bearer” might have been better named “AccessToken” or
> similar, but I don’t think the name matters as much as the semantics.
>
>
> While I can’t speak for those involved, I suspect there was a desire to
> carry over OAuth 1 behavior with message signatures at the authorization
> level. That is to say, I suspect the name Bearer was to distinguish against
> say a PoP or HttpSig scheme.
>
> In that light, I suspect the separation was not necessarily one trying to
> capture security semantics, but in understanding the format of the
> authorization header itself. A PoP scheme might include a signed
> challenge-response as a mandatory second parameter, or via wrapping the
> access token into a security structure such as a JWT. Neither of these
> would be valid for the Bearer authorization header, which is meant to
> convey an access token and provides for no additional parameters.
>
> MTLS did not change the semantics of the bearer authorization header,
> since the format/meaning and validation of an access token has always been
> implementation-defined. Thus, a “MTLS” authentication scheme does not
> provide meaningful distinction, even ignoring the issues such distinction
> gives under an attacker model.
>
> -DW

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