RFC Errata
RFC 4226, "HOTP: An HMAC-Based One-Time Password Algorithm", December 2005
Source of RFC: IETF - NON WORKING GROUPArea 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.