From nobody Tue Sep 8 23:43:07 2020 Return-Path: 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 CEB3A3A0FD1 for ; Tue, 8 Sep 2020 23:43:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=forgerock.com 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 uMJvmjUq303o for ; Tue, 8 Sep 2020 23:43:03 -0700 (PDT) Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 285853A0FCD for ; Tue, 8 Sep 2020 23:43:02 -0700 (PDT) Received: by mail-wm1-x336.google.com with SMTP id a65so1125592wme.5 for ; Tue, 08 Sep 2020 23:43:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=content-transfer-encoding:mime-version:subject:from:in-reply-to:cc :date:message-id:references:to; bh=bX9LmfqT8cqE7cBMV6z5PO+2SIPpZ7BdHCn7MGyKwpE=; b=R+otf55uqlZxxVoNgIZNEwp5jF5ipxkxH8r6JdtmSfhEi6u7o4wxXvxftrIZMlMvH4 S2m+i+Y1NRAD3+fowWjQg7Iau4Gt6GpZy3WnFgOyFDsylJdtVMB9o++UdF5A0/SPWUDa CHzGa/jFqO2klYhIGxBOZPUE9uFj+Dc/JHa2Q= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:mime-version:subject :from:in-reply-to:cc:date:message-id:references:to; bh=bX9LmfqT8cqE7cBMV6z5PO+2SIPpZ7BdHCn7MGyKwpE=; b=UtPnHAktFr9JEQfRR5l/z/xNs2bMgzlB0kvdegbXOJFXO2qX2A4MkO10LGVQrfhz5X eQNeM0zrP1CJs//N7eD4YK7EBZbD2o+0qVus1EhaWXkOKRpai4N5IiHKcSpBZs/LEIz/ WpFR2ZkSLuX4b372ss3Dw2/wlF7TMoCPjceG3HRsKYmRvPdi1MKJ36vqhvayxVkA2Beg aRyZT0yJgupGNHBH44hy9IF7L1zv9ttgYdzY/lYI6e/FPpSzMcR2JGwo9A2ZEjvyvPro wPw0GdxEoYacbBlCNqER33VBqu6D/wdtqVerBJ89K/TRdUQWdi4XnSXNAjTR2VcNKOPm dONw== X-Gm-Message-State: AOAM530x5UDoXnbgEaoGp7xfZKeoggXmq/tRGnEbwJY/L62s7gwm6eQY B8WxHEkMAAjLVeh/1zUUW73po08ll708hmhY++sxCLrwfym1JuuC5aBU57uldQoRxf1Beuxf0vk ZWw1g3j1bBifXXTPNlcKWnl9oZURLcGv4jovzuaEirSr0B+c1gvslFfhZYN0mI0q9rg== X-Google-Smtp-Source: ABdhPJxgiGUXr47Ciu5NG0SoB86VogaEYrIw+hjGZRWfv4pUXvczIQw/eRR+LaTrzXUSUILJDqcNqw== X-Received: by 2002:a1c:9a48:: with SMTP id c69mr1907285wme.43.1599633780930; Tue, 08 Sep 2020 23:43:00 -0700 (PDT) Received: from [10.0.0.5] (139.249.143.150.dyn.plus.net. [150.143.249.139]) by smtp.gmail.com with ESMTPSA id h76sm2516394wme.10.2020.09.08.23.43.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 08 Sep 2020 23:43:00 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-EC30A4EE-E6F5-4DFB-895A-DB089CE7E2AC Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) From: Neil Madden In-Reply-To: Cc: toshio9.ito@toshiba.co.jp, oauth Date: Wed, 9 Sep 2020 07:42:59 +0100 Message-Id: References: To: Brian Campbell X-Mailer: iPhone Mail (17G80) Archived-At: Subject: Re: [OAUTH-WG] Omit "jwk" (or use "kid" instead) in DPoP Proof? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2020 06:43:06 -0000 --Apple-Mail-EC30A4EE-E6F5-4DFB-895A-DB089CE7E2AC Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I disagree with this rationale, I=E2=80=99m afraid. I don=E2=80=99t think th= e simplicity gain for the client is really very great and I think we will re= gret this decision. Most importantly, including the JWK directly in the proof token increases th= e likelihood that somebody will just validate the signature using that key a= nd fail to check that it matches the hash in the AT. We=E2=80=99ve already s= een at least one vendor make exactly this kind of mistake in the past [1]. L= etting the proof tell you the key to use to verify the proof is another exam= ple of Moxie=E2=80=99s Cryptographic Doom Principle [2] - trusting the messa= ge before you=E2=80=99ve authenticated it.=20 Moving the jwk from the DPoP proof to the AT/introspection response reduces t= he chances of these kind of mistakes.=20 As a bonus it also has efficiency gains because the size of the DPoP proof i= s reduced - potentially by a lot for RSA keys. Although the JWK still has to= be communicated to the RS, this can be more efficient because: - For token introspection, in many deployments the introspection request wil= l be within a datacenter and so over a high-bandwidth low-latency network. T= his is usually not the case for the DPoP proof, which may be over a poor mob= ile connection.=20 - For embedded directly in a JWT access token, the JWK will be in the claims= rather than the header and so can at least be compressed. (Albeit not by mu= ch, because public keys don=E2=80=99t compress well, but the rest of the AT w= ill and that can compensate a little for the extra bulk).=20 [1]: https://nvd.nist.gov/vuln/detail/CVE-2018-0114 [2]: https://moxie.org/2011/12/13/the-cryptographic-doom-principle.html =E2=80=94 Neil >> On 8 Sep 2020, at 23:46, Brian Campbell wrote: > =EF=BB=BF > Indeed there are cases, as you point out, where the key might be knowable t= o the server via some other means, which makes the "jwk" header in the DPoP p= roof not strictly necessary. And while omitting the key in such cases would r= educe the size of some messages (the DPoP proof anyway), such optionality wo= uld add complexity to implementations and deployments (and that kind of comp= lexity can and often does degrade interoperability and even security). How, f= or example, would a client know if the access token includes the public key a= nd thus whether or not to include the key with the proof? Sure the access to= ken could always include the key (rather than thumbprint) but then there's t= he question of how to get the key to the AS. As well as the stated desire to= utilize the same DPoP Proof structure for requests to both the AS and RS. T= here will be some clients that have public key(s) registered and some that w= on't (maybe a lot that won't as a driving use case for many for this is key b= inding access and refresh tokens for public clients). The protocol defined b= y the draft needs to account for both.=20 >=20 > Ultimately there are a number of different ways the necessary data could f= low through the various protocol elements. And there are some tradeoffs with= different approaches and/or trying to accommodate variations under one appr= oach. The approach the draft has taken thus far is to prioritize consistency= and simplicity as much as is possible. And that ethos has led to how it's c= urrently defined, which is to always include the key in the proof and bind t= o a hash of the key in the access token.=20 >=20 >=20 >> On Tue, Sep 8, 2020 at 3:29 AM wrote: >> Hi all, >>=20 >> In section 4.1 of draft-ietf-oauth-dpop-01, the "jwk" header parameter is= >> REQUIRED. However, there are some cases where "jwk" is not necessary in t= heory. >>=20 >> For example, consider a case where the client is registered with the >> Authorization Server, and its one and only public key is also registered w= ith >> the AS. In that case, when the AS receives a request on Token endpoint, i= t can >> just use the public key registered for the client to verify the DPoP Proo= f. >> There is no need to send the public key in DPoP Proof. >>=20 >> The same goes for requests to the Resource Server, if the AS and RS share= the >> storage for clients' public keys. Things are a little difficult if the AS= and RS >> are separate. Probably the Access Token or its introspection result have t= o >> include the public key (instead of its thumbprint as described in section= 7). >>=20 >> If the client registers multiple keys with the AS, it needs to specify wh= ich key >> it uses to sign the DPoP Proof. However, there is still no absolute need t= o send >> the whole key in DPoP Proof. Instead, the client could use "kid" header >> parameter to specify the key. >>=20 >> Daniel Fett once mentioned the above case in the GitHub issue #26 [*1], b= ut I'm >> not sure what happened to the discussion. There was also a comment on the= latest >> draft about the "jwk" header parameter [*2]. I agree with using the same D= PoP >> Proof structure for requests to AS and RS, but I think there are some cas= es >> where we can omit "jwk" in BOTH requests. Making "jwk" OPTIONAL would all= ow >> those cases to reduce some messaging overhead. >>=20 >> I'd like to hear your opinions about it. >>=20 >>=20 >> [*1]: https://github.com/danielfett/draft-dpop/issues/26#issuecomment-480= 701746 >> [*2]: https://mailarchive.ietf.org/arch/msg/oauth/smwsONA6c4H2UICcZMzb8Yv= 2QRc/ >>=20 >>=20 >> Best regards, >> Toshio Ito >>=20 >> ------------- >> Toshio Ito >> Research and Development Center >> Toshiba Corporation >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 > CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= material for the sole use of the intended recipient(s). Any review, use, di= stribution or disclosure by others is strictly prohibited. If you have rece= ived this communication in error, please notify the sender immediately by e-= mail and delete the message and any file attachments from your computer. Tha= nk you._______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-EC30A4EE-E6F5-4DFB-895A-DB089CE7E2AC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I disagree w= ith this rationale, I=E2=80=99m afraid. I don=E2=80=99t think the simplicity= gain for the client is really very great and I think we will regret this de= cision.

