Date: Tue, 24 Jun 2008 21:12:22 -0500 From: Ralph Weber <roweber@IEEE.org> To: t10@t10.org Subject: Re: More ESP-SCSI issues X-Message-Number: 8888 Formatted message: HTML-formatted message Kevin, The condition cited in issue #1 should never occur. The SA should have outlived its usefulness decades (or at least weeks) before the sequence number reaches FFFF FFFF FFFF FFFFh. The only way for this to occur is for 'billions and billions' (apologies to Dr. Sagan) of messages to have been transferred under the auspices of the SA. Frankly, everything I have been told about encryption algorithms says that this means 'billions and billions' too many transactions have been performed under a single encryption key. On the other hand, saying nothing seems like a bad way to write a standard. Therefore, the middle ground exemplified by the current text seems appropriate to me. I also have no concerns about an attacker using this requirement to mount a denial of service attack. The window of opportunity is simply too small to make the effort worthwhile. If we were to substitute my original preference for the requirement (i.e., 'If the DS_SQN SA parameter is equal to FFFF FFFF FFFF FFFFh, the device shall explode with a force sufficient to demolish the building in which it is located'), then perhaps attempting an attack might be, well ... at least interesting. In summary, the text cited in issue #1 deals with a gross error in a gross manner. It seems like a good fit. The following proposal has been uploaded to address issue #2: http://www.t10.org/ftp/t10/document.08/08-262r0.pdf All the best, .Ralph Kevin D Butt wrote: > > Everybody undoubtedly knew more issues would be found with the new > security stuff. We have found two more items. The first needs > clarification, the second, seems like we just did a bad thing with the > March approved, 08-158r1. > > Issue #1: > The second to last paragraph on page 163 of SPC-4r14: > If the DS_SQN SA parameter is equal to FFFF FFFF FFFF FFFFh, the > device server shall delete the SA. > <<kdbutt: There is confusion about this statement. > *First*, I believe that there is an assumption that the ICV is > correct, that should be stated. > *Second*, does the deletion occur after processing the command or do > you not process the command and just delete the SA? > *Third*, should this be at the end of the section following this > paragraph? > ---> page 164, SPC-4r14: If the command is not terminated due to a > sequence number error or a mismatch between the computed integrity > check value and the contents of the INTEGRITY CHECK VALUE field, then > the device server shall copy the contents of > the received DS_SQN field to its DS_SQN SA parameter.<--- > *Fourth*, should the converse be added to item c) above the paragraph > "c) The value in the DS_SQN field is greater than 32 plus the value in > the device server's DS_SQN SA parameter and if the DS_SQN SA parameter > is not equal to FFFF FFFF FFFF FFFFh." > *Fifth*, it seems weird to delete the SA here. What is the thinking > or justification for this? Is it intended to happen only when there > is a failure? > >> > > Issue #2: > The new reserved field was placed between two values used in > generating the AAD field used for ICV. A lot of algorithms expect it > to be a flat buffer (i.e., contiguous). With the new reserved fields > there is a gap. This would disallow generating as the buffer is being > built. > Table 70 and 71 (and 75 and 76) have the SAI and SQN contiguous with > reserved fields before them. Tables 72 and 73 (and 77 and 78) have a > gap between SAI and SQN with that gap being the new reserved bytes. > *SUGGESTED FIX:* The reserved bytes should be before the SAI and SQN. > pg 164 of SPC-4r14 describes how the SAI and SQN fields are used.: > =============== > If the integrity algorithm for the SA specified by the DS_SAI field is > AUTH_COMBINED (see 5.13.7.2), then the AAD > input to the encryption algorithm is composed of the following bytes, > in order: > 1) The bytes in the DS_SAI field; and > 2) The bytes in the DS_SQN field; > The INTEGRITY CHECK VALUE field contains a value that is computed as > follows: > a) If the integrity algorithm is not AUTH_COMBINED, the integrity > check value is computed using the > specified integrity algorithm with the following bytes as inputs, in > order: > 1) The bytes in the DS_SAI field; > 2) The bytes in the DS_SQN field; > 3) The bytes in the INITIALIZATION VECTOR field, if any; and > 4) The bytes in the ENCRYPTED OR AUTHENTICATED DATA field after > encryption, if any, has been performed; > or > b) If the integrity algorithm is AUTH_COMBINED, the integrity check > value is computed as an additional > output of the specified encryption algorithm. > ================ > > 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/