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

Neil Madden <> Thu, 09 December 2021 21:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8D0FC3A0FDF for <>; Thu, 9 Dec 2021 13:35:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 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, 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 OEgLj-mRJ76m for <>; Thu, 9 Dec 2021 13:35:28 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::335]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 647983A0FDA for <>; Thu, 9 Dec 2021 13:35:28 -0800 (PST)
Received: by with SMTP id y196so5335386wmc.3 for <>; Thu, 09 Dec 2021 13:35:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=JogfgoaZwjWYJIO99LouTbbo8sOItBoPbAK4zMsfII0=; b=h6Kczy+MxJA8LGhnWWPODvPABfK9dSeGeh9Y79lhf2e6CbQYLehLpkUaBb06nUfC4B cI8rh3NWlSC/Yxks5rSx+fCNLwXFVEfsYQAE9zwyfKIIAq0HVtc/LUDdIIZlePV6pK5f H6KOd8k7dTnz1fx63MC8tpHzgpcMYF6XVZUQY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=JogfgoaZwjWYJIO99LouTbbo8sOItBoPbAK4zMsfII0=; b=ZZRvpWJ7p8Aqpg9coPqy178LVK57gVS3memHbZ4Ag9L5bmKrxv78OUKUd3nCPO4ufq BP/hE5OtoSVVl3CohKhJT9WpdCBwxvLyAbDGN8enXixdLR5URobGE7YgLb3xkQrXh0p1 BEm/kXDRI5QnAw29a1/96hPF8JIHsh5ZWw10v63lFCnZUiFg3F76DFB91qROi1LAxoCg 4B26Sl0aXkJMX3cL0/rJSGIYHfALfIxNEkiS2+WAQc8lOa5ViiLsCFKnd1oWP1hlTIbO OXlwxuONltHjZvfowNFNz3AohiBNhrVrVIrAHwf41Lc+fTP93C28h7mIVXoG9Hjw9H8R /ATA==
X-Gm-Message-State: AOAM533pcBhpykR+jhYWcxq3vL5sG3cCPz/w4THZJdijuXAmqM06vdcJ 5AU9BLIL3odkhCYlIIIdrA9OLg==
X-Google-Smtp-Source: ABdhPJxCb8+tHJOn9vY6M2cQSO+6gV4ANHgzu2goHcYAP7biYI0lhge2VODF8PComF5DGiVobxrZIQ==
X-Received: by 2002:a05:600c:4f8f:: with SMTP id n15mr10713838wmq.70.1639085726080; Thu, 09 Dec 2021 13:35:26 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id n1sm958532wmq.6.2021. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Dec 2021 13:35:25 -0800 (PST)
From: Neil Madden <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_DCF0A8BC-BC13-4FB0-B7F0-92013C021AFC"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
Date: Thu, 09 Dec 2021 21:35:24 +0000
In-Reply-To: <>
Cc: Dmitry Telegin <>, oauth <>
To: Justin Richer <>
References: <> <> <>
X-Mailer: Apple Mail (2.3608.
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 21:35:34 -0000

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.

> 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 < <>> 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
>> Anyway, can of worms well and truly opened…
>> — Neil
>>> On 9 Dec 2021, at 13:23, Dmitry Telegin < <>> wrote:
>>> 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: <>
>>> 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
>>> _______________________________________________
>>> OAuth mailing list
>>> <>
>>> <>
>> _______________________________________________
>> OAuth mailing list
>> <>