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 21:50 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 77A19120847 for <oauth@ietfa.amsl.com>; Thu, 31 Oct 2019 14:50:06 -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=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 SObZ3chrl51N for <oauth@ietfa.amsl.com>; Thu, 31 Oct 2019 14:50:02 -0700 (PDT)
Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [IPv6:2607:f8b0:4864:20::731]) (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 465AA12080E for <oauth@ietf.org>; Thu, 31 Oct 2019 14:50:02 -0700 (PDT)
Received: by mail-qk1-x731.google.com with SMTP id m4so8637560qke.9 for <oauth@ietf.org>; Thu, 31 Oct 2019 14:50:02 -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=sNK+HV5/Wrud1vZbBsW2W6LccbZ0FRImlczlUwxuk+I=; b=zHU9KlLfK37wHS+P2oUkqGrIkdn6c/k3rGQYVpAqjMxVt5IpFpl0v/UQGIHNBEr2gL O6HnNtScaGgrhAvksueOtHAgG4dnpHVY5dg50WnPcCmr5RtCyfFGkzkg8If99q8bYfyE r/dn9Z7bnAK61W/kQ3fW+M7ikllUECNQKzuY5+eoli+bb+ukXuL+O5qjeqvtmBsW8I2C 7BqqyhPmiBZNEpzJXKXCXgAtK3mLyfQdXCw63J5rhU5tvGzGKP0yWuO3lKUQ2AYLMZTf A4Tqe4T9Bxh/RB5MPbZkFiRK3CzZvdDyLEIEFlG9qXeBu7xe3nvFAjA4r35KYi7kmQKe 9PWQ==
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=sNK+HV5/Wrud1vZbBsW2W6LccbZ0FRImlczlUwxuk+I=; b=tSwMpsUU0aop4D9tw0qUgIkfB14qk/9fVvv7BXcMM1oHafhYBlvR2K1oYZAeZZxTDc 9UHj99R8ARZDfvdCmory2rzHW313Ox9he/J5PAD6OH30um0ak3m4NARIhuvTIQSS/UO/ UUOyxcPOnVfN3HEsi1/+JTx2xeZxQCivHsQH5AzxIkj8Qg+DsptctZtLh1tfevr9aPc3 SuDRonbHmKIORuYTBxNwkQn3fgHC4aKCAAWJ1tHKJbjssS8xxNBDM+xAdz3NtMQef4Sc xQIFr8EimKhk5PrQusYiihuvojCqEI3kC/1mCp1xAHCqWmSayKXav5+sF9Dccty0+TFU 9+xA==
X-Gm-Message-State: APjAAAUe5si1Bjbey8cjoI22xuU5K+/nVtrX1/5IVyhAXOZpTdKZugBj Hy9i9uVeYSBa+E0YYagbAQDlCg0NBLsfiqKjzkCU/2Vr
X-Google-Smtp-Source: APXvYqyaWQPM3kaHNqUVkoReBYbrT+jzqlqCoUc6j1VPqUTzJ2mn6gAVnaBrasi53yG2BhivE4VQuE7NfuYCk4nbobc=
X-Received: by 2002:ae9:f80d:: with SMTP id x13mr3337185qkh.63.1572558601090; Thu, 31 Oct 2019 14:50:01 -0700 (PDT)
MIME-Version: 1.0
References: <85D42AA1-FF57-4383-BACB-57C5AA32CFAC@lodderstedt.net> <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> <E70795A4-5BC7-4450-A1B4-FFC3D332F1DC@amazon.com> <1ec7ef38-51f9-ff93-774d-09300736be73@connect2id.com> <D5621F8B-5375-4BD0-B83D-7C2D17BC8D53@amazon.com>
In-Reply-To: <D5621F8B-5375-4BD0-B83D-7C2D17BC8D53@amazon.com>
From: Hans Zandbelt <hans.zandbelt@zmartzone.eu>
Date: Thu, 31 Oct 2019 22:49:49 +0100
Message-ID: <CA+iA6uh0QSYvqAbO=j6X_CbpNhX1i=Wv6sQ9dNsoPbXccycWTQ@mail.gmail.com>
To: "Richard Backman, Annabelle" <richanna=40amazon.com@dmarc.ietf.org>
Cc: Vladimir Dzhuvinov <vladimir@connect2id.com>, "oauth@ietf.org" <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000ce939e05963bd4ed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/PXMjTgonzVjOvi7lhQ2XEvh7P2A>
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 21:50:06 -0000

for me this thread is running a bit wild: if we don't believe that
implementers get incoming header removal right, why do we believe the same
implementers get randomizing and/or HMAC signing right
setting headers on a trusted leg between proxies and origin servers has
been a best practice for decades, regardless of implementation bugs (which
similarly exist in crypto implementations)
catering for non-trusted legs is fine, but don't let it stand in the way of
the obvious

Hans.

On Thu, Oct 31, 2019 at 10:35 PM Richard Backman, Annabelle <richanna=
40amazon.com@dmarc.ietf.org>; wrote:

> I think the HMAC/signature approach is actually easier for cloud vendors
> to implement. The threat model is much simpler to understand, and risk
> mitigation mostly boils down to well-understood cryptographic hygiene
> patterns. And again, it’s obvious what values are secrets and what values
> aren’t.
>
>
>
> –
>
> Annabelle Richard Backman
>
> AWS Identity
>
>
>
>
>
> *From: *OAuth <oauth-bounces@ietf.org>; on behalf of Vladimir Dzhuvinov <
> vladimir@connect2id.com>;
> *Organization: *Connect2id Ltd.
> *Date: *Thursday, October 31, 2019 at 1:50 PM
> *To: *"oauth@ietf.org"; <oauth@ietf.org>;
> *Subject: *Re: [OAUTH-WG] client certs and TLS Terminating Reverse
> Proxies (was Re: I-D Action:
> draft-ietf-oauth-jwt-introspection-response-08.txt)
>
>
>
> I agree wholeheartedly that an HMAC or even signature is preferable. With
> HMAC vs signature having their relative pros / cons, in terms of
> computation and key distribution. If a standard for that is created, and I
> am a web application developer, I'll be able to handle the header checks in
> the application layer code relatively easily. But I have much less control
> over how / where the application is going to be deployed, and if the
> reverse proxy has this header security implemented. Software and cloud
> vendors can sometimes be significantly behind in such developments. Even
> basic handling of self-signed client certificates has been an issue for us
> in popular cloud environments.
>
> With that in mind, the "secret" headers can be configured with most
> currently available reverse proxy software. I see it as a useful
> intermediate step, until a standard for authenticated headers gets agreed
> on and eventually implemented in reverse proxies. Can you comment on that
> from this perspective?
>
> Over the years I have come to the conclusion that standards which can be
> implemented in the application layer or as a simple config stand a better
> chance. Standards which rely on other layers or on broad vendor or
> developer support to become useful run the risk of not getting adopted in
> practice. Token binding suffered from that.
>
> Vladimir
>
> On 31/10/2019 20:55, Richard Backman, Annabelle wrote:
>
> Relying on a fixed, random header name for security, even as a “defense in
> depth” measure, is dangerous. In order for this mechanism to be effective,
> the header name must be random (in the cryptographic sense) and must be
> kept secret. It needs to be withheld from request logs or error logs,
> either on the reverse proxy or on the service. It cannot be committed to
> code repositories. Including it as a signed header in request signing
> algorithms that require an explicit list of signed headers (such as AWS
> Signature Version 4
> <https://docs.aws.amazon.com/general/latest/gr/signature-version-4.html>;,
> draft-cavage-http-signatures
> <https://tools.ietf.org/html/draft-cavage-http-signatures-12>;,
> draft-ietf-oauth-signed-http-request
> <https://tools.ietf.org/html/draft-ietf-oauth-signed-http-request>) turns
> that signature metadata into a secret, meaning that *it* cannot be
> logged, etc. If signatures are sent to a central authority for processing,
> that authority must also know not to log the list of signed headers. I
> could go on, but I hope this is enough to express that there are SO MANY
> ways that header names can and will be revealed, and they aren’t always
> obvious.
>
>
>
> What we are talking about is a message authenticity problem. The best
> practices for providing message authenticity involve applied crypto, e.g.,
> an HMAC or digital signature over the header contents. If an implementation
> does that, then the random header name is unnecessary. This approach is
> immune to the sort of misconfiguration scenarios that have been discussed
> in this thread, as they would result in the reverse proxy failing to
> provide a properly signed header to the service.
>
>
>
> –
>
> Annabelle Richard Backman
>
> AWS Identity
>
>
>
>
>
> *From: *OAuth <oauth-bounces@ietf.org>; <oauth-bounces@ietf.org>; on behalf
> of Vladimir Dzhuvinov <vladimir@connect2id.com>; <vladimir@connect2id.com>;
> *Organization: *Connect2id Ltd.
> *Date: *Thursday, October 31, 2019 at 4:27 AM
> *To: *"oauth@ietf.org"; <oauth@ietf.org>; <oauth@ietf.org>; <oauth@ietf.org>;
> *Subject: *Re: [OAUTH-WG] client certs and TLS Terminating Reverse
> Proxies (was Re: I-D Action:
> draft-ietf-oauth-jwt-introspection-response-08.txt)
>
>
>
> 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
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>


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