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

Brian Campbell <bcampbell@pingidentity.com> Fri, 25 October 2019 19:47 UTC

Return-Path: <bcampbell@pingidentity.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 972CB120044 for <oauth@ietfa.amsl.com>; Fri, 25 Oct 2019 12:47:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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=pingidentity.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 6BKkw_xoSQU6 for <oauth@ietfa.amsl.com>; Fri, 25 Oct 2019 12:47:04 -0700 (PDT)
Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 963B512003E for <oauth@ietf.org>; Fri, 25 Oct 2019 12:47:03 -0700 (PDT)
Received: by mail-lj1-x22c.google.com with SMTP id l21so4067692lje.4 for <oauth@ietf.org>; Fri, 25 Oct 2019 12:47:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wVnfHTKLXRITjv+Fh98Y3QJsM2tu4tKkSgHCOhMLEyw=; b=i0LqZHzZJSiTMz1uf5iKjwsKAgE+hIkX/OPVWG/Law2p1wwV3JklOhokhPf/keVIqk ZolWlZ0LKsqzPlXxcVJAWQb3JSdNswKAPskK7OQJWePDeuUn1w1rS6poE4Czhn/moxvX xYfPX5JozJdcB45/MpqVdqtYGpecnl5raKBuI=
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=wVnfHTKLXRITjv+Fh98Y3QJsM2tu4tKkSgHCOhMLEyw=; b=CABbyMbzagbozKc184U0gsGIME61acvXVGoOQ799w67Oe9Q4WsB3v4KGodWEgBHeQl +dcmLXQVIaywaBX/7PBPaBmWILVi0JCf0IlE5MTp962ED5BouKdfuXGnYaBgimEmMsyl Ccq/IN4sVC5vIeMyo6Xwdoy4Fi5OnVX3UF2Klt/EtlydeNRvK1rrDvzreu1dvC5thIaQ kBisEP0rqquZZSnx4IKoplZih06Vd4Kffv2u//y9FEw2MLQXVf4kSf8XcbjADNVzWscw DnfQbGVJV3/U4c9lbp9fnsCO0YRmZ9xfYQlEM8A3o+updtQN0T9+iEDgQXaJ7bkTz1D3 PZ9Q==
X-Gm-Message-State: APjAAAX2zwbwn8WBoguVR0cymSTWJ2gBcZeL8TWP09LeHbOKGK5EpLz7 JvVUqS6sRQEs1VhwRxKoDYm1tnv6ySBCNuV9K+J0MygSpdO5tZCNRuZzxEYy/ufY6elRGmVFTYa pNQl4U64ufZLtfw==
X-Google-Smtp-Source: APXvYqzr6i/0KDIVIvwE+ebhz1zIuooDW4X5kzGe2Hj+pQCKupQVc+RXk/Cc6tGZU+NFF7LMOKn0NRNA39kxGrbWFY4=
X-Received: by 2002:a2e:8204:: with SMTP id w4mr3652721ljg.3.1572032821754; Fri, 25 Oct 2019 12:47:01 -0700 (PDT)
MIME-Version: 1.0
References: <85D42AA1-FF57-4383-BACB-57C5AA32CFAC@lodderstedt.net> <CAEKOcs2gkM3Henz5nS04_EuBQXWWbJU5K02ErP0rnVZXmjxXJQ@mail.gmail.com> <20191021020546.GZ43312@kduck.mit.edu> <CA+k3eCS7pf3wXBkpbXE0AXKUGogo0YcHd8oWfiBfkPB5axGQQw@mail.gmail.com> <8A8B8892-9D16-4210-BC13-47B5D7859976@mit.edu> <20191024170326.GO69013@kduck.mit.edu> <CAGL6epJZtTXKSGFj0BfhF3kd_Z-z2xzOWXOPEKXc5m18Z4L1uA@mail.gmail.com>
In-Reply-To: <CAGL6epJZtTXKSGFj0BfhF3kd_Z-z2xzOWXOPEKXc5m18Z4L1uA@mail.gmail.com>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Fri, 25 Oct 2019 13:46:35 -0600
Message-ID: <CA+k3eCS8VuCfy4XeqYmLuuLK=rLvHsonSZj4i9O11U-mcua9Pg@mail.gmail.com>
To: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>
Cc: Benjamin Kaduk <kaduk@mit.edu>, Justin Richer <jricher@mit.edu>, oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000ea92e80595c1696f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/jQ5MAZ1XCvxWbHwqlT3ITEEQoKo>
Subject: [OAUTH-WG] client certs and TLS Terminating Reverse Proxies (was Re: I-D Action: draft-ietf-oauth-jwt-introspection-response-08.txt)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 25 Oct 2019 19:47:07 -0000

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" - https://
datatracker.ietf.org/doc/draft-ietf-tokbind-ttrp/ 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.

On Fri, Oct 25, 2019 at 8:02 AM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>

> You might want to look at RFC7239, which is trying to address the issue of
> the loss of information by proxies.
> https://tools.ietf.org/html/rfc7239
> 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 <kaduk@mit.edu> 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
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth

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