[Cfrg] aPAKE Analysis / System-Level view / Is 2FA a relevant topic ? / Is aPAKE an optional addition to WebPKI or the main TLS authentication mechanism?

[Björn Haase <[e-mail]>]

Hi Natanael,

If I understand correctly, the procedures you suggest would be quite similar to what I had in mind. I was not actually be having any preference regarding the sequencing, but your reasoning regarding “First 2FA press, then password” convinces me.

I also had actually several possible options for merging aPAKE and 2FA the operations in mind. For instance for some 2FA applications today I use a token generator that outputs a 6-digit time-dependent code, seemingly based on some shared symmetric secret and the time.
If such a code would be the second factor, one could append it to the PRS string on both sides as additional low-entropy input from the 2FA channel. This avoids the need of further asymmetric crypto on both sides.

If you have a better 2FA token that allows for signatures, one could make it sign the session ID and send this to the server for signature verification.

I believe that there might be several options for integrating multi-factor-authentication in addition to aPAKE.
The crucial points however might rather be

  1.  Do we see the need to have the use-case of authentication for aPAKE + 2FA in addition to aPAKE alone in mind? (I’d say “YES!”)
  2.  Should we enforce the mutual aPAKE authentication (+ optional 2FA) *before* or *after* the first application payload traffic (e.g. the first html information)? Or should we consider aPAKE (+ optional 2FA) to be merely an optional step after establishing a conventional (WebPKI)-certificate authenticated session?

My perception is: For the aPAKE systems (+ optional 2FA) we should not at all be relying on Web-PKI. We should finish the (aPAKE + 2FA) step before opening the TLS channel for application data.

Others seem to advocate for a setting where aPAKE is used as an optional feature *addition* to a mandatory Web-PKI configuration. In this case, essential security component would still be based on WebPKI and aPAKE would be just an optional addition.

I don’ think that the latter option would be a good solution security-wise. I also don’t see, how the end-user should be finding out that the password that she enters into an html page field would actually be protected by aPAKE or sent in clear-text to the server.

aPAKE as add-on to WebPKI would also not serve our use-case where we precisely need a solution to the problem that the end-customer is not skilled enough for maintaining certificates in his browser and his IoT device (or would like to avoid the cost/effort for getting a domain name and maintained server certificate from a browser-trusted CA). A well-configured browser would just be preventing any connection due to the failed certificate validation.

@CFRG and @Nathanael: What is your position regarding the questions 1.) and 2.) above?

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: [phone] | Fax: [phone]
[e-mail] |  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: Cfrg <[e-mail]> Im Auftrag von Natanael
Gesendet: Dienstag, 24. September 2019 12:15
An: Björn Haase <[e-mail]>
Cc: IRTF CFRG <[e-mail]>
Betreff: Re: [Cfrg] aPAKE Analysis / Why System-Level-View


Den sön 22 sep. 2019 21:32Björn Haase <[e-mail]<mailto:[e-mail]>> skrev:

> Being able to trigger a PAKE from a button press on your 2FA hardware
> token would also be a significant UX improvement over many of the
> other options with similar security level.
>
Do I correctly understand that you had in mind: The user first
establishes a normal https:// connection and then presses the 2FA
hardware switch in order to run a PAKE in addition to the previous
certificate-based authentication?

Wouldn't have to be the default, but I'm considering a version of this;

If the server tells the client that it supports both hardware 2FA and PAKE, and that they are supported together (and this flag could be cached on the client so it can alert on downgrade), then yes.

It would perform HW 2FA auth on button press (may include certificates) and then trigger PAKE. The user types the password and hits OK. Done.


This is not what I assumed. What I had in mind is rather the following
procedure. The server knows its requirements regarding security, etc. .
The user and the browser don't know the required procedure in advance
when connecting. If the server is needing 2FA, it would arrange the
client to provide the aPAKE password entry mask and provide a "Please
press authentication token switch for authentication".

Did I actually mis-understand your post?

Your approach seems to be slightly different. So the browser first opens the PAKE prompt and you then verify with the token? Presumably the browser informs the user that the current webpage has PAKE support, they click to open the prompt, and confirm with HW 2FA verification?

While functionally similar, the difference is in the UX security.

With your approach one could more easily get the user password through phishing by showing them fake login prompts (and in a targeted attack, the token could then be stolen).

A user that has been successfully taught that the password must only be entered in the prompt after pressing the HW 2FA button will not type their password into phishing prompts.