Comments on: CbCS 'correction' proposals

Sivan Tal SIVANT at il.ibm.com
Sun Mar 9 20:16:02 PDT 2008


* From the T10 Reflector (t10 at t10.org), posted by:
* Sivan Tal <SIVANT at il.ibm.com>
*
I confirm the new revision addresses those comments, thanks.
A couple of typo/editorial:
1) In 6.19.1.2 and in 6.19.1.3 where you say "as show in" it should be "as
shown in"
2) Table x3 - the last byte shoud be at offset 55 instead of 56 (we start
counting at 0).
- Sivan.
owner-t10 at t10.org wrote on 03/08/2008 08:31:52 PM:
> * From the T10 Reflector (t10 at t10.org), posted by:
> * Ralph Weber <roweber at 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.
> >
> > Comment 5:
> > In 6.19.1.3 the text "the MAM ATTRIBUTE field" should be "the
CREDENTIAL
> > REQUEST DESCRIPTOR field".
> >
> > 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:
>
> http://www.t10.org/ftp/t10/document.08/08-128r1.pdf
>
> All the best,
>
> .Ralph
>
> *
> * For T10 Reflector information, send a message with
> * 'info t10' (no quotes) in the message body to majordomo at t10.org
*
* 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 mailing list