RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 21 records.

Status: Verified (4)

RFC 4226, "HOTP: An HMAC-Based One-Time Password Algorithm", December 2005

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 4994
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Mathias Tausig
Date Reported: 2017-04-14
Verifier Name: Paul Wouters
Date Verified: 2023-08-03

Section 7.2 says:

The HOTP client (hardware or software token) increments its counter
and then calculates the next HOTP value HOTP client.  If the value
received by the authentication server matches the value calculated by
the client, then the HOTP value is validated.  In this case, the
server increments the counter value by one.

If the value received by the server does not match the value
calculated by the client, the server initiate the resynch protocol
(look-ahead window) before it requests another pass.

It should say:

The HOTP client (hardware or software token) increments its counter
and then calculates the next HOTP value HOTP client.  If the value
received by the authentication server matches the value calculated by
the server, then the HOTP value is validated.  In this case, the
server increments the counter value by one.

If the value received by the server does not match the value
calculated by the server, the server initiate the resynch protocol
(look-ahead window) before it requests another pass.

Notes:

The OTP value received by the server is the one calculated by the client.

AD Note: this text still has the stray "HOTP client" string that errata eid 5723 reported.

Errata ID: 5130
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Gerrit Jansen van Vuuren
Date Reported: 2017-09-27
Verifier Name: Paul Wouters
Date Verified: 2023-08-03

Section Appendix C says:

 static public String generateOTP(byte[] secret,
                  long movingFactor,
             int codeDigits,
                  boolean addChecksum,
             int truncationOffset)
           throws NoSuchAlgorithmException, InvalidKeyException
       {
           // put movingFactor value into text byte array
     String result = null;
     int digits = addChecksum ? (codeDigits + 1) : codeDigits;
           byte[] text = new byte[8];
           for (int i = text.length - 1; i >= 0; i--) {
               text[i] = (byte) (movingFactor & 0xff);
               movingFactor >>= 8;
           }

It should say:

 static public String generateOTP(byte[] secret,
                  long movingFactor,
             int codeDigits,
                  boolean addChecksum,
             int truncationOffset)
           throws NoSuchAlgorithmException, InvalidKeyException
       {
           // put movingFactor value into text byte array
     String result = null;
     long count = movingFactor;
     int digits = addChecksum ? (codeDigits + 1) : codeDigits;
           byte[] text = new byte[8];
           for (int i = text.length - 1; i >= 0; i--) {
               text[i] = (byte) (count & 0xff);
               count >>= 8;
           }

Notes:

method parameters like movingFactor should not be edited or changed in the method logic. This may lead to misunderstanding and bugs when the code is ported to other platforms and or re-implemented. Here movingFactor would be expected to stay constant and can be reused, but the original implementation updates the value to 0, which means any extra logic or updates (even debug statements) would always see movingFactor == 0 no matter what.

Errata ID: 163
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: M'Raihi, David
Date Reported: 2005-12-26

Section 9 says:

   Oracle AuthO()
   --------------
      A = ALG(K,C)
      C = C + 1
      Return O to B

It should say:

   Oracle AuthO()
   --------------
      A = ALG(K,C)
      C = C + 1
      Return A to B
             ^^

Notes:


Section A.4.1, Paragraph 3, Lemma 1 definition, top of page 19

The description of Lemma 1 defines P_ {N,m} (z) using the term Z_ {n}
and it should actually be Z_ {N}.
P_{N,m}(z) = Pr [x mod m = z : x randomly pick in Z_{n}]
Should be:
P_{N,m}(z) = Pr [x mod m = z : x randomly pick in Z_{N}]
^^^

Section E.2, Paragraph 4, bottom of page 32
32^8 > 10^12 so the security of an 8-alphanumeric HOTP code is
significantly better than a 9-digit HOTP value.
Should be:
32^8 > 10^12 so the security of an 8-alphanumeric HOTP code is
significantly better than a 12-digit HOTP value.
^^

In Author's Addresses, Page 35, David Naccache's contact information should be:

David Naccache
ENS, DI
45 rue d'Ulm
75005 Paris, France
and
Information Security Group,
Royal Holloway,
University of London, Egham,
Surrey TW20 0EX, UK

EMail: david.naccache@ens.fr, david.naccache@rhul.ac.uk

Errata ID: 5723
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: Adam Sorini
Date Reported: 2019-05-18
Verifier Name: Roman Danyliw
Date Verified: 2022-01-20

Section 7.2 says:

The HOTP client (hardware or software token) increments its counter
and then calculates the next HOTP value HOTP client.

It should say:

The HOTP client (hardware or software token) increments its counter
and then calculates the next HOTP value.

Notes:

Stray "HOTP client" at the end of the sentence (for no reason).

Status: Reported (4)

RFC 4226, "HOTP: An HMAC-Based One-Time Password Algorithm", December 2005

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 5129
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Gerrit Jansen van Vuuren
Date Reported: 2017-09-27

Section Appendix D says:

Count    Hexadecimal    Decimal        HOTP
   0        4c93cf18       1284755224     755224
   1        41397eea       1094287082     287082
   2         82fef30        137359152     359152
   3        66ef7655       1726969429     969429
   4        61c5938a       1640338314     338314
   5        33c083d4        868254676     254676
   6        7256c032       1918287922     287922
   7         4e5b397         82162583     162583
   8        2823443f        673399871     399871
   9        2679dc69        645520489     520489


It should say:

Count     Hexadecimal    Decimal        HOTP
   0         4c93cf18      1284755224    755224
   1         75a48a19      1973717529    717529
   2         bacb7fa       195868666     868666
   3         66c28227      1724023335    023335
   4         2904c900      688179456     179456
   5         237e783d      595490877     490877
   6         3c9cd285      1016910469    910469
   7         24fb960c      620467724     467724
   8         1b3c89f6      456952310     952310
   9         16374098      372719768     719768

Notes:

From https://www.ietf.org/rfc/rfc4226.txt, Appendix D, page 31

a. There is no mention of the parameters that were used to run the reference implementation to provide to test data. These should be:

codeDigits: 6, addCheckSum: false, truncationOffset: 0.

b. The hashes correspond. And the first row of Table2 (i.e for Count==0) correspond, but for Count 1...9 the values for Hex, Decimal and Hotp do not correspond with the values of the reference implementation.

I am using JDK 1.8.0_144

As a test I have done a copy and paste 'as is' from the reference implementation and run it with sysout statements to print the truncation and otp values for each counter.

The only changes made are: System.out and use of counter=movingFactor to print the movingFactor. None of which alter the logic. Note the differences in test data were found before adding the debug info.

Please see:
https://github.com/gerritjvv/cryptoplayground/tree/master/hmac/java/hmac/src/test/java/org/funsec/hmac

UnitTest method:
https://github.com/gerritjvv/cryptoplayground/blob/master/hmac/java/hmac/src/test/java/org/funsec/hmac/HTOPTest.java#L83

Reference Impl:
https://github.com/gerritjvv/cryptoplayground/blob/master/hmac/java/hmac/src/test/java/org/funsec/hmac/HOTPRef.java

Errata ID: 6756
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Nicholas Gaya
Date Reported: 2021-11-28

Section 5.3 says:

Let OffsetBits be the low-order 4 bits of String[19]

It should say:

Let OffsetBits be the low-order 4 bits of the last byte of String

Notes:

This change does not affect the computation for 20-byte HMAC-SHA-1 digests. However when using the HMAC-SHA-256 or HMAC-SHA-512 functions as suggested in RFC-6238, the 19th byte and the last byte may differ.

The proposed change matches the reference implementations of both RFC-4226 and RFC-6238 and removes potential ambiguity as to whether implementations should use the 19th byte or the last byte of the digest to determine the offset for dynamic truncation.

Errata ID: 6702
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Darian Miller
Date Reported: 2021-10-03

Section 5.2 says:

The Key (K), the Counter (C), and Data values are hashed high-order byte first.

It should say:

When hashing, the Key (K) value is provided in little-endian format while the Counter (C) value is in big-endian format.

Notes:

This byte reversal for the Counter (movingFactor) value is indeed demonstrated in the RFC's reference implementation code within Appendix C but this fact is not mentioned within RFC text body.

byte[] text = new byte[8];
for (int i = text.length - 1; i >= 0; i--) {
text[i] = (byte) (movingFactor & 0xff);
movingFactor >>= 8;
}


This specific issue is called out in a related wikipedia article:
https://en.wikipedia.org/wiki/HMAC-based_one-time_password: "counter must be big endian"


This can also be verified by looking at archived source of Google Authenticator on GitHub: https://github.com/google/google-authenticator/blob/51781910ae2bb1abf8ac51b290272f86f3651235/mobile/ios/Classes/OTPGenerator.m

Related code snippet:
(counter = NSSwapHostLongLongToBig(counter);)


FreeOTP also reverses the byte order of the counter
https://github.com/freeotp/freeotp-android/blob/eb2f12f33a38235433fd83e0ad3eb15affae871f/app/src/main/java/org/fedorahosted/freeotp/Token.java

code comment "// Encode counter in network byte order"
The code uses a Byte buffer which defaults to big_endian order.

Errata ID: 7651
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Ashley R. Thomas
Date Reported: 2023-09-21

Section 5.3 says:

   The Truncate function performs Step 2 and Step 3, i.e., the dynamic
   truncation and then the reduction modulo 10^Digit.  The purpose of
   the dynamic offset truncation technique is to extract a 4-byte
   dynamic binary code from a 160-bit (20-byte) HMAC-SHA-1 result.

    DT(String) // String = String[0]...String[19]
     Let OffsetBits be the low-order 4 bits of String[19]
     Offset = StToNum(OffsetBits) // 0 <= OffSet <= 15
     Let P = String[OffSet]...String[OffSet+3]
     Return the Last 31 bits of P

It should say:

   The Truncate function performs Step 2 and Step 3, i.e., the dynamic
   truncation and then the reduction modulo 10^Digit.  The purpose of
   the dynamic offset truncation technique is to extract a 4-byte
   dynamic binary code from a 160-bit (20-byte) HMAC-SHA-1 result.

    DT(String) // String = String[0]...String[19]
     Let OffsetBits be the low-order 4 bits of String[19]
     Offset = StToNum(OffsetBits) // 0 <= OffSet <= 15
|    Let P = String[Offset*8]...String[Offset*8+31]
     Return the Last 31 bits of P

Notes:

The uncorrected text uses String as a byte string amidst correct uses of it as a bit string. Section 5.1. clearly states, "A string always means a binary string, meaning a sequence of zeros and ones." The RFC seems to intend that either "string" or "String" is a bit string, not a byte string, so the use of "String" as a byte string in the uncorrected text seems incorrect, out of place, as if a typo.

Another apparent typo is use of camel case "OffSet" instead of simply "Offset". There is no distinction within the RFC that camel case "OffSet" has any meaning beyond another spelling for "Offset".

Thank you for considering this erratum and for this very straightforward, easy to understand, positively impactful RFC.

Status: Held for Document Update (12)

RFC 4226, "HOTP: An HMAC-Based One-Time Password Algorithm", December 2005

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 2404
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT

Reported By: Alfred Hoenes
Date Reported: 2006-01-18
Held for Document Update by: Sean Turner
Date Held: 2010-07-30

Section A.3 says:

   Oracle AuthO()
   --------------
      A = ALG(K,C)
      C = C + 1
      Return O to B

   Oracle VerO(A)
   --------------
      i = C
      While (i <= C + s - 1 and Win == FALSE) do
         If A == ALG(K,i) then Win = TRUE; C = i + 1
         Else i = i + 1
      Return Win to B

It should say:

   Oracle AuthO()
   --------------
      A = ALG(K,C)
      C = C + 1
|     Return A to B

   Oracle VerO(A)
   --------------
|     i = C'
|     While (i <= C' + s - 1 and Win == FALSE) do
|        If A == ALG(K,i) then Win = TRUE; C' = i + 1
         Else i = i + 1
      Return Win to B

Notes:

another typo, and continuation of Errata ID 2402.

Still in Appendix A.3, the text on the upper half of page 19 contains
a wrong (undefined) variable name 'O' which should be 'A' instead,
and it should be adapted according to [Errata ID 2402].

Errata ID: 2406
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT

Reported By: Alfred Hoenes
Date Reported: 2006-01-18
Held for Document Update by: Tim Polk
Date Held: 2011-03-27

Appendix A.4.3 says:

   Proposition 2 ------------- Suppose m = 10^Digit < 2^31, and let
   (q,r) = IntDiv(2^31,m).  Let B be any adversary attacking HOTP-IDEAL
   using v verification oracle queries and a <= 2^c - s authenticator
   oracle queries.  Then [...]

It should say:

  Proposition 2
  -------------

  Suppose m = 10^Digit < 2^31, and let (q,r) = IntDiv(2^31,m).  Let B
  be any adversary attacking HOTP-IDEAL using v verification oracle
  queries and a <= 2^c - s authenticator oracle queries.  Then  [...]

Errata ID: 2408
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT

Reported By: Alfred Hoenes
Date Reported: 2006-01-18
Held for Document Update by: Sean Turner
Date Held: 2010-07-30

Section C says:

       // These are used to calculate the check-sum digits.
|      //                                0  1  2  3  4  5  6  7  8  9
       private static final int[] doubleDigits =
                       { 0, 2, 4, 6, 8, 1, 3, 5, 7, 9 };

It should say:

       // These are used to calculate the check-sum digits.
|      //                0  1  2  3  4  5  6  7  8  9
       private static final int[] doubleDigits =
                       { 0, 2, 4, 6, 8, 1, 3, 5, 7, 9 };

Notes:

formatting.

In Appendix C, the source text in the upper half of page 28
contains an improperly formatted comment -- obviously intended
to illustrate the subsequent declaration, the comment must be
aligned with that declaration.

Errata ID: 2401
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT

Reported By: Alfred Hoenes
Date Reported: 2006-01-18
Held for Document Update by: Sean Turner
Date Held: 2010-07-30

Section A.1 says:

   Let IntDiv(a,b) denote the integer division algorithm that takes
|  input integers a, b where a >= b >= 1 and returns integers (q,r)
|
   the quotient and remainder, respectively, of the division of a by b.
   (Thus, a = bq + r and 0 <= r < b.)

It should say:

   Let IntDiv(a,b) denote the integer division algorithm that takes
|  input integers a, b where  b >= 1  and returns integers (q,r), the
   quotient and remainder, respectively, of the division of a by b.
   (Thus, a = bq + r and 0 <= r < b.)

Notes:

inappropriate restriction specified + formatting flaw.

On page 17, Appendix A.1:
The restriction "a >= b" is not necessary and in fact inappropriate; the additional blank line seems to be an artifact of the editing process. Thus, the above text should better read [as above].

Errata ID: 834
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT

Reported By: Alfred Hoenes
Date Reported: 2006-01-18
Held for Document Update by: Sean Turner
Date Held: 2010-07-30

Section E.4 says:

   1) C-client >= C-server
   2) C-client - C-server <= s
   3) Check that HOTP client is valid HOTP(K,C-Client)
   4) If true, the server sets C to C-client + 1 and client is
      authenticated                           ^^^
                              ^^^             ^^^

It should say:

   1) C-client >= C-server
   2) C-client - C-server <= s
|  3) Check that HOTP client is valid HOTP(K,C-client)
|  4) If true, the server sets C-server to C-client + 1 and client is
      authenticated

Notes:

Lines up with Errata ID 2402.

The enumeration in Appendix E.4, on page 34, contains inconsistent
variable namings (cf. [Errata ID 2402]!).
To make it self-consistent, change as detailed.

Errata ID: 2405
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT

Reported By: Alfred Hoenes
Date Reported: 2006-01-18
Held for Document Update by: Sean Turner
Date Held: 2010-07-30

Section A.4.1 says:

(6)  [ typos in mathematical text ]

Lemma 1 and its proof in Appendis A.4.1, on page 20, contains
several typos.

In Lemma 1, the line,

          P_{N,m}(z) = Pr [x mod m = z : x randomly pick in Z_{n}]
                                                              ^^^
should read:

          P_{N,m}(z) = Pr [x mod m = z : x randomly pick in Z_{N}]

This corrects the use of an undefined variable, n, by using the
variable N as expected from the LHS term.

In the Proof of Lemma 1, the case distinction for z contains an
improper relational operator at two places.
To adjust to the possible range of values (cf. item (2) above!),
the formula parts:

   P_{N,m}(z)  =  [ ... ]

                = mq/N * 1/m +
                   (N - mq)/N * 1 / (N - mq)     if 0 <= z < N - mq
|                  0                             if N - mq <= z <= m
                                                               ^^^^
                = q/N +
                   r/N * 1 / r                   if 0 <= z < N - mq
|                  0                             if r <= z <= m
                                                          ^^^^
should be modified to read:

   P_{N,m}(z)  =  [ ... ]

                = mq/N * 1/m +
                   (N - mq)/N * 1 / (N - mq)     if 0 <= z < N - mq
|                  0                             if N - mq <= z < m

                = q/N +
                   r/N * 1 / r                   if 0 <= z < N - mq
|                  0                             if r <= z < m

It should say:

see above

Notes:

typos

Errata ID: 2402
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT

Reported By: Alfred Hoenes
Date Reported: 2006-01-18
Held for Document Update by: Sean Turner
Date Held: 2010-07-30

Section A.3 says:

   The scenario we are considering is that a user and server share a key
   K for ALG.  Both maintain a counter C, initially zero, and the user
   authenticates itself by sending ALG(K,C) to the server.  The latter
   accepts if this value is correct.

   In order to protect against accidental increment of the user counter,
   the server, upon receiving a value z, will accept as long as z equals
   ALG(K,i) for some i in the range C,...,C + s-1, where s is the
   resynchronization parameter and C is the server counter.  If it
   accepts with some value of i, it then increments its counter to i+1.
   If it does not accept, it does not change its counter value.

It should say:

   The scenario we are considering is that a user and server share a key
|  K for ALG.  Both maintain a counter C and C', respectively, initially
   zero, and the user authenticates itself by sending ALG(K,C) to the
   server.  The latter accepts if this value is correct.

   In order to protect against accidental increment of the user counter,
   the server, upon receiving a value z, will accept as long as z equals
|  ALG(K,i) for some i in the range C',...,C' + s-1, where s is the
|  resynchronization parameter and C' is the server counter.  If it
   accepts with some value of i, it then increments its counter to i+1.
   If it does not accept, it does not change its counter value.

Notes:

conflicting naming of variables.

re: the text of the 2nd and 3rd paragraph of Appendix A.3, on page 18

In Appendix A.3, unfortunately the necessary distinction between
the counter value kept with the user and the counter value kept
at the server is not preserved in the variable names introduced.
This leads to significant confusion.

I hereby propose a 'minimally invasive' text modification as
[shown] (Cf. Appendix E.3 for another notation).

Errata ID: 5792
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT

Reported By: Jeffrey Goldberg
Date Reported: 2019-07-24
Held for Document Update by: Benjamin Kaduk
Date Held: 2019-07-29

Section 5.3 says:

Implementations MUST extract a 6-digit code at a minimum and possibly
7 and 8-digit code.  Depending on security requirements, Digit = 7 or
more SHOULD be considered in order to extract a longer HOTP value.

It should say:

Implementations MUST extract a 6-digit code at a minimum and possibly
7, 8 and 9-digit code.  Depending on security requirements, Digit = 7
or more SHOULD be considered in order to extract a longer HOTP value.
The code MUST NOT exceed 9 digits. 

Notes:

Although the detailed description of the dynamic truncation algorithm makes is clear that the code is generated from a 31 bit value, it is not explicitly stated in the main sections of the RFC that nine digits is the maximum number of digits supported by the algorithm.

The fact that nine digits is the maximum supported is alluded to in E.2, but this should be made more clear.

There are reports that TOTP implementations in the wild are supporting 10 digit codes. That mistaken behavior would be better discouraged by clarifying the limit of digits to 9.

Errata ID: 2400
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

Reported By: Alfred Hoenes
Date Reported: 2006-01-18
Held for Document Update by: Sean Turner
Date Held: 2010-07-30

Section 5.3 says:

   The reason for masking the most significant bit of P is to avoid
   confusion about signed vs. unsigned modulo computations.  Different
   processors perform these operations differently, and masking out the
|  signed bit removes all ambiguity.
       ^^
   Implementations MUST extract a 6-digit code at a minimum and possibly
   7 and 8-digit code.  Depending on security requirements, Digit = 7 or
   more SHOULD be considered in order to extract a longer HOTP value.

It should say:

   The reason for masking the most significant bit of P is to avoid
   confusion about signed vs. unsigned modulo computations.  Different
   processors perform these operations differently, and masking out the
|  sign bit removes all ambiguity.

   Implementations MUST extract a 6-digit code at a minimum and possibly
|  7 and 8-digit codes.  Depending on security requirements, Digit = 7
   or more SHOULD be considered in order to extract a longer HOTP value.

Notes:

Editorial fixes.

re: the text of Section 5.3, in the 2nd and 3rd paragraph on page 7.

Errata ID: 2403
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

Reported By: Alfred Hoenes
Date Reported: 2006-01-18
Held for Document Update by: Sean Turner
Date Held: 2010-07-30

Section A.3 says:

                                                    ...  It wins if the
   server accepts this accumulator.
                       ^^^^^^^^^^^

It should say:

                                                    ...  It wins if the
   server accepts this authenticator.

Notes:

typo. near the bottom of page 18, the 2nd-to-last paragraph of Appendix A.3
(on that page).

Errata ID: 2407
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

Reported By: Alfred Hoenes
Date Reported: 2006-01-18
Held for Document Update by: Sean Turner
Date Held: 2010-07-30

Section A.5 says:

   Let T denotes the time to perform one computation of H.  [...]
               ^

It should say:

   Let T denote the time to perform one computation of H.  [...]

Notes:

typo. within Appendix A.5, in the lower half of page 23, the text for
"Assumption 1".

Errata ID: 2409
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

Reported By: Alfred Hoenes
Date Reported: 2006-01-18
Held for Document Update by: Sean Turner
Date Held: 2010-07-30

Section C says:

In Appendix C, the source code on page 30 (lower half) and
page 31 contains improperly indented lines.

The following three line groups should be indented by 6 more character
positions to make them conformant to RFC style 'nice' format:

- on page 30:

     String result = null;
     int digits = addChecksum ? (codeDigits + 1) : codeDigits;

- on page 30:

     if ( (0<=truncationOffset) &&
            (truncationOffset<(hash.length-4)) ) {
         offset = truncationOffset;
     }

- on page 31:

     if (addChecksum) {
         otp =  (otp * 10) + calcChecksum(otp, codeDigits);
     }
     result = Integer.toString(otp);
     while (result.length() < digits) {
         result = "0" + result;
     }
     return result;

It should say:

 [see above]

Notes:

[ further formatting (indentation) issues ]

Status: Rejected (1)

RFC 4226, "HOTP: An HMAC-Based One-Time Password Algorithm", December 2005

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 6181
Status: Rejected
Type: Technical
Publication Format(s) : TEXT

Reported By: Yishuai Li
Date Reported: 2020-05-18
Rejected by: Benjamin Kaduk
Date Rejected: 2020-05-30

Section E.4 says:

   The server accepts if the following are all true, where C-server is
   its own current counter value:

   1) C-client >= C-server
   2) C-client - C-server <= s
   3) Check that HOTP client is valid HOTP(K,C-Client)
   4) If true, the server sets C to C-client + 1 and client is
      authenticated

   In this case, there is no need for managing a look-ahead window
   anymore.  The probability of success of the adversary is only v/10^6
   or roughly v in one million.  A side benefit is obviously to be able
   to increase s "infinitely" and therefore improve the system usability
   without impacting the security.

It should say:

   The server accepts if the following are all true, where C-server is
   its own current counter value:

   1) C-client >= C-server
   2) Check that HOTP client is valid HOTP(K,C-Client)
   3) If true, the server sets C to C-client + 1 and client is
      authenticated

   In this case, there is no need for managing a look-ahead window
   anymore.  The probability of success of the adversary is only v/10^6
   or roughly v in one million.  A side benefit is obviously to be able
   to increase C-server "infinitely" and therefore improve the system usability
   without impacting the security.

Notes:

1. Resynchronization should be allowed when C-client - C-server > s.
2. The look-ahead window s should not be increased.
--VERIFIER NOTES--
The proposed new text provides behavior equivalent to the behavior allowed by the old text with respect to the possibility of resynchronization in the face of large C-client/C-server skew.

Report New Errata



Advanced Search