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

[Warren Parad <[e-mail]>]

This is a great answer.

Warren Parad

Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress <https://authress.io/>.


On Thu, Dec 9, 2021 at 2:52 PM Neil Madden <[e-mail]>
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 <
> dmitryt=[e-mail]> 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:
> https://mailarchive.ietf.org/arch/msg/oauth/XfeH2q0Rwa2YocsR484xk-8LMqc/
>
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>