Subject: [OPSAWG] FW: New Version Notification for draft-du-opsawg-snmp-key-localization-00.txt

From: "Hedanping (Ana)" <[email-masked]>
Date: Sat, 29 Nov 2014 02:51:37 +0000

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

---

From: "Zhangdacheng (Dacheng)" <[email-masked]>
Date: Sat, 29 Nov 2014 03:59:30 +0000

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-masked]] On Behalf Of Hedanping
> (Ana)
> Sent: Saturday, November 29, 2014 10:52 AM
> To: [email-masked]
> Cc: [email-masked]
> 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.
> 
> 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-localization/
> Htmlized:
> http://tools.ietf.org/html/draft-du-opsawg-snmp-key-localization-00
> 
> 
> Abstract:
> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Sat, 29 Nov 2014 14:25:11 +0100

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

---

From: "Zhangdacheng (Dacheng)" <[email-masked]>
Date: Mon, 1 Dec 2014 02:52:38 +0000

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

> From: Bert Wijnen (IETF) [mailto:[email-masked]]
> Sent: Saturday, November 29, 2014 9:25 PM
> To: Zhangdacheng (Dacheng); Hedanping (Ana); [email-masked]
> Subject: Re: [OPSAWG] New Version Notification for
>  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.
> 
> 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:
> > 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
> >
> >> 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.
> >>

---

From: "Hedanping (Ana)" <[email-masked]>
Date: Mon, 1 Dec 2014 03:51:04 +0000

The security of SNMP is emerged to be enhanced . Besides customers won't check RFC before using SNMP devices, thus they are not aware of this vulnerability. Vendors have to implement extra modules to constrain user behavior, but not all the vendors do so. The current key localization algorithm is vulnerable, and the CVSS is rated as 7.6, AV:N/AC:H/Au:N/C:C/I:C/A:C. The new key localization mechanism might be bundled with SHA2 as important updates.

Cheers,
Ana

> From: Zhangdacheng (Dacheng)
> Sent: Monday, December 01, 2014 10:53 AM
> To: Bert Wijnen (IETF); Hedanping (Ana); [email-masked]
> Subject: RE: [OPSAWG] New Version Notification for
> 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
> 
> >  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.
> >
> > 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:
> > 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
> > >
> > >> https://datatracker.ietf.org/doc/draft-du-opsawg-snmp-key-localizat
> > >> io
> > >> n/
> > >> Htmlized: