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

[Dave Tonge <[e-mail]>]

I'm in favour of the `mtls_endpoints` metadata parameter - although it
should be optional.
While a 307 redirect seems kind of elegant I worry, like you,  that not all
clients would handle it appropriately.
There would probably need to be an error defined for clients who attempt to
use `tls_client_auth` at the regular endpoint.

Dave

On Mon, 14 Jan 2019 at 22:29, Brian Campbell <bcampbell=
[e-mail]> wrote:

> Trying to summarize things somewhat here and focus in hopefully towards
> some decision. There's basically an idea on the table to add an AS metadata
> parameter to the draft-ietf-oauth-mtls doc that would be a JSON object
> which contains endpoints that a client doing MTLS would use rather than the
> regular endpoints. A straw-man example might look like this (with
> mtls_endpoints being that new parameter).
>
> {
>   "issuer":"https://server.example.com",
>   "authorization_endpoint":"https://server.example.com/authz",
>   "token_endpoint":"https://server.example.com/token",
>   "token_endpoint_auth_methods_supported":[
> "client_secret_basic","tls_client_auth", "none"],
>   "userinfo_endpoint":"https://server.example.com/userinfo",
>   "revocation_endpoint":"https://server.example.com/revo",
>   "jwks_uri":"https://server.example.com/jwks.json",
>
>
>
>
> *  "mtls_endpoints":{
> "token_endpoint":"https://mtls.example.com/token
> <https://mtls.example.com/token>",    "userinfo_endpoint":"https://mtls
> <https://server.example.com/token>.example.com/userinfo
> <http://example.com/userinfo>",    "revocation_endpoint":"https://mtls
> <https://server.example.com/token>.example.com/revo
> <http://example.com/revo>"  }*
> }
>
> The idea behind this is that "regular" clients (those not doing MTLS) will
> use the regular endpoints. And only the host/port of the endpoints listed
> in mtls_endpoints will be set up to request TLS client certificates during
> handshake. Thus any potential impact of the CertificateRequest message
> being sent in the TLS handshake can be avoided for all the other regular
> clients that are not going to do MTLS - including and most importantly
> in-browser javascript clients where there can be less than desirable UI
> presented to the end-user.
>
> The arguments in favor of that seem to be basically that it allows for AS
> deployments to support MTLS while still allowing for a "not broken" UX for
> end-users of clients (in-browser javascript clients) that aren't doing
> MTLS. And that it's not much in terms of adding to the spec and complexity
> of implementations.
>
> The arguments against it seem to be 1) the bad UX isn't really that bad
> and/or will only happen to a subset of users 2) there are other things that
> can be done, such as 307ing or renegotiation/post-handshake client auth, to
> avoid the bad UX.
>
> Speaking for myself, I'm kinda torn on it.
>
> I will say that, in addition to the folks that have pointed out that
> renegotiation just isn't possible in some cases, my experience trying to do
> something like that in the past was not particularly successful or
> encouraging. That could have been my fault, of course, but still seems a
> relevant data point. I also have my doubts about the actual difficulty of
> getting an AS to issue a 307 like response for requests based on the
> calling client and the likelihood that some/all OAuth client software would
> handle it appropriately.
>
>
> On Fri, Jan 11, 2019 at 12:32 PM David Waite <[e-mail]>
> wrote:
>
>>
>>
>> > 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
>
>
> *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
>