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> Sent by: owner-t10@t10.org
04/01/2008 06:51 AM
To
Kevin D Butt/Tucson/IBM@IBMUS
cc
"Ballard, Curtis C \(StorageWorks\)"
<curtis.ballard@hp.com>, <t10@t10.org>
Subject
RE: SSC-3: Late Letter Ballot comment
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>
Sent by: owner-t10@t10.org
03/31/2008 02:55 PM
To
"Ballard, Curtis C \(StorageWorks\)"
<curtis.ballard@hp.com>, <t10@t10.org>
cc
Subject
RE: SSC-3: Late Letter Ballot comment
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/