Re: [OAUTH-WG] DPoP - Downgrades, Transitional Rollout & Mixed Token Type Deployments

[Brian Campbell <[e-mail]>]

The current draft (draft-ietf-oauth-dpop-01) does say that when a valid
DPoP proof is presented and refresh token is issued to a public client, the
refresh token must be bound to the DPoP key. So that part is already
covered in the document. And, for whatever it's worth, that pretty closely
mirrors how it works with MTLS, public clients, and RTs. If there are
specific suggestions as to how to make it more clear, they'd of course be
welcome.

The text in draft does need to be updated to better account/allow for, as
Justin said, the "AS could still decide to issue a Bearer token, using the
token_type field, for whatever policy reason." I'd sort of thought it
already did and it was the intent but, on reading again, there's definitely
some text that needs to be fixed. That should help better facilitate mixed
or rollout deployments by letting the AS decide to bind ATs or not based on
resource or scope requested or other policy.

Also to help facilitate mixed or rollout deployments, I'm not sure about
"An client should never send a DPoP [bound access] token as a Bearer
header."  Such a constraint could be put on the client but it seems
unhelpful. A bad acting client could easily ignore it and I'm not sure what
it accomplishes if/when followed. Following from
https://github.com/danielfett/draft-dpop/issues/58 the draft needs to be
updated to say explicitly that an RS supporting both Bearer and DPoP
schemes simultaneously needs to update its Bearer token evaluation
functionality so as to reject tokens that are dpop bound. But the draft
can't really impose anything on existing RSs supporting only Bearer (and
unaware of DPoP). And such RSs will most likely accept a DPoP bound AT when
send via the Bearer scheme (JWT says to ignore unrecognized claims,
introspection says other parameters might be present, and 6750 is basically
silent on the content of the AT, which is where the binding is carried).
This admittedly doesn't seem quite right. But there's nothing this draft
can realistically do about it. And I think it can help with mixed or
rollout deployments. Especially those where sufficient information about
what RS(s) the requested token is for are not available in the token
request for whatever reason. Currently the draft is silent about it and
maybe that's as it should be. But I'm suggesting in a few messages on this
thread that the definition of the DPoP token_type would prescribe sending
the access token with the DPoP authorization scheme in conjunction with the
DPoP header but also say that, if that was met with a 401 WWW-Authenticate:
Bearer challenge by a particular RS (or the client had prior such knowledge
about the RS), that the access token could be sent using the Bearer
authorization scheme.

It is correct that, as currently written in the draft, a public client with
a DPoP bound refresh token will have to use the same key for the lifetime
of the grant. That seemed like a good tradeoff vs. defining a mechanism for
key rotation for the public client refresh token case where two proofs (one
to verify the binding for the RT being sent and one to newly bind the RT
to) would be presented on refresh grant type request. I tend to think where
it is now hits the right balance in functionality and complexity. But if
there are strong beliefs otherwise, let's discuss the need and cost/benefit
and all that.



On Thu, Jun 11, 2020 at 1:26 AM Neil Madden <[e-mail]>
wrote:

> +1
>
> > On 11 Jun 2020, at 07:36, Torsten Lodderstedt <torsten=
> [e-mail]> wrote:
> >
> > I generally agree with the proposal, but I would suggest to limit it to
> public clients.
> >
> > In case of confidential clients, the refresh token is (via the
> client_id) already bound to the client’s secret(s) and those can be
> rotated. Additionally binding the refresh token to a DPoP key would limit
> it’s applicability w/o a benefit.
> >
> >> On 11. Jun 2020, at 01:35, Francis Pouatcha <[e-mail]> wrote:
> >>
> >>
> >> On Wed, Jun 10, 2020 at 4:32 PM Justin Richer <[e-mail]> wrote:
> >> What if we simply declare that refresh tokens are always bound to the
> DPoP key used to request them? Is there value in NOT binding the refresh
> token?
> >>
> >> Fully agree. I will add a refresh_token shall always be PoP bound.
> Independent of the type of PoP.
> >>
> >> As for access tokens, the way I read it, all of this is true:
> >>
> >> - The AS could still decide to issue a Bearer token, using the
> token_type field, for whatever policy reason.
> >> - A client getting back a Bearer token from a DPoP request would do
> Bearer headers.
> >> - A client getting a DPoP token from a DPoP request would do DPoP
> headers.
> >> - An client should never send a DPoP token as a Bearer header.
> >> - An RS should ALWAYS look for a DPoP binding signature from a DPoP
> scheme token. Missing that is an error.
> >>
> >> So if we just declare that a refresh token must always be DPoP bound
> when DPoP is used to request it and a refresh token is issued, then we’re
> in the clear here, as best as I can tell, and it allows the AS some
> flexibility.
> >>
> >> Some problems with this:
> >>
> >> 1) Pretty much every single OAuth client in the world ignores the
> “token_type” field. But clients being updated to support DPoP wouldn’t
> ignore it, so that’s probably ok.
> >> 2) If we wanted to make refresh token binding switchable we’d need a
> “refresh_token_type” field or similar, and the client would need to know
> how to understand it and deal with its absence (since most servers won’t
> send it).
> >> 3) This presumes the client will not rotate its key before using the
> refresh token. If it does it’ll have to do a whole new grant.
> >> 4) None of this prevents an RS from ignoring the DPoP signature, but I
> think that’s a separate problem.
> >> 5) It’s arguable that we’d want a client to be able to bind a NEW DPoP
> key during a refresh, using the old key as proof for the refresh token and
> the new key going forward. Is this a case we want to enable?
> >> Key rotation shall be handled separately from the refresh_token
> process. If a refresh_token is bound to a key, the client shall keep that
> key till the refresh_token is consumed. A key rotation process shall be
> designed such as to allow the key holder to keep obsolete keys for the
> completion of pending processes.
> >>
> >> — Justin
> >>
> >>>> On Jun 7, 2020, at 3:22 AM, Torsten Lodderstedt <torsten=
> [e-mail]> wrote:
> >>>
> >>> That’s correct for confidential clients.
> >>>
> >>> For a public client, the refresh token is just bound to the client id.
> DPoP allows binding to an ephemeral key pair for this kind of clients.
> >>
> >>
> >> --
> >> Francis Pouatcha
> >> Co-Founder and Technical Lead at adorys
> >> https://adorsys-platform.de/solutions/
> >
> > _______________________________________________
> > OAuth mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._