On Aug 24, 2011, at 5:45 PM, david.black@xxxxxxx 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. Henry.B.Hotz@xxxxxxxxxxxx, or hbhotz@xxxxxxx _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf