Proposed changes to P1363.2 D25:
Technical changes
1— D.5.5.3.4.1: Insert new third and fourth sentences:
“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 non-PKRS-1 server in order to obtain the component (see Note). This variant protects the password
against compromise of the PKRS-1 server.”
2— D.5.5.3.4.1: Add a new clarifying note:
“NOTE—The retrieved key itself shouldn’t be revealed to the non-PKRS-1 server, otherwise the nonPKRS-1 server has enough information itself (retrieved key + component) to determine the master key.
Instead, a variant of the retrieved key could be used as an authentication key in some proof of knowledge
protocol that doesn’t reveal the retrieved key.”
3— D.5.5.3.4.2: Correct first bullet item by replacing “Hash(Z, )” with “Hash(Z1, Z2, ... Zn, ), where the
Zi values are derived using PKRS-1 with n distinct Servers”.
Editorial changes
4— 1.2, second sentence: Change "keys," to "keys;".
5— 3.2, fourth paragraph: Correct "threshold".
6— 3.3.3: Correct "targeted".
7— 4.2.3: Correct "entangled".
8— 6.1.3: Change "key key" to "key".
9— 7.1.3: Change "key key" to "key".
10— 8.1.3: Change "key key" to "key".
11— 8.1.6: Correct "Boolean", with apologies to George.
12— 8.1.6: In Mvcf entry, change "used used" to "used".
13— 8.2.1: Change “party” to “Client” to match KRPP-1 and KRUP-1.
14— 8.2.1: Change "Discete" to "Discrete".
15— 8.2.2: Change "Discete" to "Discrete".
16— 8.2.3: Change "Discete" to "Discrete".
17— 8.2.23: Correct "Boolean".
18— 9.4.1: Correct "Boolean".
19— 9.6: Change "shared shared" to "shared".
20— 9.6.1: Correct "Boolean".
21— 9.8.3.1: Change "oS" to "CS".
22— 9.8.3.2: Change "oC" to "CC".
23— 9.8.xxx, Note 3: Correct "multiplier".
24— 10.2, paragraph 1: Change “computes” to “compute”.
25— 10.2.1, paragraph 1: Change “Client and Server parties” to “Client and Server”.
26— 10.2.2.2, Note 9, p. 78 line 10: Change “diffeerences” to “differences”.
27— A.16.13, Note 1: Change "can can" to "can".
28— B, first word: Correct "Implementers".
29— C.1.8.5, second sentence: Correct "presence".
30— C.1.8.9, second paragraph: Correct "implementer", twice.
31— C.3.10: Change "soley" to "solely".
32— D.5.4.6: Correct "implementer".
33— D.5.4.12: Correct "targeted".
34— D.5.4.14: Correct "English".
35— D.5.4.16: Correct "implementer".
36— D.5.4.17: Correct "ultimately".
37— D.5.4.21 p. 110 line 33: Insert blank line before “Denial of service”.
38— D.5.4.21: Correct period in "Mistakes vs. attacks".
39— D.5.4.21 line 36: In Group passwords paragraph, change quotes around "blinding" to “blinding”.
40— D.5.4.21: In Group passwords, "accommodate".
41— D.5.4.21 line 40: Change the colon after “Parallel guessing” to a period.
42— D.5.4.21: In Parallel guessing, "knowledge".
43— D.5.4.23, second bullet, p. 111 line 22: Change apostrophe in “1363.2's” to “1363.2’s”.
44— D.5.5.2.1: Correct "confinement".
45— D.5.5.3.2: Correct "accommodate".
46— D.5.5.3.2: Correct "implementer".
47— D.5.5.3.4: Correct "implementer", twice.
48— D.5.5.3.4.1: Delete blank line before first paragraph.
D.5.5.4.3 Application considerations for PKRS-1
D.5.5.4.3.1 Use with multiple servers
Both [B15] and [B21] describe use of a single PKRS-1-CLIENT with multiple independent PKRS-1SERVERs, where the individual keys established with each Server are combined into a single Client master
key. A variety of techniques might be used to derive the master key from multiple PKRS-1 retrieved keys
and other components. 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 non-PKRS-1 server in order to obtain the component (see Note). This variant
protects the password against compromise of the PKRS-1 server. The master key could then be verified by
the Client, perhaps using additional information stored on one or more of the Servers, and then used to
derive static secret keys that unlock sensitive user data.
NOTE—The retrieved key itself shouldn’t be revealed to the non-PKRS-1 server, otherwise the non-PKRS-1 server has
enough information itself (retrieved key + component) to determine the master key. Instead, a variant of the retrieved
key could be used as an authentication key in some proof of knowledge protocol that doesn’t reveal the retrieved key.
D.5.5.4.3.2 Need for key confirmation
In order to prevent disclosure of  to an untrusted party that knows u, or one that knows wC and controls wS,
an application protocol that invokes PKRS-1-CLIENT must confirm that the permuted password zg (or,
equivalently, a value derived from zg, such as Z or Ki) is correct before the Client reveals information about
zg to untrusted parties.
However, unlike the key agreement schemes in this standard, PKRS-1 does not include a key confirmation
operation. Methods for key confirmation may vary considerably, such as those described in [B15] and
[B21], which derive a key from a PKRS-1 established key in combination with other components.
Depending on the method, further validation of wS may be required, as shown in the following example.
Consider a PKRS-1 application where the Client attempts to confirm that its computed Z is correct by
verifying that Hash(Z) = oKCF, where oKCF is a key confirmation value received from the Server. Let’s call
the correct key confirmation value oKCF', which equals Hash(Z'), where Z' = GE2OSP-X(g^u). But, prior
to key confirmation, this Client cannot assume that wS is valid or that oKCF = oKCF'. Without further
validation of wS (other than it being in the parent group), an enemy could provide an arbitrary wS value of
small order, creating a significant chance for the enemy to further provide the Client with an oKCF equal to
Hash(Z), and thus obtain the Client’s predicted retrieved key value(s), even though oKCF  oKCF, Z  Z', and
the enemy has no knowledge of u.
Without further validation of wS, it is evident that this Hash(Z) method does not confirm that the Client’s
retrieved key is correct. An implementer may address this problem by making the Client abort when wS is
of small order, perhaps using Key Establishment Step e)2). Alternately, an implementer may use a key
confirmation technique described in the aforementioned references, such as:
 using oKCF = Hash(Z1, Z2, ... Zn, ), where the Zi values are derived using PKRS-1 with n distinct
Servers, which prevents the Server from fooling the Client without first correctly guessing the
password, or
 using a separately secured channel to protect the integrity of oKCF.
The extent to which the Client trusts the Server and the ways in which such trust is established or verified
may vary depending on the application, and are beyond the scope of PKRS-1.