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

Vladimir Dzhuvinov <vladimir@connect2id.com> Wed, 15 January 2020 21:02 UTC

Return-Path: <vladimir@connect2id.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C234120967 for <oauth@ietfa.amsl.com>; Wed, 15 Jan 2020 13:02:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.795
X-Spam-Level:
X-Spam-Status: No, score=-1.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8zW8VTDbt5TE for <oauth@ietfa.amsl.com>; Wed, 15 Jan 2020 13:02:36 -0800 (PST)
Received: from p3plsmtpa07-05.prod.phx3.secureserver.net (p3plsmtpa07-05.prod.phx3.secureserver.net [173.201.192.234]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C310120288 for <oauth@ietf.org>; Wed, 15 Jan 2020 13:02:36 -0800 (PST)
Received: from [192.168.88.250] ([94.155.17.54]) by :SMTPAUTH: with ESMTPSA id rpo9iNOTlXcz7rpoAiK0yL; Wed, 15 Jan 2020 14:02:35 -0700
To: Takahiko Kawasaki <taka@authlete.com>
Cc: John Bradley <ve7jtb@ve7jtb.com>, Mike Jones <Michael.Jones@microsoft.com>, IETF oauth WG <oauth@ietf.org>
References: <fc3805e5-e908-00db-a734-990721371ab2@connect2id.com> <79C4475C-FDEB-42C8-8A44-7BFE4DBF9453@gmail.com> <110a95d9-2981-6d2b-9cbf-9658be3585cc@connect2id.com> <CAANoGhK0-n6V_RogvVZ=8J8AQCEUUVJQn4_7wSWYixeQM8aZsw@mail.gmail.com> <CH2PR00MB0843D5044E11E0F4CE5F5D09F53B0@CH2PR00MB0843.namprd00.prod.outlook.com> <CAANoGhJB4mYSFiWKt3T=cObH7uCW0s3Zpv2m92+YaAY2Oy4mqw@mail.gmail.com> <2aca5c38-bb20-497e-14ed-f4a9245a9439@connect2id.com> <7baae999-47c1-f749-6c51-f45022ab1a3d@ve7jtb.com> <3d9ffc74-6c9c-48a1-0c98-65a7465e8dbc@connect2id.com> <CAHdPCmNHeUyDjrc32oQPZ5g3oars-XY3vq2p3qt2LzzkZMTw5w@mail.gmail.com>
From: Vladimir Dzhuvinov <vladimir@connect2id.com>
X-Enigmail-Draft-Status: N11100
Organization: Connect2id Ltd.
Message-ID: <89345e9b-8191-f01d-71a6-453ec197796f@connect2id.com>
Date: Wed, 15 Jan 2020 23:02:33 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2
MIME-Version: 1.0
In-Reply-To: <CAHdPCmNHeUyDjrc32oQPZ5g3oars-XY3vq2p3qt2LzzkZMTw5w@mail.gmail.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000105080308070105030007"
X-CMAE-Envelope: MS4wfNrQBc0l2t8XXcP5/T7/ZMh0kMqx0KjGFMU6N8N0yNVBdhwCAl0dva5m7BZQbSOjt3toTLFrHd7j1z6osLsckItjwFnRJD6k+Q71MQII0qHfXa327kOH GC+qEeLza+hE+6ruRC3OlLIYC5tsla9dDY4vbkRKqJZNP58HRr8KFIClX89xomjnvMPn2e6qTYNXUkq4ppn+lxQhUWAEV6vhpwkWBQb9JJ2BJuLo3LljnJXh DOYicbuFXAOFbdoeiR02P9Xkd0hYIdWNVvKjt+I7vQI=
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/bKZGP7I7EIhdjXs0KzuxfIn65QQ>
Subject: Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authorization Request (JAR) vs OIDC request object
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Jan 2020 21:02:40 -0000

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
> <vladimir@connect2id.com <mailto:vladimir@connect2id.com>> 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
>>>>     <Michael.Jones@microsoft.com
>>>>     <mailto:Michael.Jones@microsoft.com>> 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 <oauth-bounces@ietf.org
>>>>         <mailto:oauth-bounces@ietf.org>> *On Behalf Of * John Bradley
>>>>         *Sent:* Friday, January 10, 2020 2:15 PM
>>>>         *To:* Vladimir Dzhuvinov <vladimir@connect2id.com
>>>>         <mailto:vladimir@connect2id.com>>
>>>>         *Cc:* IETF oauth WG <oauth@ietf.org <mailto:oauth@ietf.org>>
>>>>         *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
>>>>         <vladimir@connect2id.com <mailto:vladimir@connect2id.com>>
>>>>         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
>>>>             <vladimir@connect2id.com <mailto:vladimir@connect2id.com>>:
>>>>             >>
>>>>             >> 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
>>>>             <ve7jtb@ve7jtb.com <mailto:ve7jtb@ve7jtb.com>>:
>>>>             >>>> 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
>>>>             OAuth@ietf.org <mailto:OAuth@ietf.org>
>>>>             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
>     OAuth@ietf.org <mailto:OAuth@ietf.org>
>     https://www.ietf.org/mailman/listinfo/oauth
>
-- 
Vladimir Dzhuvinov