# RFC Errata

Found 2 records.

## Status: Verified (1)

### RFC 5931, "Extensible Authentication Protocol (EAP) Authentication Using Only a Password", August 2010

Source of RFC: IETF - NON WORKING GROUPArea Assignment: sec

Errata ID: 3109

**Status: Verified
Type: Technical
Publication Format(s) : TEXT**

Reported By: Dan Harkins

Date Reported: 2012-02-06

Verifier Name: Sean Turner

Date Verified: 2012-05-04

Section 2.2.2 says:

An integer scalar, x, acts on an ECC group element, Y, via repetitive addition (Y is added to itself x times), also called point multiplication -- x * Y. The inverse function for an ECC group is defined such that the sum of an element and its inverse is the "point at infinity" (the identity for elliptic curve point addition). In other words, Q + inv(Q) = "O"

It should say:

An integer scalar, x, acts on an ECC group element, Y, via repetitive addition (Y is added to itself x times), also called point multiplication -- x * Y. ECC groups require the use of a mapping function, F(), which returns the x-coordinate of a point on the elliptic curve. In other words, if point Y has coordinates Y.x and Y.y, then, Y.x = F(Y) The inverse function for an ECC group is defined such that the sum of an element and its inverse is the "point at infinity" (the identity for elliptic curve point addition). In other words, Q + inv(Q) = "O"

Notes:

Section 2.8.4.1 mentions function F() as defined in 2.2.2 but there is no

function F() in 2.2.2.

## Status: Reported (1)

### RFC 5931, "Extensible Authentication Protocol (EAP) Authentication Using Only a Password", August 2010

Source of RFC: IETF - NON WORKING GROUPArea Assignment: sec

Errata ID: 5681

**Status: Reported
Type: Technical
Publication Format(s) : TEXT**

Reported By: Dan Harkins

Date Reported: 2019-03-31

Section 2.8.3 says:

2.8.3 Fixing the Password Element Fixing the Password Element involves an iterative hunting-and-pecking technique using the prime from the negotiated group's domain parameter set and an ECC- or FFC-specific operation depending on the negotiated group. 2.8.3.1. ECC Operation for PWE The group-specific operation for ECC groups uses pwd-value, pwd-seed, and the equation for the curve to produce the Password Element. First, pwd-value is used directly as the x-coordinate, x, with the equation for the elliptic curve, with parameters a and b from the domain parameter set of the curve, to solve for a y-coordinate, y. If there is no solution to the quadratic equation, this operation fails and the hunting-and-pecking process continues. If a solution is found, then an ambiguity exists as there are technically two solutions to the equation and pwd-seed is used to unambiguously select one of them. If the low-order bit of pwd-seed is equal to the low-order bit of y, then a candidate PWE is defined as the point (x, y); if the low-order bit of pwd-seed differs from the low-order bit of y, then a candidate PWE is defined as the point (x, p - y), where p is the prime over which the curve is defined. The candidate PWE becomes PWE, and the hunting and pecking terminates successfully. Algorithmically, the process looks like this: found = 0 counter = 1 do { pwd-seed = H(token | peer-ID | server-ID | password | counter) pwd-value = KDF(pwd-seed, "EAP-pwd Hunting And Pecking", len(p)) if (pwd-value < p) then x = pwd-value if ( (y = sqrt(x^3 + ax + b)) != FAIL) then if (LSB(y) == LSB(pwd-seed)) then PWE = (x, y) else PWE = (x, p-y) fi found = 1 fi fi counter = counter + 1 } while (found == 0) Figure 3: Fixing PWE for ECC Groups 2.8.3.2. FFC Operation for pwe The group-specific operation for FFC groups takes pwd-value, and the prime, p, and order, r, from the group's domain parameter set (see Section 2.2.1 when the order is not part of the defined domain parameter set) to directly produce a candidate Password Element, pwe, by exponentiating the pwd-value to the value ((p-1)/r) modulo the prime. If the result is greater than one (1), the candidate pwe becomes pwe, and the hunting and pecking terminates successfully. Algorithmically, the process looks like this: found = 0 counter = 1 do { pwd-seed = H(token | peer-ID | server-ID | password | counter) pwd-value = KDF(pwd-seed, "EAP-pwd Hunting And Pecking", len(p)) if (pwd-value < p) then pwe = pwd-value ^ ((p-1)/r) mod p if (pwe > 1) then found = 1 fi fi counter = counter + 1 } while (found == 0) Figure 4: Fixing PWE for FFC Groups

It should say:

