Subject: Re: [OAUTH-WG] PAR metadata

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Fri, 3 Jan 2020 21:43:36 +0000

PAR introduces an added wrinkle for encrypted request objects: the PAR endpoint and authorization endpoint may not have access to the same cryptographic keys, even though they're both part of the "authorization server." Since they're different endpoints with different roles, it's reasonable to put them in separate trust boundaries. There is no way to support this isolation with just a single "jwks_uri" metadata property.

The two options that I see are:

1. Define a new par_jwks_uri metadata property.
2. Explicitly state that this separation is not supported.

I strongly perfer #1 as it has a very minor impact on deployments that don't care (i.e., they just set par_jwks_uri and jwks_uri to the same value) and failing to support this trust boundary creates an artificial limit on implementation architecture and could lead to compatibility-breaking workarounds.

– 
Annabelle Richard Backman
AWS Identity

On 12/31/19, 8:07 AM, "OAuth on behalf of Torsten Lodderstedt" <[email-masked] on behalf of torsten=[email-masked]> wrote:

    Hi Filip, 
    
    > On 31. Dec 2019, at 16:22, Filip Skokan <[email-masked]> wrote:
    > 
    > I don't think we need a *_auth_method_* metadata for every endpoint the client calls directly, none of the new specs defined these (e.g. device authorization endpoint or CIBA), meaning they also didn't follow the scheme from RFC 8414 where introspection and revocation got its own metadata. In most cases the unfortunately named `token_endpoint_auth_method` and its related metadata is what's used by clients for all direct calls anyway.
    > 
    > The same principle could be applied to signing (and encryption) algorithms as well.
    > 
    > This I do not follow, auth methods and their signing is dealt with by using `token_endpoint_auth_methods_supported` and `token_endpoint_auth_signing_alg_values_supported` - there's no encryption for the `_jwt` client auth methods. 
    > Unless it was meant to address the Request Object signing and encryption metadata, which is defined and IANA registered by OIDC. PAR only references JAR section 6.1 and 6.2 for decryption/signature validation and these do not mention the metadata (e.g. request_object_signing_alg) anymore since draft 07.
    
    Dammed! You are so right. Sorry, I got confused somehow. 
    
    > 
    > PS: I also found this comment related to the same question about auth metadata but for CIBA.
    
    Thanks for sharing. 
    
    > Best,
    > Filip
    
    thanks,
    Torsten. 
    
    > 
    > 
    > On Tue, 31 Dec 2019 at 15:38, Torsten Lodderstedt <[email-masked]> wrote:
    > Hi all,
    > 
    > Ronald just sent me an email asking whether we will define metadata for 
    > 
    > pushed_authorization_endpoint_auth_methods_supported and
    > pushed_authorization_endpoint_auth_signing_alg_values_supported.
    > 
    > The draft right now utilises the existing token endpoint authentication methods so there is basically no need to define another parameter. The same principle could be applied to signing (and encryption) algorithms as well. 
    > 
    > What’s your opinion?
    > 
    > best regards,
    > Torsten.

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Sat, 4 Jan 2020 12:31:31 +0200

Hi Annabelle,

We recently implemented PAR in a release. What security risks do AS
users face if the clients encrypt to the same JWK set?

If there are general issues with that, do they also hold for clients?
Because an OP / AS can potentially issue multiple types of encrypted
JWTs at separate endpoints:

  * Encrypted ID tokens
  * Encrypted UserInfo
  * Encrypted authZ responses (JARM)
  * Encrypted introspection responses

I like PAR because it was so easy and straightforward to explain to
client developers, and the benefits of having an authZ request submitted
directly to the AS were also easily understood (no limits on the size of
the request and it remaining hidden from the front-channel, the client
is authenticated before user auth / consent).

Vladimir

---

From: Brian Campbell <[email-masked]>
Date: Mon, 6 Jan 2020 06:57:23 -0700

I really struggle to see the assumption that an entity be able to use the
same key to decrypt the same type of message ultimately intended for the
same purpose as an artificial limit. The same general assumption
underlies everything else in OAuth/OIDC (Vladimir's post points to some but
not all examples of such). There's no reason for PAR to make a one-off
exception. And should there be some deployment specific reason that truly
requires that kind of isolation, there are certainly implementation options
that aren't compatibility-breaking. And having said all that, I'm honestly
a little surprised anyone is thinking much about encrypted request objects
with PAR as, at least with my limited imagination, there's not really a
need for it.

On Fri, Jan 3, 2020 at 2:43 PM Richard Backman, Annabelle <richanna=
[email-masked]> wrote:

