===============================
Comments on P1363.2 D25

Kaliski/1, Technical, Clause D.5.5.3.4.1

[B15] also describes a scheme with multiple servers
where a retrieved key obtained by interacting with a
single server is used to authenticate to an ordinary
server, from which an additional component is
obtained; the master key is then derived from the
retrieved key and the additional component.  There is
only one PKRS-1 server in the scheme.  Neither the
PKRS-1 server nor the ordinary server has sufficient
information to determine the password, even if it
knows the master key or other keys derived from it. 
In contrast, in a single-server version of PKRS-1
without the ordinary server, if the master key is
derived directly from the retrieved key, then the
PKRS-1 server, given knowledge of the master key, can
determine the password by an offline dictionary
attack.

Proposed change:

The following additional sentence inserted in line 4
of the para could accommodate the two-server variant
just mentioned:

“Alternatively, the master key could be derived from a
single PKRS-1 retrieved key and a component stored on
another (non-PKRS-1) server, where the Client must
demonstrate knowledge of the retrieved key to the
second server in order to obtain the component. This
variant protects the password against compromise of
the PKRS-1 server.”
 
Editor’s notes:

I agree with inserting this as the third sentence of
D.5.5.3.4.1.

Kaliski/2, Technical, Clause D.5.5.3.4.2

In paragraph 4, bullet 1:  Does the Server know o_KCF
= Hash(Z || pi)?  If so, then the server will be able
to determine the password with an offline dictionary
attack.  The master key Z depends only on the password
pi and the server's private key u, so the value o_KCF
can likewise be calculated as a function of only those
values.  Since the server knows u already, if the
server also knows o_KCF, then pi can be exhaustively
searched.  The approach involving an ordinary server
above blocks the offline attack, and would be a better
countermeasure to attacks by the Server against the
client.

Editor’s notes:

I agree that this is a concern. The first bullet item
does not exactly correspond to either of the cited
references.  Although it was intended to correspond to
a proposal in [B21], the differences introduce this
concern. I propose replacing the first bullet item
with the following text to match the cited [B21]
reference and resolve this concern:

“? using oKCF = Hash(Hash(Z1 || Z2 || … Zn) || ?),
where the Zi values are derived using PKRS-1 with n
distinct Servers,, which prevents each Server from
fooling the Client without first correctly guessing
the password, or”

Kaliski/2, Editorial, Clause 8.2.1

In KRBP-1:  Should "party" be changed to "Client" to
match KRPP-1 and KRUP-1?

Editor’s notes:

I agree with changing “party” to “Client” here.

Kaliski/2, Editorial, Clause 10.2

In paragraph 1, line 4:  "computes" --> "compute"

Editor’s notes:

This should be corrected.

Kaliski/2, Editorial, Clause 10.2.1

In paragraph 1: "Client and Server parties" -->
"Client and Server"

Editor’s notes:

I agree with this proposed change.

Kaliski/2, Editorial, Clause 10.2.2.2

In note 9, line 2: "differences" is misspelled

Editor’s notes:

This should be corrected.