SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    Re: iSCSI Login



    
    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
    
    
    
    
    
    
    


Home

Last updated: Tue Sep 04 01:05:19 2001
6315 messages in chronological order