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

["Bill Strahm" <bill@sanera.net>]

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