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

Warren Parad <> Thu, 09 December 2021 21:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7FA0D3A0E76 for <>; Thu, 9 Dec 2021 13:00:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.088
X-Spam-Status: No, score=-2.088 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, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id m1HkvDLVU_M9 for <>; Thu, 9 Dec 2021 13:00:11 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::b36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BD3503A0E78 for <>; Thu, 9 Dec 2021 13:00:11 -0800 (PST)
Received: by with SMTP id 131so16658201ybc.7 for <>; Thu, 09 Dec 2021 13:00:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Geji1fCeGiAuSi9InO5pxGK6rM46Igj+lvbPZ/FyN3w=; b=LE0N29ZEXyazsLbl4bAfwapkObIilCZKUL8SCbDDZWc5vI00D2d20tni7ILeTxDfrE xCWnt2WiIdn9T5Fw+KyX+5erKgRs7FjRS4UmQJnjPv0XkUVY4FmR9dc11Et0CqkOzSJi CzugHmsuC2/5M4H7ID15wmjF59zNUDmuY206zmbvxBDcd5IWeJ7dKCKQQYdy8vmqOw8A FzDaN1IpEXJJgMpDECU1ShiVeQixb/tSQ5O8rUc8dqdnmXw4sY2bVJLWxFwcJmBbDdah JosOFx5R17MtyiDgNMSUrBs3UqivtRWNPZk8xRWaaoak4qIGHUqqArYHq1pkJUc2Uqqm DSBg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Geji1fCeGiAuSi9InO5pxGK6rM46Igj+lvbPZ/FyN3w=; b=q9HwmboL5XgztDstKgW/w78zKA6kii/gZIA4UnB52w9BCO1eDP+XHmDzSYpJhg9mfe 4BrUDGf8m6EZKvdnXr/Za1KukAsD8H89Q9AbkSBChvbov/Nm37bvgugZLwKE9ULB51FV xjYtx8+z6vJ9U3+FsJlbzDMb4ZvwH/dnJSuHyawVtDBKpppaGBNXAD6lYkDmvgph5+pF AMHgnmbr+SGYV0VCzqLzyU05uC5Gj/31/RLqhwoyGEZTS5DdocmI8LNzwuv/1K/hPyxA 5//d+DyZHOFK4zQsBxnjTEhdOuHvKv0/ywoIq5X58KffMeU6vzV14/iqnzu9n3qX+kxY mdXg==
X-Gm-Message-State: AOAM533O32ymqpHDtWr4h+aAe9C4R6FcICUyrryAXf9zRLVbXqshu/T/ IJNq6aeW+ntsi/8d7GqVrfnItcbLUPi8EAsvFARWL7LZLw==
X-Google-Smtp-Source: ABdhPJw9lLk8amGwHcHfnDhbdnBefutdaELD9GXcCFhWQmBlE9/k8JxR+pcS+YdHcacViezPQ+tlpupadONfkz1UDAY=
X-Received: by 2002:a25:8802:: with SMTP id c2mr8982339ybl.297.1639083609005; Thu, 09 Dec 2021 13:00:09 -0800 (PST)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Warren Parad <>
Date: Thu, 09 Dec 2021 21:59:58 +0100
Message-ID: <>
To: Justin Richer <>
Cc: Neil Madden <>, oauth <>, Dmitry Telegin <>
Content-Type: multipart/alternative; boundary="00000000000045b7f705d2bce400"
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:00:17 -0000

So if we are saying that it must be a different value than Bearer because
the RS can be lazy. Well the RS can be lazy even with MTLS and decide not
to validate, so having a different token type just adds complexity without
improving anything. I think we would need to justify a situation where an
RS can have both mTLS clients and non-mTLS clients and would need to know
whether or not to trust tokens coming from a particular client if that
client is using mTLS.

The problem with this is, the RS would need to start making decisions about
access control based on whether or not the client used mTLS to send the
request (otherwise accepting non-mTLS would prevent the benefit of ever
having mTLS). That leads to the issue of different levels of access control
that is not visible for the RS and clients by inspecting a request and/or
The RS would need to know during requests whether or not mTLS was used.
That's just bonkers, no one is going to write a service to pass around a
magic flag just so they can do differentiated access control checks based
on whether mTLS was used.

If we want to signal that the token should be used with mTLS and not
without, that to me says "claim" as "*mtls: true"*. Further, Bearer says
"use this as is, it doesn't need to be modified", the token doesn't need to
be modified to use it with mTLS so Bearer is correct.

I really wish we would stop trying to create different token values for the
part of the Authorization header string that comes before the token. Having
DPoP token type is bothering me as well, do we need it there, probably not,
but that's not this discussion. At this point we should consider the
*token_type* functionality fundamentally broken, and realistically a
vestigial piece of OAuth that neither offers value nor should be reasonably
used for any purpose. If so desired, then let's put the mTLS signaling flag
as a claim where anyone and everyone can see it without having to magically
know what protocol was used to convey the HTTP message to the RS.

Warren Parad

Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress <>.

On Thu, Dec 9, 2021 at 9:36 PM 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. 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
> _______________________________________________
> OAuth mailing list