Internet DRAFT - draft-blumenthal-snmpv2a-integrity
draft-blumenthal-snmpv2a-integrity
HTTP/1.1 200 OK
Date: Mon, 08 Apr 2002 22:54:35 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Wed, 09 Aug 1995 22:00:00 GMT
ETag: "2e7e16-324d-30292fe0"
Accept-Ranges: bytes
Content-Length: 12877
Connection: close
Content-Type: text/plain
Internet Draft SNMPv2a August 1995
SNMPv2a
Simple Authentication/Integrity for
Community-based SNMP messages
<draft-blumenthal-snmpv2a-integrity-00.txt>
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: <community name> 0 <eight bytes of digest>
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]
"