Re: [OAUTH-WG] client certs and TLS Terminating Reverse Proxies (was Re: I-D Action: draft-ietf-oauth-jwt-introspection-response-08.txt)

Rifaat Shekh-Yusef <> Mon, 28 October 2019 15:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5DF1F12010F for <>; Mon, 28 Oct 2019 08:05:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XxoGugxT3QjB for <>; Mon, 28 Oct 2019 08:05:23 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::d2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6D399120071 for <>; Mon, 28 Oct 2019 08:05:23 -0700 (PDT)
Received: by with SMTP id c11so11019808iom.10 for <>; Mon, 28 Oct 2019 08:05:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=10KSBIH1v3R7um9wuUay5yTEXOHJp0agh39XNBpsXHU=; b=DO4lcsuK8ir7p2ddYkGbroqnmLr4KpQPPBH9kAzwX4SQI98/Gn6svoVsCjUeqMYcKH f5w4trLS0LZOC16skL+TB9ajGHBZSiPGxrQqH6Cc1n42GLpbWjcxfi6x0rq+UvNJ2p1d JT9Lp8tF2lB6+9qaENCaY7X8LYdi81mVIPcXDwB+fF6aH8J8dk0k3OIqgi5UqLWZHGXE VDNwRIqEyRNG1OErpP970vWHUt5V2O4a5NTpJCw2SIuNEboMe1/iQIfLlLqtFhSiSW12 Vz9d2LJibuZimXR2e+NcdPTvGkZUYNHw5ge/t2wa2q/Kr9eO3q7oY8bcjdEv2sdD/+RY 45bg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=10KSBIH1v3R7um9wuUay5yTEXOHJp0agh39XNBpsXHU=; b=ga+w8zDrlPmJ6WumywSDwVHrGJyfdLo6BuICSQIIae2J2Utm9juWdWJcVyVNjDNvIH fg07n+uKkcdonTwvkphfVwuLArochrf/SlWpDTUgPH+qGUNDT9IQ3R4HxMhEXGbEXcC+ v6LBbtk0VhNHYSqQWy5r+XTNV6r9Wb2aJUYtwKnBMYmwKkZWqaVF2hBxkGOvNKEPt01U jIJj5QoLKy9z/Tf7y2BkjWRFOhclto0ZRMcQ5qhpWKwEvFcBrz1FtDpEwIytWEXPzw1B T1guGKcoyH9k/cJ847l0lM3mlb8tskSkSoydidJTsyPD3eFU67s4oFnwCdmqRk/aO+ky vOnA==
X-Gm-Message-State: APjAAAVGr78iAkyqM8OtTrbeqoNlzRv1zLspy9ynKcINtSi6W6WpHlS6 2g4v7vjTN9EIRKLh9or3A8hfx1+UHWU63appHoM=
X-Google-Smtp-Source: APXvYqyK3Hn5Ie3NWFJzLKB9LzVjldTnkwxLEWLrHQnZY76q0aAmVx5tlLMAgadraHjM1hJyF1H/fjtcTP7HYQVS7JE=
X-Received: by 2002:a02:c48e:: with SMTP id t14mr10167720jam.121.1572275122695; Mon, 28 Oct 2019 08:05:22 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Rifaat Shekh-Yusef <>
Date: Mon, 28 Oct 2019 11:05:10 -0400
Message-ID: <>
To: Brian Campbell <>
Cc: Benjamin Kaduk <>, Justin Richer <>, oauth <>
Content-Type: multipart/alternative; boundary="0000000000002d71610595f9d47f"
Archived-At: <>
Subject: Re: [OAUTH-WG] client certs and TLS Terminating Reverse Proxies (was Re: I-D Action: draft-ietf-oauth-jwt-introspection-response-08.txt)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 28 Oct 2019 15:05:25 -0000

Thanks Brian,

I guess my question is: given RFC7239 and the fact that it is
straightforward to secure the channel between the terminating reverse proxy
and the backend service in a cluster, is there anything, from a standard
perspective, that we need to do beyond defining a new parameter to carry
the client certificate information?
You seem suggest that the answer is yes. If so, can you please elaborate on
why is that?


On Mon, Oct 28, 2019 at 8:42 AM Brian Campbell <>

> On Sat, Oct 26, 2019 at 3:55 PM Rifaat Shekh-Yusef <>
> wrote:
>> On Fri, Oct 25, 2019 at 3:47 PM Brian Campbell <
>>> wrote:
>>> I did look at RFC7239 when doing that and it could have been made to
>>> work but felt the fit wasn't quite right and would have been more
>>> cumbersome to use than not.
>> Can you elaborate on this?
>> These days, with the zero trust model in mind, there are orchestration
>> tools, e.g. Istio, that easily allows you to establish an MTLS channel
>> between the reverse proxy/load balancer/API GW and the backend servers.
>> Why is that not sufficient?
>> Which part is cumbersome?
> What I meant was only that in the course of writing
>, which aims to
> define HTTP header fields that enable a TLS terminating reverse proxy to
> convey information to a backend server about the validated Token Binding
> Message received from a client, it seemed more straightforward and
> sufficient for the use-case to use new HTTP headers to carry the
> information rather than to use new fields in the Forwarded header framework
> from RFC7239.
> *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.*