RE: Security Use Requirements

[Joshua Tseng <jtseng@NishanSystems.com>]

Bernard,

See below:
> 
> >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. 
> 

I think there is a much easier way than the two methods you describe below.
If the iSCSI authentication is taking place using the SA negotiated by IKE,
then you have an implicit relationship between IKE and iSCSI authentication,
right?

Just layer the iSCSI authentication on top of IPSec.  Have IKE set up the
IPSec SA used to secure that communication channel between the two IP
addresses.  Then have iSCSI login process use that channel to authenticate
and authorize the communicating entities.

No need to have iSCSI and IKE/IPSec communicate with each other or in any
way be aware of each other.

This allows you to use any generic IPSec security gateway, or even to take
an off-the-shelf BITS (bump-in-the-stack) IPSec implementation and just
stick it in there somewhere underneath TCP in the iSCSI stack.

Josh

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