Subject: Re: [Cfrg] How to circumvent the obstacles for PAKE integration into TLS // slides.

From: Jonathan Trostle <[email-masked]>
Date: Tue, 6 Aug 2019 21:29:16 -0700

A good future goal is to eliminate plaintext passwords being sent over TLS.

So a future TLS implementation based on a config setting, could abort a TLS
handshake if there is no preshared key authentication or certificate verify
sent by the client. It seems the OPAQUE-sign option (in the TLS Opaque
draft) supports this but the Exported Authenticators do not.

It seems difficult for a TLS client to know which of Exported
Authenticators with OPAQUE or plaintext password over TLS is being used.

Best regards,
Jonathan

On Tue, Jul 23, 2019 at 8:29 AM Owen Friel (ofriel) <[email-masked]>
wrote:

> Björn,
>
> Its worth reading
> https://datatracker.ietf.org/doc/draft-sullivan-tls-opaque  which Nick
> presented at 104:
> https://datatracker.ietf.org/meeting/104/materials/slides-104-tls-slides-ietf104-tls-opaque-00.
> It covers both OPAQUE in the TLS handshake, and OPAQUE via Exported
> Authenticators
> https://datatracker.ietf.org/doc/draft-ietf-tls-exported-authenticator/
> at some point after TLS handshake has taken place. Its currently OPAQUE
> specific, but the EA model could probably be applied to other PAKEs. And
> finally,
> https://datatracker.ietf.org/doc/draft-ietf-httpbis-http2-secondary-certs/
> covers how to use EA with HTTP2.
>
> Owen
>
> -----Original Message-----
> From: Cfrg <[email-masked]> On Behalf Of Björn Haase
> Sent: 23 July 2019 08:43
> To: Benjamin Kaduk <[email-masked]>; Watson Ladd <[email-masked]>
> Cc: CFRG <[email-masked]>; [email-masked]
> Subject: Re: [Cfrg] How to circumvent the obstacles for PAKE integration
> into TLS // slides.
>
> Dear Ben,
>
> >To build on that, a big motivation for wanting auth at the HTTP layer
> >is that most generic web servers aren't going to know *at TLS handshake
> >time* whether a given client is going to need to authenticate for the
> >HTTP requests that will subsequently be conveyed over that connection.
>
> I fully agree. When saying this, I think that we might better be careful
> not to mix-up two aspects:
>
> 1) The human at the client side mostly wants to be sure that the server
> side contents are authentic, from the very beginning.
> 2) The server side requires authentication often only when operations with
> privileges are requested.
>
> What we have here is something similar to what I'd be calling
> "re-authentication use-case" for password checks in a connection that is
> already established.
>
> Moreover I see differences regarding the use-cases A
> "End-customer-managed web servers (IoT)" and  B "Conventional Web-Shop
> use-cases (Web-PKI)". The main additional benefit of PAKE for use-case A is
> that the server-authentication (1.) above) is provided also without the
> need of Web-PKI integration of the server.
>
> I think that one might best try to realize the maximum possible re-use for
> authentication mechanisms in both use-cases A/B. Again this might be a
> reason for "outsourcing" all of the user-handling related stuff outside of
> the main TLS body. Also for use case "B" it might be worth to consider
> pulling out the password handling out from the main html application. Maybe
> one could use the same mechanisms of a "user authentication" module that we
> would be using for PAKE? For doing so again some kind of channel-linked
> tunnel mechanism through TLS might be helpful/necessary.
>
> Yours,
>
> Björn.
>
> P.S.: I have moved this discussion back to the main list. Sorry for
> starting this discussion with the "not yet publication-ready" slides.
>
>
> Mit freundlichen Grüßen I Best Regards
>
> Dr. Björn Haase
>
> Senior Expert Electronics | TGREH Electronics Hardware
> Endress+Hauser Conducta GmbH+Co.KG | Dieselstrasse 24 | 70839 Gerlingen
> Endress+| Germany
> Phone: +49 7156 209 377 | Fax: +49 7156 209 221 [email-masked]
> |  www.conducta.endress.com
>
>
>
> Endress+Hauser Conducta GmbH+Co.KG
> Amtsgericht Stuttgart HRA 201908
> Sitz der Gesellschaft: Gerlingen
> Persönlich haftende Gesellschafterin:
> Endress+Hauser Conducta Verwaltungsgesellschaft mbH
> Sitz der Gesellschaft: Gerlingen
> Amtsgericht Stuttgart HRA 201929
> Geschäftsführer: Dr. Manfred Jagiella
>
>
> Gemäss Datenschutzgrundverordnung sind wir verpflichtet, Sie zu
> informieren, wenn wir personenbezogene Daten von Ihnen erheben.
> Dieser Informationspflicht kommen wir mit folgendem Datenschutzhinweis (
> https://www.endress.com/de/cookies-endress+hauser-website) nach.
>
>
>
> Disclaimer:
>
> The information transmitted is intended only for the person or entity to
> which it is addressed and may contain confidential, proprietary, and/or
> privileged material. Any review, retransmission, dissemination or other use
> of, or taking of any action in reliance upon, this information by persons
> or entities other than the intended recipient is prohibited. If you receive
> this in error, please contact the sender and delete the material from any
> computer. This e-mail does not constitute a contract offer, a contract
> amendment, or an acceptance of a contract offer unless explicitly and
> conspicuously designated or stated as such.
>
> _______________________________________________
> Cfrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/cfrg
> _______________________________________________
> Cfrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/cfrg
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 7 Aug 2019 12:15:16 +0000

Here are my 5 cents:

I don’t expect PAKEs to be used for web-based scenarios as a replacement for passwords used in web-based applications.
Instead, the only use of PAKEs I had seen over the last few years was in the area of IoT as part of onboarding mechanisms.

Unless those folks developing browsers tell me that they want to put PAKEs into their browsers I would focus on the IoT use cases instead. The reason why I am saying this is because FIDO, which also tackles the password problem, looks like a much, much more promising route…

Ciao
Hannes

From: Cfrg <[email-masked]> On Behalf Of Jonathan Trostle
Sent: Mittwoch, 7. August 2019 06:29
To: Owen Friel (ofriel) <[email-masked]>
Cc: Björn Haase <[email-masked]>; CFRG <[email-masked]>; [email-masked]
Subject: Re: [Cfrg] How to circumvent the obstacles for PAKE integration into TLS // slides.

So a future TLS implementation based on a config setting, could abort a TLS handshake if there is no preshared key authentication or certificate verify sent by the client. It seems the OPAQUE-sign option (in the TLS Opaque draft) supports this but the Exported Authenticators do not.

It seems difficult for a TLS client to know which of Exported Authenticators with OPAQUE or plaintext password over TLS is being used.

Best regards,
Jonathan

On Tue, Jul 23, 2019 at 8:29 AM Owen Friel (ofriel) <[email-masked]<mailto:[email-masked]>> wrote:
Björn,

Its worth reading https://datatracker.ietf..org/doc/draft-sullivan-tls-opaque<https://datatracker.ietf.org/doc/draft-sullivan-tls-opaque>  which Nick presented at 104: https://datatracker.ietf.org/meeting/104/materials/slides-104-tls-slides-ietf104-tls-opaque-00. It covers both OPAQUE in the TLS handshake, and OPAQUE via Exported Authenticators https://datatracker.ietf.org/doc/draft-ietf-tls-exported-authenticator/ at some point after TLS handshake has taken place. Its currently OPAQUE specific, but the EA model could probably be applied to other PAKEs. And finally, https://datatracker.ietf..org/doc/draft-ietf-httpbis-http2-secondary-certs/<https://datatracker.ietf.org/doc/draft-ietf-httpbis-http2-secondary-certs/> covers how to use EA with HTTP2.

Owen

-----Original Message-----
From: Cfrg <[email-masked]<mailto:[email-masked]>> On Behalf Of Björn Haase
Sent: 23 July 2019 08:43
To: Benjamin Kaduk <[email-masked]<mailto:[email-masked]>>; Watson Ladd <[email-masked]<mailto:[email-masked]>>
Cc: CFRG <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Cfrg] How to circumvent the obstacles for PAKE integration into TLS // slides.

Dear Ben,

>HTTP requests that will subsequently be conveyed over that connection.

I fully agree. When saying this, I think that we might better be careful not to mix-up two aspects:

1) The human at the client side mostly wants to be sure that the server side contents are authentic, from the very beginning.
2) The server side requires authentication often only when operations with privileges are requested.

What we have here is something similar to what I'd be calling "re-authentication use-case" for password checks in a connection that is already established.

Moreover I see differences regarding the use-cases A  "End-customer-managed web servers (IoT)" and  B "Conventional Web-Shop use-cases (Web-PKI)". The main additional benefit of PAKE for use-case A is that the server-authentication (1.) above) is provided also without the need of Web-PKI integration of the server.

I think that one might best try to realize the maximum possible re-use for authentication mechanisms in both use-cases A/B. Again this might be a reason for "outsourcing" all of the user-handling related stuff outside of the main TLS body. Also for use case "B" it might be worth to consider pulling out the password handling out from the main html application. Maybe one could use the same mechanisms of a "user authentication" module that we would be using for PAKE? For doing so again some kind of channel-linked tunnel mechanism through TLS might be helpful/necessary.

Yours,

Björn.

P.S.: I have moved this discussion back to the main list. Sorry for starting this discussion with the "not yet publication-ready" slides.

Dr. Björn Haase

