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> 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/