Internet Draft SNMPv2a August 1995 SNMPv2a Simple Authentication/Integrity for Community-based SNMP messages Wed Aug 4th, 13:23 EDT 1995 Uri Blumenthal, Nguyen C. Hien, Bert Wijnen T.J. Watson Research Center, IBM Corp. Yorktown Heights, NY, USA Bob Natale ACE*COMM Gaithersburg, MD, USA Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its Working Groups. Note that other groups may also distribute working documents as Internet-Drafts. 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'. Expires January 1996 [Page 1] " Internet-Draft SNMPv2a August 1995 1. Introduction The authors of this document are quite familiar with the various proposals that have been made concerning the SNMPv2 security architecture and some authors have actually implemented the various proposals and have shown that implementation is possible in an interoperable manner. However, it is apparent from this experience and other sources and forms of evidence that the SNMPv2 security architecture has not achieved the same degree of consensus that the other parts of SNMPv2 have achieved. Furthermore, some analyses of the proposed SNMPv2 security architecture suggest that it might face significant hurdles in the marketplace due to its inherent complexity and susceptibility to rapidly changing technology alternatives. But while the jury is still out discussing the merits of the protocols and methods proposed, deployed SNMP has no security at all. This proposal will show how with almost zero implementation costs one can plug the biggest hole in SNMPv1 - namely passwords being sent in clear, and at the same time maintain 100% compatibility with existing SNMPv1 implementations. The only goal of this proposal is to prevent eavesdropping on the password (community names in SNMPv1). But as a freebee, both message integrity and source authentication (to the level of belonging to the given community) are achieved. Implementation complexity and extra code size/performance hits are negligible, which allows quick deployment and wide usage until a more complete security procedures are agreed upon and accepted by the market. Expires January 1996 [Page 1] " Internet-Draft SNMPv2a August 1995 2. Elements of the Model Every community which wants to utilize this approach, gets a password assigned to it, in addition to the traditional "community name". From this password, 16-bytes long key is derived as in Waldbusser's Simplified Configuration and in USEC draft (see "password_to_key()" routine in [4], where the C source code example is given). The new message format is the same as the SNMPv1/SNMPv2t message format. The only difference is, that the last nine bytes of the community string encoded have special meaning. This old message with slightly different community string (but the encoding stays the same!) we will call SNMPv2a message, and the procedure - SNMPv2a. Community name is what community string is in SNMPv1/SNMPv2t. In SNMPv2a community name doesn't need to be kept secret, because it's the password, associated with it, that needs to be secret, and it never crosses the network. Thus, the encoded community string will look like: TAG: OCTET STRING LENGTH: length of the community name plus 9 DATE: 0 Digest is generated using MD5 with prepended and appended key, as described in Section 3. That's all! 2.1 Protection against Message Replay Although protection of message replay is not a specific goal of this document, the fact that a digest over the Message content is used, gives us an opportunity to protect : (somewhat) against such attacks. So to try and deal with response replays, it is recommended to not generate request-id from zero, but initialize it with random value,then increment it as appropriate with outgoing requests, and either preserve it across reboots, or reinitialize with random value again when the agent is brought up again. The above protection does not work for sending requests. The most important threat with replay is the replay of a SET request. In order to protect against that, for SNMPv2t one can always include a SET for a variable that has a syntax of TestAndIncr (see [2]). Expires January 1996 [Page 2] " Internet-Draft SNMPv2a August 1995 3 Elements of Procedure This section describes the procedures followed by an SNMPv2a entity in processing SNMPv2a messages. 3.1 Generating a Request, a Response, or a Notification 1. Information concerning the community-Name is extracted from the LCD. The transport domain and transport address to which the operation is to be sent is determined. 2. The operation is serialized (i.e., encoded) according to the conventions of [5] or [6] into a PDUs value. 3. An SNMPv2a message is constructed using the ASN.1 Message syntax with the version component set to the value 1. Nine zero bytes are appended to the community name prior to serialization. 4. The constructed Message value is serialized (i.e., encoded) according to the conventions of [5] for SNMPv1, or [6] for SNMPv2t. 5. The key, derived from the community password is prepended to the message, then appended to it. 6. MD5 is run over the resulting octet string (as in SNMPv2, see [3] and other SNMPv2-related drafts). 7. First eight bytes of resulting MD5 digest are placed after the first zero byte which follows community string (so that there is one zero byte between the community string and eight bytes of message digest). Why only eight bytes - see [8]. 8. The resulting serialized Message value is transmitted to the determined transport address. 3.2 Processing a Received Communication Everything's exactly as in SNMPv1, except for the following: 1. If the entire community string is found in the local database, the message is believed to be SNMPv1/SNMPv2t and is processed accordingly. Otherwise - proceed to (2). Expires January 1996 [Page 3] " Internet-Draft SNMPv2a August 1995 2. If community string without the last nine bytes is found in the local database, and the first byte of the last nine bytes is zero, the last eight bytes are stored as a received digest and their place in the message is zeroed. 3. If there's no key associated with this community, no further authentication is performed and the received digest is discarded. It is recommended to inialize authentication failure procedure in this case. 4. If the key is found, it's prepended and appended to the message (as in Section 3.1 and in [7]), MD5 is run over it, and the first eight bytes of the resulting digest are compared with the received digest. If they match, the message is authentic, otherwise it's not and authentication failure procedure is initiated. 5. At this point the message is believed authentic and is processed according to it's format (SNMPv1 or SNMPv2t). 4 Security Considerations The method described guarantees authentication (ensures the message came from a member of given community) and message integrity. In addition, it accomplishes the goal of this proposal - to stop sending passwords in clear. This method doesn't protect against message replays, which was not a goal of this intermediate step, aimed at providing temporary fix to the worst existing problem in SNMPv1 security. Usage of MD5 in this method slightly differs from "traditional" SNMP approach. This is due to the latest results in cryptanalysis of keyed hash functions used for authentication (see [7], [8]). For even though this is meant to be a temporary fix, we want it to be secure. 5 References [1] Jeffrey D. Case, Keith McCloghrie, Marshall T. Rose and Keith Steven Waldbusser, SMI formation for version 2 of the Simple Network Management Protocol (SNMPv2), SNMP Research Inc, Cisco Systems Inc, Dover Beach Consulting Inc, Carnegie Mellon University, draft-kzm-snmpv2-smi-alt-00.txt, June 1995. Expires January 1996 [Page 4] " Internet-Draft SNMPv2a August 1995 [2] Jeffrey D. Case, Keith McCloghrie, Marshall T. Rose and Keith Steven Waldbusser, Textual Conventions for version 2 of the Simple Network Management Protocol (SNMPv2), SNMP Research Inc, Cisco Systems Inc, Dover Beach Consulting Inc, Carnegie Mellon University, draft-kzm-snmpv2-tc-alt-00.txt, June 1995. [3] Jeffrey D. Case, Keith McCloghrie, Marshall T. Rose and Keith Steven Waldbusser, Protocol Operations for version 2 of the Simple Network Management Protocol (SNMPv2), SNMP Research Inc, Cisco Systems Inc, Dover Beach Consulting Inc, Carnegie Mellon University, draft-kzm-snmpv2-proto-alt-00.txt, June 1995. [4] James M. Galvin, Keith McCloghrie, Marshall T. Rose and Glen Waters, User Based Security Model for version 2 of the Simple Network Management Protocol (SNMPv2), Trusted Information Systems, Cisco Systemc Inc, Dover Beach Consulting Inc, Bell Northern Research, draft-kzm-snmpv2-sec-alt-00.txt, June 1995. [5] Jeffrey D. Case, Mark Fedor, Martin Lee Schoffstall and James R. Davin, Simple Network Management Protocol (SNMP), SNMP Research, Performance Systems International, MIT Laboratory for Computer Science, RFC 1157, May 1990. [6] Bert Wijnen, Uri Blumenthal, Nguyen. C. Hien, Bob Natale SNMPv2t Simple Network Management Protocol Version 2 with Transitional Authentication. July 1995, Internet Draft. [7] Hugo Krawczyk, Keyed MD5 for Message Authentication, June 1995, Internet Draft. [8] Bart Preenel and Paul van Oorschot, MDx-MAC and Building Fast MACs from Hash Functions, to appear in Proceedings of CRYPTO-95, Springer-Verlag, LNCS, August 1995. Expires January 1996 [Page 5] " Internet-Draft SNMPv2a August 1995 6 Authors' Addresses Uri Blumenthal IBM T.J.Watson Research Center P. O. Box 218 Yorktown Heights, NY 10598 USA Phone: +1-914-945-1267 E-mail: uri@watson.ibm.com Nguyen C. Hien IBM T.J.Watson Research Center P. O. Box 218 Yorktown Heights, NY 10598 USA Phone: +1-914-945-2806 E-mail: hien@watson.ibm.com Bob Natale ACE*COMM 209 Perry Pkwy Gaitherburg MD 20877 USA Fax: +1-301-921-0434 Phone: +1-301-258-9850 E-mail: natale@acec.com Bert Wijnen IBM International Operations Watsonweg 2 1423 ND Uithoorn The Netherlands Phone: +31-2975-53316 Fax: +31-2975-62468 E-mail: wijnen@vnet.ibm.com Expires January 1996 [Page 6] "