Re: [OAUTH-WG] Comments on ietf-oauth-dpop

[Rohan Mahy <[e-mail]>]

Hi Brian,
1) Re: requiring a nonce or an expiration time, I'll propose some specific
text.
Section 4.2
insert after "* iat: Time at which the JWT was created (REQUIRED)."

"The DPoP proof MUST include either one or both of the following:
 * exp: time after which the proof is no longer valid.

* nonce: an Authorization Server-provided nonce as defined in Section 8."

Section 4.3, insert between steps 9 and 10:
"10.  if an exp claim is present, verify that it is in the future and that
the resulting
duration is acceptable to the server. A proof which contains neither an exp
claim nor a server-provided nonce is invalid;"

Renumber step 10 -> 11 and 11 -> 12.

2) Regarding linking Figure 5 and Figure 12, perhaps the simplest way to
make this linkage clear would be to move Section 7 and Section 7.1 in front
of Section 5.1, and then show the calculation of the hash:

"In our example, we take the value of the access_token in Figure 5:
   Kz~8mXK1EalYznwH-LC-1fBAo.4Ljp~zsPE_NeO.gxU
and calculate the base64 encoding of the SHA256:
   fUHyO2r2Z3DZ53EsNrWBb0xWXoaNy59IiKCAqksmQE "

One specific question which I could not find the answer to is if the token
has been refreshed, is the ath the hash of the original token or the
most-recent token?

Thanks,
-rohan

*Rohan Mahy  *l  Vice President Engineering, Architecture

Chat: @rohan_wire on Wire



Wire <https://wire.com/en/download/> - Secure team messaging.

*Zeta Project Germany GmbH  *l  Rosenthaler Straße 40,
<https://maps.google.com/?q=Rosenthaler+Stra%C3%9Fe+40,%C2%A0+10178+Berlin,%C2%A0+Germany&entry=gmail&source=g>10178
Berlin,
<https://maps.google.com/?q=Rosenthaler+Stra%C3%9Fe+40,%C2%A0+10178+Berlin,%C2%A0+Germany&entry=gmail&source=g>
Germany
<https://maps.google.com/?q=Rosenthaler+Stra%C3%9Fe+40,%C2%A0+10178+Berlin,%C2%A0+Germany&entry=gmail&source=g>

Geschäftsführer/Managing Director: Morten J. Broegger

HRB 149847 beim Handelsregister Charlottenburg, Berlin

VAT-ID DE288748675


On Thu, Mar 24, 2022 at 3:23 AM Brian Campbell <bcampbell=
[e-mail]> wrote:

