Subject: [Cfrg] On terminology (and essence): peer-to-peer or client-server

From: Hugo Krawczyk <[email-masked]>
Date: Tue, 28 May 2019 23:58:12 -0400

It is very important that when people propose or discuss specific PAKE
protocols and applications, that they distinguish between those intended
for "peer communication" (where both ends share the same password) and
those for the client-server case (where the server does not store the
password but only a one-way function of the password).

These are different types of protocols, for different settings, different
security goals and  definitions, and quite different designs. In
particular, they cover very different applications (the client-server
setting is where most uses of passwords are found while the peer case seems
of more  restricted applicability, at least in the past).

It would be very helpful if we developed some common terminology for
differentiating these two settings. Unfortunately, there are many different
names people have been using. I like to call them "symmetric" (for the peer
case) and "asymmetric" (for the client-server case), but we have also
balanced and unbalanced, plain PAKE for the peer case and augmented PAKE
for the client server and more (e.g. "Verifier-based" for the asymmetric
case).

It would be good to set some conventions here.

But regardless of names, the most important point is to make clear to what
setting one refers when discussing specific protocols and applications.

Hugo

---

From: "Stanislav V. Smyshlyaev" <[email-masked]>
Date: Wed, 29 May 2019 08:42:02 +0300

Dear Hugo,

I completely agree with your point: when comparing PAKEs, we must be very
explicit about the primary scope of each protocol and clearly distinguish
"client-server" applications of PAKEs and "peer-to-peer" ones. I hope that
I've reflected this in my presentation about PAKE selection in Prague at
IETF 104,
https://www.ietf.org/proceedings/104/slides/slides-104-cfrg-pake-selection-01.pdf
.

While we are going through the PAKE selection process, we need to be very
accurate with the goals which are achieved by each PAKE: in Prague I gave a
simple example that being "augmented"/"asymmetric" can be redundant when
we're thinking about such applications as Wi-Fi DPP protocol, for example.
Of course, we must take this to account.

We have the document, that helps with a number of questions with
terminology here: RFC 8125. But, as any document, it can't answer all
questions, so we may have to make adjustments during our discussions in the
selection process.

And my point is that at the end of the main process, when we (hopefully)
select some PAKEs and start our work with CFRG document “Recommendations
for password-based authenticated key establishment in IETF protocols”,
we'll be obliged to reflect all issues with the terms, goasl of PAKEs,
scope and recommendations in that document.

Kind regards,
Stanislav

ср, 29 мая 2019 г. в 06:59, Hugo Krawczyk <[email-masked]>:

> _______________________________________________
> Cfrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/cfrg
>