Kevin,
Some comments below.
Curtis Ballard
Hewlett Packard
From: Kevin D Butt
[mailto:kdbutt@us.ibm.com]
Sent: Tuesday, April 01, 2008 5:36 PM
To: Entzel, Paul
Cc: Ballard, Curtis C (StorageWorks); owner-t10@t10.org; t10@t10.org
Subject: RE: SSC-3: Late Letter Ballot comment
Paul,
I see. I think
I agree with everything you have said.
My review has
uncovered the need to add a statement that the "data encryption
scope" field is set to PUBLIC when the device server processes a set data
encryption page with the SCOPE field set to PUBLIC.
How "key
scope" is set to LOCAL is not covered.
To summarize in
a UMLish view what we discussed:
[CCB]
I assume by DS(1) you mean the one instance of the device server in which case
I would agree that these define what we have today.
a) and b) are
constrained such that only one can exist at a time for a specific I_T nexus.
When the data
encryption scope=PUBLIC for an I_T nexus, then that I_T nexus uses the data
encryption parameters in a) if they exist.
Now my concern
is, what is the proper behavior in this scenario:
I_T nexus A
sends a SPOUT command to create a set of data encryption parameters with a
scope of ALL I_T_NEXUS but does not set the LOCK bit, then I_T nexus B sends a
SPOUT command with a scope of PUBLIC with the LOCK bit set to 1, the ENCRYPTION
MODE field set to DISABLE and DECRYPTION MODE field set to DISABLE or RAW.
[CCB]
from table 142 describing the behavior when the SCOPE field is set to PUBLIC:
"All fields other than the scope field
and LOCK bit shall be ignored." I
interpret that to mean that the following action based on the values in the
mode fields should not be executed because the device ignored those fields and
does not know what was in them. That would mean that somebody setting a
scope of PUBLIC does not affect saved parameters.
According to
4.2.21.6 If the encryption/decryption modes are set to DISABLE, then
"release any resources that it had allocated to store data encryption
parameters for the I_T nexus associated with the SECURITY PROTOCOL OUT command
and shall change the contents of all memory containing a key value associated
with the data encryption parameters that are released;"
I believe the
intent would be to lock B to the encryption parameters for the ALL I_T NEXUS
(i.e., established by A).
But if there were
no A, then what would happen? There are no encryption parameters (..shall
release any resources that it had allocated to store data encryption
parameters..) so there is no "key instance counter".
[CCB]
In the case of no ALL I_T NEXUS existing when the command was received then
there may be an issue but if the default key instance counter had been defined
as going to default when released (which it isn't but was is a possible
interpretation) and a set of parameters always existing (but maybe set to
defaults == released) for ALL I_T NEXUS scope, then the I_T nexus can be bound
to the key instance counter value of 0 which would be incremented to 1 if
somebody came along and set an ALL I_T NEXUS.
I think it
would break if the key instance counter were released. Instead the key
instance counter should be incremented. This needs to be corrected.
[CCB] That's one potential solution. Another
would be to have an indicator in the values saved per I_T nexus for "Lock
Violation" then any change to the key instance counter for the a set of parameters
with an I_T nexus locked to those parameters would set the Lock Violation indicator
in all saved values for I_T nexuses locked to the ALL I_T NEXUS
parameters. That may be less disruptive than completely changing the
behavior of the key instance counter.
If
the check for violation only examines the key instance counter then it appears
that there is no way we can allow that counter to be released without opening
the case of a counter value being the same but the parameters associated with
that counter being completely different and the counter just happened to count
back up to the same value.
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/
|
"Entzel,
Paul" <Paul.Entzel@lsi.com> 04/01/2008
02:48 PM |
|
Kevin,
The
device server should not establish a set of data encryption parameters for an
I_T nexus that issues a SPOUT command that sends a Set Data Encryption page
with the SCOPE field set to PUBLIC. See the third paragraph in 4.2.21.7.
There is no question that this could be made clearer both in the model
clause and in table 142.
Paul
From: Kevin D Butt [mailto:kdbutt@us.ibm.com]
Sent: Tuesday, April 01, 2008 1:48 PM
To: Entzel, Paul
Cc: Ballard, Curtis C (StorageWorks); owner-t10@t10.org; t10@t10.org
Subject: RE: SSC-3: Late Letter Ballot comment
My comments below <<kdbutt>>
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/
|
"Entzel,
Paul" <Paul.Entzel@lsi.com> 04/01/2008
06:51 AM |
|
Kevin,
Comments below.
Paul Entzel
From: Kevin D Butt
[mailto:kdbutt@us.ibm.com]
Sent: Monday, March 31, 2008 5:21 PM
To: Entzel, Paul
Cc: Ballard, Curtis C (StorageWorks); owner-t10@t10.org; t10@t10.org
Subject: RE: SSC-3: Late Letter Ballot comment
Paul,
Just to be clear, the LOCK bit is only associated with the specific I_T nexus
on which the SPOUT command was received with the LOCK bit set.
[Paul Entzel] Yes.
In your example A is not locked to the parameters (the parameters being those
set for I_T nexus A) but B is locked to the parameters (those parameters set
for I_T nexus B - which are different parameters than those that are set for
I_T nexus A).
[Paul Entzel] The fist half of this sentence is correct, but the parenthetical
part is not. In my example, initiator A established a set of shared data
encryption parameters using the ALL I_T NEXUS scope. Initiator B did not
establish a set of parameters, but instead created an association with the
shared data encryption parameters and locked itself to this set of parameters
by using the PUBLIC scope and the LOCK bit. The two initiators are
associated with the same set of data encryption parameters.
<<kdbutt: Yes, because B used PUBLIC it refers to the ALL I_T NEXUS
parameters. I missed this.>>
The key point here is that the encryption parameters are set per I_T nexus.
[Paul Entzel] If this were true, Curtis' external encryption control will
never work. If the scope is LOCAL, then this is true. If the scope is ALL
I_T NEXUS, then the data encryption parameters are shared between the I_T nexus
that set them and all I_T nexuses that have been configured with a scope of
PUBLIC.
<<kdbutt: I agree>>
Any changes that occur on other I_T nexuses do not change the parameters in
another I_T nexus.
[Paul Entzel] If the SCOPE field is LOCAL in page that establishes a set of
data encryption parameters, then this is generally true. To accommodate
designs with limited resources for storage of data encryption parameters
(particularly keys), the standard allows for the device to release a set of
data encryption parameters for anther I_T nexus when they needed to establish a
new set of data encryption parameters for a different I_T nexus. This feature
is optional. See the second paragraph in 4.2.21.8. Remember, the
data encryption parameters are not IN the I_T nexus, they are in the physical
device. They are owned by an I_T nexus and possible shared with other I_T
nexuses.
<<kdbutt: I agree>>
This means the LOCK bit only helps the I_T nexus that set the encryption
parameters with the LOCK bit set.
[Paul Entzel] The LOCK bit only applies to an I_T nexus that set the bit
in the Set Data Encryption Parameters page in the last SPOUT command that sent
this page.
<<kdbutt: I agree>>
This page may not have established a set of data encryption parameters, it may
have also had the SCOPE field set to PUBLIC which means that the I_T nexus is
locked to the current set of ALL I_T NEXUS data encryption parameters, if one
exists.
<<kdbutt: In this case there is a set of data encryption parameters.
The key scope and the encryption mode and decryption mode are all part of
the data encryption parameters. This means that when the SCOPE is set to
PUBLIC, that there exists data encryption parameters associated with this I_T
nexus, but it also means that this I_T nexus is to use the data encryption
parameters that are set with a SCOPE of ALL I_T NEXUS. This means that
this I_T nexus has two sets of data encryption parameters - the one whose scope
is PUBLIC and the one whose scope is ALL I_T NEXUS.
In 4.2.21.7 paragraphs 3,4,5, and 6 the scope is referred to as being saved by
I_T nexus. But in 4.2.21.8 key scope is listed as part of the data
encryption parameters. How can data encryption parameters not be by I_T
nexus yet some of its members are by I_T nexus. I think this shows that
the requirements are not clear in SSC-3. I agree that data encryption
parameters should be a global thing, but some of what we list as data
encryption parameters are said to be for a specific I_T nexus.
Perhaps I am looking at this wrong, but it seems to be lacking a complete or
concise description and we have placed certain parameters in the data encryption
parameters when we should not have.>>
If not, it is locked to the default set of data encryption parameters
(DISABLED/DISABLED).
The point behind the LOCK bit was to provide a method to prevent the device
from writing data if the data encryption parameters had changed since the last
time the application client configured them without the application client
having a chance to fix them again, even in an environment where UAs don't make
it to the proper layer to fix the problem. If Gideon is listening, this
is the place where he jumps in and claims that the protection is too weak and
so it is worthless, but it is what we have.
<<kdbutt: I agree with the point of the LOCK>>
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/
|
"Entzel,
Paul" <Paul.Entzel@lsi.com> 03/31/2008
02:55 PM |
|
Hello Curtis,
The concept of LOCK was to allow an I_T nexus to create a fixed association
with a particular set of data encryption parameters at a specific generation
(key instance counter). This association is saved with the I_T nexus (see
subclause 4.2.21.7) not with the set of data encryption parameters because more
than one I_T nexus can be associated with a set of data encryption parameters
(one as the creator, others using the PUBLIC scope). It was not an
oversight to not include the lock bit in the data encryption parameters
structure, it doesn't belong there. Consider the example where I_T nexus
A sends a SPOUT command to create a set of data encryption parameters with a
scope of ALL I_T_NEXUS but does not set the LOCK bit, then I_T nexus B sends a
SPOUT command with a scope of PUBLIC with the LOCK bit set to 1. In this
example, A is not locked to the parameters but B is. What would you put
in the lock parameter if it was part of the set of data encryption parameters?
You may want to consider fixing the problem by introducing the concept of a
master key instance counter in 4.2.41.10 that is not associated with any set of
data encryption parameters. It would be incremented and inserted into the
set of data encryption parameters each time one is created. You would
also need to modify the test in 4.2.21.11 such that a lock violation occurs if
the I_T nexus is locked and the data encryption parameters have been released.
Paul Entzel
From: owner-t10@t10.org
[mailto:owner-t10@t10.org] On Behalf Of Ballard, Curtis C (StorageWorks)
Sent: Monday, March 31, 2008 2:51 PM
To: 't10@t10.org'
Subject: RE: SSC-3: Late Letter Ballot comment
Kevin,
I looked into this a bit and came to a different conclusion.
You reference section 4.2.21.6 on Managing keys within the device server and
the section on when to release a set of data encryption parameters which does
not discuss turning off encryption.
I believe the section we need to reference is a little further into 4.2.21.6 at
that start of document page 56 in SSC3r04a.pdf where it discusses what to do
when both the ENCRYPTION MODE and the DECRYPTION MODE are set to DISABLE which
is the encryption off condition.
"If a device server processes a Set Data Encryption page with the ENCRYPTION MODE field set to DISABLE
and DECRYPTION
MODE field
set to DISABLE or RAW, the physical device shall:
a)release any resources that it had allocated to store data encryption
parameters for the I_T nexus associated with the
SECURITY PROTOCOL OUT command and shall change the contents of all memory
containing a key value associated with the data encryption parameters that are
released; and
b)establish a unit attention condition . . ."
The statement "data encryption parameters" was referenced to 4.2.21.8
earlier in that clause so if we follow that reference we find that virtually
all of the settings that a host can establish are included in the data
encryption parameters including the key instance counter which is tied to
locking. When both modes are set to DISABLED which is what has to be done
to turn encryption off, then everything in the set of data encryption
parameters is released so all of those values are gone. If the counter is
gone along with all the other parameters I don't see how the parameters can
possibly continue to be associated with that I_T nexus.
According to my notes we discussed at the last SSC-3 meeting that
"LOCK" should also be included in the data encryption parameters but
wasn't due to an oversight. If it had been then it would be clear that
"LOCK" is gone when the encryption parameters are released.
I'm concerned that this behavior seems to be inconsistent with the introduction
to 4.2.21.11 which discusses exactly the case of resources being released and
the UA not detected and suggests that LOCK solves the issue.
If the intent is that LOCK persist when the rest of the parameters are released
then I don't think the change is as simple as you suggest. I think that
we would need to modify 4.2.21.6 to indicate that the key instance counter is
not released with the rest of the parameters if LOCK is set to one, but instead
is incremented. That way the test described in the section on locking
where a changed key instance counter triggers the CHECK CONDITION will still
work. We might also have to modify some text describing releasing
resources when limited resources are exhausted to make it clear that parameters
containing a LOCK bit set to one can't be released (I have some concerns with
whether that can be required). There might also be other sections that
talking about releasing parameters that would need examined.
This one looks to me like it's going to take a proposal to address.
Curtis Ballard
Hewlett Packard
From:
owner-t10@t10.org [mailto:owner-t10@t10.org] On Behalf Of Kevin D Butt
Sent: 20 March 2008 21:48
To: t10@t10.org
Subject: SSC-3: Late Letter Ballot comment
I received communication from an ISV today related to Encryption mode locking
(4.2.21.11). They were unable to determine if the locking applied when
the data encryption parameters were set such that encryption/decryption is
turned off. In a close reading this clause refers to "...locked to
that set of data encryption parameters and key instance counter value until a
hard reset condition occurs or another [SPOUT command is received]"
In 4.2.21.6 Managing keys within the physical device, where it describes when
to release a set of data encryption parameters, there is no mention of turning
off encryption. Therefore, the locking does apply to the saved set of
encryption parameters even when encryption is turned off. This is indeed
the desired behavior. However, it is not clear to the casual or novice
standards reader that this is the case.
Proposed Solution (Editorial):
In 4.2.21.11, p2, add a new sentence after s1:
The LOCK bit in the Set Data Encryption page is set to one to lock the I_T
nexus that issued the SECURITY PROTOCOL OUT command to the set of data
encryption parameters established at the completion of the processing of the
command. A set of data encryption parameters are
established and locked even if the ENCRYPTION MODE is set to DISABLE and the
DECRYPTION MODE is set to DISABLE.
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/