SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    RE: question about iscsiTgtPortalAttributesTable



    On Fri, 6 Jun 2003 wrstuden@wasabisystems.com wrote:
    
    > On Thu, 5 Jun 2003, Elizabeth G. Rodriguez wrote:
    >
    > > Hi Bill,
    > >
    > > First off, wouldn't this need to be covered in the auth MIB instead of the
    > > iSCSI MIB?  (though both are in the hands of the ADs at this point).
    >
    > Probably not. These "self" auths are auths just like any other, and the
    > current Auth-MIB structure describes them well.
    >
    > > Do you have a proposed solution to the issue?
    > > Is this something that can be addressed in a new MIB, or does it really need
    > > to belong in one of the above named MIBs?
    
    Ok. After talking with David, I have a better statement of the problem:
    
            The iSCSI MIB and AUTH MIB do not support configuring
            the identity and authentication credentials that a
            local iSCSI node uses to identify/authenticate
            itself to other nodes.  The MIBs can only specify the
            identity and credentials that other nodes use to
            identify/authenticate themselves to the local iSCSI node.
    
    I want to thank David for supplying the above text.
    
    My proposed solution is to add two other tables of AUTH-MIB references,
    iscsiTgtSelfAuth and iscsiIntrSelfAuth. These tables will behave the same
    as iscsiTgtAuth and iscsiIntrAuth, but will point to credentials used for
    the node authenticating itself to other nodes, rather than other nodes
    authenticating to it.
    
    I think this change is important for three reasons:
    
    1) Some sites will have safe, secure SNMP and this change will let them
    configure all aspects of authentication. While there has been a lot of bad
    SNMP and the thought of SNMP-based host configuration makes many
    (justifiably) cringe, SNMP v3's security is strong enough that it would
    make this configuration safe. I suspect that the kind of sites that would
    get SNMP configuration working safely are typically the large ones that
    could benefit from having all aspects of configuration under SNMP control.
    
    I'll not that I think the most sensitive auth entries are the ones in
    iscsiTgtAuth, as they permit an initiator to connect to a target. So
    adding this change isn't creating a new security concern-pinacle. :-)
    
    2) While I expect most sites won't enable SNMP configuration, being able
    to verify what credentials a node has configured for itself will help
    verify configuration correctness. If a group of targets expect initiator
    iqn.2000-01.com.foo.bigserver to use chap key "bigserver" but it is
    configured to contain "bigerver", well, there's an obvious configuration
    problem.
    
    3) The SNMP MIB serves as a reference MIB for iSCSI node configuration
    data, even in products without SNMP support. I've spoken with other
    vendors, and a number of iSCSI products' internal configurations parallel
    the MIBs. By adding these tables, we will set a consistent format for
    representing these authentication credentials.
    
    Given the timing, it sounds like the best approach is for me to write a
    follow-on draft to the iSCSI MIB.
    
    Any comments/thoughts?
    
    Take care,
    
    Bill
    


Home

Last updated: Tue Aug 05 12:46:14 2003
12771 messages in chronological order