RE: Security Use Requirements

["Bernard Aboba" <aboba@internaut.com>]

>is that it's necessary to ensure that there isn't a gap between iSCSI
>authentication and IPSec authentication/integrity/confidentiality that
>would allow the communication to be attacked without breaking IPSec.

I think you're basically asking to make sure that an given IPSEC-protected
iSCSI packet originated from the same entity that completed the 
iSCSI authentication, no?

In IPSEC there is a similar issue in that you want to make sure that a
given IPSEC packet originated from the same entity with which you
negotiated the IKE MM and QM SAs. The packet identity is tied back to the
IKE-provided identity via the IP header and SPI, and the claim of
identity is proven by verifying the integrity/authenticity of the
packet, thereby verifying that the entity has posession of the 
key previously negotiated within IKE. 

So, in the case of iSCSI authentication, you have a claim of identity,
and a proof of identity. To link this to an IPSEC packet, you have
a few choices:

1. Somehow link the identity claimed in the iSCSI authentication to
information exchanged within the IKE negotiation.

If you can link the iSCSI authentication to the IKE MM and QM SAs, 
you will have a link to the IPSEC packet via the IP header and SPI. 

Note that "information exchanged" may constitute more than just
the claimed IKE identity. It could include information within the
cert, for example.

It is best to accomplish this without trying to invent new
identity payloads within IKE. 

2. Somehow link the proof of identity within iSCSI authentication
to the proof of identity made within IKE. For example, if a key
is generated within iSCSI authentication, then this key can be
used as a shared secret within IKE. 

However, in order to make this work, you will also need to link
the iSCSI authentication claim of identity to the claim of
identity made within IKE. Note that this does not mean that
the claims are identical -- merely that they can be bound in
a secure way.