Skip to main content

HOTP: An HMAC-Based One-Time Password Algorithm
draft-mraihi-oath-hmac-otp-04

Revision differences

Document history

Date Rev. By Action
2020-01-21
04 (System) Received changes through RFC Editor sync (added Verified Errata tag)
2018-12-20
04 (System)
Received changes through RFC Editor sync (changed abstract to 'This document describes an algorithm to generate one-time password values, based on Hashed Message Authentication Code …
Received changes through RFC Editor sync (changed abstract to 'This document describes an algorithm to generate one-time password values, based on Hashed Message Authentication Code (HMAC). A security analysis of the algorithm is presented, and important parameters related to the secure deployment of the algorithm are discussed. The proposed algorithm can be used across a wide range of network applications ranging from remote Virtual Private Network (VPN) access, Wi-Fi network logon to transaction-oriented Web applications.

This work is a joint effort by the OATH (Open AuTHentication) membership to specify an algorithm that can be freely distributed to the technical community. The authors believe that a common and shared algorithm will facilitate adoption of two-factor authentication on the Internet by enabling interoperability across commercial and open-source implementations. This memo provides information for the Internet community.')
2017-05-16
04 (System) Changed document authors from "Frank Hoornaert, David Naccache, Mihir Bellare, Ohad Ranen" to "Frank Hoornaert, David Naccache, Mihir Bellare, Ohad Ranen, Mountain View, David M'Raihi"
2009-02-25
(System) Posted related IPR disclosure: VeriSign's Statement about IPR related to draft-mraihi-mutual-oath-hotp-variants, draft-mraihi-totp-timebased, draft-ietf-keyprov-dskpp, draft-ietf-keyprov-pskc, and RFC 4226
2009-02-18
(System) Posted related IPR disclosure: VeriSign's Statement about IPR related to draft-ietf-keyprov-pskc, draft-ietf-keyprov-dskpp, draft-mraihi-totp-timebased, draft-mraihi-mutual-oath-hotp-variants, and RFC 4226
2005-12-27
04 Amy Vezza State Changes to RFC Published from RFC Ed Queue by Amy Vezza
2005-12-27
04 Amy Vezza [Note]: 'RFC 4226' added by Amy Vezza
2005-12-23
04 (System) RFC published
2005-06-12
04 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2005-05-31
04 Amy Vezza IESG state changed to Approved-announcement sent
2005-05-31
04 Amy Vezza IESG has approved the document
2005-05-31
04 Amy Vezza Closed "Approve" ballot
2005-05-27
04 Amy Vezza State Changes to Approved-announcement to be sent from IESG Evaluation by Amy Vezza
2005-05-27
04 (System) Removed from agenda for telechat - 2005-05-26
2005-05-26
04 Margaret Cullen [Ballot Position Update] New position, No Objection, has been recorded for Margaret Wasserman by Margaret Wasserman
2005-05-26
04 Mark Townsley [Ballot Position Update] New position, No Objection, has been recorded for Mark Townsley by Mark Townsley
2005-05-26
04 Bert Wijnen [Ballot Position Update] New position, No Objection, has been recorded for Bert Wijnen by Bert Wijnen
2005-05-26
04 Brian Carpenter
[Ballot comment]
Review by Lakshminath Dondeti

Draft is generally ready to move forward as Informational RFC, but needs Editorial fixes before publication.

* Editorial issues: …
[Ballot comment]
Review by Lakshminath Dondeti

Draft is generally ready to move forward as Informational RFC, but needs Editorial fixes before publication.

* Editorial issues:
---------------------

ID-checklist says there shouldn't be a reference in the Abstract (RFC Editor will force this later on).

In Section 3, please replace RFC 2119 with BCP 14, and cite BCP 14.  (I am told RFC #2119 could be ephemeral, but BCP 14 would be long(er)-living).

In Section 4, the paragraph describing "R5" refers to a non-existent Section 8.4.  6.4 is not about resynchronization, Section 6.5 is.

Section 5.3.  Step 3, 2nd line says Snum = StToNum(S)
Q: Since Step 2 is Sbits = DT(HS), shouldn't S above be Sbits?

Section 6:  Shouldn't this section be after the algorithm overview etc?

The sentence preceding Section 6.1 is dangling.  "Other mechanisms should be used to defeat ..."  please complete the sentence.

As I read Section 6, I think perhaps this should be renamed Security requirements.

6.1.  Please rewrite requirement RP1.
P is defined earlier as a protocol implementing HOTP as the authentication method.
RP1 states that "P MUST be two-factor," and goes on to elaborate on the meaning of two-factor.  A protocol cannot be a two-factor though.  (note: Just needs clarifying text).

RP3:  "state of the art" and "usual attacks and risks" tend to mean different things to different people.  Please state what is required.

6.3 Last paragraph: Does HOTP require SSL?  Why can't this be used for client authentication in IPsec RAS connections?  Perhaps a generic term such as secure channel could be used with SSL/TLS and IPsec as examples?

Section 6.6.  Does HSM stand for Hardware security module?  Please expand the first use of HSM.

Section 10.  If the suggestion to rename Section 6 is followed, this could renamed "Security Considerations" with some additional text.
Section 13 has 12.1 and 12.2 as subsections.  Please renumber here and in the ToC.

Note: This review does not include a review of the appendices.  Q: Has this been circulated to the CFRG list?
2005-05-26
04 Brian Carpenter
[Ballot comment]
Lakshminath Dondeti

Draft is generally ready to move forward as Informational RFC, but needs Editorial fixes before publication.

* Editorial issues:
---------------------

ID-checklist …
[Ballot comment]
Lakshminath Dondeti

Draft is generally ready to move forward as Informational RFC, but needs Editorial fixes before publication.

* Editorial issues:
---------------------

ID-checklist says there shouldn't be a reference in the Abstract (RFC Editor will force this later on).

In Section 3, please replace RFC 2119 with BCP 14, and cite BCP 14.  (I am told RFC #2119 could be ephemeral, but BCP 14 would be long(er)-living).

In Section 4, the paragraph describing "R5" refers to a non-existent Section 8.4.  6.4 is not about resynchronization, Section 6.5 is.

Section 5.3.  Step 3, 2nd line says Snum = StToNum(S)
Q: Since Step 2 is Sbits = DT(HS), shouldn't S above be Sbits?

Section 6:  Shouldn't this section be after the algorithm overview etc?

The sentence preceding Section 6.1 is dangling.  "Other mechanisms should be used to defeat ..."  please complete the sentence.

As I read Section 6, I think perhaps this should be renamed Security requirements.

6.1.  Please rewrite requirement RP1.
P is defined earlier as a protocol implementing HOTP as the authentication method.
RP1 states that "P MUST be two-factor," and goes on to elaborate on the meaning of two-factor.  A protocol cannot be a two-factor though.  (note: Just needs clarifying text).

RP3:  "state of the art" and "usual attacks and risks" tend to mean different things to different people.  Please state what is required.

6.3 Last paragraph: Does HOTP require SSL?  Why can't this be used for client authentication in IPsec RAS connections?  Perhaps a generic term such as secure channel could be used with SSL/TLS and IPsec as examples?

Section 6.6.  Does HSM stand for Hardware security module?  Please expand the first use of HSM.

Section 10.  If the suggestion to rename Section 6 is followed, this could renamed "Security Considerations" with some additional text.
Section 13 has 12.1 and 12.2 as subsections.  Please renumber here and in the ToC.

Note: This review does not include a review of the appendices.  Q: Has this been circulated to the CFRG list?
2005-05-26
04 Brian Carpenter [Ballot Position Update] New position, No Objection, has been recorded for Brian Carpenter by Brian Carpenter
2005-05-26
04 Bill Fenner [Ballot Position Update] New position, No Objection, has been recorded for Bill Fenner by Bill Fenner
2005-05-25
04 David Kessens [Ballot Position Update] New position, No Objection, has been recorded for David Kessens by David Kessens
2005-05-25
04 Michelle Cotton IANA Comments:
We understand this document to have no IANA Actions.
2005-05-24
04 Ted Hardie [Ballot Position Update] New position, No Objection, has been recorded for Ted Hardie by Ted Hardie
2005-05-24
04 Scott Hollenbeck
[Ballot comment]
Not a discuss since this is an Informational document and these are editorial issues:

There probably shouldn't be a reference in the Abstract. …
[Ballot comment]
Not a discuss since this is an Informational document and these are editorial issues:

There probably shouldn't be a reference in the Abstract.

Please expand the HOTP acronym on first use in Section 1.

Please add cite RFC 2119 in Section 3.
2005-05-24
04 Scott Hollenbeck
[Ballot comment]
Not a discuss since this is an Informational document and these are editorial issues:

There probably shouldn't be a reference in the Abstract. …
[Ballot comment]
Not a discuss since this is an Informational document and these are editorial issues:

There probably shouldn't be a reference in the Abstract.

Please expand the HOTP algorithm on first use in Section 1.

Please add cite RFC 2119 in Section 3.
2005-05-24
04 Scott Hollenbeck [Ballot Position Update] New position, No Objection, has been recorded for Scott Hollenbeck by Scott Hollenbeck
2005-05-19
04 Russ Housley Placed on agenda for telechat - 2005-05-26 by Russ Housley
2005-05-19
04 Russ Housley [Ballot Position Update] New position, Yes, has been recorded for Russ Housley
2005-05-19
04 Russ Housley Ballot has been issued by Russ Housley
2005-05-19
04 Russ Housley Created "Approve" ballot
2005-05-19
04 (System) Ballot writeup text was added
2005-05-19
04 (System) Last call text was added
2005-05-19
04 (System) Ballot approval text was added
2005-05-19
04 Russ Housley State Changes to IESG Evaluation from AD Evaluation::External Party by Russ Housley
2005-05-19
04 (System) New version available: draft-mraihi-oath-hmac-otp-04.txt
2005-04-18
04 Russ Housley State Changes to AD Evaluation::External Party from AD Evaluation by Russ Housley
2005-04-18
04 Russ Housley State Changes to AD Evaluation from Publication Requested by Russ Housley
2005-04-18
04 Russ Housley Draft Added by Russ Housley in state Publication Requested
2005-04-18
03 (System) New version available: draft-mraihi-oath-hmac-otp-03.txt
2005-02-10
02 (System) New version available: draft-mraihi-oath-hmac-otp-02.txt
2004-10-21
01 (System) New version available: draft-mraihi-oath-hmac-otp-01.txt
2004-10-19
00 (System) New version available: draft-mraihi-oath-hmac-otp-00.txt