Re: [OAUTH-WG] Comments on draft-ietf-oauth-jwsreq-22 (The OAuth 2.0 Authorization Framework: JWT Secured Authorization Request))

2020-05-30 Thread Aaron Parecki 
> the AS will have the knowledge of these request parameters such as
"please let me make a payment with the amount of 45 Euros"
or "please give me read access to folder A and write access to file X"

Typically in OAuth it's the authorization server's job to inform users and
protect access to their resources. Obviously in order to do that the AS
must know about the details of the request.

Can you please clarify the scenario in which you would want the AS to have
no information about the request that it's authorizing?

Aaron Parecki




On Wed, May 27, 2020 at 10:20 AM Denis  wrote:

> As indicated in the abstract:
>
> "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)".
>
> This approach has a major consequence which is not indicated in the
> "Privacy Considerations section:
> the AS will have the knowledge of these request parameters such as "please
> let me make a payment with the amount of 45 Euros"
> or "please give me read access to folder A and write access to file X".
>
> Such an approach has privacy issues which are currently not documented in
> the Privacy Considerations section.
>
> The AS would be in a position to know, not only which resources servers
> are going to be accessed, but also what kind of operations
> are going to be performed by its clients on the resource servers. With
> such an approach, ASs will have a deep knowledge of every
> operation that can be performed by a user on every RS.
>
> As a consequence, the AS would also be in a position to trace the actions
> performed by its users on the resources servers.
>
> Other approaches that are more "privacy friendly" should be considered to
> address the initial problem.
>
> Denis
>
> PS. This email closely relates to the previous email sent on the WG
> mailing list with the following topic:
>Comments on OAuth 2.0 Rich Authorization Requests
> (draft-ietf-oauth-rar-01)
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
-- 
---
Aaron Parecki
https://aaronparecki.com
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Comments on draft-ietf-oauth-jwsreq-22 (The OAuth 2.0 Authorization Framework: JWT Secured Authorization Request))

2020-05-30 Thread Benjamin Kaduk 
On Wed, May 27, 2020 at 07:20:29PM +0200, Denis wrote:
> As indicated in the abstract:
> 
> "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)".
> 
> This approach has a major consequence which is not indicated in the 
> "Privacy Considerations section:
> the AS will have the knowledge of these request parameters such as 
> "please let me make a payment with the amount of 45 Euros"
> or "please give me read access to folder A and write access to file X".
> 
> Such an approach has privacy issues which are currently not documented 
> in the Privacy Considerations section.
> 
> The AS would be in a position to know, not only which resources servers 
> are going to be accessed, but also what kind of operations
> are going to be performed by its clients on the resource servers. With 
> such an approach, ASs will have a deep knowledge of every
> operation that can be performed by a user on every RS.
> 
> As a consequence, the AS would also be in a position to trace the 
> actions performed by its users on the resources servers.
> 
> Other approaches that are more "privacy friendly" should be considered 
> to address the initial problem.

Do you have the start of a list of such other approaches to seed the
discussion?  There seemms to be some inherent tension between the
authorization server knowing what it is authorizing and the privacy
properties you are advocating...

Thanks,

Ben

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

Re: [OAUTH-WG] [Errata Verified] RFC7800 (6187)

2020-05-30 Thread Pete Resnick 
But 
https://www.ietf.org/about/groups/iesg/statements/processing-rfc-errata/, 
in particular:


1. Only errors that could cause implementation or deployment problems or 
significant confusion should be Verified.
2. Things that are clearly wrong but could not cause an implementation 
or deployment problem should be Hold for Document Update.
5. Typographical errors which would not cause any confusions to 
implementation or deployments should be Hold for Document Update.


Did something change these criteria?

pr

On 30 May 2020, at 23:09, Benjamin Kaduk wrote:


The new text is clearly the right thing, and there is no need
to debate it if/when the document gets updated.  "Don't hold
it; do it now", so to speak -- and noting that (my
understanding/recollection of) the plan for
https://www.rfc-editor.org/rfc/inline-errata/rfc7800.html is that only
verified errata, not those in other states, will be displayed.

(Yes, that link 404s at the moment, I assume a caching issue.)

-Ben

On Sat, May 30, 2020 at 10:55:01PM -0500, Pete Resnick wrote:

"Verified", not "Hold For Document Update"?

pr

On 30 May 2020, at 20:34, RFC Errata System wrote:


The following errata report has been verified for RFC7800,
"Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6187

--
Status: Verified
Type: Editorial

Reported by: Pete Resnick 
Date Reported: 2020-05-26
Verified by: Benjamin Kaduk (IESG)

