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 <[email protected]> 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= > [email protected]> 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 < >> [email protected]> wrote: >> >>> >>> >>> > On Jan 11, 2019, at 3:32 AM, Neil Madden <[email protected]> >>> wrote: >>> > >>> > On 9 Jan 2019, at 05:54, David Waite <[email protected]> >>> wrote: >>> >> >>> >>> On Dec 28, 2018, at 3:55 PM, Brian Campbell <bcampbell= >>> [email protected]> 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth >> > > > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
