Hi, you still seem to confuse key localization with the optional transform of a password into a (non-localized) key (that is subsequently localized).
/js On Fri, Jan 23, 2015 at 07:54:50AM +0000, Fangliang (Leon, ICSL) wrote: > Hi Tom and all, > > Network management protocol is usually attackers' target. Once attacked, the > service will be tampered and result in significant security issue. As SNMP is > the widely used management protocol for network device and a large proportion > of network devices support SNMP, the security of SNMP is especially > important. As a result we (IETF) should pay more attention to SNMP security > issues. > > The security expert as Stuart McClure have mentioned SNMP in his famous book > as "HACKING EXPOSED 7: NETWORK SECURITY SECRETS & SOLUTIONS", McGraw-Hill > Education, 2012, pp 348: Conceived as a network management and monitoring > service, the Simple Network Management Protocol (SNMP) is designed to provide > intimate information about network devices, software, and systems. As such, > it is a frequent target of attackers. In addition, its general lack of strong > security protections has garnered it the colloquial name “Security Not My > Problem.” > > The current Key Localization Algorithm have obvious vulnerability. We never > see such cryptographic algorithm defect in other widely used protocol. Hacker > communities have mentioned the current key localization method as a loophole, > and plan to exploit the vulnerability or publish it to CVE. > > To add an extra password processing module for SNMPV3, it need add more > restricted condition than the regular way. We have discussed it with design > teams, nobody accept this design proposal, for it will induce more > interoperability problems for other password based module. Besides, this is a > collision problem in key localization in SNMP, it is not suitable to demand > the developer to change the general module to fix this special problem in > SNMP. > > In consideration of other architectural vulnerability, this vulnerability can > be easily fixed by little revision as proposed by this draft . Any comments? > > > Regards, > Fang Liang > > > > ----- Original Message ----- > 发件人: t.petch [mailto:[email protected]] > 发送时间: 2014年12月1日 18:31 > 收件人: Zhangdacheng (Dacheng); Hedanping (Ana); [email protected] > 抄送: [email protected] > 主题: Re: [OPSAWG] New Version Notification for > draft-du-opsawg-snmp-key-localization-00.txt > > ----- Original Message ----- > From: "Zhangdacheng (Dacheng)" <[email protected]> > To: "Hedanping (Ana)" <[email protected]>; <[email protected]> > Cc: <[email protected]> > Sent: Saturday, November 29, 2014 3:59 AM > > > Let me help clarify Danping's point. > > > > We found there was a problem in the localization algorithm, but we are > not sure whether this issue is worthwhile for us to address, or the effort of > addressing this issue is out of scope of the SNMP specification. So, we raise > this question here, and hope to get comments or suggestions. > > The new algorithm that you propose seems to offer very little improvement. > You suggest that after replicating the password, you then add the password > length in the last four octets to bring the length up to 64 octet. This > seems to add very little entropy. > > Also, an 8 character string, containing upper case, lower case, digit and > extended punctuation would have been regarded as too weak many years ago and > we should not be documenting such an approach now. > > Again, anyone who uses a password based system and does not have a extra > module to ensure that passwords meet current standards deserves all the > security breaches they get! > > Tom Petch > > > > > Cheers > > > > Dacheng > > > > > -----Original Message----- > > > From: OPSAWG [mailto:[email protected]] On Behalf Of Hedanping > > > (Ana) > > > Sent: Saturday, November 29, 2014 10:52 AM > > > To: [email protected] > > > Cc: [email protected] > > > Subject: [OPSAWG] FW: New Version Notification for > > > draft-du-opsawg-snmp-key-localization-00.txt > > > > > > Dear all, > > > We find a security problem in the current SNMP key localization > algorithm, but > > > we are not sure whether IETF is the right place to improve it. The > draft is > > > submitted and comments are appreciated. > > > > > > A new version of I-D, draft-du-opsawg-snmp-key-localization-00.txt > > > has been successfully submitted by Danping He and posted to the IETF > > > repository. > > > > > > Name: draft-du-opsawg-snmp-key-localization > > > Revision: 00 > > > Title: A New Algorithm for SNMP Key Localization Document date: > > > 2014-11-28 > > > Group: Individual Submission > > > Pages: 4 > > > URL: > > > > http://www.ietf.org/internet-drafts/draft-du-opsawg-snmp-key-localizatio > n-00. > > > txt > > > Status: > > > > https://datatracker.ietf.org/doc/draft-du-opsawg-snmp-key-localization/ > > > Htmlized: > > > http://tools.ietf.org/html/draft-du-opsawg-snmp-key-localization-00 > > > > > > > > > Abstract: > > > This draft discusses a security issue with the algorithm for > > > generating SNMP localized keys and introduce a new algorithm to > > > address this problem. > > > > > > > > > Regards, > > > Ana (Danping) > > _______________________________________________ > OPSAWG mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/opsawg -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/> _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
