Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authorization Request (JAR) vs OIDC request object

[Vladimir Dzhuvinov <[e-mail]>]

On 14/01/2020 19:20, Takahiko Kawasaki wrote:
> Well, embedding a client_id claim in the JWE header in order to
> achieve "request parameters outside the request object should not be
> referred to" is like "putting the cart before the horse". Why do we
> have to avoid using the traditional client_id request parameter so
> stubbornly?
>
> The last paragraph of Section 3.2.1
> <https://tools.ietf.org/html/rfc6749#section-3.2.1> of RFC 6749 says
> as follows.
>
>     /A client MAY use the "client_id" request parameter to identify
>     itself when sending requests to the token endpoint.  In the
>     "authorization_code" "grant_type" request to the token endpoint,
>     *an unauthenticated client MUST send its "client_id" to prevent
>     itself from inadvertently accepting a code intended for a client
>     with a different "client_id".*  This protects the client from
>     substitution of the authentication code.  (It provides no
>     additional security for the protected resource.)/
>
>
> If the same reasoning applies, a client_id must always be sent with
> request / request_uri because client authentication is not performed
> at the authorization endpoint. In other words, */an unauthenticated
> client (every client is unauthenticated at the authorization endpoint)
> MUST send its "client_id" to prevent itself from inadvertently
> accepting a request object for a client with a different "client_id"./*
>
Identifying the client in JAR request_uri requests can be really useful
so that an AS which requires request_uri registration to prevent DDoS
attacks and other checks can do those without having to index all
request_uris individually. I mentioned this before.

I really wonder what the reasoning of the IESG reviewers was to insist
on no params outside the JAR JWT / request_uri.

I'm beginning to realise this step of the review process isn't
particularly transparent to WG members.

Vladimir


> Best Regards,
> Taka
>
>
>
> On Tue, Jan 14, 2020 at 12:57 AM Vladimir Dzhuvinov
> <[e-mail] <mailto:[e-mail]>> wrote:
>
>     John, thanks, much appreciated!
>
>     On 11/01/2020 21:36, John Bradley wrote:
>>
>>     Yes JAR is not prohibiting paramater replication in the header. 
>>
>>     I will see if i can add something in final edits to call that out.
>>
>>     John B.
>>
>>     On 1/11/2020 6:16 AM, Vladimir Dzhuvinov wrote:
>>>
>>>     Thanks Mike for the rfc7519 section-5.3
>>>     <https://tools.ietf.org/html/rfc7519#section-5.3> pointer. Can
>>>     this parameter replication be used for client_id or the
>>>     client_id ass "iss" even though it isn't explicitly mentioned in
>>>     the JAR spec?
>>>
>>>     On 11/01/2020 02:58, John Bradley wrote:
>>>>     Right we just don't say to put the iss there in OIDC if it's
>>>>     symetricly encrypted.
>>>
>>>     OIDC doesn't have the symmetric key selection issue, I suppose
>>>     that why the possibility to replicate params to the JWE header
>>>     isn't mentioned at all. OIDC requires the top-level query params
>>>     to represent a valid OAuth 2.0 request, and there client_id is
>>>     required. If the client_id is present the client registration
>>>     together with any present client_secret can be retrieved.
>>>
>>>     I reread the JAR spec, this is the only place that mentions
>>>     handling of symmetric JWE.
>>>
>>>     https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-20#section-10.2
>>>
>>>>        (b)  Verifying that the symmetric key for the JWE encryption is the
>>>>             correct one if the JWE is using symmetric encryption.
>>>
>>>
>>>     Vladimir
>>>
>>>
>>>>
>>>>     On Fri, Jan 10, 2020, 9:41 PM Mike Jones
>>>>     <[e-mail]
>>>>     <mailto:[e-mail]>> wrote:
>>>>
>>>>         The technique of replicating JWT claims that need to be
>>>>         publicly visible in an encrypted JWT in the header is
>>>>         defined at
>>>>         https://tools.ietf.org/html/rfc7519#section-5.3.  (Thanks
>>>>         to Dick Hardt for bringing this need to my attention as we
>>>>         were finishing the JWT spec.)
>>>>
>>>>          
>>>>
>>>>                                                                -- Mike
>>>>
>>>>          
>>>>
>>>>         *From:* OAuth <[e-mail]
>>>>         <mailto:[e-mail]>> *On Behalf Of * John Bradley
>>>>         *Sent:* Friday, January 10, 2020 2:15 PM
>>>>         *To:* Vladimir Dzhuvinov <[e-mail]
>>>>         <mailto:[e-mail]>>
>>>>         *Cc:* IETF oauth WG <[e-mail] <mailto:[e-mail]>>
>>>>         *Subject:* [EXTERNAL] Re: [OAUTH-WG] JWT Secured
>>>>         Authorization Request (JAR) vs OIDC request object
>>>>
>>>>          
>>>>
>>>>         The intent was to do that, but specs change once the OAuth
>>>>         WG and IESG get there hands on them.  
>>>>
>>>>          
>>>>
>>>>         Being backwards compatible with OIDC is not a compelling
>>>>         argument to the IESG.
>>>>
>>>>          
>>>>
>>>>         We were mostly thinking of asymmetric encryption.  
>>>>
>>>>          
>>>>
>>>>         Specifying puting the issuer and or the audience in the
>>>>         headder has come up in the past but probably is not
>>>>         documented.  
>>>>
>>>>          
>>>>
>>>>         John B 
>>>>
>>>>          
>>>>
>>>>         On Fri, Jan 10, 2020, 6:29 PM Vladimir Dzhuvinov
>>>>         <[e-mail] <mailto:[e-mail]>>
>>>>         wrote:
>>>>
>>>>             Yes, putting the client_id into the JWE header is a way
>>>>             around the need
>>>>             to have the client_id outside the JWE as top-level
>>>>             authZ request parameter.
>>>>
>>>>             Unfortunately this work around isn't mentioned
>>>>             anywhere, I just checked
>>>>             the most recent draft-ietf-oauth-jwsreq-20.
>>>>
>>>>             Our DDoS attack mitigation (for OIDC request_uri) also
>>>>             relies on the
>>>>             presence of client_id as top-level parameter, together
>>>>             with requiring
>>>>             RPs to register their request_uri's (so that we don't
>>>>             need to build and
>>>>             store an index of all request_uri's). I just had a look
>>>>             at "DDoS Attack
>>>>             on the Authorization Server" and also realised the
>>>>             request_uri
>>>>             registration isn't explicitly mentioned as attack
>>>>             prevention ("the
>>>>             server should (a) check that the value of "request_uri"
>>>>             parameter does
>>>>             not point to an unexpected location").
>>>>
>>>>             https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-20#section-10.4.1
>>>>             <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-oauth-jwsreq-20%23section-10.4.1&data=02%7C01%7CMichael.Jones%40microsoft.com%7Cc470d4ec4bd14d481c0f08d7961a8abb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637142913068793193&sdata=%2FvHVp68SN5CAHimqZ5jx93aOCIruxqLCRMUFCc5DSxc%3D&reserved=0>
>>>>
>>>>             To be honest, I feel quite bad about the situation with
>>>>             JAR we are in
>>>>             now. For some reason I had the impression that OAuth
>>>>             JAR was going to be
>>>>             the OIDC request / request_uri for general OAuth 2.0
>>>>             use, as with other
>>>>             OIDC bits that later became general purpose OAuth 2.0
>>>>             specs.
>>>>
>>>>             I find it unfortunate I didn't notice this when I was
>>>>             reviewing the spec
>>>>             in the past.
>>>>
>>>>             Vladimir
>>>>
>>>>
>>>>             On 10/01/2020 22:39, Filip Skokan wrote:
>>>>             > Vladimir,
>>>>             >
>>>>             > For that very case the payload claims may be repeated
>>>>             in the JWE protected header. An implementation wanting
>>>>             to handle this may look for iss/client_id there.
>>>>             >
>>>>             > Odesláno z iPhonu
>>>>             >
>>>>             >> 10. 1. 2020 v 21:19, Vladimir Dzhuvinov
>>>>             <[e-mail] <mailto:[e-mail]>>:
>>>>             >>
>>>>             >> I just realised there is one class of JARs where
>>>>             it's practially
>>>>             >> impossible to process the request if merge isn't
>>>>             supported:
>>>>             >>
>>>>             >> The client submits a JAR encrypted (JWT) with a
>>>>             shared key. OIDC allows
>>>>             >> for that and specs a method for deriving the shared
>>>>             key from the
>>>>             >> client_secret:
>>>>             >>
>>>>             >>
>>>>             https://openid.net/specs/openid-connect-core-1_0.html#Encryption
>>>>             <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fopenid.net%2Fspecs%2Fopenid-connect-core-1_0.html%23Encryption&data=02%7C01%7CMichael.Jones%40microsoft.com%7Cc470d4ec4bd14d481c0f08d7961a8abb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637142913068793193&sdata=soK9t7pzu504iILuDNFnG%2BMLxZPP2pN6ugEJ4ZOpqd4%3D&reserved=0>
>>>>             >>
>>>>             >> If the JAR is encrypted with the client_secret, and
>>>>             there is no
>>>>             >> top-level client_id parameter, there's no good way
>>>>             for the OP to find
>>>>             >> out which client_secret to get to try to decrypt the
>>>>             JWE. Unless the OP
>>>>             >> keeps an index of all issued client_secret's.
>>>>             >>
>>>>             >>
>>>>             >> OP servers which require request_uri registration
>>>>             >> (require_request_uri_registration=true) and don't
>>>>             want to index all
>>>>             >> registered request_uri's, also have no good way to
>>>>             process a request_uri
>>>>             >> if the client_id isn't present as top-level parameter.
>>>>             >>
>>>>             >>
>>>>             >> Vladimir
>>>>             >>
>>>>             >>
>>>>             >>> On 10/01/2020 20:13, Torsten Lodderstedt wrote:
>>>>             >>>
>>>>             >>>>> Am 10.01.2020 um 16:53 schrieb John Bradley
>>>>             <[e-mail] <mailto:[e-mail]>>:
>>>>             >>>> I think Torsten is speculating that is not a
>>>>             feature people use.   
>>>>             >>> I’m still trying to understand the use case for
>>>>             merging signed and unsigned parameters. Nat once
>>>>             explained a use case, where a client uses parameters
>>>>             signed by a 3rd party (some „certification authority“)
>>>>             in combination with transaction-specific parameters. Is
>>>>             this being done in the wild?
>>>>             >>>
>>>>             >>> PS: PAR would work with both modes.
>>>>
>>>>
>>>>             _______________________________________________
>>>>             OAuth mailing list
>>>>             [e-mail] <mailto:[e-mail]>
>>>>             https://
>>>>             <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=02%7C01%7CMichael.Jones%40microsoft.com%7Cc470d4ec4bd14d481c0f08d7961a8abb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637142913068803145&sdata=kobH%2FsGT7ElSSUCJvu%2FbiAqnRCXx%2B4SZNJsrL%2FCuVyc%3D&reserved=0>
>>>>
>
>     _______________________________________________
>     OAuth mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/oauth
>
-- 
Vladimir Dzhuvinov