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

Neil Madden <neil.madden@forgerock.com> Thu, 31 October 2019 20:16 UTC

Return-Path: <neil.madden@forgerock.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 AFEAF120255 for <oauth@ietfa.amsl.com>; Thu, 31 Oct 2019 13:16:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 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, MIME_QP_LONG_LINE=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 (1024-bit key) header.d=forgerock.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 8q1kE5e-ktIs for <oauth@ietfa.amsl.com>; Thu, 31 Oct 2019 13:16:43 -0700 (PDT)
Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [IPv6:2a00:1450:4864:20::32a]) (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 CCF6112022C for <oauth@ietf.org>; Thu, 31 Oct 2019 13:16:42 -0700 (PDT)
Received: by mail-wm1-x32a.google.com with SMTP id p21so7314536wmg.2 for <oauth@ietf.org>; Thu, 31 Oct 2019 13:16:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=Mxxe9b7GXhVZ5GL8mKfpLoIDLyfUoub34jS1HQ6utis=; b=DpCIgA0p5ZRtoA18nH7CG2eyjvET2EPNR7lYupocuSq403ka5CaybzkZXd7875F83y A35zn2i07xVbLDwEGio3Owu+jlIzceIQ3GPJl36HYkg3F06TmMTPEdmTokmW1dMaqPTA Ef7YqeMAsAmkQskRsbZ06YpRUvePtawQ8ok4g=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=Mxxe9b7GXhVZ5GL8mKfpLoIDLyfUoub34jS1HQ6utis=; b=Yyesjb8e3mFfdPz9pcAjyRgy3SYnmvnHYN/xEvpaI9UUbNz6I3XwcdQIa/m5bKCpiu fUQUMTz7f4aM+xc9ED8WkKN2ljAFqcmGGix7lhc9E2IIw9dwuEpreRNyd9DUHDiWqkeJ bcIc5n0UT4XA24g4nP4zi1sVsaTC9+SofWZthpZS76BJ47ES+cUAcTKyPcW169HnTEYw KWlHsIP94s2nBr/WEp00GPK8Mi54QFgKHSXoZiu21z8ItiOD0oM3vtlz+USxzVkpy6Nl 3PseCpMT1X9PlAdhbeXkpUJpY7fYBcv6S2fBERNpjJLD82Uxedia4fITj3020yD4AFnp zwRA==
X-Gm-Message-State: APjAAAUy0p+xZNvn9nuqHMOLMf5EcdYpQsm7hKi++x7XSX2EZi/xUTC2 qHSb3454eyOoIr1i52/hZ/JI+g==
X-Google-Smtp-Source: APXvYqyF1cfbHVlrGrn87F9e8qf5Ux6TzfoIGKd2ukguAbGIPpn8Nysbc6c86enC3ZQsAEaNxxSjxQ==
X-Received: by 2002:a1c:544e:: with SMTP id p14mr6696996wmi.17.1572553001123; Thu, 31 Oct 2019 13:16:41 -0700 (PDT)
Received: from ?IPv6:2a01:4c8:f:b76f:8df3:da5f:6b92:be99? ([2a01:4c8:f:b76f:8df3:da5f:6b92:be99]) by smtp.gmail.com with ESMTPSA id x7sm7941620wrg.63.2019.10.31.13.16.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 31 Oct 2019 13:16:40 -0700 (PDT)
Content-Type: multipart/alternative; boundary=Apple-Mail-2AEC8239-D615-4BC0-B7E5-97B29305D9DA
Content-Transfer-Encoding: 7bit
From: Neil Madden <neil.madden@forgerock.com>
Mime-Version: 1.0 (1.0)
Date: Thu, 31 Oct 2019 20:16:39 +0000
Message-Id: <01E27CED-383F-4E5A-B092-4D176A217C6C@forgerock.com>
References: <E70795A4-5BC7-4450-A1B4-FFC3D332F1DC@amazon.com>
Cc: "oauth@ietf.org" <oauth@ietf.org>
In-Reply-To: <E70795A4-5BC7-4450-A1B4-FFC3D332F1DC@amazon.com>
To: "Richard Backman, Annabelle" <richanna=40amazon.com@dmarc.ietf.org>
X-Mailer: iPhone Mail (17A878)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/hYiDLI5NyHNmwwDhuk0-2AUv6cA>
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 20:16:47 -0000

On 31 Oct 2019, at 18:55, Richard Backman, Annabelle <richanna=40amazon.com@dmarc.ietf.org>; 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.

Just like any other bearer token. I mean this is the *OAuth* WG, right? Where we regularly recommend people send bearer tokens in headers? I don’t really understand how that can be considered secure to send over the internet to a cloud service, but suddenly becomes insecure when done inside the firewall within a datacenter between a reverse proxy and an app server. 

I mean, are people honestly suggesting that randomizing header names introduces *new* vulnerabilities that aren’t present when you use a well-known name? “Dangerous” even! 

> Including it as a signed header in request signing algorithms that require an explicit list of signed headers (such as AWS Signature Version 4, draft-cavage-http-signatures, 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.

I agree that HMAC signatures are generally better, but which reverse proxies support signing headers?

Actually HMAC signatures do have one significant downside compared to using a random header name - if you forget to validate the signature *nothing fails*. If you mess up the name of a random header then your app doesn’t see any credentials and fails noisily. 

— Neil