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. 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).
The key point here is that the encryption
parameters are set per I_T nexus. Any changes that occur on other
I_T nexuses do not change the parameters in another I_T nexus. This
means the LOCK bit only helps the I_T nexus that set the encryption parameters
with the LOCK bit set.
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/