Re: Client-Cert Header draft

Graham Leggett <minfrin@sharp.fm> Tue, 21 April 2020 22:21 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 258373A0C03 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 21 Apr 2020 15:21:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.749
X-Spam-Level:
X-Spam-Status: No, score=-2.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sharp.fm
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 svGNLu6aj3IX for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 21 Apr 2020 15:21:17 -0700 (PDT)
Received: from lyra.w3.org (lyra.w3.org [128.30.52.18]) (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 01FFF3A0BFF for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 21 Apr 2020 15:21:11 -0700 (PDT)
Received: from lists by lyra.w3.org with local (Exim 4.92) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1jR1D6-00086i-4y for ietf-http-wg-dist@listhub.w3.org; Tue, 21 Apr 2020 22:17:44 +0000
Resent-Date: Tue, 21 Apr 2020 22:17:44 +0000
Resent-Message-Id: <E1jR1D6-00086i-4y@lyra.w3.org>
Received: from titan.w3.org ([128.30.52.76]) by lyra.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <minfrin@sharp.fm>) id 1jR1D5-00085x-7i for ietf-http-wg@listhub.w3.org; Tue, 21 Apr 2020 22:17:43 +0000
Received: from chandler.sharp.fm ([2001:470:18b1:0:5054:ff:fe6e:d541]) by titan.w3.org with esmtp (Exim 4.92) (envelope-from <minfrin@sharp.fm>) id 1jR1D1-0007we-0F for ietf-http-wg@w3.org; Tue, 21 Apr 2020 22:17:43 +0000
Received: from [IPv6:2001:470:18b1:1:39d9:a4f3:4a64:5fb2] (unknown [IPv6:2001:470:18b1:1:39d9:a4f3:4a64:5fb2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: minfrin@sharp.fm) by chandler.sharp.fm (Postfix) with ESMTPSA id 828BA2891D0; Tue, 21 Apr 2020 23:17:27 +0100 (BST)
DKIM-Filter: OpenDKIM Filter v2.11.0 chandler.sharp.fm 828BA2891D0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sharp.fm; s=default; t=1587507447; bh=hGgbAlj2WtBZkaW+2yVopE6R+rY/kqIYMGv1bQpjmHM=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=BsI6nLuafGWQNqGGhxr9wYNG6EbYYsPSTMegrN/OaPZwqwkx4RdO22q4Mmpu1DXsI JRSo2wv1drNpQ42t/VO5VFbZOXfTmasWsExp6R4/Xa9Al+Au0W0C5DA+kOIDhI9e/c bbVDM+7N2CjbQOqpW38TtEpcD96dqtuz/vrKsrL0=
From: Graham Leggett <minfrin@sharp.fm>
Message-Id: <5AC09590-1978-4EAB-B5D9-B8E126ED839C@sharp.fm>
Content-Type: multipart/signed; boundary="Apple-Mail=_1CB151C5-409D-4EFE-B672-8C169AAC16F2"; protocol="application/pkcs7-signature"; micalg=sha-256
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Wed, 22 Apr 2020 00:17:17 +0200
In-Reply-To: <CA+k3eCRQhuS9TyEVdF6ZAfLSyPngjDLvctUTc++2Ok+RJmw0qA@mail.gmail.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
To: Brian Campbell <bcampbell@pingidentity.com>
References: <CA+k3eCRQhuS9TyEVdF6ZAfLSyPngjDLvctUTc++2Ok+RJmw0qA@mail.gmail.com>
X-Mailer: Apple Mail (2.3445.104.11)
Received-SPF: pass client-ip=2001:470:18b1:0:5054:ff:fe6e:d541; envelope-from=minfrin@sharp.fm; helo=chandler.sharp.fm
X-W3C-Hub-Spam-Status: No, score=-4.1
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: titan.w3.org 1jR1D1-0007we-0F 3d29b5997fd1422e39ae6bf54e627811
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Client-Cert Header draft
Archived-At: <https://www.w3.org/mid/5AC09590-1978-4EAB-B5D9-B8E126ED839C@sharp.fm>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/37535
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <https://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

On 15 Apr 2020, at 23:01, Brian Campbell <bcampbell@pingidentity.com> wrote:

> I've somewhat inadvertently found myself working on this draft https://datatracker.ietf.org/doc/draft-bdc-something-something-certificate/ <https://datatracker.ietf.org/doc/draft-bdc-something-something-certificate/>, which aspires to define a "Client-Cert" HTTP header field that allows a TLS terminating reverse proxy to convey information about the client certificate of a mutually-authenticated TLS connection to an origin server in a common and predictable manner.

Big +1 for this.

I added JWT support to Apache httpd/apr in an effort to solve this problem, having one single header would be vastly simpler.

> I presented the concept <https://datatracker.ietf.org/meeting/107/materials/slides-107-secdispatch-client-cert-http-header-00> at the recent virtual IETF 107 secdispatch meeting <https://datatracker.ietf.org/meeting/107/materials/minutes-107-secdispatch-00> and the outcome from that was basically that there seems to be some interest in pursuing the work and the suggestion that the conversation be taken to the HTTPbis WG (and also keep TLS WG involved - presumably if the work progresses). And that's what brings me here. I also hope to get a little bit of time at one of the upcoming virtual interims to present/discuss the draft.

Having read the draft, one thing I would suggest is that the ability exists for the contents of the Client-Cert header to be signed, so that anyone who cares can verify that the header came from where it said it came from.

To simplify this even further, if the Client-Cert header was signed by the private key of the certificate of the server that terminated the request, a lot of complexity around figuring out the origin of the header evaporates. (I wouldn’t make this a MUST requirement, but maybe RECOMMENDED perhaps).

As an optional one step further I personally would then connect the terminating reverse proxy and the backend with a client certificate connection using the TTRP reverse proxy’s certificate. The backend can then verify the client certificate (the TTRP cert) as being expected, then verify that the Client-Cert header was signed with the TTRP certificate. If this checks out, and we trust the TTRP as having not been tampered with, we have a strong path.

"A certificate is represented in text as an "EncodedCertificate",
   which is the base64-encoded (Section 4 of [RFC4648]) DER [ITU.X690]
   PKIX certificate.”

To do this the payload of the Client-Cert header would be a base64 of a DER encoded RFC5652 CMS/PKCS7. The payload would be the DER encoded X509 client certificate, and the CMS would be the signed envelope.

Regards,
Graham
—