roweber at IEEE.org
Fri Mar 7 05:51:34 PST 2008
Formatted message: <A HREF="r0803070_f.htm">HTML-formatted message</A>
The description of the enforcement manager's behavior
shown below appears to conflict with Kevin's understanding
of what those who requested CbCS support for volumes wanted.
The Volume Credential is valid for only one logical unit
(or possibly all the logical units in one SCSI target device).
Any other logical unit will have a different key and therefore
be unable to construct the correct capkey associated with the
Volume Credential. Therefore, use of the volume in other
logical units appears to be prohibited.
I am no longer certain that CbCS Volume support functions
All the best,
Sivan Tal wrote:
> 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 at t10.org wrote on 03/06/2008 05:41:00 PM:
>> * From the T10 Reflector (t10 at t10.org), posted by:
>> * Ralph Weber <roweber at ieee.org>
>> Sivan Tal wrote:
>>> Comment 4:
>>> The RECEIVE CREDENTIAL command must always include a logical unit (or
>>> device) and optionally a volume designator. When CbCS is used with
>>> the Capability field only contains identification of the volume, but
>>> request must also include identification of the LU through which the
>>> is to be accessed. This allows the Security Manager to use the right
>>> key for the ICV. The new way you constructed the CDB allows for either
>>> 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,
>> * 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