[OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-28.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol WG of the IETF.

Title   : The OAuth 2.0 Authorization Framework: JWT Secured 
Authorization Request (JAR)
Authors : Nat Sakimura
  John Bradley
  Michael B. Jones
Filename: draft-ietf-oauth-jwsreq-28.txt
Pages   : 35
Date: 2020-08-20

Abstract:
   The authorization request in OAuth 2.0 described in RFC 6749 utilizes
   query parameter serialization, which means that Authorization Request
   parameters are encoded in the URI of the request and sent through
   user agents such as web browsers.  While it is easy to implement, it
   means that (a) the communication through the user agents is not
   integrity protected and thus the parameters can be tainted, and (b)
   the source of the communication is not authenticated.  Because of
   these weaknesses, several attacks to the protocol have now been put
   forward.

   This document introduces the ability to send request parameters in a
   JSON Web Token (JWT) instead, which allows the request to be signed
   with JSON Web Signature (JWS) and encrypted with JSON Web Encryption
   (JWE) so that the integrity, source authentication and
   confidentiality property of the Authorization Request is attained.
   The request can be sent by value or by reference.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-28
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwsreq-28

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-jwsreq-28


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


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

Re: [OAUTH-WG] Client authentication on token revocation

[Emond Papegaaij]

Hi Torsten,

Thanks for your insight. I agree, a sender constraint token, such as
when using certificate bound tokens from RFC 8705, cannot be used by
an attacker. It makes sense to only allow the owner to revoke them,
probably using the same mechanism as by which they are bound to the
client. For bearer tokens, we will simply skip the validation of the
client credentials.

Best regards,
Emond Papegaaij

On Thu, Aug 20, 2020 at 12:52 PM Torsten Lodderstedt
 wrote:
>
> Hi Emond,
>
> I tend to agree with your assessment. Revoking bearer tokens without client 
> authentication seems to be better than leaving the attacker the option to use 
> them to invoke resources.
>
> However, if the attacker cannot use the access tokens (e.g. because they are 
> sender constrained), the attacker could revoke tokens issued to a 
> confidential client as a kind of DoS attack.
>
> best regards,
> Torsten.
>
> > On 20. Aug 2020, at 11:02, Emond Papegaaij  
> > wrote:
> >
> > Hi all,
> >
> > We are currently implementing the token revocation endpoint (RFC 7009)
> > on our authorization server and do not understand why it requires
> > client authentication. When a party (a valid client or not) gets hold
> > of a valid access token in whatever way, the least damaging it could
> > do with it, is to revoke it. The current spec allows an attacker to
> > misuse this token for access to the resource server, but forbids it to
> > revoke it. This seems strange to me.
> >
> > Section 5 of RFC 7009 does not help in this either. It starts to
> > explain that this authentication is needed to prevent malicious
> > clients from guessing tokens, but ends with the fact that if this were
> > possible, much worse damage could be done by using the guessed token
> > on the resource server. We plan to skip the authentication all
> > together and simply revoke any valid token presented. How would you
> > recommend we deal with this?
> >
> > Best regards,
> > Emond Papegaaij
> > Topicus KeyHub
> >
> > ___
> > 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] WGLC review of PAR

[Neil Madden]

As promised in the last interim meeting, I’ve reviewed the current (03) 
draft-ietf-oauth-par document. Overall it looks close to ready to me, with 
mostly minor comments and one security-relevant comment on section 2.1 that 
should be discussed further, and one additional proposed security consideration:

Abstract:
The wording here could be improved - “allows clients to push an authorization 
request […] used as a reference to the data in a subsequent authorization 
request.” Both the pushed data and the call to the authorization endpoint are 
referred to as an “authorization request”. Maybe change the second usage to “in 
a subsequent call to the authorization endpoint”.

Section 1:
The introductory part here is quite long. Maybe adding a new sub-heading before 
the example would make it flow better.

The end of the introduction uses the acronym “PAR” for the first time, but 
never explicitly defines it.

I agree with Justin that ACR is not the best example to lead with. If it stays 
there should be a reference to OIDC to explain what this means.

The paragraph that begins “It also allows clients to push the form encoded …” 
is confusing because the use of “also” suggests this is different from the 
previous paragraph, but it seems to actually be saying the same thing?

“[…] but it also allows clients requiring
   an even higher security level, especially cryptographically confirmed
   non-repudiation, to explicitly adopt JWT-based request objects”

The “but” should be an “and” in this paragraph. It’s also not clear what is 
being said here - isn’t JAR what provides JWT-based request objects? 

The paragraph beginning “As a further benefit, …” is a little bit of a Columbo 
moment (“Just one more thing…”) at the end of the introduction. Maybe move this 
as another bullet point at the start of the section. The following paragraph 
can then be rewritten as “The increased confidence in the identity of the 
client during the authorization process allows confidential clients to provide 
a different redirect_uri on every request. […]”

