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]
"