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

"Tobias Gondrom" <tobias.gondrom@gondrom.org> Mon, 16 April 2018 09:56 UTC

Return-Path: <tobias.gondrom@gondrom.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 068471275F4 for <tls@ietfa.amsl.com>; Mon, 16 Apr 2018 02:56:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.101
X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=tobias.gondrom@gondrom.org header.d=gondrom.org
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id XTuDLw8gy2FK for <tls@ietfa.amsl.com>; Mon, 16 Apr 2018 02:56:25 -0700 (PDT)
Received: from gondrom.org (www.gondrom.org []) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7084126B6E for <tls@ietf.org>; Mon, 16 Apr 2018 02:56:24 -0700 (PDT)
Received: from seraph (unknown []) by gondrom.org (Postfix) with ESMTPSA id 5F2E86495F for <tls@ietf.org>; Mon, 16 Apr 2018 11:56:18 +0200 (CEST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=2dglW4zjc6yOJfl6ZmCttl7xC+jAjCbfKmn0ActYkAln7JxW82dWv7QxAmQK4FRQeiNY74VDeTaGSve1o+QqkbU1VDZp5Gf6ujnzs012PLtUyPuvlj88UvkE+WHfMGEtXikI0VuW1wqKrRs/H08WYl79EdqJiS+CvXF7uyCI3NE=; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type:X-Priority:X-MSMail-Priority:X-Mailer:Thread-Index:Content-Language:Importance;
From: Tobias Gondrom <tobias.gondrom@gondrom.org>
To: tls@ietf.org
Date: Mon, 16 Apr 2018 17:56:13 +0800
Message-ID: <064a01d3d569$2a3cdaf0$7eb690d0$@gondrom.org>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_064B_01D3D5AC.3861A190"
X-Priority: 5 (Lowest)
X-MSMail-Priority: Low
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AdPVZYk+oWNMQIzzR+6S409zcpHaHQ==
Content-Language: en-us
Importance: Low
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/kbasTbUN0PZn557KclvksB-pg4s>
Subject: [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 09:56:27 -0000

Hi dear TLS experts, 


Apologies for my stupid question for advise: 

I am currently working on some design requirements for mutual authentication
and have a question regarding verification of client certificate. 


In many web scenarios the simple use is server authentication by certificate
and verification of client id by username & password or by a simple
verification of client certificate. 


Are there any RFCs that speak (beyond the general verification of the
certificate in mutual TLS authentication) to the need to also verify the CN
inside the client certificate against an additional whitelist _before_
establishing a TLS connection. 


For example in this scenario: 

A client with a valid certificate may be allowed to connect to application
1, but would not be allowed to connect to application 2. (for sake of
separation application 1 and 2 are on separate servers (application 1 on
server 1 and application 2 on server 2).) 


>From my current understanding, I would establish the TLS connection in both
cases, do mutual authentication and then let application 2 reject access
based on that the user is not allowed to access it. There is a question
whether this would expose to a risk that server resources could be exhausted
by allowing to establish the TLS connection before failing, but this does
not seem too bad to me. But maybe I am missing something.


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)


Thank you and sorry for bothering, Tobias