Access Controls (99-245r6), Override of Lost Keys protocol (longish posting)

chamb at almaden.ibm.com chamb at almaden.ibm.com
Thu Mar 16 17:22:47 PST 2000


* From the T10 Reflector (t10 at t10.org), posted by:
* chamb at almaden.ibm.com
*



Gerry_Houlder at notes.seagate.com notes:

> (a) If the timer should always restart after resets, someone could
prevent
> the old key from being overridden by doing resets on the bus just a
little
> more frequently than the initial timer value. If the initial timer value
is
> something like 5 or 10 minutes, this probably isn't likely for normal
use.
> If the initial timer value is more than an hour, this could be a problem.
>
> (b) Do you include logins and/or logouts (on FC interface) in the same
> category as a reset? Or LIP where everyone simply reconfigures to
possibly
> a new ID?


I think the real need is that a *power on* will reset the timer, and that
lesser reset actions will not cause the timer value to decrease.  Neither
startup after a power outage nor reset actions should open up an
opportunity
for an unauthorized override.

It is simpler not to require a target to maintain a persistent (if lazy)
record of the timer's progress.

Is it common practice to issue periodic resets on a shared bus?
In such an environment, if the target resets the timer on every reset,
PAM could detect this by examining the return data that will show
how far the timer has expired.  Then PAM could set the value short
enough to avoid the problem.


David Chambliss
Research Staff Member, Computer Science /Storage Systems
IBM Research Division
(408) 927-2243  (TL 457-2243)
FAX (408) 927-3497


*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org




More information about the T10 mailing list