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

Brian Campbell <> Mon, 28 October 2019 12:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F0E3712004C for <>; Mon, 28 Oct 2019 05:42:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IaKJM8slPxdq for <>; Mon, 28 Oct 2019 05:42:17 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::12e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 93301120018 for <>; Mon, 28 Oct 2019 05:42:16 -0700 (PDT)
Received: by with SMTP id t8so7647822lfc.13 for <>; Mon, 28 Oct 2019 05:42:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jfWhc/v9Dzrocbha/NNEIP0LaLKceVQH1WriBG2LJxc=; b=cHACZvOExtu3lGKExiJF9G+Nx2oQukyeiU+XkoszsEZs08a+LJKBmUN8CFC6Dx3J6y QOINVjSYiJmM/K6aAL1k44cE5QeBERbKhGi+8bBBuk8zoJPk//ERiGRcGEuxYm4j65xF RkCefBQbKsLOGdIhyIcAbotzFmP3YH7ZX+XYE=
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=jfWhc/v9Dzrocbha/NNEIP0LaLKceVQH1WriBG2LJxc=; b=I8NiVdmMKjuovfQV68vHuwKyN/hfprcl6cpY9R4yAQK4RkIMVHJsbFl5gNTJHGqvhA c5WVyq/ud+oAbux/X1TBWUBKYYEUvrMlkPsQQ80v6iGXPoA+XwLaH3qgQomd0QK1F7dY GaKH4J59nsHq79Qk/NlvlFeDltXDqBKeB1tIioRgc8paUGCpU9age0ZnosRC6yFbcoTP z4rjMxa0LP3Paa3JnhDzLkWVEa0RR918y9zwnK2He/LT5epxMo4razsLGmbvo8ZyJskL WA6GVonqdP0WGPEsoDxF7D+5w70pz/8hza1Bj4W4kgM9LnKVM8x7qXLpyjUviiVZHyXl dcZw==
X-Gm-Message-State: APjAAAVhErsglUkaolfdWepWDDpJ1MXEtPT19ExdMqxqXgFz1RLxT2RK 7P8/M4RY0sJbAcv1LLs9lo4WoQxR4BGnpQqdMvvkZfdEyG8n0oaUHOdVSP8XHX5QA4CuHkjbb3B vCFcW9ZCWgtZq7g==
X-Google-Smtp-Source: APXvYqwp+MRb2uQgZ0RLhW/XO/ss6ibK6aDe3Dinkg1o6f4A8bVtwr9lP+n7C6qn4G5TMxWeT0nwKqlLOynRQLeM1dI=
X-Received: by 2002:a19:f811:: with SMTP id a17mr1874691lff.132.1572266534597; Mon, 28 Oct 2019 05:42:14 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Brian Campbell <>
Date: Mon, 28 Oct 2019 06:41:48 -0600
Message-ID: <>
To: Rifaat Shekh-Yusef <>
Cc: Benjamin Kaduk <>, Justin Richer <>, oauth <>
Content-Type: multipart/alternative; boundary="00000000000049972b0595f7d49c"
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 12:42:19 -0000

On Sat, Oct 26, 2019 at 3:55 PM Rifaat Shekh-Yusef <>

> 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._