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

From: "Fangliang (Leon, ICSL)" <[email-masked]>
Date: Fri, 23 Jan 2015 07:54:50 +0000

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-masked]] 
发送时间: 2014年12月1日 18:31
收件人: Zhangdacheng (Dacheng); Hedanping (Ana); [email-masked]
抄送: [email-masked]
主题: Re: [OPSAWG] New Version Notification for draft-du-opsawg-snmp-key-localization-00.txt

----- Original Message -----
From: "Zhangdacheng (Dacheng)" <[email-masked]>
To: "Hedanping (Ana)" <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
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-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.
> >
> > 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)

---

From: Johannes Merkle <[email-masked]>
Date: Fri, 23 Jan 2015 11:09:43 +0100

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

To me, your statement seems exaggerating the issue: The problem is simply that passwords A...A consisting of repetitions
of an expression A result in the same key as passwords with less repetitions. However, the entropy gained by repetitions
is quite low, and if a user chooses the password "bertbert", she cannot expect it much more difficult to guess than if
it was "bert". Thus, the fact that the attacker succeeds as soon as he guesses "bert" is just a gradual amplification of
an issue that exists outside the cryptographic method. And as others have pointed out, it is common sense that choosing
such passwords A...A is poor practice.

I don't mean say that the issue is completely irrelevant, but just it is not as severe as your post seems to imply. And
given the difficulties involved with a potential change, I doubt that it is worth.

That said, I suggest to include a warning into the security considerations of draft-hmac-sha-2-usm-snmp pointing to this
issue and recommending (generally) to use sufficiently strong passwords. RFC 3414 already contains such a caveat but
repeating it in the new specification might help to draw attention to it.
-- 
Johannes

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 23 Jan 2015 11:12:52 +0100

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:
> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> 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/>

---

From: "Fangliang (Leon, ICSL)" <[email-masked]>
Date: Fri, 23 Jan 2015 07:26:19 +0000

Hi Tom and all,

Regards,
Fang Liang

-----邮件原件-----
发件人: t.petch [mailto:[email-masked]] 
发送时间: 2014年12月1日 18:31
收件人: Zhangdacheng (Dacheng); Hedanping (Ana); [email-masked]
抄送: [email-masked]
主题: Re: [OPSAWG] New Version Notification for draft-du-opsawg-snmp-key-localization-00.txt

----- Original Message -----
From: "Zhangdacheng (Dacheng)" <[email-masked]>
To: "Hedanping (Ana)" <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Saturday, November 29, 2014 3:59 AM

Tom Petch

algorithm, but
draft is

---

From: t.petch <[email-masked]>
Date: Fri, 23 Jan 2015 13:21:01 +0000

----- Original Message -----
From: "Fangliang (Leon, ICSL)" <[email-masked]>
To: "t.petch" <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>; "Hedanping
(Ana)" <[email-masked]>
Sent: Friday, January 23, 2015 7:26 AM

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

I think the same comment as last time, that the improvement in security
is slight and the cost of doing so significant.  And better alternatives
are available (e.g. SNMP over TLS, Netconf).

Tom Petch

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

---

From: Warren Kumari <[email-masked]>
Date: Fri, 23 Jan 2015 09:41:17 -0500

[ With chair hat ]

Yup - this does not seem like a document that the WG is interested in
working on. If the authors are concerned about the strength of the key
created by the password expansion function, I'd suggest that a blog
posting suggesting longer passwords be used would be more useful.

W

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Robert Story <[email-masked]>
Date: Fri, 23 Jan 2015 10:13:52 -0500

On Fri, 23 Jan 2015 11:09:43 +0100 Johannes wrote:
JM> I don't mean say that the issue is completely irrelevant, but just it
JM> is not as severe as your post seems to imply. And given the
JM> difficulties involved with a potential change, I doubt that it is worth.
JM> 
JM> That said, I suggest to include a warning into the security
JM> considerations of draft-hmac-sha-2-usm-snmp pointing to this issue and
JM> recommending (generally) to use sufficiently strong passwords. RFC 3414
JM> already contains such a caveat but repeating it in the new
JM> specification might help to draw attention to it.

+1

Robert

-- 
Senior Software Engineer @ Parsons