New Auth draft (as promised :-)

[[e-mail]]

Hi,
	First - sorry about the delay, but there were some last-time
      	updates Friday evening flying between USA and Netherlands,
	and then I wake up pretty late in Mondays (:-).

	Anyways, here's the proposal to authenticate community-based
	messages.


Internet Draft                  SNMPv1a                     August 1995


                                SNMPv1a
                   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                  SNMPv1a                     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, 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                  SNMPv1a                     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 SCM draft (see "password2key()" routine).

     The new message format is exactly the same as the old SNMPv1
     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 SNMPv1a
     message, and the procedure - SNMPv1a.

     Community name is what community string is in SNMPv1. In
     SNMPv1a 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 corsses the network.

     Thus, the encoded community string will look like:

      TAG:    OCTET STRING
      LENGTH: length of the community name plus 9
      DATE:   <community string> 0 <eight bytes of digest>

     Digest is generated using MD5 with padded prepended and appended
     key, as described in Section 3.


     That's all!

     2.1. Community names

     To grossly simplify the life of numan Network Managers and of
     SNMP implementors, it's recommended to restrict the community
     names in SNMPv1a to non-zero printable strings. Pending SNMPv2
     WG approval, "it's recommended" will be substituted by "must".


     2.2  One more recommendation

     In order to deal with response replays, it would be useful to
     not generate request-id from zero, but treat it as TestAndIncr
     in SNMPv2 documents. I.e. initialize it with random value,then
     increment it one by one and either preserve it accross reboots,
     or reinitialize with random value again.

     Of course, for sensitive Set operations and such, TestAndIncr
     or SNMPv2t and SNMPv2 will protect against request replay as
     well (i.e. having a TestAndIncr object associated with the
     MIB group or MIB object one writes to).






















Expires January 1996                                           [Page 2]
"
Internet-Draft                  SNMPv1a                     August 1995


     3  Elements of Procedure

     This section describes the procedures followed by an SNMPv1a entity
     in processing SNMPv1a messages.


     3.1  Generating a Request, a Response, or a Notification

     1.  Information concerning the communityName 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 [10] or [11] into a PDUs value.

     3.  An SNMPv1a message is constructed using the ASN.1 Message
         syntax with the version component set to the value 1, but
         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 [10] for SNMPv1, or [11]
         for SNMPv1a.

     5.  The key, derived from the community password is prepended to
         the message and padded to the length of 512 bits with one
         1 bit and 383 zero bits, then appended to it (appended
         key isn't padded). For reference see [12].

     6.  MD5 is run over the resulting octet string (as in SNMPv2, see
         [4], [5] 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 [13].

     5.  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 and is
        processed accordingly. Otherwise - proceed to (2).

     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. As a note, if an
        extra restriction is applied to community names, forcing them
        to be printable strings, as most of the community strings in
        the real world are today - the dealing with them can be grossly
        simplified.

     3. If there's no key associated with this community, no further
        authentication is performed and the received digest is discarded.

     4. If the key is found, it's prepended-padded and appended to the
        message (as in Section 3.1 and in [12], 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.



Expires January 1996                                          [Page 3]
"
Internet-Draft                  SNMPv1a                     August 1995


     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 completely 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 differs from "traditional" SNMP approach.
     This is due to the latest results in cryptanalysis of keyed hash
     functions used for authentication (see [12], [13], [14], [15], 16]).


     5  References

     [1]  Jeffrey  D. Case, Keith McCloghrie, Marshall T. Rose and Keith
          Steven Waldbusser, Introduction to SNMPv2, SNMP Research  Inc,
          Cisco Systems Inc, Dover Beach Consulting Inc, Carnegie Mellon
          University, draft-kzm-snmpv2-intro-alt-00.txt, June 1995.

     [2]  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.

     [3]  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.

     [4]  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.

     [5]  Jeffrey  D. Case, Keith McCloghrie, Marshall T. Rose and Keith
          Steven Waldbusser, Transport Mappings 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-tm-alt-00.txt, June 1995.







Expires January 1996                                          [Page 4]
"
Internet-Draft                  SNMPv1a                     August 1995


     [6]  Jeffrey  D. Case, Keith McCloghrie, Marshall T. Rose and Keith
          Steven Waldbusser, Management Information Base 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-mib-alt-00.txt,
          June 1995.

     [7]  Jeffrey  D. Case, Keith McCloghrie, Marshall T. Rose and Keith
          Steven Waldbusser, Conformance Statements 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-conf-alt-00.txt,   June
          1995.

     [8]  Jeffrey  D. Case, Keith McCloghrie, Marshall T. Rose and Keith
          Steven Waldbusser, Coexistence between version 1 and version 2
          of the Internet-standard Network  Management  Framework,  SNMP
          Research  Inc,  Cisco Systems Inc, Dover Beach Consulting Inc,
          Carnegie Mellon University,  draft-kzm-snmpv2-coex-alt-00.txt,
          June 1995.

     [9]  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.

     [10] 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.

     [11] Bert Wijnen, Uri Blumenthal, Nguyen. C. Hien, Bob Natale
          SNMPv1a Simple Network Management Protocol Version 2 with
          Transitional Authentication. July 1995, Internet Draft.

     [12] Hugo Krawczyk, Keyed MD5 for Message Authentication,
          June 1995, Internet Draft.

     [13] Bart Preenel and Paul van Oorschot, MDx-MAC and Buinding Fast
          MACs from Hash Functions,
          to appear in Proceedings of CRYPTO-95, Springer-Verlag, LNCS,
          August 1995.

     [14] Paul van Oorschot, personal communications.

     [15] M. Bellare, R. Canetti, and H. Krawczyk, Keing MD5 - Message
          Authentication via Iterated Pseudo-randomness", manuscript.

     [16] B. Kaliski and M. Robshaw, Message Authentication with MD5,
          RSA Labs' CryptoBytes, Vol. 1 No. 1, Spring 1995.


















Expires January 1996                                          [Page 5]
"
Internet-Draft                  SNMPv1a                     August 1995


     6  Authors' Addresses

       Uri Blumenthal
       IBM T.J.Watson Research Center
       P. O. Box 218
       Yorktown Heights, NY 10598
       USA

       Phone: [phone]
       E-mail: [e-mail]



       Nguyen C. Hien
       IBM T.J.Watson Research Center
       P. O. Box 218
       Yorktown Heights, NY 10598
       USA

       Phone: [phone]
       E-mail: [e-mail]



       Bob Natale
       ACE*COMM
       209 Perry Pkwy
       Gaitherburg MD 20877
       USA

       Fax:   [phone]
       Phone: [phone]
       E-mail: [e-mail]



       Bert Wijnen
       IBM International Operations
       Watsonweg 2
       1423 ND Uithoorn
       The Netherlands

       Phone: [phone]
       Fax:   [phone]
       E-mail: [e-mail]




Expires January 1996                                          [Page 6]
"
--
Regards,
Uri         [e-mail]      N2RIU
-=-=-=-=-=-
<Disclamer>