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

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 <jricher@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.ip@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 <bcampbell@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.ip@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
>
>
>