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

[hafner at almaden.ibm.com]

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


Folks,

One of the major issues that has resisted consensus in the Access Controls
proposal (99-245r6) is the mechanism for overriding lost keys.

Any comments/discussions on the model suggested here are welcome:

Here's the error scenario:
We have a fully functioning SAN, with PAM application governing the
allocation
of resources using Access Controls.  Each target has been given a
Management
Identifier Key (by PAM) and this key is required for PAM to change the
access
controls state of the device.  PAM maintains an inventory of devices which
includes
the key she uses to manage each device and the access controls she has
set up for each device.  [PAM of course is a 24/7 application (or at least
her
database is 24/7) so PAM should, in practice never forget the keys.]
Suppose PAM forgets the keys.  How can she recover access controls
management over the targets?  Note that in this scenario, the SAN is
still functioning happily and all access controls are still in place.  They
just
can't be changed until PAM can get a new key in place at each target.

Here is a proposed solution to the problem which we hope meets
all the requirements (this is mostly due to Ralph Weber with some
additional
sculpting by David Chambliss, IBM, and myself).  It falls under the "state
machine" category as described in 99-245r6, section 2.1.3.7.1 but includes
features of the "fingerprint" category as well.

Keep in mind that we're only concerned about the issue of "overriding the
key"
without knowledge of what the target thinks the key should be.   "Changing
the key" with the old key is not the issue.

Here are the model generalities:

The target (access controls coordinator) has a configurable count-down
timer (a non-negative integer), decrementing once per second.

If the timer is not zero ("state machine"), then any attempt to override
the
key fails and is logged (with info about the initiator doing the attempt --
"fingerprints").  If the timer is zero, then the override try will succeed.

An initiator can set the value of the initial state of the timer and check
the current value of the timer and the current initial state with
Key-validated command (in other words, only PAM can do this function).
Any initiator (without the key) can restart the timer to its current
initial value.

Positive aspects of this model:
1) we don't require any physical access or private data to override
keys.
2) the method is standard and programmatic
3) PAM can configure the initial state of the timers for each target
in deployment specific way (including setting the value to zero if
she has no concerns about inadvertant override).
4) PAM doesn't really need to do much to keep the devices in the
"non-overrideable" state; she (or her dumb agents) can restart
the timers whenever she/they want with very little overhead in the
target, themselves or the fabric.
5) PAM or her agents don't need to be reactive to override attempts;
she's effectively pre-empting them.
6) Override can occur once the timers have expired; PAM can get
devices to this state simply by getting everybody to stop sending
the "restart".
6) If someone tries to force everybody from restarting the timers
(e.g., denial of service) in order to force them to expire, then
ALL service to the affected targets will be suspended.  This state is
no more or less of a problem than simple denial of service for its
own sake and presumably is either not part of the threat model
or has been addressed already (i.e., it's independent of the timer
reset problem).

Two additional details about the timers:
- Initial timer values should be persistent (non-volatile).
-Timers should always restart after resets.

The only real problems I see is the requirement for an additional timer.

Any comments?

Jim Hafner


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