Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint
Brian Campbell <bcampbell@pingidentity.com> Mon, 14 January 2019 21:29 UTC
Return-Path: <bcampbell@pingidentity.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 C5D5713134D for <oauth@ietfa.amsl.com>; Mon, 14 Jan 2019 13:29:30 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.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 4eAormEiE6pP for <oauth@ietfa.amsl.com>; Mon, 14 Jan 2019 13:29:27 -0800 (PST)
Received: from mail-it1-x130.google.com (mail-it1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (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 AC1251312FF for <oauth@ietf.org>; Mon, 14 Jan 2019 13:29:26 -0800 (PST)
Received: by mail-it1-x130.google.com with SMTP id z7so1906851iti.0 for <oauth@ietf.org>; Mon, 14 Jan 2019 13:29:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=h8Fz05lJtFlFG6byFjopubDfXYHtXgFULuqISn5jNMU=; b=UyRG9kM5VHK0JOlW9dcVp7chHFqcOGoRfRaVtTr3lZz2t4YXni4hNBcxDAUzrD2XFI 9AP0gQNwZeXfEozUsv6hCo7Z7rpYFm2ysq1cEbQ+LoX4awyulv+/HYHuONZS3f3+tnaz w6XPylbK/ivN/rxtEVmwky2U5V9PcLJdWf8oA=
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=h8Fz05lJtFlFG6byFjopubDfXYHtXgFULuqISn5jNMU=; b=o1H54YagGg0oPMO/6eAPeOdtZm8ygMg5SsL75zbQAuEMT6nvtCviafLXpegtJWY/pD gjxPWMqzryT0dlaYRxn2k/qMjL/SkJoe7XmmNf5Y5UwKGYDG4/h02rgOP8oQGnhr6dUz Hgd8MhkUo46PLES6P0CC1REK5Nls20uDfuHVO+4lvtA9MpBX+QAemAYLX07C1ghfYc7/ QhbfMyTN/dC0oBgbkC00pEN+azZmTMsfCoJu1vTX1cXPQMYKB94eDSMtnkbjtHLIswMT VDgaf11t+Q+PtSw8OFZgLCqBdtnXsPgMGmlH9P2qJnorMsUZpiNsuJqx/DWCDVaf4mMm C9Cw==
X-Gm-Message-State: AJcUukdXmtADuwDLo0LAhZrRvyDLW44eLOGf1cPOTEmJtH5A1QKFolfD kUyFZiqK4JCBxT4Xp1x7YTH+BKXArrrcSgylBS/UgmsZJDDukokIjuFS9FZ6dYqwD3QsEbKEcLv tN04Zdp+jS6jI4g==
X-Google-Smtp-Source: ALg8bN5/XUdpe1KPSq0mBMtWcQNtUYf70cFKHATCWSpv73GQqsEBWMwqWkCS9GdkkEOSYBGhX6YoZEMftzFjqaKZ2bk=
X-Received: by 2002:a05:660c:452:: with SMTP id d18mr744477itl.124.1547501365836; Mon, 14 Jan 2019 13:29:25 -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> <9D007408-3BCC-4165-BCA4-083BD7602E7D@alkaline-solutions.com>
In-Reply-To: <9D007408-3BCC-4165-BCA4-083BD7602E7D@alkaline-solutions.com>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Mon, 14 Jan 2019 14:28:59 -0700
Message-ID: <CA+k3eCQi1sz2bDOMEATpN9ZvXd+VJydQXG03WKuLczG5kz2z+Q@mail.gmail.com>
To: David Waite <david@alkaline-solutions.com>
Cc: Neil Madden <neil.madden@forgerock.com>, oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000336047057f71bd8c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/y3N3mP13WOCt7wAJwPDbZzyS1Rg>
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: Mon, 14 Jan 2019 21:29:31 -0000
Trying to summarize things somewhat here and focus in hopefully towards some decision. There's basically an idea on the table to add an AS metadata parameter to the draft-ietf-oauth-mtls doc that would be a JSON object which contains endpoints that a client doing MTLS would use rather than the regular endpoints. A straw-man example might look like this (with mtls_endpoints being that new parameter). { "issuer":"https://server.example.com", "authorization_endpoint":"https://server.example.com/authz", "token_endpoint":"https://server.example.com/token", "token_endpoint_auth_methods_supported":[ "client_secret_basic","tls_client_auth", "none"], "userinfo_endpoint":"https://server.example.com/userinfo", "revocation_endpoint":"https://server.example.com/revo", "jwks_uri":"https://server.example.com/jwks.json", * "mtls_endpoints":{ "token_endpoint":"https://mtls.example.com/token <https://mtls.example.com/token>", "userinfo_endpoint":"https://mtls <https://server.example.com/token>.example.com/userinfo <http://example.com/userinfo>", "revocation_endpoint":"https://mtls <https://server.example.com/token>.example.com/revo <http://example.com/revo>" }* } The idea behind this is that "regular" clients (those not doing MTLS) will use the regular endpoints. And only the host/port of the endpoints listed in mtls_endpoints will be set up to request TLS client certificates during handshake. Thus any potential impact of the CertificateRequest message being sent in the TLS handshake can be avoided for all the other regular clients that are not going to do MTLS - including and most importantly in-browser javascript clients where there can be less than desirable UI presented to the end-user. The arguments in favor of that seem to be basically that it allows for AS deployments to support MTLS while still allowing for a "not broken" UX for end-users of clients (in-browser javascript clients) that aren't doing MTLS. And that it's not much in terms of adding to the spec and complexity of implementations. The arguments against it seem to be 1) the bad UX isn't really that bad and/or will only happen to a subset of users 2) there are other things that can be done, such as 307ing or renegotiation/post-handshake client auth, to avoid the bad UX. Speaking for myself, I'm kinda torn on it. I will say that, in addition to the folks that have pointed out that renegotiation just isn't possible in some cases, my experience trying to do something like that in the past was not particularly successful or encouraging. That could have been my fault, of course, but still seems a relevant data point. I also have my doubts about the actual difficulty of getting an AS to issue a 307 like response for requests based on the calling client and the likelihood that some/all OAuth client software would handle it appropriately. On Fri, Jan 11, 2019 at 12:32 PM David Waite <david@alkaline-solutions.com> wrote: > > > > On Jan 11, 2019, at 3: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. > > Agreed. There are trade-offs for both. As you say, I don’t know a way to > have say a custom error code or WWW-Authenticate challenge to trigger > renegotiation on the reverse proxy - usually this is just a static, > location-based directive. > > > > >> 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. > > The primary use is to set policy to rely on device level management in > controlled environments like enterprises when available. So an AS may try > to detect a client certificate as an indicator of a managed device, use > that to assume a device with certain device-level authentication, single > user usage, remote wipe, etc. characteristics, and decide that it can > reduce user authentication requirements and/or expose additional scopes. > > On more thought, this is typically done as part of the user agent hitting > the authorization endpoint, as a separate native application may be > interacting with the token endpoint, and in some operating systems the > application’s network connections do not utilize (and may not have access > to) the system certificate store. > > In terms of user agents, I believe you can perform similar behavior > (managed systems using client certificates on user agents transparently) on > macOS, Windows, Chrome, and Android devices, Chrome (outside iOS) typically > inherits device level policy. Firefox on desktop I assume you can do that > in limited fashion as well. > > -DW -- _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you._
- [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