Errata Search
RFC Number:		Errata ID:
Source of RFC		Status:	All/Any Verified+Reported Verified Reported Held for Document Update Rejected
Area Acronym:	All/Any app art gen int ops rai rtg sec tsv wit	Type:	All/Any Editorial Technical
WG Acronym:		Submitter Name:
Other:	All/Any IAB INDEPENDENT IRTF Legacy Editorial	Date Submitted:
Summary Table Full Records

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

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

---

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).

Report New Errata