I already sent this note to you offline,
but now I wish to send it slightly modified for all to see.
This proposal adds definitions but does
nothing to specify HOW to create an SA. With the WHAT but without
the HOW TO create portion, I fear this will push vendors to implement before
the HOW TO is defined. This may tend to push for vendor specific
methods to create an SA without having a standard method defined. This
will defeat the purpose of having a standard. IBM Tape is strongly
opposed to voting for something that is incomplete and begs for vendor-specific
solutions because there is no standard method to do something that is described.
We believe that the HOW TO needs to be added in before this should
be allowed into the standards.
Thanks,
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware
MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
Tel: 520-799-2869 / 520-799-5280
Fax: 520-799-2723 (T/L:321)
Email address: kdbutt@us.ibm.com
http://www-03.ibm.com/servers/storage/
Ralph Weber <roweber@ieee.org> Sent by: owner-t10@t10.org
08/26/2006 09:36 AM
To
t10@t10.org
cc
Subject
Re: comment on 06-369r2 -- Security
Association Model for SPC-4
For my part, I fail to see how an SA can be established
until there is a definition of what an SA is.
I consider the SA definition so fundamental that having
the definition phrased in traditional SCSI terms is
critical to me. This is why (as SPC-4 editor) I am
working on 06-369rx.
While it seems simpler to have the SA definition in
a working draft for easy reference by those writing
SA creation proposals (and there might be two of these
coming, one for authenticated SAs and one for
unauthenticated SAs), if the majority of CAP sees
things differently, I will of course abide by that
decision.
I still plan to press for a vote on 06-369.
All the best,
.Ralph
Gideon Avida wrote:
* From the T10 Reflector (t10@t10.org),
posted by:
* "Gideon Avida" <gideon@decru.com>
*
While I understand the motivation behind proposal 06-369, I don't think
Decru can vote for it for similar reasons voiced against proposal 06-225
in
Colorado Springs. From the SSC-3 minutes: "Kevin Butt from IBM raised
the
issue that this proposal relies on an already established security
association. It is the foundation for this key wrapping and we are opposed
to this without a method in SCSI defined to create a Security Association."
On a related topic, Decru would like to propose the use of public key
cryptography as an alternative means for securing data encrypting keys.
Due
to time constraints between the meetings, I only have a rough overview
that
I'd like to discuss in Nashua (it's currently submitted to the SSC-3
agenda). Please see http://www.t10.org/ftp/t10/document.06/06-389r0.pdf.
If
there is interest in this approach, I will flesh out the details of the
proposal by the Las Vegas meeting.
It is also unclear if this security association method
is required for
all
"security protocols" supported in SECURITY
PROTOCOL IN/ OUT commands
or
just the tape protocol (which is the only one described
in SPC-4 at
the
moment).
The function of the proposed security association abstraction is to
separate generation of symmetric cryptographic keys from use of those
keys
in order to enable mix/match of security mechanisms across that boundary
(separation of key generation from key usage). If a "security
protocol"
does not generate keys for use in other SCSI functionality, it can
ignore the whole concept of a security association.
The tape protocol is going to specify a means of encrypting encryption
keys in order to transfer them securely to tape devices that have
onboard
encryption - to do so, the protocol needs to use another key. This
may
sound recursive (need a second key to protect first key, how is the
second key protected?), but fortunately, the recursion ends with what
is called a "key exchange protocol" that generates a shared secret
from
non-secret communication exchanges plus some mathematics. One of
the
reasons for putting forward security association text now is that there
is a possibility that SSC-3 will want to specify multiple key exchange
protocols, and a structure in which multiple such protocols can co-exist
cleanly is important to avoid chaos.
Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA 01748
+1 (508) 293-7953 FAX: +1 (508)
293-7786 black_david@emc.com
Mobile: +1 (978) 394-7754
----------------------------------------------------
While reading through the new section 5.13, I thought the information
was
not organized in the best order for understanding.
5.13.1 and 5.13.2
introduce tables without describing what they are for. Clause 5.13.3
finally starts defining a "security association" and what it
is used
for.
This should become the first clause in 5.13 because
it provides a
basis for
understanding the stuff in the other clauses.
It is also unclear if this security association method is required for
all
"security protocols" supported in SECURITY
PROTOCOL IN/ OUT commands
or
just the tape protocol (which is the only one described
in SPC-4 at
the
moment).
I would like to see a more generic model that starts with material
from
5.13.1,5.13.3, and 5.13.4; then moves on to describe
the choices made
for
the minimum SA parameters, etc. for the tape protocol.
It should also
state
that the tape protocol details do not necessarily
apply to protocols
that
reference other documents for their description.
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo@t10.org
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo@t10.org
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo@t10.org