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 <rifaat.ietf@gmail.com> Mon, 28 October 2019 16:00 UTC

Return-Path: <rifaat.ietf@gmail.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97CA71201E4 for <oauth@ietfa.amsl.com>; Mon, 28 Oct 2019 09:00:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 waEF-XMdOuTb for <oauth@ietfa.amsl.com>; Mon, 28 Oct 2019 09:00:15 -0700 (PDT)
Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (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 5FB65120098 for <oauth@ietf.org>; Mon, 28 Oct 2019 09:00:15 -0700 (PDT)
Received: by mail-io1-xd2b.google.com with SMTP id k20so1231912ior.0 for <oauth@ietf.org>; Mon, 28 Oct 2019 09:00:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vPRQAtsMnxcvosIaiWPHje8mBV7Vy5w3bG1CRMpVkyU=; b=Tnj92cC0l4qsn5VuseZUngIXWs1fQ2tPMGEUlxM+YP1A9nEp5i/C+q/BCOO0q7oIZC rCSBst5W0aoHjsH6Hs0V/VQxnRI2UOb76eeDDG+UV/qkIAoD1wjFuGKbsQcbwMJlRJBX 1uMKkZTEZa1HxovGJ9SRtO98rSaYfdu7pTP4A8DS5TTOuudaqeDjUh9J8UpXKF3f00Zy Ne80DxowgfsNLXUGiI5THz1xBnf3OSkDy6twcJaXpxLCitr0iWjhNYFzc12G3bnvZBvj WCnSIjj4YXoJg4YiWkezI89PTYJaZbBUbYdVTfouQ6V7Mr5vxrpancfVk8mYlp6fvR4d S3Pw==
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=vPRQAtsMnxcvosIaiWPHje8mBV7Vy5w3bG1CRMpVkyU=; b=YX7gpKG0dEO9Vv1xjp4zre6mkwonBHwzmq46XTJCi3mtfC1ZdHXftoRjPvGY40yvhx kR1g1EfwStK4/RX8wu/kqRu4Bq31RfJhyTftA89G76mgOGcW9m/0r8dI6QFMzBDQmx5w M1AyKQHqzKMu0MCazzX21mrIJqJcjD3L1SZotGT4rS6njWMi2xIaYUiitLuRDXz6A9og DxeRiNN50jvRor71WpUk50EWjfsyR3r8aNDSd24Prq1XsJsNEK9TR5+wYGEmV4ofW/3Y JL8+ipnK7wusXBC68MTLC9TQdWrRFbe9HnOcJKtf0BJ/Zlu1KktCoAH40/A360EJBeNg uwAA==
X-Gm-Message-State: APjAAAUryQTy5ZuV93VDDOBgshFPfaeRfmWIiKq5rVgygHDkmkxydb9r kQ5mfeQVivmO9W9oeG5jID1pgZCIKk/jbGTXQhk=
X-Google-Smtp-Source: APXvYqzoV7i5xhPno1QHfwTC8PRLOhU7zlIDhtauS8hS8o0qJsAyoJJLZHDuQUQsfK4D65S1V3m/g0jZA/8CJxQndpU=
X-Received: by 2002:a02:1c41:: with SMTP id c62mr15907563jac.132.1572278414573; Mon, 28 Oct 2019 09:00:14 -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> <CA+k3eCS8VuCfy4XeqYmLuuLK=rLvHsonSZj4i9O11U-mcua9Pg@mail.gmail.com> <CAGL6epKTV5hXqm2-qgUyG-iA90eLu49GjOKeyLcfsn2naTSV5w@mail.gmail.com> <CA+k3eCQ87n4m--nBc+PX7qE727fqA6vM=meEJZxwfnbpJ2dOsw@mail.gmail.com> <CAGL6epJQbVDrAKB+zNAPuaG0+uLxF3HijEE6=vgYaeXxB_2PXQ@mail.gmail.com> <CA+k3eCQbku0V6z2wCM084FW342dY6=_H7mEv6U3sHCDgefkxXA@mail.gmail.com>
In-Reply-To: <CA+k3eCQbku0V6z2wCM084FW342dY6=_H7mEv6U3sHCDgefkxXA@mail.gmail.com>
From: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>
Date: Mon, 28 Oct 2019 12:00:02 -0400
Message-ID: <CAGL6epLR6_pG55F1PzZJf2aSd7J51tu9yPyOqLB9a3Qd3ibDDA@mail.gmail.com>
To: Brian Campbell <bcampbell@pingidentity.com>
Cc: Benjamin Kaduk <kaduk@mit.edu>, Justin Richer <jricher@mit.edu>, oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000006385690595fa983b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/LUh1TdXcmA8y9z5Vw3hx0exaEkQ>
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-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: Mon, 28 Oct 2019 16:00:26 -0000

Ok, then we are on the same page.
The reason I am asking is that I have a use case where I need such a
mechanism.

What is the advantage you see for defining a new HTTP header over extending
RFC7239?

Regards,
 Rifaat



On Mon, Oct 28, 2019 at 11:32 AM Brian Campbell <bcampbell@pingidentity.com>;
wrote:

> I don't think there's anything beyond defining something to carry the
> client certificate information (including the format and encoding). And it
> could well be a new RFC7239 parameter. Or it might just be a new HTTP
> header on its own.
>
> On Mon, Oct 28, 2019 at 9:05 AM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>;
> wrote:
>
>> 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?
>>
>> Regards,
>>  Rifaat
>>
>>
>>
>> On Mon, Oct 28, 2019 at 8:42 AM Brian Campbell <
>> bcampbell@pingidentity.com>; wrote:
>>
>>>
>>>
>>> On Sat, Oct 26, 2019 at 3:55 PM Rifaat Shekh-Yusef <
>>> rifaat.ietf@gmail.com>; wrote:
>>>
>>>>
>>>> On Fri, Oct 25, 2019 at 3:47 PM Brian Campbell <
>>>> bcampbell@pingidentity.com>; 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
>>> https://tools.ietf.org/html/draft-ietf-tokbind-ttrp-09, 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.*
>>
>>
> *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.*