Skip to main content

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

Yes

(Russ Housley)

No Objection

(Bert Wijnen)
(Bill Fenner)
(David Kessens)
(Margaret Cullen)
(Mark Townsley)
(Ted Hardie)

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

(Russ Housley; former steering group member) Yes

Yes ()

                            

(Bert Wijnen; former steering group member) No Objection

No Objection ()

                            

(Bill Fenner; former steering group member) No Objection

No Objection ()

                            

(Brian Carpenter; former steering group member) No Objection

No Objection (2005-05-26)
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?

(David Kessens; former steering group member) No Objection

No Objection ()

                            

(Margaret Cullen; former steering group member) No Objection

No Objection ()

                            

(Mark Townsley; former steering group member) No Objection

No Objection ()

                            

(Scott Hollenbeck; former steering group member) No Objection

No Objection (2005-05-24)
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.

(Ted Hardie; former steering group member) No Objection

No Objection ()