Re: [PATCH 13/13] credential: add support for multistage credential rounds

From: brian m. carlson <sandals@crustytoothpaste.net>
Date: Mar 28, 2024, 21:53 UTC
Message-ID: <ZgXmxvRv0rNBKk5K@tapette.crustytoothpaste.net>
In-Reply-To: <CAGJzqsn4Lz1T=q8NHi7kHHRdYVXKCMPGVBGzkkvZA=P1O9HtUw@mail.gmail.com>

On 2024-03-28 at 08:00:00, M Hickford wrote:

Show 22 quoted lines

> Is this design sufficiently flexible for OAuth DPoP (RFC 9449), or at
> least to make it work in future?
> 
> OAuth 2.0 Demonstrating Proof of Possession describes "a mechanism for
> sender-constraining OAuth 2.0 tokens via a proof-of-possession
> mechanism on the application level. This mechanism allows for the
> detection of replay attacks with access and refresh tokens."
> https://www.rfc-editor.org/rfc/rfc9449.html
> 
> Popular hosts GitHub, GitLab, Bitbucket and Gitea already support
> OAuth. OAuth DPoP "provides a general defense in depth against the
> impact of unanticipated token leakage". Motivated by a 2022 GitHub
> attack involving stolen tokens
> (https://github.blog/2022-04-15-security-alert-stolen-oauth-user-tokens/),
> some hosts are already experimenting with it.
> https://lore.kernel.org/git/20230128142827.17397-1-mirth.hickford@gmail.com/
> 
> In particular, the http request has to include both Authorization and
> DPoP headers https://www.rfc-editor.org/rfc/rfc9449.html#name-the-dpop-authentication-sch.
> The latter depends on timestamp and a server-optional challenge in a
> DPoP-Nonce header.
> https://www.rfc-editor.org/rfc/rfc9449.html#name-resource-server-provided-no.

It will likely be sufficient with further extensions. Right now, we don't have a way to provide DPoP headers or send nonces to the client. However, there's no reason we cannot provide that functionality in the future via additional key/value pairs, in which case this design should be fine.

This would have been sufficient if the OAuth working group had not added extra additional headers that other authentication mechanisms would have simply put (and, honestly, should have been put) in the WWW-Authenticate and Authorization headers, but alas, we can't change it now.

Since I think this gets us at least part of the way where we need to be, I think we should be able to keep it for now and implement the extra support for DPoP later.

-- 
brian m. carlson (they/them or he/him)
Toronto, Ontario, CA