Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint
Brian Campbell <bcampbell@pingidentity.com> Fri, 28 December 2018 22:55 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 6D6A4130ED4 for <oauth@ietfa.amsl.com>; Fri, 28 Dec 2018 14:55:49 -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 IDPlkrDo4Djo for <oauth@ietfa.amsl.com>; Fri, 28 Dec 2018 14:55:46 -0800 (PST)
Received: from mail-it1-x135.google.com (mail-it1-x135.google.com [IPv6:2607:f8b0:4864:20::135]) (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 DCC8F1311D8 for <oauth@ietf.org>; Fri, 28 Dec 2018 14:55:42 -0800 (PST)
Received: by mail-it1-x135.google.com with SMTP id h65so28538163ith.3 for <oauth@ietf.org>; Fri, 28 Dec 2018 14:55:42 -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=tVSQBcXycz/r3XsWWDIX+CAHwZxLEovkns0gxyFB6Xg=; b=M/J2LfeOXbC4yaQExYwYsfLp5xLtNKxlPzr6248xtc2+elLH8iJ8a1WPe+KGLERCZg JSJ9MODod67PLZl5yOrFn2HwJSfzwjB8jVGcKXd+lo1NK6kIe6/6cMqWMrI8rRv/PH6M RszV/IJzrljYaNXDdsIULbyUeFsoSBiwT2rdw=
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=tVSQBcXycz/r3XsWWDIX+CAHwZxLEovkns0gxyFB6Xg=; b=sZSCd6glBe/Mf3P0VIy79uNCCrYDk8k63zkNvMw/w0aA+wm0Us6kzbkElTFiyadhkw GOiZf7fkz3ddhmmS/Gsj9g8fQa8fkEmiP5vfRnK/GU7BKFV8X6YkxxRv4WFGCSH8QSzU VQwXG+yUER4+0niZXEpQQF9L22BktgOhGLTS9Du7HZAncWGEJDVmlQV6lXqrnBxj71yY dqs1TcrLpV+bmWYJ8S0xxb86Ox/4MnqukTlnnYFYqI3jcLgBryCB2z2sxIQfb7Zj4DSq jSLrRigRWz0obUYfLts+9NV79VKOPF9gzHnnVUITVPX+gWV+qbdasTJL0e9n7F1+KsUA +dzg==
X-Gm-Message-State: AJcUukds3LNgN3j+9QBpXPY+e7VFeS9PjuQT/5UtOrTdbqWSpt9qmRjO AJFb79dcayrpnqcp1mJg1qTbm4Uw7/AGfGq2JrFG+9PGxjXYJavXt9XtlOogLcfNcyY5XSQdlyU +brKZXUG4pxvmTQ==
X-Google-Smtp-Source: ALg8bN5T3SCnljJWakzFX6N3QnNbL5U4QqvACUe2pvyxT0m/Pe48aa6fNUXAbyeDPyvnq+Im5HJvmOTWYc6SkpryLSI=
X-Received: by 2002:a24:8ac7:: with SMTP id v190mr18791734itd.174.1546037741976; Fri, 28 Dec 2018 14:55:41 -0800 (PST)
MIME-Version: 1.0
References: <CA+k3eCTKSFiiTw8--qBS0R2YVQ0MY0eKrMBvBNE4pauSr1rHcA@mail.gmail.com> <6A614742-290D-47E2-B3E9-A4D49DB32DD7@forgerock.com>
In-Reply-To: <6A614742-290D-47E2-B3E9-A4D49DB32DD7@forgerock.com>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Fri, 28 Dec 2018 15:55:15 -0700
Message-ID: <CA+k3eCSoNRGrsxeLYd6DEqU+U6TB_aXV2aPUa07Um2X0ZH_ZEw@mail.gmail.com>
To: Neil Madden <neil.madden@forgerock.com>
Cc: oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000006b972a057e1cf6af"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/mATipcsdGSZ6m2WP9jZr6xEJiC0>
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, 28 Dec 2018 22:55:50 -0000
I spent some time this holiday season futzing around with a few different browsers to see what kind of UI, if any, they present to the user when seeing different variations of the server requesting a client certificate during the handshake. In a non-exhaustive and unscientific look at the browsers I had easily at my disposal (FF, Chrome, and Safari on Mac OS), it seems they all behave basically the same. If the browser is configured with, or has access to, one or more client certificates that match the criteria of the CertificateRequest message from the server (basically if issued by one of the CAs in the certificate_authorities of the CertificateRequest), a certificate selection UI prompt will be presented to the user. Otherwise, a certificate selection UI prompt is not presented all. When the CertificateRequest message has an empty certificate_authorities list (likely the case with a optional_no_ca type config), the browsers look for client certificates with any issuer rather than narrowing it down. The observed behavior of the browsers surveyed seems logical and rather reasonable (and better than the last time I futzed with it). Importantly it means that for the situation described in the email that started this thread (a javascript client making a fetch/XHR request to an MTLS token endpoint), users using browsers that are not configured with, or have access to, any client keys/certs will not see any UI prompt at all. I suspect that not having client certs set up is the situation for the vast majority of users and their browsers. And for those that do have client certs set up, I think they are more likely to be the kind of user that is able to deal with the UI prompt okay. 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. On Fri, Dec 28, 2018 at 10:50 AM Neil Madden <neil.madden@forgerock.com> wrote: > On the assumption that this is likely to be a requirement from customers, > I’d be in favour of a new server metadata field. My favourite bikeshed > colour would be: > > tls_client_auth_token_endpoint > > On another metadata-related note, given that the additional security of > certificate-bound access tokens vanishes if the resource server doesn’t > understand and enforce the certificate-binding associated with the access > token, is there a general need for a client to be able to discover if any > given RS does actually support this? Otherwise the whole scheme “fails > open” in that the access token silently degrades to a normal bearer token. > Or do we consider it unlikely that an RS is going to accept a TLS client > certificate without supporting this? > > — Neil > > > On 17 Dec 2018, at 20:26, Brian Campbell <bcampbell= > 40pingidentity.com@dmarc.ietf.org> wrote: > > > > While there's been some disagreement about the specific wording etc., > there does seem to be general consensus coming out of this WG to, in one > form or another, recommend against the use of the implicit grant in favor > of authorization code. In order to follow that recommendation, in-browser > JavaScript clients will need to use XHR/fetch (and likely CORS) to make > requests directly to the token endpoint. > > > > Meanwhile there is the MTLS document utilizes TLS client certificates at > the token endpoint for client authentication and/or certificate bound > access tokens. The security BCP draft even recommends sender/key > constrained access tokens and MTLS is close to the only viable way to do > that at this time. > > > > Unfortunately, however, these two things don't play very nice together. > When a browser makes a TLS connection where a client cert is requested by > the server in the handshake, even when client certificates are optional and > even when it's fetch/XHR, most/many/all browsers will throw up some kind of > certificate selection interface to the user. Which is typically a very > very bad user experience. From a practical standpoint, this means that a > single deployment cannot really support the MTLS draft and have in-browser > JavaScript clients using authorization code at the same time. > > > > In order to address the conflict here, I'd propose that the MTLS draft > introduce a new optional AS metadata parameter that is an MTLS enabled > token endpoint alias. Clients that are doing MTLS client authentication > and/or certificate bound access tokens would/should/must use the > alternative token endpoint when present in the AS's metadata. While all > other clients continue to use the standard token endpoint as they always > have. This would allow for an AS to deploy an alternative token endpoint > alias on a distinct host or port where it will request client certs in the > TLS handshake for OAuth clients that use it while keeping the regular token > endpoint as it normally is for other clients, especially in-browser > JavaScript clients. > > > > Thoughts, objections, agreements, etc., on this proposal? > > > > PS Bikeshedding on a name for the metadata parameter is also welcome. > Some ideas to start: > > token_endpoint_mtls_alias > > token_endpoint_mtls > > mtls_token_endpoint_alias > > mtls_token_endpoint > > alt_token_endpoint_mtls > > mtls_token_endpoint_alt > > > a_token_endpoint_that_a_client_wanting_to_do_mtls_stuff_a_la_RFC_[TBD]_should_use > > equally_poor_idea_here > > > > > > > > > > > > > > > > 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 mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > -- _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