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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
