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

[David Waite <[e-mail]>]

> On Jan 11, 2019, at 3:32 AM, Neil Madden <[e-mail]> wrote:
> 
> On 9 Jan 2019, at 05:54, David Waite <[e-mail]> wrote:
>> 
>>> On Dec 28, 2018, at 3:55 PM, Brian Campbell <bcampbell=[e-mail]> 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