Section: 7.1

Original Text
-
   [JWK]  Jones, M., "JSON Web Key (JWK)", RFC 7517,
  DOI 10.17487/RFC7157, May 2015,
  .


Corrected Text
--
   [JWK]  Jones, M., "JSON Web Key (JWK)", RFC 7517,
  DOI 10.17487/RFC7517, May 2015,
  .


Notes
-
DOI has a typo: 7157 instead of 7517.

--
RFC7800 (draft-ietf-oauth-proof-of-possession-11)
--
Title   : Proof-of-Possession Key Semantics for JSON Web
Tokens (JWTs)
Publication Date: April 2016
Author(s)   : M. Jones, J. Bradley, H. Tschofenig
Category: PROPOSED STANDARD
Source  : Web Authorization Protocol
Area: Security
Stream  : IETF
Verifying Party : IESG



--
Pete Resnick https://www.episteme.net/
All connections to the world are tenuous at best



--
Pete Resnick https://www.episteme.net/
All connections to the world are tenuous at best
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] [Errata Verified] RFC7800 (6187)

2020-05-30 Thread Benjamin Kaduk 
The new text is clearly the right thing, and there is no need
to debate it if/when the document gets updated.  "Don't hold
it; do it now", so to speak -- and noting that (my
understanding/recollection of) the plan for
https://www.rfc-editor.org/rfc/inline-errata/rfc7800.html is that only
verified errata, not those in other states, will be displayed.

(Yes, that link 404s at the moment, I assume a caching issue.)

-Ben

On Sat, May 30, 2020 at 10:55:01PM -0500, Pete Resnick wrote:
> "Verified", not "Hold For Document Update"?
> 
> pr
> 
> On 30 May 2020, at 20:34, RFC Errata System wrote:
> 
> > The following errata report has been verified for RFC7800,
> > "Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)".
> >
> > --
> > You may review the report below and at:
> > https://www.rfc-editor.org/errata/eid6187
> >
> > --
> > Status: Verified
> > Type: Editorial
> >
> > Reported by: Pete Resnick 
> > Date Reported: 2020-05-26
> > Verified by: Benjamin Kaduk (IESG)
> >
> > Section: 7.1
> >
> > Original Text
> > -
> >[JWK]  Jones, M., "JSON Web Key (JWK)", RFC 7517,
> >   DOI 10.17487/RFC7157, May 2015,
> >   .
> >
> >
> > Corrected Text
> > --
> >[JWK]  Jones, M., "JSON Web Key (JWK)", RFC 7517,
> >   DOI 10.17487/RFC7517, May 2015,
> >   .
> >
> >
> > Notes
> > -
> > DOI has a typo: 7157 instead of 7517.
> >
> > --
> > RFC7800 (draft-ietf-oauth-proof-of-possession-11)
> > --
> > Title   : Proof-of-Possession Key Semantics for JSON Web 
> > Tokens (JWTs)
> > Publication Date: April 2016
> > Author(s)   : M. Jones, J. Bradley, H. Tschofenig
> > Category: PROPOSED STANDARD
> > Source  : Web Authorization Protocol
> > Area: Security
> > Stream  : IETF
> > Verifying Party : IESG
> 
> 
> -- 
> Pete Resnick https://www.episteme.net/
> All connections to the world are tenuous at best

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

Re: [OAUTH-WG] [Errata Verified] RFC7800 (6187)

2020-05-30 Thread Pete Resnick 

"Verified", not "Hold For Document Update"?

pr

On 30 May 2020, at 20:34, RFC Errata System wrote:


The following errata report has been verified for RFC7800,
"Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6187

--
Status: Verified
Type: Editorial

Reported by: Pete Resnick 
Date Reported: 2020-05-26
Verified by: Benjamin Kaduk (IESG)

Section: 7.1

Original Text
-
   [JWK]  Jones, M., "JSON Web Key (JWK)", RFC 7517,
  DOI 10.17487/RFC7157, May 2015,
  .


Corrected Text
--
   [JWK]  Jones, M., "JSON Web Key (JWK)", RFC 7517,
  DOI 10.17487/RFC7517, May 2015,
  .


Notes
-
DOI has a typo: 7157 instead of 7517.

--
RFC7800 (draft-ietf-oauth-proof-of-possession-11)
--
Title   : Proof-of-Possession Key Semantics for JSON Web 
Tokens (JWTs)

Publication Date: April 2016
Author(s)   : M. Jones, J. Bradley, H. Tschofenig
Category: PROPOSED STANDARD
Source  : Web Authorization Protocol
Area: Security
Stream  : IETF
Verifying Party : IESG



