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= 40pingidentity....@dmarc.ietf.org> 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 <da...@alkaline-solutions.com> > wrote: > >> >> >> > On Jan 11, 2019, at 3:32 AM, Neil Madden <neil.mad...@forgerock.com> >> wrote: >> > >> > On 9 Jan 2019, at 05:54, David Waite <da...@alkaline-solutions.com> >> wrote: >> >> >> >>> On Dec 28, 2018, at 3:55 PM, Brian Campbell <bcampbell= >> 40pingidentity....@dmarc.ietf.org> 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 > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth