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

[M Hickford <mirth.hickford@gmail.com>]

On Thu, 28 Mar 2024 at 21:53, brian m. carlson
<sandals@crustytoothpaste.net> wrote:
>
> On 2024-03-28 at 08:00:00, M Hickford wrote:
> > 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.

Fantastic, thanks for considering this.

I look forward to sharing a test Git remote with OAuth DPoP when I can
figure out how.

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