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

[Filip Skokan <[e-mail]>]

I'm in favour of both 307 and metadata.

   - case 307 - I don't recall ever encountering an http client software
   that wouldn't have an option for following redirects, same for a server
   side frameworks not having the option to do a 307 response with a location
   header.
   - case 307 - Relying purely on a new metadata doesn't help in the
   scenario David put forth earlier about clients not being aware of using
   mtls, a device policy of sorts.
   - case metadata - no second request if the client knows there's an mtls
   endpoint it should use.

Maybe we should specify both as optional for an AS to deploy and a client
to be ready for?

S pozdravem,
*Filip Skokan*


On Tue, Jan 15, 2019 at 10:05 AM Dave Tonge <[e-mail]>
wrote:

> 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
>>
>
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>