Subject: [TLS] TLS 1.3 and certificate based authentication

From: Urmas Vanem <[email-masked]>
Date: Tue, 11 Jan 2022 10:47:00 +0000

Hello!

TLS 1.3 introduces post-handshake authentication. It relies on client/browser, client/browser must send post_handshake_auth extension to server before it can work. I hope I understood it correctly.
But today we know only Firefox from popular browsers support this extension (and not by default).

Question: How can I implement certificate based client authentication against web server in TLS 1.3 only environment, if browsers do not support post_handshake_auth extension.

I have open discussion with one big software company. Can you please share your opinion/recommendation here regarding to the issue?

Thanks in advance,

Urmas

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 14 Jan 2022 09:54:04 -0800

TLS 1.3 supports certificate-based client auth in the primary handshake.

-Ekr

On Fri, Jan 14, 2022 at 8:19 AM Urmas Vanem <[email-masked]> wrote:

> Hello!
>
>
>
> TLS 1.3 introduces post-handshake authentication. It relies on
> client/browser, client/browser must send post_handshake_auth extension to
> server before it can work. I hope I understood it correctly.
>
> Question: How can I implement certificate based client authentication
> against web server in TLS 1.3 only environment, if browsers do not support
> post_handshake_auth extension.
>
>
>
> I have open discussion with one big software company. Can you please share
> your opinion/recommendation here regarding to the issue?
>
>
>
> Thanks in advance,
>
>
>
> Urmas
>
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Andrei Popov <[email-masked]>
Date: Fri, 14 Jan 2022 20:23:53 +0000

Essentially, TLS 1.3 post-handshake authentication is analogous to client auth via renegotiation available with TLS <= 1.2.
An important difference is that TLS 1.3 post-handshake authentication is optional, and major browsers chose not to support it.

In practice, this means TLS server deployments and applications that rely on authenticating clients post-handshake have to change if they want to enable TLS 1.3.
These changes can include creating separate endpoints for client-authenticating services, and configuring those endpoints to perform client authentication during the handshake.

This affects a significant number of Microsoft customers, who have been using client auth support via renegotiation in IIS.
The typical scenario is: landing page without client authentication, then renegotiation with client auth if the user navigates to a protected resource on the page.
I recommend customers to work directly with browser vendors if they want TLS 1.3 post-handshake auth support. This is not a TLS 1.3 standard's limitation.

Cheers,

Andrei

From: TLS <[email-masked]> On Behalf Of Eric Rescorla
Sent: Friday, January 14, 2022 9:54 AM
To: Urmas Vanem <[email-masked]>
Cc: [email-masked]
Subject: [EXTERNAL] Re: [TLS] TLS 1.3 and certificate based authentication

-Ekr

On Fri, Jan 14, 2022 at 8:19 AM Urmas Vanem <[email-masked]<mailto:[email-masked]>> wrote:
Hello!

Thanks in advance,

Urmas

_______________________________________________
TLS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tls<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftls&data=04%7C01%7CAndrei.Popov%40microsoft.com%7Cb2bba7ba2abe443a7a9808d9d787029a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637777797645282331%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=%2FuoB5juM%2FxEOU7jezPgyRm6tTN0ChjPXAaAamARZoY0%3D&reserved=0>

---

From: Urmas Vanem <[email-masked]>
Date: Sun, 16 Jan 2022 15:29:11 +0000

Microsoft Windows Server 2022 supports post-handshake as default authentication method with TLS 1.3. It means, before we can use certificate base authentication with IIS and TLS 1.3 protocol, we must change default configuration from post-handshake authentication method to in-handshake authentication method. So, by default it affects all Microsoft customers who want to enable certificate based authentication with TLS 1.3 in IIS, because enabling certificate based authentication with TLS 1.3 leads us to err_connection_reset error.
IMHO this (post-handshake authentication method) is not correct default configuration in situation, where common browsers do not support post-handshake authentication (Firefox supports it, but it is disabled by default).

It is good to hear that post-handshake authentication method is optional and not preferred.

Thanks,

Urmas

From: Andrei Popov <[email-masked]>
Sent: Friday, January 14, 2022 10:24 PM
To: Eric Rescorla <[email-masked]>; Urmas Vanem <[email-masked]>
Cc: [email-masked]
Subject: RE: [EXTERNAL] Re: [TLS] TLS 1.3 and certificate based authentication

Cheers,

Andrei

From: TLS <[email-masked]<mailto:[email-masked]>> On Behalf Of Eric Rescorla
Sent: Friday, January 14, 2022 9:54 AM
To: Urmas Vanem <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [EXTERNAL] Re: [TLS] TLS 1.3 and certificate based authentication

-Ekr

Thanks in advance,

Urmas

---

From: Andrei Popov <[email-masked]>
Date: Wed, 19 Jan 2022 02:06:00 +0000

*   IMHO this (post-handshake authentication method) is not correct default configuration in situation, where common browsers do not support post-handshake authentication (Firefox supports it, but it is disabled by default).
TLS client authentication is off by default in IIS, but it is true that a lot of IIS deployments use it.

  *   It means, before we can use certificate base authentication with IIS and TLS 1.3 protocol, we must change default configuration from post-handshake authentication method to in-handshake authentication method.
Correct. Unfortunately, there is no way to automatically handle this in the general case, because the server does not know in advance which protected resource (if any) the user might choose on the landing page. The server cannot ask for the right client certificate in advance of the request for a protected resource.

Also, for TLS < 1.3, configuring TLS client authentication in the original handshake exposes client certificates in the clear, leaking client identities to the network observer.

Cheers,

Andrei

From: Urmas Vanem <[email-masked]>
Sent: Sunday, January 16, 2022 7:29 AM
To: Andrei Popov <[email-masked]>; Eric Rescorla <[email-masked]>
Cc: [email-masked]
Subject: RE: [EXTERNAL] Re: [TLS] TLS 1.3 and certificate based authentication

Thanks,

Urmas

From: Andrei Popov <[email-masked]<mailto:[email-masked]>>
Sent: Friday, January 14, 2022 10:24 PM
To: Eric Rescorla <[email-masked]<mailto:[email-masked]>>; Urmas Vanem <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [EXTERNAL] Re: [TLS] TLS 1.3 and certificate based authentication

Cheers,

Andrei

-Ekr

Thanks in advance,

Urmas

_______________________________________________
TLS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tls<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftls&data=04%7C01%7CAndrei.Popov%40microsoft.com%7C75277cb97bbd46cbdae908d9d904f410%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637779437923623660%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=bg7eBHb91vNSnvcfk8UymotT8EphnYLrgSO2%2FfGdfJw%3D&reserved=0>