Subject: [OAUTH-WG] MTLS and Native apps Best practices

From: Phil Hunt <[email-masked]>
Date: Thu, 2 May 2019 11:41:19 -0700

I was wondering if anyone had any recommended MTLS best practices for mobile apps and native browsers.

Considering Section 6 of RFC8252…
   After constructing the authorization request URI, the app uses
   platform-specific APIs to open the URI in an external user-agent.
   Typically, the external user-agent used is the default browser, that
   is, the application configured for handling "http" and "https" scheme
   URIs on the system; however, different browser selection criteria and
   other categories of external user-agents MAY be used.

What choices do developers have to ensure the authorization (and subsequent user authentication) occur over MTLS? Can the app provide its own key for MTLS or can it ask that an embedded X.509 cert be used (assuming one is available)?

Are there any platform issues or best practices?

Phil Hunt | Cloud Security and Identity Architect
Oracle Corporation, Oracle Cloud Infrastructure
@independentid
www.independentid.com
[email-masked]

---

From: Torsten Lodderstedt <[email-masked]>
Date: Fri, 3 May 2019 08:27:39 +0200

Hi Phil,

since mTLS is used at the tokens endpoint, native apps can definitely use their own key  pair. I would asunder such an app to act as public client, but mTLS would allow such an app to bind its key pair with the token request to the issued tokens.

Apps running in the browser is a separate topic. There are potential issues with using the certs in the browser. That’s why work towards an application level PoP mechanism has been started - DPoP.

best regards,
Torsten.

> Am 02.05.2019 um 20:41 schrieb Phil Hunt <[email-masked]>:
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Phil Hunt <[email-masked]>
Date: Fri, 3 May 2019 00:07:20 -0700

Yes. I was more wondering if the app can invoke the system embedded view using its own key pair to ensure protected authen. 

Eg. If the authorization endpoint is set to require mutual tls, can the system view use the app’s keys since the app is invoking it?

Or, would there have to be a user x.509 cert embedded in the browser store?  

I agree browser based apps is another matter. 

Phil

> On May 2, 2019, at 11:27 PM, Torsten Lodderstedt <[email-masked]> wrote:
> 
> Hi Phil,
>

---

From: Rob Otto <[email-masked]>
Date: Fri, 3 May 2019 08:12:52 +0100

Are you hoping to use the key to authenticate the user, or the OAuth
client? If it's the latter, then you don't need to use MTLS to the
authorisation endpoint. If it's the former, I'd argue that you would
certainly need to include your public key in an X509 cert and *somehow*
make it available to the system browser.

On Fri, 3 May 2019 at 08:07, Phil Hunt <[email-masked]> wrote:

> Yes. I was more wondering if the app can invoke the system embedded view
> using its own key pair to ensure protected authen.
>
> Eg. If the authorization endpoint is set to require mutual tls, can the
> system view use the app’s keys since the app is invoking it?
>
> Or, would there have to be a user x..509 cert embedded in the browser
> store?
>
> since mTLS is used at the tokens endpoint, native apps can definitely use
> their own key  pair. I would asunder such an app to act as public client,
> but mTLS would allow such an app to bind its key pair with the token
> request to the issued tokens.
>
> Apps running in the browser is a separate topic. There are potential
> issues with using the certs in the browser. That’s why work towards an
> application level PoP mechanism has been started - DPoP.
>
> best regards,
> Torsten.
>
> What choices do developers have to ensure the authorization (and
> subsequent user authentication) occur over MTLS? Can the app provide its
> own key for MTLS or can it ask that an embedded X.509 cert be used
> (assuming one is available)?
>

-- 
<https://www.pingidentity.com>
<https://www.pingidentity.com>
Rob Otto
EMEA Field CTO/Solutions Architect
[email-masked]

c: +44 (0) 777 135 6092
Connect with us: 
<https://www.glassdoor.com/Overview/Working-at-Ping-Identity-EI_IE380907.11,24.htm>
[image:
LinkedIn logo] <https://www.linkedin.com/company/21870> [image: twitter
logo] <https://twitter.com/pingidentity> 
<https://www.facebook.com/pingidentitypage> 
<https://www.youtube.com/user/PingIdentityTV> 
<https://plus.google.com/u/0/114266977739397708540> 
<https://www.pingidentity.com/en/blog.html>
<https://www.pingidentity.com/content/ping/en/lp/d/p14e-trial.html>
<https://www.pingidentity.com/en/lp/d/p14e-trial.html?utm_source=Email&utm_medium=p14e-trial-sso-mfa-emailsig&utm_campaign=p14e-trial-sso-mfa-emailsig>
<https://www.pingidentity.com/en/lp/d/p14e-trial.html?utm_source=Email&utm_medium=p14e-trial-sso-mfa-emailsig&utm_campaign=p14e-trial-sso-mfa-emailsig>
<https://developer.pingidentity.com/en/signup.html>
<https://developer.pingidentity.com/en/signup.html>
<https://developer.pingidentity.com/en/signup.html>
<https://developer.pingidentity.com/en/signup.html?utm_source=email&utm_medium=P14C-Trial-Email&utm_campaign=P14C-Trial-Email&utm_content=link>
<https://developer.pingidentity.com/en/signup.html?utm_source=email&utm_medium=P14C-Trial-Email&utm_campaign=P14C-Trial-Email&utm_content=link>

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 7 May 2019 08:33:17 +0000

