Encrypted SA management after an SA is created
Ralph Weber
roweber at ieee.org
Wed Sep 12 08:57:04 PDT 2007
* From the T10 Reflector (t10 at t10.org), posted by:
* Ralph Weber <roweber at ieee.org>
*
Currently, 04-449r8 provides for encrypted SA management functions only
|from the application client to the device server after SA creation is
finished.
This is needed because SA Delete requests need to be encrypted and SA
Delete requests transit from the application client to the device
server. (If the device server deletes an SA, the application client
finds out about it only when an SA he thinks ought to work is rejected
by the device server.)
SA deletion is the only SA management function allowed after an SA is
created.
As a result of all of this, no secure keys are generated (or needed) for
SA management functions sent from the device server to the application
client. This seems very natural in the SCSI world where device servers
never do such things.
A possible use for these un-generated secure keys might be the need to
encrypt SA management data send from the device server to the
application client as the result of an SA management function requested
by the application client.
As far as I can tell, the creation of Child SAs is the one and only
instance where such an issue might arise. However, the SCSI SA model
explicitly eschews Child SA as follows: "... In this standard an SA is
rekeyed by replacing it with a new SA ... CHILD_SAs are not used by this
standard ..."
Can anybody think of reasons why secure keys are needed to encrypt SA
management messages from the device server to the application client
after the SA is created?
If not, 06-449r9 and its successors will continue to explicitly not
generate such secure keys.
All the best,
.Ralph
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org
More information about the T10
mailing list