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

[Vladimir Dzhuvinov <[e-mail]>]

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