SSC-3: Late Letter Ballot comment

Kevin D Butt kdbutt at us.ibm.com
Mon Mar 31 16:20:55 PDT 2008


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

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