Internet DRAFT - draft-du-opsawg-snmp-key-localization
draft-du-opsawg-snmp-key-localization
Network Working Group H. Du
Internet-Draft L. Fang
Intended status: Standards Track F. Zou
Expires: June 1, 2015 D. Zhang
D. He
Huawei Technologies Co., Ltd.
November 28, 2014
A New Algorithm for SNMP Key Localization
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.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 1, 2015.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
Du, et al. Expires June 1, 2015 [Page 1]
Internet-Draft Abbreviated-Title November 2014
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Updated Algorithm . . . . . . . . . . . . . . . . . . . . . . 2
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3
4. Security Considerations . . . . . . . . . . . . . . . . . . . 3
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 3
6. Normative References . . . . . . . . . . . . . . . . . . . . 3
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 3
1. Introduction
In Appendix 2 of [RFC3414], the SNMP localized key is obtained by the
MD5 or SHA function with user password and SnmpEngineID as inputs.
The user password should be padded by repeating itself if its length
is less than 64 Octects. RFC3414 warns that longer passwords with
repetitive strings may result in exactly the same key. For example,
a password 'bertbert' will result in exactly the same key as password
'bertbertbert'. In other words, if an SNMP key string can be
expressed by repeating string S with M times, other keys that
expressed by repeating S with N times are also able to access the
same target device. The traditional solution to avoid this security
issue is to implement an extra module to check the format of user
password, such as the length of the key should be between 8 and 15
chars, it must contain capital, small letters, digits and special
characters, forbid using repetitive string with length as the divisor
of 64. This draft tries to tackle this issue by revising the key
localization algorithm specified in Appendix 2 of [RFC3414].
2. Updated Algorithm
Instead of extending to 64 Octets, the original user password is only
extended to M<64 octets. The remaining Octets are padded with the
original user password length. The value of M could be various, here
we recommend M=60.
Du, et al. Expires June 1, 2015 [Page 2]
Internet-Draft Abbreviated-Title November 2014
while (count < 1048576) {
cp = password_buf;
for (i = 0; i < 60; i++) {
/*************************************************/
/* Take the next octet of the password, wrapping */
/* to the beginning of the password as necessary.*/
/*************************************************/
*cp++ = password[password_index++ % passwordlen];
}
memcpy(cp, &passwordlen, 4);
MD5Update (&MD, password_buf, 64);
count += 64;
}
3. IANA Considerations
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an
RFC.
4. Security Considerations
5. Acknowledgements
6. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model
(USM) for version 3 of the Simple Network Management
Protocol (SNMPv3)", STD 62, RFC 3414, December 2002.
Authors' Addresses
Huan Du
Huawei Technologies Co., Ltd.
Email: duhuan09@huawei.com
Liang Fang
Huawei Technologies Co., Ltd.
Email: leon.fang@huawei.com
Du, et al. Expires June 1, 2015 [Page 3]
Internet-Draft Abbreviated-Title November 2014
Fengyuan Zou
Huawei Technologies Co., Ltd.
Email: Zou.Fengyuan@huawei.com
Dacheng Zhang
Huawei Technologies Co., Ltd.
Email: zhangdacheng@huawei.com
Danping He
Huawei Technologies Co., Ltd.
Email: ana.hedanping@huawei.com
Du, et al. Expires June 1, 2015 [Page 4]