> PAR introduces an added wrinkle for encrypted request objects: the PAR
> endpoint and authorization endpoint may not have access to the same
> cryptographic keys, even though they're both part of the "authorization
> server." Since they're different endpoints with different roles, it's
> reasonable to put them in separate trust boundaries. There is no way to
> support this isolation with just a single "jwks_uri" metadata property.
>
> I strongly perfer #1 as it has a very minor impact on deployments that
> don't care (i.e., they just set par_jwks_uri and jwks_uri to the same
> value) and failing to support this trust boundary creates an artificial
> limit on implementation architecture and could lead to
> compatibility-breaking workarounds.
>
> –
> On 12/31/19, 8:07 AM, "OAuth on behalf of Torsten Lodderstedt" <
> [email-masked] on behalf of torsten=
> [email-masked]> wrote:
>
>     Hi Filip,
>
>     > I don't think we need a *_auth_method_* metadata for every endpoint
> the client calls directly, none of the new specs defined these (e.g. device
> authorization endpoint or CIBA), meaning they also didn't follow the scheme
> from RFC 8414 where introspection and revocation got its own metadata. In
> most cases the unfortunately named `token_endpoint_auth_method` and its
> related metadata is what's used by clients for all direct calls anyway.
>     >
>     > This I do not follow, auth methods and their signing is dealt with
> by using `token_endpoint_auth_methods_supported` and
> `token_endpoint_auth_signing_alg_values_supported` - there's no encryption
> for the `_jwt` client auth methods.
>     > Unless it was meant to address the Request Object signing and
> encryption metadata, which is defined and IANA registered by OIDC. PAR only
> references JAR section 6.1 and 6.2 for decryption/signature validation and
> these do not mention the metadata (e.g. request_object_signing_alg) anymore
> since draft 07.
>
>     > The draft right now utilises the existing token endpoint
> authentication methods so there is basically no need to define another
> parameter. The same principle could be applied to signing (and encryption)
> algorithms as well.
>     >
>     > What’s your opinion?
>     >
>     > best regards,
>     > Torsten.
>
>
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> 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._

---

From: Neil Madden <[email-masked]>
Date: Mon, 6 Jan 2020 14:28:21 +0000

Agreed.

In addition, I'm not sure why the PAR endpoint would need access to the decryption keys at all. If you're using encrypted request objects then the PAR endpoint receives an encrypted JWT and then later makes the same (still encrypted) JWT available to the authorization endpoint. If the PAR endpoint is doing any kind of decryption or validation on behalf of the authorization endpoint then they are clearly not in separate trust boundaries.

-- Neil

> On 6 Jan 2020, at 13:57, Brian Campbell <bcampbell=[email-masked]> wrote:
> 
> I really struggle to see the assumption that an entity be able to use the same key to decrypt the same type of message ultimately intended for the same purpose as an artificial limit. The same general assumption   underlies everything else in OAuth/OIDC (Vladimir's post points to some but not all examples of such). There's no reason for PAR to make a one-off exception. And should there be some deployment specific reason that truly requires that kind of isolation, there are certainly implementation options that aren't compatibility-breaking. And having said all that, I'm honestly a little surprised anyone is thinking much about encrypted request objects with PAR as, at least with my limited imagination, there's not really a need for it. 
> 
> 
> 
> 
>  
> 
> 
> 
> On Fri, Jan 3, 2020 at 2:43 PM Richard Backman, Annabelle <richanna=[email-masked] <mailto:[email-masked]>> wrote:
> On 12/31/19, 8:07 AM, "OAuth on behalf of Torsten Lodderstedt" <[email-masked] <mailto:[email-masked]> on behalf of torsten=[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Hi Filip, 
> 
>     > On 31. Dec 2019, at 16:22, Filip Skokan <[email-masked] <mailto:[email-masked]>> wrote:
>     > 
>     > On Tue, 31 Dec 2019 at 15:38, Torsten Lodderstedt <[email-masked] <mailto:[email-masked]>> wrote:
>     > Hi all,
>     > 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> 
> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you._______________________________________________
> OAuth mailing list
> [email-masked]

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Mon, 6 Jan 2020 21:59:45 +0000

The issue isn’t that the PAR endpoint needs access to one specific request object decryption key that could reasonably be shared across AS endpoints, but that it actually needs access to the private keys for all encryption public keys in the JWK set pointed to by the AS’s jwks_uri metadata property. Since there is no way to designate one particular key as the one to use for encrypting request objects, clients may reasonably use any encryption public key in the JWK set to encrypt a request object. As one example of how this could expose sensitive data to the PAR endpoint, if the PAR endpoint has all the decryption keys for the keys in the AS’s JWK set, it would be able to decrypt ID Tokens sent in id_token_hint request parameters. As more and more use cases develop for encrypting blobs for the AS, this issue will only get worse.

The PAR endpoint can’t simply stash the encrypted request object, as it is required to verify the request, according to §2.1:

The AS MUST process the request as follows:

...

3.  The AS MUST validate the request in the same way as at the

          authorization endpoint. ...

This language needs to be more flexible, IMHO, to allow for lightweight PAR endpoints that may not have the information or authority needed to perform all the validation that happens at the authorization endpoint. I need to think about this more before I can say if it would adequately address my concerns, but it’d be a good start and makes sense in its own right.

I think it’s pretty risky for us to base decision on an assumption that no one is going to need or want to encrypt pushed request objects, particularly when they’re JWTs, and JWTs have well established support for encryption, and encrypted JWTs are supported by pass-by-value in OIDC and draft-ietf-oauth-jwsreq. But if you insist, here are a few examples for why someone might want to do this:

  1.  The request object is passed by reference, and accessible on the public Internet.
  2.  The request object contains sensitive transaction-related data in RAR parameters that the client’s authN/authZ stack doesn’t need to have access to.
  3.  The AS requires request object encryption to minimize exposure to the hosted PAR endpoint service it uses.
  4.  #2, but the threat vector is gaps in end-to-end TLS.
  5.  Any of the above, but the concern is message integrity, and the AS requires requested objects to be encrypted for confidentiality and integrity protection and does not support signed request objects.

–

From: Neil Madden <[email-masked]>
Date: Monday, January 6, 2020 at 6:29 AM
To: Brian Campbell <[email-masked]>
Cc: "Richard Backman, Annabelle" <[email-masked]>, Nat Sakimura <[email-masked]>, Dave Tonge <[email-masked]>, Torsten Lodderstedt <[email-masked]>, oauth <[email-masked]>
Subject: [UNVERIFIED SENDER] Re: [OAUTH-WG] PAR metadata

Agreed.

-- Neil

On 6 Jan 2020, at 13:57, Brian Campbell <bcampbell=[email-masked]<mailto:bcampbell=[email-masked]>> wrote:

On Fri, Jan 3, 2020 at 2:43 PM Richard Backman, Annabelle <richanna=[email-masked]<mailto:[email-masked]>> wrote:
PAR introduces an added wrinkle for encrypted request objects: the PAR endpoint and authorization endpoint may not have access to the same cryptographic keys, even though they're both part of the "authorization server." Since they're different endpoints with different roles, it's reasonable to put them in separate trust boundaries. There is no way to support this isolation with just a single "jwks_uri" metadata property.

–

On 12/31/19, 8:07 AM, "OAuth on behalf of Torsten Lodderstedt" <[email-masked]<mailto:[email-masked]> on behalf of torsten=[email-masked]<mailto:[email-masked]>> wrote:

    Hi Filip,

    > On 31. Dec 2019, at 16:22, Filip Skokan <[email-masked]<mailto:[email-masked]>> wrote:
    >

    Thanks for sharing.

    thanks,
    Torsten.

    >
    >
    > On Tue, 31 Dec 2019 at 15:38, Torsten Lodderstedt <[email-masked]<mailto:[email-masked]>> wrote:
    > Hi all,
    >

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you._______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: Filip Skokan <[email-masked]>
Date: Mon, 6 Jan 2020 23:22:09 +0100

We've been discussing making the following change to the language

The AS SHOULD validate the request in the same way as at the authorization
> endpoint. The AS MUST ensure that all parameters to the authorization
> request are still valid at the time when the request URI is used.
>

This would allow the PAR endpoint to simply stash the encrypted request
object instead of decrypting and validating it. All within the bounds of
"SHOULD - We’d like you to do this, but we can’t always require it". This
supports "light weight PAR" implementation rather than introducing the
unnecessary complexity in the form of a second JWKS.

Best,
*Filip*

On Mon, 6 Jan 2020 at 23:00, Richard Backman, Annabelle <richanna=
[email-masked]> wrote:

> The issue isn’t that the PAR endpoint needs access to one specific request
> object decryption key that could reasonably be shared across AS endpoints,
> but that it actually needs access to the private keys for all encryption
> public keys in the JWK set pointed to by the AS’s jwks_uri metadata
> property. Since there is no way to designate one particular key as the one
> to use for encrypting request objects, clients may reasonably use any
> encryption public key in the JWK set to encrypt a request object. As one
> example of how this could expose sensitive data to the PAR endpoint, if the
> PAR endpoint has all the decryption keys for the keys in the AS’s JWK set,
> it would be able to decrypt ID Tokens sent in id_token_hint request
> parameters. As more and more use cases develop for encrypting blobs for the
> AS, this issue will only get worse.
>
>
>
> The PAR endpoint can’t simply stash the encrypted request object, as it is
> required to verify the request, according to §2.1:
>
>
>
> This language needs to be more flexible, IMHO, to allow for lightweight
> PAR endpoints that may not have the information or authority needed to
> perform all the validation that happens at the authorization endpoint. I
> need to think about this more before I can say if it would adequately
> address my concerns, but it’d be a good start and makes sense in its own
> right.
>
>
>
> I think it’s pretty risky for us to base decision on an assumption that no
> one is going to need or want to encrypt pushed request objects,
> particularly when they’re JWTs, and JWTs have well established support for
> encryption, and encrypted JWTs are supported by pass-by-value in OIDC and
> draft-ietf-oauth-jwsreq. But if you insist, here are a few examples for why
> someone might want to do this:
>
>    2. The request object contains sensitive transaction-related data in
>    RAR parameters that the client’s authN/authZ stack doesn’t need to have
>    access to.
>    5. Any of the above, but the concern is message integrity, and the AS
>    requires requested objects to be encrypted for confidentiality and
>    integrity protection and does not support signed request objects.
>
>
>
> –
>
> *From: *Neil Madden <[email-masked]>
> *Date: *Monday, January 6, 2020 at 6:29 AM
> *To: *Brian Campbell <[email-masked]>
> *Cc: *"Richard Backman, Annabelle" <[email-masked]>, Nat Sakimura <
> [email-masked]>, Dave Tonge <[email-masked]>, Torsten
> Lodderstedt <[email-masked]>, oauth <[email-masked]>
> *Subject: *[UNVERIFIED SENDER] Re: [OAUTH-WG] PAR metadata
>
>
>
> Agreed.
>
>
>
> In addition, I'm not sure why the PAR endpoint would need access to the
> decryption keys at all. If you're using encrypted request objects then the
> PAR endpoint receives an encrypted JWT and then later makes the same (still
> encrypted) JWT available to the authorization endpoint. If the PAR endpoint
> is doing any kind of decryption or validation on behalf of the
> authorization endpoint then they are clearly not in separate trust
> boundaries.
>
>
>
> -- Neil
>
>
>
>
>
> On 6 Jan 2020, at 13:57, Brian Campbell <
> bcampbell=[email-masked]> wrote:
>
>
>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited..
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you.*_______________________________________________
> OAuth mailing list
> [email-masked]

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Tue, 7 Jan 2020 15:52:29 +0200

Just to comment that with a lightweight PAR (stash-only) endpoint one of
the nice benefits of PAR will be lost - to pre-validate the request
(client_id, redirect_uri, etc) as much as possible before a front-end
call is made and the user is sent to the authZ endpoint.

Vladimir

On 06/01/2020 23:59, Richard Backman, Annabelle wrote:
>
> The issue isn’t that the PAR endpoint needs access to one specific
> request object decryption key that could reasonably be shared across
> AS endpoints, but that it actually needs access to the private keys
> for all encryption public keys in the JWK set pointed to by the AS’s
> jwks_uri metadata property. Since there is no way to designate one
> particular key as the one to use for encrypting request objects,
> clients may reasonably use any encryption public key in the JWK set to
> encrypt a request object. As one example of how this could expose
> sensitive data to the PAR endpoint, if the PAR endpoint has all the
> decryption keys for the keys in the AS’s JWK set, it would be able to
> decrypt ID Tokens sent in id_token_hint request parameters. As more
> and more use cases develop for encrypting blobs for the AS, this issue
> will only get worse.
>
>  
>
> The PAR endpoint can’t simply stash the encrypted request object, as
> it is required to verify the request, according to §2.1:
>
>  
>
> This language needs to be more flexible, IMHO, to allow for
> lightweight PAR endpoints that may not have the information or
> authority needed to perform all the validation that happens at the
> authorization endpoint. I need to think about this more before I can
> say if it would adequately address my concerns, but it’d be a good
> start and makes sense in its own right.
>
>  
>
> I think it’s pretty risky for us to base decision on an assumption
> that no one is going to need or want to encrypt pushed request
> objects, particularly when they’re JWTs, and JWTs have well
> established support for encryption, and encrypted JWTs are supported
> by pass-by-value in OIDC and draft-ietf-oauth-jwsreq. But if you
> insist, here are a few examples for why someone might want to do this:
>
>     RAR parameters that the client’s authN/authZ stack doesn’t need to
>     have access to.
> *Cc: *"Richard Backman, Annabelle" <[email-masked]>, Nat Sakimura
> <[email-masked]>, Dave Tonge <[email-masked]>, Torsten
> In addition, I'm not sure why the PAR endpoint would need access to
> the decryption keys at all. If you're using encrypted request objects
> then the PAR endpoint receives an encrypted JWT and then later makes
> the same (still encrypted) JWT available to the authorization
> endpoint. If the PAR endpoint is doing any kind of decryption or
> validation on behalf of the authorization endpoint then they are
> clearly not in separate trust boundaries.
>
>  
>
> -- Neil
>
>  
>
>
>
>     On 6 Jan 2020, at 13:57, Brian Campbell
>     <bcampbell=[email-masked]
>     <mailto:bcampbell=[email-masked]>> wrote:
>
>      
>
>     I really struggle to see the assumption that an entity be able to
>     use the same key to decrypt the same type of message ultimately
>     intended for the same purpose as an artificial limit. The same
>     general assumption   underlies everything else in OAuth/OIDC
>     (Vladimir's post points to some but not all examples of such).
>     There's no reason for PAR to make a one-off exception. And should
>     there be some deployment specific reason that truly requires that
>     kind of isolation, there are certainly implementation options that
>     aren't compatibility-breaking. And having said all that, I'm
>     honestly a little surprised anyone is thinking much about
>     encrypted request objects with PAR as, at least with my limited
>     imagination, there's not really a need for it.
>
>      
>
>      
>
>      
>
>      
>
>      
>
>      
>
>      
>
>      
>
>     On Fri, Jan 3, 2020 at 2:43 PM Richard Backman, Annabelle
>     <richanna=[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>         PAR introduces an added wrinkle for encrypted request objects:
>         the PAR endpoint and authorization endpoint may not have
>         access to the same cryptographic keys, even though they're
>         both part of the "authorization server." Since they're
>         different endpoints with different roles, it's reasonable to
>         put them in separate trust boundaries. There is no way to
>         I strongly perfer #1 as it has a very minor impact on
>         deployments that don't care (i.e., they just set par_jwks_uri
>         and jwks_uri to the same value) and failing to support this
>         trust boundary creates an artificial limit on implementation
>         architecture and could lead to compatibility-breaking workarounds.
>
>         –
>         On 12/31/19, 8:07 AM, "OAuth on behalf of Torsten Lodderstedt"
>         <[email-masked] <mailto:[email-masked]> on
>         behalf of torsten=[email-masked]
>         <mailto:[email-masked]>> wrote:
>
>             Hi Filip,
>
>             > On 31. Dec 2019, at 16:22, Filip Skokan
>         <[email-masked] <mailto:[email-masked]>> wrote:
>             >
>             > I don't think we need a *_auth_method_* metadata for
>         every endpoint the client calls directly, none of the new
>         specs defined these (e.g. device authorization endpoint or
>         CIBA), meaning they also didn't follow the scheme from RFC
>         8414 where introspection and revocation got its own metadata.
>         In most cases the unfortunately named
>         `token_endpoint_auth_method` and its related metadata is
>         what's used by clients for all direct calls anyway.
>             >
>             > The same principle could be applied to signing (and
>         encryption) algorithms as well.
>             >
>             > This I do not follow, auth methods and their signing is
>         dealt with by using `token_endpoint_auth_methods_supported`
>         and `token_endpoint_auth_signing_alg_values_supported` -
>         there's no encryption for the `_jwt` client auth methods.
>             > Unless it was meant to address the Request Object
>         signing and encryption metadata, which is defined and IANA
>         registered by OIDC. PAR only references JAR section 6.1 and
>         6.2 for decryption/signature validation and these do not
>         mention the metadata (e.g. request_object_signing_alg) anymore
>         since draft 07.
>
>             >
>             > PS: I also found this comment related to the same
>         question about auth metadata but for CIBA.
>
>             Thanks for sharing.
>
>             >
>             > Best,
>             > Filip
>
>             thanks,
>             Torsten.
>
>             >
>             >
>             > On Tue, 31 Dec 2019 at 15:38, Torsten Lodderstedt
>         <[email-masked] <mailto:[email-masked]>> wrote:
>             > Hi all,
>             >
>             > Ronald just sent me an email asking whether we will
>         define metadata for
>             >
>             > pushed_authorization_endpoint_auth_methods_supported and
>             >
>             >
>             > The draft right now utilises the existing token endpoint
>         authentication methods so there is basically no need to define
>         another parameter. The same principle could be applied to
>         signing (and encryption) algorithms as well.
>             >
>             > What’s your opinion?
>             >
>             > best regards,
>             > Torsten.
>
>
>
>     */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

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Tue, 7 Jan 2020 15:58:21 +0200

On 07/01/2020 00:22, Filip Skokan wrote:
>     The AS SHOULD validate the request in the same way as at the
>     authorization endpoint. The AS MUST ensure that all parameters to
>     the authorization request are still valid at the time when the
>     request URI is used.
>
Could you expand a bit on the second sentence?

Alternative suggestion:

The AS MUST validate the request in the same way as at the authorization
endpoint, or complete the request validation at the authorization endpoint.

Vladimir

> This would allow the PAR endpoint to simply stash the encrypted
> request object instead of decrypting and validating it. All within the
> bounds of "SHOULD - We’d like you to do this, but we can’t always
> require it". This supports "light weight PAR" implementation rather
> than introducing the unnecessary complexity in the form of a second JWKS.
>
> Best,
> *Filip*
>
>
> On Mon, 6 Jan 2020 at 23:00, Richard Backman, Annabelle
>     request object decryption key that could reasonably be shared
>     across AS endpoints, but that it actually needs access to the
>     private keys for all encryption public keys in the JWK set pointed
>     to by the AS’s jwks_uri metadata property. Since there is no way
>     to designate one particular key as the one to use for encrypting
>     request objects, clients may reasonably use any encryption public
>     key in the JWK set to encrypt a request object. As one example of
>     how this could expose sensitive data to the PAR endpoint, if the
>     PAR endpoint has all the decryption keys for the keys in the AS’s
>     JWK set, it would be able to decrypt ID Tokens sent in
>     id_token_hint request parameters. As more and more use cases
>     develop for encrypting blobs for the AS, this issue will only get
>     worse.
>
>      
>
>     The PAR endpoint can’t simply stash the encrypted request object,
>     as it is required to verify the request, according to §2.1:
>
>      
>
>     authorization endpoint. I need to think about this more before I
>     can say if it would adequately address my concerns, but it’d be a
>     good start and makes sense in its own right.
>
>      
>
>     established support for encryption, and encrypted JWTs are
>     supported by pass-by-value in OIDC and draft-ietf-oauth-jwsreq.
>     But if you insist, here are a few examples for why someone might
>     want to do this:
>
>      2. The request object contains sensitive transaction-related data
>         in RAR parameters that the client’s authN/authZ stack doesn’t
>         need to have access to.
>      3. The AS requires request object encryption to minimize exposure
>         to the hosted PAR endpoint service it uses.
>      5. Any of the above, but the concern is message integrity, and
>         the AS requires requested objects to be encrypted for
>         confidentiality and integrity protection and does not support
>         signed request objects.
>
>      
>
>     – 
>
>     *From: *Neil Madden <[email-masked]
>     <mailto:[email-masked]>>
>     *To: *Brian Campbell <[email-masked]
>     <mailto:[email-masked]>>
>     *Cc: *"Richard Backman, Annabelle" <[email-masked]
>     <mailto:[email-masked]>>, Nat Sakimura <[email-masked]
>     <mailto:[email-masked]>>, Dave Tonge <[email-masked]
>     <mailto:[email-masked]>>, Torsten Lodderstedt
>     <torsten@lodderstedt..net <mailto:[email-masked]>>, oauth
>     <[email-masked] <mailto:[email-masked]>>
>     In addition, I'm not sure why the PAR endpoint would need access
>     to the decryption keys at all. If you're using encrypted request
>     objects then the PAR endpoint receives an encrypted JWT and then
>     later makes the same (still encrypted) JWT available to the
>     authorization endpoint. If the PAR endpoint is doing any kind of
>     decryption or validation on behalf of the authorization endpoint
>     then they are clearly not in separate trust boundaries.
>
>      
>
>     -- Neil
>
>      
>
>
>
>         I really struggle to see the assumption that an entity be able
>         to use the same key to decrypt the same type of message
>         ultimately intended for the same purpose as an artificial
>         limit. The same general assumption   underlies everything else
>         in OAuth/OIDC (Vladimir's post points to some but not all
>         examples of such). There's no reason for PAR to make a one-off
>         exception. And should there be some deployment specific reason
>         that truly requires that kind of isolation, there are
>         certainly implementation options that aren't
>         compatibility-breaking. And having said all that, I'm honestly
>         a little surprised anyone is thinking much about encrypted
>         request objects with PAR as, at least with my limited
>             PAR introduces an added wrinkle for encrypted request
>             objects: the PAR endpoint and authorization endpoint may
>             not have access to the same cryptographic keys, even
>             though they're both part of the "authorization server."
>             Since they're different endpoints with different roles,
>             it's reasonable to put them in separate trust boundaries.
>             There is no way to support this isolation with just a
>             single "jwks_uri" metadata property.
>
>             deployments that don't care (i.e., they just set
>             par_jwks_uri and jwks_uri to the same value) and failing
>             to support this trust boundary creates an artificial limit
>             on implementation architecture and could lead to
>             On 12/31/19, 8:07 AM, "OAuth on behalf of Torsten
>             Lodderstedt" <[email-masked]
>             <mailto:[email-masked]> on behalf of
>             torsten=[email-masked]
>             8414 where introspection and revocation got its own
>             metadata. In most cases the unfortunately named
>                 > This I do not follow, auth methods and their signing
>             is dealt with by using
>             `token_endpoint_auth_methods_supported` and
>             `token_endpoint_auth_signing_alg_values_supported` -
>             registered by OIDC. PAR only references JAR section 6.1
>             and 6.2 for decryption/signature validation and these do
>             not mention the metadata (e.g. request_object_signing_alg)
>             anymore since draft 07.
>
>                 > The draft right now utilises the existing token
>             endpoint authentication methods so there is basically no
>             need to define another parameter. The same principle could
>             be applied to signing (and encryption) algorithms as well.
>                 >
>                 > What’s your opinion?
>                 >
>                 > best regards,
>                 > Torsten.
>
>
>

---

From: Brian Campbell <[email-masked]>
Date: Tue, 7 Jan 2020 15:53:53 -0700

A little more context about that proposed wording is in a github issue at
https://github.com/oauthstuff/draft-oauth-par/issues/38, which is different
driver than allowing a PAR endpoint to stash the encrypted request object
rather than decrypting/validating it. But it's kind of the same concept at
some level too - that there are some things that can't or won't be
validated at the PAR endpoint and those then have to be validated at the
authorization endpoint.

I rather like your suggested text, Vladimir, and have mentioned it in a
comment on the aforementioned issue.

On Tue, Jan 7, 2020 at 6:58 AM Vladimir Dzhuvinov <[email-masked]>
wrote:

>> request object decryption key that could reasonably be shared across AS
>> endpoints, but that it actually needs access to the private keys for all
>> encryption public keys in the JWK set pointed to by the AS’s jwks_uri
>> metadata property. Since there is no way to designate one particular key as
>> the one to use for encrypting request objects, clients may reasonably use
>> any encryption public key in the JWK set to encrypt a request object. As
>> one example of how this could expose sensitive data to the PAR endpoint, if
>> the PAR endpoint has all the decryption keys for the keys in the AS’s JWK
>> set, it would be able to decrypt ID Tokens sent in id_token_hint request
>> The PAR endpoint can’t simply stash the encrypted request object, as it
>> is required to verify the request, according to §2.1:
>>
>>
>>
>> I think it’s pretty risky for us to base decision on an assumption that
>> no one is going to need or want to encrypt pushed request objects,
>> Lodderstedt <torsten@lodderstedt..net <[email-masked]>>, oauth <
>> [email-masked]>

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Wed, 8 Jan 2020 02:25:01 +0000

I think it’s clearer if we split out the requirements for the PAR endpoint and the requirements for the authorization endpoint, given that they are each covered in different sections of the doc (2 and 4, respectively). With that in mind, here are a couple suggestions:

For the text in Section 2.1:

3.  The AS MUST validate the pushed request as it would an authorization
    request sent to the authorization endpoint, however the AS MAY omit
    validation steps that it is unable to perform when processing the
    pushed request.

Additional text for Section 4 (note that this section pertains to the authorization endpoint):

The AS MUST validate authorization requests arising from a pushed request as
it would any other authorization request.  The AS MAY omit validation steps
that it performed when the request was pushed, provided that it can validate
that the request was a pushed request, and that the request has not been
modified in a way that would affect the outcome of the omitted steps.

This is longer than the current text and the other proposals, but it adds a few important points:

  *   Turns the 2.1 SHOULD back into a MUST, with an explicit exception for validation that can’t be done yet.
  *   Reinforces the fact that the authorization endpoint still needs to do validation.
  *   Clearly states requirements for when an AS can trust that validation happened at the PAR endpoint.

–

From: Brian Campbell <bcampbell=[email-masked]>
Date: Tuesday, January 7, 2020 at 2:54 PM
To: Vladimir Dzhuvinov <[email-masked]>
Cc: Filip Skokan <[email-masked]>, "Richard Backman, Annabelle" <[email-masked]>, Dave Tonge <[email-masked]>, oauth <[email-masked]>, Nat Sakimura <[email-masked]>
Subject: [UNVERIFIED SENDER] Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: PAR metadata

A little more context about that proposed wording is in a github issue at https://github.com/oauthstuff/draft-oauth-par/issues/38, which is different driver than allowing a PAR endpoint to stash the encrypted request object rather than decrypting/validating it. But it's kind of the same concept at some level too - that there are some things that can't or won't be validated at the PAR endpoint and those then have to be validated at the authorization endpoint..

I rather like your suggested text, Vladimir, and have mentioned it in a comment on the aforementioned issue.

On Tue, Jan 7, 2020 at 6:58 AM Vladimir Dzhuvinov <[email-masked]<mailto:[email-masked]>> wrote:
On 07/01/2020 00:22, Filip Skokan wrote:
We've been discussing making the following change to the language

The AS SHOULD validate the request in the same way as at the authorization endpoint. The AS MUST ensure that all parameters to the authorization request are still valid at the time when the request URI is used.

Alternative suggestion:

The AS MUST validate the request in the same way as at the authorization endpoint, or complete the request validation at the authorization endpoint.

Vladimir

This would allow the PAR endpoint to simply stash the encrypted request object instead of decrypting and validating it. All within the bounds of "SHOULD - We’d like you to do this, but we can’t always require it". This supports "light weight PAR" implementation rather than introducing the unnecessary complexity in the form of a second JWKS.

Best,
Filip

On Mon, 6 Jan 2020 at 23:00, Richard Backman, Annabelle <richanna=[email-masked]<mailto:[email-masked]>> wrote:
The issue isn’t that the PAR endpoint needs access to one specific request object decryption key that could reasonably be shared across AS endpoints, but that it actually needs access to the private keys for all encryption public keys in the JWK set pointed to by the AS’s jwks_uri metadata property. Since there is no way to designate one particular key as the one to use for encrypting request objects, clients may reasonably use any encryption public key in the JWK set to encrypt a request object. As one example of how this could expose sensitive data to the PAR endpoint, if the PAR endpoint has all the decryption keys for the keys in the AS’s JWK set, it would be able to decrypt ID Tokens sent in id_token_hint request parameters. As more and more use cases develop for encrypting blobs for the AS, this issue will only get worse.

....

–

From: Neil Madden <[email-masked]<mailto:[email-masked]>>
Date: Monday, January 6, 2020 at 6:29 AM
To: Brian Campbell <[email-masked]<mailto:[email-masked]>>
Cc: "Richard Backman, Annabelle" <[email-masked]<mailto:[email-masked]>>, Nat Sakimura <[email-masked]<mailto:[email-masked]>>, Dave Tonge <[email-masked]<mailto:[email-masked]>>, Torsten Lodderstedt <torsten@lodderstedt..net<mailto:[email-masked]>>, oauth <[email-masked]<mailto:[email-masked]>>
Subject: [UNVERIFIED SENDER] Re: [OAUTH-WG] PAR metadata

Agreed.

-- Neil

–

    Hi Filip,

    Thanks for sharing.

    thanks,
    Torsten.

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.

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 8 Jan 2020 11:10:39 +0100

Hi Annabelle, 

thanks for your proposal, which reads reasonable to me. 

I suggest to extend “and that the request has not been modified in a way that would affect the outcome of the omitted steps.” a bit to also consider policy changes that may have occurred between push and authorization request processing. 

"and that the request or the authorization server’s policy has not been modified in a way that would affect the outcome of the omitted steps."

best regards,
Torsten. 

> On 8. Jan 2020, at 03:25, Richard Backman, Annabelle <richanna=[email-masked]> wrote:
> 
> 	• Turns the 2.1 SHOULD back into a MUST, with an explicit exception for validation that can’t be done yet.
> 	• Reinforces the fact that the authorization endpoint still needs to do validation.
> 	• Clearly states requirements for when an AS can trust that validation happened at the PAR endpoint.
>  
> – 
>>>> 	•
>>>> 	•
>>>> 	•
>>>> 	•
>>>> 	•
https://github.com/oauthstuff/draft-oauth-par/issues/38, which is different driver than allowing a PAR endpoint to stash the encrypted request object rather than decrypting/validating it. But it's kind of the same concept at some level too - that there are some things that can't or won't be validated at the PAR endpoint and those then have to be validated at the authorization endpoint..

On Tue, Jan 7, 2020 at 6:58 AM Vladimir Dzhuvinov <[email-masked]> wrote:
On 07/01/2020 00:22, Filip Skokan wrote:
We've been discussing making the following change to the language

Best,
Filip

On Mon, 6 Jan 2020 at 23:00, Richard Backman, Annabelle <richanna=[email-masked]> wrote:
The issue isn’t that the PAR endpoint needs access to one specific request object decryption key that could reasonably be shared across AS endpoints, but that it actually needs access to the private keys for all encryption public keys in the JWK set pointed to by the AS’s jwks_uri metadata property. Since there is no way to designate one particular key as the one to use for encrypting request objects, clients may reasonably use any encryption public key in the JWK set to encrypt a request object. As one example of how this could expose sensitive data to the PAR endpoint, if the PAR endpoint has all the decryption keys for the keys in the AS’s JWK set, it would be able to decrypt ID Tokens sent in id_token_hint request parameters. As more and more use cases develop for encrypting blobs for the AS, this issue will only get worse.

 
....

The request object is passed by reference, and accessible on the public Internet.
The request object contains sensitive transaction-related data in RAR parameters that the client’s authN/authZ stack doesn’t need to have access to.
The AS requires request object encryption to minimize exposure to the hosted PAR endpoint service it uses.
#2, but the threat vector is gaps in end-to-end TLS.
Any of the above, but the concern is message integrity, and the AS requires requested objects to be encrypted for confidentiality and integrity protection and does not support signed request objects.

– 

AWS Identity

Cc: "Richard Backman, Annabelle" <[email-masked]>, Nat Sakimura <[email-masked]>, Dave Tonge <[email-masked]>, Torsten Lodderstedt <torsten@lodderstedt..net>, oauth <[email-masked]>

Agreed.

-- Neil

 

 

On Fri, Jan 3, 2020 at 2:43 PM Richard Backman, Annabelle <richanna=[email-masked]> wrote:

– 

    Hi Filip, 

    Thanks for sharing. 

    thanks,
    Torsten.

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Wed, 8 Jan 2020 20:46:58 +0000

I almost included text to that effect, but thought it was getting too wordy. However your suggestion is simple and concise. +1

Given all of this discussion, we should include a section on request validation in Security Considerations, to provide some context on what might be validated when and where, what kinds of problems deployments need to consider, etc. I think this is useful to have in the document, but would be too much clutter in the main body. We should keep that focused on the precise normative requirements.

– 

On 1/8/20, 2:11 AM, "Torsten Lodderstedt" <torsten=[email-masked]> wrote:

    Hi Annabelle, 

    
    
    best regards,
    Torsten. 

     

    Best,
    Filip

    

     
    .....

    

    – 

    AWS Identity

    
    Agreed.

    
    -- Neil

    

     

     

    

    
    
    – 

        Hi Filip, 

    
    
        Thanks for sharing. 

        thanks,
        Torsten.

---

From: Justin Richer <[email-masked]>
Date: Fri, 10 Jan 2020 09:56:12 -0500

I just want to add that the requirement to validate the request at PAR the same way as you would at the auth endpoint is something that I want to see relaxed, and I hope it doesn’t make it through to the final standard. 

Also keep in mind that this is barely started as a WG document so any requirement is soft at best. When discussing things like this, we should keep this in mind by discussing the consequences of having a phrase in there, not behaving as if things are unchangeable. 

 — Justin

> On Jan 6, 2020, at 4:59 PM, Richard Backman, Annabelle <richanna=[email-masked]> wrote:
> 
> From: Neil Madden <[email-masked] <mailto:[email-masked]>>
> To: Brian Campbell <[email-masked] <mailto:[email-masked]>>
> Cc: "Richard Backman, Annabelle" <[email-masked] <mailto:[email-masked]>>, Nat Sakimura <[email-masked] <mailto:[email-masked]>>, Dave Tonge <[email-masked] <mailto:[email-masked]>>, Torsten Lodderstedt <[email-masked] <mailto:[email-masked]>>, oauth <[email-masked] <mailto:[email-masked]>>
>> On 6 Jan 2020, at 13:57, Brian Campbell <bcampbell=[email-masked] <mailto:bcampbell=[email-masked]>> wrote:
>>

---

From: Justin Richer <[email-masked]>
Date: Fri, 10 Jan 2020 11:42:48 -0500

+1 to this being a security consideration

 — Justin

> On Jan 8, 2020, at 3:46 PM, Richard Backman, Annabelle <richanna=[email-masked]> wrote:
>