2.8.3 Fixing the Password Element Fixing the Password Element involves an iterative hunting-and-pecking technique using the prime from the negotiated group's domain parameter set and an ECC- or FFC-specific operation depending on the negotiated group. To thwart side-channel attacks that attempt to determine the number of iterations of the hunting-and-pecking loop used to find the PE for a given password, a security parameter, k, is used that ensures that at least k iterations are always performed. The probability that one requires more than n iterations of the hunting-and-pecking loop to find an ECC PE is roughly (q/2p)^n and to find an FFC PE is roughly (q/p)^n, both of which rapidly approach zero (0) as n increases. The security parameter, k, SHOULD be set sufficiently large such that the probability that finding the PE would take more than k iterations is sufficiently small. It is RECOMMENDED that an implementation set the security parameter, k, to a value of at least forty (40) which will put the probability that more than forty iterations are needed in the order of one in one trillion (1:1,000,000,000,000) 2.8.3.1. ECC Operation for PWE The group-specific operation for ECC groups uses pwd-value, pwd-seed, and the equation for the curve to produce the Password Element. First, pwd-value is used directly as an x-coordinate, v, with the equation for the elliptic curve, with parameters a and b from the domain parameter set of the curve, to check whether v^3 + a*v + b is a quadratic residue modulo p. If it is a quadratic non residue, this operation fails and the hunting-and-pecking process continues. If it is a quadratic residue, then the x-coordinate is saved and the current seed is stored. When the hunting-and-pecking loop terminates, the x-coordinate is used with the equation of the curve to solve for a y-coordinate. An ambiguity exists since two values for the y-coordinate would be valid, and the low-order bit of the stored base is used to unambiguously determine the correct y-coordinate. The resulting (x,y) pair becomes PWE. Algorithmically, the process looks like this: found = 0 counter = 1 do { pwd-seed = H(token | peer-ID | server-ID | password | counter) pwd-value = KDF(pwd-seed, "EAP-pwd Hunting And Pecking", len(p)) if (pwd-value < p) then v = pwd-value if ((v^3 + av + b)) is a quadratic residue) then if ( found == 0 ) then x = v save = pwd-seed found = 1 fi fi fi counter = counter + 1 } while ((found == 0) || (counter < k)) y = sqrt(x^3 + ax + b) if ( lsb(y) == lsb(save)) then PWE = (x, y) else PWE = (x, p-y) fi Figure 3: Fixing PWE for ECC Groups Checking whether a value is a quadratic residue modulo a prime can leak information about that value in a side-channel attack. Therefore, it is RECOMMENDED that the technique used to determine if the value is a quadratic residue modulo p blind the value with a random number so that the blinded value can take on all numbers between 1 and p-1 with equal probability while not changing its quadratic residuosity. Determining the quadratic residue in a fashion that resists leakage of information is handled by flipping a coin and multiplying the blinded value by either a random quadratic residue or a random quadratic nonresidue and checking whether the multiplied value is a quadratic residue (qr) or a quadratic nonresidue (qnr) modulo p, respectively. The random residue and nonresidue can be calculated prior to hunting and pecking by calculating the Legendre symbol on random values until they are found: do { qr = random() mod p } while ( lgr(qr, p) != 1) do { qnr = random() mod p } while ( lgr(qnr, p) != -1) Algorithmically, the masking technique to find out whether or not a value is a quadratic residue looks like this: is_quadratic_residue (val, p) { r = (random() mod (p - 1)) + 1 num = (val * r * r) mod p if ( lsb(r) == 1 ) num = (num * qr) mod p if ( lgr(num, p) == 1) then return TRUE fi else num = (num * qnr) mod p if ( lgr(num, p) == -1) then return TRUE fi fi return FALSE } 2.8.3.2. FFC Operation for pwe The group-specific operation for FFC groups takes pwd-value, and the prime, p, and order, r, from the group's domain parameter set (see Section 2.2.1 when the order is not part of the defined domain parameter set) to directly produce a candidate Password Element, pwe, by exponentiating the pwd-value to the value ((p-1)/r) modulo the prime. If the result is greater than one (1), the candidate pwe becomes pwe, and the hunting and pecking continues. Algorithmically, the process looks like this: found = 0 counter = 1 do { pwd-seed = H(token | peer-ID | server-ID | password | counter) pwd-value = KDF(pwd-seed, "EAP-pwd Hunting And Pecking", len(p)) if (pwd-value < p) then temp = pwd-value ^ ((p-1)/r) mod p if (temp > 1) then found = 1 pwe = temp fi fi counter = counter + 1 } while ((found == 0) || (counter < k)) Figure 4: Fixing PWE for FFC Groups

Notes:

The key exchange in EAP-pwd is dragonfly which was described in RFC 7664. During the standardization of RFC 7664, comments were received to prevent a side-channel attack against the hunting-and-pecking loop and the technique used in RFC 7664 should be done in RFC 5931 to prevent side-channel attack.