Most importantly, i= ncluding the JWK directly in the proof token increases the likelihood that s= omebody will just validate the signature using that key and fail to check th= at it matches the hash in the AT. We=E2=80=99ve already seen at least one ve= ndor make exactly this kind of mistake in the past [1]. Letting the proof te= ll you the key to use to verify the proof is another example of Moxie=E2=80=99= s Cryptographic Doom Principle [2] - trusting the message before you=E2=80=99= ve authenticated it. 

= Moving the jwk from the DPoP proof to the AT/introspection response reduces t= he chances of these kind of mistakes. 

=
As a bonus it also has efficiency gains because the size of= the DPoP proof is reduced - potentially by a lot for RSA keys. Although the= JWK still has to be communicated to the RS, this can be more efficient beca= use:
- For token introspection, in many deployments th= e introspection request will be within a datacenter and so over a high-bandw= idth low-latency network. This is usually not the case for the DPoP proof, w= hich may be over a poor mobile connection. 
- For= embedded directly in a JWT access token, the JWK will be in the claims rath= er than the header and so can at least be compressed. (Albeit not by much, b= ecause public keys don=E2=80=99t compress well, but the rest of the AT will a= nd that can compensate a little for the extra bulk). 

[1]: https://nvd.nist.gov/vuln/detail/CVE-2018-0114<= /div>

