> 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). That new text is fine. My primary concern with the existing text is that the server has to do something like this for all the cases except when the clock in a clock-based token is slightly slow, but the existing text doesn't indicate that such server action may be needed. The proposed new text does so, and the reference to section 7.4 of RFC 4226 is a good addition that makes the point clear. Thanks, --David > -----Original Message----- > From: Richards, Gareth > Sent: Friday, August 26, 2011 10:45 AM > To: hotz@xxxxxxxxxxxx > Cc: Black, David; ietf@xxxxxxxx; hartmans-ietf@xxxxxxx; ietf-krb-wg@xxxxxxxxxxxxx > Subject: RE: [Ietf-krb-wg] Gen-ART review of draft-ietf-krb-wg-otp-preauth-18 > > > > > > 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