SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    Re: IKE and iSCSI Authentication



    
    David,
    I agree with most of what you said, but not comfortable with the Tape
    Application that you address,  but it is NOT important that we agree on
    this at this time.
    
    I really did understand what it take to associate the iSCSI Initiator Name
    with the UserID.  I said that an tight binding table was needed.  I also
    said that you have to be sure that it is kept in sync with the
    Installations User/Password Database/Directory.  You did not refute that,
    just attempted to trivialize the relationship table that needs to be built.
    
    We have never address this Table as part of iSCSI before, and it is
    important that everyone understands this, and that we understand how it is
    to be kept in sync with the installations User/Password Directory.  As part
    of doing this, we need to really understand what directories prevent our
    use of iSCSI Node Names, and which permit it.  We need to understand if it
    is possible to have more then one UserID associated with a single iSCSI
    Node Name, etc.
    
    The point is, this is all new information and has not been discussed, and
    no expert in UserID Directories have had a chance to tell us their
    thoughts.  This needs to be completely understood (especially since it is
    not documented anywhere in our iSCSI Documents), and most folks on this
    Reflector did not have a clue about it.
    
    Discussions and thoughts about this is what I have been trying to get
    going.  I would not like this to fade into the background until it is fully
    reviewed and commented upon.
    
    .
    .
    .
    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
    
    
    Black_David@emc.com@ece.cmu.edu on 08/30/2001 07:50:40 PM
    
    Sent by:  owner-ips@ece.cmu.edu
    
    
    To:   ips@ece.cmu.edu
    cc:
    Subject:  IKE and iSCSI Authentication
    
    
    
    Starting a new thread to try to roll up a number of related
    issues from the User vs. Machine Authentication thread and
    a few others.
    
    -- Concept of "user".
    
    This has been confusing due in part to lazy/sloppy use of
    terminology by yours truly.  The term "machine"
    has been used to refer to IKE authentication that has a single
    identity associated with the network interface (i.e., IP address).
    Finer grain authentication at a higher level has been referred
    to as "user" authentication by analogy to remote access via
    ppp/l2tp/ipsec, where a "machine" is authenticated by IKE
    and a "user" is authenticated by ppp.  For iSCSI, we do have
    a need to authenticate at a finer grain than one entity per
    network interface, but "user" is a poor choice of word for
    that.
    
    -- Need for finer grain authentication than "machine"
    
    As noted earlier, IKE starts up in response to the TCP SYN
    packet being queued for transmission to set up a TCP connection
    for iSCSI.  IKE intercepts that packet and completes its
    its authentication and SA setup before allowing that packet
    to continue on its way (over the SA that was just set up).
    Hence IKE can't know what the iSCSI Initiator and
    Target names are.  The usual result is that the IPsec
    implementation behind a single network interface has a
    single identity.  We went to great efforts in iSCSI to allow
    multiple Initiators and Targets to share IP addresses, and
    hence if there's any authentication associated with those
    names, some other authentication mechanism is required that
    occurs at a later stage and higher level than IKE (i.e.,
    iSCSI inband authentication).
    
    -- Need for authentication management
    
    A careful reader of RFC 2401 will note the ability to inject
    Name information into an IPsec SPD, and if one is careful about
    having Initiators or Targets that one wants to distinguish be
    associated with different OS user identities, this can be made
    to work when IPsec is on the same system as the Initiator or
    Target (it won't work with an outboard security gateway).  This
    is not the best approach in many cases because it requires IKE
    keying material (a certificate or pre-shared key) per identity
    and these things are at best clumsy to administer.
    
    Due to the complexities involved in administering even the best
    IPsec systems, I expect to see deployments in which IPsec and IKE
    are simply not used, or the authentication is very coarse.  One
    could load the same pre-shared key or certificate into multiple
    systems so that the IKE authentication only establishes that both
    systems are members of some "ok" group, and then another mechanism
    is used to determine who can actually access what - inband
    authentication provides that mechanism.  The SRP mechanism is easy
    to set up in situations where one does not want to run IKE, and
    the other mechanisms are motivated by integration into existing
    scalable centrally managed authentication systems - Kerberos,
    CHAP (RADIUS), SPKM* (PKI).
    
    -- That "tape" example
    
    Obviously, I didn't explain this well, because nobody seems to
    understand it.  Consider a SAN-accessible tape drive that is
    sequentially shared by multiple hosts for backup.  To claim
    that the operating systems own the tape drive misses the point
    here - the multiple OSs will allow multiple backups from different
    systems to the same drive to start at the same time, and the result
    will be chaos.  One plausible alternative view is that the SAN
    owns the tape drive, in which case authentication to the drive
    can be used to control who can access it when, and the backup
    application is the obvious entity to authenticate.  Some backup
    applications have application-specific solutions to this problem
    that work among cooperating entities (i.e., each instance of the backup
    app knows that it has to ask permission) - requiring authentication
    can keep out the uncooperative entities that won't bother asking
    for permission.
    
    -- iSCSI names and authentication identities
    
    One could certainly use the same string as the iSCSI Initiator or
    Target name and the userid used to do inband authentication, but
    requiring that forces those strings into the existing authentication
    systems that we'd like to live with.  The alternative of associating
    userids from those systems with iSCSI authentication information
    should be allowed to avoid forcing this.  John complains mightily
    about the required translation, forgetting that there already has
    to be a table indicating which Initiators are allowed to access
    each Target; adding a userid column (or even a list) to this table
    is a minor addition for the benefit of being able to reuse the
    existing authentication infrastructure.  Pierre's suggestion of
    issuing a certificate for every iSCSI initiator and target seems
    to prevent reuse of existing certificates that were already issued
    for some other reason, and that seems very wrong given the administrative
    difficulties already posed by certificate issuance and management.
    Mark's example of wanting to reuse his login ID on a local RADIUS
    server (which is highly unlikely to meet the uniqueness requirements
    of iSCSI Initiator and Target names) is a related situation in which
    this forcing causes problems.
    
    I'll stop here - I think I've caught most of the major points.
    Comments?
    
    Thanks,
    --David
    
    ---------------------------------------------------
    David L. Black, Senior Technologist
    EMC Corporation, 42 South St., Hopkinton, MA  01748
    +1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
    black_david@emc.com       Mobile: +1 (978) 394-7754
    ---------------------------------------------------
    
    
    
    


Home

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