RE: Security Use Requirements

[julian_satran@il.ibm.com]

Josh,

The connections are disjoint allways and the IPSec context is per
connection.
There is no issue here.  iSCSI does not allow 1 session to several targets.
The target sellector is used only at connection setup and the connections
to different targets are disjoint (even if they use the same target port -
the initiator address+port has to be distinct in this case).

Regards,
Julo

Joshua Tseng <jtseng@NishanSystems.com> on 09/02/2001 21:11:54

Please respond to Joshua Tseng <jtseng@NishanSystems.com>

To:   Bernard Aboba <aboba@internaut.com>
cc:   ips@ece.cmu.edu
Subject:  RE: Security Use Requirements




>
> >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?
>
> That would be fine if there is only one iSCSI authentication
> per IKE QM
> SA. Is that realistic?
>

Yes, you have a point in that multiple iSCSI devices MAY exist behind the
same IP address, and each device would be sharing the same IKE SA if they
were talking to the same peer IP address.  This would be the case for a
storage device that had multiple WWUI's.  It could also happen if the IP
address/IKE endpoint was a security gateway, and there was a network behind
it supporting multiple iSCSI devices.

As I mentioned before, physical security is needed to handle each of these
cases, to ensure a hostile entity can't use the same IP address that was
authenticated by IKE.  In the former case, physical security is pretty much
assured, since both IKE/IPSec and the
multiple iSCSI WWUI's share not only the same physical box, but also the
same TCP stack. In the latter, yes of course additional measures MUST be
taken to ensure there are no hostile entities living behind a security
gateway.

Sure, an implementation geared to the paranoid user could do what you
prescribed in your previous message (but your suggestions only make sense
for a native iSCSI device).  But I don't think these measures should be a
MUST.  Physical security is a non-negotiable requirement in both cases, and
especially in the standalone security gateway scenario, this is a quite
well
understood requirement in the security architecture document RFC 2401 when
it describes tunnel mode.

Josh