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= [email protected]> 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= > [email protected]> 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 >> [email protected] >> 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.*
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
