Re: [Cfrg] CPace feedback regarding the identity handling

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

Dear Hao,

Regarding your remark regarding the structure of the channel identifier, the device Identities A, B were not meant to be memorized or typed by the end user by us but are meant to be inputs available in some binary form by the computers that run the protocol.

For instance A and B might be a string shown in a GUI control of a login message "You are requested to authenticate to the server device A='someServerIdentityName', please enter the password for this specific server". 

The implicit assumption of CPace is that in some form the server identity information needs to be available in some digital form at protocol start at least for the initiator. This holds at least if a password is to be entered on a human user GUI control. The user needs to be given this information before choosing the right password for the remote unit.

A and B possibly could also be MAC addresses, Hardware serial numbers or the like in case of machine-machine interfaces. The name "Channel Identifier" CI indicates that it should specify in some way which end points are to be connected and possibly, if there are more than one active interconnections, which one among these interconnections.

Including this in the input string CI avoids the need to keep these strings as part of the state of the CPace protocol and reduces memory consumption, but requires that A and B are available upon protocol start. In the current definition, the only state that a CPace player needs to keep during for an active session is the session ID and the secret exponent (ya or yb).

Without any impact on the proof A and B could alternatively also be transmitted together with Ya and Yb in the protocol messages and integrated in the final hash in the transcript. This comes at the cost of slightly larger state. For the proof correctness, the requirement is that the CPace result ISK needs to be bound to the identities.

Without the A/B identifiers, relay attacks in the style of the "selfie" attack on TLS would be feasible and the proof would not hold because a such a relay attack would become possible in the real world but not possible in the ideal world.

Regarding the question whether to include the A/B information better initially or better in the final hash is probably worth a discussion.

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.
 


-----Ursprüngliche Nachricht-----
Von: Cfrg <[e-mail]> Im Auftrag von Hao, Feng
Gesendet: Dienstag, 9. Juni 2020 13:16
An: Björn Haase <[e-mail]>
Cc: [e-mail]
Betreff: Re: [Cfrg] Comments on the CPace proof and the CFRG PAKE selection process

Dear Bjorn (and CFRG),

I hope you are all well.

I raised one question about CPace during the selection process, however I don't think it has been properly addressed. Also I don't know whether the selection panel have actually taken this into account. Given that the selection process has finished and that CPace will likely be fielded, I feel we (everyone on CRFG) still have the responsibility to make sure all the technical claims in CPace are accurate and that the protocol can indeed be implemented securely and efficiently.

CPace modifies SPEKE by adding a random string (session ID) in the first flow. It claims to be one-round and UC-Secure.

However, the design of CPace is based on an "unusual" assumption: namely, each party should know the shared password and the other party's identity even before any communication in key exchange takes place. I say this is "unusual" as no other PAKE protocols make the same assumption, as far as I can tell. 

The "standard" assumption (e.g., as defined in ISO/IEC 11770-4) in PAKE is that a user only needs to memorize a shared password. The identities are established in-flow as part of the key exchange process and are verified based on the equality of the two passwords supplied by the two parties. This is reflected in all the PAKE designs that I know - but with exception of CPace.

One implication for the "unusual" assumption in CPace is that now a user not only needs to memorize a password, but also memorize the other party's "exact" identity which is to going to be used in the key exchange. However, when a key exchange session fails, it's simply impossible to distinguish whether the failure is due to the use of the wrong password or the user mis-remembering the other party's identity. This will impose severe difficulties in the implementation, e.g., defending against online dictionary attacks.
 
The other issue I raised in the earlier discussion in this list is that from the protocol design perspective, CPace is under-specified: there is no specification in the discrete logarithm setting, and several critical efficiency/security questions have been abstracted away by the idealization of hash-to-curve (which is yet to be established). 

Best regards,
Feng


_______________________________________________
Cfrg mailing list
[e-mail]
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.irtf.org%2Fmailman%2Flistinfo%2Fcfrg&amp;data=02%7C01%7Cbjoern.haase%40endress.com%7Cde190fc13b26402f113208d80c668bd7%7C52daf2a93b734da4ac6a3f81adc92b7e%7C1%7C1%7C637272981885924039&amp;sdata=Jj39ka13ASLKkMKsMjqllavkRfR1AbO6r0v%2BBMuDpAY%3D&amp;reserved=0