> > > In section 2.4, the following sentence is potentially confusing: > > > > For example, > > event-based tokens may drift since the counter on the token is > > incremented every time the token is used but the counter on the > > server is only incremented on an authentication. Similarly, the > > clocks on time-based tokens may drift. > > > > The confusion arises because the resync mechanism described in that > section causes > > the client to use the next token value. By itself, that won't help > when an event based > > has gotten ahead of the server; using the next value only puts the > token further ahead. > > Similarly, by itself, this mechanism does not help if the token clock > has drifted ahead > > of the server clock, but does help if the token clock has drifted > behind. A little more > > explanation of what the server can do to take advantage of this > mechanism (e.g., how to > > deal with an event-based token that is ahead of the server) would > reduce the confusion. > > Possibly there is something in RFC4226, section 7.4 which could be > referenced or re-used? It seems to assume that the server itself knows > the token seed, which may not be a valid assumption, so perhaps not. Resynchronization in the algorithms I am familiar with involves the server resetting its OTP search window and the system in the ID allows the client to send an additional value to help the server do this. This is just as described in RFC4226. How about the following clarification text: Methods to recover from this type of situation are OTP algorithm specific but may involve the client sending a sequence of OTP values to allow the server to further validate the correct position in its search window (see section 7.4 of [RFC4226] for an example). --Gareth _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf