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

Vladimir Dzhuvinov <vladimir@connect2id.com> Tue, 29 August 2017 07:29 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 E2B6613293A for <oauth@ietfa.amsl.com>; Tue, 29 Aug 2017 00:29:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.7
X-Spam-Level:
X-Spam-Status: No, score=-4.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8] 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 bQu4ZEDuSHNq for <oauth@ietfa.amsl.com>; Tue, 29 Aug 2017 00:29:26 -0700 (PDT)
Received: from p3plsmtpa12-06.prod.phx3.secureserver.net (p3plsmtpa12-06.prod.phx3.secureserver.net [68.178.252.235]) (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 480C81326DF for <oauth@ietf.org>; Tue, 29 Aug 2017 00:29:26 -0700 (PDT)
Received: from [192.168.0.103] ([78.130.190.73]) by :SMTPAUTH: with SMTP id maxCdUlF9RZBrmaxCdmOPi; Tue, 29 Aug 2017 00:28:55 -0700
To: IETF oauth WG <oauth@ietf.org>
From: Vladimir Dzhuvinov <vladimir@connect2id.com>
Organization: Connect2id Ltd.
Message-ID: <c8393341-18fe-df74-4d3f-26a444e65679@connect2id.com>
Date: Tue, 29 Aug 2017 10:28:53 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms080901070502090603030108"
X-CMAE-Envelope: MS4wfIawBgV7laX1krsP1zNK8zXqEok6s99m5+1wV5fJF+gE2aKZ96uj3nssSW5cWx6RVq5Tnq2ti3bwasrgbzpc/GRwWRollHBVJ2dd7PNcc6wrTUnmnWyk NUmQIYROii90taTugIN3trvlfsvFMpAqmPH8NM5kZHU9YZOrdfuEnVlI
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/lgjaQqVwP6EgLv1wpHlRXPdW50M>
Subject: [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: Tue, 29 Aug 2017 07:29:28 -0000

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