SSC-3: Late Letter Ballot comment

Kevin D Butt kdbutt at us.ibm.com
Wed Apr 2 11:15:15 PDT 2008


Formatted message: <A HREF="r0804023_f.htm">HTML-formatted message</A>

Paul,
I think care is needed related to the "key instance counter".  If defaults 
always go to zero, then won't we have instances where the key instance 
counter will not be good enough to distinguish that a change has occurred. 
 e.g., key instance counter = 1 and is saved for the lock comparison.  The 
encryption parameters are set to default.  A new I_T nexus or the same 
creates new encryption parameters.  The key instance counter =1.  This is 
the same as the previous set, but has changed.
If the key instance counter does not reset to zero when encryption is 
disabled, then it continues to count and there is no issue with the same 
value.	The only concern is for RESETs.  In those cases, everything in the 
LUN changes and the 6/2900 UA occurs which should trigger basic setups to 
occur.	Though the lock is trying to address lack of visibility to UA's.
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 at us.ibm.com
http://www-03.ibm.com/servers/storage/ 
"Entzel, Paul" <Paul.Entzel at lsi.com> 
04/02/2008 07:41 AM
To
Kevin D Butt/Tucson/IBM at IBMUS
cc
"Ballard, Curtis C \(StorageWorks\)" <curtis.ballard at hp.com>, 
<owner-t10 at t10.org>, <t10 at t10.org>
Subject
RE: SSC-3: Late Letter Ballot comment
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
From: Kevin D Butt [mailto:kdbutt at us.ibm.com] 
Sent: Tuesday, April 01, 2008 5:36 PM
To: Entzel, Paul
Cc: Ballard, Curtis C (StorageWorks); owner-t10 at t10.org; t10 at 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: 
a.	DS (1)-------(0..1) set of data encryption parameters with key 
scope=ALL I_T NEXUS 
b.	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] 
c.	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 at us.ibm.com
http://www-03.ibm.com/servers/storage/ 
"Entzel, Paul" <Paul.Entzel at lsi.com> 
04/01/2008 02:48 PM 
To
Kevin D Butt/Tucson/IBM at IBMUS 
cc
"Ballard, Curtis C \(StorageWorks\)" <curtis.ballard at hp.com>, 
<owner-t10 at t10.org>, <t10 at 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 at us.ibm.com] 
Sent: Tuesday, April 01, 2008 1:48 PM
To: Entzel, Paul
Cc: Ballard, Curtis C (StorageWorks); owner-t10 at t10.org; t10 at 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 at us.ibm.com
http://www-03.ibm.com/servers/storage/ 
"Entzel, Paul" <Paul.Entzel at lsi.com> 
Sent by: owner-t10 at t10.org 
04/01/2008 06:51 AM 
To
Kevin D Butt/Tucson/IBM at IBMUS 
cc
"Ballard, Curtis C \(StorageWorks\)" <curtis.ballard at hp.com>, 
<t10 at t10.org> 
Subject
RE: SSC-3: Late Letter Ballot comment
Kevin, 
Comments below. 
Paul Entzel 
From: Kevin D Butt [mailto:kdbutt at us.ibm.com] 
Sent: Monday, March 31, 2008 5:21 PM
To: Entzel, Paul
Cc: Ballard, Curtis C (StorageWorks); owner-t10 at t10.org; t10 at 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 at us.ibm.com
http://www-03.ibm.com/servers/storage/ 
"Entzel, Paul" <Paul.Entzel at lsi.com> 
Sent by: owner-t10 at t10.org 
03/31/2008 02:55 PM 
To
"Ballard, Curtis C \(StorageWorks\)" <curtis.ballard at hp.com>, 
<t10 at 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 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Ballard, 
Curtis C (StorageWorks)
Sent: Monday, March 31, 2008 2:51 PM
To: 't10 at 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 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Kevin D 
Butt
Sent: 20 March 2008 21:48
To: t10 at 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 at us.ibm.com
http://www-03.ibm.com/servers/storage/ 



More information about the T10 mailing list