Re: iSCSI Login

[julian_satran@il.ibm.com]

John,

Yes it is easier to do, it does not make sense to enforce similarity (no
good infrastructure and no real benefit as sessions are long- very much
unlike http where it makes sense to replicate security and avoid
negotiation) and then it will be nice to have private channel with a backup
public channel not having the same security.

Regards,
Julo



John Hufferd@IBMUS
15/03/2001 19:53

To:   Julian Satran/Haifa/IBM@IBMIL
cc:   ips@ece.cmu.edu
From: John Hufferd/San Jose/IBM@IBMUS
Subject:  Re: iSCSI Login  (Document link: Julian Satran - Mail)

Julian,
Perhaps I missed something important here but I can not remember a reason
why there would need to be different Security actions on each connection
within a session.  I can understand that being appropriate for different
Sessions, but it seems strange to me that it make since within a Session.

Perhaps, the code is easier if you did not check to see if they are
consistent, so that your proposed wordage is applicable in all cases and
therefore the Target does not have to care about, and not have to enforce
the same Security process across different connections within the same
Session.  If that is what you are saying, then maybe it is alright, but it
does seem strange.  I can not think of a credible reason why any Session
would have different Security processes on its different connections.

Please let me know what I missed, or your thinking about the value of your
proposed new wording.

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


Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 03/15/2001 06:34:16 AM

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


To:   ips@ece.cmu.edu
cc:
Subject:  Re: iSCSI Login





Mathew,

Answers in text - Julo

"BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" <matthew_burbridge@hp.com> on
15/03/2001 11:43:33

Please respond to "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)"
      <matthew_burbridge@hp.com>

To:   ips@ece.cmu.edu
cc:
Subject:  iSCSI Login




Hi Julian,

A couple of items:

1) Section 4.1 (iSCSI Rev 5) states that:

The target can answer in the following ways:

      -Login Response with Login Reject (and F bit 1).  This is an
      immediate rejection from the target, that causes the session to
      terminate

I agree that this could be the case for a security breach - authentication
failed but what if the target only supports one connection per session and
the initiator is attempting to set up another connection.  Surely, the new
login should be rejected but the session remains intact.


+++ will fix - the new text will be:

Login Response with Login Reject (and F bit 1).  This is an immediate
rejection from the target, that causes the connection to terminate. If this
connection is the leading or only connection of a session the session is
also terminated.

++++
2) Still on the subject of login:  In section 4, page 74, the spec states
that:

  "The initiator and target MAY want to negotiate authentication and
   data integrity parameters. Once this negotiation is completed, the
   channel is considered secure."

It is unclear as to the mandated handling of conflicting/differing
authentication mechanisms negotiated on multiple connections participating
in the same session.  I  propose that the spec should state that if
authentication is required then the same authentication method MUST
be used on all connections in a session.


+++ we are going to add the following clarification text to 8.1 (I hope it
answers also your implied question).

   Each connection in a session may operate in a different security
   protection mode.  Some connection may use private networks and require
   minimal protection while others may use public networks and require the
   highest level of protection.

   ++++


Cheers

Matthew Burbridge
Network Infrastructure Solutions
Hewlett Packard
Bristol
+44 117 312 7010
E-mail: matthewb@bri.hp.com