HOTP: An HMAC-Based One-Time Password Algorithm
RFC 4226

Note: This ballot was opened for revision 04 and is now closed.

(Russ Housley) Yes

(Brian Carpenter) No Objection

Comment (2005-05-26)
No email
send info
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?

(Margaret Cullen) No Objection

(Bill Fenner) No Objection

(Ted Hardie) No Objection

(Scott Hollenbeck) No Objection

Comment (2005-05-24)
No email
send info
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.

(David Kessens) No Objection

(Mark Townsley) No Objection

(Bert Wijnen) No Objection