Kevin,
I think you
have pointed out a gaping hole in this part of the
standard. There is no definition for the phrase "default data encryption
parameters" anywhere in SSC-3. I always assumed we had one, since we used
the term several times in the standard, but I went to look for it as a rebuttal
to your email, and it's not there. This is probably a common problem when
creating such a large proposal, if you remember the final version of the
proposal that added encryption control to SSC-3 was about 30 pages long.
Anyway, it might help you understand my point of view if I were to describe
my definition of the "default data encryption parameters". The default
data encryption parameters are a statically defined set of data encryption
parameters as defined in 4.2.21.8 with the encryption mode parameter set to
DISABLE, the encryption mode parameter set to DISABLE, and the key instance
counter parameter set to 0. All other fields are undefined. The last
sentence fixes the problem of what to put in the I and the T parameters, and
more important, what to put in the key scope parameter. In my opinion, it
does not matter what you put in these parameters, since the parameter set is
statically defined, that is, it exists from reset and never gets release or
reallocated. It is shared between I_T nexuses, like the ALL I_T NEXUS
scope parameters set, but exists even when a valid ALL I_T NEXUS scope set of
data encryption parameters exists. I like this concept because it gives
you a place to park any I_T nexuses that set a LOCAL scope set of data
encryption parameters that specify DISABLE/DISABLE without burning a full
set of unique data encryption parameters for them.
However, another way to fix this problem would be to remove
this term and add a couple of new rules to the ALL I_T NEXUS scope set of data
encryption parameters. In the original proposal, support for the the ALL
I_T NEXUS scope was not mandatory, so this would have not fixed the
problem. But in SSC-3 now, support for this scope is mandatory and in
4.2.21.8 there is a paragraph that states:
A device
server shall support an encryption key scope value of ALL I_T NEXUS and the
physical device shall have resources to save one set of data encryption
parameters with this scope.
Since the ALL I_T NEXUS scope set of data encryption
parameters is statically allocated, there's no reason rules can't be created for
the default settings to be used on power-up and when no key of this scope is
defined. How about if this set of data encryption parameters is defined to
default to DISABLE for the encryption mode and decryption mode
parameters? A rule could be added that the ALL I_T NEXUS scope data
encryption parameters shall be set to default values when
released. If you did this, then the term "default data encryption
parameters" is synonymous with the term "set of data encryption parameters with
the scope parameter of ALL I_T NEXUS". This is true because the
default data encryption scope parameter for each I_T nexus is PUBLIC (see
4.2.21.7). There are a couple of places that state what to do if there is
no ALL I_T NEXUS scope data encryption parameters that would need to change,
since there always will be one.
Either of these changes will fix the problem of what key
instance counter value to lock to.
As for the UML, I am far from an expert and am a little
confused about your use of DS(1). However, the information saved per I_T
nexus is defined in 4.2.21.7 and the information saved per data encryption
parameters set is defined in 4.2.21.8, and they are significantly
different. We've already discussed that there is not always a one to one
relationship between I_T nexus and data encryption parameters, and that not
every I_T nexus will have a set of data encryption parameters that is
"owns". However, if you agree with the concepts I mentioned above, there
is one and only one set of data encryption parameters associated with each I_T
nexus at all times (a LOCAL set, the ALL I_T NEXUS set, or the default set
(if this concept remains)).
I hope this helps,
Paul Entzel
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:
- DS (1)-------(0..1) set of data
encryption parameters with key scope=ALL I_T NEXUS
- DS (1)-------(0..n) set of data
encryption parameters with key scope=LOCAL [there is one for every I_T nexus
that has a data encryption scope=LOCAL]
- DS (1)-------(1..n) saved information
per I_T nexus (4.2.21.7) [there is one for every I_T nexus in
existence]
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.
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".
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.
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
|
|
To
| Kevin D
Butt/Tucson/IBM@IBMUS
|
|
cc
| "Ballard, Curtis C
\(StorageWorks\)" <curtis.ballard@hp.com>,
<owner-t10@t10.org>, <t10@t10.org>
|
|
Subject
| RE: SSC-3: Late Letter Ballot
comment |
|
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>
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/