[OAUTH-WG] PAR error for redirect URI?

[Brian Campbell]

During the course of a recent OIDF FAPI WG discussion (the FAPI profiles
use PAR for authz requests) on this issue

it was noted that there's no specific error code for problems with the
redirect_uri (the example in
https://www.ietf.org/archive/id/draft-ietf-oauth-par-04.html#section-2.3
even shows a general error code with mention of the redirect_uri not being
valid in the error description). Some folks on that call thought it would
be worthwhile to have a more specific error code for an invalid
redirect_uri and I reluctantly took an action item to raise the issue here.
At the time I'd forgotten that PAR had already passed WGLC. But it's been
sitting idle while awaiting the shepherd writeup since mid September so
it's maybe realistic to think the window for a small change is still open.

Presumably nothing like an "invalid_redirect_uri" error code was defined in
RFC 6749 because that class of errors could not be returned to the client
via redirection. But the data flow in PAR would allow for a
"invalid_redirect_uri" so it's not an unreasonable thing to do.

As I write this message, however, I'm not personally convinced that it's
worth making a change to PAR at this point. But I did say I'd bring the
question up in the WG list and I'm just trying to be true to my word. So
here it is. Please weigh in, if you have opinions on the matter.

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

[OAUTH-WG] draft-ietf-oauth-dpop-02: The size of the "jti" is currently mandated to 96 bits minimum

[Denis]

Hi Brian,

I changed the title of this thread from "Reminder - Interim Meeting to 
discuss DPoP" to "draft-ietf-oauth-dpop-02: The size of the "jti" is 
currently mandated to 96 bits minimum".


Thank you for the link. I read it but I am still not convinced that 
using a minimum of 96 bits is necessary.


Using both the "iat" claim and the "jti" claim, it is very unlikely that 
the same 32 bits jti will be picked up
at the very same "iat" time by two or more clients. Should such a 
condition happen, then another attempt

with a new DPoP proof JWT would very likely succeed for the second client.

In case of a collision, it would also be possible to return a specific 
error code saying something like "duplicate iat/jti pair".
So the client would be informed that it should perform another attempt 
using a new DPoP proof JWT.


Denis

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 

[OAUTH-WG] Proposed text for a Privacy considerations section in draft-ietf-oauth-dpop-02

[Denis]

This is the development of the 18 th comment from my previous email.

Proposed text:

9. Privacy considerations

The document does not specify how the public key used to compute the 
signature of the DPoP proof JWT is generated or comes from. Different 
scenarios are possible.
They are addressed with respect to the ability of RSs or other servers 
being able to link the users using the DPoP proof JWTs and the 
associated access tokens they receive.


In order to limit attacks to impersonation attacks, an access token must 
include either a "sub" claim or other claims allowing to unambiguously 
identify the user to a RS.
When a "sub" claim is being used, RFC 7519 states in section 4.1.2 that 
"the subject value MUST either be scoped to be locally unique in the 
context of the issuer or be globally unique".


When the subject value is globally unique, RSs usually do not learn more 
than they already knew but since that subject value may be shared and 
compared with globally unique identifiers
stored by other servers that are not part of the OAuth framework this 
may be considered as a problem but this has nothing to do with the DPoP 
mechanism.


The case where the subject value is locally unique in the context of the 
AS or other claims incorporated into an access token allow to 
unambiguously identify the user to a RS is addressed below.



9.1 Use of a single asymmetric key pair for all ASs

All the "DPoP" access tokens issued by all the ASs, will include the 
same public key.


When the subject value is locally unique in the context of the issuer 
(i.e. an AS) or other claims allow to unambiguously identify the user to 
a RS,
RSs may learn more than they already knew since a locally unique 
identifier used by one AS may be different from another locally unique 
identifier used by another AS.
The same applies for other claims allowing to unambiguously identify the 
user to a RS. In this case, this allows RSs to link a "sub" claim or 
other claims allowing
to unambiguously identify the user to a RS with another "sub" claim or 
other claims allowing to unambiguously identify the user to another RS.


While this method may not be a problem when it is only used within an 
Intranet context, this method may be a problem as soon as it is used 
over the Internet,
because RSs will be able to link the access tokens they receive. This 
method is strongly deprecated when used over the Internet. It may be 
used with great care
within an Intranet as long as the network is kept isolated from the 
Internet since it may affect the privacy of the users.


9.2 Use of a static asymmetric key pair between a client and each AS

All the "DPoP" access tokens issued by one AS for one user, will include 
the same public key. This allows each RS to know whether the access tokens

it receives are coming from the same AS and from the same user.

Using this method, RSs are able to know that the access tokens they 
receive have been issued for the same user whatever claims have been 
incorporated

into the access token. This method may affect the user's privacy.

9.3 Use of a static asymmetric key pair between a client and each RS

All the "DPoP" access tokens issued for one RS, will include the same 
public key, no matter which AS has generated the access token.
This allows each RS to know that the access tokens it receives are 
coming from the same user. Using this method, RSs are unable to link the 
access tokens

