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

[Brian Campbell <[e-mail]>]

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._