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= 40pingidentity....@dmarc.ietf.org> wrote: > > > 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