=E2=80=94 Neil

On 8 S= ep 2020, at 23:46, Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.i= etf.org> wrote:

=EF=BB=BF
Indeed there are cases, as you poi= nt out, where the key might be knowable to the server via some other means, w= hich makes the "jwk" header in the DPoP proof not strictly necessary. And wh= ile omitting the key in such cases would reduce the size of some messages (t= he DPoP proof anyway), such optionality would add complexity to implementati= ons and deployments (and that kind of complexity can and often does degrade i= nteroperability and even security). How, for example, would a client know if= the access token includes the public key and thus whether or not to include= the key with the proof? Sure the access token could always include the key (= rather than thumbprint) but then there's the question of how to get the key t= o the AS. As well as the stated desire to utilize the same DPoP Proof struct= ure for requests to both the AS and RS. There will be some clients that have= public key(s) registered and some that won't (maybe a lot that won't as a d= riving use case for many for this is key binding access and refresh tokens f= or public clients). The protocol defined by the draft needs to account for b= oth.

Ultimately there are a number of differen= t ways the necessary data could flow through the various protocol elements. A= nd there are some tradeoffs with different approaches and/or trying to accom= modate variations under one approach. The approach the draft has taken thus f= ar is to prioritize consistency and simplicity as much as is possible. And t= hat ethos has led to how it's currently defined, which is to always include t= he key in the proof and bind to a hash of the key in the access token.
<= /div>


On Tue, Sep 8, 2020 at 3:29 AM <toshio9.ito@toshiba.co.jp> wrote:
Hi all,

In section 4.1 of draft-ietf-oauth-dpop-01, the "jwk" header parameter is REQUIRED. However, there are some cases where "jwk" is not necessary in theo= ry.

For example, consider a case where the client is registered with the
Authorization Server, and its one and only public key is also registered wit= h
the AS. In that case, when the AS receives a request on Token endpoint, it c= an
just use the public key registered for the client to verify the DPoP Proof.<= br> There is no need to send the public key in DPoP Proof.

The same goes for requests to the Resource Server, if the AS and RS share th= e
storage for clients' public keys. Things are a little difficult if the AS an= d RS
are separate. Probably the Access Token or its introspection result have to<= br> include the public key (instead of its thumbprint as described in section 7)= .

If the client registers multiple keys with the AS, it needs to specify which= key
it uses to sign the DPoP Proof. However, there is still no absolute need to s= end
the whole key in DPoP Proof. Instead, the client could use "kid" header
parameter to specify the key.

Daniel Fett once mentioned the above case in the GitHub issue #26 [*1], but I= 'm
not sure what happened to the discussion. There was also a comment on the la= test
draft about the "jwk" header parameter [*2]. I agree with using the same DPo= P
Proof structure for requests to AS and RS, but I think there are some cases<= br> where we can omit "jwk" in BOTH requests. Making "jwk" OPTIONAL would allow<= br> those cases to reduce some messaging overhead.

I'd like to hear your opinions about it.


[*1]: https://github.com/dani= elfett/draft-dpop/issues/26#issuecomment-480701746
[*2]: https://mailarchive.ietf= .org/arch/msg/oauth/smwsONA6c4H2UICcZMzb8Yv2QRc/


Best regards,
Toshio Ito

-------------
Toshio Ito
Research and Development Center
Toshiba Corporation

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

CONFIDENTIALITY NOTICE: This email may contain confidential and pr= ivileged material for the sole use of the intended recipient(s). Any review,= use, distribution or disclosure by others is strictly prohibited.  If y= ou have received this communication in error, please notify the sender immed= iately by e-mail and delete the message and any file attachments from your c= omputer. Thank you._________________________________= ______________
OAuth mailing list
OAuth@ietf= .org
https://www.ietf.org/mailman/listinfo/oauth
<= /div>
= --Apple-Mail-EC30A4EE-E6F5-4DFB-895A-DB089CE7E2AC--