--
Pete Resnick https://www.episteme.net/
All connections to the world are tenuous at best

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

[OAUTH-WG] [Errata Verified] RFC7800 (6187)

2020-05-30 Thread RFC Errata System 
The following errata report has been verified for RFC7800,
"Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)". 

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6187

--
Status: Verified
Type: Editorial

Reported by: Pete Resnick 
Date Reported: 2020-05-26
Verified by: Benjamin Kaduk (IESG)

Section: 7.1

Original Text
-
   [JWK]  Jones, M., "JSON Web Key (JWK)", RFC 7517,
  DOI 10.17487/RFC7157, May 2015,
  .


Corrected Text
--
   [JWK]  Jones, M., "JSON Web Key (JWK)", RFC 7517,
  DOI 10.17487/RFC7517, May 2015,
  .


Notes
-
DOI has a typo: 7157 instead of 7517.

--
RFC7800 (draft-ietf-oauth-proof-of-possession-11)
--
Title   : Proof-of-Possession Key Semantics for JSON Web Tokens 
(JWTs)
Publication Date: April 2016
Author(s)   : M. Jones, J. Bradley, H. Tschofenig
Category: PROPOSED STANDARD
Source  : Web Authorization Protocol
Area: Security
Stream  : IETF
Verifying Party : IESG

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

Re: [OAUTH-WG] JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens

2020-05-30 Thread Benjamin Kaduk 
On Fri, May 22, 2020 at 11:37:28AM +0200, Denis wrote:
> Hi Benjamin,
> > On Thu, May 14, 2020 at 04:29:43PM +0200, Denis wrote:
> >> Since then, I questioned myself how a client would be able to request an
> >> access token that would be
> >> *strictly compliant with this Profile*.
> > I don't understand why this is an interesting question to ask.  The access
> > token and interpretation thereof is (AIUI) generally seen as an internal
> > matter between AS and RS, with the client having no need to care about the
> > specifics.
> 
> This document is*_a_* Profile for OAuth 2.0 Access Tokens. It is not 
> _*the*_ Profile for *_all_ *OAuth 2.0 Access Tokens.

Sure.  But (in my understanding), in common usage, the contents and
interpretation of the access token is set by common agreement between AS
and RS, with the client serving only as a "dumb" channel for transporting
the token.  That is, we're providing a token format that an RS and AS can
agree to use, most likely for all tokens issued by the AS for that RS.  I
don't know of any existing mechanisms, or desire for such mechanisms by
deployments, for using a different token format for different tokens issued
by a given AS for a given RS.  Attempting to have the client provide input
that would affect such a mechanism seems like complexity with no market
demand; a "solution in search of a problem" as it were.  Is there some
pent-up demand among OAuth deployments that I'm not aware of?  I freely
admit to not being very on top of the broad spectrum of what's deployed...

> 1) A client may wish to obtain an Access Token that corresponds to this 
> Profile because, for example,
> this document mandates the "sub" claim to be present". Hence, the 
> content of the Access Token is not
> totally "/an internal matter between AS and RS/".
> 
> However, I have not understood how a client could request an Access 
> Token that corresponds to *_this_***Profile,
> since there is no mandatory parameter in the request (both the "scope" 
> parameter and the "resource" parameter are optional).
> 
> In the future, we could define _*another*_**Profile. Hence, there is the 
> same question:  How could a client request an Access Token
> that corresponds to *_that other_***Profile ?
> 
> 2) When getting a JWT,  how can the client make sure that the access 
> token it got is compliant with this Profile ?
> 
> RFC 8725 states in section 3.11 :
> 
> 3.11. Use Explicit Typing
> Sometimes, one kind of JWT can be confused for another. If a
> particular kind of JWT is subject to such confusion,
> that JWT can include an explicit JWT type value, and the validation
> rules can specify checking the type (...).
> Explicit JWT typing is accomplished by using the "typ" Header
> Parameter.
> 
> Wouldn't be wise to include an explicit JWT type value for JWTs 
> conformant to this Profile ?

In the model where the client is a "dumb" communications channel, this
question does not seem interesting.  But the related question of "how can
the RS make sure that the access token it got was generated according to
this profile?" does seem interesting, and seems like it would benefit from
the same proposed solution.

> This relates to an email posted by Dominick Baier under the topic "JAR: 
> JWT typ" on May 19 :
> 
> This has been brought up before - but no response.
> 
> Either I can’t find it - or it is missing. But is the setting the
> JWT typ explicitly mentioned somewhere?

