TOTP: Time-Based One-Time Password Algorithm
draft-mraihi-totp-timebased-08

Some comments from Ari Keränen who helped me with some of the
reviews today:

3.  Algorithm Requirements

   R1 - The prover (e.g. token, soft token) and verifier (authentication
   or validation server) MUST have access to the Unix Time

A reference to, or explicit definition of, Unix Time would be good already here. "MUST have access to" sounds a bit misleading since any time reference where one can derive the unix time should be OK. Also, should mention how well synchronized the clocks need to be (or at least refer to sec 6).

Perhaps could say something like "MUST know or be able to derive the current Unix Time (explanation-of-unix-time-here) with precision of (precision-requirements-here)".


   R8 - The TOTP algorithm SHOULD be used for online application.

What does this requirement exactly mean? {All, Only, ?} on-line apps should use TOTP?


5.2.  Validation and Time-step Size

   Secondly, the next different OTP must be generated in the next Time-
   step window.  A user must wait till the clock moves to the next Time-
   step window from the last submission. 

s/must be generated/can only be generated/ ?

Should also mention/warn about the Year 2038 problem with 32-bit unix time stamps.


6.  Resynchronization

Why is this section after the security considerations? I would switch the order of sections 5 and 6.

I concur with with the discusses from Dan Romascanu, Robert Sparks, and Alexey Melnikov.

  Please consider the questions raised on the Gen-ART Review by
  Ben Campbell on 14-Feb-2011.  He asks about Section 5.2:

  Is there a requirement that the proover must not make a second
  attempt inside a given time window? If so, that was not clear
  from the text.  If there is not such a requirement, are there
  security implications if the proover does send multiple messages
  inside the same tick?  It is not really a one time pad if that
  happens is it?