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

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=
40alkaline-solutions.com@dmarc.ietf.org> wrote:

>
>
> On Dec 9, 2021, at 2:35 PM, Neil Madden <neil.madden@forgerock.com> wrote:
>
> On 9 Dec 2021, at 20:36, Justin Richer <jricher@mit.edu> 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
> OAuth@ietf.org
> 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._