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/