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

David Waite <> Thu, 09 December 2021 22:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8FFF93A11BA for <>; Thu, 9 Dec 2021 14:25:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ujkTfW77Nq_4 for <>; Thu, 9 Dec 2021 14:24:57 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A4C7F3A11B6 for <>; Thu, 9 Dec 2021 14:24:57 -0800 (PST)
Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by (Postfix) with ESMTPA id 4EFEB206DDC; Thu, 9 Dec 2021 22:24:54 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=dkim; t=1639088695; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=ZtgHKBmT11fO/3cIB+NGwlgl7xaOnclDaYuTRn9TX8o=; b=SMnvZtq0vbkoZm8Hob9Urj2IClIa08PrB4y2fGHf60dACVQyXB99TpiKp8eyTYLdTLUqzx NULMLtUhHJKHqPAMlhrIVOWaXHJOj7AthJsmVW6/yiXPHbGGQMH0tNHk8eniZXOw8hVJC2 UTXLor8q0pAkM84IGvRe7AftcclRIO8=
From: David Waite <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_C0BFAEFB-A336-4A6E-86B5-2A15D4BAE40B"
Mime-Version: 1.0
Date: Thu, 09 Dec 2021 15:24:53 -0700
In-Reply-To: <>
Cc: Justin Richer <>, oauth <>, Dmitry Telegin <>
To: Neil Madden <>
References: <> <> <> <>
Authentication-Results:; auth=pass
X-Spamd-Bar: /
Archived-At: <>
Subject: Re: [OAUTH-WG] Proposed changes to RFC 8705 (oauth-mtls)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 09 Dec 2021 22:25:03 -0000

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