Investigate provisions for resynchronization

[rietta]

6.  Resynchronization

   Because of possible clock drifts between a client and a validation
   server, we RECOMMEND that the validator be set with a specific limit
   to the number of time steps a prover can be "out of synch" before
   being rejected.

   This limit can be set both forward and backward from the calculated
   time step on receipt of the OTP value.  If the time step is
   30 seconds as recommended, and the validator is set to only accept
   two time steps backward, then the maximum elapsed time drift would be
   around 89 seconds, i.e., 29 seconds in the calculated time step and
   60 seconds for two backward time steps.

   This would mean the validator could perform a validation against the
   current time and then two further validations for each backward step
   (for a total of 3 validations).  Upon successful validation, the
   validation server can record the detected clock drift for the token
   in terms of the number of time steps.  When a new OTP is received
   after this step, the validator can validate the OTP with the current
   timestamp adjusted with the recorded number of time-step clock drifts
   for the token.

   Also, it is important to note that the longer a prover has not sent
   an OTP to a validation system, the longer (potentially) the
   accumulated clock drift between the prover and the verifier.  In such
   cases, the automatic resynchronization described above may not work
   if the drift exceeds the allowed threshold.  Additional
   authentication measures should be used to safely authenticate the
   prover and explicitly resynchronize the clock drift between the
   prover and the validator.