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

[Filip Skokan <[e-mail]>]

>
> In this example, the custom certificates one has to install on their
> system are additional root CAs, right?


Correct,* in this example.*


> From my observations that has no bearing on the prompting behavior of the
> browsers (and shouldn't). What dictates the behavior is whether the browser
> is configured with, or has access to, one or more certificate with the
> associated private key that could be used as client TLS certificates.


*with the associated private key* - hmm, does that explain my observation
then (tested on OS X Chrome and FF) the result was that supporting both
self-signed and PKI client auth method on the token (+introspection,
revocation) endpoints and support for cert bound access tokens on the
userinfo_endpoint for non-browser based clients while not prompting on
token, userinfo or revocation calls made from the browser.

This was my nginx server block
https://gist.github.com/panva/bb153c974cfd65fb0bc9ebb89ca0a3eb

Is that a valid setup? I honestly don't know, it seemed to fit the bill for
this particular AS configuration. But without the option to discover mtls
specific endpoints it's seems to be the only one usable for an AS that also
has browser-based clients, one couldn't use `on` or `optional`
configuration - are we in the position to restrict the possible
configuration to just one? nah.

If we consider having an `mtls_endpoints` or similar object in discovery
then this whole problem and potential broken UX goes away, or rather, will
only come up for browser based clients on e.g. provisioned hardware that
access sites like company's intranet etc. and is developed with using those
certs and therefore directly accessing the mtls_endpoints discovery
namespace.
The logic is also rather simple for a regular backend client
implementation, if there's a client cert, look for that object's endpoint
(and fallback to the usual if missing). If the client doesn't support
sending mtls client certs, it will continue using the regular endpoints.
The use of `mtls_endpoints` is optional but when used guarantees that
browser based clients will never have randomly broken UX for some users. I
can only imagine the support cases horror from customer's end-users who
don't know what to do.

It was, afterall, the original intention behind this section of the draft.

The authorization server may also consider hosting the token endpoint, and
other endpoints requiring client authentication, on a separate host name or
port in order to prevent unintended impact on the TLS behavior of its other
endpoints, e.g. the authorization endpoint.


S pozdravem,
*Filip Skokan*


On Tue, Jan 8, 2019 at 2:00 PM Brian Campbell <[e-mail]>
wrote:

> inline below...
>
> On Mon, Jan 7, 2019 at 11:15 AM Filip Skokan <[e-mail]> wrote:
>
>> I think we shouldn't make a sweeping assumption that may potentially harm
>> UX for end-users. Even if for a small percentage. Tho i can say for sure
>> this percentage may also be rather significant depending on the types of
>> services end-users have encountered in the past and made them install certs.
>>
>> For example, in Czech Republic there's an online system for communicating
>> with government agencies, essentially an email-like inbox that you only get
>> when verifying your identity in person on a post office, every company is
>> required to have one for communication e.g. with the tax office and
>> individuals and freelancers are encouraged to have one as well. To finish
>> signing up for this inbox online after you've verified your identity in
>> person, you must install custom certificates on your system otherwise the
>> browser won't let you through the online signup part due to HSTS. I can say
>> with 100% confidence that most folk do not remove these certs from their
>> system, this means they'd fall in the category that gets prompted and are
>> in majority nowhere near the kind of users that are able to deal with the
>> UI prompt when encountered in the wild.
>>
>
> In this example, the custom certificates one has to install on their
> system are additional root CAs, right?  From my observations that has no
> bearing on the prompting behavior of the browsers (and shouldn't). What
> dictates the behavior is whether the browser is configured with, or has
> access to, one or more certificate with the associated private key that
> could be used as client TLS certificates.
>
>
>>
>> I'd like to see a solution that
>>
>>    - works for every endpoint that needs mtls client cert for either
>>    client auth or certificate bound token validation. This isn't only a case
>>    for token endpoint, introspection, revocation, userinfo (RS-like endpoint
>>    that might be checking a cert bound access token) to list a few
>>    - can ensure clients without access to client certificates won't hit
>>    an endpoint configured to request one to avoid the change of having the UX
>>    flow broken, potentially selecting the wrong certificate which the browser
>>    then remembers to use thus failing auth until website data is cleared.
>>
>> Working under the assumption a client software always knows whether it is
>> configured with client certificates or not it would be nice if there was
>> either a defined prefix, suffix or a specific object in the discovery
>> response (with the same endpoint names in it) that a client can rely on to
>> detect if there is an mtls specific url for any discovered endpoint it
>> needs to use when providing client certificates.
>>
>
> Yeah, you are right about other endpoints (I'd been kind of willfully
> ignoring them to be honest) and I think the specific object in the
> discovery response that itself could have any of the same endpoint names in
> it would be the most straight forward way to approach that.
>
>
> Best,
>> *Filip*
>>
>>
>> On Mon, Jan 7, 2019 at 6:22 PM Brian Campbell <bcampbell=
>> [e-mail]> wrote:
>>
>>> I don't honestly know for sure but I suspect that employees of big
>>> corporations will likely have keys/certs on their devices/machines that are
>>> issued by some internal CA and provisioned to them automatically (and in
>>> many cases without the user knowing and/or understanding that they are
>>> there and why). Those users would likely be prompted when TLS handshaking
>>> with a server that presents an empty list of CAs in the
>>> certificate_authorities of the CertificateRequest.
>>>
>>> I dunno. Maybe I was too quick to retract the proposal for the MTLS
>>> supporting secondary token endpoint?
>>>
>>> What do folks (including Ben & Neil) think?
>>>
>>> On Fri, Jan 4, 2019 at 2:55 PM Benjamin Kaduk <[e-mail]> wrote:
>>>
>>>> On Fri, Dec 28, 2018 at 03:55:15PM -0700, Brian Campbell wrote:
>>>> > 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
>>>>
>>>> Is this still true when we limit to the set of users/browsers that are
>>>> employees of big corporations?
>>>>
>>>> -Ben
>>>>
>>>> > 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.
>>>>
>>>
>>> *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
>>> [e-mail]
>>> 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.*