SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    Re: ISCSI: User authentication vs. Machine Authentication for iSCSI



    
    Pierre asks the following question.
    
    "John,
    
    Do i miss something? Why not use Certificate where
    the subjectname is the iSCSI name (iqn or eui)?.
    So as soon as the IPSEC SA are established each side
    knows what intitiator/target is the other side.
    There no need for extra password or alias.
    The only problem with that is that some directory
    as you mentionned below wouldn't support subjectname
    as long as an iqn? "
    
    I would like to see more discussion on the feasibility of this approach,
    especially
    since iSCSI and IKE/IPSec are disjoint processes.  Please, anyone, that
    understands
    how these different layers would communicate with each other (using
    Standard IKE/IPSec
    implementations) please help.  For instance how does the IKE get the iSCSI
    name of the
    system on which it is running, and how does the iSCSI layer find out the
    "Subjectname"
    the remote system used to establish the connection, since it must be check
    that it is the
    same name sent on the iSCSI Login."  (Otherwise any valid Certificate owner
    could still
    masquerade as any other iSCSI Initiator Node.)
    
    Also, if we can figure out how the above works, we need to understand how,
    in an SRP environment,
    the iqn or eui type name can be used.  (Environment 3).
    
    Further, following Mark's Environment 2, we still need to find a way to use
    the iSCSI initiator Node
    Name, or understand the ramifications of establishing and using a related
    Alias for the
    iSCSI initiator node name.
    
    .
    .
    .
    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: hufferd@us.ibm.com
    
    
    Pierre Labat <pierre_labat@hp.com>@cup.hp.com on 08/30/2001 08:37:46 AM
    
    Sent by:  plabat@cup.hp.com
    
    
    To:   John Hufferd/San Jose/IBM@IBMUS
    cc:   ips@ece.cmu.edu
    Subject:  Re: ISCSI: User authentication vs. Machine Authentication for
          iSCSI
    
    
    
    
    John Hufferd wrote: Bill,
    You are correct, in my opinion, on the problem statement, but not  on the
    solution.
    
    The IKE stuff will Get a system identified, and perhaps ensure that a
    encrypted connection is put in place.  This then give the Source and Target
    the Freedom to exchange stuff that would otherwise be in the clear, such as
    iSCSI Node Names etc.  But after the iSCSI session is established, it is
    between an OS and a target.  The OS, is the thing that actually owns the
    resource, it only loans the resources, in some manor, to applications.
    
    I was having a similar problem to what you stated, at the Irvine meeting,
    and kept digging and objecting (off-stage) until I got the following more
    acceptable response.
    
    Environment 1: (Use of IKE with complete Certificates processing ( or
    pre-Shared password), with ESP equal to something other then Null)
    1. We use IKE to get a mutually authenticated and Encrypted communication
    link.  This means that the Target knows that (at the IKE/TCP Layer) there
    is, at the other end, an authorized thing.  (What or who that thing is,
    relative to iSCSI is not really known).  This secure link can be
    established either via Certificates or via a pre-Shared password.
    2. An iSCSI Login can now be done, over a secure link, so the iSCSI
    Initiator Name, and iSCSI Target Name etc can be exchanged securely.
    Please note, just because you passed the IKE certificate gate does not mean
    you are the iSCSI Initiator that you claim to be.John,
    
    Do i miss something? Why not use Certificate where
    the subjectname is the iSCSI name (iqn or eui)?.
    So as soon as the IPSEC SA are established each side
    knows what intitiator/target is the other side.
    There no need for extra password or alias.
    The only problem with that is that some directory
    as you mentionned below wouldn't support subjectname
    as long as an iqn?
    
    Regards,
    
    Pierre Therefore, a password,
    for example, that is associated with the iSCSI Initiator Name can now be
    used to perform an iSCSI validation of the Initiator.  (Please note, this
    could, instead of a password,  be a Kerberos type Validation etc.)
    3. David, and perhaps other used the words "User" or "Application" name to
    address what was being addressed in 2 above.  But there was more to this
    then just assuming that the iSCSI Initiator Name was the User name.  Since
    folks may actually want to use existing infrastructure, to handle the
    password management and authentication process, they will need to assign
    what I might call an "Alias for the iSCSI Initiator" which can actually be
    saved in the existing infrastructure user authentication repository.  The
    point that was made to me, is that iSCSI Initiator Name (iqn or eui) will
    not "fit" into things that contain "User Names" so we need to have a
    corresponding "User Name" that we can actually authenticate using, for
    example Microsoft Active Directory etc. Hence the need for a "Alias for the
    iSCSI initiator.  (I really hate this, and wish there was something else we
    could do.)
    
    
    
    
    


Home

Last updated: Tue Sep 04 01:03:49 2001
6315 messages in chronological order