CbCS (Capability-based Command Security) is part of the SPC-4 (SCSI Primary
Commands) standard draft.
The current version is in
http://www.t10.org/ftp/t10/drafts/spc4/spc4r16.pdf Clause 5.14.6 described Command Security, and sub-clause 220.127.116.11 describes
CbCS, which is currently the only SCSI command security technique.
Using CbCS, the initiator provides credential to the target that authorizes
it to access the target logical unit. The credential does not contain an
initiator identity and it is obtained from a trusted third party (security
manager) and "signed" with HMAC (based on a symmetric key shared between
the security manager and the target). The credential (the Capability
descriptor) contains a DISCRIMINATOR field that can be set in a "vendor
specific" manner. One can use that field for initiator identifier. However,
it should be noted that when using CbCS you don't need this for
authorization. The access decision point is in the security manager and the
access enforcement point is in the target device, based on the credential.
The initiator authenticates only to the security manager, thus keeping the
device simple. This is especially valuable in virtualized environments.
I think that some of the OSs have the initiator name wired into the image
and boot providers will have to set this name.
I am not sure how what exactly is required for each version.
The boot RFC defines where the image comes from but very little else.
Julian Satran wrote:
> Michael - I am not sure what you are looking for? A standard parameter
> as those described by the iBOOT RFC?
Yes, I am looking for a specific DHCP parameter that defines what
InitiatorName is to be used by the iSCSI boot client.
It seems to me that the purpose of RFC4173 was/is to allow stateless
clients to boot. The target parameters that are specified in RFC4173 are
necessary, but not sufficient. On many commercial iSCSI target servers
you must have the InitiatorName in order to be able to log in to the
target. This is the case for NetApp and SANRAD, and I strongly for many
> In any case the initiator name is not the only way to control what a
> server will access.
> CbCS (stands for Credential Based Command Security) available for any
> SCSI device at the SCSI layer (see the T10 site) is probably
> safer/better and does not depend on things that can be so easy faked by
> an initiator as the initiator name and may be easier to deploy.
This is not something that I am familiar with ...
*** 10 minutes later ***
I could find no reference to CbCS or Command Based Command Security at
the NetApp support site now.netapp.com
A quick search at www.t10.org didn't turn anything up either ... I'll
There may (and should) be other/better security mechanisms working their
way through the standardization and implementation processes.
As a practical measure, I believe that a DHCP-supplied InitiatorName is
needed because InitiatorName is required by many commercial iSCSI target