Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint

[Phil Hunt]

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 unexpected things. Because 
of this, returning the CertificateRequest message may cause problems for legacy 
clients. It seems practical to just to tell the MTLS clients where they will 
definitely work given they will make changes to support MTLS certs anyway.

Thanks.

Phil

Oracle Corporation, Cloud Security and Identity Architect
@independentid
www.independentid.com phil.h...@oracle.com 


> On Feb 1, 2019, at 3:26 PM, Brian Campbell  wrote:
> 
> 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 the 
> connection even when no client cert is presented. In the required case, the 
> server will terminate the handshake when no client cert is presented. 
> 
> So yes, optional is possible. The potential problem is the (sometimes pretty 
> bad and/or confusing) UI that browsers will present to the end-user anytime 
> the CertificateRequest message is sent by the server in the handshake. And 
> that message is sent in the optional case and the required case. Giving an AS 
> a way to avoid the potentially bad UX for the end user is the impetus behind 
> this whole discussion. 
> 
> On Fri, Feb 1, 2019 at 3:49 PM Phil Hunt  > wrote:
> 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 
> phil.h...@oracle.com
>  
> 
>> On Feb 1, 2019, at 1:43 PM, Brian Campbell > > wrote:
>> 
>> 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 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 
>> phil.h...@oracle.com
>>  
>> 
>>> On Feb 1, 2019, at 1:14 PM, Brian Campbell >> > 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 >> > 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 >> > 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 >>> > 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 

Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint

[Brian Campbell]

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
the connection even when no client cert is presented. In the required case,
the server will terminate the handshake when no client cert is presented.

So yes, optional is possible. The potential problem is the (sometimes
pretty bad and/or confusing) UI that browsers will present to the end-user
anytime the CertificateRequest message is sent by the server in the
handshake. And that message is sent in the optional case and the required
case. Giving an AS a way to avoid the potentially bad UX for the end user
is the impetus behind this whole discussion.

On Fri, Feb 1, 2019 at 3:49 PM Phil Hunt  wrote:

> 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
> phil.h...@oracle.com
>
> On Feb 1, 2019, at 1:43 PM, Brian Campbell 
> wrote:
>
> 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 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
>> 
>> phil.h...@oracle.com
>>
>> On Feb 1, 2019, at 1:14 PM, Brian Campbell 
>> 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  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 
>>> 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  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
 
 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> 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 
> 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

Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint

[Brian Campbell]

It doesn't seem like that confusing or large of a change to me - if the
client is doing MTLS and the given endpoint is present in `mtls_endpoints`,
then it uses that one.  Otherwise it uses the regular endpoint. It gives an
AS a lot of flexibility in deployment options. I personally think getting a
307 approach deployed and working would be more complicated and error
prone.

It is a minority use case at the moment but there are forces in play, like
the push for increased security in general and to have javascript clients
use the code flow, that suggest it won't be terribly unusual to see an AS
that wants to support MTLS clients and javascript/spa clients at the same
time.

I've personally wavered back and forth in this thread on whether or not to
add the new metadata (or something like it). With my reasoning each way
kinda explained somewhere back in the 40 or so messages that make up this
thread.  But it seems like the rough consensus of the group here is in
favor of it.




On Fri, Feb 1, 2019 at 3:18 PM Richard Backman, Annabelle  wrote:

> This strikes me as a very prominent and confusing change to support what
> seems to be a minority use case. I’m getting a headache just thinking about
> the text needed to clarify when the AS should provide `mtls_endpoints` and
> when the client should use that versus using `token_endpoint.` Why is the
> 307 status code insufficient to cover the case where a single AS supports
> both mTLS and non-mTLS?
>
>
>
> --
>
> 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 clients using the token
> endpoint
>
>
>
> Yes, that would work.
>
>
>
> On Fri, Feb 1, 2019 at 2:28 PM George Fletcher  40aol@dmarc.ietf.org> 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 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` metadata parameter - although it
> should be optional.
>
>
> *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 
> <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

Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint

[Phil Hunt]

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 phil.h...@oracle.com 


> On Feb 1, 2019, at 1:43 PM, Brian Campbell  wrote:
> 
> 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 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 
> phil.h...@oracle.com
>  
> 
>> On Feb 1, 2019, at 1:14 PM, Brian Campbell > > 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 > > 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 > > 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 >> > 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 
>>> phil.h...@oracle.com
>>>  
>>> 
 On Feb 1, 2019, at 11:56 AM, Brian Campbell 
 >>> > 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 >>> > 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 >>> > 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 >>> > 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 >>> > 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 

Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint

[Brian Campbell]

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 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
> phil.h...@oracle.com
>
> On Feb 1, 2019, at 1:14 PM, Brian Campbell 
> 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  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 
>> 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  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
>>> 
>>> 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> 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 
 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> 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 
>> 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> 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 >>> 40pingidentity@dmarc.ietf.org> wrote:

> Trying to summarize things somewhat here and focus in 

Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint

[Phil Hunt]

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 phil.h...@oracle.com 


> On Feb 1, 2019, at 1:14 PM, Brian Campbell  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  > 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  > 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 > > 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 
>> phil.h...@oracle.com
>>  
>> 
>>> On Feb 1, 2019, at 11:56 AM, Brian Campbell 
>>> >> > 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 >> > 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 >> > 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 >> > 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 >> > 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 >> > 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 
>>> >> > 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 

Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint

[Brian Campbell]

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 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` metadata parameter - although it
>> should be optional.
>>
>
> *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 listOAuth@ietf.orghttps://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._
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint

