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

[Brian Campbell <[e-mail]>]

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