Brian,
Thanks for clarifying. Given the browser uncertainty that happens with optional
configs and browsers, I agree with your suggestion of using ‘mtls_endpoints’.
I’m expecting this will be a big deal as we migrate apps and clients. We have
to make sure old clients keep working and don’t do
Yes client certificate authen can be made optional. In the optional case
the server still sends the CertificateRequest message during the handshake
which efficiently asks the client to present a cert. The client send a cert
or not at that point. In the optional case, the server will continue with
> --
>
> Annabelle Richard Backman
>
> AWS Identity
>
>
>
>
>
> *From: *OAuth on behalf of Brian Campbell
>
> *Date: *Friday, February 1, 2019 at 1:31 PM
> *To: *George Fletcher
> *Cc: *oauth
> *Subject: *Re: [OAUTH-WG] MTLS and in-browser clie
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
I guess I'm not clear what you are driving at.
On Fri, Feb 1, 2019 at 2:32 PM Phil Hunt 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
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
Yes, that would work.
On Fri, Feb 1, 2019 at 2:28 PM George Fletcher wrote:
> What if the AS wants to ONLY support MTLS connections. Does it not specify
> the optional "mtls_endpoints" and just use the normal metadata values?
>
> On 1/15/19 8:48 AM, Brian Campbell wrote:
>
> It would definitely
What if the AS wants to ONLY support MTLS connections. Does it not
specify the optional "mtls_endpoints" and just use the normal metadata
values?
On 1/15/19 8:48 AM, Brian Campbell wrote:
It would definitely be optional, apologies if that wasn't made clear.
It'd be something to the effect of
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 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
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
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 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
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
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
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 wrote:
> I don't know that the use of 307 would need to be discussed in the
>> document
>
> 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
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 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
It would definitely be optional, apologies if that wasn't made clear. It'd
be something to the effect of optional for the AS to include and clients
doing MTLS would use it when present in AS metadata.
On Tue, Jan 15, 2019 at 2:04 AM Dave Tonge
wrote:
> I'm in favour of the `mtls_endpoints`
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 -
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
No, my testing was not via XHR/fetch. Just direct request from the browser.
I was making the assumption (maybe foolishly) that it wouldn't impact
behavior because it's all at the network layer.
I saw that Firefox setting but left the default (at least for my install),
which was not to autopick.
> On Jan 11, 2019, at 3:32 AM, Neil Madden wrote:
>
> On 9 Jan 2019, at 05:54, David Waite wrote:
>>
>>> On Dec 28, 2018, at 3:55 PM, Brian Campbell
>>> wrote:
>>>
>>
>>
>>> All of that is meant as an explanation of sorts to say that I think that
>>> things are actually okay enough as
307 indeed seems doable, similar to a discovery namespace it requires the
client software to be prepared for this and follow the redirect in that
case, but in David’s case it doesn’t require the client to “know” it is
bound to a device wide policy. The client just assumes it has no form of
On 9 Jan 2019, at 05:54, David Waite wrote:
>
>> On Dec 28, 2018, at 3:55 PM, Brian Campbell
>> wrote:
>>
>
>
>> 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
> On Dec 28, 2018, at 3:55 PM, Brian Campbell
> wrote:
>
> 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
> On Dec 28, 2018, at 3:55 PM, Brian Campbell
> wrote:
>
> I spent some time this holiday season futzing around with a few different
> browsers to see what kind of UI, if any, they present to the user when seeing
> different variations of the server requesting a client certificate during
On Mon, Jan 07, 2019 at 10:21:51AM -0700, Brian Campbell wrote:
> I don't honestly know for sure but I suspect that employees of big
> corporations will likely have keys/certs on their devices/machines that are
> issued by some internal CA and provisioned to them automatically (and in
> many cases
>
> In this example, the custom certificates one has to install on their
> system are additional root CAs, right?
Correct,* in this example.*
> From my observations that has no bearing on the prompting behavior of the
> browsers (and shouldn't). What dictates the behavior is whether the
Yes *but* not when the client is a javascript application running in the
user's browser. And the direction this WG is taking is to start/continue to
suggest that such clients use the code flow (which hits the token endpoint)
rather than the implicit (which only hits the authorization endpoint).
inline below...
On Mon, Jan 7, 2019 at 11:15 AM Filip Skokan wrote:
> I think we shouldn't make a sweeping assumption that may potentially harm
> UX for end-users. Even if for a small percentage. Tho i can say for sure
> this percentage may also be rather significant depending on the types of
>
Thinking about this, given that this is the *token* endpoint that clients talk
to directly, not the *authorize* endpoint, it seems already possible for the AS
to put it on a different port/host so that users aren’t ever prompted for a
cert. Right?
— Neil
> On 7 Jan 2019, at 17:21, Brian
I think we shouldn't make a sweeping assumption that may potentially harm
UX for end-users. Even if for a small percentage. Tho i can say for sure
this percentage may also be rather significant depending on the types of
services end-users have encountered in the past and made them install certs.
I don't honestly know for sure but I suspect that employees of big
corporations will likely have keys/certs on their devices/machines that are
issued by some internal CA and provisioned to them automatically (and in
many cases without the user knowing and/or understanding that they are
there and
On Fri, Dec 28, 2018 at 03:55:15PM -0700, Brian Campbell wrote:
>
> The observed behavior of the browsers surveyed seems logical and rather
> reasonable (and better than the last time I futzed with it). Importantly it
> means that for the situation described in the email that started this
>
I spent some time this holiday season futzing around with a few different
browsers to see what kind of UI, if any, they present to the user when
seeing different variations of the server requesting a client certificate
during the handshake.
In a non-exhaustive and unscientific look at the
On the assumption that this is likely to be a requirement from customers, I’d
be in favour of a new server metadata field. My favourite bikeshed colour would
be:
tls_client_auth_token_endpoint
On another metadata-related note, given that the additional security of
certificate-bound access
Correct. If there are certs installed on the device the browsers are likely
going to prompt.
Having at least one CA configured together with optional_no_ca (even if its a
CA noone ever has certs for) additionally omits the prompt for some client
configurations.
Odesláno z iPhonu
17. 12.
I think that works for those browsers if no certificates are installed
for the browser. We should test, but I think if any certificates are
available to the browser then it will prompt.
John B.
On 12/17/2018 1:52 PM, Neil Madden wrote:
I am currently running a Tomcat instance that I have
I am currently running a Tomcat instance that I have configured to support, but
not demand, client certificates using the
certificateVerification=“optionalNoCA” setting. With this config I am able to
authenticate a confidential client using mTLS, and yet connecting to the same
server over
Yes that is a general problem with browsers and MTLS.
A separate token endpoint is probably useful.
I don't really see SPA doing mutual TLS as likely, however once MTLS is
turned on on the token endpoint for some clients it can mess up other
browser and non browser clients.
A separate
39 matches
Mail list logo
