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

From: "Julian Satran" <[email-masked]>
Date: Fri, 31 Aug 2001 00:06:27 +0300

Sandeep,

Comments in text.  Julo

Sandeep Joshi <[email-masked]>@ece.cmu.edu on 30-08-2001
19:11:53

Please respond to Sandeep Joshi <[email-masked]>

Sent by:  [email-masked]

To:   [email-masked]
cc:
Subject:  Re: iSCSI - Change - Login/Text commands with the binary stage
      code

Julian,

> > As for the names - I though that security people might object having
the
> > name in clear if the security phase does not make use of the name.
> > Otherwise we can mandate them on the login but I wonder if that is a
real
> > improvement or we are getting carelles.
> >
> > Julo

The problem with these names (and hence the request from Steve and
others
earlier) is that it is not possible to know when the target wants them.

Consider the following excerpts from your latest login proposal..
+++ The initiator know if the authentication method selected needs the name
and will offer it if so (that is mostly context information not related to
the wire protocol +++
> A target MAY use the iSCSI Initiator Name as part of its access control
> mechanism; therefore, the iSCSI Initiator Name MUST be sent before the
> target is required to disclose its LUs.

The above is _very_ confusing..how can the initiator know if the
 the target is doing access control ?
+++ It really is not. LU names can be obtaine only in FFP. The statement
says that you have to disclose them before reaching FFP and explains why
+++
> If the iSCSI Target Name and/or iSCSI Initiator Name is going to be used
> in determining the security mode or it is implicit part of
> authentication, then the iSCSI Target Name and/or iSCSI Initiator Name
> MUST be sent in the login command for the first connection of a session
> to identify the storage endpoint of the session

In both the above cases, how does the initiator know when the target
requires these names?  The partial login response occurs *only* once.
So when going from the security->operational phase, there is no
indication that the target would like these names sent.
+++ the security negotiation is not ended with partial response
but through a complete handshake in the old and new schemes.
The initiator will know before by the selection made if he has to give its
name or not.
The whole point was for us to mandate what is mandatory for iSCSI in
general
and let all the other choices open.
With IPSec it is less of an issue as the name can be presented on an
encrypted although not fully authenticated channel+++

There are 3 options here :
(A) ALways send the names in the login command.  Simplify target
   and initiator and eliminate a few of those partial login
   response codes.
(B) Maintain a configuration database (per-target) of when names
   must be sent - adds an administration burden.
(C) Change the wire protocol to allow the target to indicate when
   the names must be sent - again more complications.
+++ please read and react to the new proposals +++
To round up, I prefer Option (A).  These are just names and not
passwords, so the security risks are minimal.  Are we trying to
protect against traffic analysis ?
+++ I agree that it is simpler to think about it this way. I do not agree
that it is more difficult to implement.
If you need the name in the security negotiation it is just another
parameter of the
method and you will know when to present it.
If you don't need it you will present it on the last Login request (or text
in the old version) - the one that holds the F bit set.
IAgain I hold no strong opinion for or against what you suggest.
I simply don't want us to make a decision based on convenience. It is a bad
guide.
+++
-Sandeep

> >
> > Steve Senum <[email-masked]>@ece.cmu.edu on 29-08-2001 23:59:36
> >
> > 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,
> >
> > A couple of ideas from Matthew Burbridge & Co.'s
> > login proposal that has generated some interest here:
> >
> > 1. Removal of partial login response.  Is it still needed?
> >
> > 2. Requiring Initiator and (if not a discovery session)
> >    Target names on login command, so they are always
> >    available if needed by the initial phase.
> >
> > Comments?
> >
> > Regards,
> > Steve Senum
> >
> >
> >
> >

---

From: "Julian Satran" <[email-masked]>
Date: Thu, 30 Aug 2001 23:35:07 +0300

If IPsec secures only the connection between
an initiator and a piece of hardware+code that sits in foront of several
initiator (an example of a configuration)
and this piece is the endpoint of the IP connection as seen by the
initiator) a login authenticantion (or none) may be requested by one or
both parties.

Julo

"Bill Strahm" <[email-masked]> on 30-08-2001 23:03:36

Please respond to "Bill Strahm" <[email-masked]>

To:   <[email-masked]>
cc:   Julian Satran/Haifa/IBM@IBMIL, "Ips@Ece. Cmu. Edu" <[email-masked]>
Subject:  RE: iSCSI - Change - Login/Text commands with the binary stage
      code

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-

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

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

---

From: "Julian Satran" <[email-masked]>
Date: Fri, 31 Aug 2001 00:43:15 +0300

Or it may skip the Security Stage at all (e.g., when it uses IPSEc and it
is satisfied with whatever IPSec gives him).

Julo

Steve Senum <[email-masked]>@ece.cmu.edu on 30-08-2001 19:48:04

Julian,

not
> 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: "John Hufferd" <[email-masked]>
Date: Thu, 30 Aug 2001 17:50:42 -0700

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

"Bill Strahm" <[email-masked]>@ece.cmu.edu on 08/30/2001 11:49:01 AM

To:   Julian Satran/Haifa/IBM@IBMIL
cc:   "Ips@Ece. Cmu. Edu" <[email-masked]>
Subject:  RE: iSCSI - Change - Login/Text commands with the binary stage
      code

Ok,

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

Steve,

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

Julo

Julian,

Regards,
Steve Senum

---

From: "John Hufferd" <[email-masked]>
Date: Thu, 30 Aug 2001 17:55:55 -0700

Mark, (I attached this note to the wrong message from you previously, so
here it is attached to the approprate message)

Regardless of whether IKE and IPSec is used, you Still need iSCSI
Authentication to prevent Masquerading as various different iSCSI Initiator
Nodes.

.

.
.
.
John L. Hufferd

Mark Bakke <[email-masked]>@ece.cmu.edu on 08/30/2001 12:13:34 PM

To:   Bill Strahm <[email-masked]>
cc:   Julian Satran/Haifa/IBM@IBMIL, "Ips@Ece. Cmu. Edu" <[email-masked]>
Subject:  Re: iSCSI - Change - Login/Text commands with the binary stage
      code

Bill-

--
Mark

security.
machine
to
be
filters
was
at
I
not

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