they receive when receiving a DPoP proof JWT.

From a security point of view, this method has a side benefit since all 
access tokens that contain the same public key that are received by a 
given RS are indeed

issued for the same user.

9.4 Use of an ephemeral asymmetric key pair for every "DPoP" access token

When only using the public key placed in a "DPoP" access token, RSs are 
unable to link the access tokens they receive.  However, this method has 
the disadvantage
to require the generation of a different key pair for every "DPoP" 
access token.  This may be time and resource consuming.  When this 
method is being used,
it is recommended to generate key pairs in advance, whenever it is 
possible.


Denis

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

[OAUTH-WG] Proposed changes to draft-ietf-oauth-dpop-02

[Denis]

I have reviewed the whole draft and you will find comments below 
starting with five editorials comments. Every other comment is numbered.


Let us start with five typos where there is a duplication of the word "the":

Page 4:

XXS vulnerabilities also allow an attacker to execute code in the 
context of the browser-based client application and maliciously use a 
token indirectly through the _the_ client.


Page 11:

The example response in Figure 5 included a refresh token, which the 
client can use to obtain a new access token when the _the_ previous one 
expires.


Page 11:

Refreshing an access token is a token request using the "refresh_token" 
grant type made to the _the_ authorization server’s token endpoint.


Page 13:

Resource servers MUST be able to reliably identify whether an access 
token is bound using DPoP and ascertain sufficient information about the 
public key to which
the token is bound in order to verify the binding with respect to the 
_the_ presented DPoP proof (see Section 7.1).


Page 13:

Resource servers supporting DPoP MUST ensure that the _the_ public key 
from the DPoP proof matches the pubic key to which the access token is 
bound.



1. Section 1. Introduction

The text states:

 The value of the header is a JWT [RFC7519] that enables the 
authorization server to bind issued tokens to the public part of the 
client’s key pair.


A client may use different key pairs.

Change :

"the client’s key pair"

into :

" a client’s key pair".

2. Section 2.Objectives

The text states:

    The primary aim of DPoP is to prevent unauthorized or illegitimate 
parties from using leaked or stolen access tokens by binding a token to 
a public key
    upon issuance and requiring that the client demonstrate possession 
of the corresponding private key when using the token.


The objective needs to be described in terms of what ,the mechanism does 
and not yet at this time for which reasons.


Change into:

 The aim of DPoP is first to require a client to demonstrate 
possession of a public key when requesting an access token or a refresh 
token to an AS
 where the AS will then bind that public key upon a token issuance 
and, then to demonstrate the possession of a public key included into a 
token

 when presenting a refresh token to an AS or an access token to a RS.


3. The next sentence looks odd as far as the English grammar is considered.

    This constrains the legitimate sender of the token to only the 
party with access to the private key and gives the server receiving the 
token added assurances

    that the sender is legitimately authorized to use it.

With the proposed change above, this sentence looks unnecessary and 
could be deleted.


4. Section 3 Concepts Page 5

In order to make crystal clear that they are to different DPoP Proofs, 
(DPoP Proof 1) and (DPoP Proof 2) should be shown on the figure as 
proposed below:


*+++---+
||--(A)-- Token Request --->||
| Client |(DPoP Proof 1)| Authorization |
|||Server|
||<-(B)-- DPoP-bound Access Token --||
||(token_type=DPoP)+---+
||
||
||+---+
||--(C)-- DPoP-bound Access Token ->||
||(DPoP Proof 2)|Resource|
|||Server|
||<-(D)-- Protected Resource ---||
||+---+
++
Figure 1: Basic DPoP Flow
*
5. The text states:

 The basic steps of an OAuth flow with DPoP are shown in Figure 1:

 *(A) In the Token Request, the client sends an authorization grant 
(e.g., an authorization code, refresh token, etc.) to the authorization 
server
    in order to obtain an access token (and potentially a refresh 
token).The client attaches a DPoP proof to the request in an HTTP header.


At the end of the sentence, add : (DPoP Proof 2).


6. The text states:

 *(C) To use the access token the client has to prove possession of 
the private key by, again, adding a header to the request that carries 
the DPoP proof.


Change into:

 *(C) To use the access token the client has to prove possession of 
the private key by using a header to the request that carries another 
DPoP proof (DPoP Proof 2).



7. Section 4.DPoP Proof JWTs

The text states:

 A valid DPoP proof demonstrates to the server that the client 
holds the private key that was used to sign the JWT.


For avoiding misunderstandings, it would be better to say that this 
applies to DPoP Proof JWTs and that it applicable for both ASs and RSs.


Proposed change:

 A valid DPoP proof demonstrates to a server, (i.e. an AS or a RS), 
that the client holds the private key that was used to sign a DPoP Proof 
JWT.


8. The text states:

 This enables authorization servers to bind issued tokens to the 
corresponding public key (as described in Section 5) and for resource 
servers to verify
 the key-binding of tokens that it receives (see Section 7.1), 
which prevents said tokens from being used by any entity that does not 
have access to the private 

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.