Subject: [OAUTH-WG] MTLS and in-browser clients using the token endpoint

From: Brian Campbell <[email-masked]>
Date: Mon, 17 Dec 2018 13:26:58 -0700

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
<https://tools.ietf.org/html/draft-ietf-oauth-mtls-12> 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._

---

From: John Bradley <[email-masked]>
Date: Mon, 17 Dec 2018 13:28:29 -0800

Yes that is a general problem with browsers and MTLS.

A separate token endpoint is probably useful.

I don't really see SPA doing mutual TLS as likely, however once MTLS is 
turned on on the token endpoint for some clients it can mess up other 
browser and non browser clients.

A separate endpoint in discovery is a good idea  they can always both 
point to the same place.

John B.

On 12/17/2018 12:26 PM, Brian Campbell 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.
>
> <https://tools.ietf.org/html/draft-ietf-oauth-mtls-12> 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.
>
> 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.
>
> PS Bikeshedding on a name for the metadata parameter is also welcome. 
> Some ideas to start:
> /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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Neil Madden <[email-masked]>
Date: Mon, 17 Dec 2018 21:52:08 +0000

I am currently running a Tomcat instance that I have configured to support, but not demand, client certificates using the certificateVerification=“optionalNoCA” setting. With this config I am able to authenticate a confidential client using mTLS, and yet connecting to the same server over HTTPS in either Safari or Chrome on Mac does not prompt me for any certificate. I don’t have any client certificates configured in my browser, so does this only happen if you do?

Depending on the deployment scenario, it may also be possible to terminate TLS at a proxy and use a separate proxy for (intranet) mTLS clients vs public clients, but that may not suit every deployment.

— Neil

> On 17 Dec 2018, at 20:26, Brian Campbell <bcampbell=[email-masked]> 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. 
> 
> PS Bikeshedding on a name for the metadata parameter is also welcome. Some ideas to start:
> 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
> [email-masked]

---

From: John Bradley <[email-masked]>
Date: Mon, 17 Dec 2018 14:10:44 -0800

I think that works for those browsers if no certificates are installed 
for the browser.   We should test, but I think if any certificates are 
available to the browser then it will prompt.

John B.

---

From: Filip Skokan <[email-masked]>
Date: Mon, 17 Dec 2018 23:37:00 +0100

Correct. If there are certs installed on the device the browsers are likely going to prompt. 

Having at least one CA configured together with optional_no_ca (even if its a CA noone ever has certs for) additionally omits the prompt for some client configurations. 

Odesláno z iPhonu

17. 12. 2018 v 23:10, John Bradley <[email-masked]>:

> I think that works for those browsers if no certificates are installed for the browser.   We should test, but I think if any certificates are available to the browser then it will prompt.
> 
> John B.
> 
>

---

From: Brian Campbell <[email-masked]>
Date: Tue, 18 Dec 2018 10:26:53 -0700

I claim no particular expertise here and it's admittedly been a long time
since I actually tested the behavior myself.  But in my prior experience
there were browsers that would prompt the user even when there were no
certificates/keys configured for or available to the browser.

On Mon, Dec 17, 2018 at 3:37 PM Filip Skokan <[email-masked]> wrote:

> Having at least one CA configured together with optional_no_ca (even if
> its a CA noone ever has certs for) additionally omits the prompt for some
> client configurations.
>
> Odesláno z iPhonu
>
> >> I am currently running a Tomcat instance that I have configured to
> support, but not demand, client certificates using the
> certificateVerification=“optionalNoCA” setting. With this config I am able
> to authenticate a confidential client using mTLS, and yet connecting to the
> same server over HTTPS in either Safari or Chrome on Mac does not prompt me
> for any certificate. I don’t have any client certificates configured in my
> browser, so does this only happen if you do?
> >>
> >> Depending on the deployment scenario, it may also be possible to
> terminate TLS at a proxy and use a separate proxy for (intranet) mTLS
> clients vs public clients, but that may not suit every deployment.
> >>
> >> — Neil
> >>
> >>> On 17 Dec 2018, at 20:26, Brian Campbell <bcampbell=
> [email-masked]> wrote:
> >>>
> 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
> >>> 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.
> >>>
> 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.
> >>>
> >>> CONFIDENTIALITY NOTICE: This email may contain confidential and
> 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
> >>> [email-masked]

---

From: Neil Madden <[email-masked]>
Date: Fri, 28 Dec 2018 17:50:23 +0000

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

---

From: Brian Campbell <[email-masked]>
Date: Fri, 28 Dec 2018 15:55:15 -0700

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 <[email-masked]>
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:
>
> 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
>
> > Meanwhile there is the MTLS document utilizes TLS client certificates at
> the token endpoint for client authentication and/or certificate bound