More ESP-SCSI issues

Ralph Weber roweber at IEEE.org
Tue Jun 24 19:12:22 PDT 2008


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

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 at us.ibm.com
> http://www-03.ibm.com/servers/storage/ 



More information about the T10 mailing list