To: Dale LaFollette <Dale.Lafollette@Sun.COM> Cc: t10@t10.org Subject: Re: SSC-3: Resolution to LB Comment EMC-001 (Multiple SDK support) From: Kevin D Butt <kdbutt@us.ibm.com> Date: Tue, 14 Oct 2008 14:01:17 -0700 X-Message-Number: 9206 Formatted message: HTML-formatted message 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>> 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.>> 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.>> 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 > >