* 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.

Thanks,
Gideon

-----Original Message-----
From: owner-t10@t10.org [mailto:owner-t10@t10.org] On Behalf Of
Black_David@emc.com
Sent: Friday, August 25, 2006 2:49 PM
To: Gerry.Houlder@seagate.com; t10@t10.org
Subject: RE: comment on 06-369r2 -- Security Association Model for SPC-4

* From the T10 Reflector (t10@t10.org), posted by:
* Black_David@emc.com
*
Gerry,

  

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
----------------------------------------------------

  

-----Original Message-----
From: owner-t10@t10.org [mailto:owner-t10@t10.org] On Behalf 
Of Gerry.Houlder@seagate.com
Sent: Friday, August 25, 2006 3:44 PM
To: t10@t10.org
Subject: comment on 06-369r2 -- Security Association Model for SPC-4

* From the T10 Reflector (t10@t10.org), posted by:
* Gerry.Houlder@seagate.com
*

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