Date: Wed, 15 Oct 2008 09:50:02 -0600 From: Dale LaFollette <Dale.Lafollette@Sun.COM> Subject: Re: SSC-3: Resolution to LB Comment EMC-001 (Multiple SDK support) To: Kevin D Butt <kdbutt@us.ibm.com> Cc: t10@t10.org X-Message-Number: 9211 Formatted message: HTML-formatted message Hi Kevin, Please see my responses to your comments embedded below. Regards, Dale LaFollette Kevin D Butt wrote: > > Dale, > > I have another comment on this proposal. > > It seems like the algorithm descriptor might contain the maximum > number of allowed supplemental keys (but NOT the [current] amount > left, as this might be tied to scope, or etc.). If a remaining amount > is desirable, I think it should be returned on SPI x20, x0020 (the > Data Encryption Status page). This page reports stuff about the > currently set keys, scope, algorithms, etc., for a given initiator. > Putting a current [or remaining] SDK count here seems far more > natural than on the algorithm descriptor [this info should not be that > dynamic, and has no indication of scope, etc. -- this would imply that > SDKs are always global, but they need to follow the scope used for > setting them] -- as this x20/x0020 already has scope, mode, algorithm > index and other current state settings. > > *<<kdbutt: I will respond to your comments below in this style>>* <<dlafollette: I had a hard time deciding for this proposal which page to use. I completely agree with your reasons above. The main reason that I choose x20/x0010 Data Encryption Algorithm descriptor is that is where the SDK_C capability is defined so I thought it would be the best location to provide the remaining amount field. I propose the following possible solutions and encourage suggestions on better field names and I will yield to the group decision; 1. Move the Undefined Supplemental Keys (remaining amount of SDKs) field to page x20/x0020. 2. Move the Undefined Supplemental Keys (remaining amount of SDKs) field to page x20/x0020, and create a Maximum Number Allowed (maximum amount of SDKs) field in page x20/x0010 Data Encryption Algorithm descriptor. 3. Leave the Undefined Supplemental Keys (remaining amount of SDKs) field in page x20/x0010 Data Encryption Algorithm descriptor. > > 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/ > > > From: Dale LaFollette <Dale.Lafollette@Sun.COM> > To: Kevin D Butt/Tucson/IBM@IBMUS > Date: 10/14/2008 08:58 AM > Subject: Re: SSC-3: Resolution to LB Comment EMC-001 (Multiple SDK > support) > > > ------------------------------------------------------------------------ > > > > Hi Kevin, > > Thanks for taking the time to review this proposal, I will try to answer > your comment questions here. > > 1. From page #2; > > Proposal text; > "The device server reports its capability with respect to key-associated > data in the Data Encryption Algorithm descriptor(s) (see 8.5.2.4). If > the device server reports that it requires key-associated data from the > application client and a Set Data Encryption page is processed that does > not include a key-associated data descriptor, the device server shall > terminate the command with CHECK CONDITION, with the sense key set to > ILLEGAL REQUEST, and the additional sense code set to INCOMPLETE > KEY-ASSOCIATED DATA SET." > > Comment; > "I do not understand the need for this. We already have the MAXIMUM > UNAUTHENTICATED KEY-ASSOCIATED DATA BYTES field and the MAXIMUM > UNAUTHENTICATED KEY-ASSOCIATED DATA BYTES field. If a non-zero value is > in them then that KAD is allowed (and if the UKADF or the AKADF bits are > set the size shall be that size). > > What problem does this solve?" > > > Response; > The above is quite true when the device server is being set to Encrypt > data, the device will accept a KAD with the Key. > > It appears that some of the current implementors will not accept a KAD > when being set to "Decrypt" data however, > in fact they return a Check condition it a U-KAD is present. > > Imagine a device server that supports one (primary) OR more > (supplemental) decryption Keys for Decrypting. > The implementation might be designed something like, one decryption > engine with multiple Key ID & Key pairs > stored at the front door. When the encrypted record is presented to the > decryption engine the recorded U-KAD > is used to find and seed the decryption engine with the correct Key. > Then the record is decrypted correctly. > > For a Device Server to support Decrypting operations similar to the > above it would then REQUIRE the Host > Client to provide the KAD with each loaded Key for decrypting. > > This proposal allows a Device Server that requires a KAD for decrypting > to advertise this, and for those Device > Servers that do not require it they do nothing new and they are not > changed or broken. > *<<kdbutt: The statement "The device server reports its capability > with respect to key-associated data in the Data Encryption Algorithm > descriptor(s)" forces a previously non-existent requirement on device > servers. Currently implementations do NOT report its capability with > respect to KAD in this page. This proposal would immediately make all > existing implementations non-compliant.>>* <<dlafollette: Yes by definition, changing SSC-3 for most Letter Ballot Technical reasons would make all existing EARLY implementations non-compliant. I have tried to word this change proposal in such a way that would NOT require any code/hardware changes for the early implementors, possibly just a documentation update along with the rest of the SSC-3 release changes. To the best of my knowledge and that of an existing Host Application Client there are no other existing Device Servers that would be required to change their current behavior to be compliant with this proposed change. > > > 2. From page 8. > > Proposal text; > "If the Decryption KAD (DKAD_C) bit is set to one, then this algorithm > requires a key-associated data descriptor, U-KAD or A-KAD, to be > provided by the application client for decryption operations. If the > Decryption KAD (DKAD_C) bit is set to zero, then this algorithm does not > require a key-associated data descriptor, U-KAD or A-KAD, to be provided > by the application client for decryption operations." > > Comment; > "This will break existing implementations. Can't do that!" > > > Response; > I do not see how this would break existing implementations. > > The existing implementations would just leave this bit set to zero, as > they do not require a KAD with a loaded > Decryption Key, the Host Application would not do anything differently. > > For other implementations that need the KAD with the loaded Decryption > Key they would set the bit and the > Application Client would then be informed to send the KAD with the > Decryption Key and Supplemental Decryption > Keys. > *<<kdbutt: The statement, "If the Decryption KAD (DKAD_C) bit is set > to zero, then this algorithm does not require a key-associated data > descriptor, U-KAD or A-KAD, to be provided by the application client > for decryption operations." is levying a new requirement on device > servers that require a KAD. They are now required to set this bet to > one. They currently do not do that and if this proposal is accepted > as is, they will become non-compliant and will be broken.>>* >>dlafollette: Again, to the best of my knowledge and that of an existing Host Application Client there are no other existing early implementation Device Servers that would be required to change their current behavior to be compliant with this proposed change. As you have already stated the current standard has the MAXIMUM UNAUTHENTICATED KEY-ASSOCIATED DATA BYTES field and the MAXIMUM AUTHENTICATED KEY-ASSOCIATED DATA BYTES field. If a non-zero value is in them then that KAD is allowed (and if the UKADF or the AKADF bits are set the size shall be that size). One could argue that all the existing early implementors with the above capabilities are non-compliant in that they accept KADs when being set to Encrypt but do NOT accept KADs when being set to Decrypt. This causes a problem for the Application Client in not knowing what to do to correctly set Decryption mode. This change addresses that problem and provides the Application Client with the information necessary. > > > I hope I have been able to answer your questions on this. > I currently have the buy-in, in principle, from the NetBackUp driver > guru for this as long as it does not break > existing implementations. > > > > Regards, > Dale LaFollette > > > > > Kevin D Butt wrote: > > > > Dale, > > > > I have made some comments in your proposal. > > > > > > 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/ > > > > > > From: Dale LaFollette <Dale.Lafollette@Sun.COM> > > To: t10@t10.org > > Date: 10/10/2008 04:42 PM > > Subject: SSC-3: Resolution to LB Comment EMC-001 > (Multiple SDK support) > > > > > > ------------------------------------------------------------------------ > > > > > > > > * From the T10 Reflector (t10@t10.org), posted by: > > * Dale LaFollette <Dale.Lafollette@Sun.COM> > > * > > I have uploaded the first pass draft of the proposal to answer SSC-3 LB > > comment EMC-001. > > This is about multiple SDK support. > > > > http://www.t10.org/ftp/t10/document.08/08-410r0.pdf > > > > > > > > Regards, > > > > Dale LaFollette > > Principal Engineer, SW, Systems Group > > Sun Microsystems, Inc. > > 500 Eldorado Blvd., Bldg. 5 MS UBRM05-383 > > Broomfield, CO 80021 United States > > Tel: 800-555-9786 ext 77151 / 303-272-7151 > > Fax: 303-272-6555 > > Email address: Dale.LaFollette@Sun.com > > * > > * For T10 Reflector information, send a message with > > * 'info t10' (no quotes) in the message body to majordomo@t10.org > > > > > > >