Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwt-introspection-response-08.txt

Benjamin Kaduk <kaduk@mit.edu> Mon, 21 October 2019 02:05 UTC

Return-Path: <kaduk@mit.edu>
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 0D16E120074 for <oauth@ietfa.amsl.com>; Sun, 20 Oct 2019 19:05:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 h9Q0A38U1INq for <oauth@ietfa.amsl.com>; Sun, 20 Oct 2019 19:05:53 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77E0312006B for <oauth@ietf.org>; Sun, 20 Oct 2019 19:05:53 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x9L25kug013137 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 20 Oct 2019 22:05:49 -0400
Date: Sun, 20 Oct 2019 19:05:46 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: Travis Spencer <travis.spencer@curity.io>
Cc: Torsten Lodderstedt <torsten@lodderstedt.net>, oauth <oauth@ietf.org>
Message-ID: <20191021020546.GZ43312@kduck.mit.edu>
References: <85D42AA1-FF57-4383-BACB-57C5AA32CFAC@lodderstedt.net> <CAEKOcs2gkM3Henz5nS04_EuBQXWWbJU5K02ErP0rnVZXmjxXJQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAEKOcs2gkM3Henz5nS04_EuBQXWWbJU5K02ErP0rnVZXmjxXJQ@mail.gmail.com>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/WtR-VfkfSGHB90i70gDrfMdWau0>
Subject: Re: [OAUTH-WG] 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: Mon, 21 Oct 2019 02:05:55 -0000

Just on one narrow point:

On Wed, Oct 16, 2019 at 04:23:56PM +0200, Travis Spencer wrote:
> On Sun, Oct 6, 2019 at 3:31 PM Torsten Lodderstedt
> > Open: How would one implement sender constrained access tokens in that case? I’m asking since the receiving RS obviously has no access to the information from the TLS handshake since TLS termination happens at the proxy (or even in before the request hits the proxy). The RS would need to get provided with the cert fingerprint via a trustworthy header, i.e. the RS must be aware of the fact it sits behind a proxy.
> 
> This is unfortunately the typical case even with the mTLS draft. This
> is because SSL is almost never terminated by the AS; in my experience,
> TLS termination is instead handled by some very fast proxy.[1] In such
> cases, the proxy will pass the cert through to the AS in some
> undefined HTTP header with some undefined encoding. The mTLS spec
> should have defined this IMO, as it prevents interop for a primary use
> case -- sender constrained tokens.

It's not clear to me that mTLS should have defined a protocol from proxy to
backend; that seems like it could be a fairly generic thing and I know of
several people that are working on similar things, to one degree or
another.  draft-schwartz-tls-lb is the example that I can most easily find
in my archives; though it's working with non-TLS-terminating cases, there
is probably some commonality with TLS-terminating cases as well.

-Ben