RE: question about iscsiTgtPortalAttributesTable

[wrstuden@wasabisystems.com]

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