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
- [OAUTH-WG] I-D Action: draft-ietf-oauth-jwt-intro… internet-drafts
- Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwt-i… Vladimir Dzhuvinov
- Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwt-i… Torsten Lodderstedt
- Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwt-i… Travis Spencer
- Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwt-i… Benjamin Kaduk
- Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwt-i… Travis Spencer
- Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwt-i… Justin Richer
- Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwt-i… Torsten Lodderstedt
- Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwt-i… Travis Spencer
- Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwt-i… Benjamin Kaduk
- Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwt-i… Brian Campbell
- Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwt-i… Justin Richer
- Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwt-i… Benjamin Kaduk
- Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwt-i… Rifaat Shekh-Yusef
- [OAUTH-WG] client certs and TLS Terminating Rever… Brian Campbell
- Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwt-i… Benjamin Kaduk
- Re: [OAUTH-WG] client certs and TLS Terminating R… Rifaat Shekh-Yusef
- Re: [OAUTH-WG] client certs and TLS Terminating R… Brian Campbell
- Re: [OAUTH-WG] client certs and TLS Terminating R… Rifaat Shekh-Yusef
- Re: [OAUTH-WG] client certs and TLS Terminating R… Brian Campbell
- Re: [OAUTH-WG] client certs and TLS Terminating R… Rifaat Shekh-Yusef
- Re: [OAUTH-WG] client certs and TLS Terminating R… Neil Madden
- Re: [OAUTH-WG] client certs and TLS Terminating R… Salz, Rich
- Re: [OAUTH-WG] client certs and TLS Terminating R… Rifaat Shekh-Yusef
- Re: [OAUTH-WG] client certs and TLS Terminating R… Salz, Rich
- Re: [OAUTH-WG] client certs and TLS Terminating R… Brian Campbell
- Re: [OAUTH-WG] client certs and TLS Terminating R… Rifaat Shekh-Yusef
- Re: [OAUTH-WG] client certs and TLS Terminating R… Salz, Rich
- Re: [OAUTH-WG] client certs and TLS Terminating R… Justin Richer
- Re: [OAUTH-WG] client certs and TLS Terminating R… Brian Campbell
- Re: [OAUTH-WG] client certs and TLS Terminating R… Hans Zandbelt
- Re: [OAUTH-WG] client certs and TLS Terminating R… Neil Madden
- Re: [OAUTH-WG] client certs and TLS Terminating R… Justin Richer
- Re: [OAUTH-WG] client certs and TLS Terminating R… Torsten Lodderstedt
- Re: [OAUTH-WG] client certs and TLS Terminating R… Neil Madden
- Re: [OAUTH-WG] client certs and TLS Terminating R… Torsten Lodderstedt
- Re: [OAUTH-WG] client certs and TLS Terminating R… Salz, Rich
- Re: [OAUTH-WG] client certs and TLS Terminating R… Neil Madden
- Re: [OAUTH-WG] client certs and TLS Terminating R… Salz, Rich
- Re: [OAUTH-WG] client certs and TLS Terminating R… Neil Madden
- Re: [OAUTH-WG] client certs and TLS Terminating R… Salz, Rich
- Re: [OAUTH-WG] client certs and TLS Terminating R… Neil Madden
- Re: [OAUTH-WG] client certs and TLS Terminating R… Salz, Rich
- Re: [OAUTH-WG] client certs and TLS Terminating R… Neil Madden
- Re: [OAUTH-WG] client certs and TLS Terminating R… Salz, Rich
- Re: [OAUTH-WG] client certs and TLS Terminating R… Jim Manico
- Re: [OAUTH-WG] client certs and TLS Terminating R… Vladimir Dzhuvinov
- Re: [OAUTH-WG] client certs and TLS Terminating R… Hans Zandbelt
- Re: [OAUTH-WG] client certs and TLS Terminating R… Torsten Lodderstedt
- Re: [OAUTH-WG] client certs and TLS Terminating R… Vladimir Dzhuvinov
- Re: [OAUTH-WG] client certs and TLS Terminating R… Hans Zandbelt
- Re: [OAUTH-WG] client certs and TLS Terminating R… Salz, Rich
- Re: [OAUTH-WG] client certs and TLS Terminating R… Vladimir Dzhuvinov
- Re: [OAUTH-WG] client certs and TLS Terminating R… Richard Backman, Annabelle
- Re: [OAUTH-WG] client certs and TLS Terminating R… Salz, Rich
- Re: [OAUTH-WG] client certs and TLS Terminating R… Neil Madden
- Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: client cer… Richard Backman, Annabelle
- Re: [OAUTH-WG] client certs and TLS Terminating R… Vladimir Dzhuvinov
- Re: [OAUTH-WG] client certs and TLS Terminating R… Richard Backman, Annabelle
- Re: [OAUTH-WG] client certs and TLS Terminating R… Hans Zandbelt
- Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: client cer… Neil Madden
- Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwt-i… Travis Spencer
- Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwt-i… Brian Campbell