Hi, Bert: Thanks a lot for your comments. We fully understand the concerns of potential compatibility issues. That is why we intend to firstly discuss whether this work will bring more benefits than negative influences . However, for the moment, opsawg is discussing the work of enhancing snmp with sha-2. So, maybe we can use this chance to address this problem and use the new key localization mechanism for sha-2 only? That is, when md-5 or sha-1 is deployed for snmp, we still use the old algorithm.
Thoughts? Dacheng > -----Original Message----- > From: Bert Wijnen (IETF) [mailto:[email protected]] > Sent: Saturday, November 29, 2014 9:25 PM > To: Zhangdacheng (Dacheng); Hedanping (Ana); [email protected] > Cc: [email protected] > Subject: Re: [OPSAWG] New Version Notification for > draft-du-opsawg-snmp-key-localization-00.txt > > From a quick check, it seems that your solution would solve the problem that > we describe in RFC3414. However, RFC3414 also discusses the issue (page 73) > in the Security considerations, so users of the spec should/could be well > aware > of the issue and easily avoid the problem. > > It should also be clear to anyone that a password of "bertbert" or any > "abcdabcd" repeated sequence is a very weak password. > > The RFC3414 spec (i.e. its final Internet Standard version) is from 2002. > I don;t think it is wise to change the algorithms at this point, specifically > since > we have documented how to avoid the issue. > > If we (IETF) were to change the algorith, I think we would also have to > indicate > how implementations of the old and new algorithms can coexist. We cannot > expect all current deployments to migrate to a new version on some D-day. > > Full disclosure: > as co-author of the RFC3414 I am probably biased. > > Bert > > On 29/11/14 04:59, Zhangdacheng (Dacheng) wrote: > > 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. > > > > 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-localization-00. > >> txt > >> Status: > >> https://datatracker.ietf.org/doc/draft-du-opsawg-snmp-key-localizatio > >> n/ > >> 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 > > > > _______________________________________________ > > OPSAWG mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/opsawg > > _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
