I was a bit confused by how the 307 would work. To confirm, Is the client having reached an MTLS optional endpoint being redirected to an MTLS mandatory endpoint if the AT (or a cookie) is detected to have a “cnf” claim in order to make the browser invoke MTLS?
Phil Oracle Corporation, Cloud Security and Identity Architect @independentid www.independentid.com <http://www.independentid.com/>phil.h...@oracle.com <mailto:phil.h...@oracle.com> > On Feb 1, 2019, at 11:56 AM, Brian Campbell > <bcampbell=40pingidentity....@dmarc.ietf.org> wrote: > > I'm finally getting around to working on the document updates (there's quite > a few things that came out of AD review too). As far as the issue in this > thread goes though, I'm leaning towards adding "mtls_endpoints" as a new > metadata parameter. Maybe mention that a 307 might happen but it'd be more of > a considerations type text. > > On Wed, Jan 16, 2019 at 5:52 AM Brian Campbell <bcampb...@pingidentity.com > <mailto:bcampb...@pingidentity.com>> wrote: > I guess I should have also said or been more straightforward in saying that I > don't particularly want to try and discuss/define the use of a 307 in the > document. > > On Tue, Jan 15, 2019 at 6:59 AM Filip Skokan <panva...@gmail.com > <mailto:panva...@gmail.com>> wrote: > I don't know that the use of 307 would need to be discussed in the document > itself. > > If the clients are supposed to be ready for this, yeah. For instance, my > client software by default doesn't follow redirects, in order for it to be > ready for mtls client authentication i'd have to know 307 is a possibility > and whitelist 307 as a valid code to be followed. > > S pozdravem, > Filip Skokan > > > On Tue, Jan 15, 2019 at 2:54 PM Brian Campbell <bcampb...@pingidentity.com > <mailto:bcampb...@pingidentity.com>> wrote: > I don't know that the use of 307 would need to be discussed in the document > itself. > > On Tue, Jan 15, 2019 at 2:30 AM Filip Skokan <panva...@gmail.com > <mailto:panva...@gmail.com>> wrote: > 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 <dave.to...@momentumft.co.uk > <mailto:dave.to...@momentumft.co.uk>> 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=40pingidentity....@dmarc.ietf.org > <mailto: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 <https://server.example.com/>", > "authorization_endpoint":"https://server.example.com/authz > <https://server.example.com/authz>", > "token_endpoint":"https://server.example.com/token > <https://server.example.com/token>", > "token_endpoint_auth_methods_supported":[ > "client_secret_basic","tls_client_auth", "none"], > "userinfo_endpoint":"https://server..example.com/userinfo > <https://server.example.com/userinfo>", > "revocation_endpoint":"https://server.example.com/revo > <https://server.example.com/revo>", > "jwks_uri":"https://server.example.com/jwks.json > <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 > <mailto:da...@alkaline-solutions.com>> wrote: > > > > On Jan 11, 2019, at 3:32 AM, Neil Madden <neil.mad...@forgerock.com > > <mailto:neil.mad...@forgerock.com>> wrote: > > > > On 9 Jan 2019, at 05:54, David Waite <da...@alkaline-solutions.com > > <mailto:da...@alkaline-solutions.com>> wrote: > >> > >>> On Dec 28, 2018, at 3:55 PM, Brian Campbell > >>> <bcampbell=40pingidentity....@dmarc.ietf.org > >>> <mailto: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 <mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth > <https://www.ietf.org/mailman/listinfo/oauth> > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org <mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth > <https://www.ietf.org/mailman/listinfo/oauth> > > 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. > > 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
