Re: [TLS] question about verification of client side certificate for TLS session for mutual authentication

Viktor Dukhovni <ietf-dane@dukhovni.org> Mon, 16 April 2018 16:11 UTC

Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23F9C12E8E7 for <tls@ietfa.amsl.com>; Mon, 16 Apr 2018 09:11:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 xaS4N4YkHowy for <tls@ietfa.amsl.com>; Mon, 16 Apr 2018 09:11:42 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74C9012E8DE for <tls@ietf.org>; Mon, 16 Apr 2018 09:11:42 -0700 (PDT)
Received: from [10.200.0.109] (unknown [8.2.105.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 3DB727A3309 for <tls@ietf.org>; Mon, 16 Apr 2018 16:11:41 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\))
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
X-Priority: 5 (Lowest)
In-Reply-To: <064a01d3d569$2a3cdaf0$7eb690d0$@gondrom.org>
Date: Mon, 16 Apr 2018 12:11:40 -0400
Reply-To: TLS WG <tls@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <70D47A63-5703-4D14-BDCF-09CE52ED1105@dukhovni.org>
References: <064a01d3d569$2a3cdaf0$7eb690d0$@gondrom.org>
To: TLS WG <tls@ietf.org>
X-Mailer: Apple Mail (2.3445.6.18)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/ZQci8rumZt9DRxMIs_vXLwRbJdA>
Subject: Re: [TLS] question about verification of client side certificate for TLS session for mutual authentication
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Apr 2018 16:11:44 -0000


> On Apr 16, 2018, at 5:56 AM, Tobias Gondrom <tobias.gondrom@gondrom.org> wrote:
> 
> Are there any informational (or standard) RFCs for TLS that speak about this risk and best practices to address it?  
> (e.g. using additional whitelist checks of parameters inside the client certificate for access control checks already during phase of establishing the TLS connection)

A major obstacle to making access control decisions during the TLS handshake is that at that time the server often does not yet have enough information to determine which specific resource the client will ask to access.

If the access control is very coarse, and the client is simply not allowed any of the features of the application, then one might terminate the handshake "early", but by the time server has processed the client certificate it has done pretty much all the heavy lifting (signing its own key exchange messages, ...) so allowing the handshake to complete and dealing with access control at the application layer is far more typical, and makes possible more meaningful (to the client application) "Permission denied" error responses, which would be far less likely to be understood if communicated via a handshake failure.

-- 
	Viktor.