Draft: draft-mraihi-oath-hmac-otp-04
Review: Lakshminath Dondeti 
Date: 25 maj 2005 1 


I-D: draft-mraihi-oath-hmac-otp-04
Title:  HOTP: An HMAC-based One Time Password Algorithm
Authors: D. M'Raihi, M. Bellare, F. Hoornaert, D. Naccache, O. Ranen
Intended Status: Informational (but contains BCP 14 keywords)

Reviewer:  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? 

+++++++++++++++IDnits output +++++++++++++

IDnits complains that there in no Security Considerations section,
however there is one.  I think it is perhaps because of the order the
section is present in this document.  Usually it is just before the
IANA considerations.  It also thinks there is no Introduction section,
perhaps because that Section is not Section 1.  I am going to send the
output to the tools list to see if they can chime in. :-) 

bash-2.05b$ ./idnits --verbose draft-mraihi*
idnits 1.72

draft-mraihi-oath-hmac-otp-04.txt:

draft-mraihi-oath-hmac-otp-04.txt(268): Line has weird spacing: '...  Digit    n
um...'
draft-mraihi-oath-hmac-otp-04.txt(1432): Line has weird spacing: '...eyBytes   t
he ...'
draft-mraihi-oath-hmac-otp-04.txt(1475): Line has weird spacing: '...eDigits   t
he ...'
draft-mraihi-oath-hmac-otp-04.txt(1477): Line has weird spacing: '...hecksum  a
fla...'
draft-mraihi-oath-hmac-otp-04.txt(1482): Line has weird spacing: '...ncation  wi
ll ...'


 Checking nits according to http://www.ietf.org/ID-Checklist.html :

 * The document seems to lack an Introduction section.
 * The document seems to lack a Security Considerations section.
 * The document seems to lack an IANA Considerations section.
 * The document seems to lack an Authors' Addresses Section.
   Checking conformance with RFC 3978/3979 boilerplate...
   the boilerplate looks good.

 Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt :

   Nothing found here (but these checks does not cover all of
   1id-guidelines.txt yet).

 Miscellaneous warnings:

   None.

bash-2.05b$