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

[David Waite <[e-mail]>]

> On Dec 9, 2021, at 2:35 PM, Neil Madden <[e-mail]> wrote:
> 
> On 9 Dec 2021, at 20:36, Justin Richer <[e-mail] <mailto:[e-mail]>> 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.
> 
> 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