iSCSI User Auth MIB - security issue

[Black_David@emc.com]

Folks,

AD and Expert Review of the User Identity Authentication MIB
for iSCSI, draft-ietf-ips-auth-mib-04.txt, has turned up
some serious security issues with the following two MIB objects:

 	- ipsAuthCredChapPassword
 	- ipsAuthCredSrpPassword

Aside from the first one being misnamed (iSCSI requirements
for CHAP prohibit using something as weak as a password),
the major issue is that even with SNMPv3, it's not possible
to write to these objects with security comparable to the
underlying authentication mechanisms.  SNMPv3 security
apparently does not currently support any encryption 
stronger than DES, making a 56-bit DES key the weak
link if these fields are written via SNMPv3, and anyone
who writes these fields without encryption is probably
clue-impaired.

I'm seeking input on how to move forward.  There are
two basic choices:

(1) Delete those two objects and rename this MIB to be an
Authorization MIB in some fashion.

Despite its Authentication name, this MIB is mostly about
authorization - determining which identities are allowed to
participate in an iSCSI session.  This choice would involve
deleting the above two fields, renaming the MIB from  an
"Authentication" MIB to something containing "Authorization" or
"Access Control", and revising appropriate descriptive text
accordingly.  The resulting MIB would still be able to
configure which identities and related credentials could be
used for by iSCSI counterparts, but would not be able to
set CHAP secrets or SRP passwords.

(2) Retain those two objects either via redesign or work on
SNMPv3 to improve available encryption.

If the WG feels that the ability to set CHAP secrets and SRP
passwords via this MIB is crucial to the functional utility of
the MIB, it is possible do work to improve their security,
either via higher security MIB objects (e.g., along the lines
of the KeyChange TC in RFC 2274) or by providing stronger
encryption for SNMPv3.  Both would involve significant work
and take significant time.

My inclination would be to remove the fields (1), as it's 
simpler and appears to retain most of the useful functionality,
but I wanted to ask WG members whether the resulting loss of
functionality is sufficiently severe to favor an alternative
approach of increasing the security of the objects involved (2).

Please comment.

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