Re: [OAUTH-WG] draft-ietf-oauth-mtls-03: jwk / x5c sanity checks when registering for pub_key_tls_client_auth

Vladimir Dzhuvinov <vladimir@connect2id.com> Wed, 30 August 2017 05:11 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 9AF721321EC for <oauth@ietfa.amsl.com>; Tue, 29 Aug 2017 22:11:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.92
X-Spam-Level:
X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 3BJ9PHs5XhAD for <oauth@ietfa.amsl.com>; Tue, 29 Aug 2017 22:11:06 -0700 (PDT)
Received: from p3plsmtpa12-01.prod.phx3.secureserver.net (p3plsmtpa12-01.prod.phx3.secureserver.net [68.178.252.230]) (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 42C1F1321AE for <oauth@ietf.org>; Tue, 29 Aug 2017 22:11:06 -0700 (PDT)
Received: from [192.168.0.103] ([78.130.190.73]) by :SMTPAUTH: with SMTP id mvGsdGxOZE0BdmvGsdnx7Y; Tue, 29 Aug 2017 22:10:35 -0700
To: Brian Campbell <bcampbell@pingidentity.com>
Cc: IETF oauth WG <oauth@ietf.org>
References: <c8393341-18fe-df74-4d3f-26a444e65679@connect2id.com> <CA+k3eCRVPXN16qjnbU1zf8DP=XU+zu+o3N4jcD_yjmF7VKxjPg@mail.gmail.com>
From: Vladimir Dzhuvinov <vladimir@connect2id.com>
Organization: Connect2id Ltd.
Message-ID: <8e9eaf64-6859-0674-d586-ab23ab91f086@connect2id.com>
Date: Wed, 30 Aug 2017 08:10:33 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <CA+k3eCRVPXN16qjnbU1zf8DP=XU+zu+o3N4jcD_yjmF7VKxjPg@mail.gmail.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000904030703050102050501"
X-CMAE-Envelope: MS4wfD64gwPHFTcsY7f7hrZbQOZNsyjgcoKP4nwGgpdeHmsUzPJuioQeIKkpMpw8VlCZdJbA3Sow0hr+jX3wPJLUDvFhgGYxB1t24YOvkHphHzUScbHbGI7c AoyRCOwR6WH2kAbM5DDTplAvw7xOLMvGvJWeaMIepTZ7KEqiTe9ejLh6e1QG6cZ6dK0JkBWsXb2tK00PqBvt0tkOa0FuqE3rPes=
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/NGP0V6TwAzE27JFmnOlhTeyICbI>
Subject: Re: [OAUTH-WG] draft-ietf-oauth-mtls-03: jwk / x5c sanity checks when registering for pub_key_tls_client_auth
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
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, 30 Aug 2017 05:11:07 -0000

On 29/08/17 18:14, Brian Campbell wrote:
> Sec 4.7 of RFC 7517 <https://tools.ietf.org/html/rfc7517#section-4.7>,
> which defines "x5c" for JWK, says that the "key in the first certificate
> MUST match the public key represented by other members of the JWK." Thus,
> how I read it anyway, the check you mention is already a requirement of the
> JWK layer.
Thanks Brian, I missed that bit!

And just realised that the Nimbus lib doesn't check the x5c pub key when
creating / parsing JWKs! I suppose other JOSE libs may have the same
omission. A reason to add a note to the MTLS spec perhaps?

Vladimir

> On Tue, Aug 29, 2017 at 1:28 AM, Vladimir Dzhuvinov <vladimir@connect2id.com
>> wrote:
>> Aspects of this were previously discussed, on and off list.
>>
>> According to section 2.3, clients registering for public key bound mTLS
>> auth must register their public keys as JWKs, or client X.509
>> certificate (as x5c parameter in RSA and EC JWK).
>>
>> In the latter case, are there any security implications if there is
>> mismatch between the registered x5c and the top-level public key JWK
>> parameters? Should the AS perform some sanity checks on the JWK parameters?
>>
>> A client could for instance register a JWK where the top-level JWK
>> public key doesn't match the public key in the x5c (as key type, or
>> public key value).
>>
>> Thanks,
>>
>> Vladimir
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>

-- 
Vladimir Dzhuvinov :: vladimir@connect2id.com