> On Dec 9, 2021, at 2:35 PM, Neil Madden <[email protected]> wrote:
>
> On 9 Dec 2021, at 20:36, Justin Richer <[email protected]
> <mailto:[email protected]>> 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
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
