ietf
[Top] [All Lists]

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

2011-08-26 11:07:39
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(_at_)jpl(_dot_)nasa(_dot_)gov
Cc: Black, David; ietf(_at_)ietf(_dot_)org; hartmans-ietf(_at_)mit(_dot_)edu; 
ietf-krb-wg(_at_)lists(_dot_)anl(_dot_)gov
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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf