RE: iSCSI - Change - Login/Text commands with the binary stage code

["John Hufferd" <hufferd@us.ibm.com>]

Bill,
This IPSec is not enough, you need to ensure that the initiator you are
connected too, is who it claims to be in the eui, or iqn iSCSI Initiator
Names.  It could lie and get at LUNs that he is not authorized to get at.
Subsequent iSCSI Authentication must be done to prevent this masquerade.

.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136
Internet address: hufferd@us.ibm.com


"Bill Strahm" <bill@sanera.net>@ece.cmu.edu on 08/30/2001 11:49:01 AM

Sent by:  owner-ips@ece.cmu.edu


To:   Julian Satran/Haifa/IBM@IBMIL
cc:   "Ips@Ece. Cmu. Edu" <ips@ece.cmu.edu>
Subject:  RE: iSCSI - Change - Login/Text commands with the binary stage
      code



Ok,

I am confused here (or maybe it is just a lag effect for me)

I thought we had decided in Irvine to use IPsec/IKE to negotiate security.
So basically the process is this

1) Administrator makes several entries into a Security Policy Database
2) An iSCSI initiator attempts to send a TCP-SYN packet to a target machine
3) The IPsec packet filter detects this packet, realized there isn't a
security association for it, and asks the Security Policy Database what to
do about it
4) The security Policy Database may determine that an IPsec SA needs to be
established so tells IKE to negotiate with the remote peer
5) An IKE negotiation proceeds until either it succeeds or fails
6) If it fails, packets are dropped
7) If it succeeds, the negotiated SAs are pushed to the IPsec packet
filters
8) The origional TCP-SYN packet is now sent out under the IPsec SA that was
negotiated.

Now under this scenario there is no need for iSCSI to negotiate security at
all.  I DO now see the need to include an iSCSI Login phase that includes
passing user identities across so targets and initiators can identify
themselves, but this is over a secure link (see the above discussion) so I
can just put ID= Bills-iSCSI-Initiator PW=BetYouCantGuessIt and the link
will secure it for me...

Bill
Sanera Systems Inc.
-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
Julian Satran
Sent: Wednesday, August 29, 2001 2:40 PM
To: ips@ece.cmu.edu
Subject: Re: iSCSI - Change - Login/Text commands with the binary stage
code



Steve,

Implement and use are different terms. An administrator might set it up not
to use security under specific conditions.

Julo

Steve Senum <ssenum@cisco.com>@ece.cmu.edu on 30-08-2001 00:12:28

Please respond to Steve Senum <ssenum@cisco.com>

Sent by:  owner-ips@ece.cmu.edu


To:   ietf-ips <ips@ece.cmu.edu>
cc:
Subject:  Re: iSCSI - Change - Login/Text commands with the binary stage
      code



Julian,

In the following section:

   If the initiator decides to forego the SecurityNegotiation stage it
   issues the Login with the CNxSG set to LoginOperationalNegotiation in
   the current stage and the target may replay with a Login Response
   indicating that it is unwilling to accept the connection without
   SecurityNegotiation and terminate the connection.

This seems contrary to the requirement to implement
authentication (at least AuthMethod=SRP).  I realize
this could also be a configuration issue, but I wonder
if the spec should at least strongly recommend starting
with phase SecurityNegotiation, or better yet, make it
a SHOULD?

Regards,
Steve Senum