[George Fletcher]

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 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 
mailto:dave.to...@momentumft.co.uk>> wrote:


I'm in favour of the `mtls_endpoints` metadata parameter -
although it should be optional.


/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

Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint

[Brian Campbell]

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 to
> hit an mtls required endpoint before they reliably use a client cert.
>
> Phil
>
> On Feb 1, 2019, at 12:56 PM, Brian Campbell 
> 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  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
>> 
>> 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> 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  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> 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 
> 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> 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 >> 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;,
   

Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint

[Phil Hunt]

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  
> 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  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
>> phil.h...@oracle.com
>> 
>>> On Feb 1, 2019, at 11:56 AM, Brian Campbell 
>>>  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 
  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  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 
>>  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  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 
  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 
>  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;,
> "userinfo_endpoint":"https://mtls.example.com/userinfo;,
> "revocation_endpoint":"https://mtls..example.com/revo;
>   }
> }
> 
> The idea 

Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint

[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 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
> 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 
> 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  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> 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 
 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> 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 > 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
>>> ","userinfo_endpoint":"https://mtls
>>> .example.com/userinfo
>>> ","revocation_endpoint":"https://mtls
>>> ..example.com/revo
>>> "  }*
>>> }
>>>
>>> The idea behind this is that "regular" clients (those not doing
>>> MTLS) will 

Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint

[Phil Hunt]

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 phil.h...@oracle.com 


> On Feb 1, 2019, at 11:56 AM, Brian Campbell 
>  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  > 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  > 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  > 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  > 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  > 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 
>  > 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 
> ",
> "userinfo_endpoint":"https://mtls 
> .example.com/userinfo 
> ",
> "revocation_endpoint":"https://mtls 
> ..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 

Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint

[Brian Campbell]

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 
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  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> 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  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> 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  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
>> ","userinfo_endpoint":"https://mtls
>> .example.com/userinfo
>> ","revocation_endpoint":"https://mtls
>> ..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 

Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint

[Brian Campbell]

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 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 
> 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  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 
>>> 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 >>> 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
> ","userinfo_endpoint":"https://mtls
> .example.com/userinfo
> ","revocation_endpoint":"https://mtls
> ..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 

Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint

[Filip Skokan]

>
> 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 
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  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 
>> 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 >> 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
 ","userinfo_endpoint":"https://mtls
 .example.com/userinfo
 ","revocation_endpoint":"https://mtls
 ..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 

Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint

[Brian Campbell]

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 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 
> 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 > 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
>>> ","userinfo_endpoint":"https://mtls
>>> .example.com/userinfo
>>> ","revocation_endpoint":"https://mtls
>>> ..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 
 wrote:
 >
 > On 9 Jan 2019, at 05:54, David Waite 
 wrote:
 >>
 >>> On Dec 28, 2018, at 3:55 PM, Brian Campbell >>> 40pingidentity@dmarc.ietf.org> wrote:
 >>>
 >> 
 >>
 >>> All of that is meant as an explanation of sorts to say that I think
 that things are actually okay enough as is 

Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint

