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 IESG member
Yes
Yes () Unknown

                            
Bert Wijnen Former IESG member
No Objection
No Objection () Unknown

                            
Bill Fenner Former IESG member
No Objection
No Objection () Unknown

                            
Brian Carpenter Former IESG member
No Objection
No Objection (2005-05-26) Unknown
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 IESG member
No Objection
No Objection () Unknown

                            
Margaret Cullen Former IESG member
No Objection
No Objection () Unknown

                            
Mark Townsley Former IESG member
No Objection
No Objection () Unknown

                            
Scott Hollenbeck Former IESG member
No Objection
No Objection (2005-05-24) Unknown
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 IESG member
No Objection
No Objection () Unknown