Access Control points of debate

[hafner at almaden.ibm.com]

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


Greetings,
First, thanks for Robert Elliot and Compaq for hosting the T10
Access Controls teleconference and putting up the minutes.

A couple of issues were raised in the teleconference and in
other e-mail discussions.  Rather than me making some
decisions, writing them into the next revision and finding
that they don't meet the need,  I thought I'd throw out some
strawman proposals here to see what discussion/resolution
we can generate.

1) Two related things came up in the teleconference: request
for a simple "RESET" service action (to clear the ACL, set Manage
ACL Key to zero, etc.), and a mechanism to override the
Manage ACL Key (reset in the absense of the current key).
I'd like to suggest the following to address both.  We add a RESET
ACCESS CONTROLS service action which includes a VS bit field.
If the VS bit field is set to zero, then the parameter list contains
the current Manage ACL Key which must be checked.  If the
VS bit is set to one, then any validation of the command
happens in a VS-specific manner.  Example VS implementations
might include:
     a) no parameter list, no checking, simple reset
     b) parameter list contains serial number or some public value
     c) parameter list contains some other value requiring either
          physical access to the device (akin to the HW password of
          earlier drafts) or vendor servicing/maintanence software.
     d) other...
What this does is provide a simple API to reset with Key
checking (VS=0) and a standardized template for implementation
dependent reset (VS=1).

2) One major change from rev1 to rev2 involved moving "access
controls management/enforcement server" functions from LUN0
to each logical unit independently (as that seemed to fit the SAM-2
model much better).  This implies that there will be a Manage ACL Key
per logical unit.  It also means that ENROLLMENT is on a per logical
unit basis (and this implies that an initiator can use a different AccessID
per logical unit -- it's not how I'd implement it, but the standard can't
require it).  This change forces more resource requirements on the
target (and I'm getting requests to go back to the original model).
I personally perfer this "shared" model but I don't see how the SAM-2
model can easily adapt to this (I like to be wrong on this point).
Alternatives to rev2:
   a) allow shared behavior if the device reports the presence of an
embedded controller in inquiry.
   b) allow (somehow) implicit enrollment at other logical units if
there is an explicit enrollment at another (shared enrollment).  This
has some interesting consequences, however.
   c) find some language which requires that an initiator use the same
AccessID on all logical units of a given target (is there such language?)
   d) change the SAM-2 model to allow for an "access control server"
which spans logical units (IMHO, this is too much to bite off,...)

Other big issues to resolve are:
a) element level access controls (are they needed, if so, does the current
draft provide the right functionality)
b) proxy model (is it clear, and provide the right functionality)

Comments, suggestions, questions, etc. are welcome.

Jim Hafner


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