[Brian Campbell]

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` metadata parameter - although it
> should be optional.
>

-- 
_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

Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint

[Filip Skokan]

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 
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  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
>> ","userinfo_endpoint":"https://mtls
>> .example.com/userinfo
>> ","revocation_endpoint":"https://mtls
>> ..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 
>>> wrote:
>>> >
>>> > On 9 Jan 2019, at 05:54, David Waite 
>>> wrote:
>>> >>
>>> >>> On Dec 28, 2018, at 3:55 PM, Brian Campbell >> 40pingidentity@dmarc.ietf.org> 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 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 

Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint

[Brian Campbell]

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
","userinfo_endpoint":"https://mtls
.example.com/userinfo
","revocation_endpoint":"https://mtls
.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 
wrote:

>
>
> > 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  40pingidentity@dmarc.ietf.org> 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 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 

Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint

[Brian Campbell]

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 Tue, Jan 8, 2019 at 10:30 PM David Waite 
wrote:

>
> Was your testing via XHR/fetch?
>
> FWIW,
>
> Firefox behavior is determined by a global pick automatically / prompt
> every time flag. Details at https://wiki.mozilla.org/PSM:CertPrompt
>
> Safari on macOS relies on the keychain, where a record is created called
> an Identity Preference. This is a URL (https or email) to preferred
> certificate mapping. Previously, it would create this record the first time
> a user selected a certificate, then never prompt again.
>
> Chrome seems to delegate to the underlying OS for certificate management,
> so on the Mac it has this behavior as well. This means however that other
> platforms may have different behaviors.
>
> Safari on iOS used to automatically select a single certificate match, if
> the query was for a single client CA. I didn’t try with other small numbers
> (2, 3, etc) but when exposing the list of all available CAs as valid client
> CAs, it would prompt. This may not be the heuristic anymore, as knowing the
> name of a client CA (such one issued as part of a cloud EMM deployment)
> would allow certificates to be used for tracking.
>
> IE (pre-edge) would allow the behavior to use an automatic cert or prompt
> to be configured per-zone, which would allow policy to send a device/user
> identification certificate to a particular set of sites by default. I have
> no experience with configuring Edge, unfortunately.
>
> -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

Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint

[David Waite]

> 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 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
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint

[Filip Skokan]

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
authentication and only sends the client_id.

I’ll try to do a quick PoC for 307 and share any findings i may have.

Renegotiation not only isn’t easy to do in some common setups (self managed
tls terminating LB or proxy), but in some is outright impossible - e.g.
managed services like AWS ALB or API Gateway that may be in use for regular
requests and with self-hosted endpoints running nxinx/apache for just mtls
requests on the side.

Best,
*Filip*


On Fri, Jan 11, 2019 at 11: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  40pingidentity@dmarc.ietf.org> 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 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.
>
> > 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.
>
> — Neil
> ___
> 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

Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint

[Neil Madden]

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 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.

> 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.

— Neil
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint

[David Waite]

> 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 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.

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.

-DW___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint

[David Waite]

> 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 the 
> handshake. 
> 
> In a non-exhaustive and unscientific look at the browsers I had easily at my 
> disposal (FF, Chrome, and Safari on Mac OS), it seems they all behave 
> basically the same. If the browser is configured with, or has access to, one 
> or more client certificates that match the criteria of the CertificateRequest 
> message from the server (basically if issued by one of the CAs in the 
> certificate_authorities of the CertificateRequest), a certificate selection 
> UI prompt will be presented to the user. Otherwise, a certificate selection 
> UI prompt is not presented all. When the CertificateRequest message has an 
> empty certificate_authorities list (likely the case with a optional_no_ca 
> type config), the browsers look for client certificates with any issuer 
> rather than narrowing it down. 

Was your testing via XHR/fetch?

FWIW,

Firefox behavior is determined by a global pick automatically / prompt every 
time flag. Details at https://wiki.mozilla.org/PSM:CertPrompt 


Safari on macOS relies on the keychain, where a record is created called an 
Identity Preference. This is a URL (https or email) to preferred certificate 
mapping. Previously, it would create this record the first time a user selected 
a certificate, then never prompt again.

Chrome seems to delegate to the underlying OS for certificate management, so on 
the Mac it has this behavior as well. This means however that other platforms 
may have different behaviors.

Safari on iOS used to automatically select a single certificate match, if the 
query was for a single client CA. I didn’t try with other small numbers (2, 3, 
etc) but when exposing the list of all available CAs as valid client CAs, it 
would prompt. This may not be the heuristic anymore, as knowing the name of a 
client CA (such one issued as part of a cloud EMM deployment) would allow 
certificates to be used for tracking.

IE (pre-edge) would allow the behavior to use an automatic cert or prompt to be 
configured per-zone, which would allow policy to send a device/user 
identification certificate to a particular set of sites by default. I have no 
experience with configuring Edge, unfortunately.

-DW___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint

[Benjamin Kaduk]

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 without the user knowing and/or understanding that they are
> there and why). Those users would likely be prompted when TLS handshaking
> with a server that presents an empty list of CAs in the
> certificate_authorities of the CertificateRequest.
> 
> I dunno. Maybe I was too quick to retract the proposal for the MTLS
> supporting secondary token endpoint?
> 
> What do folks (including Ben & Neil) think?

Sorry for the slow reply.  I agree with Filip that we can't be confident
that the affected population is a vanishingly small population, so it
probably does make sense to continue thinking about how we can present a
better UX.

-Ben

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint

[Filip Skokan]

>
> 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 browser
> is configured with, or has access to, one or more certificate with the
> associated private key that could be used as client TLS certificates.


*with the associated private key* - hmm, does that explain my observation
then (tested on OS X Chrome and FF) the result was that supporting both
self-signed and PKI client auth method on the token (+introspection,
revocation) endpoints and support for cert bound access tokens on the
userinfo_endpoint for non-browser based clients while not prompting on
token, userinfo or revocation calls made from the browser.

This was my nginx server block
https://gist.github.com/panva/bb153c974cfd65fb0bc9ebb89ca0a3eb

Is that a valid setup? I honestly don't know, it seemed to fit the bill for
this particular AS configuration. But without the option to discover mtls
specific endpoints it's seems to be the only one usable for an AS that also
has browser-based clients, one couldn't use `on` or `optional`
configuration - are we in the position to restrict the possible
configuration to just one? nah.

If we consider having an `mtls_endpoints` or similar object in discovery
then this whole problem and potential broken UX goes away, or rather, will
only come up for browser based clients on e.g. provisioned hardware that
access sites like company's intranet etc. and is developed with using those
certs and therefore directly accessing the mtls_endpoints discovery
namespace.
The logic is also rather simple for a regular backend client
implementation, if there's a client cert, look for that object's endpoint
(and fallback to the usual if missing). If the client doesn't support
sending mtls client certs, it will continue using the regular endpoints.
The use of `mtls_endpoints` is optional but when used guarantees that
browser based clients will never have randomly broken UX for some users. I
can only imagine the support cases horror from customer's end-users who
don't know what to do.

It was, afterall, the original intention behind this section of the draft.

The authorization server may also consider hosting the token endpoint, and
other endpoints requiring client authentication, on a separate host name or
port in order to prevent unintended impact on the TLS behavior of its other
endpoints, e.g. the authorization endpoint.


S pozdravem,
*Filip Skokan*


On Tue, Jan 8, 2019 at 2:00 PM Brian Campbell 
wrote:

> 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
>> services end-users have encountered in the past and made them install certs.
>>
>> For example, in Czech Republic there's an online system for communicating
>> with government agencies, essentially an email-like inbox that you only get
>> when verifying your identity in person on a post office, every company is
>> required to have one for communication e.g. with the tax office and
>> individuals and freelancers are encouraged to have one as well. To finish
>> signing up for this inbox online after you've verified your identity in
>> person, you must install custom certificates on your system otherwise the
>> browser won't let you through the online signup part due to HSTS. I can say
>> with 100% confidence that most folk do not remove these certs from their
>> system, this means they'd fall in the category that gets prompted and are
>> in majority nowhere near the kind of users that are able to deal with the
>> UI prompt when encountered in the wild.
>>
>
> In this example, the custom certificates one has to install on their
> system are additional root CAs, right?  From my observations that has no
> bearing on the prompting behavior of the browsers (and shouldn't). What
> dictates the behavior is whether the browser is configured with, or has
> access to, one or more certificate with the associated private key that
> could be used as client TLS certificates.
>
>
>>
>> I'd like to see a solution that
>>
>>- works for every endpoint that needs mtls client cert for either
>>client auth or certificate bound token validation. This isn't only a case
>>for token endpoint, introspection, revocation, userinfo (RS-like endpoint
>>that might be checking a cert bound access token) to list a few
>>- can ensure clients without access to client certificates won't hit
>>an endpoint configured to request one to avoid the change of having the UX
>>flow broken, potentially selecting the wrong certificate which the browser
>>then remembers to use thus failing auth 

Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint

[Brian Campbell]

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).

On Mon, Jan 7, 2019 at 11:36 AM Neil Madden 
wrote:

> 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 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 without the user knowing and/or understanding that they are
> there and why). Those users would likely be prompted when TLS handshaking
> with a server that presents an empty list of CAs in the
> certificate_authorities of the CertificateRequest.
>
> I dunno. Maybe I was too quick to retract the proposal for the MTLS
> supporting secondary token endpoint?
>
> What do folks (including Ben & Neil) think?
>
> On Fri, Jan 4, 2019 at 2:55 PM Benjamin Kaduk  wrote:
>
>> On Fri, Dec 28, 2018 at 03:55:15PM -0700, Brian Campbell wrote:
>> > I
>> > suspect that not having client certs set up is the situation for the
>> vast
>> > majority of users and their browsers. And for those that do have client
>>
>> Is this still true when we limit to the set of users/browsers that are
>> employees of big corporations?
>>
>> -Ben
>>
>> > certs set up, I think they are more likely to be the kind of user that
>> is
>> > able to deal with the UI prompt okay.
>>
>
> *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

Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint

[Brian Campbell]

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
> services end-users have encountered in the past and made them install certs.
>
> For example, in Czech Republic there's an online system for communicating
> with government agencies, essentially an email-like inbox that you only get
> when verifying your identity in person on a post office, every company is
> required to have one for communication e.g. with the tax office and
> individuals and freelancers are encouraged to have one as well. To finish
> signing up for this inbox online after you've verified your identity in
> person, you must install custom certificates on your system otherwise the
> browser won't let you through the online signup part due to HSTS. I can say
> with 100% confidence that most folk do not remove these certs from their
> system, this means they'd fall in the category that gets prompted and are
> in majority nowhere near the kind of users that are able to deal with the
> UI prompt when encountered in the wild.
>

In this example, the custom certificates one has to install on their system
are additional root CAs, right?  From my observations that has no bearing
on the prompting behavior of the browsers (and shouldn't). What dictates
the behavior is whether the browser is configured with, or has access to,
one or more certificate with the associated private key that could be used
as client TLS certificates.


>
> I'd like to see a solution that
>
>- works for every endpoint that needs mtls client cert for either
>client auth or certificate bound token validation. This isn't only a case
>for token endpoint, introspection, revocation, userinfo (RS-like endpoint
>that might be checking a cert bound access token) to list a few
>- can ensure clients without access to client certificates won't hit
>an endpoint configured to request one to avoid the change of having the UX
>flow broken, potentially selecting the wrong certificate which the browser
>then remembers to use thus failing auth until website data is cleared.
>
> Working under the assumption a client software always knows whether it is
> configured with client certificates or not it would be nice if there was
> either a defined prefix, suffix or a specific object in the discovery
> response (with the same endpoint names in it) that a client can rely on to
> detect if there is an mtls specific url for any discovered endpoint it
> needs to use when providing client certificates.
>

Yeah, you are right about other endpoints (I'd been kind of willfully
ignoring them to be honest) and I think the specific object in the
discovery response that itself could have any of the same endpoint names in
it would be the most straight forward way to approach that.


Best,
> *Filip*
>
>
> On Mon, Jan 7, 2019 at 6:22 PM Brian Campbell  40pingidentity@dmarc.ietf.org> 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 without the user knowing and/or understanding that they are
>> there and why). Those users would likely be prompted when TLS handshaking
>> with a server that presents an empty list of CAs in the
>> certificate_authorities of the CertificateRequest.
>>
>> I dunno. Maybe I was too quick to retract the proposal for the MTLS
>> supporting secondary token endpoint?
>>
>> What do folks (including Ben & Neil) think?
>>
>> On Fri, Jan 4, 2019 at 2:55 PM Benjamin Kaduk  wrote:
>>
>>> On Fri, Dec 28, 2018 at 03:55:15PM -0700, Brian Campbell wrote:
>>> > I
>>> > suspect that not having client certs set up is the situation for the
>>> vast
>>> > majority of users and their browsers. And for those that do have client
>>>
>>> Is this still true when we limit to the set of users/browsers that are
>>> employees of big corporations?
>>>
>>> -Ben
>>>
>>> > certs set up, I think they are more likely to be the kind of user that
>>> is
>>> > able to deal with the UI prompt okay.
>>>
>>
>> *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
>>
>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use 

Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint

[Neil Madden]

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 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 without the user knowing and/or understanding that they are there and 
> why). Those users would likely be prompted when TLS handshaking with a server 
> that presents an empty list of CAs in the certificate_authorities of the 
> CertificateRequest. 
> 
> I dunno. Maybe I was too quick to retract the proposal for the MTLS 
> supporting secondary token endpoint?
> 
> What do folks (including Ben & Neil) think? 
> 
>> On Fri, Jan 4, 2019 at 2:55 PM Benjamin Kaduk  wrote:
>> On Fri, Dec 28, 2018 at 03:55:15PM -0700, Brian Campbell wrote:
>> > I
>> > suspect that not having client certs set up is the situation for the vast
>> > majority of users and their browsers. And for those that do have client
>> 
>> Is this still true when we limit to the set of users/browsers that are
>> employees of big corporations?
>> 
>> -Ben
>> 
>> > certs set up, I think they are more likely to be the kind of user that is
>> > able to deal with the UI prompt okay.
> 
> 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

Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint

[Filip Skokan]

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.

For example, in Czech Republic there's an online system for communicating
with government agencies, essentially an email-like inbox that you only get
when verifying your identity in person on a post office, every company is
required to have one for communication e.g. with the tax office and
individuals and freelancers are encouraged to have one as well. To finish
signing up for this inbox online after you've verified your identity in
person, you must install custom certificates on your system otherwise the
browser won't let you through the online signup part due to HSTS. I can say
with 100% confidence that most folk do not remove these certs from their
system, this means they'd fall in the category that gets prompted and are
in majority nowhere near the kind of users that are able to deal with the
UI prompt when encountered in the wild.

I'd like to see a solution that

   - works for every endpoint that needs mtls client cert for either client
   auth or certificate bound token validation. This isn't only a case for
   token endpoint, introspection, revocation, userinfo (RS-like endpoint that
   might be checking a cert bound access token) to list a few
   - can ensure clients without access to client certificates won't hit an
   endpoint configured to request one to avoid the change of having the UX
   flow broken, potentially selecting the wrong certificate which the browser
   then remembers to use thus failing auth until website data is cleared.

Working under the assumption a client software always knows whether it is
configured with client certificates or not it would be nice if there was
either a defined prefix, suffix or a specific object in the discovery
response (with the same endpoint names in it) that a client can rely on to
detect if there is an mtls specific url for any discovered endpoint it
needs to use when providing client certificates.

Best,
*Filip*


On Mon, Jan 7, 2019 at 6:22 PM 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 without the user knowing and/or understanding that they are
> there and why). Those users would likely be prompted when TLS handshaking
> with a server that presents an empty list of CAs in the
> certificate_authorities of the CertificateRequest.
>
> I dunno. Maybe I was too quick to retract the proposal for the MTLS
> supporting secondary token endpoint?
>
> What do folks (including Ben & Neil) think?
>
> On Fri, Jan 4, 2019 at 2:55 PM Benjamin Kaduk  wrote:
>
>> On Fri, Dec 28, 2018 at 03:55:15PM -0700, Brian Campbell wrote:
>> > I
>> > suspect that not having client certs set up is the situation for the
>> vast
>> > majority of users and their browsers. And for those that do have client
>>
>> Is this still true when we limit to the set of users/browsers that are
>> employees of big corporations?
>>
>> -Ben
>>
>> > certs set up, I think they are more likely to be the kind of user that
>> is
>> > able to deal with the UI prompt okay.
>>
>
> *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

Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint

[Brian Campbell]

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 why). Those users would likely be prompted when TLS handshaking
with a server that presents an empty list of CAs in the
certificate_authorities of the CertificateRequest.

I dunno. Maybe I was too quick to retract the proposal for the MTLS
supporting secondary token endpoint?

What do folks (including Ben & Neil) think?

On Fri, Jan 4, 2019 at 2:55 PM Benjamin Kaduk  wrote:

> On Fri, Dec 28, 2018 at 03:55:15PM -0700, Brian Campbell wrote:
> > I
> > suspect that not having client certs set up is the situation for the vast
> > majority of users and their browsers. And for those that do have client
>
> Is this still true when we limit to the set of users/browsers that are
> employees of big corporations?
>
> -Ben
>
> > certs set up, I think they are more likely to be the kind of user that is
> > able to deal with the UI prompt okay.
>

-- 
_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

Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint

[Benjamin Kaduk]

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
> thread (a javascript client making a fetch/XHR request to an MTLS token
> endpoint), users using browsers that are not configured with, or have
> access to, any client keys/certs will not see any UI prompt at all. I
> suspect that not having client certs set up is the situation for the vast
> majority of users and their browsers. And for those that do have client

Is this still true when we limit to the set of users/browsers that are
employees of big corporations?

-Ben

> certs set up, I think they are more likely to be the kind of user that is
> able to deal with the UI prompt okay.

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint

[Brian Campbell]

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 browsers I had easily at
my disposal (FF, Chrome, and Safari on Mac OS), it seems they all behave
basically the same. If the browser is configured with, or has access to,
one or more client certificates that match the criteria of the
CertificateRequest message from the server (basically if issued by one of
the CAs in the certificate_authorities of the CertificateRequest), a
certificate selection UI prompt will be presented to the user. Otherwise, a
certificate selection UI prompt is not presented all. When the
CertificateRequest message has an empty certificate_authorities list
(likely the case with a optional_no_ca type config), the browsers look for
client certificates with any issuer rather than narrowing it down.

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
thread (a javascript client making a fetch/XHR request to an MTLS token
endpoint), users using browsers that are not configured with, or have
access to, any client keys/certs will not see any UI prompt at all. I
suspect that not having client certs set up is the situation for the vast
majority of users and their browsers. And for those that do have client
certs set up, I think they are more likely to be the kind of user that is
able to deal with the UI prompt okay.

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.



On Fri, Dec 28, 2018 at 10:50 AM Neil Madden 
wrote:

> 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 tokens vanishes if the resource server doesn’t
> understand and enforce the certificate-binding associated with the access
> token, is there a general need for a client to be able to discover if any
> given RS does actually support this? Otherwise the whole scheme “fails
> open” in that the access token silently degrades to a normal bearer token.
> Or do we consider it unlikely that an RS is going to accept a TLS client
> certificate without supporting this?
>
> — Neil
>
> > On 17 Dec 2018, at 20:26, Brian Campbell  40pingidentity@dmarc.ietf.org> wrote:
> >
> > While there's been some disagreement about the specific wording etc.,
> there does seem to be general consensus coming out of this WG to, in one
> form or another, recommend against the use of the implicit grant in favor
> of authorization code. In order to follow that recommendation, in-browser
> JavaScript clients will need to use XHR/fetch (and likely CORS) to make
> requests directly to the token endpoint.
> >
> > Meanwhile there is the MTLS document utilizes TLS client certificates at
> the token endpoint for client authentication and/or certificate bound
> access tokens. The security BCP draft even recommends sender/key
> constrained access tokens and MTLS is close to the only viable way to do
> that at this time.
> >
> > Unfortunately, however, these two things don't play very nice together.
> When a browser makes a TLS connection where a client cert is requested by
> the server in the handshake, even when client certificates are optional and
> even when it's fetch/XHR, most/many/all browsers will throw up some kind of
> certificate selection interface to the user.  Which is typically a very
> very bad user experience. From a practical standpoint, this means that a
> single deployment cannot really support the MTLS draft and have in-browser
> JavaScript clients using authorization code at the same time.
> >
> > In order to address the conflict here, I'd propose that the MTLS draft
> introduce a new optional AS metadata parameter that is an MTLS enabled
> token endpoint alias. Clients that are doing MTLS client authentication
> and/or certificate bound access tokens would/should/must use the
> alternative token endpoint when present in the AS's metadata. While all
> other clients continue to use the standard token endpoint as they always
> have. This would allow for an AS to deploy an alternative token endpoint
> alias on a distinct host or port 

Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint

[Neil Madden]

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 tokens vanishes if the resource server doesn’t 
understand and enforce the certificate-binding associated with the access 
token, is there a general need for a client to be able to discover if any given 
RS does actually support this? Otherwise the whole scheme “fails open” in that 
the access token silently degrades to a normal bearer token. Or do we consider 
it unlikely that an RS is going to accept a TLS client certificate without 
supporting this?

— Neil

> On 17 Dec 2018, at 20:26, Brian Campbell 
>  wrote:
> 
> While there's been some disagreement about the specific wording etc., there 
> does seem to be general consensus coming out of this WG to, in one form or 
> another, recommend against the use of the implicit grant in favor of 
> authorization code. In order to follow that recommendation, in-browser 
> JavaScript clients will need to use XHR/fetch (and likely CORS) to make 
> requests directly to the token endpoint.
> 
> Meanwhile there is the MTLS document utilizes TLS client certificates at the 
> token endpoint for client authentication and/or certificate bound access 
> tokens. The security BCP draft even recommends sender/key constrained access 
> tokens and MTLS is close to the only viable way to do that at this time. 
> 
> Unfortunately, however, these two things don't play very nice together. When 
> a browser makes a TLS connection where a client cert is requested by the 
> server in the handshake, even when client certificates are optional and even 
> when it's fetch/XHR, most/many/all browsers will throw up some kind of 
> certificate selection interface to the user.  Which is typically a very very 
> bad user experience. From a practical standpoint, this means that a single 
> deployment cannot really support the MTLS draft and have in-browser 
> JavaScript clients using authorization code at the same time. 
> 
> In order to address the conflict here, I'd propose that the MTLS draft 
> introduce a new optional AS metadata parameter that is an MTLS enabled token 
> endpoint alias. Clients that are doing MTLS client authentication and/or 
> certificate bound access tokens would/should/must use the alternative token 
> endpoint when present in the AS's metadata. While all other clients continue 
> to use the standard token endpoint as they always have. This would allow for 
> an AS to deploy an alternative token endpoint alias on a distinct host or 
> port where it will request client certs in the TLS handshake for OAuth 
> clients that use it while keeping the regular token endpoint as it normally 
> is for other clients, especially in-browser JavaScript clients. 
> 
> Thoughts, objections, agreements, etc., on this proposal?
> 
> PS Bikeshedding on a name for the metadata parameter is also welcome. Some 
> ideas to start:
> token_endpoint_mtls_alias
> token_endpoint_mtls
> mtls_token_endpoint_alias
> mtls_token_endpoint
> alt_token_endpoint_mtls
> mtls_token_endpoint_alt
> a_token_endpoint_that_a_client_wanting_to_do_mtls_stuff_a_la_RFC_[TBD]_should_use
> equally_poor_idea_here
> 
> 
> 
> 
> 
> 
> 
> 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

Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint

[Filip Skokan]

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. 2018 v 23:10, John Bradley :

> 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 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 HTTPS in either Safari or Chrome on Mac does not prompt me 
>> for any certificate. I don’t have any client certificates configured in my 
>> browser, so does this only happen if you do?
>> 
>> Depending on the deployment scenario, it may also be possible to terminate 
>> TLS at a proxy and use a separate proxy for (intranet) mTLS clients vs 
>> public clients, but that may not suit every deployment.
>> 
>> — Neil
>> 
>>> On 17 Dec 2018, at 20:26, Brian Campbell 
>>>  wrote:
>>> 
>>> While there's been some disagreement about the specific wording etc., there 
>>> does seem to be general consensus coming out of this WG to, in one form or 
>>> another, recommend against the use of the implicit grant in favor of 
>>> authorization code. In order to follow that recommendation, in-browser 
>>> JavaScript clients will need to use XHR/fetch (and likely CORS) to make 
>>> requests directly to the token endpoint.
>>> 
>>> Meanwhile there is the MTLS document utilizes TLS client certificates at 
>>> the token endpoint for client authentication and/or certificate bound 
>>> access tokens. The security BCP draft even recommends sender/key 
>>> constrained access tokens and MTLS is close to the only viable way to do 
>>> that at this time.
>>> 
>>> Unfortunately, however, these two things don't play very nice together. 
>>> When a browser makes a TLS connection where a client cert is requested by 
>>> the server in the handshake, even when client certificates are optional and 
>>> even when it's fetch/XHR, most/many/all browsers will throw up some kind of 
>>> certificate selection interface to the user.  Which is typically a very 
>>> very bad user experience. From a practical standpoint, this means that a 
>>> single deployment cannot really support the MTLS draft and have in-browser 
>>> JavaScript clients using authorization code at the same time.
>>> 
>>> In order to address the conflict here, I'd propose that the MTLS draft 
>>> introduce a new optional AS metadata parameter that is an MTLS enabled 
>>> token endpoint alias. Clients that are doing MTLS client authentication 
>>> and/or certificate bound access tokens would/should/must use the 
>>> alternative token endpoint when present in the AS's metadata. While all 
>>> other clients continue to use the standard token endpoint as they always 
>>> have. This would allow for an AS to deploy an alternative token endpoint 
>>> alias on a distinct host or port where it will request client certs in the 
>>> TLS handshake for OAuth clients that use it while keeping the regular token 
>>> endpoint as it normally is for other clients, especially in-browser 
>>> JavaScript clients.
>>> 
>>> Thoughts, objections, agreements, etc., on this proposal?
>>> 
>>> PS Bikeshedding on a name for the metadata parameter is also welcome. Some 
>>> ideas to start:
>>> token_endpoint_mtls_alias
>>> token_endpoint_mtls
>>> mtls_token_endpoint_alias
>>> mtls_token_endpoint
>>> alt_token_endpoint_mtls
>>> mtls_token_endpoint_alt
>>> a_token_endpoint_that_a_client_wanting_to_do_mtls_stuff_a_la_RFC_[TBD]_should_use
>>> equally_poor_idea_here
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 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
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org

Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint

[John Bradley]

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 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 HTTPS in either Safari or Chrome on Mac does not prompt me for any 
certificate. I don’t have any client certificates configured in my browser, so 
does this only happen if you do?

Depending on the deployment scenario, it may also be possible to terminate TLS 
at a proxy and use a separate proxy for (intranet) mTLS clients vs public 
clients, but that may not suit every deployment.

— Neil


On 17 Dec 2018, at 20:26, Brian Campbell 
 wrote:

While there's been some disagreement about the specific wording etc., there 
does seem to be general consensus coming out of this WG to, in one form or 
another, recommend against the use of the implicit grant in favor of 
authorization code. In order to follow that recommendation, in-browser 
JavaScript clients will need to use XHR/fetch (and likely CORS) to make 
requests directly to the token endpoint.

Meanwhile there is the MTLS document utilizes TLS client certificates at the 
token endpoint for client authentication and/or certificate bound access 
tokens. The security BCP draft even recommends sender/key constrained access 
tokens and MTLS is close to the only viable way to do that at this time.

Unfortunately, however, these two things don't play very nice together. When a 
browser makes a TLS connection where a client cert is requested by the server 
in the handshake, even when client certificates are optional and even when it's 
fetch/XHR, most/many/all browsers will throw up some kind of certificate 
selection interface to the user.  Which is typically a very very bad user 
experience. From a practical standpoint, this means that a single deployment 
cannot really support the MTLS draft and have in-browser JavaScript clients 
using authorization code at the same time.

In order to address the conflict here, I'd propose that the MTLS draft 
introduce a new optional AS metadata parameter that is an MTLS enabled token 
endpoint alias. Clients that are doing MTLS client authentication and/or 
certificate bound access tokens would/should/must use the alternative token 
endpoint when present in the AS's metadata. While all other clients continue to 
use the standard token endpoint as they always have. This would allow for an AS 
to deploy an alternative token endpoint alias on a distinct host or port where 
it will request client certs in the TLS handshake for OAuth clients that use it 
while keeping the regular token endpoint as it normally is for other clients, 
especially in-browser JavaScript clients.

Thoughts, objections, agreements, etc., on this proposal?

PS Bikeshedding on a name for the metadata parameter is also welcome. Some 
ideas to start:
token_endpoint_mtls_alias
token_endpoint_mtls
mtls_token_endpoint_alias
mtls_token_endpoint
alt_token_endpoint_mtls
mtls_token_endpoint_alt
a_token_endpoint_that_a_client_wanting_to_do_mtls_stuff_a_la_RFC_[TBD]_should_use
equally_poor_idea_here







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


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint

[Neil Madden]

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 HTTPS in either Safari or Chrome on Mac does not prompt me for any 
certificate. I don’t have any client certificates configured in my browser, so 
does this only happen if you do?

Depending on the deployment scenario, it may also be possible to terminate TLS 
at a proxy and use a separate proxy for (intranet) mTLS clients vs public 
clients, but that may not suit every deployment.

— Neil

> On 17 Dec 2018, at 20:26, Brian Campbell 
>  wrote:
> 
> While there's been some disagreement about the specific wording etc., there 
> does seem to be general consensus coming out of this WG to, in one form or 
> another, recommend against the use of the implicit grant in favor of 
> authorization code. In order to follow that recommendation, in-browser 
> JavaScript clients will need to use XHR/fetch (and likely CORS) to make 
> requests directly to the token endpoint.
> 
> Meanwhile there is the MTLS document utilizes TLS client certificates at the 
> token endpoint for client authentication and/or certificate bound access 
> tokens. The security BCP draft even recommends sender/key constrained access 
> tokens and MTLS is close to the only viable way to do that at this time. 
> 
> Unfortunately, however, these two things don't play very nice together. When 
> a browser makes a TLS connection where a client cert is requested by the 
> server in the handshake, even when client certificates are optional and even 
> when it's fetch/XHR, most/many/all browsers will throw up some kind of 
> certificate selection interface to the user.  Which is typically a very very 
> bad user experience. From a practical standpoint, this means that a single 
> deployment cannot really support the MTLS draft and have in-browser 
> JavaScript clients using authorization code at the same time. 
> 
> In order to address the conflict here, I'd propose that the MTLS draft 
> introduce a new optional AS metadata parameter that is an MTLS enabled token 
> endpoint alias. Clients that are doing MTLS client authentication and/or 
> certificate bound access tokens would/should/must use the alternative token 
> endpoint when present in the AS's metadata. While all other clients continue 
> to use the standard token endpoint as they always have. This would allow for 
> an AS to deploy an alternative token endpoint alias on a distinct host or 
> port where it will request client certs in the TLS handshake for OAuth 
> clients that use it while keeping the regular token endpoint as it normally 
> is for other clients, especially in-browser JavaScript clients. 
> 
> Thoughts, objections, agreements, etc., on this proposal?
> 
> PS Bikeshedding on a name for the metadata parameter is also welcome. Some 
> ideas to start:
> token_endpoint_mtls_alias
> token_endpoint_mtls
> mtls_token_endpoint_alias
> mtls_token_endpoint
> alt_token_endpoint_mtls
> mtls_token_endpoint_alt
> a_token_endpoint_that_a_client_wanting_to_do_mtls_stuff_a_la_RFC_[TBD]_should_use
> equally_poor_idea_here
> 
> 
> 
> 
> 
> 
> 
> 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

Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint

[John Bradley]

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 endpoint in discovery is a good idea  they can always both 
point to the same place.


John B.

On 12/17/2018 12:26 PM, Brian Campbell wrote:
While there's been some disagreement about the specific wording etc., 
there does seem to be general consensus coming out of this WG to, in 
one form or another, recommend against the use of the implicit grant 
in favor of authorization code. In order to follow that 
recommendation, in-browser JavaScript clients will need to use 
XHR/fetch (and likely CORS) to make requests directly to the token 
endpoint.


Meanwhile there is the MTLS document 
 utilizes TLS 
client certificates at the token endpoint for client authentication 
and/or certificate bound access tokens. The security BCP draft even 
recommends sender/key constrained access tokens and MTLS is close to 
the only viable way to do that at this time.


Unfortunately, however, these two things don't play very nice 
together. When a browser makes a TLS connection where a client cert is 
requested by the server in the handshake, even when client 
certificates are optional and even when it's fetch/XHR, most/many/all 
browsers will throw up some kind of certificate selection interface to 
the user.  Which is typically a very very bad user experience. From a 
practical standpoint, this means that a single deployment cannot 
really support the MTLS draft and have in-browser JavaScript clients 
using authorization code at the same time.


In order to address the conflict here, I'd propose that the MTLS draft 
introduce a new optional AS metadata parameter that is an MTLS enabled 
token endpoint alias. Clients that are doing MTLS client 
authentication and/or certificate bound access tokens 
would/should/must use the alternative token endpoint when present in 
the AS's metadata. While all other clients continue to use the 
standard token endpoint as they always have. This would allow for an 
AS to deploy an alternative token endpoint alias on a distinct host or 
port where it will request client certs in the TLS handshake for OAuth 
clients that use it while keeping the regular token endpoint as it 
normally is for other clients, especially in-browser JavaScript clients.


Thoughts, objections, agreements, etc., on this proposal?

PS Bikeshedding on a name for the metadata parameter is also welcome. 
Some ideas to start:

token_endpoint_mtls_alias
token_endpoint_mtls
mtls_token_endpoint_alias
mtls_token_endpoint
alt_token_endpoint_mtls
mtls_token_endpoint_alt
a_token_endpoint_that_a_client_wanting_to_do_mtls_stuff_a_la_RFC_[TBD]_should_use
equally_poor_idea_here







/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