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 
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 
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,
* 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