Well, the enforcement manager will have to figure it out, but I don't think
this is an issue because the command is received at a logical unit or
device. If the enforcement manager is contained in a device server, then it
is contained in a logical unit (per the CbCS UML diagram) and it should use
the logical unit's key. If it is contained in a target device, it should
use the device's "global" key. There is a clause on shared keys that
explain the distinction between LU keys and global keys.

Regards, Sivan.

owner-t10@t10.org wrote on 03/06/2008 05:41:00 PM:

  

* From the T10 Reflector (t10@t10.org), posted by:
* Ralph Weber <roweber@ieee.org>
*
Sivan Tal wrote:
    

<snip>

Comment 4:
The RECEIVE CREDENTIAL command must always include a logical unit (or
      

SCSI
  

device) and optionally a volume designator. When CbCS is used with
      

volumes,
  

the Capability field only contains identification of the volume, but
      

the
  

request must also include identification of the LU through which the
      

volume
  

is to be accessed. This allows the Security Manager to use the right
      

shared
  

key for the ICV. The new way you constructed the CDB allows for either
      

LU
  

or volume identifier. It should be either LU or LU+volume.
      

Since the LU information is not in the capability, how does
the enforcement manager determine the correct shared key
for use in its reconstruction of the capkey?

I spoke with Kevin about this, and the intention is to make this
credential format applicable to a volume regardless of the LU in
which it is mounted. Therefore, I am concerned that there are
some undesirable hidden connections here.

All the best,

.Ralph

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