Re: [Cfrg] My review of the four PAKEs

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

Dear Scott,

thank you for your careful review. I agree with all of your assessments. 

Specifically I agree that for the use-case of a direct integration of an augmented PAKE 
into TLS 1.3, OPAQUE is better. The feature that OPAQUE requires one round-trip less 
than AuCPace might outweight the single practical disadvantage that I see (the *large* 
size of password verifiers) in many scenarios.

Still from a system-level architecture point of view, I believe that there could be 
applications, where too neatly integrating the human-user related mechanisms into 
a transport-layer level component such as TLS might generate headaches.

I still would like to suggest to consider/discuss the following points.

- The augmented PAKE use-case is in my opinion directly linked to human 
  end-user authentication. This is different from the case for balanced 
  PAKE, where I also see the application of machine-machine interfaces.
  
- This means that a TLS subsystem using OPAQUE might have to maintain a
  quite close and possibly intricate link to software components that a)
  maintain the user credential database and b) the applications that
  use the TLS channel.
  For instance, TLS would have to provide interfaces to the application
  on the server side for retrieving the information which user has 
  successfully logged in.
  
- For many applications, I also see the need of a lot of flexibility.
  Sometimes users might not want to enter passwords but use
  Security tokens alone.
  Others would like to use username/passwords, and possibly
  TLS with OPAQUE.
  Other might require supporting two-factor  authentication 
  (TFA, username/password + security hardware).
  Managing all of these 3 settings while maintaining the same software-level
  structure might require not only require TLS cipher suites for OPAQUE but also
  TLS OPAQUE+Security-Token and TLS-Security-Token.
  Possibly for TLS this could result in a complexity that is no
  longer practical.
  
- I also see some unsolved issues for applications that need to migrate an 
  existing user-credential database to OPAQUE.

My personal assessment is that too closely integrating human user-interface
related complexity into a component such as TLS might generate trouble ?.

Here I see advantages for a more modular approach, as I had also tried to 
sketch in:

https://github.com/BjoernMHaase/fe25519/blob/master/Concept_For_Modularized_PAKE_integration_into_TLS_20190726.pdf

Basically the idea is to try to keep the intricate complexity of human 
user-related API interfaces away from the transport-layer components such 
as TLS. Instead TLS would be focusing on the transport-layer aspects and
the intricate human-user interfaces would be integrated into software modules
external to TLS, e.g. in the style of PAM on Linux.

Of course there is the risk of integrating insecure options (e.g. the EAP approach
might be overly flexible). On the other hand if we are too restrictive/monolithic,
we might not be serving important use-cases.

In my opinion the considerations regarding internal software APIs and
the respective scope/responsibilities of software components such as 
TLS / QUIC / PAM would benefit from discussions with people also from 
outside the typical CFRG team.

I believe that at the end of the discussion involving the system architects
for components such as PAM, there might be applications that are actually 
better served by the a more modular approach such as AuCPace.?

I have already tried to enter a discussion with the PAM people, but did not yet
receive any feedback. Maybe some other people on the CFRG list have such
contacts or suggestions regarding this topic.

Maybe somebody else on this list might have an idea on how to get into
discussion with people that have the "system-level" and "os architecture level" 
hat on.

Yours,

Björn.


Mit freundlichen Grüßen I Best Regards 

Dr. Björn Haase 


Senior Expert Electronics | TGREH Electronics Hardware
Endress+Hauser Liquid Analysis

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 Scott Fluhrer (sfluhrer)
Gesendet: Dienstag, 25. Februar 2020 21:46
An: [e-mail]
Betreff: [Cfrg] My review of the four PAKEs

Summary of my vote: Balanced PAKE: CPace; Augmented PAKE: OPAQUE ...