>
>
> On Wed, Mar 23, 2022 at 5:01 PM Rohan Mahy <rohan.mahy=
> [e-mail]> wrote:
>
>> Hi Brian,
>>
>> To be clear, for pre-generated proofs, I am not worried about an attack
>> against the client; I am worried about a malicious client. Imagine a
>> malicious client which pre-generates proofs during a brief window while it
>> has access to a private key stored on the iOS secure enclave, or on a
>> Yubikey, or a non-extractable WebCryptoAPI CryptoKey. The ability to
>> pre-generate proofs with no lifetime effectively makes these
>> non-extractable key protections meaningless for some fixed number of proofs.
>>
>
> Direct usage of everything is also possible during that brief window. Yes,
> a nonce helps protect against usage after the window has closed. But it's
> not a panacea of protection. Which is, again, why it's an option provided
> by the draft to server implementations/deployments that need or want it.
> But not more.
>
>
>
>> If the WG does not want to make server nonces a SHOULD, then I suggest
>> the following:
>> "Server implementations need some protection against arbitrary
>> pre-generation. Servers MUST require all client proofs to contain either a
>> server-provided nonce, or a server-provided explicit expiration time, or
>> both."
>>
>
> I'm not sure what, other than a nonce, a "server-provided explicit
> expiration time" would be in the context of DPoP? Any
> recommendations/requirements the document makes need to be rooted in actual
> existing pieces of the protocol defined by that document.
>
>
>
>> Adding "(on the order of seconds or minutes)" would already be a big
>> improvement to what is in the document.
>>
>
> Will do. Thanks.
>
>
>
>> The linkage between Figure 12 and Figure 13 is clear. I was talking about
>> the linkage between Figure 5 (or the refresh response to Figure 6) and the
>> token hash in Figure 12.
>>
>
> The access token returned in Fig 5 is the same one used in Fig 12. But
> that it's in Fig 5 is not really meaningful to the ath or much else. I'm
> not sure what could be clarified or better linked?
>
>
>
>> Many Thanks,
>> -rohan
>>
>>
>> *Rohan Mahy  *l  Vice President Engineering, Architecture
>>
>> Chat: @rohan_wire on Wire
>>
>>
>>
>> Wire <https://wire.com/en/download/> - Secure team messaging.
>>
>> *Zeta Project Germany GmbH  *l  Rosenthaler Straße 40,
>> <https://maps.google.com/?q=Rosenthaler+Stra%C3%9Fe+40,%C2%A0+10178+Berlin,%C2%A0+Germany&entry=gmail&source=g>10178
>> Berlin,
>> <https://maps.google.com/?q=Rosenthaler+Stra%C3%9Fe+40,%C2%A0+10178+Berlin,%C2%A0+Germany&entry=gmail&source=g>
>> Germany
>> <https://maps.google.com/?q=Rosenthaler+Stra%C3%9Fe+40,%C2%A0+10178+Berlin,%C2%A0+Germany&entry=gmail&source=g>
>>
>> Geschäftsführer/Managing Director: Morten J. Broegger
>>
>> HRB 149847 beim Handelsregister Charlottenburg, Berlin
>>
>> VAT-ID DE288748675
>>
>>
>> On Wed, Mar 23, 2022 at 8:17 AM Brian Campbell <bcampbell=
>> [e-mail]> wrote:
>>
>>> Thanks Rohan,
>>>
>>> Pre-generating a proof requires the ability to execute code on the
>>> client, which is already a problematic situation where other (arguably
>>> more) serious attacks are possible. Such as driving a whole attack directly
>>> from the client. The draft aims to give servers the option to use a nonce
>>> but not push it too much or overstate its protections.
>>>
>>> The vagueness around lifetimes is somewhat intentional. At one point the
>>> document (maybe aspirationally) had something like 'no more than a few
>>> seconds' but there was some push-back that it was unrealistically short to
>>> accommodate real world client clock skew. I'm not sure the draft can make a
>>> much more concrete recommendation as I think it really is something that
>>> has tradeoffs and will be implementation/deployment specific. Perhaps
>>> something like, "(on the order of seconds or minutes)" could be added as a
>>> qualifier around lifetime leniency? That maybe gives a general idea of what
>>> is acceptable and/or relatively brief without being overly prescriptive.
>>> I'm quite hesitant to say anything more specific.
>>>
>>> An access token and its "ath" hash value are shown as part of the
>>> examples
>>> https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-06.html#figure-12
>>> and
>>> https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-06.html#figure-13
>>> respectively. Perhaps it'd be worthwhile to more explicitly mention the
>>> relationship between the two examples? I think I did the calculations
>>> correctly but anyone double checking that work would be welcome. The
>>> sentence in sec 4.3 step 11 is already pretty darn verbose - probably too
>>> much so. I think breaking it up would probably be a better way to make it
>>> more clear.
>>>
>>> The MIME type registration will be in the next revision
>>> https://mailarchive.ietf.org/arch/msg/oauth/Vj24ZXU4UuG6Rr04U1Cdrz2rx3o/
>>>
>>> I'll work those nits and fix things up as appropriate.
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Tue, Mar 22, 2022 at 4:24 PM Rohan Mahy <rohan.mahy=
>>> [e-mail]> wrote:
>>>
>>>> Hi,
>>>> Here are some comments on draft-ietf-oauth-dpop-06:
>>>>
>>>> 1) With such a significant attack possible as DPoP proof
>>>> pre-generation, why isn't using the server nonce a SHOULD? Preventing a
>>>> significant attack and making lifetime handling sane are two excellent
>>>> reasons to use a server nonce. If an implementation has a good reason to
>>>> not use a server nonce, we can give guidance about what additional steps
>>>> the implementation needs to take.
>>>>
>>>> 2) The handling of lifetimes of DPoP proofs is vague: "acceptable
>>>> timeframe" (Section 4.3), "relatively brief period" (Section 11.1). Is that
>>>> 1 day,15 minutes, or 30 seconds?
>>>> The normative text in the two sections seem contradictory.
>>>> I think you need a lifetime parameter if a server nonce isn't included,
>>>> or just pick a number (5 minutes?).
>>>>
>>>> 3) I had a similar thought to Nicolas Mora about including other
>>>> assertions/tokens. There should be a way to chain, include, or reference
>>>> other OAuth assertions and bind them somehow with the DPoP. This will be a
>>>> common and important model.
>>>>
>>>> 4. Right now you describe the access token hash before describing the
>>>> access token itself. I think it would be very useful to show the a worked
>>>> example of an access token and then its hash used subsequently. Also
>>>> Section 4.3 step 11 feels like a circular description. Please rewrite more
>>>> verbosely to be clearer:
>>>> Currently:
>>>> "when presented to a protected resource in conjunction with an access
>>>> token, ensure that the value of the ath claim equals the hash of that
>>>> access token and confirm that the public key to which the access token is
>>>> bound matches the public key from the DPoP proof."
>>>>
>>>> 5. Re: IANA registration of the MIME type. TL;DR: Just register
>>>> application/dpop+jwt.
>>>> Long version: The semantics of the thing you want to register is
>>>> application/dpop. The first syntax you are defining is jwt. For example,
>>>> iCalendar has three formats: text/calendar (iCal),
>>>> application/calendar+json (jCal), and application/calendar+xml (xCal).
>>>>
>>>> NITS:
>>>> - Spell out first use of acronyms: JWT, JWK, JWS, TLS, JOSE, PKCE,
>>>> - Add reference to TLS, XSS, Crime/Heartbleed/BREACH/etc., HTTP, JOSE,
>>>> on first use
>>>> - First sentence of Section 2 (Objectives): add a comma (access
>>>> tokens_,_ by binding) to make it clear that "binding a token" is doing the
>>>> preventing instead of the stealing in the sentence.
>>>> - Section 2 para 5: s/XXS/XSS/
>>>> - Maybe mention why you are using ASCII (7-bit) when the charset in the
>>>> examples is UTF-8.
>>>>
>>>> I hope these comments are useful.
>>>> Many thanks,
>>>> -rohan
>>>>
>>>>
>>>> *Rohan Mahy  *l  Vice President Engineering, Architecture
>>>>
>>>> Chat: @rohan_wire on Wire
>>>>
>>>>
>>>>
>>>> Wire <https://wire.com/en/download/> - Secure team messaging.
>>>>
>>>> *Zeta Project Germany GmbH  *l  Rosenthaler Straße 40,
>>>> <https://maps.google.com/?q=Rosenthaler+Stra%C3%9Fe+40,%C2%A0+10178+Berlin,%C2%A0+Germany&entry=gmail&source=g>10178
>>>> Berlin,
>>>> <https://maps.google.com/?q=Rosenthaler+Stra%C3%9Fe+40,%C2%A0+10178+Berlin,%C2%A0+Germany&entry=gmail&source=g>
>>>> Germany
>>>> <https://maps.google.com/?q=Rosenthaler+Stra%C3%9Fe+40,%C2%A0+10178+Berlin,%C2%A0+Germany&entry=gmail&source=g>
>>>>
>>>> Geschäftsführer/Managing Director: Morten J. Broegger
>>>>
>>>> HRB 149847 beim Handelsregister Charlottenburg, Berlin
>>>>
>>>> VAT-ID DE288748675
>>>> _______________________________________________
>>>> 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.*
>>
>>
> *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.*