On Wed, Mar 23, 2022 at 5:01 PM Rohan Mahy <rohan.mahy= 40wire....@dmarc.ietf.org> 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= > 40pingidentity....@dmarc.ietf.org> 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= >> 40wire....@dmarc.ietf.org> 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 >>> OAuth@ietf.org >>> 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._
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
