Brian, Let me turn this around. Is it possible for a single endpoint to have MTLS clients (mutual auth) and bearer clients (server auth TLS)?
I had thought that client certificate authen can be made optional, but I must confess I’m confused as to how optionality works in TLS when it comes to client certificate authentication. If we have to do multiple endpoints for the APIs and/or the token endpoints, we have to send clients to the correct endpoints to make TLS set up correctly. If this is the case, I think Brian is right—we need a parameter. 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 1:43 PM, Brian Campbell <bcampb...@pingidentity.com> wrote: > > I guess I'm not clear what you are driving at. > > On Fri, Feb 1, 2019 at 2:32 PM Phil Hunt <phil.h...@oracle.com > <mailto:phil.h...@oracle.com>> wrote: > That way works. But one of the modes on most tls terminators is client cert > optional. > > This works ok when you want dual mode to support bearer and mtls for apps > (e.g. mobile) because the client will decide to use MTLS. With browsers, > they only use it if forced. > > Phil > > Oracle Corporation, Cloud Security and Identity Architect > @independentid > www.independentid.com > <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.independentid.com&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=zghYuxpPtYeMn2IhNNwG0lo64yhSMZ5ER8oPt3G95oE&s=1K1v6KsnRhJrNtN6LVDS7U_kzRD5xLCy59j-ij-MGNA&e=>phil.h...@oracle.com > <mailto:phil.h...@oracle.com> > >> On Feb 1, 2019, at 1:14 PM, Brian Campbell <bcampb...@pingidentity.com >> <mailto:bcampb...@pingidentity.com>> wrote: >> >> The server has to ask during the handshake for a client to send a cert. >> >> On Fri, Feb 1, 2019 at 2:12 PM Phil Hunt <phil.h...@oracle.com >> <mailto:phil.h...@oracle.com>> wrote: >> If a client attempts to force mtls would typical tls terminators accept it >> enough to redirect? >> >> My worry is how optionality works in browsers. It seems like they have to >> hit an mtls required endpoint before they reliably use a client cert. >> >> Phil >> >> On Feb 1, 2019, at 12:56 PM, Brian Campbell <bcampb...@pingidentity.com >> <mailto:bcampb...@pingidentity.com>> wrote: >> >>> It would be more a client having reached a non-MTLS endpoint and is 307'd >>> to an MTLS enabled endpoint. >>> >>> On Fri, Feb 1, 2019 at 1:40 PM Phil Hunt <phil.h...@oracle.com >>> <mailto:phil.h...@oracle.com>> wrote: >>> 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 >>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.independentid.com&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=phUYsLIDYY7XNgWGCUgJ7N9VhrrCNFXff2qqJiEF2rc&s=XMz5UneDiol_fVUSqQrKTYmt9CaOqeHjRwMvPx3szZc&e=>phil.h...@oracle.com >>> <mailto:phil.h...@oracle.com> >>> >>>> On Feb 1, 2019, at 11:56 AM, Brian Campbell >>>> <bcampbell=40pingidentity....@dmarc.ietf.org >>>> <mailto: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://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_oauth&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=phUYsLIDYY7XNgWGCUgJ7N9VhrrCNFXff2qqJiEF2rc&s=U24_047OeCiktLwRQs8xiahNU72QuHsnJ2k6R-Zuk0w&e=> >>>> >>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_oauth&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=phUYsLIDYY7XNgWGCUgJ7N9VhrrCNFXff2qqJiEF2rc&s=U24_047OeCiktLwRQs8xiahNU72QuHsnJ2k6R-Zuk0w&e=> >>>> >>>> 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 <mailto:OAuth@ietf.org> >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_oauth&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=phUYsLIDYY7XNgWGCUgJ7N9VhrrCNFXff2qqJiEF2rc&s=U24_047OeCiktLwRQs8xiahNU72QuHsnJ2k6R-Zuk0w&e=> >>> >>> >>> 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. > > > 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
