Sivan Tal SIVANT at
Fri Mar 7 07:38:53 PST 2008

* From the T10 Reflector (t10 at, posted by:
* Sivan Tal <SIVANT at>
The current draft reflects the original intention for volume support.
The intention is indeed that a credential to access a volume can only be
used with a specific logical unit, or a specific device.
The application client (or whatever entity that retrieves a credential on
its behalf) is expected to know what device/LU it is going to use to access
the volume. Although a volume can be moved between devices, this should not
happen too frequently. Typically the LU doesn't change for the duration of
a backup/restore session that writes/reads a volume.
Certain implementation may share keys across multiple devices to allow
application clients to be totally unaware of the logical units they are
sending commands to, from access control perspective (for what it's worth).
A model that supports volume credentials that are not bound to a LU or
device would require that the CbCS Management application client sends
"volume keys" to target devices. This is a significant change, and I'm not
sure what's the value in it because ultimately it comes down back to having
to know to which LU that volume key is to be sent.
I will discuss this with Kevin, and we will update if we find anything
needs to be changed.
Regards, Sivan.
	     Ralph Weber						   
	     <roweber at						   
	     >								To 
	     Sent by:		       "'t10 at'" <t10 at>	   
	     owner-t10 at						cc 
	     03/07/2008 08:51	       Re: LU+Volume			   
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
as intended.
All the best,
Sivan Tal wrote:
      Well, the enforcement manager will have to figure it out, but I don't
      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
      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 wrote on 03/06/2008 05:41:00 PM:
	    * From the T10 Reflector (:t10 at, posted by:
	    * Ralph Weber <roweber at>
	    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
	    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
	    credential format applicable to a volume regardless of the LU
	    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
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at

More information about the T10 mailing list