[prev in list] [next in list] [prev in thread] [next in thread]
List: cfrg
Subject: Re: [Cfrg] How to circumvent the obstacles for PAKE integration into TLS // slides.
From: Björn Haase <bjoern.haase () endress ! com>
Date: 2019-08-28 11:04:47
Message-ID: VI1PR0501MB225513F74F687991E72F2D8183A30 () VI1PR0501MB2255 ! eurprd05 ! prod ! outlook ! com
[Download RAW message or body]
[Attachment #2 (text/plain)]
> 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.
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 | Germany
Phone: +49 7156 209 377 | Fax: +49 7156 209 221
bjoern.haase@endress.com | 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.
Von: Natanael <natanael.l@gmail.com>
Gesendet: Mittwoch, 28. August 2019 11:32
An: Hannes Tschofenig <Hannes.Tschofenig@arm.com>
Cc: Jonathan Trostle <jonattr@gmail.com>; Owen Friel (ofriel) <ofriel@cisco.com>; \
hugokraw@gmail.com; Björn Haase <bjoern.haase@endress.com>; CFRG \
<cfrg@irtf.org>
Betreff: Re: [Cfrg] How to circumvent the obstacles for PAKE integration into TLS // \
slides.
Den ons 7 aug. 2019 14:16Hannes Tschofenig \
<Hannes.Tschofenig@arm.com<mailto:Hannes.Tschofenig@arm.com>> 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.
[Attachment #3 (text/html)]
<html xmlns:v="urn:schemas-microsoft-com:vml" \
xmlns:o="urn:schemas-microsoft-com:office:office" \
xmlns:w="urn:schemas-microsoft-com:office:word" \
xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" \
xmlns="http://www.w3.org/TR/REC-html40"> <head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.E-MailFormatvorlage18
{mso-style-type:personal-reply;
font-family:"Arial",sans-serif;
color:black;
font-weight:normal;
font-style:normal;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;
mso-fareast-language:EN-US;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:70.85pt 70.85pt 2.0cm 70.85pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="DE" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span lang="EN-US">>The way I see it, combining a PAKE with a \
2FA solution like FIDO / WebAuthn is the best approach. <o:p></o:p></span></p> \
<p class="MsoNormal"><span lang="EN-US" \
style="font-size:10.0pt;font-family:"Arial",sans-serif;color:black;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" \
style="font-size:10.0pt;font-family:"Arial",sans-serif;color:black;mso-fareast-language:EN-US">This \
corresponds exactly to what I have had in mind when creating slide #13 of the \
slides<o:p></o:p></span></p> <p class="MsoNormal"><span lang="EN-US" \
style="font-size:10.0pt;font-family:"Arial",sans-serif;color:black;mso-fareast-language:EN-US"><a \
href="https://github.com/BjoernMHaase/fe25519/blob/master/Concept_For_Modularized_PAKE \
_integration_into_TLS_20190726.pdf">https://github.com/BjoernMHaase/fe25519/blob/maste \
r/Concept_For_Modularized_PAKE_integration_into_TLS_20190726.pdf</a><o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" \
style="font-size:10.0pt;font-family:"Arial",sans-serif;color:black;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" \
style="font-size:10.0pt;font-family:"Arial",sans-serif;color:black;mso-fareast-language:EN-US">However, \
the bootstrapping use-case that Hannes refers to is also an important application \
IMO. (Slide #14).<o:p></o:p></span></p> <p class="MsoNormal"><span lang="EN-US" \
style="font-size:10.0pt;font-family:"Arial",sans-serif;color:black;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" \
style="font-size:10.0pt;font-family:"Arial",sans-serif;color:black;mso-fareast-language:EN-US">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.<o:p></o:p></span></p> <p \
class="MsoNormal"><span lang="EN-US" \
style="font-size:10.0pt;font-family:"Arial",sans-serif;color:black;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" \
style="font-size:10.0pt;font-family:"Arial",sans-serif;color:black;mso-fareast-language:EN-US">For \
your reference here are the slides that I will be presenting today at \
Atlanta.<o:p></o:p></span></p> <p class="MsoNormal"><span lang="EN-US" \
style="font-size:10.0pt;font-family:"Arial",sans-serif;color:black;mso-fareast-language:EN-US"><a \
href="https://github.com/BjoernMHaase/fe25519/blob/master/Presentation_CHES2019.pdf">h \
ttps://github.com/BjoernMHaase/fe25519/blob/master/Presentation_CHES2019.pdf</a><o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" \
style="font-size:10.0pt;font-family:"Arial",sans-serif;color:black;mso-fareast-language:EN-US">There \
I have also added some slides dealing my opinions regarding the session id complexity \
that comes with OPAQUE and AuCPace.<o:p></o:p></span></p> <p class="MsoNormal"><span \
lang="EN-US" style="font-size:10.0pt;font-family:"Arial",sans-serif;color:black;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" \
style="font-size:10.0pt;font-family:"Arial",sans-serif;color:black;mso-fareast-language:EN-US">Yours,<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" \
style="font-size:10.0pt;font-family:"Arial",sans-serif;color:black;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" \
style="font-size:10.0pt;font-family:"Arial",sans-serif;color:black;mso-fareast-language:EN-US">Björn.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" \
style="font-size:10.0pt;font-family:"Arial",sans-serif;color:black;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><b>Von:</b> Natanael <natanael.l@gmail.com> <br>
<b>Gesendet:</b> Mittwoch, 28. August 2019 11:32<br>
<b>An:</b> Hannes Tschofenig <Hannes.Tschofenig@arm.com><br>
<b>Cc:</b> Jonathan Trostle <jonattr@gmail.com>; Owen Friel (ofriel) \
<ofriel@cisco.com>; hugokraw@gmail.com; Björn Haase \
<bjoern.haase@endress.com>; CFRG <cfrg@irtf.org><br> <b>Betreff:</b> Re: \
[Cfrg] How to circumvent the obstacles for PAKE integration into TLS // \
slides.<o:p></o:p></p> <p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">Den ons 7 aug. 2019 14:16Hannes Tschofenig <<a \
href="mailto:Hannes.Tschofenig@arm.com" \
target="_blank">Hannes.Tschofenig@arm.com</a>> skrev:<o:p></o:p></p> </div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm \
6.0pt;margin-left:4.8pt;margin-right:0cm"> <div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span \
lang="EN-GB">Here are my 5 cents:<o:p></o:p></span></p> <p class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="EN-GB">I don't \
expect PAKEs to be used for web-based scenarios as a replacement for passwords used \
in web-based applications. <o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span \
lang="EN-GB">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.<o:p></o:p></span></p> <p \
class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span \
lang="EN-GB">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â¦<o:p></o:p></span></p> </div>
</div>
</blockquote>
</div>
<div>
<p class="MsoNormal">We just got Facebook declaring interest in using OPAQUE or \
equivalent PAKE protocols, which is significant. <o:p></o:p></p> </div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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;<o:p></o:p></p> </div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">The way I see it, combining a PAKE with a 2FA solution like FIDO \
/ WebAuthn is the best approach. <o:p></o:p></p> </div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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! <o:p></o:p></p> </div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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!). <o:p></o:p></p> \
</div> <div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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). <o:p></o:p></p> </div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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. <o:p></o:p></p> </div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Arial",sans-serif">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. </span><o:p></o:p></p> </div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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).<o:p></o:p></p> \
</div> <div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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. <o:p></o:p></p> </div>
<div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm \
6.0pt;margin-left:4.8pt;margin-right:0cm"> <div>
<div>
<div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm \
6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt"> <p \
class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span \
lang="EN-GB"><o:p> </o:p></span></p> </blockquote>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
<P><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: arial, helvetica, sans-serif"><BR>Mit \
freundlichen Grüßen I Best Regards </SPAN></P> <P><SPAN style="FONT-SIZE: \
10pt; FONT-FAMILY: arial, helvetica, sans-serif">Dr. Björn Haase </SPAN></P> <HR \
width="550" SIZE="1" align="left"> <SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: arial, \
helvetica, sans-serif">Senior Expert Electronics | TGREH Electronics \
Hardware<BR>Endress+Hauser Conducta GmbH+Co.KG | Dieselstrasse 24 | 70839 Gerlingen | \
Germany<BR>Phone: +49 7156 209 377 | Fax: +49 7156 209 \
221<BR>bjoern.haase@endress.com | www.conducta.endress.com <BR><BR></SPAN><hr> \
<p><span style="font-family: Arial; font-size: small;">Endress+Hauser Conducta \
GmbH+Co.KG<br>Amtsgericht Stuttgart HRA 201908<br>Sitz der Gesellschaft: \
Gerlingen<br>Persönlich haftende Gesellschafterin:<br>Endress+Hauser \
Conducta<br>Verwaltungsgesellschaft mbH<br>Sitz der Gesellschaft: \
Gerlingen<br>Amtsgericht Stuttgart HRA 201929<br>Geschäftsführer: Dr. \
Manfred Jagiella<br></span></p> <hr>
<p><span style="font-family: arial,helvetica,sans-serif; font-size: \
10pt;">Gemäss Datenschutzgrundverordnung sind wir verpflichtet, Sie zu \
informieren, wenn wir personenbezogene Daten von Ihnen erheben.</span></p> <p><span \
style="font-family: arial,helvetica,sans-serif; font-size: 10pt;">Dieser \
Informationspflicht kommen wir mit folgendem <a rel="noopener" target="_blank" \
href="https://www.de.endress.com/de/cookies-endress+hauser-website">Datenschutzhinweis</a> \
nach.</span></p> <hr>
<p> </p><p><span style="font-family: Arial; font-size: 10pt;">Disclaimer: \
</span></p> <p><span style="font-family: Arial; font-size: 10pt;">The information \
transmitted is intended only for the person or entity to which it is addressed and \
may contain confidential, proprietary, and/or privileged<br>material. Any review, \
retransmission, dissemination or other use of, or taking of any action in reliance \
upon, this information by persons or entities<br>other than the intended recipient is \
prohibited. If you receive this in error, please contact the sender and delete the \
material from any computer.<br>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.</span></p> <p> </p></body>
</html>
_______________________________________________
Cfrg mailing list
Cfrg@irtf.org
https://www.irtf.org/mailman/listinfo/cfrg
--===============7176048751282563432==--
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic