Re: [OAUTH-WG] DPoP - new authorization scheme / immediate usability concerns

[John Bradley <[e-mail]>]

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=[e-mail]>:
>>
>>  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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]>
>>>> wrote:
>>>>
>>>>> Hi Filip,
>>>>>
>>>>> My attempts at responses to your questions/comments are inline:
>>>>>
>>>>> On Tue, Apr 14, 2020 at 2:14 AM Filip Skokan <[e-mail]> 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
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>>
>>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/oauth
>>
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth