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

Hans Zandbelt <hans.zandbelt@zmartzone.eu> Wed, 30 October 2019 00:52 UTC

Return-Path: <hans.zandbelt@zmartzone.eu>
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 CE080120052 for <oauth@ietfa.amsl.com>; Tue, 29 Oct 2019 17:52:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.888
X-Spam-Level:
X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=zmartzone-eu.20150623.gappssmtp.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 u9s0OyMMPOMs for <oauth@ietfa.amsl.com>; Tue, 29 Oct 2019 17:52:42 -0700 (PDT)
Received: from mail-qt1-x843.google.com (mail-qt1-x843.google.com [IPv6:2607:f8b0:4864:20::843]) (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 70F7B12009E for <oauth@ietf.org>; Tue, 29 Oct 2019 17:52:42 -0700 (PDT)
Received: by mail-qt1-x843.google.com with SMTP id l3so928361qtp.2 for <oauth@ietf.org>; Tue, 29 Oct 2019 17:52:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zmartzone-eu.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PP2XVRVhxjMxJUVeGmFg6P5VZyGo8bXWjGu6Bixt9Lc=; b=jdRcycxIUGQZDXBsH2Pi9fNt4JbMkRTuogeKCJqtp6eSlmBazSy39NCDBYNbjOQO/K s5XlDVm940fH5spPcPeH5oVcIC83ZO1MJCTRzoegN7dGXYIqcGPPzVf5j2x5P1F5yNPw HQ+YVKxFeFmZY67sAKVefaGI9yhadlcd4S5qBafHqMAr//GryIZd1vKl+g6toakhtCfa jmyMcwxYETkmkeuz99YnwjDrsraxQPaODsuyO7DxmANNZ4qXOUP374J0/rxWzLQ9uzeD g6D99uSLX0K9TtnK9uczHLyw+8Cvak/kaafKuz5xWmyr3abshIOMtFNMbkbetiCcFrVA iozg==
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=PP2XVRVhxjMxJUVeGmFg6P5VZyGo8bXWjGu6Bixt9Lc=; b=hBXfPAHZY0E2enIwZ+jBIGKf2PJo5HqJG4omq1QYPSkFju1IwjGV2ffd/ISZGCAUgv 7cA1Mn7MkLYhco2QqA5SJ2DguJ5wIDkzHHJGT56JraPdxI+N4nJjzOdweFeRuu5uOfum O17daegSxXWwEslFS/eiSgjS3UGnDgpGEHmUm0IOwWMFs38RcTZh+sEfXx76RlJTnXvR sYWFonkObRyoouYDt/W9xvJLNxMjVAM9UdUTUUJcd9ROfxtjqyO+pg1YZ8NslVD0mOOp vxEZwA4LISbANuOK/K8dUWq8BGdwZQ1oieHbsVV57TK0XWyk1+YQLaQineW1ZYuKUed/ tUrQ==
X-Gm-Message-State: APjAAAUFFf6f2q+oMWULC0lCEMYCLMDSzo6f5Zupg8GQC6Rxfp/3uins r0nRxVoPkkzDnpyXnDFcQGV7rYzeg0sKj69Lq6uavw==
X-Google-Smtp-Source: APXvYqxs/l8ObXGAaK1ttNNp0WmKP9q35SgXc/TJcVf8PgMeh2POk/VcYjHn3QKL2DERNah4xLxmqugkWiTjOcaRT6o=
X-Received: by 2002:ac8:4149:: with SMTP id e9mr2258210qtm.321.1572396760359; Tue, 29 Oct 2019 17:52:40 -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> <E03CD445-39E8-4262-97BE-E0EE11231A63@forgerock.com> <2B2ACEE8-7B48-4E2D-94DA-AF3DA86DE809@mit.edu> <CA+k3eCRmmZJQjk-WGmpYZeyTvQR0SttRUZeh7FDT-=ikzOUwAA@mail.gmail.com>
In-Reply-To: <CA+k3eCRmmZJQjk-WGmpYZeyTvQR0SttRUZeh7FDT-=ikzOUwAA@mail.gmail.com>
From: Hans Zandbelt <hans.zandbelt@zmartzone.eu>
Date: Wed, 30 Oct 2019 01:52:29 +0100
Message-ID: <CA+iA6uj64yxsvpeb=+9mLp0BnnfD1nTfFN2GzR+4aAK-06gcYA@mail.gmail.com>
To: Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org>
Cc: Justin Richer <jricher@mit.edu>, oauth@ietf.org
Content-Type: multipart/alternative; boundary="00000000000058fc9505961626b1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/hUTTkqc_2F_hFqa7EGEBgmfLoJ8>
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: Wed, 30 Oct 2019 00:52:45 -0000

+1 to Justin's and Brian's comments, I am interested to contribute and I
will try and be there in person as well

Hans.

On Tue, Oct 29, 2019, 22:56 Brian Campbell <bcampbell=
40pingidentity.com@dmarc.ietf.org>; wrote:

> +1 to pretty much everything Justin said there.
>
> With some facilitating assistance from Ben it looks like there's now an
> agenda slot for this in the upcoming secdispatch meeting in Singapore. I'll
> attempt to articulate the situation and see if there's interest in finding
> a home for the perspective work. Folks that'll be in Singapore and
> interested in the topic would be encouraged to attend to the secdispatch
> meeting during the Afternoon Session III 1710-1840 on Tuesday.
>
>
> On Tue, Oct 29, 2019 at 1:13 PM Justin Richer <jricher@mit.edu>; wrote:
>
>> I would argue that making this standard would actually increase the
>> likelihood of developers getting this right, as now instead of following
>> some copy-pasted recipe for NGINX or Apache that they found on the web,
>> they could turn on a standard setting that would take care of both
>> stripping out incoming headers and injecting the appropriate values. And
>> all of that can be covered in the security considerations with a bunch of
>> normative text on top to make sure inbound headers are stripped. What
>> you’re describing below is clever, but ultimately it’s just a small bit of
>> obscurity more than anything real.
>>
>> The way things are today, you’ve got to not only pick a header and figure
>> out its format, but also do the injection protection step yourself. Since
>> all of these are disconnected, there are a lot more places that it could
>> fall over. Even a typo where you throw out incoming “CLIENT_CERT” but
>> inject “CLIENT_CERTS” or something like that would be disastrous.
>>
>> All in all, I am in favor of this being defined in one standard way, in
>> addition to secure communication between proxies and backends being
>> standardized — but this latter bit really seems like a separate problem.
>>
>>  — Justin
>>
>> On Oct 28, 2019, at 12:32 PM, Neil Madden <neil.madden@forgerock.com>;
>> wrote:
>>
>> While there are some benefits to standardizing headers for this kind of
>> communication, there are some significant downsides - particularly when
>> using headers to communicate critical security information like certs. It
>> is *very* easy to misconfigure a reverse proxy to not strip Forwarded (or
>> whatever) headers from incoming requests, allowing a client to simply
>> supply a certificate as a header without authenticating the TLS connection
>> with the corresponding private key. One good practice to prevent this is to
>> pick a random and unguessable header name (configurable per installation)
>> to be used for communicating the certificate, rather than using something
>> fixed and standard. That way even if you misconfigure the proxy an attacker
>> still has to try and guess the correct header name.
>>
>> I suppose the same thing could be accomplished by having an extension for
>> including a shared secret (or HMAC tag) in the header to authenticate it.
>>
>> -- Neil
>>
>> On 28 Oct 2019, at 15:32, Brian Campbell <
>> bcampbell=40pingidentity.com@dmarc.ietf.org>; 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.*_______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>> _______________________________________________
>> 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.*_______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>