Hi Brian,
The client is not necessarily identified in requests to the RS (it
could be via the access token but that's an implementation detail that
can't be counted on in spec) so maintaining a per client list isn't
viable.
That as well as some other considerations/approaches were talked about
in https://github.com/danielfett/draft-dpop/issues/47
<https://github.com/danielfett/draft-dpop/issues/47> with what's in
the spec now maybe not being perfect but good enough.
The message sent by b---c on September 23, 2019 states:
I think there are a number of options. The ones that come to mind are:
1. servers track only the jti value and require that jti be
globally unique (a UUID or >= ~128 bit random)
2. servers track the public key (or hash of it) + a jti that is
incrementing or otherwise unique within that instance of the
client (like random >= ~32 bits but I'm not sure and it really
depends on how many requests are being made in the allowed
timeframe)
3. servers track the whole dpop jwt (or probably a hash of it) and
jti is not required at all (or could be very very small). I
think the iat and jwk and signature in the dpop jwt would
provide more than sufficient entropy for this to work. Although
I guess multiple requests to the same URI & same method during
the same second (iat) when using a deterministic signature
scheme would need to be differentiated somehow.
I think 1 is the most straightforward to describe in a document. I'm
drawn to 3 because it would allow for smaller dpops and move some of
the complexity burden from the client to the server. 2 kinda does
also but feels to me like not a great compromise that's maybe harder
for both parties to implement.
Thoughts? Preferences? Alternatives?
Method 1 is not "good enough" as you write: it is over-engineering. A
method for flushing the cache of "whatever data is being stored" has not
be considered in the discussion.
There are alternatives methods that have not been proposed, nor discussed.
In an earlier email, I proposed a pseudo random number with 2 ^ 32
values associated with the"iat" time. For more details, see item 9
(Section 4.2. DPoP Proof JWT Syntax)
from:
https://mailarchive.ietf.org/arch/browse/oauth/?q=Proposed%20changes%20to%20draft-ietf-oauth-dpop-02
The text is as follows:
*"jti": JWT identifier that complements the "iat" claim to
handle replay protection for a given server (REQUIRED).
The value MUST be assigned such that there is a negligible
probability that the same value will be assigned to any other DPoP proof
received by the server within the same second during a short time window
of validity (i.e. a few minutes only). This MUST be accomplished by
encoding 32 bits of pseudorandom data. I would add the following
sentence: In case of a replay detection, an "replay_dpop_proof" error
code MUST be returned
This will allow both to recover from an error by sending a new DPoP
proof and to test that replay detection is indeed working.
Note that 64 bits of pseudorandom data would also make it, but 96 bits
(or more) is oversized.
The following guidance in section 8.1 will then become unnecessary:
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.
Denis
On Thu, Dec 3, 2020 at 5:09 AM Neil Madden <[email protected]
<mailto:[email protected]>> wrote:
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
<[email protected]
<mailto:[email protected]>> 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 <[email protected]
<mailto:[email protected]>> 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"
*o**r* "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 <[email protected]
<mailto:[email protected]>> 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
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
<https://www.ietf.org/mailman/listinfo/oauth>
_______________________________________________
OAuth mailing list
[email protected] <mailto:[email protected]>
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
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
<https://www.ietf.org/mailman/listinfo/oauth>
--
https://danielfett.de <https://danielfett.de/>
_______________________________________________
OAuth mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
<https://www.ietf.org/mailman/listinfo/oauth>
_______________________________________________
OAuth mailing list
[email protected] <mailto:[email protected]>
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
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
<https://www.ietf.org/mailman/listinfo/oauth>
ForgeRock values your Privacy <https://www.forgerock.com/your-privacy>
/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
