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> Thu, 31 October 2019 11:38 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 A6B07120099 for <oauth@ietfa.amsl.com>; Thu, 31 Oct 2019 04:38:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 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, URIBL_BLOCKED=0.001] autolearn=ham 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 BplJiuKKxyL1 for <oauth@ietfa.amsl.com>; Thu, 31 Oct 2019 04:38:28 -0700 (PDT)
Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) (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 E2126120074 for <oauth@ietf.org>; Thu, 31 Oct 2019 04:38:27 -0700 (PDT)
Received: by mail-qt1-x836.google.com with SMTP id t26so8081610qtr.5 for <oauth@ietf.org>; Thu, 31 Oct 2019 04:38:27 -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=PvHm3gzqS+xhaK7B42AKQhn1w9C1/EReD70liZPY5sw=; b=SBPJXpsCP6Ef/EE4S3dLTp3ZW30ci9+lM7QjQUU27LhSjcte9DuZRBUbJr9oTogM32 VCkYP+fVDyb+oUaZk3FZ2TZn1kbGQVFQcWW/TYNzLJ+5WvMxaxIa+dhbb3D8DnjFMOEB 6Ur11eCmWgsjF/Y6Em0Ub5D+6GDit1sDkpPbR0vAadq9YEhg95reXS9WMMCBMqTW4bc0 hrE2DR+CCGfkOGyEqwIXqR01qCJKtM8dFGK1vH0rzMQNccF7PQeSGtdHGxQ3237MRzM9 nUn06JV8EftRPaxMgksSBdczc9zXnlqjOOfMXDurqtaqDaMSAZIRUUu0Cko/ceeRjqgN 7ymA==
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=PvHm3gzqS+xhaK7B42AKQhn1w9C1/EReD70liZPY5sw=; b=uYJQvs0pdtE9xmkcvUSXeDkjOxwQqrvE3jgIeaNtTV79PUwBxZfaAg4gr7C8rJiIWq CN4BE+oYwaLlDxa9jEDpxY9t3qcT+PWFX5Q7jY7asPxBm0zF3d0ADYc1w6JsXjPAOr5S IUYK92NyZtBc6BzA+CyweK+J3p7pvHvlkHMCpICBdHjJwUc0+243kaoLVIk+2yAxwRBo G2v0njicrukxcSi988s6tpf4vZB8CR06tNJHO3T8/Fg6MDXQSPi/RByU3PhUu78LofkA XTtmLWe80/CY6hQM8D+JWTZYOyHhXA6f6+stEt8xfK7SYr7JvWdI0foDyT/UjtGQbhYo 4PqQ==
X-Gm-Message-State: APjAAAWwAnY/VwHjv0W90mXeqvrYcoaNAoeGGkoES6fNB6jA6OGbVg+3 8w9Dby3csDVeViwh/aE/+KsOwyhoQreNw4hk1yegE2nG1MU=
X-Google-Smtp-Source: APXvYqxv1j/3tR1r/9jO/vRS53pfPad34jDjxkGv8Jsvsrz6fTQ/xA0SakF6Tj08Tu/pUwfRvVByx7Qb4EEQSjgQI7M=
X-Received: by 2002:ac8:4149:: with SMTP id e9mr4834617qtm.321.1572521906766; Thu, 31 Oct 2019 04:38:26 -0700 (PDT)
MIME-Version: 1.0
References: <85D42AA1-FF57-4383-BACB-57C5AA32CFAC@lodderstedt.net> <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> <d2dd4b24-a7d5-5080-4ddc-05e9a742d5d3@connect2id.com> <CA+iA6uiCu8KZM8xpxqxuF4cGR-n53c=w03-h9Ja1rpVsg0goQg@mail.gmail.com> <6535fb8b-89fd-9499-ebf6-e8c6e5542fcc@connect2id.com>
In-Reply-To: <6535fb8b-89fd-9499-ebf6-e8c6e5542fcc@connect2id.com>
From: Hans Zandbelt <hans.zandbelt@zmartzone.eu>
Date: Thu, 31 Oct 2019 12:38:15 +0100
Message-ID: <CA+iA6uhpFb-hn=iG-wR5oU4haRSkSTaawAAQK5TfmT0HkWv3Dg@mail.gmail.com>
To: Vladimir Dzhuvinov <vladimir@connect2id.com>
Cc: "oauth@ietf.org" <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000a79b3a05963349b5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/zojPxFfl2Syg2DTLI8XmOCqd_Dw>
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: Thu, 31 Oct 2019 11:38:31 -0000

+10

On Thu, Oct 31, 2019 at 12:26 PM Vladimir Dzhuvinov <vladimir@connect2id.com>;
wrote:

> This is a good story.
>
> How about requiring reverse proxies to automatically scrub all inbound
> HTTP headers that start with "Sec-"?
>
> If a sec header has the format "Sec-[NAME]-[random-chars]" we get:
>
> * The "Sec-" prefix will  cause new compliant reserve proxies to
> automatically scrub the inbound HTTP header.
>
> * The NAME part still makes the header easily identifiable (I think Rich
> Salz had this concern).
>
> * The random chars part, potentially optional, will provide a line of
> defence against config errors in old legacy reverse proxies.
>
> All concerns should then get covered.
>
> Vladimir
> On 31/10/2019 12:48, Hans Zandbelt wrote:
>
> the way I see this is that stripping and setting the headers must be part
> of the implementation of the protocol itself, it should not be something
> left to a non-atomic piece of configuration by an administrator; I
> implemented it like this in the Apache implementation of Brian's TTRP spec
> [1] and have been doing this for the OIDC and OAuth Apache modules that set
> headers for backends to consume [2]; and yes, I have made mistakes [3], but
> IMHO it should not be a problem to use a well known header and make the
> implementer (not the admin) get it right by pointing this out in the spec,
> as is done for many other pitfalls
>
> Hans.
>
> [1]
> https://github.com/zmartzone/mod_token_binding/blob/master/src/mod_token_binding.c#L481-L483
> [2]
> https://github.com/zmartzone/mod_auth_openidc/blob/master/src/mod_auth_openidc.c#L164-L175
> [3] https://www.cvedetails.com/cve/CVE-2017-6413/
>
> On Thu, Oct 31, 2019 at 11:37 AM Vladimir Dzhuvinov <
> vladimir@connect2id.com>; wrote:
>
>> 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
>>
>> -1 for devising a well known header
>>
>> +1 for a simple way to authenticate a reverse proxy with a web server
>>
>> With a well known name, in a attack this will get probed first. The well
>> known header name doesn't guarantee a correct config. And if we have a new
>> standard for sec headers that must be stripped automatically from inbound
>> HTTP requests, we cannot expect that will get implemented in all reverse
>> proxy software overnight.
>>
>> Because a correct config is not practical as the only line of defense,
>> when we implemented mTLS we decided to add a length (>= 32 chars) and
>> randomness check to the header config. I saw some concerns that this may
>> cause deployment issues. Nobody has complained about that so far.
>>
>>
>> https://connect2id.com/products/server/docs/config/core#op-tls-clientX509CertHeader
>>
>> Regarding mistyping, this can be an issue, but has little to no effect if
>> a long random header gets misstyped (from the inbound strip directive).
>> With a well known header this will result in a immediate security hole,
>> which can theoretically go unnoticed.
>>
>> Here is an example Apache httpd config, to illustrate my point:
>>
>> RequestHeader set Sec-Client-X509-Cert-liede5vaePeeMiYie0xu2jaudauleing ""
>> RequestHeader set Sec-Client-X509-Cert-liede5vaePeeMiYie0xu2jaudauleing "%{SSL_CLIENT_CERT}s"
>>
>> (the first line strips the inbound headers)
>>
>>
>> Vladimir
>>
>> --
>> Vladimir Dzhuvinov
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
>
> --
> hans.zandbelt@zmartzone.eu
> ZmartZone IAM - www.zmartzone.eu
>
> --
> Vladimir Dzhuvinov
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>


-- 
hans.zandbelt@zmartzone.eu
ZmartZone IAM - www.zmartzone.eu