It seems like the algorithm descriptor
might contain the maximum number of allowed supplemental keys (but NOT
the [current] amount left, as this might be tied to scope, or etc.). If
a remaining amount is desirable, I think it should be returned on SPI x20,
x0020 (the Data Encryption Status page). This page reports stuff
about the currently set keys, scope, algorithms, etc., for a given initiator.
Putting a current [or remaining] SDK count here seems far more natural
than on the algorithm descriptor [this info should not be that dynamic,
and has no indication of scope, etc. -- this would imply that SDKs are
always global, but they need to follow the scope used for setting them]
-- as this x20/x0020 already has scope, mode, algorithm index and other
current state settings.
<<kdbutt: I will
respond to your comments below in this style>>
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/
From:
Dale LaFollette <Dale.Lafollette@Sun.COM>
To:
Kevin D Butt/Tucson/IBM@IBMUS
Date:
10/14/2008 08:58 AM
Subject:
Re: SSC-3: Resolution to LB Comment
EMC-001 (Multiple SDK support)
Hi Kevin,
Thanks for taking the time to review this proposal, I will try to answer
your comment questions here.
1. From page #2;
Proposal text;
"The device server reports its capability with respect to key-associated
data in the Data Encryption Algorithm descriptor(s) (see 8.5.2.4). If
the device server reports that it requires key-associated data from the
application client and a Set Data Encryption page is processed that does
not include a key-associated data descriptor, the device server shall
terminate the command with CHECK CONDITION, with the sense key set to
ILLEGAL REQUEST, and the additional sense code set to INCOMPLETE
KEY-ASSOCIATED DATA SET."
Comment;
"I do not understand the need for this. We already have the
MAXIMUM
UNAUTHENTICATED KEY-ASSOCIATED DATA BYTES field and the MAXIMUM
UNAUTHENTICATED KEY-ASSOCIATED DATA BYTES field. If a non-zero value
is
in them then that KAD is allowed (and if the UKADF or the AKADF bits are
set the size shall be that size).
What problem does this solve?"
Response;
The above is quite true when the device server is being set to Encrypt
data, the device will accept a KAD with the Key.
It appears that some of the current implementors will not accept a KAD
when being set to "Decrypt" data however,
in fact they return a Check condition it a U-KAD is present.
Imagine a device server that supports one (primary) OR more
(supplemental) decryption Keys for Decrypting.
The implementation might be designed something like, one decryption
engine with multiple Key ID & Key pairs
stored at the front door. When the encrypted record is presented to the
decryption engine the recorded U-KAD
is used to find and seed the decryption engine with the correct Key.
Then the record is decrypted correctly.
For a Device Server to support Decrypting operations similar to the
above it would then REQUIRE the Host
Client to provide the KAD with each loaded Key for decrypting.
This proposal allows a Device Server that requires a KAD for decrypting
to advertise this, and for those Device
Servers that do not require it they do nothing new and they are not
changed or broken. <<kdbutt: The
statement "The device server reports its capability with respect to
key-associated data in the Data Encryption Algorithm descriptor(s)"
forces a previously non-existent requirement on device servers. Currently
implementations do NOT report its capability with respect to KAD in this
page. This proposal would immediately make all existing implementations
non-compliant.>>
2. From page 8.
Proposal text;
"If the Decryption KAD (DKAD_C) bit is set to one, then this algorithm
requires a key-associated data descriptor, U-KAD or A-KAD, to be
provided by the application client for decryption operations. If the
Decryption KAD (DKAD_C) bit is set to zero, then this algorithm does not
require a key-associated data descriptor, U-KAD or A-KAD, to be provided
by the application client for decryption operations."
Comment;
"This will break existing implementations. Can't do that!"
Response;
I do not see how this would break existing implementations.
The existing implementations would just leave this bit set to zero, as
they do not require a KAD with a loaded
Decryption Key, the Host Application would not do anything differently.
For other implementations that need the KAD with the loaded Decryption
Key they would set the bit and the
Application Client would then be informed to send the KAD with the
Decryption Key and Supplemental Decryption
Keys. <<kdbutt: The
statement, "If the Decryption KAD (DKAD_C) bit is set to zero, then
this algorithm does not require a key-associated data descriptor, U-KAD
or A-KAD, to be provided by the application client for decryption operations."
is levying a new requirement on device servers that require a KAD. They
are now required to set this bet to one. They currently do not do
that and if this proposal is accepted as is, they will become non-compliant
and will be broken.>>
I hope I have been able to answer your questions on this.
I currently have the buy-in, in principle, from the NetBackUp driver
guru for this as long as it does not break
existing implementations.
Regards,
Dale LaFollette
Kevin D Butt wrote:
>
> Dale,
>
> I have made some comments in your proposal.
>
>
> 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/
>
>
> From:
Dale LaFollette <Dale.Lafollette@Sun.COM>
> To:
t10@t10.org
> Date:
10/10/2008 04:42 PM
> Subject:
SSC-3: Resolution to LB Comment EMC-001 (Multiple
SDK support)
>
>
> ------------------------------------------------------------------------
>
>
>
> * From the T10 Reflector (t10@t10.org), posted by:
> * Dale LaFollette <Dale.Lafollette@Sun.COM>
> *
> I have uploaded the first pass draft of the proposal to answer SSC-3
LB
> comment EMC-001.
> This is about multiple SDK support.
>
> http://www.t10.org/ftp/t10/document.08/08-410r0.pdf
>
>
>
> Regards,
>
> Dale LaFollette
> Principal Engineer, SW, Systems Group
> Sun Microsystems, Inc.
> 500 Eldorado Blvd., Bldg. 5 MS UBRM05-383
> Broomfield, CO 80021 United States
> Tel: 800-555-9786 ext 77151 / 303-272-7151
> Fax: 303-272-6555
> Email address: Dale.LaFollette@Sun.com
> *
> * For T10 Reflector information, send a message with
> * 'info t10' (no quotes) in the message body to majordomo@t10.org
>
>