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



    
    Comments in line below.
    
    
    .
    .
    .
    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
    
    
    Stephen Bailey <steph@cs.uchicago.edu>@ece.cmu.edu on 08/30/2001 06:50:23
    AM
    
    Sent by:  owner-ips@ece.cmu.edu
    
    
    To:   ips@ece.cmu.edu
    cc:
    Subject:  Re: ISCSI: User authentication vs. Machine Authentication for iSC
          SI
    
    
    
    > I believe this is the "iSCSI Name" (formerly WWUI).
    
    I guess I was unclear.  I consider the iSCSI name to BE the `user
    name' in this discussion.
    
    I was not suggesting that we introduce any additional identities.  I
    was only suggesting it might be a mistake to slavishly equate identity
    with OS instance.  I don't THINK we're in any risk of doing that.
    Somebody please shout if they think we are, or if they think we should
    be.
    
    /*Huf**
    The new Name (UserID) is exactly what was implied at the meeting in Irvine.
    The reason that came in was that it was stated that the iSCSI
    Initiator Node Name would not Fit into the installation's normal
    Authorization
    process (which today is used to Authenticate USERS), such as the
    Microsoft Active Directory.
    **Huf*/
    
    
    If a user process wants to initiate its own iSCSI connection to a
    target, there are two options:
      1) the host OS gives the process ITS identity (& credentials)
      2) the user process uses its own unique identity (obtained through
         some mechanism we're not describing or discussing, e.g. from the
         storage domain administrator).
    
    1) would be the case if you were using SCSI passthru to an iSCSI
    driver.  In this situation, it's still really the OS that's doing the
    interaction as a proxy for the user.  The OS can ensure (or not) that
    its identity isn't being abused.  The OS could also give its identity
    to a user-mode iSCSI sockets client through a securable interface.
    The OS should never completely freely give away its identity (e.g. to
    an untrusted user process), unless it doesn't care how it's used.
    
    /*Huff**
    A number of us, I am sure, think this is a very poor direction for an
    implementation. But you are correct. If an OS passes off its identity
    to a User Process, a User Process could masquerade as a valid OS and
    send its own stuff via a normal TCP/IP Sockets. Since this application
    would not be able to use the iSCSI HW HBAs, that most Servers will be
    dependent upon to provide the approprate performance and lower the
    TCP/IP processing overhead, I believe that this approach will probably
    not be an important issue for legitimate applications.
    **Huff*/
    
    2) would be the case if jane helpful-programmer (or joe script-kiddy)
    wrote a user-mode iSCSI initiator using sockets for whatever purpose.
    
    /*Huff**
    This is one of the problems we must protect from. Since an OS (iSCSI
    Initiator Node Name can be validated, we must make sure that the
    Authorization approach prevents this from happening.  As I stated
    above I can not believe that a user mode application (other then in
    development) that had to add all its own PDU structures etc.
    would be a valid application (especially since it could NOT use any
    iSCSI offload HW that might be in place.)
    So I believe we must consider such a potential application as
    probably a rouge application and do nothing to help this, and work
    to prevent it.
    **Huff*/
    
    Perhaps I'm covering old ground that was already worked out at the
    interim meeting.  If so, I apologize.
    
    /*Huff**
    This is just a direction (thread) that got started, based on a
    misunderstanding
    of what was meant when the concept of UserID came up as part of
    authentication during the Irvine meeting.
    The important issue is, can we make the iSCSI Initiator Node Name be used
    as the UserID.  A separate UserID is only needed if you use an
    existing Authentication infrastructure that does not permit the
    use of the eui or iqn type names.  This is where we need to focus
    and see if we fully understand the problems and the impacts of
    such approaches.
    **Huff*/
    
    
    Steph
    
    
    
    


Home

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