Re: [Cfrg] CPace feedback regarding the identity handling

["Hao, Feng" <[e-mail]>]

Dear Bjorn,

Thanks for your response. I understand it's an implicit assumption that you make in your paper. I just wanted to highlight it explicitly so people are aware of the potential difficulty in the implementation and the fact that this is not how PAKE normally works. I don't think the use of a GUI program as you suggested does any help to resolve this fundamental issue. Note that this issue doesn’t apply to other PAKE protocols.

Your suggestion of including the identities into the KDF to resolve this issue is reasonable, but that will be a different protocol. Btw, that is exactly what we did in the design of the patched SPEKE in ISO/IEC 11770-4:2017 (https://arxiv.org/pdf/1802.04900.pdf).

Cheers,
Feng

On 09/06/2020, 20:01, "Björn Haase" <[e-mail]> wrote:

    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