Hi, Sorry, I meant to type server-provided nonce or *server-validated* expiration.
Thank you for the pointer to the discussion about exp. Skimming the comments, the discussion seems oriented at what would be easy for the client, rather than a balance of implementable for both client and server. I will raise my concern that requiring the server to remember iat values for an ambiguous period of time is a security concern (resource exhaustion/DoS). I don't think this is wise, but if you still want to allow no server-nonce, and no exp, please include this attack in the security considerations. 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 Fri, Mar 25, 2022 at 2:27 AM Brian Campbell <bcampbell= [email protected]> wrote: > Hello Rohan, > > The ath claim value in the proof is always the hash of the access token > sent in the same request. > > A decision was made fairly early on to not use `exp` in the proof but > rather to rely on the proof's `iat` and give the server some discretion > around the window of acceptance. > https://github.com/danielfett/draft-dpop/issues/38 has some of the > discussion around that. There'd need to be a very compelling reason with WG > agreement to change something fundamental like that at this stage in the > document lifecycle. Note also that, in the context of the proof, the `exp` > value would be something that's set by the client. So it wouldn't be a > "server-provided explicit expiration time" that was in the prior suggested > text. > > Similarly, reorganizing the document is not to be undertaken lightly > especially at this point. > > > > On Fri, Mar 25, 2022 at 12:19 AM Rohan Mahy <rohan.mahy= > [email protected]> wrote: > >> 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= >> [email protected]> wrote: >> >>> >>> >>> On Wed, Mar 23, 2022 at 5:01 PM Rohan Mahy <rohan.mahy= >>> [email protected]> 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= >>>> [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.* >>>> >>>> >>> *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 [email protected] https://www.ietf.org/mailman/listinfo/oauth
