Re: [OAUTH-WG] Reminder - Interim Meeting to discuss DPoP

[Brian Campbell]

While there are certainly more than a few different ways of approaching it,
I am still not convinced of any significant advantage to tracking iat + a
slightly smaller jti value vs. what is currently in the draft. And as we
are trying to reflect WG consensus here rather than one person's opinion, I
do not plan to engage in discussing this item any further unless others
from the WG indicate their interest in making a change.

On Mon, Dec 7, 2020 at 1:31 AM Denis  wrote:

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

Re: [OAUTH-WG] Reminder - Interim Meeting to discuss DPoP

[Denis]

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

The conversation at
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 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 

Re: [OAUTH-WG] Reminder - Interim Meeting to discuss DPoP

[Brian Campbell]

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 with what's in the spec
now maybe not being perfect but good enough.

On Thu, Dec 3, 2020 at 5:09 AM Neil Madden 
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 <
> bcampbell=40pingidentity@dmarc.ietf.org> wrote:
>
> The conversation at
> 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  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.
>> 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 

Re: [OAUTH-WG] Reminder - Interim Meeting to discuss DPoP

[Neil Madden]

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 
>  wrote:
> 
> The conversation at 
> 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  > 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 
 . 
 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 

Re: [OAUTH-WG] Reminder - Interim Meeting to discuss DPoP

[Brian Campbell]

The conversation at
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  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.
> 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 

Re: [OAUTH-WG] Reminder - Interim Meeting to discuss DPoP

[Denis]

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 
.
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.

Re: [OAUTH-WG] Reminder - Interim Meeting to discuss DPoP

[Brian Campbell]

Thanks Dick.

On Tue, Dec 1, 2020 at 1:43 PM Dick Hardt  wrote:

> I have 2 suggestions for the draft that I beleive address the issues Denis
> is bringing up:
>
> 1) call out that a DPoP proof can only be used once, and a new DPoP proof
> is needed for every API call. Apologies if that is in the text -- but I
> could not find it doing a skim over the document.
>

I think it is very strongly implied but not called out explicitly as such.
We can add that.



> 2) Provide additional guidance on what "a relatively brief period" is
> including what factors an implementation should consider when determining
> the length of time. I'm assuming it is a small number of seconds to
> accommodate for the delay between the client creating the DPoP proof and
> the server receiving it.
>

On the order of seconds is my assumption too. But yes we can add some more
guidance here with a bit more specificity.



> ᐧ
>
> On Tue, Dec 1, 2020 at 5:24 AM Daniel Fett  wrote:
>
>> 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.
>> 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
>> 

Re: [OAUTH-WG] Reminder - Interim Meeting to discuss DPoP

[Dick Hardt]

I have 2 suggestions for the draft that I beleive address the issues Denis
is bringing up:

1) call out that a DPoP proof can only be used once, and a new DPoP proof
is needed for every API call. Apologies if that is in the text -- but I
could not find it doing a skim over the document.

2) Provide additional guidance on what "a relatively brief period" is
including what factors an implementation should consider when determining
the length of time. I'm assuming it is a small number of seconds to
accommodate for the delay between the client creating the DPoP proof and
the server receiving it.

ᐧ

On Tue, Dec 1, 2020 at 5:24 AM Daniel Fett  wrote:

> 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.
> 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 

Re: [OAUTH-WG] Reminder - Interim Meeting to discuss DPoP

[Daniel Fett]

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.
>> 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 

Re: [OAUTH-WG] Reminder - Interim Meeting to discuss DPoP

[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 
.
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 > 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 

Re: [OAUTH-WG] Reminder - Interim Meeting to discuss DPoP

[Brian Campbell]

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. I believe it pretty
well has consensus at this point and thus unlikely to be changed.

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.





On Mon, Nov 30, 2020 at 8:45 AM Denis  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/
>
> You can find the details of the meeting and the slides here:
> https://datatracker.ietf.org/meeting/interim-2020-oauth-16/session/oauth
>
> Regards,
>  Rifaat & Hannes
>
>
> ___
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>
>
> ___
> 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._
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Reminder - Interim Meeting to discuss DPoP

[Denis]

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/ 



You can find the details of the meeting and the slides here:
https://datatracker.ietf.org/meeting/interim-2020-oauth-16/session/oauth 



Regards,
 Rifaat & Hannes


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Reminder - Interim Meeting to discuss DPoP

[Rifaat Shekh-Yusef]

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/

You can find the details of the meeting and the slides here:
https://datatracker.ietf.org/meeting/interim-2020-oauth-16/session/oauth

Regards,
 Rifaat & Hannes
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth