RE: iSCSI User Auth MIB - security issue

[Black_David@emc.com]

Bernard,

> >So in most cases, we would not likely lose anything
> >by removing these two objects, since if we are using RADIUS, the 
> >iSCSI/FCIP/etc entity would not know or be able to configure the 
> >secrets.
> 
> Out of curiosity -- how would the authorization be accomplished if
> RADIUS is used?  Wouldn't a similar problem exist?

I think that's Mark's point - the object that contains the CHAP
authentication secret is of no use when RADIUS verifies authentication,
as the secrets that matter are on the RADIUS server, not the iSCSI
node. So, in the RADIUS case, the MIB as-is functions only to do
authorization (i.e., which identities using what authentication
methods have access to which targets) in combination with the main
iSCSI MIB.

As a reminder, the functionality change if the objects are removed
is that SNMP could not be used to set CHAP secrets or SRP passwords
of counterparts to be authenticated.

On further thought, SRP "password" set should be ok via
SNMP as long as what is being set is the SRP password *verifier* -
that's ok to make public as long as bidirectional SRP authentication
is not in use, as the second direction of bidirectional authentication
(responder demonstrates knowledge of verifier) relies on the verifier
being secret.  Unfortunately, the MIB describes ipsAuthCredSrpPassword
as containing the password (from which one could presumably compute
the verifier by unspecified means) rather than the verifier itself -
that would have to change if this set ability were retained, and
doubly unfortunately, an object would have to be added to allow
the SRP salt to be set (not present in the current MIB).

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
black_david@emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------