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

[Rohan Mahy <[e-mail]>]

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. 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."

Adding "(on the order of seconds or minutes)" would already be a big
improvement to what is in the document.

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.

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.*