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

[Filip Skokan <[e-mail]>]

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=
[e-mail]> 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:
>
>
>
> 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]> 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]> 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] on behalf of torsten=
> [e-mail]> wrote:
>
>     Hi Filip,
>
>     > On 31. Dec 2019, at 16:22, Filip Skokan <[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]> 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]
> 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]
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>