Re: [Cfrg] Review of the Balanced PAKE proposals // Session ID handling

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

Dear Karthik,

I would like to respond to your questions. I will add some of the CFRG reviewers on the CC list because the issue that you have brought up regarding the session ids is exactly what I have been discussing with them.


>CPace ======
>
>CPace can be considered a variant of SPEKE and the proposal includes a full security
>proof in the Universal Composability (UC) framework [3].
>We did not check the proof in detail but have no reason to believe it is flawed.

There was the need for some fixes and clarification (see e.g. the review of Björn Tackmann) but in my opinion there
is no serious flaw remaining for CPace if we add the requirement to Map2Point that the image
of Map2Point is not significantly smaller than the order of the DH group. I am working on a revision that is
sorting out the remaining aspects.

>Unfortunately, features of the proof appear to leak into the protocol design which
>make it difficult to understand how the concrete protocol will be deployed.
>The protocol in Figure 4 includes a first round to establish a session identifier,
>making CPace into a 2 round protocol.
>If this first round is included, then CPace would not be suitable for TLS 1.3,
>so understanding its need is essential.

Yes I agree and for this precise aspect, I am in a closer discussion with both, the authors of OPAQUE
and people from the crypto review panel in order to sort this out. Note that the session-id complexity
is a topic that comes with any security analysis in the UC
framework and is relevant also for the augmented protocol AuCPace and OPAQUE.

>The assumptions on this identifier are unclear to us: is it just a proof artefact?
>does removing it introduce a concrete attack?

I am not aware of any concrete attack. Part of the session id topic should probably be considered a
technical proof artefact. It is my conviction that in any case CPace without ephemeral session id will be no less secure than
SPEKE, but one might actually be loosing some of the composability guarantees.

Note that because of the importance of this aspect, I have add my own assessment as part of the presentation at CHES 2019 in August.
The sid topic is discussed on the slides
https://ches.iacr.org/2019/src/slides/Day3/Session13_IOTSec/Paper2_Session13_Presentation_AuCPace_CHES2019.pdf
starting at page #53.

I’d appreciate the feedback and comment of the crypto review panel members here, since I believe that they will
be having more insight than I do. In my opinion this topic is related to the fact that we have to use joint state in combination
with a global RO.

I’d also appreciate your opinion on slides 69ff.


>The authors say "Hashing CI into G allows us to fend off certain types of relay attacks”.
>What are these attacks? Are they practical?
Yes. Imagine for instance that you have two servers A,B that use the same password but have different IP addresses and port numbers.
Assume that you have one client that believes that it is connected to server A but in fact the adversary relays the
communication to server B. By including the CI as the port numbers and IP addresses of both parties fends of the attack.

In case that you use explicit key confirmation and incorporate the information on the two parties into the final hash for the key confirmation (as you do for TLS), there is no need for CI. Still CPace is designed to be also suitable also in a setting where you have
security *without* any key confirmation and there it is helpful to integrate this information into the CI. Possibly, you might want to
authenticate other associate data.

>The authors also say that "In the context of TCP/IP, the CI might be constructed by concatenating unique representations
>of the server’s and client’s IP address and TCP port numbers.”
Yes, as I have discussed above. I believe that this feature is particularly suitable and helpful if a construction uses implicit authentication without explicit key confirmation.

>This seems to indicate that uniqueness across CPace sessions is the only property desired for the CI. Is this the case?
No. The CI is designed for authenticating any possibly important information and the purpose of this field is: Implicit authentication
of some associated data if you don’t want to add explicit key confirmation. If you have key confirmation you could also choose to
Include this information there. Note that when including the information in the CI, you might spare some bytes of memory. In our constrained server setting this advantage is helpful (~64 bytes of the precious RAM were saved).

>The proof appears to rely on the ssid being derived from fresh random values “s” and “t” generated
>by both parties, and TCP/IP addresses are definitely not fresh random values in practice.
Yes. This is the topic I have also explicitly addressed to some of the crypto review panel members (and added them CC).

>Would the proof still work if you used local counters for s and t?
In my opinion yes. UC does not require anything but uniqueness, to my very best knowledge.

>Also, how would the authors envision this would work with other transport protocols like Quic or raw UDP?
In this case if several concurrent sessions share the same UDP port on one peer, I’d see the need for a session ID for arranging for
the local addressing at the host. Actually this is exactly what happens in the “ITM” touring machine setting in which the UC framework
runs its simulations. (as depicted in my CHES slides mentioned above).
There the internal addressing within the peers is done using the session ID.

>Also: CPace does not specify key confirmation and it would be an important aspect to flesh out if the
>protocol were to be integrated into TLS.

The protocol does not require key confirmation. As pointed out, important information to be authenticated (such as the party identities A,C in the example above) could be integrated already in the CI field. Within the proof in its latest revised version (including the feedback from the CFRG reviewers), you will find out that there is a slight modification in the security guarantees for CPace with and without explicit key confirmation. This change in my opinion matches closely the difference between perfect and weak forward secrecy.
(Note that according to the analysis of Hugo Krawczyk in his HQMV paper, any two-flow protocol without mutual key confirmation could not realize perfect forward secrecy but only weak forward secrecy.)

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.