Senior Expert Electronics | TGREH Electronics Hardware
Endress+Hauser Conducta GmbH+Co.KG | Dieselstrasse 24 | 70839 Gerlingen
Endress+| Germany
Phone: +49 7156 209 377 | Fax: +49 7156 209 221 [email-masked]<mailto:[email-masked]> |  www.conducta.endress.com<http://www.conducta.endress.com>

Gemäss Datenschutzgrundverordnung sind wir verpflichtet, Sie zu informieren, wenn wir personenbezogene Daten von Ihnen erheben.
Dieser Informationspflicht kommen wir mit folgendem Datenschutzhinweis (https://www.endress.com/de/cookies-endress+hauser-website) nach.

Disclaimer:

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you receive this in error, please contact the sender and delete the material from any computer. This e-mail does not constitute a contract offer, a contract amendment, or an acceptance of a contract offer unless explicitly and conspicuously designated or stated as such.

_______________________________________________
Cfrg mailing list
[email-masked]<mailto:[email-masked]>
https://www.irtf.org/mailman/listinfo/cfrg
_______________________________________________
Cfrg mailing list
[email-masked]<mailto:[email-masked]>
https://www.irtf.org/mailman/listinfo/cfrg
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: "Salz, Rich" <[email-masked]>
Date: Wed, 7 Aug 2019 12:38:33 +0000

>Unless those folks developing browsers tell me that they want to put PAKEs into their browsers I would focus on the IoT use cases instead.

Strongly agree.  It is too bad that four dev groups effectively control what technology is used on the web, but there ya go.

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 07 Aug 2019 22:54:13 +1000

FWIW, as a browser, these "iot" cases - enrollment and the like - are more what motivate us than the augmented ones. For example, we're interested in using low entropy values in pairing new browser instances, and setting up debugging sessions with things like VR/AR headsets, which have limited interfaces. 

On Wed, Aug 7, 2019, at 22:15, Hannes Tschofenig wrote:
>  
> Here are my 5 cents: 
> 
> 
> I don’t expect PAKEs to be used for web-based scenarios as a 
> replacement for passwords used in web-based applications. 
> 
> Instead, the only use of PAKEs I had seen over the last few years was 
> in the area of IoT as part of onboarding mechanisms.
> 
> 
> Unless those folks developing browsers tell me that they want to put 
> PAKEs into their browsers I would focus on the IoT use cases instead. 
> The reason why I am saying this is because FIDO, which also tackles the 
> password problem, looks like a much, much more promising route…
> 
> 
> Ciao
> 
> Hannes
> 
> 
> *From:* Cfrg <[email-masked]> *On Behalf Of *Jonathan Trostle
> *Sent:* Mittwoch, 7. August 2019 06:29
> *To:* Owen Friel (ofriel) <[email-masked]>
> *Cc:* Björn Haase <[email-masked]>; CFRG <[email-masked]>; 
> [email-masked]
> *Subject:* Re: [Cfrg] How to circumvent the obstacles for PAKE 
> integration into TLS // slides.
> 
> 
>  So a future TLS implementation based on a config setting, could abort 
> a TLS handshake if there is no preshared key authentication or 
> certificate verify sent by the client. It seems the OPAQUE-sign option 
> (in the TLS Opaque draft) supports this but the Exported Authenticators 
> do not.
> 
> On Tue, Jul 23, 2019 at 8:29 AM Owen Friel (ofriel) <[email-masked]> wrote:
> 
> > Björn, 
> > 
> >  Its worth reading  https://datatracker.ietf..org/doc/draft-sullivan-tls-opaque <https://datatracker.ietf.org/doc/draft-sullivan-tls-opaque> which Nick presented at 104:  https://datatracker.ietf.org/meeting/104/materials/slides-104-tls-slides-ietf104-tls-opaque-00. It covers both OPAQUE in the TLS handshake, and OPAQUE via Exported Authenticators  https://datatracker.ietf.org/doc/draft-ietf-tls-exported-authenticator/ at some point after TLS handshake has taken place. Its currently OPAQUE specific, but the EA model could probably be applied to other PAKEs. And finally,  https://datatracker.ietf..org/doc/draft-ietf-httpbis-http2-secondary-certs/ <https://datatracker.ietf.org/doc/draft-ietf-httpbis-http2-secondary-certs/> covers how to use EA with HTTP2.
> > 
> >  Owen
> > 
> >  Phone: +49 7156 209 377 | Fax: +49 7156 209 221  [email-masked] |  www.conducta.endress.com 
> > 
> > 
> > 
>  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: Eric Rescorla <[email-masked]>
Date: Mon, 12 Aug 2019 01:50:03 -0700

On Wed, Aug 7, 2019 at 5:39 AM Salz, Rich <[email-masked]> wrote:

> *>*Unless those folks developing browsers tell me that they want to put
> Strongly agree.  It is too bad that four dev groups effectively control
> what technology is used on the web, but there ya go.
>

While I certainly wouldn't deny that the browser makers have a lot of
influence here, the issue is as much as anything the interest level that
*sites* have in this kind of technology, and that seems to be moving much
more towards WebAuthN than PAKE.

-Ekr

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 12 Aug 2019 17:00:36 +0000

*   While I certainly wouldn't deny that the browser makers have a lot of influence here, the issue is as much as anything the interest level that *sites* have in this kind of technology, and that seems to be moving much more towards WebAuthN than PAKE.

If all you have is a hammer…

Hannes said IOT would really like this.  Does that mean a browser is going to support it?

---

From: Natanael <[email-masked]>
Date: Wed, 28 Aug 2019 11:31:30 +0200

Den ons 7 aug. 2019 14:16Hannes Tschofenig <[email-masked]>
skrev:

> Here are my 5 cents:
>
> I don’t expect PAKEs to be used for web-based scenarios as a replacement
> for passwords used in web-based applications.
>
> Instead, the only use of PAKEs I had seen over the last few years was in
> the area of IoT as part of onboarding mechanisms.
>
> Unless those folks developing browsers tell me that they want to put PAKEs
> into their browsers I would focus on the IoT use cases instead. The reason
> why I am saying this is because FIDO, which also tackles the password
> problem, looks like a much, much more promising route…
>
We just got Facebook declaring interest in using OPAQUE or equivalent PAKE
protocols, which is significant.

And I also think (in my layman's opinion) that this should be supported in
browsers so websites can use it. I've written this once before;

The way I see it, combining a PAKE with a 2FA solution like FIDO / WebAuthn
is the best approach.

It's infinitely more resistant to both phishing and to accidental harm.
Compared to just adding a second factor which would still expose the
password, you don't just devalue credential phishing attempts when
combining U2F + PAKE, you can make it close to impossible.

FIDO 2FA by itself doesn't really "tackle the password problem". It "just"
adds a very strong shield *behind* it (but not in front of it). You still
risk leaking passwords, and password reuse isn't going away no matter how
much we try, people will remain lazy and reuse them. And not every site
will use 2FA!

While it's true that a PAKE can't protect a weak password if the server
gets breached (dictionary or bruteforce guessing), it can however protect
against a hacker spying on your strong passwords when they hack a site you
use! So under PAKE, your strong passwords remain strong even if the
adversary can manipulate the server, and they won't be able to test reusing
then against other services (at least assuming replay attack protection in
the protocol!).

A secondary and less common risk (yet real) is spearphishing, where
somebody is willing to steal your token and test reused passwords against
the target web service(s).

Pushing for widespread PAKE support (with dictionary attack resistance) to
resist password leaks is far more effective. One could hope that training
users to expect a browser initiated PAKE password entry would make them
suspicious of plaintext credential phishing forms.

I envision an approach where the user first types their username (which the
browser can remember), get asked to confirm their login attempt with their
hardware 2FA token (button press, or TPM connected secure input), and then
they get a secure PAKE prompt from the browser that asks the user to type
their password / PIN. After both U2F and PAKE has successfully
authenticated the user, they get logged in.

The browser's PAKE prompt may even be integrated with a password manager,
so you only need to click OK after you have unlocked your password manager.

U2F even supports registering keypair on the hardware token which allow you
to login without typing your username (requires using storage space on the
token), making it even simpler (press the button, type a PIN).

So the simplest secure login ux flow would be to unlock the password
manager once with your password, then login to a website by tapping the
hardware token's input button, then (optionally, can be automated) confirm
your password input.

---

From: Björn Haase <[email-masked]>
Date: Wed, 28 Aug 2019 11:04:47 +0000

>The way I see it, combining a PAKE with a 2FA solution like FIDO / WebAuthn is the best approach.

This corresponds exactly to what I have had in mind when creating slide #13 of the slides
https://github.com/BjoernMHaase/fe25519/blob/master/Concept_For_Modularized_PAKE_integration_into_TLS_20190726.pdf

However, the bootstrapping use-case that Hannes refers to is also an important application IMO. (Slide #14).

My perception that in order to allow for integrating use-cases such as 2FA into TLS, we might better need a modular approach. This is the main advantages that I see for AuCPace in comparison to OPAQUE or VTBPEKE. Otherwise OPAQUE and VTBPEKE are decent and secure constructions in my opinion.

For your reference here are the slides that I will be presenting today at Atlanta.
https://github.com/BjoernMHaase/fe25519/blob/master/Presentation_CHES2019.pdf
There I have also added some slides dealing my opinions regarding the session id complexity that comes with OPAQUE and AuCPace.

Yours,

Björn.

Dr. Björn Haase 

Senior Expert Electronics | TGREH Electronics Hardware
Endress+Hauser Conducta GmbH+Co.KG | Dieselstrasse 24 | 70839 Gerlingen | Germany
Phone: +49 7156 209 377 | Fax: +49 7156 209 221
[email-masked] |  www.conducta.endress.com 

Disclaimer: 

Von: Natanael <[email-masked]>
Gesendet: Mittwoch, 28. August 2019 11:32
An: Hannes Tschofenig <[email-masked]>
Cc: Jonathan Trostle <[email-masked]>; Owen Friel (ofriel) <[email-masked]>; [email-masked]; Björn Haase <[email-masked]>; CFRG <[email-masked]>
Betreff: Re: [Cfrg] How to circumvent the obstacles for PAKE integration into TLS // slides.

Den ons 7 aug. 2019 14:16Hannes Tschofenig <[email-masked]<mailto:[email-masked]>> skrev:
Here are my 5 cents:
I don’t expect PAKEs to be used for web-based scenarios as a replacement for passwords used in web-based applications.
Instead, the only use of PAKEs I had seen over the last few years was in the area of IoT as part of onboarding mechanisms.
Unless those folks developing browsers tell me that they want to put PAKEs into their browsers I would focus on the IoT use cases instead. The reason why I am saying this is because FIDO, which also tackles the password problem, looks like a much, much more promising route…
We just got Facebook declaring interest in using OPAQUE or equivalent PAKE protocols, which is significant.

And I also think (in my layman's opinion) that this should be supported in browsers so websites can use it. I've written this once before;

The way I see it, combining a PAKE with a 2FA solution like FIDO / WebAuthn is the best approach.

It's infinitely more resistant to both phishing and to accidental harm. Compared to just adding a second factor which would still expose the password, you don't just devalue credential phishing attempts when combining U2F + PAKE, you can make it close to impossible.

FIDO 2FA by itself doesn't really "tackle the password problem". It "just" adds a very strong shield *behind* it (but not in front of it). You still risk leaking passwords, and password reuse isn't going away no matter how much we try, people will remain lazy and reuse them. And not every site will use 2FA!

While it's true that a PAKE can't protect a weak password if the server gets breached (dictionary or bruteforce guessing), it can however protect against a hacker spying on your strong passwords when they hack a site you use! So under PAKE, your strong passwords remain strong even if the adversary can manipulate the server, and they won't be able to test reusing then against other services (at least assuming replay attack protection in the protocol!).

A secondary and less common risk (yet real) is spearphishing, where somebody is willing to steal your token and test reused passwords against the target web service(s).

Pushing for widespread PAKE support (with dictionary attack resistance) to resist password leaks is far more effective. One could hope that training users to expect a browser initiated PAKE password entry would make them suspicious of plaintext credential phishing forms.

I envision an approach where the user first types their username (which the browser can remember), get asked to confirm their login attempt with their hardware 2FA token (button press, or TPM connected secure input), and then they get a secure PAKE prompt from the browser that asks the user to type their password / PIN. After both U2F and PAKE has successfully authenticated the user, they get logged in.

The browser's PAKE prompt may even be integrated with a password manager, so you only need to click OK after you have unlocked your password manager.

U2F even supports registering keypair on the hardware token which allow you to login without typing your username (requires using storage space on the token), making it even simpler (press the button, type a PIN).

So the simplest secure login ux flow would be to unlock the password manager once with your password, then login to a website by tapping the hardware token's input button, then (optionally, can be automated) confirm your password input.