Re: [OAUTH-WG] Omit "jwk" (or use "kid" instead) in DPoP Proof?

toshio9.ito@toshiba.co.jp Wed, 09 September 2020 07:20 UTC

Return-Path: <toshio9.ito@toshiba.co.jp>
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 ACE713A0FD5 for <oauth@ietfa.amsl.com>; Wed, 9 Sep 2020 00:20:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 Qie4Bb516YxH for <oauth@ietfa.amsl.com>; Wed, 9 Sep 2020 00:20:23 -0700 (PDT)
Received: from mo-csw.securemx.jp (mo-csw1115.securemx.jp [210.130.202.157]) (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 36CDD3A0C17 for <oauth@ietf.org>; Wed, 9 Sep 2020 00:20:23 -0700 (PDT)
Received: by mo-csw.securemx.jp (mx-mo-csw1115) id 0897KJKL026974; Wed, 9 Sep 2020 16:20:19 +0900
X-Iguazu-Qid: 2wGrGhpI0urotI7t4b
X-Iguazu-QSIG: v=2; s=0; t=1599636019; q=2wGrGhpI0urotI7t4b; m=DrBW+sq5kmercKjzDwVQ6iGRZWd3h0zpQcDe02VngRg=
Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) by relay.securemx.jp (mx-mr1111) id 0897KHXX026346; Wed, 9 Sep 2020 16:20:18 +0900
Received: from enc02.toshiba.co.jp ([61.202.160.51]) by imx12.toshiba.co.jp with ESMTP id 0897KH0u029960; Wed, 9 Sep 2020 16:20:17 +0900 (JST)
Received: from hop101.toshiba.co.jp ([133.199.85.107]) by enc02.toshiba.co.jp with ESMTP id 0897KH3J025831; Wed, 9 Sep 2020 16:20:17 +0900
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bVzrfFYW9unazSSVEH6kjKWU23q8XxzyRSfUWYBPgFURrBONTQsb4+e+APKsu1H0duKnYKzjI7+BbRoTrjw65CNloS2Sic8sMbYk/tfqIlcxm0H+6KwPK04idTlun7+5OvURrGKh2Yy/rZF+1SWDRsH4aBQK3cUDGq2ImbAR3e//w0PF1YE8k5jgkHXCpRDZwDv0Mvz/b91jSwIUwI4ZZB1j7iczwdr50dXbCnsKMiBzhuA0STrY9UK2smmHuvOtL9TKD/EyyI1VnesBPq0ZGCdqXvejVhLoQk9dXowcrRMvEFRYOnnKOQut8WpTGrUZ7uoVGUq3loiAqyMEnjU5xg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=moncLSrppYnKiwmiKU3+vYVSltXGDKPfRyzfmErptss=; b=kk6f8kRUgRIdUOhXX7GcNSQdQE+QjuVQ6zxsJHZh4gfjeli7LsgzOF9iOFvJrKrVxUl7BxBR1P6+FamayGeGv6x6xL0urrISlrM/jxCxanROpWIrV//cnJJSn4T+miwKZ4ZjkQ6BD5DfiSjATvTc5s0+OtKepz6WM5x+wqna08VrksPYfaP4nzAPY+UaoD5uN1XxOTCy8+vpccaTct7KvuL+2E0sgFUBAzKxFs8A6KOjQhSTeiRU2fA8+VHi7H6X1OrP9S2mh+NGN7sRHpAU91ZS+B8+NUCmuBwxrs6o8WSKaXykkb1TATmTmAHRw+zfxvQarnwaMrKoASvAOTQKLA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=toshiba.co.jp; dmarc=pass action=none header.from=toshiba.co.jp; dkim=pass header.d=toshiba.co.jp; arc=none
From: <toshio9.ito@toshiba.co.jp>
To: <bcampbell@pingidentity.com>
CC: <oauth@ietf.org>
Thread-Topic: [OAUTH-WG] Omit "jwk" (or use "kid" instead) in DPoP Proof?
Thread-Index: AdaFwiWCFexiV/DnR8eDAlJqPzgDigAb5S6AABH1iVA=
Date: Wed, 9 Sep 2020 07:20:14 +0000
X-TSB-HOP: ON
Message-ID: <TY1PR01MB1466A09FB0194B47F702DB92E5260@TY1PR01MB1466.jpnprd01.prod.outlook.com>
References: <TY1PR01MB1466E7D4AF21EA5C56467E6AE5290@TY1PR01MB1466.jpnprd01.prod.outlook.com> <CA+k3eCRffzry_+GVieOcWs0RHqwo_XGgMTwx4LOCZFPioD_xdw@mail.gmail.com>
In-Reply-To: <CA+k3eCRffzry_+GVieOcWs0RHqwo_XGgMTwx4LOCZFPioD_xdw@mail.gmail.com>
Accept-Language: ja-JP, en-US
Content-Language: ja-JP
authentication-results: pingidentity.com; dkim=none (message not signed) header.d=none;pingidentity.com; dmarc=none action=none header.from=toshiba.co.jp;
x-originating-ip: [103.91.184.4]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: d34eeb05-27d4-4a46-52b1-08d85490cc16
x-ms-traffictypediagnostic: TY2PR01MB2684:
x-microsoft-antispam-prvs: <TY2PR01MB26840489D273E7D4123EF65FE5260@TY2PR01MB2684.jpnprd01.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:8273;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: qkqi9jo3PA5aQmkHgkBG2/O8IrKKostz35G1Sl8QsijV1b8N3Am3ttAtg1UwnyY8MGTGAx78PZlLMs7laukwQCpNX6i8P9kh3obdGYS3tujPbGtxonL4ksWdMMDoFhWDAtKNoau77Vxx2LMqdtONsCDfpH9c/kc0/6Gh+XvaLch0Usb48u6eRnjGaFnQaQzLo/ya6yMi9m2SD2qvFBOfXb0VMnFvFm0zLJcw+DI3d3NkZCja5IISyrLyB3r9I6m3gvcRD3WyYIkHQXsHSH1sxvGYC69WUXClTOZladGUSLnRn2KuF4R1YM69c+li8uj7vGrlZVMw6DATtfI5dJFn/dE19IoSMUe0680z2Adu6A/Sw9KYyYD8ddVWtiOW3ZpbM/FrAgKeHuHSyRP0j6HnxA==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:TY1PR01MB1466.jpnprd01.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39860400002)(366004)(396003)(136003)(346002)(376002)(66446008)(186003)(52536014)(966005)(166002)(86362001)(478600001)(71200400001)(6916009)(55016002)(2906002)(64756008)(9686003)(66556008)(76116006)(66476007)(66946007)(5660300002)(33656002)(83380400001)(316002)(8936002)(8676002)(53546011)(26005)(4326008)(6506007)(7696005); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: P1WNKVhjvB2Yyr740lA8b36uUqrMmMN0xGHW2ZnuJbgb5n5LaeSOgX1WZJTX2dZzma4FMO60ho/EX2/hZU3q5Wf+aej83qhbKvX5F5lJcEQZMB7/YQf0AU0auOAM4VeNW9Tvyh/qX45ng1iwWgsYWmDs2CJTBxOVp7mC5keYnPTB/afIh3IOOPFo1uvT1xLTdGn6pgNgZRb53JyEz1wGYoppUUWOwe4/ewZeLgYwo/7agwUynjeYUGFLaecipN7P43kgQBbeToi/o2qPYX/ga9WXLLLBI0YpVjnDz28GLrbvLrtJVw1Z761JQynFRM4jn2lVySOPU2dBWo65yOMPH7AqWpc2mvY7uYjlnAIXMpQCDpyIi7blo6QT+py+1EjjEpOsRdj1lE3WxpEepq9qZ97RKRqaGoeh4tfVbu4xHSkqOC3ff4h/Iz4dmyihFfZKLkZKEW2rUmAp5X1mRh8QrqD2cweuWOdAs0rccg+h57Mg3+5AlwUmxKTg9SxDaytMyeDMoOQzvKp5TCm4SPGvFWIkF684bZfxjIT7KHNy8gP02sCZpSs/6KjtW2qvTXxeAPND1zMEWQSzi4FmojKku/mSY2bzKlKe7dvrBkKWmRBWw9aD85P+LgmcEVbKQozNZ3tBJWz9JyrB5yl6ytQsgA==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_TY1PR01MB1466A09FB0194B47F702DB92E5260TY1PR01MB1466jpnp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: TY1PR01MB1466.jpnprd01.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: d34eeb05-27d4-4a46-52b1-08d85490cc16
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Sep 2020 07:20:14.7814 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: f109924e-fb71-4ba0-b2cc-65dcdf6fbe4f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: YX0SUgHqOC5KKqblcIdA1UYhPX0FgujQTk4X/mQVSVLBEq1fF4tlViTUqIAKWQco8cPMGyKGOhocJ4kc7bXUvPzRSqF1fL5aAKJHNXyo3yQ=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: TY2PR01MB2684
MSSCP.TransferMailToMossAgent: 103
X-OriginatorOrg: toshiba.co.jp
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/75MqxLy_3Z8JY-FdX_s5i5-Ugmc>
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 <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, 09 Sep 2020 07:20:26 -0000

