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 <> Sat, 26 October 2019 21:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3774812003E for <>; Sat, 26 Oct 2019 14:55:11 -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 JhVg2H6JOcmC for <>; Sat, 26 Oct 2019 14:55:08 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::d33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B7570120013 for <>; Sat, 26 Oct 2019 14:55:08 -0700 (PDT)
Received: by with SMTP id r144so6371786iod.8 for <>; Sat, 26 Oct 2019 14:55:08 -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=i5xo+oarvKfvVIv8cUkCreo2kG2Z1CdL+S2uPKatspk=; b=e3tTSJ86eDADYk7pzM1WcZdUnZSLy47C8MM5B02EQ3SPPwOBhLfRnWCVv8cJJw3Nm6 i0GTRXCe+eqUpLFBlW8syHo3QYppBq78c7TUFxRDU/nTRa1INCWJDv/yua7CtH250ZFB f349xceDxYLR6Pt8A4rEujVa5u8HBt2Upc8sdYWw7v6qAi4d90NL8NLMcrSUhUFbWi/7 UDFnXHbe9+qQoOs33Y0lBRaE8FtyaPMYTW6mtXKwIn3RdLBRcpgJ1xKflnOaeSlIwSyN LDl6id07jN06PTBEMRaxNY/KbQyFAoWk7OA9oUGiHwyO7/ow4w/NFqNRPVoR2Gxe+I82 57Fg==
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=i5xo+oarvKfvVIv8cUkCreo2kG2Z1CdL+S2uPKatspk=; b=P1zHvRl0y5S5m5zil9ySAjl+V4BKBDsOQDs2ZsTfuRE1ZwNmD7mUwpnKynKizfA+wH RcSnT1Q+UF+R6dC+mOLDohz7fFY0jVcz7Guxa2cKrG2i9UiOt0kBoLWuhVUjZYscZmCD J+6nBYuCQLLkWnRwQmPEhOA9bBbZSO7Wll48dSnjGCoYnBSZtliCrmH4NylXYm8Wg0dC m/uH2ozAs7J65RHv/9x0biRatDQM5LU7/76yKjOdNsbEDfM+qqevcdZbMlJpS6ZXOweF 8pA3Z9Pl8+EEgNlKhntKSDEKWXN+T+m+mo1f2JBB9GLoTiEi3QwV1WjhEbZODWIs4HvA Gckw==
X-Gm-Message-State: APjAAAWvkkJyz8LoYbsxo3GDtMPsrzixoPprpZfy7iZlmsNypxY81A54 7yJUrPAtq4lwid7MQ/LHOnBxUMqDaJMJjrmReRs=
X-Google-Smtp-Source: APXvYqxNmwdQIBIezh5x/kskwyjX9zgZkKa3xTJm20z5e/bPo3uMMKTAWuq5OgNmr3TJSx4FRKYCGujJrzZj+9y86CE=
X-Received: by 2002:a6b:5908:: with SMTP id n8mr11246168iob.31.1572126908050; Sat, 26 Oct 2019 14:55:08 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Rifaat Shekh-Yusef <>
Date: Sat, 26 Oct 2019 17:54:58 -0400
Message-ID: <>
To: Brian Campbell <>
Cc: Benjamin Kaduk <>, Justin Richer <>, oauth <>
Content-Type: multipart/alternative; boundary="000000000000e573a40595d751cb"
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: Sat, 26 Oct 2019 21:55:12 -0000

On Fri, Oct 25, 2019 at 3:47 PM Brian Campbell <>

> Few thoughts, comments, & questions.
> I've always kind of assumed that the ship had already sailed on doing
> anything standards related with this because implementations out in the
> wild like Apache, NGNIX, IIS, etc. were already providing ad hoc
> solutions and had been doing so for a long time. But this thread at least
> hints that there may yet be an appetite for such a standardization effort?
> I'll be in Singapore but my (long) flight is scheduled to land about the
> time when HotRFC starts. I could perhaps do something for secdispatch
> though. Ben, is a draft needed for that or can secdispatch be engaged with
> some slides amounting to a problem statement? I'm just not confident a
> draft could be published in the next week or so before the cut off.
> I did put it some work on a conceptually similar issue around token
> binding with "HTTPS Token Binding with TLS Terminating Reverse Proxies" -
> not too long
> ago. It was a WG item that had gone through WGLC but kinda stalled out
> waiting on the chair(s) for the shepard writeup when adoption questions
> around token binding came up.
> There are lots of ways to approach the problem and solution but I think
> perhaps a lot could be taken from that document and applied to the similar
> client cert situation.
> 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?


> On Fri, Oct 25, 2019 at 8:02 AM Rifaat Shekh-Yusef <>
> wrote:
>> You might want to look at RFC7239, which is trying to address the issue
>> of the loss of information by proxies.
>> The document does not have a parameter to carry the client certificate
>> information, but it allows for new parameters to be defined.
>> Would that help in this case?
>> Regards,
>>  Rifaat
>> On Thu, Oct 24, 2019 at 1:03 PM Benjamin Kaduk <> wrote:
>>> On Wed, Oct 23, 2019 at 10:13:04AM -0400, Justin Richer wrote:
>>> >    I also agree. Would it be possible to get this pushed to http or
>>> tls? It
>>> >    would be more appropriate there, and very helpful to have a general
>>> spec
>>> >    for this.
>>> I think it's possible to get such work done in one of those places, but
>>> first someone has to actually write a draft.  Barring that, a HotRFC or
>>> secdispatch slot in Singapore would probably be good for drumming up
>>> interest.  In related news, I am told that draft-duke-quic-load-balancers
>>> had some time in the QUIC interim this month, and may be moving towards
>>> adoption, so time may be short if we want to have a fully general
>>> solution.
>>> -Ben
>>> _______________________________________________
>>> OAuth mailing list
> *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.*