It is fairly likely that I will remember to ask about explicit "typ" usage
if I'm still on the IESG when this document gets there: I think I've been
making a habit of doing so.

Thanks,

Ben

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

Re: [OAUTH-WG] Downgrade attacks on PKCE

2020-05-30 Thread Neil Madden 
We (ForgeRock) already support solution 1 as a configuration option, but I 
prefer solution 2 and have raised a ticket for us to implement it. For us at 
least it’s a trivial fix and seems more robust against configuration errors.

— Neil

> On 30 May 2020, at 08:58, Daniel Fett  wrote:
> 
> Hi all,
> 
> Aaron, Dick, Torsten and I today discussed the downgrade attacks on PKCE [1] 
> and how to mitigate them in OAuth 2.1 and 2.0. We came to the conclusion that 
> we have two options:
> 
> 1. "Static" Solution
> 
> For every client_id that is registered with an AS, the AS MUST either always 
> enforce the use of PKCE or always enforce the use of nonce. Whether PKCE or 
> nonce is enforced can be part of the client registration or configured in 
> other ways.
> 
> In other words: A single client is not allowed to switch between using PKCE 
> and using nonce.
> 
> Note that the client is allowed to use the respective other mechanism on top 
> of the enforced one.
> 
> Properties:
> Easy to understand mitigation.
> Implementation is mainly a new data field and a check in the authorization 
> request.
> Not compatible to deployments where clients sometimes use nonce and sometimes 
> use PKCE with the same client_id. 
> 2. "Dynamic" Solution
> 
> Each AS that supports PKCE MUST check whether a code challenge is contained 
> in the authorization request. This information MUST be bound to the code that 
> is issued.
> 
> When a code arrives at the token endpoint, the AS MUST do the following check:
> 
> If there was a code_challenge in the authorization request for which this 
> code was issued, there must be a code_verifier in the token request and it 
> must be verified according to RFC7636. (This is no change from the current 
> behavior in RFC7636.)
> If there was no code_challenge in the authorization request, any request to 
> the token endpoint containing a code_verifier MUST be rejected.
> Properties:
> 
> No change in behavior needed for properly implemented clients. Backwards 
> compatible for all existing deployments.
> Implementation is mainly some logic for the authorization endpoint, token 
> endpoint, and a new data field in the authorization session maintained by the 
> AS.
> Slightly more complex to implement for the AS, maybe.
> We would like to hear the feedback from the working group on these two 
> solutions before proceeding to propose wording for the affected documents.
> 
> [1] https://danielfett.de/2020/05/16/pkce-vs-nonce-equivalent-or-not/ 
> 
> 
> -Daniel
> 
> ___
> 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] Downgrade attacks on PKCE

2020-05-30 Thread Daniel Fett 
Hi all,

Aaron, Dick, Torsten and I today discussed the downgrade attacks on PKCE
[1] and how to mitigate them in OAuth 2.1 and 2.0. We came to the
conclusion that we have two options:

*1. "Static" Solution*

For every client_id that is registered with an AS, the AS MUST either
always enforce the use of PKCE or always enforce the use of nonce.
Whether PKCE or nonce is enforced can be part of the client registration
or configured in other ways.

In other words: A single client is not allowed to switch between using
PKCE and using nonce.

Note that the client is allowed to use the respective other mechanism on
top of the enforced one.

Properties:

  * Easy to understand mitigation.
  * Implementation is mainly a new data field and a check in the
authorization request.
  * Not compatible to deployments where clients sometimes use nonce and
sometimes use PKCE with the same client_id. *
***

**

*2. "Dynamic" Solution*

Each AS that supports PKCE MUST check whether a code challenge is
contained in the authorization request. This information MUST be bound
to the code that is issued.

When a code arrives at the token endpoint, the AS MUST do the following
check:

 1. If there was a code_challenge in the authorization request for which
this code was issued, there must be a code_verifier in the token
request and it must be verified according to RFC7636. (This is no
change from the current behavior in RFC7636.)
 2. If there was no code_challenge in the authorization request, any
request to the token endpoint containing a code_verifier MUST be
rejected.

Properties:

  * No change in behavior needed for properly implemented clients.
Backwards compatible for all existing deployments.
  * Implementation is mainly some logic for the authorization endpoint,
token endpoint, and a new data field in the authorization session
maintained by the AS.
  * Slightly more complex to implement for the AS, maybe.

We would like to hear the feedback from the working group on these two
solutions before proceeding to propose wording for the affected documents.

[1] https://danielfett.de/2020/05/16/pkce-vs-nonce-equivalent-or-not/

-Daniel

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