I agree that without a tight binding between the RS and AS we need to revisit RS meta-data.
It is a can of worms however. On 4/17/2020 2:39 PM, Torsten Lodderstedt wrote: > I think the same is already true for mTLS. Solving it in an > interoperable way would require some metadata about RS and their > requirements re mTLS/DPoP. Shall we revitalize the idea of RS metadata? > >> Am 17..04.2020 um 17:37 schrieb George Fletcher >> <gffletch=40aol....@dmarc.ietf.org>: >> >> This brings up interesting rollout questions. Protecting just the >> refresh_token is easy and a useful security measure (especially if >> access tokens are short lived). However, once you start issuing DPoP >> bound access tokens to a client, it means ALL the endpoints that >> client invokes MUST understand DPoP and know what to do with the >> header. Depending on how many endpoints that is, spread across N >> teams (or even companies) this can be problematic. >> >> As much as I agree with Justin in regards to the security issues, it >> may not be possible to force all RPs to update at the same time. This >> is of course potentially solvable if the client uses unique access >> tokens per API endpoint AND the AS knows which endpoints support DPoP >> and which don't. The problem here is that this creates a >> tight-coupling between RP and AS (at least for the rollout period). >> >> On 4/17/20 11:25 AM, Filip Skokan wrote: >>> I completely agree Justin, as mentioned - i wondered a year ago, I don't >>> anymore. But i'd like it to be clear that sending a DPoP proof does not >>> necessarily mean the AS MUST issue a DPoP access token. Depending on the >>> AS/RS relationship and configuration a regular Bearer may be still be >>> issued and only the public client's refresh token would be constrained. >>> >>> Best, >>> *Filip* >>> >>> >>> On Fri, 17 Apr 2020 at 17:16, Justin Richer <jric...@mit.edu> wrote: >>> >>>> The idea of “Continuing to work without taking advantage of sender >>>> constraints” is, I would argue, a security hole. Systems are allowed to >>>> fail security checks but still offer functionality. This is exactly the >>>> pattern behind allowing an unsigned JWT because you checked the “alg" >>>> header and it was “none” and so you’re OK with that. Yes, you shouldn’t do >>>> that, but maybe we could’ve also made this more explicit within JOSE.. By >>>> using the ‘DPoP’ auth scheme, we’re making a clear syntactic change that >>>> says to the RS “either you know to look for this or you don’t know what it >>>> is”. >>>> >>>> It’s one of the problems I have with how the OAuth MTLS spec was written. >>>> By re-using the “Bearer” scheme there, I believe we’ve made a mistake that >>>> allows things to fall through in an insecure fashion. The same argument >>>> against it — ease of porting existing deployments — was raised there as >>>> well, and it won in the end. I hope we can do better this time. >>>> >>>> — Justin >>>> >>>> On Apr 16, 2020, at 4:05 AM, Filip Skokan <panva...@gmail.com> wrote: >>>> >>>> I'm still somewhat on the fence as to the pros and cons of using a new >>>>> token type and authorization scheme. But the draft has gone with a new >>>>> one. >>>>> Would it have really helped this situation, if it'd stuck with "bearer"? >>>>> Or >>>>> would it just be less obvious? >>>>> >>>> If we had stuck "bearer" than i wouldn't have raised this topic, since >>>> existing RS would most likely ignore the cnf claim and the resource server >>>> calls would continue to work, obviously without taking advantage of the >>>> available sender check. >>>> >>>> As I wrote the preceding rambling paragraph I am starting to think that >>>>> more should be said in the draft about working with RSs that don't support >>>>> DPoP. Which isn't really what you were asking about. But maybe would cover >>>>> some of the same ground. >>>> I agree. >>>> >>>> The AS is the one that does the binding (which includes checking the >>>>> proof) so I don't see how sending two proofs would really work or help the >>>>> situation? >>>> :facepalm: indeed, sorry. >>>> >>>> S pozdravem, >>>> *Filip Skokan* >>>> >>>> >>>> On Tue, 14 Apr 2020 at 23:39, Brian Campbell <bcampb...@pingidentity.com> >>>> wrote: >>>> >>>>> Hi Filip, >>>>> >>>>> My attempts at responses to your questions/comments are inline: >>>>> >>>>> On Tue, Apr 14, 2020 at 2:14 AM Filip Skokan <panva...@gmail.com> wrote: >>>>> >>>>>> I've wondered about the decision to use a new scheme before >>>>>> <https://github.com/danielfett/draft-dpop/issues/41#issuecomment-490096716> >>>>>> but >>>>>> this time i'd like to challenge the immediate usability of the future >>>>>> spec >>>>>> for one specific case - sender constraining public client Refresh Tokens. >>>>>> >>>>> I'm still somewhat on the fence as to the pros and cons of using a new >>>>> token type and authorization scheme. But the draft has gone with a new >>>>> one. >>>>> Would it have really helped this situation, if it'd stuck with "bearer"? >>>>> Or >>>>> would it just be less obvious? >>>>> >>>>> >>>>>> If at all, it is going to take time for RS implementations to recognize >>>>>> the new `DPoP` authorization scheme, let alone process it properly. In >>>>>> the >>>>>> meantime, i'd still like to have the option to bind issued public client >>>>>> refresh tokens using DPoP without affecting the access tokens. In doing >>>>>> so >>>>>> i get an immediate win in sender constraining the refresh tokens but not >>>>>> introducing a breaking change for the RS. >>>>>> >>>>>> >>>>>> - Do you see this as something an AS implementation is just free to >>>>>> do since it's both the issuer and recipient of a refresh token? >>>>>> >>>>>> That's my first thought, yes. >>>>>> - Should this be somehow baked in the draft? >>>>>> >>>>>> I'm not sure. Do you think it needs to be? I'm not sure what it would >>>>> say though. >>>>> >>>>> In such a case the AS could bind the RT to the given dpop proof and >>>>> either not bind the AT while returning token_type=Bearer or bind the AT >>>>> while returning token_type value DPoP. In the latter case the AT would >>>>> almost certainly still work as a bearer token at the RS and the client >>>>> that >>>>> knew the RS's needs could send it as such with an `Authorization: Bearer >>>>> <at>`. Or if it didn't know the RS's needs, it could start with >>>>> `Authorization: DPoP <at>` which would get a 401 with `WWW-Authenticate: >>>>> Bearer` at which point it could send `Authorization: Bearer <at>`. >>>>> >>>>> As I wrote the preceding rambling paragraph I am starting to think that >>>>> more should be said in the draft about working with RSs that don't support >>>>> DPoP. Which isn't really what you were asking about. But maybe would cover >>>>> some of the same ground. >>>>> >>>>> >>>>> >>>>>> - Do you think client registration metadata could be used to signal >>>>>> such intent? >>>>>> >>>>>> I think it certainly could. But it seems maybe too specific to warrant >>>>> metadata. >>>>> >>>>> >>>>>> - Do you think the protocol should have signals in the messages >>>>>> themselves to say what the client wants to apply DPoP to? >>>>>> >>>>>> My initial thought here is no. Take the case of a client working with an >>>>> AS that supports DPoP and one RS that does and one RS that doesn't. I >>>>> can't >>>>> really even think what signaling might look like there or how it could be >>>>> made to be generally useful. >>>>> >>>>> >>>>>> - What if AS and RS don't have a shared support DPoP JWS Algorithm? >>>>>> Do we disqualify such cases or allow for sending two proofs, one for >>>>>> the AS >>>>>> to bind refresh tokens to, one for the RS to bind access tokens to? >>>>>> >>>>>> The AS is the one that does the binding (which includes checking the >>>>> proof) so I don't see how sending two proofs would really work or help the >>>>> situation? >>>>> >>>>> >>>>> *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.* >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> >>>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