Hi Brian,

Thanks for clarification. Now I understand the rationale of this design.

I agree that having many options leads to interoperability issues and security
risk. Also, I forgot about public clients. I think requiring "jwk" in DPoP Proof
is one way to cover all use cases.



From: Brian Campbell <bcampbell@pingidentity.com>
Sent: Wednesday, September 9, 2020 7:45 AM
To: ito toshio(伊藤 俊夫 ○RDC□IT研○CNL) <toshio9.ito@toshiba.co.jp>
Cc: oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Omit "jwk" (or use "kid" instead) in DPoP Proof?

Indeed there are cases, as you point out, where the key might be knowable to the server via some other means, which makes the "jwk" header in the DPoP proof not strictly necessary. And while omitting the key in such cases would reduce the size of some messages (the DPoP proof anyway), such optionality would add complexity to implementations and deployments (and that kind of complexity can and often does degrade interoperability 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 to the AS. As well as the stated desire to utilize the same DPoP Proof structure 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 driving use case for many for this is key binding access and refresh tokens for public clients). The protocol defined by the draft needs to account for both.

Ultimately there are a number of different ways the necessary data could flow through the various protocol elements. And there are some tradeoffs with different approaches and/or trying to accommodate variations under one approach. 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 currently defined, which is to always include the key in the proof and bind to a hash of the key in the access token.


On Tue, Sep 8, 2020 at 3:29 AM <toshio9.ito@toshiba.co.jp<mailto: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 theory.

For example, consider a case where the client is registered with the
Authorization Server, and its one and only public key is also registered with
the AS. In that case, when the AS receives a request on Token endpoint, it can
just use the public key registered for the client to verify the DPoP Proof.
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 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 to
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 send
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 latest
draft about the "jwk" header parameter [*2]. I agree with using the same DPoP
Proof structure for requests to AS and RS, but I think there are some cases
where we can omit "jwk" in BOTH requests. Making "jwk" OPTIONAL would allow
those cases to reduce some messaging overhead.

I'd like to hear your opinions about it.


[*1]: https://github.com/danielfett/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<mailto:OAuth@ietf.org>
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.