On Aug 24, 2011, at 5:45 PM, [email protected] wrote: > 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. ------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [email protected], or [email protected] _______________________________________________ Ietf mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf
