Re: Client-Cert Header draft

Brian Campbell <bcampbell@pingidentity.com> Fri, 24 April 2020 21:34 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 A6DFB3A0BE7 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 24 Apr 2020 14:34:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.569
X-Spam-Level:
X-Spam-Status: No, score=-3.569 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, RCVD_IN_MSPIKE_H2=-0.82, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pingidentity.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 B1N-beT7rNcU for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 24 Apr 2020 14:34:08 -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 2CB553A0856 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 24 Apr 2020 14:34:08 -0700 (PDT)
Received: from lists by lyra.w3.org with local (Exim 4.92) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1jS5xM-0000g4-0E for ietf-http-wg-dist@listhub.w3.org; Fri, 24 Apr 2020 21:33:56 +0000
Resent-Date: Fri, 24 Apr 2020 21:33:56 +0000
Resent-Message-Id: <E1jS5xM-0000g4-0E@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 <bcampbell@pingidentity.com>) id 1jS5xL-0000fJ-1F for ietf-http-wg@listhub.w3.org; Fri, 24 Apr 2020 21:33:55 +0000
Received: from mail-lf1-x131.google.com ([2a00:1450:4864:20::131]) by titan.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <bcampbell@pingidentity.com>) id 1jS5xI-0007ZG-UJ for ietf-http-wg@w3.org; Fri, 24 Apr 2020 21:33:54 +0000
Received: by mail-lf1-x131.google.com with SMTP id r17so8930754lff.2 for <ietf-http-wg@w3.org>; Fri, 24 Apr 2020 14:33:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=70n/s6BfBnRcBffsudZh0w8ac3A5GuKB8Ghi0yWwQbc=; b=O8XeKp3+0BEbkdh0NhSjs8yU9/XXd93LYDYeJVYzsAnDf/YlYjsCma/O3os7n8vxu4 ct/I4dE9TBP2Zjk/T4e9c+K5O9b4ZxtMb+HX/+gU+wtq51PaLSfV64doUOaTIrgdS4cE 14qTgzpXiBg58Ua3ibCPGgsRcTHWs8eILZ+3GrOXodzc79MGX13sK0uvraFQgm7NaDda ZaGyboMMiPxCKFVgHWrgEO3LtgzZ4Ea+5QYLZRZLhT0Xv1FDEAoryPTjSezJ7dyYQ/dq 6y44aNK6GUCZWHX0O5junFMNo16eEKsA+sWCxDujyhEiMFMFnxRH9bf2jq6hqBmeD/z0 B/OA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=70n/s6BfBnRcBffsudZh0w8ac3A5GuKB8Ghi0yWwQbc=; b=noRag8FYbmVJQ29BeENTO/mjEd8Yp/4XvuZv2/amIub8V4TdoWhbPkWin3DmFt/H4y zjmGmGdX4m3r0Y5M+Gf2H1TVwfjqL8QcGJk/WzPLWNubMMz5N1IlkbFIl9PXloteoJ+c wBEUeP3I533t2xgS3g0qV9wKnm3+6ouGj2xw3I/PoYNkZn4mOX+8GaTbpd1taupV2BO7 t62l+vz85ViM8d06fLKM5nkf1TI15AkozmWd9ARVrow+qwtmaungnVTREDcQMjXABFvL ZWz/vHYM0Qyg9aoGeZ1FsP311McCmJn3jufemnwMFFfh28768fNum1NDDAFjZ4PcCumW vDWw==
X-Gm-Message-State: AGi0PuZU4pDr1kGk2izLcToQzoHrqb/7TchGcJQ4lvDlvsW6B72FXLM+ 9v0/rbOboX46GWt2ibAnRk4ZEQXQp2mqf67P9+NgqL5MQn4aZubyR+OhCd5WdcyxOmtPS29OxR/ 0E6YWN0OidIB0V3nFlTfXdd3Qyg==
X-Google-Smtp-Source: APiQypLqQJKDHuxBrpVOtFRPdwSuf5Q0h1ML/e/lshfX80B3dKahYBQtaZMW1hw4XQkMbLB9RRKXvRBJCmD870WPi0g=
X-Received: by 2002:a05:6512:d1:: with SMTP id c17mr7668441lfp.167.1587764021163; Fri, 24 Apr 2020 14:33:41 -0700 (PDT)
MIME-Version: 1.0
References: <CA+k3eCRQhuS9TyEVdF6ZAfLSyPngjDLvctUTc++2Ok+RJmw0qA@mail.gmail.com> <5AC09590-1978-4EAB-B5D9-B8E126ED839C@sharp.fm>
In-Reply-To: <5AC09590-1978-4EAB-B5D9-B8E126ED839C@sharp.fm>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Fri, 24 Apr 2020 15:33:14 -0600
Message-ID: <CA+k3eCR0fDfDtWWraZt8=yHsfRtuyMj_rY3bz7YNrWzHTyVGaQ@mail.gmail.com>
To: Graham Leggett <minfrin@sharp.fm>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="00000000000078110605a4101ef2"
Received-SPF: pass client-ip=2a00:1450:4864:20::131; envelope-from=bcampbell@pingidentity.com; helo=mail-lf1-x131.google.com
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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: titan.w3.org 1jS5xI-0007ZG-UJ 192b9471d252350e6231538c76486e61
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Client-Cert Header draft
Archived-At: <https://www.w3.org/mid/CA+k3eCR0fDfDtWWraZt8=yHsfRtuyMj_rY3bz7YNrWzHTyVGaQ@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/37549
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>

Apologies for the slow reply. And thanks for the support of the idea and
suggestions. At this point, while this is still just an unadopted
individual draft, I think I'd categorize the suggestion as another voice of
support for something more to be done directly with respect to protecting
the header from injection. Using the server certificate and an asymmetric
signature is an approach to that (which I admittedly hadn't thought much
about) which would have its pros and cons.



On Tue, Apr 21, 2020 at 4:17 PM Graham Leggett <minfrin@sharp.fm> wrote:

> 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/,
> 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
> —
>
>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._