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

[Vladimir Dzhuvinov <[e-mail]>]

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:
>
>  
>
> 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
>
>  
>