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

"Hedanping (Ana)" <ana.hedanping@huawei.com> Wed, 03 December 2014 10:02 UTC

Return-Path: <ana.hedanping@huawei.com>
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECC001A1A10 for <opsawg@ietfa.amsl.com>; Wed, 3 Dec 2014 02:02:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.611
X-Spam-Level:
X-Spam-Status: No, score=-3.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MsbW14hOZNvo for <opsawg@ietfa.amsl.com>; Wed, 3 Dec 2014 02:02:53 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36A751A0389 for <opsawg@ietf.org>; Wed, 3 Dec 2014 02:02:51 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BPN11103; Wed, 03 Dec 2014 10:02:49 +0000 (GMT)
Received: from SZXEML454-HUB.china.huawei.com (10.82.67.197) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 3 Dec 2014 10:02:20 +0000
Received: from szxeml557-mbs.china.huawei.com ([169.254.6.67]) by SZXEML454-HUB.china.huawei.com ([10.82.67.197]) with mapi id 14.03.0158.001; Wed, 3 Dec 2014 18:00:17 +0800
From: "Hedanping (Ana)" <ana.hedanping@huawei.com>
To: "t.petch" <ietfc@btconnect.com>, Johannes Merkle <johannes.merkle@secunet.com>, "Bert Wijnen (IETF)" <bertietf@bwijnen.net>, "Zhangdacheng (Dacheng)" <zhangdacheng@huawei.com>, "opsawg@ietf.org" <opsawg@ietf.org>
Thread-Topic: [OPSAWG] New Version Notification for draft-du-opsawg-snmp-key-localization-00.txt
Thread-Index: AQHQC32W7oq+6LVoDE6S5Cxlxqg8yZx25Uig//+PYQCABB7B5YADEpyQ
Date: Wed, 03 Dec 2014 10:00:16 +0000
Message-ID: <77FA386512F0D748BC7C02C36EB1106D8F534A@szxeml557-mbs.china.huawei.com>
References: <77FA386512F0D748BC7C02C36EB1106D8F4E6D@szxeml557-mbs.china.huawei.com> <C72CBD9FE3CA604887B1B3F1D145D05EA9DCA75B@nkgeml507-mbs.china.huawei.com> <019501d00d55$33c871e0$4001a8c0@gateway.2wire.net>
In-Reply-To: <019501d00d55$33c871e0$4001a8c0@gateway.2wire.net>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.95.23]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/fkcjYpXfmxYCyGvkfj9EyC3KBHw
Cc: "draft-du-opsawg-snmp-key-localization@tools.ietf.org" <draft-du-opsawg-snmp-key-localization@tools.ietf.org>
Subject: Re: [OPSAWG] New Version Notification for draft-du-opsawg-snmp-key-localization-00.txt
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsawg/>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Dec 2014 10:02:56 -0000

Thanks for the comments and I answer all the questions together:

The new algorithm only tries to tackle the repetitive password issue of key localization. So, it is not the objective of this algorithm to increase entropy. 

Tom mentioned 'anyone who uses a password based system and does not have an extra module to ensure that passwords meet current standards deserves all the security breaches they get ' , and it is really extreme. The more constraints we impose on user password, the less the available password space will be, which will in turn increases the possibility of collision attack. We examined enormous devices that have extra modules for SSH and even for Windows server. It turns out that the extra module for SNMPV3 already disobeys the regular and prevalent way, which normally checks '8 character string, upper case, lower case, digit and extended punctuation'. Thus 'BerT135!BerT135!BerT135!' is believed strong enough in a regular check.

Hacker communities have mentioned the current key localization method as a loophole, and plan to submit it to CVE.

Moreover, as the co-author of 'draft-hartman-snmp-sha2', I definitely agree SHA2 being used in SNMP. We also support the adoption of 'draft-hmac-sha-2-usm-snmp ' in order to support SHA2 to be a standard SNMP authentication method. If SHA2 is adopted, changes are mandated in the SNMP module. I don't think the change of key localization 'from 64bits to 60bits+4bits' can be more than the change' from SHA1,MD5 to SHA2'!

Hence why don't we change the key localization algorithm together with authentication method and enhance the SNMP to a better security level, and most importantly with interoperability?

I believe as time goes by standards should be updated. Especially for a protocol like SNMP, which impacts worldwide devices, the requirements of standardizing secure key localization method, authentication method and so on are emerged.

Cheers,
Ana

> -----Original Message-----
> From: t.petch [mailto:ietfc@btconnect.com]
> Sent: Monday, December 01, 2014 6:31 PM
> To: Zhangdacheng (Dacheng); Hedanping (Ana); opsawg@ietf.org
> Cc: draft-du-opsawg-snmp-key-localization@tools.ietf.org
> Subject: Re: [OPSAWG] New Version Notification for
> draft-du-opsawg-snmp-key-localization-00.txt
> 
> ----- Original Message -----
> From: "Zhangdacheng (Dacheng)" <zhangdacheng@huawei.com>
> To: "Hedanping (Ana)" <ana.hedanping@huawei.com>; <opsawg@ietf.org>
> Cc: <draft-du-opsawg-snmp-key-localization@tools.ietf.org>
> 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:opsawg-bounces@ietf.org] On Behalf Of Hedanping
> > > (Ana)
> > > Sent: Saturday, November 29, 2014 10:52 AM
> > > To: opsawg@ietf.org
> > > Cc: draft-du-opsawg-snmp-key-localization@tools.ietf.org
> > > 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)