RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 2 records.

Status: Verified (1)

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

Note: This RFC has been updated by RFC 8146

Source of RFC: IETF - NON WORKING GROUP
Area 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

Note: This RFC has been updated by RFC 8146

Source of RFC: IETF - NON WORKING GROUP
Area 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.

Report New Errata



Advanced Search