Re: iSCSI User Auth MIB - security issue

[Mark Bakke <mbakke@cisco.com>]

David-

We added these password fields to allow credentials to be
set up via snmp, but in the real world, most of these secrets
would be configured on a RADIUS or similar server; the
implementor of the MIB would simply hook up the user identity
names.  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.

--
Mark

Black_David@emc.com wrote:
> 
> 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
> ----------------------------------------------------
> 

-- 
Mark A. Bakke
Cisco Systems
mbakke@cisco.com
763.398.1054