From: Keith McCloghrie <kzm@cisco.com>
Message-Id: <200306260143.SAA18700@cisco.com>
Subject: Re: iSCSI User Auth MIB - security issue
To: Black_David@emc.com
Date: Wed, 25 Jun 2003 18:43:56 -0700 (PDT)
Cc: ips@ece.cmu.edu
In-Reply-To: <277DD60FB639D511AC0400B0D068B71E0564CE0F@corpmx14.us.dg.com> from "Black_David@emc.com" at Jun 25, 2003 03:46:00 PM
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

David,
 
The statement (below) about DES was true last year but it's about to
become false, because draft-blumenthal-aes-usm-05.txt recently went
through IETF Last Call, and all the security-related issues raised were
requests for clarifications/further explanations.  An updated draft
addressing all the Last Call comments is ready to be submitted (before
next week's deadline).

Thus, your choice 2) is already in process, and "the major issue" will
no longer be valid when the User Identity Authentication MIB is ready
to be standardized.

Keith.

PS. One of the requirements of the Security Considerations section
in a RFC containing a MIB is to specify which objects need what
kind of security, e.g., encryption.


> 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
> ----------------------------------------------------
>  
>