Hi Phil

I believe this is a question that William and John may be able to answer.

Should MTLS be added to a future version of the Native Apps BCP? If the answer is “no”, why not?

Ciao
Hannes

From: OAuth <[email-masked]> On Behalf Of Phil Hunt
Sent: Donnerstag, 2. Mai 2019 20:41
To: oauth <[email-masked]>
Subject: [OAUTH-WG] MTLS and Native apps Best practices

Phil Hunt | Cloud Security and Identity Architect
Oracle Corporation, Oracle Cloud Infrastructure
@independentid
www.independentid.com<http://www.independentid.com>
[email-masked]<mailto:[email-masked]>

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: John Bradley <[email-masked]>
Date: Tue, 7 May 2019 10:02:01 -0400

The mtls spec doesn't cover the authorization endpoint.

Mtls via the browser is a whole world of pain.

I believe that for a native app to use mtls via a chrome custom tab or
Safari view controller you need to provision a certificate and private key
to the system keystore.  It is not something that can happen dynamically
from the app.

That in practice is generally done by proprietary EMM (Enterprise Mobility
Management) systems like mobile Iron etc.

I think there are also some issues with the app using the same key, it may
need to be separately provisioned to the app as well.

Each OS and browser has its own twists.

It is probably better to explain how to do WebAuthn based authentication
via the browser and app.

I think there is likely more value in having a WebAuthn based
authentication of the app that also attests to the identity of the app than
trying to document all the implimented issues with MTLS via the browser.

It depends on what the working group thinks is important.

John B.

On Tue, May 7, 2019, 4:33 AM Hannes Tschofenig <[email-masked]>
wrote:

> *From:* OAuth <[email-masked]> *On Behalf Of *Phil Hunt
> *Sent:* Donnerstag, 2. Mai 2019 20:41
> *To:* oauth <[email-masked]>
> *Subject:* [OAUTH-WG] MTLS and Native apps Best practices
>
>
>
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
>

---

From: Phil Hunt <[email-masked]>
Date: Tue, 7 May 2019 11:25:53 -0700

Thanks John. This is what I suspected but wanted to confirm. 

Phil

> On May 7, 2019, at 7:02 AM, John Bradley <[email-masked]> wrote:
> 
> I believe that for a native app to use mtls via a chrome custom tab or Safari view controller you need to provision a certificate and private key to the system keystore.  It is not something that can happen dynamically from the app.
> 
> That in practice is generally done by proprietary EMM (Enterprise Mobility Management) systems like mobile Iron etc. 
> 
> I think there are also some issues with the app using the same key, it may need to be separately provisioned to the app as well.  
> 
> It is probably better to explain how to do WebAuthn based authentication via the browser and app.  
> 
> I think there is likely more value in having a WebAuthn based authentication of the app that also attests to the identity of the app than trying to document all the implimented issues with MTLS via the browser.
> 
>> On Tue, May 7, 2019, 4:33 AM Hannes Tschofenig <[email-masked]> wrote:
>> Hi Phil
>> 
>>  
>>

---

From: David Waite <[email-masked]>
Date: Wed, 8 May 2019 02:06:43 -0600

> On May 7, 2019, at 8:02 AM, John Bradley <[email-masked]> wrote:
> 

> That in practice is generally done by proprietary EMM (Enterprise Mobility Management) systems like mobile Iron etc. 

On iOS you can load a PKCS12 file or use SCEP. You can do so with static policies, but nobody does it that way - they use an EMM system. This really limits things to enterprise usage or value-added features for small businesses that use EMM management integrated into other products like GSuite.

> I think there are also some issues with the app using the same key, it may need to be separately provisioned to the app as well.  

On iOS, such certificates will be used by the system browser, but will not be used by an embedded web view or otherwise made available to applications. So, code flow and resource access MTLS using a client certificate at the system level is right out, unless some app-specific mechanism to negotiate a client key pair is used. Mobile apps on iOS will need to use ephemeral keys.

The client certificate may be used by the system browser to identify the device, so that the user authentication process can also verify that they are accessing from a device that meets corporate policy. So there’s precedent for a MTLS negotiation with the front channel being used for a different, non-PoP purpose. Not to say that enterprises wouldn’t prefer access be tied to a certificate they know was installed on the device and was requested to be non-exportable - there is just no standard way to do that today. Well, I suppose Kerberos.

-DW