Section 2:
The 3rd paragraph contains statements like 
The endpoint also supports sending all authorization
   request parameters as request object according to
   [I-D.ietf-oauth-jwsreq 
].
presumably this is not a normative requirement that any PAR implementation has 
to also support JAR, or is it? Maybe change the wording to “MAY also support …”.

The first mention of “token_endpoint_auth_method” and client metadata should 
have a reference to RFC 7591 - currently it’s only referenced later in section 
2.1.

2.1:
I’m a little bit wary of the relaxing of the redirect_uri processing rules, 
because this removes a layer of defence in depth. With the current requirement 
for pre-registered URIs an attacker needs to compromise the redirect endpoint 
*and* the client credentials in order to steal an authorization code and use 
it. With this change, compromising the client credentials alone would be 
enough. If the use-case is specifically in a PKI environment, could the 
redirect_uri be baked into the cert? Maybe this use-case could be better 
addressed in a separate draft.

2.2:
The definition of “expires_in” as a "JSON number" suggests that 
fractional/floating-point values are allowed. Presumably this is intended to be 
an integer? Is there a recommended minimum/maximum? Suggested wording:

===
   *  "expires_in" : A JSON number that represents the lifetime of the
  request URI in seconds as a positive integer. The lifetime SHOULD 
  be at least 5 seconds and at most 600 seconds, but other values are
  permitted at the discretion of the authorization server.
===

Those values are fairly arbitrary - 5 seconds seems a reasonable lower bound 
for a client with a bad network connection, and 10 minutes seems more than 
adequate upper bound for the typical uses.

3:
I confirmed that the request JWT verifies with the given JWK using our internal 
JWT library :-)

5:
“require_pushed_authorization_requests” might be better named 
“requires_pushed_authorization_requests” given that it is describing the 
server’s policy rather than telling the client to require them, but this is a 
really pedantic point. Same for the client metadata in section 6.

7:
I would like to propose an additional security consideration, with the 
following wording:

===
7.5. Request URI swapping

An attacker could capture the request URI from one request and then substitute 
it into a different authorization request. For example, in the context of 
OpenID Connect, an attacker could replace a request URI asking for a high level 
of authentication assurance with one that requires a lower level of assurance. 
Clients SHOULD make use of PKCE, a unique “state" parameter, or the OIDC 
“nonce” parameter in the pushed request object to prevent this attack.
===

— Neil

___
OAuth mailing 

Re: [OAUTH-WG] Client authentication on token revocation

[Torsten Lodderstedt]

Hi Emond, 

I tend to agree with your assessment. Revoking bearer tokens without client 
authentication seems to be better than leaving the attacker the option to use 
them to invoke resources. 

However, if the attacker cannot use the access tokens (e.g. because they are 
sender constrained), the attacker could revoke tokens issued to a confidential 
client as a kind of DoS attack. 

best regards,
Torsten. 

> On 20. Aug 2020, at 11:02, Emond Papegaaij  wrote:
> 
> Hi all,
> 
> We are currently implementing the token revocation endpoint (RFC 7009)
> on our authorization server and do not understand why it requires
> client authentication. When a party (a valid client or not) gets hold
> of a valid access token in whatever way, the least damaging it could
> do with it, is to revoke it. The current spec allows an attacker to
> misuse this token for access to the resource server, but forbids it to
> revoke it. This seems strange to me.
> 
> Section 5 of RFC 7009 does not help in this either. It starts to
> explain that this authentication is needed to prevent malicious
> clients from guessing tokens, but ends with the fact that if this were
> possible, much worse damage could be done by using the guessed token
> on the resource server. We plan to skip the authentication all
> together and simply revoke any valid token presented. How would you
> recommend we deal with this?
> 
> Best regards,
> Emond Papegaaij
> Topicus KeyHub
> 
> ___
> 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] Client authentication on token revocation

[Emond Papegaaij]

Hi all,

We are currently implementing the token revocation endpoint (RFC 7009)
on our authorization server and do not understand why it requires
client authentication. When a party (a valid client or not) gets hold
of a valid access token in whatever way, the least damaging it could
do with it, is to revoke it. The current spec allows an attacker to
misuse this token for access to the resource server, but forbids it to
revoke it. This seems strange to me.

Section 5 of RFC 7009 does not help in this either. It starts to
explain that this authentication is needed to prevent malicious
clients from guessing tokens, but ends with the fact that if this were
possible, much worse damage could be done by using the guessed token
on the resource server. We plan to skip the authentication all
together and simply revoke any valid token presented. How would you
recommend we deal with this?

Best regards,
Emond Papegaaij
Topicus KeyHub

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