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

Nico Williams <nico@cryptonector.com> Mon, 16 April 2018 18:51 UTC

Return-Path: <nico@cryptonector.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 E4F71126CF6 for <tls@ietfa.amsl.com>; Mon, 16 Apr 2018 11:51:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 dgWUNZv2eAh5 for <tls@ietfa.amsl.com>; Mon, 16 Apr 2018 11:51:38 -0700 (PDT)
Received: from homiemail-a95.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 731BB126CC4 for <tls@ietf.org>; Mon, 16 Apr 2018 11:51:38 -0700 (PDT)
Received: from homiemail-a95.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a95.g.dreamhost.com (Postfix) with ESMTP id AE61F6000915; Mon, 16 Apr 2018 11:51:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=4H8/NOIIRLypii KGD2SXcl4AojE=; b=ZHR3pbviS4szoO8tTndQMHsEgEN9zVYSE338wzIEFj74ff 7ge0ivFF56ednavOu+cGfYjPltxyuaLaNB6pi/SAXV6atIMJJxtW8+MyWf8WKfFG LJtD2H5NrjnpjcnoIJbvQ8v0A7nr5ppxl2z1WxCbx29BUrVbs2y5SYvfx3P/Y=
Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a95.g.dreamhost.com (Postfix) with ESMTPSA id 609106000139; Mon, 16 Apr 2018 11:51:37 -0700 (PDT)
Date: Mon, 16 Apr 2018 13:45:44 -0500
From: Nico Williams <nico@cryptonector.com>
To: Tony Arcieri <bascule@gmail.com>
Cc: TLS WG <tls@ietf.org>
Message-ID: <20180416184543.GB25259@localhost>
References: <064a01d3d569$2a3cdaf0$7eb690d0$@gondrom.org> <70D47A63-5703-4D14-BDCF-09CE52ED1105@dukhovni.org> <CAHOTMV+ULS9pxZaD9Jj4DgUmti-9t=_ugr25xDPfWLErWLCQeQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAHOTMV+ULS9pxZaD9Jj4DgUmti-9t=_ugr25xDPfWLErWLCQeQ@mail.gmail.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/gSpaBpiCFhphs34LtsZj1jj2LyA>
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 18:51:40 -0000

On Mon, Apr 16, 2018 at 11:38:28AM -0700, Tony Arcieri wrote:
> On Mon, Apr 16, 2018 at 9:11 AM, Viktor Dukhovni <ietf-dane@dukhovni.org>
> wrote:
> > 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.
> 
> There's also the problem that (at least in an SOA/"microservice
> architecture") people will inevitably want some resources to be accessible
> without a client certificate, e.g. status endpoints or anything consumed by
> clients which do not support TLS certificates. In these cases it really
> helps to force things up a level out of the TLS handshake into something at
> the application level like an ACL language that lets you whitelist
> unauthenticated access to these resources.

Indeed, one might even say that user authentication should be driven by
application needs.  This is done in HTTP, for example, via 401
responses, which can trigger HTTP authentication.  Granted, HTTP
authentication methods are fairly limited.

If a client is authenticated at the TLS layer, authorization should
still happen at the application layer as much as possible, as otherwise
access control is very coarse-grained.

Nico
--