ietf
[Top] [All Lists]

RE: [Ietf-krb-wg] Gen-ART review of draft-ietf-krb-wg-otp-preauth-18

2011-08-26 11:09:32

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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf