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

[Watson Ladd <[e-mail]>]

On Fri, Oct 16, 2020, 1:22 AM Hao, Feng <[e-mail]> wrote:
>
>     Would removing this/retaining this and adding a per-application
>     variant be a way forward? Part of the issue here is that people have
>     mostly been fine with per-application and global variants, so I can't
>     really point to a deployment that I know of that works.
>
> I think the best way forward would be that you code it up and show a realistic implementation that works in the way you describe. Then you can verify your claim yourself. Don't leave difficult implementation questions to developers!

I can write an implementation but you would then say no, we cannot
know A and B ahead of time or no, this  not in the client server case.
Do you have a good example of an application where this is an issue so
that I can understand what the constraints are? For example would
making M depend only on A and N depend only on B (or maybe it is the
other way around) so each side can prepare the flow without the other
identity resolve your issue?

>
>     I strongly question "cannot be realistically implemented". It would
>     seem to me that no PAKE that uses user identities would meet the
>     requirement you outline.
>
> Have a look at the original (published) SPAKE2 which you should already be familiar with and see how the identities are established in-flow there. Also have a look at PAKEs that have been implemented and used in realistic applications (EKE, SPEKE, J-PAKE) and see how the identities are established in-flow. More broadly, have a look at the nearly 30 years literature on PAKE, and the field of authenticated key exchange in general, and see how identities are defined and established in-flow as part of the key exchange process. If you believe "identities" can be remembered by the communicating parties without needing any communication, you need to show working examples.

I think you agree with me that this is only an issue when both sides
simultaneously prepare and exchange the first flow.  This is quite an
exotic application. Even peer-to-peer apps typically have initiators
and responders.  Again, do you have real world protocols with the
constraints you describe?

Sincerely,
Watson Ladd