Skip to main content

TOTP: Time-Based One-Time Password Algorithm
RFC 6238

Yes

(Sean Turner)

No Objection

(Alexey Melnikov)
(Dan Romascanu)
(Gonzalo Camarillo)
(Ralph Droms)
(Robert Sparks)
(Ron Bonica)

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

(Sean Turner; former steering group member) Yes

Yes ()

                            

(Alexey Melnikov; former steering group member) (was Discuss) No Objection

No Objection (2011-02-26)

                            

(Dan Romascanu; former steering group member) (was Discuss) No Objection

No Objection ()

                            

(Gonzalo Camarillo; former steering group member) No Objection

No Objection ()

                            

(Jari Arkko; former steering group member) No Objection

No Objection (2011-02-17)
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.

(Peter Saint-Andre; former steering group member) No Objection

No Objection (2011-02-15)
I concur with with the discusses from Dan Romascanu, Robert Sparks, and Alexey Melnikov.

(Ralph Droms; former steering group member) No Objection

No Objection ()

                            

(Robert Sparks; former steering group member) (was Discuss) No Objection

No Objection (2011-02-23)

                            

(Ron Bonica; former steering group member) No Objection

No Objection ()

                            

(Russ Housley; former steering group member) No Objection

No Objection (2011-02-16)
  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?