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

From: "Julian Satran" <[email-masked]>
Date: Thu, 30 Aug 2001 00:40:29 +0300

Steve,

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

Julo

Steve Senum <[email-masked]>@ece.cmu.edu on 30-08-2001 00:12:28

Please respond to Steve Senum <[email-masked]>

Sent by:  [email-masked]

To:   ietf-ips <[email-masked]>
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

---

From: Steve Senum <[email-masked]>
Date: Thu, 30 Aug 2001 11:48:04 -0500

Julian,

> to use security under specific conditions.

I understand that.  Still, the only situation I would
consider it valid for the initiator to skip the
SecurityNegotiation stage is if it intended to send out:

I-> AuthMethod:none
    HeaderDigest:none
    DataDigest:none

Otherwise it should give the target the chance to
negotiate these options.

Regards,
Steve Senum

---

From: Mark Bakke <[email-masked]>
Date: Thu, 30 Aug 2001 14:13:34 -0500

Bill-

In Irvine, we agreed that when IPsec is enabled, IKE will be used
to do key exchange.  We also agreed on which transforms to use when
IPsec is enabled.

The key word is "enabled".  Keep in mind that there will probably
be three classes of iSCSI implementations "out there":

1. iSCSI implementations without security.  These won't be able to
   say they are "compliant", but are likely to be the majority of
   implementations, at least for a little while.  At any rate, we
   all pay our marketing folks to get us around this one.

2. iSCSI implementations with software security.  These will add
   IPsec in software for one of two reasons: either high performance
   is not required (perhaps it's designed to go over a T1 or something),
   or just so the "RFC-xxxx-compliant" bullet can be checked off on
   the list.  If it's for the first reason, IPsec will be used by
   some customers; if it's for the second reason, it will likely
   never be enabled.

3. iSCSI implementations with hardware security.  These will be
   serious implementations that include IPsec, and can perform
   well enough that a customer will want to use IPsec.  These
   implementations will enable IPsec if the customer needs it, but
   again, might not enable it if this is not a concern.

Your assumption seems to be that because we chose IPsec/IKE, that
it will always be used.  Given the implementations 1 and 2, and
some of 3, that is not always the case.

As you mentioned, when your assumptions are correct, the login
phase only has to exchange initiator and target names, and can
use AuthMethod=none if it likes.  However, those assumptions
will not always hold.

--
Mark

Bill Strahm wrote:
> 
> 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: [email-masked] [mailto:[email-masked]]On Behalf Of
> Julian Satran
> Sent: Wednesday, August 29, 2001 2:40 PM
> To: [email-masked]

-- 
Mark A. Bakke
Cisco Systems
[email-masked]
763.398.1054

---

From: "Bill Strahm" <[email-masked]>
Date: Thu, 30 Aug 2001 11:49:01 -0700

Ok,

Bill
Sanera Systems Inc.
-----Original Message-----

Steve,

Julo

Julian,

Regards,
Steve Senum

---

From: "Bill Strahm" <[email-masked]>
Date: Thu, 30 Aug 2001 13:03:36 -0700

So you are saying that there will be a second layer of security that we will
build on top of TCP to secure the iSCSI traffic above and beyond the
security available at layer 3 IPsec ???

I agree with your deployment strategies.  It will be up to custommers to
determine what is important, and how much to pay for security.  If the
custommer determines that the price that they are willing to pay for
security is 0, then you get products of type 1 maybe 2.  If the custommer is
willing to pay for the cost of security you will end up with products like 2
and 3.

What I don't like is that if a custommer only wants to pay for 1, he has to
pick up 2 & 3 as well, and also if a custommer only wants to pay for 1,
having any illusions that there is security.

I am concerned that there will be layer 7 authentication/encryption methods,
on top of layer 4 authentication/encryption methods, on top of layer 3
authentication/encryption methods on top of layer 2
authentication/encryption methods...  I want a security method specified,
and either it is implemented or not, if it is not - you don't get security.
Why is specifying another layer of security that I don't have to implement
going to lead to anything other than interoperablility problems

Bill
Sanera Systems Inc.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, August 30, 2001 12:14 PM
To: Bill Strahm
Cc: Julian Satran; Ips@Ece. Cmu. Edu
Subject: Re: iSCSI - Change - Login/Text commands with the binary stage
code

Bill-

--
Mark

--
Mark A. Bakke
Cisco Systems
[email-masked]
763.398.1054