Re: [Cfrg] RGLC on draft-irtf-cfrg-spake2-13

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

In reply to Watson's offlist questions and with his permission I post my response on the CFRG list, as I feel the discussion may be of wider interest.

On 15/10/2020, 01:28, "Watson Ladd" <[e-mail]> wrote:

    Offlist:
    On Wed, Oct 14, 2020, 3:48 PM Hao, Feng <[e-mail]> wrote:
    >
    >
    >
    > On Wed, Oct 14, 2020, 12:36 PM Hao, Feng <[e-mail]> wrote:
    >
    > For “per-user M and N”, the authors need to be explicit how exactly will each party know the identity to be used by the other party even before any communication starts. Otherwise, you will end up with a “one-round PAKE” that can’t be implemented in one round.
    >
    >
    >
    > This is a higher level protocol consideration, but I don't see how an extra round would be needed since the server seems the client identity in the first message. It has to look up the password after all.
    >
    >
    >
    > How about the initiator? Besides client-server, you also need to consider peer-to-peer which is a typical setting for a balanced PAKE. How do peers know each other’s identity beforehand?

    I'm really struggling to understand what is meant here.  Do you have a
    concrete application that can't work because of this limitation? In
    what world do you open a connection with no idea of who you will find
    on the other end?

The identity used in PAKE must be "exact", as it will be used to look up the shared password from a local database. You of course know where to open a connection, say if you want to connect to a site, you may use "example.com", "www.example.com", "example.com:80", and etc. All these will lead you to the same site. However, these strings are too ambiguous to be used as an identity. You have to agree with the other party which "exact" string you two shall use. This can't happen out of thin air; it needs two parties to communicate and negotiate. Your draft mentions using internet addresses for identities - however, IP or MAC addresses are unsuitable to be used as identities as they may change at any time. When they change, the user will get authentication failure even after they have used the correct password. This is clearly unacceptable. To sum up, the identity in PAKE is defined at the application level. It must NOT be mixed up with "identities" used in the lower layers in the TCP/IP stack, which serve different purposes.

    >
    >
    >
    > If you have specific text that would be helpful I'm happy to add it post collecting all the comments.
    >
    >
    >
    > I’m afraid I don’t have any specific text to propose. It’s not about tweaking text. It’s a fundamental issue that needs to be considered carefully, especially that what you are doing here deviates from the established practice in the past many years research on PAKE where the user identities are established in-flow rather than being presumed or “remembered”. It’s OK that you do something different, but extra care is needed. I can only suggest you to flesh out full details on “per-user M and N” and how it is integrated within the SPAKE2 protocol as a complete specification before it’s possible for others to review and comment on your proposal; or alternatively revert to the original (published) SPAKE2 scheme and acknowledge the limitation of using a global trusted setup.


    The global setup is still an option in this version. I can also add a
    per-application variant.

It's good to see that you're taking steps to address the trusted setup issue. However, the pre-application solution, as you currently describe in the draft, cannot be realistically implemented in one round. You may want to revise your claims. Also, technically speaking, what you propose in Section 5 is not a "variant" of SPAKE2, but a new protocol (which hasn't gone through any formal peer-review process). You should at least call it a different name to avoid mixing up with the original (peer-reviewed) SPAKE2.