comment on 06-369r2 -- Security Association Model for SPC-4

Ralph Weber roweber at IEEE.org
Wed Aug 30 14:25:22 PDT 2006


Formatted message: <A HREF="r0608304_f.htm">HTML-formatted message</A>

Kevin,
If SPC-4 were headed to Letter Ballot in the near future,
I would support your position 100%, but such is not the case.
Working drafts are always works in progress, and I feel
that having a good SA definition in SPC-4 will encourage
those who know the ropes better than I to bring in the
needed HOW TO proposals. Since they no longer have to
jump through the hoops needed to define WHAT, they have
less work to do and that should lower whatever hurdles
are keeping them from coming forward.
As for the matter of vendor specific solutions ...
I must note two things:
a) SA definition are totally internal to SCSI devices, and
b) There already are 16 VS codes in SECURITY PROTOCOL IN/OUT.
Surely any suitably determined organization can define
VS SAs till the cows come home, even if 06-369rx is never
incorporated in SPC-4.
All the best,
.Ralph
Kevin D Butt wrote:
>
> Ralph,
>
> 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 at us.ibm.com
> http://www-03.ibm.com/servers/storage/
>
>
> *Ralph Weber <roweber at ieee.org>*
> Sent by: owner-t10 at t10.org
>
> 08/26/2006 09:36 AM
>
>	
> To
>	t10 at 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 at t10.org_ <mailto:t10 at t10.org>), posted by:
> * "Gideon Avida" _<gideon at 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 at t10.org_ <mailto:owner-t10 at t10.org> 
> [_mailto:owner-t10 at t10.org_] On Behalf Of
> _Black_David at emc.com_ <mailto:Black_David at emc.com>
> Sent: Friday, August 25, 2006 2:49 PM
> To: _Gerry.Houlder at seagate.com_ ; 
> _t10 at t10.org_ <mailto:t10 at t10.org>
> Subject: RE: comment on 06-369r2 -- Security Association Model for SPC-4
>
> * From the T10 Reflector (_t10 at t10.org_ <mailto:t10 at t10.org>), posted by:
> * _Black_David at emc.com_ <mailto:Black_David at 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 at emc.com_ <mailto:black_david at emc.com>	    Mobile: +1 
> (978) 394-7754
> ----------------------------------------------------
>
>  
> -----Original Message-----
> From: _owner-t10 at t10.org_ <mailto:owner-t10 at t10.org> 
> [_mailto:owner-t10 at t10.org_] On Behalf
> Of _Gerry.Houlder at seagate.com_ 
> Sent: Friday, August 25, 2006 3:44 PM
> To: _t10 at t10.org_ <mailto:t10 at t10.org>
> Subject: comment on 06-369r2 -- Security Association Model for SPC-4
>
> * From the T10 Reflector (_t10 at t10.org_ <mailto:t10 at t10.org>), posted by:
> * _Gerry.Houlder at 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 at t10.org_ 
> <mailto: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_ 
> <mailto: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_ 
> <mailto:majordomo at t10.org>
>
>
>
>  



More information about the T10 mailing list