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 <bcampbell@pingidentity.com> Mon, 28 October 2019 19:35 UTC

Return-Path: <bcampbell@pingidentity.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 9185312006D for <oauth@ietfa.amsl.com>; Mon, 28 Oct 2019 12:35:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.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 9NlQlHBq5a2T for <oauth@ietfa.amsl.com>; Mon, 28 Oct 2019 12:35:18 -0700 (PDT)
Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (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 25ACA120120 for <oauth@ietf.org>; Mon, 28 Oct 2019 12:35:18 -0700 (PDT)
Received: by mail-lj1-x235.google.com with SMTP id c4so12606595lja.11 for <oauth@ietf.org>; Mon, 28 Oct 2019 12:35:18 -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=ToDrQu7Xr820Vw5Fnkrd2s/HOjXfXsSNhig591mhJf8=; b=FNTeA+SwZzNX05hvPn3/bX9GZJw0EG1QXjFoNZuyHwDrLwaQ5RufzFSwT6WoE0XLoV qyQH3Fwzq4Aaj69sKc1BReC7OWLWwlJLOLfhnmqxh7yR+no6/I03IxUvDWTX8N6HI8KL GNS2S6/LMFDbozVOhoFJgsjbPso5F3THD5zU8=
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=ToDrQu7Xr820Vw5Fnkrd2s/HOjXfXsSNhig591mhJf8=; b=AYG4qMWJwBAEcRUBl6Slb8cXD/wWFKLdxl6preGchu69L0KYyD4qdkQEzdE8Ck7pF4 9ioeNIKXXcACZsymVi7RBZHLnjaE5EETseVAVr7Vt9p2hHjeD5GHZdx9+fgC3wKsoD1e y+jieAG+VsSVGsdGN3FtszYG4Ah71d+G8yzHtHZHS/Py/ybpkJ0ZvZITQ9loC9YqQ1aG Vy2SpNbtbnEykc+2OtMRMpnf7KGo+c9cgu2LOoCQSPw1a/X6WW43DBk6CrJ/teHABOiU 6EVRi1FHZACAqPwt9OJ0b/n6Yhzuiz5YdNCK9uQ3qxsr3jakXqV/hchiEnvrESGH4kzS PLIw==
X-Gm-Message-State: APjAAAXRYshW12b8T0GX3ZMBRwVPcK0qNQOTd0eg8K91Joki3PpGAfIt DNHq2GBBNOXAz8Qb2Sm+8qjM1skgvQqMOFtem55eo3i5YOft+wmgAh7Ixe00JcAx19ocy5CYNRT dWm/rBMBiV+4xbg==
X-Google-Smtp-Source: APXvYqxE8RB8BsiG7XmP2WzXGA32IROiSXvrpTIZJZRWzYotbnnMr4q1dYkGVhwB2TzLGyoKTWfrxMKsOkhWrXSLO60=
X-Received: by 2002:a2e:9bd2:: with SMTP id w18mr13056837ljj.140.1572291316342; Mon, 28 Oct 2019 12:35:16 -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> <CAGL6epLR6_pG55F1PzZJf2aSd7J51tu9yPyOqLB9a3Qd3ibDDA@mail.gmail.com>
In-Reply-To: <CAGL6epLR6_pG55F1PzZJf2aSd7J51tu9yPyOqLB9a3Qd3ibDDA@mail.gmail.com>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Mon, 28 Oct 2019 13:34:49 -0600
Message-ID: <CA+k3eCTRGFXAVT+gp-jwjpAOPA4vGOwZHGokjH5a=6W+Ui33+Q@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="00000000000064fa9d0595fd9979"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/zBVegdBzGaSVO-pQBfDN8HsHzMU>
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 19:35:20 -0000

When working on the Token Binding TTRP draft I guess I saw the advantage as
being the simplicity or setting, sanitizing, and reading an independent
header that's only conveying the token binding info about the TLS
connection between the "outside" client/browser and the proxy, (which is
the application/service from that client's perspective). That simplicity
comes at the cost of not being able to represent that information about
multiple hops as would be the case extending RFC7239. The simplicity won
the day in that particular tradeoff. I suspect that would be the case with
client cert info too. But that's admittedly just conjecture at this point.
Although it is, as far as I know, inline with the capabilities of the
popular reverse proxies.

On Mon, Oct 28, 2019 at 10:00 AM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>;
wrote:

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

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