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

Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> Mon, 16 April 2018 13:20 UTC

Return-Path: <kathleen.moriarty.ietf@gmail.com>
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 F2D8E126E64 for <tls@ietfa.amsl.com>; Mon, 16 Apr 2018 06:20:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 QgciHM8lfh9l for <tls@ietfa.amsl.com>; Mon, 16 Apr 2018 06:20:23 -0700 (PDT)
Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (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 C5934127522 for <tls@ietf.org>; Mon, 16 Apr 2018 06:20:21 -0700 (PDT)
Received: by mail-oi0-x22c.google.com with SMTP id u84-v6so14463231oie.10 for <tls@ietf.org>; Mon, 16 Apr 2018 06:20:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ipIrogjOdDtx8UhsVs6AQElLTrOtKYVredYa5IlMIaE=; b=Cy244DWeZP01pOisosqfmdck7v6etgs0p23ilsSpIyPjh3QVxAskTbUi3RWtAYQv5U Iup+S7Fh4DWvnjHeL41F9TMbTG0lcxUpxkGBOzx5Ux4u8y7k2eUsGkKyW/7YoRkee2j6 T3wxkrP834/RNmhiAZx9rwOSMlmfcKWI4W2kzkXHlr9yaHDYIO6y6LHy+kctttk1nPT3 2aMVuD7Skpj5RHYh8haRUS7jLEMg/6PYwkYLBb5N4VJVqU3345yzhW6t/DBhUfnP1r4l 6+mswKpSknJ+kIksPIHYn9C+qu8XS7KIImglk3SlmO3AtwLCjF1unol+C6HgQmKDY7Wt lxCQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ipIrogjOdDtx8UhsVs6AQElLTrOtKYVredYa5IlMIaE=; b=UndEltYMfw40TEPT3Ac34znmuOOsXdBQHDAumLr2ESrdiC0otXBY9EQfI0lJglDSOS 2Zda6Q7l+tW4n3DS25GZVH/+vDgJ0f3NxDv1/TC4h+yr/ROFPoUBY1Y5QKOBZTQ6vXja pNz3ew7ZTSbgtAMNTJ2EGrx8G/ppUE2MZg5J6ChkvjzNA+3S5eNaBH1Mb64L03+A6why vBWVD5uFgyYSXLBWgqkpuWLXowoCLMJk+KdoqQvo+1fG9EhIfv673Y4U9ycdneECBkew fOe6DTag1SaRYv7iNLvPEjJiQhwucNl+BmKYRFKmeU2yjF7Ed4yzkPFHA3zH7OqyWQc9 O0Ew==
X-Gm-Message-State: ALQs6tALjwMNH8+1tfaPPw/ktuWcNczFCfyS+AeudxchoUU8cEGMJP4n aN/cgde6wSpWzPsr7Pn+D4uZ4PVf
X-Google-Smtp-Source: AIpwx4+uFYPNLer8nutA2OzbMvQQnpZaVncVhoY7gd8UDu1JrO9tB9+iCuZnvjr+GnBTes6K3N2Emw==
X-Received: by 2002:aca:1204:: with SMTP id 4-v6mr3034613ois.241.1523884821042; Mon, 16 Apr 2018 06:20:21 -0700 (PDT)
Received: from [172.20.0.107] ([12.15.241.29]) by smtp.gmail.com with ESMTPSA id c49-v6sm8058868ote.79.2018.04.16.06.20.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Apr 2018 06:20:20 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail-9AE11407-A791-4475-8986-C80DB17FEA7B"
Mime-Version: 1.0 (1.0)
From: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
X-Mailer: iPhone Mail (15E216)
In-Reply-To: <CABcZeBPpmJBfA13VzvuspO7QSx46re_UR=e+OvqvgsBpMk8EQw@mail.gmail.com>
Date: Mon, 16 Apr 2018 06:20:04 -0700
Cc: Tobias Gondrom <tobias.gondrom@gondrom.org>, "<tls@ietf.org>" <tls@ietf.org>
Content-Transfer-Encoding: 7bit
Message-Id: <0FEA7711-7DC1-487B-A544-FAEFC9377C96@gmail.com>
References: <064a01d3d569$2a3cdaf0$7eb690d0$@gondrom.org> <CABcZeBPpmJBfA13VzvuspO7QSx46re_UR=e+OvqvgsBpMk8EQw@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/TvjDwBpQBYxUP_AQskuwsz4ZXbc>
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 13:20:26 -0000

Hi Tobias,

If you use search terms that include pkix, authorization, access control, and attribute certificate profile, you’ll find a few documents.  This one should be helpful based on your description:

https://tools.ietf.org/html/rfc5755

Best regards,
Kathleen 

Sent from my mobile device

> On Apr 16, 2018, at 4:55 AM, Eric Rescorla <ekr@rtfm.com> wrote:
> 
> I am not aware of anywhere this is documented, primarily because it's so application-specifiic.
> 
> -Ekr
> 
> 
>> On Mon, Apr 16, 2018 at 2:56 AM, Tobias Gondrom <tobias.gondrom@gondrom.org> wrote:
>> 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
>> 
>>  
>> 
>> 
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>> 
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls