RE: Security Use Requirements

[Joshua Tseng <jtseng@NishanSystems.com>]

Hmmmm,

Yes, you are right Julian.  I was thinking about IPSec implementations that
use only the IP address and not the TCP port as a selector.  But yes, IPSec
can use source & destination TCP port as a selector, in addition to IP
address.  If that is the case, then there can only be one iSCSI Login per
IKE negotiation.  Thanks!

I believe that wraps up the case that IKE/IPSec and iSCSI can be completely
independent of each other.  If we layer iSCSI sessions on top of IKE/IPSec,
there should be no loss of security.

Josh

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