Comments on: CbCS 'correction' proposals

Ralph Weber roweber at
Sat Mar 8 17:31:52 PST 2008

* From the T10 Reflector (t10 at, posted by:
* Ralph Weber <roweber at>
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.
> Comment 5:
> In the text "the MAM ATTRIBUTE field" should be "the CREDENTIAL
> Comment 6:
> Table 180 — Capability format values : This should be renamed to
> "Credential format values". Note that 'Credential' is what the CbCS
> Management device server sends to the Secure CDB Originator, but the
> Enforcement Manager never gets a 'Credential'. It only gets a 'Capability'
> and 'ICV'. The group had decided that a 'CbCS Capability' has a single
> format and future formats will define new capability types and extension
> types.
> The rationale is that the current (only) credential format - 1h - is used
> in conjunction with CbCS extension. In the future, new credential formats
> may be defined, in conjunction with new extension types (say CbCSv2, CbCSv3
> type extensions). Moreover, new credential formats may be defined to
> facilitate non-CbCS credentials, as the SCSI command security model
> supports multiple techniques (We spent so much time on this - you wouldn't
> forget that ;-)
> <snip>
Hopefully, these comments are addressed by the just uploaded:
All the best,
* 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