Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: PAR metadata

["Richard Backman, Annabelle" <[e-mail]>]

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.

–
Annabelle Richard Backman
AWS Identity


From: Neil Madden <[e-mail]>
Date: Monday, January 6, 2020 at 6:29 AM
To: Brian Campbell <[e-mail]>
Cc: "Richard Backman, Annabelle" <[e-mail]>, Nat Sakimura <[e-mail]>, Dave Tonge <[e-mail]>, Torsten Lodderstedt <[e-mail]>, oauth <[e-mail]>
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=[e-mail]<mailto:bcampbell=[e-mail]>> 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=[e-mail]<mailto:[e-mail]>> 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.

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" <[e-mail]<mailto:[e-mail]> on behalf of torsten=[e-mail]<mailto:[e-mail]>> wrote:

    Hi Filip,

    > On 31. Dec 2019, at 16:22, Filip Skokan <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>> 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.



_______________________________________________
OAuth mailing list
[e-mail]<mailto:[e-mail]>
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
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/oauth