I think perhaps an assumption in the DPoP draft (and in the description of “jti” in RFC 7519) is that the server will maintain a single global list of recently used jti values to prevent replay, rather than maintaining a separate list per client. That could perhaps be spelled out more clearly in the draft, as I think the entropy discussions only really make sense in that context. If the RS instead maintains a separate list per client then a simple counter is sufficient.
— Neil > On 2 Dec 2020, at 15:17, Brian Campbell > <bcampbell=40pingidentity....@dmarc.ietf.org> wrote: > > The conversation at > https://github.com/danielfett/draft-dpop/pull/51#discussion_r332377311 > <https://github.com/danielfett/draft-dpop/pull/51#discussion_r332377311> has > a bit more of the rational behind the choice of 96 bit minimum. > > On Wed, Dec 2, 2020 at 7:07 AM Denis <denis.i...@free.fr > <mailto:denis.i...@free.fr>> wrote: > Hi Daniel, > > All your arguments make sense. I agree. > > A minor point however. The size of the jti" is currently mandated to 96 bits > minimum. This is unnecessarily long for a time window of a few minutes. > The jti" does not need to be a unique identifier valid for ever. It can > simply be an identifier used during the time window which complements the > "iat" claim. > > Using both the "iat" claim and a 32 bits pseudo-random number will be quite > sufficient. It is also has the advantage of using less memory and > it is easier to flush the entries looking at the 32 first bits only. > > Denis > >> So what you are proposing is that the time window in which an RS accepts the >> DPoP proof is defined by the expiration time of the access token? >> >> DPoP proofs are intended to be generally be short-lived and fresh for each >> request in order to provide some level of replay protection. There is no >> point in making the time window as long as the (typically longer) time >> window in which an AT would be accepted. A DPoP proof that is valid for 12 >> hours would not provide much replay protection. >> >> The time window is left unspecified because it is only meant to account for >> clock differences and network latency. Its precise value can depend on >> deployment considerations. It is not intended to give the client an option >> to re-use proofs, which is prevented together with the jti. >> >> Also this would introduce new, unwanted and potentially surprising >> dependencies between token lifetimes and the DPoP usage. >> >> And finally, as discussed before, not all access tokens are JWTs and we are >> not going to mandate JWT access tokens in this spec. >> >> -Daniel >> >> >> Am 01.12.20 um 09:54 schrieb Denis: >>> Hi Brian, >>> >>>> Hi Denis, >>>> >>>> The choice to use "iat" vs. "exp" was made in the summer of last year. You >>>> can see some of the discussion from then in >>>> https://github.com/danielfett/draft-dpop/issues/38 >>>> <https://github.com/danielfett/draft-dpop/issues/38>. >>>> I believe it pretty well has consensus at this point and thus unlikely to >>>> be changed. >>> I fear that you misread my email or read it too fast. My point had nothing >>> to do whether using either of "iat" or "exp" in the DPoP proof JWT sent by >>> the client. >>> >>> The first sentence of my email was: "One comment on slide 5 about the time >>> window". So the topic was all about how the RS SHALL handle the "jti" claim >>> included >>> in the DPoP proof JWT when using a time window. >>> >>> >>>> While I do believe there are reasonable arguments that can be made on both >>>> sides of using either of "iat" or "exp", it's difficult (and honestly time >>>> consuming and very frustrating) to try and have such discussions or even >>>> respond in a coherent way when fundamental aspects of the draft are >>>> misrepresented or misunderstood. For example, the DPoP proof JWT is >>>> created by the client not the AS so the advantages you put forward are >>>> nonsensical in the context of the actual workings of the draft. >>> Section 8.1 addresses the topic of the time window, but this topic should >>> not only be addressed in the "Security Considerations" section >>> but in the main body of the document, since some checks MUST be done by the >>> RS. "Security Considerations"are intended to provide >>> explanations but are not intended to be normative. >>> >>> Section 8.1 states: >>> >>> " If an adversary is able to get hold of a DPoP proof JWT, the adversary >>> could replay that token at the same endpoint (the HTTP >>> endpoint and method are enforced via the respective claims in the JWTs). >>> To prevent this, servers MUST only accept DPoP proofs >>> for a limited time window after their "iat" time, preferably only for a >>> relatively brief period. >>> >>> Servers SHOULD store, in the context of the request URI, the "jti" value >>> of each DPoP proof for the time window in which the respective >>> DPoP proof JWT would be accepted and decline HTTP requests to the same >>> URI for which the "jti" value has been seen before. In order >>> to guard against memory exhaustion attacks a server SHOULD reject DPoP >>> proof JWTs with unnecessarily large "jti" values or store only >>> a hash thereof. >>> >>> (...) ". >>> >>> The previous text makes the assumption that RSs MUST only accept DPoP >>> proofs for a relatively brief period after their "iat" time included >>> in the DPoP proof JWT. This assumption is rather restrictive. A client >>> might get an access token and associate it with DPoP proof JWT that >>> could be used during, e.g., 12 hours. A DPoP proof JWT/ access token JWT >>> pair could thus be used by a client during, e.g., one day for >>> several sessions with a RS. >>> >>> The time window is currently left at the discretion of each RS and is >>> supposed to be short (without stating explicitly what "short" may mean).. >>> >>> It would be possible to mandate in the JWT the inclusion of the exp >>> (Expiration Time) Claim. (I am not advocating the inclusion of the "exp" >>> claim in the DPoP proof JWT). >>> >>> In this way, for a RS, the time window would be defined using the "iat" >>> claim defined in the DPoP proof JWT and the "exp" claim defined in >>> the JWT. >>> >>> Such a description should not be done in section 8, but in a section >>> earlier in the main body of the document. >>> >>> This would have the following advantages: >>> >>> The RS would be able to better manage the "jti" claim values, because it >>> would be able to discard "jti" claim values as soon as they are >>> outside the time window as defined above. >>> The client would know whether a DPoP proof JWT/ access token JWT pair is >>> still usable, in particular using the "expires_in" status code >>> returned in case of a successful response from the AS and is thus unlikely >>> to get a rejection of both of them because of an unknown time >>> window used by a RS. >>> Denis >>> >>> >>>> >>>> On Mon, Nov 30, 2020 at 8:45 AM Denis <denis.i...@free.fr >>>> <mailto:denis.i...@free.fr>> wrote: >>>> One comment on slide 5 about the time window. >>>> >>>> At the bottom, on the left, it is written: "Only valid for a limited time >>>> window relative to creation time". >>>> >>>> While the creation time is defined by "iat", the time window is currently >>>> left at the discretion of each RS. >>>> >>>> It would be preferable to mandate the inclusion in the JWT of the exp >>>> (Expiration Time) Claim. >>>> In this way, the time window would be defined by the AS using both the >>>> "iat" and the "exp" claims. >>>> >>>> This would have the following advantages: >>>> >>>> The client will know whether a token is still usable and is unlikely to >>>> get a rejection of the token >>>> because of an unknown time window defined by a RS. >>>> The RS is able to manage better the "jti" claim values, because it will be >>>> able to discard "jti" claim values >>>> as soon as they are outside the time window defined by the AS in a JWT. >>>> Denis >>>> >>>> >>>>> All, >>>>> >>>>> This is a reminder that we have an Interim meeting this Monday, Nov 30th >>>>> @ 12:00pm ET, to discuss the latest with the DPoP document: >>>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/ >>>>> <https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/> >>>>> >>>>> You can find the details of the meeting and the slides here: >>>>> https://datatracker.ietf.org/meeting/interim-2020-oauth-16/session/oauth >>>>> <https://datatracker.ietf.org/meeting/interim-2020-oauth-16/session/oauth> >>>>> >>>>> Regards, >>>>> Rifaat & Hannes >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> <https://www.ietf.org/mailman/listinfo/oauth> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> <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 >>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>> https://www.ietf.org/mailman/listinfo/oauth >>> <https://www.ietf.org/mailman/listinfo/oauth> >> >> -- >> https://danielfett.de <https://danielfett.de/> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org <mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth >> <https://www.ietf.org/mailman/listinfo/oauth> > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org <mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth > <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 > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth -- ForgeRock values your Privacy <https://www.forgerock.com/your-privacy>
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
