Re: [Cfrg] aPAKE Analysis / Why System-Level-View

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

Dear Jonathan, Dear Hugo,

> Hugo Krawcyzk wrote:
>Jonathan, I have not looked into making OPAQUE quantum annoying …

In my perception we should probably not make the mistake of over-estimating the risk of quantum-computing attacks. In my opinion when considering passwords the primary target would be to avoid the obvious known pitfalls. I don’t believe that the fact that OPAQUE is not “quantum annoying” would be any big problem in the real world setting.

In my opinion the key question to structure the future selection process might be that we don’t yet have a common
“system-level view” of the applications that would use PAKE. Most surely there is also not one type of “system” which
would like to use aPAKE.

OPAQUE will make integration into TLS somewhat easier, but I believe that integration of TLS-OPAQUE on the system-level into systems that are dealing with user credential database maintenance, password changes, user-authorization-level changes, user management, etc.
might be quite difficult.

My key questions today are for instance:

  1.  How could I neatly integrate TLS-PAKE with PAM on Linux.
  2.  How could I keep the pitfalls of security away from the normal application developpers.

In my opinion this would best require the feature of a message tunnel for “security subsystems” operating on both sides of the link in addition to the “application”’s payload channel. We would be having today’s application “TCP-like” channel and in addition the possibility to exchange messages between the security-subsystems. This is possibly a somewhat a larger change in TLS, but might be very helpful for neat integration on the system levels.

So in my opinion it’s not only the TLS-Designer perspective which needs to be considered but also the larger perspective of the system. In my opinion the situation for aPAKE is way more complex than for balanced PAKE. I believe that we don’t yet have a common understanding regarding the system level.

In my opinion we also should consider the use-case of “PASSWORD + second-factor” for TLS authentication where the password is protected by PAKE.

@Hugo: It seems that you had primarily use-cases in mind, where one specific secure channel is needed. E.g. for securing a remote VPN access by some user in its home environment? In this case neat integration with PAKE into systems such as PAM might not be the primary target and a simpler “TLS-only” approach will be the best solution with a separate application-specific user-credential database.

@CFRG: I’d appreciate your opinion regarding the system level view. Should we consider integration into systems like PAM or ActiveDirectory databases as important use-case or is our focus rather a “stand-alone” type of system with a small specific database for aPAKE.

Regarding the aPAKE protocols. In my opinion we have very good nominations which all meet (or could be made to meet) the important security targets. The question that I believe to be decisive is the “system view” that employs aPAKE as a subcomponent. Here I see different possible models and advantages and drawbacks of the different nominations.

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.