On Aug 24, 2011, at 5:45 PM, david(_dot_)black(_at_)emc(_dot_)com 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(_dot_)B(_dot_)Hotz(_at_)jpl(_dot_)nasa(_dot_)gov, or
hbhotz(_at_)oxy(_dot_)edu
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf