Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint
Filip Skokan <panva.ip@gmail.com> Fri, 11 January 2019 11:51 UTC
Return-Path: <panva.ip@gmail.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 C541212E043 for <oauth@ietfa.amsl.com>; Fri, 11 Jan 2019 03:51:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 Jhn4iKnnhFzX for <oauth@ietfa.amsl.com>; Fri, 11 Jan 2019 03:51:04 -0800 (PST)
Received: from mail-oi1-x230.google.com (mail-oi1-x230.google.com [IPv6:2607:f8b0:4864:20::230]) (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 D5A3B129B88 for <oauth@ietf.org>; Fri, 11 Jan 2019 03:51:03 -0800 (PST)
Received: by mail-oi1-x230.google.com with SMTP id v6so11974960oif.2 for <oauth@ietf.org>; Fri, 11 Jan 2019 03:51:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=yc25wqx9FA1hVOpul5rzJ1Ksny03uGp0nfRYCDJRM88=; b=T9w/GIGKZJQi/beEdfFnGAHYbbBAjphsp80L+Bz0pX4oMoCH5UuE8aZ3EhMF+PgofQ LNdTsGKKL1yZ1qn/Fc2XVI3WRGQaOf+b9PPFD7DnjH6TiDFDhd/w3tt7oazf7E9Efgfm rOhHvyz7W8TN3Ki7bZmV7EZyyYwUruTBoang96yI16SCBWfy7+F0dW+MfEKiYK/+7gga yr5ojN8DPkr2vTrp9Wcqgz98HSgMay2agn0T04fFnzMyY8D/WydlqmmW6iTv6VHdS9Bt vKw9E6/ttBFLvm9cWcFZHn/YPoHx0raBUYoi8EVYLlPhfGily6+z8//RX2sFSHiNPWmB SfUg==
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=yc25wqx9FA1hVOpul5rzJ1Ksny03uGp0nfRYCDJRM88=; b=ANohWX73ohdNQBwTRAyFhhTtnb14GDE4O18VLfK+BCJkePu8xW7/qVcmqAZtt0o8Pi I3Q0P046GPi5bIKp39tpdhZwpW+I2eYgwHvQOOOBeRmSqIIlxcvagYRNfyVGOrNebUHG brXLsUeNttYNdtJBLXofnXfXiFhgKz9n9RpFDj5xFfVSiKA+KmvhT62kY2YkjHZ2dqxc iN71bcstiSSSnnKVS56U3zdnZQSpZYl6MexHQKSJ9OrLKbpKsMhnQbqTJoKk8yzxHcD5 J8U1GEotlhaTnVjbUH1yEY9pxGG1WcIpl+8d7HMhtSlxZPNsCAK/qRVdTTsFsIQPh6y0 eR8w==
X-Gm-Message-State: AJcUukezMAST7ma7lF0IY1CbKBFjeyeX2gp0x0VFXAhgIfEVjyN8NaAV ct89jK0fjXvNUNmnXzeofqhH/U3XNA5SR9yVUw==
X-Google-Smtp-Source: ALg8bN7Glm8mbmYbebaFMRluaxBWZZbMWcJBxtVWUFvgTUcyu4c0uK79BN5oge331sgBx0ZS6rSrhomF3/EMuros7WU=
X-Received: by 2002:aca:fdd0:: with SMTP id b199mr8490112oii.178.1547207463064; Fri, 11 Jan 2019 03:51:03 -0800 (PST)
MIME-Version: 1.0
References: <CA+k3eCTKSFiiTw8--qBS0R2YVQ0MY0eKrMBvBNE4pauSr1rHcA@mail.gmail.com> <6A614742-290D-47E2-B3E9-A4D49DB32DD7@forgerock.com> <CA+k3eCSoNRGrsxeLYd6DEqU+U6TB_aXV2aPUa07Um2X0ZH_ZEw@mail.gmail.com> <548FF68E-7775-4FE0-829F-1E9CC6EA8E3F@alkaline-solutions.com> <1119DDAE-8044-43C9-A6D4-6032B3BB62B8@forgerock.com>
In-Reply-To: <1119DDAE-8044-43C9-A6D4-6032B3BB62B8@forgerock.com>
From: Filip Skokan <panva.ip@gmail.com>
Date: Fri, 11 Jan 2019 12:50:51 +0100
Message-ID: <CALAqi_99kgSVZXr6FyE6VkYRQqt_MPq_ZiGqgm+76wryRcUjTg@mail.gmail.com>
To: Neil Madden <neil.madden@forgerock.com>
Cc: David Waite <david@alkaline-solutions.com>, Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org>, oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000003ada66057f2d4fef"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/k3c4O-tC0AjysITmQWx1lwEvFiE>
Subject: Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint
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: Fri, 11 Jan 2019 11:51:07 -0000
307 indeed seems doable, similar to a discovery namespace it requires the client software to be prepared for this and follow the redirect in that case, but in David’s case it doesn’t require the client to “know” it is bound to a device wide policy. The client just assumes it has no form of authentication and only sends the client_id. I’ll try to do a quick PoC for 307 and share any findings i may have. Renegotiation not only isn’t easy to do in some common setups (self managed tls terminating LB or proxy), but in some is outright impossible - e.g. managed services like AWS ALB or API Gateway that may be in use for regular requests and with self-hosted endpoints running nxinx/apache for just mtls requests on the side. Best, *Filip* On Fri, Jan 11, 2019 at 11:32 AM Neil Madden <neil.madden@forgerock.com> wrote: > On 9 Jan 2019, at 05:54, David Waite <david@alkaline-solutions.com> wrote: > > > >> On Dec 28, 2018, at 3:55 PM, Brian Campbell <bcampbell= > 40pingidentity.com@dmarc.ietf.org> wrote: > >> > > <snip> > > > >> All of that is meant as an explanation of sorts to say that I think > that things are actually okay enough as is and that I'd like to retract the > proposal I'd previously made about the MTLS draft introducing a new AS > metadata parameter. It is admittedly interesting (ironic?) that Neil sent a > message in support of the proposal as I was writing this. It did give me > pause but ultimately didn't change my opinion that it's not worth it to add > this new AS metadata parameter. > > > > Note that the AS could make a decision based on the token endpoint > request - such as a policy associated with the “client_id”, or via a > parameter in the ilk of “client_assertion_type” indicating MTLS was desired > by this public client installation. The AS could then to TLS 1.2 > renegotiation, 1.3 post-handshake client authentication, or even use 307 > temporary redirects to another token endpoint to perform mutual > authentication. > > Renegotiation is an intriguing option, but it has some practical > difficulties. Our AS product runs in a Java servlet container, where it is > pretty much impossible to dynamically trigger renegotiation without > accessing private internal APIs of the container. I also don’t know how you > could coordinate this in the common scenario where TLS is terminated at a > load balancer/reverse proxy? > > A 307 redirect could work though as the server will know if the client > either uses mTLS for client authentication or has indicated that it wants > certificate-bound access tokens, so it can redirect to a mTLS-specific > endpoint in those cases. > > > Both the separate metadata url and a “client_assertion_type”-like > indicator imply that the client has multiple forms of authentication and is > choosing to use MTLS. The URL in particular I’m reluctant to add support > for, because I see it more likely a client would use MTLS without knowing > it (via a device-level policy being applied to a public web or native app) > than the reverse, where a single client (represented by a single client_id) > is dynamically picking between forms of authentication. > > That’s an interesting observation. Can you elaborate on the sorts of > device policy you are talking about? I am aware of e.g. mobile device > management being used to push client certificates to iOS devices, but I > think these are only available in Safari. > > — Neil > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >
- [OAUTH-WG] MTLS and in-browser clients using the … Brian Campbell
- Re: [OAUTH-WG] MTLS and in-browser clients using … John Bradley
- Re: [OAUTH-WG] MTLS and in-browser clients using … Neil Madden
- Re: [OAUTH-WG] MTLS and in-browser clients using … John Bradley
- Re: [OAUTH-WG] MTLS and in-browser clients using … Filip Skokan
- Re: [OAUTH-WG] MTLS and in-browser clients using … Brian Campbell
- Re: [OAUTH-WG] MTLS and in-browser clients using … Neil Madden
- Re: [OAUTH-WG] MTLS and in-browser clients using … Brian Campbell
- Re: [OAUTH-WG] MTLS and in-browser clients using … Benjamin Kaduk
- Re: [OAUTH-WG] MTLS and in-browser clients using … Brian Campbell
- Re: [OAUTH-WG] MTLS and in-browser clients using … Filip Skokan
- Re: [OAUTH-WG] MTLS and in-browser clients using … Neil Madden
- Re: [OAUTH-WG] MTLS and in-browser clients using … Brian Campbell
- Re: [OAUTH-WG] MTLS and in-browser clients using … Brian Campbell
- Re: [OAUTH-WG] MTLS and in-browser clients using … Filip Skokan
- Re: [OAUTH-WG] MTLS and in-browser clients using … Benjamin Kaduk
- Re: [OAUTH-WG] MTLS and in-browser clients using … David Waite
- Re: [OAUTH-WG] MTLS and in-browser clients using … David Waite
- Re: [OAUTH-WG] MTLS and in-browser clients using … Neil Madden
- Re: [OAUTH-WG] MTLS and in-browser clients using … Filip Skokan
- Re: [OAUTH-WG] MTLS and in-browser clients using … David Waite
- Re: [OAUTH-WG] MTLS and in-browser clients using … Brian Campbell
- Re: [OAUTH-WG] MTLS and in-browser clients using … Brian Campbell
- Re: [OAUTH-WG] MTLS and in-browser clients using … Benjamin Kaduk
- Re: [OAUTH-WG] MTLS and in-browser clients using … Dave Tonge
- Re: [OAUTH-WG] MTLS and in-browser clients using … Filip Skokan
- Re: [OAUTH-WG] MTLS and in-browser clients using … Brian Campbell
- Re: [OAUTH-WG] MTLS and in-browser clients using … Brian Campbell
- Re: [OAUTH-WG] MTLS and in-browser clients using … Filip Skokan
- Re: [OAUTH-WG] MTLS and in-browser clients using … Brian Campbell
- Re: [OAUTH-WG] MTLS and in-browser clients using … Brian Campbell
- Re: [OAUTH-WG] MTLS and in-browser clients using … Phil Hunt
- Re: [OAUTH-WG] MTLS and in-browser clients using … Brian Campbell
- Re: [OAUTH-WG] MTLS and in-browser clients using … Phil Hunt
- Re: [OAUTH-WG] MTLS and in-browser clients using … Brian Campbell
- Re: [OAUTH-WG] MTLS and in-browser clients using … George Fletcher
- Re: [OAUTH-WG] MTLS and in-browser clients using … Brian Campbell
- Re: [OAUTH-WG] MTLS and in-browser clients using … Phil Hunt
- Re: [OAUTH-WG] MTLS and in-browser clients using … Brian Campbell
- Re: [OAUTH-WG] MTLS and in-browser clients using … Richard Backman, Annabelle
- Re: [OAUTH-WG] MTLS and in-browser clients using … Phil Hunt
- Re: [OAUTH-WG] MTLS and in-browser clients using … Brian Campbell
- Re: [OAUTH-WG] MTLS and in-browser clients using … Brian Campbell
- Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and i… Richard Backman, Annabelle
- Re: [OAUTH-WG] MTLS and in-browser clients using … Phil Hunt
- Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and i… Neil Madden
- Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and i… Brian Campbell
- Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and i… Brian Campbell
- Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and i… David Waite
- Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and i… Justin Richer
- Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and i… Neil Madden
- Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and i… Richard Backman, Annabelle
- Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and i… Filip Skokan
- Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and i… Brian Campbell
- Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and i… Brian Campbell
- Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and i… Brian Campbell
- Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and i… Brian Campbell
- Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and i… Richard Backman, Annabelle
- Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and i… Brian Campbell
- [OAUTH-WG] MTLS token endoint & discovery Dominick Baier
- Re: [OAUTH-WG] MTLS token endoint & discovery Brian Campbell
- Re: [OAUTH-WG] MTLS token endoint & discovery Dominick Baier
- Re: [OAUTH-WG] MTLS token endoint & discovery Justin Richer
- Re: [OAUTH-WG] MTLS token endoint & discovery Brian Campbell
- Re: [OAUTH-WG] MTLS token endoint & discovery Brian Campbell
- Re: [OAUTH-WG] MTLS token endoint & discovery Richard Backman, Annabelle
- Re: [OAUTH-WG] MTLS token endoint & discovery George Fletcher
- Re: [OAUTH-WG] MTLS token endoint & discovery Justin Richer
- Re: [OAUTH-WG] MTLS token endoint & discovery George Fletcher
- Re: [OAUTH-WG] MTLS token endoint & discovery Filip Skokan
- Re: [OAUTH-WG] MTLS token endoint & discovery Richard Backman, Annabelle
- Re: [OAUTH-WG] MTLS token endoint & discovery Filip Skokan
- Re: [OAUTH-WG] MTLS token endoint & discovery Dominick Baier
- Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS token… Richard Backman, Annabelle
- Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS token… Dominick Baier
- Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS token… Phil Hunt
- Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS token… Brian Campbell
- Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS token… Phil Hunt
- Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS token… George Fletcher
- Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS token… Filip Skokan
- Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS token… Phil Hunt
- Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS token… George Fletcher
- Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS token… Filip Skokan
- Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS token… George Fletcher
- Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS token… Neil Madden
- Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS token… David Waite
- Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS token… Richard Backman, Annabelle
- Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS token… Richard Backman, Annabelle
- Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS token… Brian Campbell