[Search] [txt|pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 01                                                            
INTERNET-DRAFT
Expires in six months


                   Security Encapsulation of SNMP
                   -------- ------------- -- ----
                <draft-alten-snmpv2-sec-encap-01.txt>

                         Alexander. I. Alten

                          November 6, 1995



Abstract

   This document proposes a practical solution for the security
   of SNMP packets.  It allows any SNMP packet to be transmitted
   with strong authentication information.  Packets can be optionally
   encrypted for full security.  This encapsulation protocol is
   designed to allow implementations to meet USA export requirements.
   It supports SNMPv1 [2], SNMPv2 [11], and will support any future
   SNMP protocol enhancements.  It can be added transparently so that
   investment in existing SNMP protocol stacks can be preserved.

   Administration is kept simple, in particular public key management
   and time synchronization.  This encapsulation scales well to large
   numbers of managers and agents.  It is designed to facilitate
   implementation and to minimize troubleshooting with extensive
   error reporting mechanisms.


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.''

     To learn the current status of any Internet-Draft, please check
     the ``1id-abstracts.txt'' listing contained in the Internet-
     Drafts Shadow Directories on ftp.is.co.za (Africa),
     nic.nordu.net (Europe), munnari.oz.au (Pacific Rim),
     ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast).


1. Introduction

   When devices, containing sensitive or critical data, are attached to
   a computer network the possibility arises in which an unauthorized
   person may tamper, alter, review or destroy that data.  Using SNMP to
   configure and manage the device is a powerful and useful mechanism.
   It is a real convenience and advantage to be able administer any
   device across a computer network.  However this same technology can
   also allow a stranger to damage or manipulate the device without the
   owner's permission.  This person could be malicious, or simply
   ignorant of the damage he is causing.

   In the electronic world of computer networks, encryption technology
   provides the only real solution of preventing unauthorized access
   to the device, while at the same time allowing authorized people to
   access it from their desks anywhere in the world.

   Most commercial software applications are using the SNMP version 1
   (SNMPv1) [1, 2, 3] network management protocol to allow remote
   administration of a device.  SNMPv1 is usually chosen because the
   technology is proven and there are many available and robust
   commercial implementations.  SNMPv1 is a transaction protocol with
   a pair of read requests, called Get and Get Next, and a write request,
   called a Set.  In general the most critical transaction request is
   the Set since it can do serious damage to the data inside a device.
   A later version of the protocol, SNMP version 2 (SNMPv2) [9, 10, 11],
   adds some new read requests; Get Bulk and Inform.  To prevent an
   unauthorized SNMP transaction we must use encryption technology.

   This document describes an encapsulation protocol for SNMP which
   provides authentication and data privacy capabilities.  Existing
   implementations of SNMP can be easily supported, along with any
   future enhancements to SNMP.  This encapsulation is orthogonal to
   any new SNMP PDU types or mechanisms to control MIB access.  It is
   designed to be easy to implement with a modest administrative
   overhead.


2. Technical Overview of the Protocol

   This protocol encapsulates any SNMP protocol.  Using a hybrid
   encryption approach, it provides either authentication-only or
   secure SNMP transactions.  It acts like a preprocessor to a SNMP
   protocol, providing its own mechanisms for reporting errors, such
   as an authentication failure.  This document specifies the
   encapsulation header format which contains a version identifier, an
   opaque value, an error value, a time stamp, and an encrypted hash.
   The SNMP packet is appended, either as plain data or as encrypted
   data.

   The signed and encrypted hash provides the most critical part of the
   authentication of the SNMP packet.  It binds the entire encapsulation
   and SNMP packet together and ensures that it cannot be tampered with
   on its journey from the sender to the receiver.  It is signed and
   encrypted using asymmetric (public key) encryption technology, such
   as the RSA algorithm [15].  First the sender signs the hash with
   his private key, then he encrypts it with the receiver's public key.
   This ensures that only the correct receiver can recover the hash
   from the encapsulation, by decrypting first with his private key and
   then verifying it with the sender's public key, authenticating the
   sender.  This model of authentication is simple and robust.

   The SNMP packet itself can be kept in its original ASN.1 encoding
   or it can be encrypted with a symmetric encryption algorithm, such
   as DES [13, 16, 17, 19] or RC4 [27].  This type of algorithm is
   chosen because it is much faster than an asymmetric one.  For
   example DES is roughly 1000 times faster than RSA.  Asymmetric
   algorithms are chosen because the public portion of the keys can be
   easily distributed over a network without compromising data
   encrypted by the private portion.  Since these algorithms are very
   slow, only small pieces of data are encrypted with them, like
   one-way hashes, timestamps and symmetric keys.  A fully secure SNMP
   packet would be authenticated and encrypted.

   The agent MIB extensions are primarily to facilitate the exchange
   of public keys.  A table is specified where managers can deposit
   their public keys.  Also managers can retrieve the agent's public
   key.  The agent's timer value can be retrieved.  Public key
   distribution  and time synchronization issues are more fully
   discussed below.

   This protocol has been designed with export licensing in mind.  For
   example an implementor may choose to do only authentication, the
   SNMP packet is never encrypted.  This would be the easiest
   implementation to license.  If encryption of the SNMP packet is
   required, then the implementor may choose to use RC2 or RC4 with
   40 bit keys.  This would qualify for an export license.

   This protocol has been designed to facilitate implementation
   and in-the-field troubleshooting.  Encryption technology can make
   SNMP protocol transactions very difficult to analyze by obscuring
   encodings and other critical data.  As much data as possible is
   unencrypted, such as the time stamp and the error status, to assist
   the implementor or the administrator when they are trying to fix a
   problem.  By providing an encapsulation to existing SNMP protocol
   machinery, which has been in use and field proven, problems can be
   isolated and solved more easily.


3. Comparison With SNMPv2 Security

   Both SNMPv2 and this proposal use encapsulation to provide
   authentication and privacy of SNMP packets.  However this proposal
   diverges from SNMPv2 in how authentication is performed.  SNMPv2,
   after stripping away the details, uses a symmetric key algorithm,
   DES, to provide authentication.  This proposal uses an asymmetric
   (public key) algorithm, such as RSA.  This choice significantly
   simplifies the exchange and maintenance of authentication
   information.  SNMPv2 relies on a mechanism of preconfiguring parties
   on each agent and manager which wish to communicate, e.g. setting up
   the DES key for each pair.  DES keys cannot be freely sent across
   the network, they must be given out either by hand or by some other
   secure mechanism.  In contrast, this proposal only requires that the
   agent collect, possibly remotely across the network, public keys of
   any managers that it will allow to communicate with it.  Managers
   simply get the agent's public key when they wish to communicate with
   it.  SNMPv2 becomes difficult to administer as the numbers of agents
   and managers wishing to communicate increases, an exponential
   explosion of DES keys must be created and distributed.  For this
   proposal the number of public keys remains equal to the total number
   of agents and managers.  In addition, distribution might only occur
   when a manager and agent actually need to communicate.

   For software which encrypts user data it is difficult to obtain
   a US export license and many countries, notably France, will not
   allow it to be used by their citizens without severe restrictions.
   SNMPv2 uses DES to provide privacy for SNMP PDUs.  This proposal
   recommends RC2 or RC4 with 40 bit keys to provide privacy for SNMP
   packets, DES is an optional implementation.  It very difficult, if
   not impossible, to get a US export license for DES.  RC2 or RC4 with
   40 bit keys (or less) can be exported from the USA.

   Unlike SNMPv2 this proposal encapsulates an entire SNMP packet.
   This means that it can provide authentication and privacy to
   existing SNMPv1 packets as well as SNMPv2 packets.  This is
   important since there is a large installed base of SNMPv1 managers
   and agents.  The impact on SNMPv1 protocol stack machinery should be
   negligible allowing easy upgrades.  It should be able to support any
   future versions of SNMP.

   In summary this proposal provides three advantages over SNMPv2.
   1. Authentication (key distribution) is simpler and scales better.
   2. Export licenses can be obtained when encrypting data (privacy).
   3. Also provides security for SNMPv1.


4. What This Document Does Not Discuss

   This document does not discuss the following.

   1. Patent licenses or royalties.
   2. Encryption theory or background.
   3. Operating system security policy.
   4. Legal policy.
   5. Generating random numbers.
   6. Generating encryption keys.
   7. Encrypting and storing private asymmetric encryption keys.
   8. Encryption key escrow.


5. What This Document Does Discuss

   This document discusses SNMP authentication and privacy.

   1. USA export rules governing the export of encryption software.
   2. Network security policy (limited).
   3. Computing, signing and encrypting hashes.
   4. Synchronizing time.
   5. Encryption key identification.
   6. Distributing encryption keys.
   7. Certifying encryption keys (simple).
   8. Encrypting SNMP packets.


6. Encryption Nomenclature

   There are two types of encryption algorithms; asymmetric and
   symmetric.  Asymmetric algorithms use two keys, a public and a
   private key.  If one of the keys is used to encrypt data, then
   only the other key may decrypt the data.  If one of the keys is
   used to sign the data, then only the other key may verify the
   signature of the data.  For some algorithms, like RSA [15],
   these pair of operations use the exact same mathematical formula.
   I.e. signing and encrypting with the same key are identical
   operations, creating the same multiprecision integer result.  For
   other algorithms, like ElGamal [25], these are not the same
   mathematical formula.  I.e. signing and encrypting with the same key
   will create different multiprecision integer results.  The only
   asymmetric algorithms specified are RSA and ElGamal.

   Symmetric algorithms use only one key for both encryption and
   decryption of bulk data, such as an SNMP packet.  The only
   symmetric algorithms specified are; RC2, RC4 [27], DES [13, 16, 17,
   18], Triple DES [25], and IDEA [14].

   In summary, for authentication, an encrypted signature, we use the
   public and private keys.  While for privacy, an encrypted SNMP
   packet, we use a symmetric key.  Note that full SNMP security
   requires both authentication and privacy.


7. Security Nomenclature

   Security is usually defined as all of the following.

   1. Authentication, integrity
   2. Privacy, secrecy, confidential
   3. Availability, denial of service
   4. Access control, authorization
   5. Non-repudiation

   In the context of this document they are defined as follows.

   1. Authentication or integrity means that sender and the receiver
      are known to each other, via asymmetric encryption, such as RSA,
      and are associated with this encapsulated packet.

   2. Privacy, secrecy or confidential means that the data payload of
      this encapsulation packet, e.g. the SNMP packet, is encrypted
      with a symmetric encryption algorithm, such as DES.

   3. Availability means that the agent can ensure that it is still
      functioning properly after an illegal attempt to modify its
      MIB content.  Denial of service means a valid manager could be
      denied access to an agent.  Unfortunately this document cannot
      propose any solution for this attack.

   4. Access control or authorization means that a manager may only
      have access to portions of an agent's MIB or may only be able to
      perform limited SNMP operations.  This document does not describe
      this.  The underlying SNMP protocol inside the encapsulation
      supports this.

   5. Non-repudiation means that a manager cannot deny they performed
      an operation on the agent.  This document provides the foundation
      mechanism for this (authentication), but does not describe how
      to do it.


8. Requirements for Authenticated SNMP Packets

   1. To prevent an unauthorized manager from initiating a destructive
      operation on an agent e.g. a malicious Set request.

   2. To allow an agent to accurately distinguish between management
      stations or individuals.  This will allow an agent to tailor
      access rights to portions of a MIB.

   3. To meet USA export requirements for software containing
      encryption which is used only for authentication purposes.


9. Requirements for Private SNMP Packets

   1. To prevent sensitive information from being read by unauthorized
      recipients.

   2. To allow the implementer to meet USA export requirements for
      software containing encryption which is used for data
      encryption purposes.


10. Secure Encapsulation Header

   The secure encapsulation header for an SNMP packet contains
   information to support the protocol operations and to provide
   authentication of the sender.  The SNMP packet is appended to it
   either in plain or encrypted form.

   The version field indicates the protocol described in this
   document.  The specified value is two.

   The opaqueValue field allows the manager to match requests
   with agent responses.  This is needed in particular when the
   SNMP packet is encrypted, shrouding the request identifer.
   It can be any value, except zero.  A simple count is recommended.
   Traps set this to zero.

   The errorStatus field is used by the agent to report any
   encapsulation processing errors.

      Error Name                Description
      -----------------------   ---------------------------------------
      noError                   Request encapsulation was correct.
                                Traps always use this code.

      generalError              An unspecified error occured.

      badSignature              The manager's public key is not
                                registered with the agent.  Or the
                                signature is malformed; the one-way
                                hash is invalid or the decryption
                                failed to produce the correct
                                signature. This means that the
                                signature verification failed.

      unsupportedPublicKey      This type of public key is not
                                supported.  RSA is required for all
                                implementations.   This means that the
                                signature verification failed.

      unsupportedHash           This one-way hash algorithm is not
                                supported.

      badTimeStamp              The agent has an accurate clock and
                                requires a valid time.  The manager's
                                time stamp is too old or incorrect.

      badSymmetricKey           The symmetric key is malformed.  This
                                means the SNMP packet could not be
                                recovered from the encrypted data.

      tooLargeSymmetricKey      The agent does not allow too large a
                                symmetric key.  This is to allow
                                encryption of the SNMP packet
                                conforming to export restrictions.

      unsupportedSymmetricKey   This symmetric key is not supported.
                                If encryption of the SNMP packet is
                                supported then RC2 and RC4, up to 40
                                bit key sizes, must be implemented.

      unsupportedSymmetricMode  This symmetric mode is not supported.
                                If encryption of the SNMP packet is
                                supported then ECB mode must be
                                supported.  Other modes are optional.

      noEncryptedDataAllowed    The agent does not allow encrypted
                                SNMP packets.

      badEncryptedData          After decryption the data could not
                                be interpreted as a valid SNMP packet.

   The timeStamp field is to reduce the probability of an authentic
   packet being replayed.  It represents the number of seconds since
   midnight January 1, 1900 GMT.  The manager fills this out with
   a time value.  The agent checks to see if this time is what it
   expects i.e. the timestamp falls within a certain delay period.
   This interval is not specified by this document.  It is recommended
   that it be configurable value on the agent.  Some agents may not
   have a reliable timer available.  In this case the field can be
   ignored by the agent.  The return value should be an accurate copy
   of the agent's timer when the response encapsulation is created.
   If no reliable timer is available, then this field should be set to
   zero by the agent.

   The encryptedSignature is the computed one-way hash of the entire
   encapsulation, not including this field, and the appended SNMP
   packet (plain or encrypted).  It is signed first by the sender's
   private key and then encrypted by the receiver's public key.  This
   is called an encrypted signature.  If the SNMP packet is encrypted
   then the symmetric key is included with the hash before the
   signature is created.

   The final field is the SNMP packet, either plain or symmetric
   algorithm encrypted.


   -- Authenticated or secure encapsulation of SNMP message.

   Encapsulation-Message ::=
           SEQUENCE {
               version          -- Version 3 for this RFC.
                   INTEGER {
                       version-3(2)
                   },

               opaqueValue      -- Manager sets this, agent must
                   INTEGER,     -- echo it back.  Traps use 0.

               errorStatus      -- Response from agent, 0 otherwise.
                   INTEGER {
                       noError(0),
                       generalError(1),
                       badSignature(2),
                       unsupportedPublicKey(3),
                       unsupportedHash(4),
                       badTimeStamp(5),
                       badSymmetricKey(6),
                       tooLargeSymmetricKey(7),
                       unsupportedSymmetricKey(8),
                       unsupportedSymmetricMode(9),
                       noEncryptedDataAllowed(10),
                       badEncryptedData(11)
                   },

               timeStamp       -- Synchronized time value.
                   INTEGER,    -- Agent returns current value.

               encryptedSignature -- May contain symmetric key.
                   EncryptedSignature,

               CHOICE {
                  data             -- SNMPv1, SNMPv2, etc., packet
                     ANY,
                  encryptedData    -- The encrypted SNMP packet.
                     EncryptedData
               }

           }


11. Authentication-only SNMP

   Initially the sender, either a manager or agent, generates a public
   and private key pair.  The manager then registers its public key
   with the agent.  This registration can be done using SNMP or by
   another mechanism.  The manager can retrieve the agent's public key
   using SNMP or by another mechanism.  Once this exchange has taken
   place then authenticated SNMP packets can be emitted and received.


   Authenticated Requests
   ----------------------

   When the manager wishes to send an authenticated SNMP request packet
   the following steps need to be followed.

   1. Retrieve a current time from the agent or use an internal timer
      if the manager is confident that it is synchronized with the
      agent.

   2. Construct the encapsulation header and append the SNMP packet.
      Set the encrypted signature and error values to zero.  The opaque
      value is set to some useful value, typically a unique count.

   3. Compute a hash of the encapsulation header (see below) and
      the SNMP packet.  Everything must already be in its ASN.1
      encoded form, including the current time stamp.

   4. Sign the hash value with the manager's private key, then encrypt
      the resulting signature with the agent's public key.  This not
      only authenticates the manager to the agent, but prevents a replay
      attack against another agent which has also registered this
      manager's public key.

   When the agent receives this authenticated SNMP request packet, the
   following steps are followed.

   1. Decrypt the encrypted signature using the agent's private key,
      then verify the signature with the manager's public key.  If the
      manager's public key is not registered then issue an authenticated
      response indicating that a bad public key was encountered.  If
      the decryption or verification fails then send an appropriate
      error response back to the sender.

   2. Compute a hash of the encapsulation header (see below) and the
      appended SNMP packet.  The encrypted signature field is zeroed
      during the calculation.

   3. Compare the computed hash and the received hash.  If they are
      equal then proceed.  Otherwise send an authenticated response
      indicating a bad signature was encountered.

   4. Check the time stamp.  The agent should allow for network delays
      time skews.  If the time stamp is within an acceptable delay
      period (this can be a configurable value on the agent) then
      proceed.  Otherwise send an authenticated response indicating
      a bad time stamp was encountered.

   Note: If any errors occur, such as a bad public key, then the
      agent constructs a new encapsulation header and sends it and the
      data (the SNMP packet) back to the manager.


   Authenticated Responses
   -----------------------

   When the agent issues an authenticated SNMP response packet, the
   following steps are followed.

   1. Use an internal timer (secureSystemTime) to set the time stamp.
      This can be used to synchronize the manager's timer.

   2. Construct the encapsulation header and append the SNMP packet.
      The encrypted signature and error values are set to zero.  The
      opaque value is set to some useful value, typically a unique
      count.  Copy the opaque value from the original request
      encapsulation header to this one.

   3. Compute a hash of the encapsulation header (see below) and
      the SNMP packet.  Everything must already be in its ASN.1
      encoded form, including the current time stamp.

   4. Sign the hash value with the agent's private key, then encrypt it
      with the manager's public key.  This not only authenticates
      the agent to the manager, but prevents a replay attack against
      another manager.

   When the manager receives this authenticated SNMP response packet, the
   following steps are followed.

   1. Decrypt the encrypted signature using the manager's private key,
      then verify it with the agent's public key.  If the decryption or
      verification fails then ignore the packet and optionally report
      the error back up the protocol stack.

   2. Compute a hash of the encapsulation header (see below) and the
      SNMP packet.  The encrypted signature field is zeroed during
      the calculation.

   3. Compare the computed hash and the received hash.  If they are
      equal then proceed.  If not then ignore the packet and optionally
      report the error back up the protocol stack.

   4. The time stamp can be used to resynchronize the manager's timer.

   5. Use the opaque value to demultiplex the response, e.g. to match
      it with a pending request in the protocol machinery.


   Authenticated Traps
   -------------------

   When the agent issues an authenticated SNMP trap packet, the
   following steps are followed.

   1. Use an internal timer (authSystemTime) to set the time stamp.
      This can be used to synchronize the manager's timer.

   2. Construct the encapsulation header and appended SNMP trap packet.
      The encrypted signature, error and opaque values are set to zero.

   3. Compute a hash of the encapsulation header (see below) and
      the SNMP packet.  Everything must already be in its ASN.1
      encoded form, including the current time stamp.

   4. Sign the hash value with the agent's private key, then encrypt it
      with the manager's public key.  This not only authenticates the
      agent to the manager, but prevents a replay attack against
      another manager.

   When the manager receives this authenticated SNMP trap packet, the
   following steps are followed.

   1. Decrypt the encrypted signature using the manager's private key,
      then verify it with the agents's public key.  If the decryption
      or verification fails then ignore the packet and optionally
      report the error back up the protocol stack.

   2. Compute a hash of the encapsulation header (see below) and the
      SNMP packet.  The encrypted signature field is zeroed during
      the calculation.

   3. Compare the computed hash and the received hash.  If they are
      equal then proceed.  If not then ignore the packet and optionally
      report the error back up the protocol stack.

   4. The time stamp can be used to resynchronize the manager's timer.


                   Authenticated SNMP Transaction or Trap

                       +--------------------------+
                       |                          |
                       |      Encapsulation       |
                       |          Header          |
                       |         using an         |
                       |    Encrypted Signature   |
                       |                          |
   +-------------+     | +----------------------+ |     +------------+
   |             |     | |                      | |     |            |
   |    Sender   |     | |                      | |     |  Receiver  |
   |             |---->| |     SNMP Packet      | |---->|            |
   |(Private Key)|     | |                      | |     |(Public Key)|
   |             |     | |                      | |     |            |
   +-------------+     | +----------------------+ |     +------------+
                       +--------------------------+


12. Secure SNMP

   For full SNMP security, authentication information and the
   encryption of the encapsulated SNMP packet is required.  The
   preparation of the encapsulation header is identical to the
   authentication steps outlined above, except that the encrypted
   symmetric key field is now used and that the data, an SNMP packet,
   is encrypted using this symmetric key.  It is recommended that each
   pair of manager and agent use a different symmetric key during
   their secure communications.  For maximum security, each packet
   sent should use a different symmetric key for encrypting the
   SNMP packet.  If the software is to be exported outside the USA
   then it is recommended to use either the RC2 or RC4 algorithms
   with a maximum of 40 bit keys.


   Secure Requests
   ---------------

   When the manager wishes to send a secure SNMP request packet the
   following steps need to be followed.

   1. Retrieve a current time from the agent or use an internal timer
      if the manager is confident that it is synchronized with the
      agent.

   2. Using the symmetric key encrypt the SNMP packet.  ASN.1 encode
      the results as an OCTET STRING.  The symmetric key is generated,
      then signed by the manager's private key and then it is encrypted
      by the agent's public key, and finally ASN.1 encoded.  These two
      ASN.1 variables are then appended to the encapsulation header as
      a SEQUENCE.

   3. Construct the encapsulation header and append the SNMP packet.
      The encrypted signature and error values are set to zero, and
      ASN.1 encoded.  The opaque value is set to some useful value,
      typically a unique count.

   4. Compute a hash of the encapsulation header (see below) and
      the encrypted SNMP packet.  Everything must already be in its
      ASN.1 encoded form, including the time stamp.  The only exception
      is the asymmetric key encrypted signature field which is zeroed
      during the calculation.

   5. Sign the hash value with the manager's private key, then encrypt
      it with the agent's public key.  This not only authenticates
      the manager to the agent, but prevents a replay attack against
      another agent which has also registered this agent's public key.

   When the agent receives this secured SNMP request packet, the
   following steps are followed.

   1. Decrypt the encrypted signature using the agent's private key,
      then verify it with the manager's public key.  If the manager's
      public key is not registered then issue a secure response
      indicating that a bad public key was encountered.  This operation
      will also recover the symmetric key.

   2. Compute a hash of the encapsulation header (see below) and the
      SNMP packet.  The encrypted signature field is zeroed during
      the calculation.

   3. Compare the computed hash and the received hash.  If they are
      equal then proceed.  Otherwise send a secure response indicating
      a bad signature was encountered.

   4. Check the time stamp.  The agent should allow for network delays
      time skews.  If the time stamp is within an acceptable delay
      period (this can be a configurable value on the agent) then
      proceed.  Otherwise send a secure response indicating a bad time
      stamp was encountered.

   5. Using the symmetric key from step one ASN.1 decode and decrypt
      the SNMP packet.

   Note: If any errors occur, such as a bad signature, then the agent
      constructs a new encapsulation header and sends it and the
      encrypted data (the SNMP packet) back to the manager.


   Secure Responses
   ----------------

   When the agent issues a secure SNMP response packet, the following
   steps are followed.

   1. Use an internal timer (authSystemTime) to set the time stamp.
      This can be used to synchronize the manager's timer.

   2. Using the symmetric key encrypt the SNMP packet.  ASN.1 encode
      the results as an OCTET STRING.  The symmetric key is generated,
      then encrypted by the manager's private key and then the agent's
      public key, and finally ASN.1 encoded.  These two ASN.1 variables
      are then appended to the encapsulation header as a SEQUENCE.

   3. Construct the encapsulation header and append the SNMP packet.
      The encrypted signature value is set to zero.  Set the error
      status value.  Copy the opaque value from the original request
      encapsulation header to this one.

   4. Compute a hash of the encapsulation header (see below) and
      the encrypted SNMP packet.  Everything must already be in its
      ASN.1 encoded form, including the time stamp.

   5. Sign the hash value with the agent's private key, then encrypt it
      with the manager's public key.  This not only authenticates the
      agent to the manager, but prevents a replay attack against
      another manager.

   When the manager receives this secure SNMP response packet, the
   following steps are followed.

   1. Decrypt the encrypted signature using the manager's private key,
      then verify it with the agents's public key.  If the decryption
      fails then ignore the packet and optionally report the error back
      up the protocol stack.

   2. Compute a hash of the encapsulation header (see below) and the
      SNMP packet.  The encrypted signature field is zeroed during
      the calculation.

   3. Compare the computed hash and the received hash.  If they are
      equal then proceed.  If not then ignore the packet and optionally
      report the error back up the protocol stack.

   4. The time stamp can be used to resynchronize the manager's timer.

   5. Using the symmetric key from step one ASN.1 decode and decrypt
      the SNMP packet.

   6. Use the opaque value to demultiplex the response, e.g. to match
      it with a pending request in the protocol machinery.


   Secure Traps
   ------------

   When the agent issues a secure SNMP trap packet, the following steps
   are followed.

   1. Use an internal timer (authSystemTime) to set the time stamp.
      This can be used to synchronize the manager's timer.

   2. Construct the encapsulation header.  The encrypted signature,
      error, and opaque values are set to zero.  Since this is for
      authentication only the encrypted symmetric key is set to an
      ASN.1 NULL value.

   3. Compute a hash of the encapsulation header (see below) and
      the SNMP packet.  Everything must already be in its ASN.1
      encoded form, including the time stamp.  The only exception is
      the encrypted signature field which is zeroed during the
      calculation.

   4. Sign the hash value with the agent's private key, then encrypt it
      with the manager's public key.  This not only authenticates
      the agent to the manager, but prevents a replay attack against
      another manager.

   When the manager receives this authenticated SNMP trap packet, the
   following steps are followed.

   1. Decrypt the doubly encrypted hash, first using the manager's
      private key, then the agents's public key.  If the decryption
      fails then ignore the packet and optionally report the error back
      up the protocol stack.

   2. Compute a hash of the encapsulation header (see below) and the
      SNMP packet.  The encrypted signature field is zeroed during
      the calculation.

   3. Compare the computed hash and the received hash.  If they are
      equal then proceed.  If not then ignore the packet and optionally
      report the error back up the protocol stack.

   4. The time stamp can be used to resynchronize the manager's timer.

   5. Using the symmetric key from step one ASN.1 decode and decrypt
      the SNMP packet.



                     Secure SNMP Transaction or Trap

                       +--------------------------+
                       |                          |
                       |      Encapsulation       |
                       |          Header          |
                       |         using an         |
                       |    Encrypted Signature   |
                       |                          |
   +-------------+     | +----------------------+ |     +------------+
   |             |     | |                      | |     |            |
   |             |     | |      Encrypted       | |     |            |
   |   Sender    |     | |    Symmetric Key     | |     |  Receiver  |
   |             |     | |         and          | |     |            |
   |(Private Key)|---->| |      Encrypted       | |---->|(Public Key)|
   |             |     | |     SNMP Packet      | |     |            |
   |             |     | |                      | |     |            |
   +-------------+     | +----------------------+ |     +------------+
                       +--------------------------+



13. Time Stamp Format

   The timer (secureSystemTime) is maintained by the agent.  When a
   manager wishes to synchronize it's own copy of this timer then
   it can retrieve the time from the agent.  Whenever the manager
   sends a SNMP request it includes a copy of it's syncronized timer
   value.  Likewise the manager uses it's own timer when sending a
   response or trap.

   secureSystemTime OBJECT-TYPE
                  SYNTAX    Time
                  ACCESS    read-only
                  STATUS    optional
                  DESCRIPTION
                            "This is the Agent's system date and time
                             expressed as the number of seconds since
                             midnight January 1, 1900 GMT.  The manager
                             can retrieve this to synchronize its time
                             stamps.  A practical implementation will
                             allow a certain amount of clock skew when
                             comparing incoming timestamps with this
                             value.
                            "
                  ::= { secure 2 }


14. Hash Format

   This is the ASN.1 format of a hash.  Implicit values 0 to 3 are
   reserved for one-way hashes.

   HashMd5 ::= [0] IMPLICIT OCTET STRING (SIZE (16))

   HashSha ::= [1] IMPLICIT OCTET STRING (SIZE (20))

   Hash ::=
       CHOICE {
          hashMd5
             HashMd5,
          hashSha
             HashSha
       }

   The MD5 [6] and SHA [21] one-way hashes are the only ones defined.


15. Public Key Format

   This is the ASN.1 format of a public key [28].  When a public and
   private key are generated by a manager or agent, two additional
   pieces of information must be associated with this key pair.  A
   validity period and an identification number.  The validity period
   is used to age the key.  If a key is older than the validity period
   date then it is considered to be invalid.  Implicit values 4 to 7
   are reserved for public keys.

   PublicKeyRsa ::= [4] IMPLICIT SEQUENCE {
     validityPeriod
        INTEGER,
     modulus     -- n
        INTEGER,
     encryption  -- e
        INTEGER
   }

   The validityPeriod is in number of seconds since midnight January 1,
   1900 GMT (0 means forever).

   The modulus and exponent are multiprecision integers which together
   represent the public key.

   For RSA it is recommended that the modulus is at least 768 bits in
   length.

   PublicKeyElGamal ::= [5] IMPLICIT SEQUENCE {
     validityPeriod
        INTEGER,
     modulus     -- p
        INTEGER,
     constant    -- g
        INTEGER,
     resultant   -- y
        INTEGER
   }

   The validityPeriod is in number of seconds since midnight January 1,
   1900 GMT (0 means forever).

   The modulus, constant, and resultant, are multiprecision integers
   which together represent the public key.

   For ElGamal in DSS it is recommended that the modulus is 512 to 1024
   bits in length.

   PublicKey ::=
       CHOICE {
          publicKeyRsa
             PublicKeyRsa
       }

   The RSA [15] and ElGamal [25] algorithms are the only ones defined.


16. Private Key Signature Format

   This is the format of the private key signature format [14].
   For this document the signature data will consist of a calculated
   hash and possibly a symmetric key.  When data is encrypted, a
   unique identifier (keyIdentifier) is prepended to it.  This is a
   unique value associated with this public and private key pair.  This
   identifier is computed by taking a hash of a phase phrase or text,
   and using only the lower 8 octets.  While this increases the chance
   of a duplicate value, it should be sufficient for manager and agent
   communications.  Implicit values 8 to 11 are reserved for private
   key encrypted data.

   PrivateKeySignatureRsa ::= [8] IMPLICIT SEQUENCE {
     keyIdentifier
        OCTET STRING (SIZE(8)),
     encryptedData,
        OCTET STRING
   }

   PrivateKeySignatureElGamal ::= [9] IMPLICIT SEQUENCE {
     keyIdentifier
        OCTET STRING (SIZE(8)),
     encryptedData,
        OCTET STRING
   }

   PrivateKeySignatureData ::=
       CHOICE {
          privateKeySignatureRsa
             PrivateKeySignatureRsa,
          privateKeySignatureElGamal
             PrivateKeySignatureElGamal
       }

   The RSA [15] and ElGamal [25] algorithms are the only ones defined.


17. Public Key Encrypted Data Format

   This is the format of the public key encrypted data format [28].
   For this document the encrypted data will consist only of a private
   key signature.  When data is encrypted, a unique identifier
   (keyIdentifier) is prepended to it.  This is a unique value
   associated with this public and private key pair.  This identifier
   is computed by taking a hash of the RSA modulus and using only the
   lower 8 octets.  While this increases the chance of a duplicate
   value, it should be sufficient for manager and agent communications.
   Implicit values 12 to 15 are reserved for public key encrypted data.

   PublicKeyEncryptedDataRsa ::= [12] IMPLICIT SEQUENCE {
     keyIdentifier
        OCTET STRING (SIZE(8)),
     encryptedData,
        OCTET STRING
   }

   PublicKeyEncryptedDataElGamal ::= [13] IMPLICIT SEQUENCE {
     keyIdentifier
        OCTET STRING (SIZE(8)),
     encryptedData,
        OCTET STRING
   }

   PublicKeyEncryptedData ::=
       CHOICE {
          privateKeyEncryptedDataRsa
             PrivateKeyEncryptedDataRsa,
          privateKeyEncryptedDataElGamal
             PrivateKeyEncryptedDataElGamal
       }

   The RSA [15] and ElGamal [25] algorithms are the only ones defined.


18. Symmetric Key Format

   This is the ASN.1 format of a symmetric key.  Implicit values 16 to
   30 are reserved for symmetric keys.

   SymmetricKeyRc2 ::= [16] IMPLICIT SEQUENCE {
     numberOfBits    -- recommend 40 bits for export software
        INTEGER,
     key
        OCTET STRING
   }

   SymmetricKeyRc4 ::= [17] IMPLICIT SEQUENCE {
     numberOfBits    -- recommend 40 bits for export software
        INTEGER,
     key
        OCTET STRING
   }

   SymmetricKeyDes ::= [18] IMPLICIT SEQUENCE {
     modes           -- ECB, CBC, etc...
        INTEGER { ecb(0), cbc(1), cfb(2), ofb(3) },
     vector  -- Used by CBC, CFB and OFB modes
        OCTET STRING OPTIONAL (SIZE (8)),
     numBytes  -- Used by CFB and OFB modes
        INTEGER OPTIONAL { 1..7 },
     key
        OCTET STRING (SIZE (8))
   }

   SymmetricKeyTripleDes ::= [19] IMPLICIT SEQUENCE {
     modes,  -- normal or encrypt-decrypt-encrypt modes
        INTEGER { normal(0), ede2(1), ede3(2) },
     pad1,   -- random bits of half a block
        OCTET STRING (SIZE (4)) OPTIONAL,
     pad2,   -- random bits of half a block
        OCTET STRING (SIZE (4)) OPTIONAL,
     key1
        SymmetricKeyDes,
     key2
        SymmetricKeyDes,
     key3
        SymmetricKeyDes
   }

   SymmetricKeyIdea ::= [20] IMPLICIT SEQUENCE {
     modes           -- ECB, CBC, etc...
        INTEGER { ecb(0), cbc(1), cfb(2), ofb(3) },
     vector  -- Used by CBC, CFB and OFB modes
        OCTET STRING (SIZE(8)) OPTIONAL,
     numBytes  -- Used by CFB and OFB modes
        INTEGER OPTIONAL { 1..7 },
     key
        OCTET STRING (SIZE(16))
   }

   SymmetricKey ::=
       CHOICE {
          symmetricKeyRc2
             SymmetricKeyRc2,
          symmetricKeyRc4
             SymmetricKeyRc4,
          symmetricKeyDes
             SymmetricKeyDes,
          symmetricKeyTripleDes
             SymmetricKeyTripleDes,
          symmetricKeyIdea
             SymmetricKeyIdea
       }


19. Hash Only Encrypted Signature

   The one-way hash (message digest) [6, 21] computation is done after
   the assembly of an SNMP packet and the encapsulation header.  The
   encrypted signature field data octets are set to zero during the
   calculation.

   Step 1: One-way hash computation.

      H = Hash ( Encapsulation-Message including zeroed encrypted
                 signature field )

   Step 2: Sign the computed hash value with the sender's
           private key.

      S = Sign( H, Sender's Private Key )

   Step 3: Encrypt the signature with the receiver's public key.

      E = Encrypt( S, Receiver's PublicKey )


20. Hash And Symmetric Key Encrypted Signature

   The one-way hash (message digest) [6, 21] computation is done after
   the assembly of an SNMP packet and the encapsulation header.  The
   encrypted signature field data octets are set to zero during the
   calculation.

   Step 1: One-way hash computation.

      H = Hash ( Encapsulation-Message including zeroed encrypted
                 signature field )

   Step 2: Randomly generate a symmetric key.

   Step 3: Sign the computed hash value and the symmetric key with
           the sender's private key.

      S = Sign( H, Symmetric Key, Sender's Private Key )

   Step 4: Encrypt the signature with the receiver's public key.

      E = Encrypt( S, Receiver's PublicKey )


21. Encrypted Signature Format

   This is the format of the above encrypted signatures.

   EncryptedSignatureHash ::= {
      {
         hash
            Hash
      }
         PrivateKeySignature
   }
      PublicKeyEncryptedData

   EncryptedSignatureHashSymmetricKey ::= {
      {
      SEQUENCE {
            hash
               Hash,
            symmetricKey
               SymmetricKey
         }
      }
         PrivateKeySignature
   }
      PublicKeyEncryptedData

   EncryptedSignature ::= {
      CHOICE {
         encryptedSignatureHash
            EncryptedSignatureHash,
         encryptedSignatureHashSymmetricKey
            EncryptedSignatureHashSymmetricKey
      }
   }

22. Encrypted Data Format

   This is the encrypted SNMP packet.  It is encrypted using the
   key to a selected symmetric algorithm.  The symmetric key
   encoding will indicate which algorithm, mode, etc., to use.

   EncryptedData ::= [31] IMPLICIT {
        encryptedData,
                OCTET STRING
   }

   Note: Some algorithms require the data to be encrypted to be padded.
         For example, DES requires data to be in discrete eight (8)
         byte blocks.  The data may need to be padded out to the
         nearest eight byte boundary.

   Note: A DES key is 8 octets of data.  This consists of 56 bits of
         key, and 8 parity bits (one per octet).  The key is encoded
         as a series of 8 octets written in MSB-first order. The bits
         within the key are also encoded in MSB order.  For example,
         if the encryption key is: (B1,B2,...,B7,P1,B8,...,B14,P2,B15,
         ...,B49,P7,B50,...,B56,P8) where B1,B2,...,B56 are the key
         bits in MSB order, and P1,P2,...,P8 are the parity bits, the
         first octet of the key would be B1,B2,...,B7,P1 (with B1 as
         the MSbit).  [17]  (This text was derived from section 6.3.4
         in RFC 1510).


23. Distributing and Certifying Encryption Keys

   Only the public keys can be distributed by any means.  Private keys
   can never be distributed.  Symmetric keys can only be distributed
   when they are first encrypted by the sender's private key and then
   by the receiver's public key.  Symmetric keys typically have a
   restricted lifetime, only for one or a limited series of requests.

   An agent can receive and certify a manager's key in one of two ways,
   either by the administrator or across the network from a trusted
   manager.  A manager's public key can be deposited in a secure
   location on the agent by an administrator.  This should be done
   during the agent's initial installation. These keys are then
   certified by the person installing them.  Each key has a privilege
   level associated with it.  Note asymmetric key pairs are generated
   by each manager, only the public key is registered and certified on
   the agent, the private key is never distributed.  Once a manager's
   public key is registered, certified, and given a privilege level,
   then it in turn can use an authenticated SNMP Set to deposit other
   public keys.  These keys are implicitly certified by this manager
   an cannot have privilege levels better than his privilege level.
   The highest privilege level is zero, and declines with higher
   values.

   During the installation of the agent, the installer should generate
   its asymmetric key pair using proper key generation techniques
   [12, 24, 28].  The public key is then made available to managers via
   a MIB variable (securePublicKey).  The agent's public key is always
   available as a read-only variable (securePublicKey).  It is
   recommended that managers use an authenticated SNMP Get to retrieve
   the agent's public key.

   This document specifies an optional MIB table (securePublicKeyTable)
   which allows managers to write a public key.  Only manager's which
   have been previously registered can place a public key in this
   table, in essence they are certifying the new key.  The very first
   public key would have to be set up by a non-SNMP mechanism.  This
   could be done during the initial set up and configuration of the
   agent.


   The Agent Public Key
   --------------------

   securePublicKey OBJECT-TYPE
                  SYNTAX    PublicKey
                  ACCESS    read-only
                  STATUS    mandatory
                  DESCRIPTION
                            "The agent's public key.
                            "
                  ::= { secure 1 }


   Table of Certified Manager Public Keys
   --------------------------------------

   securePublicKeyTable OBJECT-TYPE
                  SYNTAX    SEQUENCE OF securePublicKeyEntry
                  ACCESS    not-accessible
                  STATUS    optional
                  ::= { secure 3 }

   securePublicKeyEntry OBJECT-TYPE
                  SYNTAX    SecurePublicKeyEntry
                  ACCESS    not-accessible
                  STATUS    mandatory
                  INDEX     { publicKeyIndex }
                  ::= { securePublicKeyTable 1 }

   AuthPublicKeyEntry ::= SEQUENCE {
                  securePublicKeyIndex
                          INTEGER,
                  securePublicKeyPrivilegeLevel
                          INTEGER,
                  securePublicKeyIdentifier,
                          OCTET STRING,
                  securePublicKey
                          PublicKey
                  }

   securePublicKeyIndex OBJECT-TYPE
                  SYNTAX    INTEGER
                  ACCESS    read-only
                  STATUS    mandatory
                  DESCRIPTION
                            "This is an index value."
                  ::= { securePublicKeyEntry 1 }

   securePublicKeyPrivilegeLevel OBJECT-TYPE
                  SYNTAX    INTEGER
                  ACCESS    read-write
                  STATUS    mandatory
                  DESCRIPTION
                            "This indicates what privileges are
                             allowed for the manager associated with
                             this public key.  This entry can only be
                             written using an authenticated Set request
                             which is accepted by the agent.  The highest
                             privilege level is zero, and the lower the
                             level the greater the integer value."
                  ::= { securePublicKeyEntry 2 }

   securePublicKeyIdentifier OBJECT-TYPE
                  SYNTAX    OCTET STRING (SIZE(8))
                  ACCESS    read-write
                  STATUS    mandatory
                  DESCRIPTION
                            "A unique identifier associated with the
                             public key.  It is generated by the
                             manager.  This helps associate the
                             incoming encrypted variables with the
                             correct public key to decrypt them.  This
                             entry can only be written using an
                             authenticated Set request which is
                             accepted by the agent."
                  ::= { securePublicKeyEntry 3 }

   securePublicKeyValue OBJECT-TYPE
                  SYNTAX    PublicKey
                  ACCESS    read-write
                  STATUS    mandatory
                  DESCRIPTION
                            "The manager's public key.  This is
                             used by the agent to authenticate the
                             manager.  This entry can only be written
                             using an authenticated Set request which
                             is accepted by the agent."
                  ::= { securePublicKeyEntry 4 }


24. Levels of Security

   Different implementations of managers and agents need varying grades
   of security.  An agent controlling a RAID device may need a higher
   level of security than one which tells you the configuration of a
   user's personal computer.  This document divides security into four
   levels.

   Level A = Authentication and strong privacy.
   Level B = Authentication and medium privacy.
   Level C = Authentication and weak privacy.
   Level D = Authentication only.

   A timestamp is an optional part of the authentication information.
   If it is included then it has enhanced the level and the letter has
   a plus sign appended as follows.

   Level A+ = Authentication (w/timestamp) and strong privacy.
   Level B+ = Authentication (w/timestamp) and medium privacy.
   Level C+ = Authentication (w/timestamp) and weak privacy.
   Level D+ = Authentication (w/timestamp) only.

   Note: Traps do not support enhanced levels.

   There are two possible authentication types, each has a one-way hash
   and uses asymmetric encryption.  They are numbered as follows.

   0 = MD5 and RSA (768 bit modulus or greater) algorithms
   1 = SHA and ElGamal algorithms

   There are two possible strong privacy types, each uses symmetric
   encryption.  They are numbered as follows.

   0 = Triple DES algorithm
   2 = IDEA algorithm

   There is one possible medium privacy type, which uses symmetric
   encryption.  It is numbered as follows.

   0 = DES algorithm

   There are two possible weak privacy types, each uses symmetric
   encryption.  They are numbered as follows.

   0 = RC2 algorithm (40 bit key or less)
   2 = RC4 algorithm (40 bit key or less)

   By adding the numbers for authentication and privacy a unique
   value will exactly indicate which algorithms are used for each
   level.

   A0 = MD5, RSA and Triple DES
   A1 = SHA, ElGamal and Triple DES
   A2 = MD5, RSA and IDEA
   A3 = SHA, ElGamal and IDEA
   B0 = MD5, RSA and DES
   B1 = SHA, ElGamal and DES
   C0 = MD5, RSA and RC2
   C1 = SHA, ElGamal and RC2
   C2 = MD5, RSA and RC4
   C3 = SHA, ElGamal and RC4
   D0 = MD5 and RSA
   D1 = SHA and ElGamal

   If the authentication uses a valid timestamp then the security
   levels are considered enhanced.  Traps do not support enhanced
   levels.

   A0+ = MD5, RSA, timestamp and Triple DES
   A1+ = SHA, ElGamal, timestamp and Triple DES
   A2+ = MD5, RSA, timestamp and IDEA
   A3+ = SHA, ElGamal, timestamp and IDEA
   B0+ = MD5, RSA, timestamp and DES
   B1+ = SHA, ElGamal, timestamp and DES
   C0+ = MD5, RSA, timestamp and RC2
   C1+ = SHA, ElGamal, timestamp and RC2
   C2+ = MD5, RSA, timestamp and RC4
   C3+ = SHA, ElGamal, timestamp and RC4
   D0+ = MD5, RSA and timestamp
   D1+ = SHA, ElGamal and timestamp


25. Implementation Requirements of Security Levels


   General
   -------

   The maximum level of security is always determined by the agent.
   A manager must send a series of encapsulated SNMP requests at
   different levels to determine which level will be accepted by the
   agent.  The agent will indicate with the error codes what levels it
   will accept.  If the manager cannot support the level required by
   the agent then it cannot communicate with the agent.  If an agent
   supports multiple levels then the manager may select which level it
   wishes to communicate on.  Some agents may require a higher level
   for some MIB variables and a lower level for others.  A manager
   should try to seek the highest level it and the agent mutually
   support together.

   All managers are required to support D0 and D0+.  If a manager can
   support a higher level then it must also be able to support enhanced
   version of that level.  For example if it can support B1 then it
   must also be prepared to support B1+.

   All agents must at least support one of the following levels; A0,
   A0+, A2, A2+, B0, B0+, C0, C0+, C2, C2+, D0, D0+.  They must support
   the securePublicKey variable.  They can optionally support the
   secureSystemTime variable and the securePublicKeyTable table.


   Authentication-only SNMP
   ------------------------

   The easiest USA export license is for authentication-only software.
   For this license it is required to implement the agent or manager
   with one of the following combinations.

   Manager: D0, or D0+, or D0 and D1, or D0+ and D1+.
   Agent:   D0, or D0+, or D0 and D1, or D0+ and D1+.


   Exportable Secure SNMP
   ----------------------
   USA export licenses are usually granted for (weak) encryption
   software using RC2 or RC4 with 40 bit keys.  For this license it is
   required to implement the agent or manager with one of the following
   combinations.

   Manager: D0, or D0+, or D0 and D1, or D0+ and D1+.  Plus C0, or C0+,
            or C1, or C1+, or C2, or C2+, or C3, or C3+.
   Agent:   D0, or D0+, or D0 and D1, or D0+ and D1+.  Plus C0, or C0+,
            or C1, or C1+, or C2, or C2+, or C3, or C3+.



26. Agent Requirements

   An agent must use the same level of security for its response as the
   manager used for its request.  If the agent cannot or will not
   support an algorithm (or key size) then it should return an
   appropriate error.  It is up to the manager to choose another
   security level.

   Only for traps can an agent select any level, besides enhanced,
   however it is recommended to use the lowest available level.  If
   possible, D0 is the best since all managers guarentee to support
   this level.

   For the opaqueValue field it must respond with the exact same value
   it received during the request.  For traps this field is set to zero.

   The timeStamp field should be set to a copy of its internal clock when
   creating the response encapsulation header.  If no clock is available
   then this should be set to zero.



27. Explanation of Certain Design Details


   Time Synchronization
   --------------------

   Time synchronization is quite simple.  Each agent is considered
   to keep an accurate timer.  Any manager which wishes to communicate
   with an agent, gets this timer to synchronize with their internal
   timer.  Once the flow of encapsulated packets has begun, then
   the manager can automatically synchronize from the timeStamp
   field when receiving a packet from the agent.  Each agent
   maintains what it considers to be an acceptable amount of delay
   from its current time for any incoming packets.  Packets
   which fall outside this delay range must be returned to the
   sender with an error (badTimeStamp) and a current copy of its
   internal time in the timeStamp field.  This gives the manager
   a chance to correct its timestamp and to resubmit its request.
   This also makes analyzing errors simpler.  Managers do not test time
   stamps, they only examine them to resynchronize their internal
   timers for each agent they are communicating with.  This does expose
   managers to a replay attack.  There are no real benefits to be
   gained by this type of attack, in fact a good SNMP manager protocol
   stack implementation should ignore duplicate SNMP responses.

   Some agents may not be able to support an accurate timer.  In
   this case time synchronization is not possible.  Any timeStamp
   field value sent by the manager can be ignored by the agent.
   When the agent responds it sets this field to zero, indicating
   that there is no time stamp support.  This degrades the
   authentication robustness by increasing the possibility of replay
   attacks against the agent.


   Encrypted Signature
   -------------------

   The encrypted signature, where the signature contains the one-way
   hash and potentially the symmetric key, ensures that only the
   authorized sender and receiver can communicate.


   Asymmetric Key Identification
   -----------------------------

   When the receiving an encapsulated SNMP packet with data that
   has been signed by a private key, e.g. the hash and possibly the
   symmetric key, there is a problem of looking up the correct public
   key.  All asymmetric algorithm signed or encrypted data, with either
   the public or private key respectively, has a unique identifier
   prepended to it.  This allows the receiver to find the corresponding
   key, usually a public key, to verify or decrypt the data.  This
   unique identifier is generated by whomever created the public and
   private key pair.  This document recommends that a hash be run over
   a pass phrase or text, and then the lower 8 octets are used as the
   unique identifier of the keys.


28. Exporting Encryption Software

   According to the USA government, cryptography is a munition. You
   must obtain the proper export license to sell any software with
   cryptography [27]. There are two USA government agencies that
   control export of encryption software.

   One is the Bureau of Export Administration (BXA) in the Department
   of Commerce, authorized by the Export Administration Regulations.
   The other is the Office of Defense Trade Controls (DTC) in the State
   Department, authorized by the Defense Trade Regulations.  The
   National Security Agency (NSA) controls the DTC.

   The BXA has less stringent requirements.  The DTC usually inspects
   an application first and can refuse to transfer jurisdiction to BXA.
   The Defense Trade Regulations regulates the export sales of
   munitions.  An encryption product may need approval for every
   product revision or even every sale.

   The State Department does not approve the export of products with the
   DES algorithm.  The Software Publishers Association (SPA) has recently
   been negotiating with the government to ease the export license
   restrictions.  A 1992 agreement eased the export license rules for two
   ciphers, RC2 and RC4, as long as the key size is 40 bits or less.
   Products that implement one of these two algorithms have a much
   simpler export approval process, provided that the keys are no more
   than 40 bits in size.

   Please note that these export rules do not apply to sales within the
   USA, or to foreign subsidiaries of USA corporations in friendly
   countries, or for financial uses in friendly countries, or to
   Canada [22].  There are no restrictions in these cases.  However,
   they do apply to sales to foreign nationals residing within the USA.

   Some foreign countries, most notably France, restrict the import of
   encryption software.


29. Exporting Authentication-only Software

   It is the stated policy of the NSA not to restrict the export of
   authentication products, only encryption products.  To export an
   authentication-only product approval is subject to showing that the
   device cannot easily be converted to an encryption device.  The
   bureaucratic procedures are much simpler for authentication products
   than encryption products.  An authentication product needs NSA and
   State Department export approval only once.


30. Definitions


SECURE-SNMP DEFINITIONS ::= BEGIN

   -- Authenticated or secure encapsulation of SNMP message.

   Encapsulation-Message ::=
           SEQUENCE {
               version          -- Version 3 for this RFC.
                   INTEGER {
                       version-3(2)
                   },

               opaqueValue      -- Manager sets this, agent must
                   INTEGER,     -- echo it back.  Traps use 0.

               errorStatus      -- Response from agent, 0 otherwise.
                   INTEGER {
                       noError(0),
                       generalError(1),
                       badSignature(2),
                       unsupportedPublicKey(3),
                       unsupportedHash(4),
                       badTimeStamp(5),
                       badSymmetricKey(6),
                       tooLargeSymmetricKey(7),
                       unsupportedSymmetricKey(8),
                       unsupportedSymmetricMode(9),
                       noEncryptedDataAllowed(10),
                       badEncryptedData(11)
                   },

               timeStamp       -- Synchronized time value.
                   INTEGER,    -- Agent returns current value.

               encryptedSignature -- May contain symmetric key.
                   EncryptedSignature,

               CHOICE {
                  data             -- SNMPv1, SNMPv2, etc., packet
                     ANY,
                  encryptedData    -- The data encrypted w/symm. key.
                     EncryptedData
               }

           }

END



AUTHENTICATION-MIB DEFINITIONS ::= BEGIN


   IMPORTS
           mgmt
                   FROM RFC1155-SMI
           OBJECT-TYPE
                   FROM RFC-1212;



   -- MIB I and MIB II have the same object identifier.

   mib-2               OBJECT IDENTIFIER ::= { mgmt 1 }

   secure              OBJECT IDENTIFIER ::= { mib-2 111 }


   -- Textual conventions

   Time ::= INTEGER
   -- The date and time expressed as the number of seconds
   -- since midnight January 1, 1900 GMT





-- ====================================================================
--
-- Support Variables
--


   securePublicKey OBJECT-TYPE
                  SYNTAX    PublicKey
                  ACCESS    read-only
                  STATUS    mandatory
                  DESCRIPTION
                            "The agent's public key.
                            "
                  ::= { secure 1 }


   secureSystemTime OBJECT-TYPE
                  SYNTAX    Time
                  ACCESS    read-only
                  STATUS    optional
                  DESCRIPTION
                            "This is the Agent's system date and time
                             expressed as the number of seconds since
                             midnight January 1, 1900 GMT.  The manager
                             can retrieve this to synchronize its time
                             stamps.  A practical implementation will
                             allow a certain amount of clock skew when
                             comparing incoming timestamps with this
                             value.
                            "
                  ::= { secure 2 }



-- ====================================================================
--
-- The Public Key Table
--
-- It is optional to implement this table.
--
-- This table is for managers to deposit their public keys with an agent.
-- They must use their private keys to encrypt the hash and time stamps
-- but the agent uses the public keys to decrypt them and thus certify
-- the incoming SNMP request.
--
-- For a public key to be allowed into this table from across the
-- network it will have to be authenticated by a trusted person.  This
-- person's public key must already be registered in this table before
-- they can add another person's public key i.e. certifing the new key.
-- This table controls which SNMP requests will be accepted by the
-- agent, and what privilege level will be associated with it.  The
-- actual details of how the privilege levels will work and an acceptable
-- certification alogrithm is left up to the agent designer.


   securePublicKeyTable OBJECT-TYPE
                  SYNTAX    SEQUENCE OF securePublicKeyEntry
                  ACCESS    not-accessible
                  STATUS    optional
                  ::= { secure 3 }

   securePublicKeyEntry OBJECT-TYPE
                  SYNTAX    SecurePublicKeyEntry
                  ACCESS    not-accessible
                  STATUS    mandatory
                  INDEX     { publicKeyIndex }
                  ::= { securePublicKeyTable 1 }

   AuthPublicKeyEntry ::= SEQUENCE {
                  securePublicKeyIndex
                          INTEGER,
                  securePublicKeyPrivilegeLevel
                          INTEGER,
                  securePublicKeyIdentifier,
                          OCTET STRING,
                  securePublicKey
                          PublicKey
                  }

   securePublicKeyIndex OBJECT-TYPE
                  SYNTAX    INTEGER
                  ACCESS    read-only
                  STATUS    mandatory
                  DESCRIPTION
                            "This is an index value."
                  ::= { securePublicKeyEntry 1 }

   securePublicKeyPrivilegeLevel OBJECT-TYPE
                  SYNTAX    INTEGER
                  ACCESS    read-write
                  STATUS    mandatory
                  DESCRIPTION
                            "This indicates what privileges are
                             allowed for the manager associated with
                             this public key.  This entry can only be
                             written using an authenticated Set request
                             which is accepted by the agent.  The highest
                             privilege level is zero, and the lower the
                             level the greater the integer value."
                  ::= { securePublicKeyEntry 2 }

   securePublicKeyIdentifier OBJECT-TYPE
                  SYNTAX    OCTET STRING (SIZE(8))
                  ACCESS    read-write
                  STATUS    mandatory
                  DESCRIPTION
                            "A unique identifier associated with the
                             public key.  It is generated by the
                             manager.  This helps associate the
                             incoming encrypted variables with the
                             correct public key to decrypt them.  This
                             entry can only be written using an
                             authenticated Set request which is
                             accepted by the agent."
                  ::= { securePublicKeyEntry 3 }

   securePublicKeyValue OBJECT-TYPE
                  SYNTAX    PublicKey
                  ACCESS    read-write
                  STATUS    mandatory
                  DESCRIPTION
                            "The manager's public key.  This is
                             used by the agent to authenticate the
                             manager.  This entry can only be written
                             using an authenticated Set request which
                             is accepted by the agent."
                  ::= { securePublicKeyEntry 4 }

END


31. An Example Encoding

   We wish to set the following value on an agent.

        Object Identifier = 1.3.6.1.4.1.123.5.0
        Data Type = Integer
        Data = 65


   A standard SNMP Set request packet.

        30 27 02 01 00 04 06 70 75 62 6C 69 63 A4 1A 02
        01 01 02 01 00 02 01 00 30 0F 30 0D 06 08 2B 06
        01 04 01 7B 05 00 02 01 41


   The authenticated SNMP Set request packet.  Using MD5 and
   and RSA with a 512 bit modulus.

        30 81 C8 02 01 02 02 01 00 02 01 00 02 04 30 9D
        96 E5 AC 81 8D 04 08 02 00 00 00 00 00 00 00 04
        81 80 80 58 D0 EB 7A C2 71 7B A8 9E 66 28 CD 2D
        41 74 4F 6F 3D BE AC 22 6C 25 57 23 3D BF EF CE
        21 9B AA 44 02 EA 32 B7 9D 92 BB 88 72 FC 86 32
        66 B7 E0 75 3A 0D D6 87 0E 77 37 91 F1 EF B0 D7
        F2 75 24 69 8D F2 C8 76 50 62 15 31 6E 7E 8D 9C
        16 CD 72 AA 05 8E 1F 18 80 DA 99 54 77 78 DE 8E
        2F 2F EA BF 39 A0 92 40 BB F3 E6 79 59 76 2E 49
        B5 47 6A 32 0F 50 51 4E 13 A9 88 54 5C 69 1B F8
        36 24 30 27 02 01 00 04 06 70 75 62 6C 69 63 A4
        1A 02 01 01 02 01 00 02 01 00 30 0F 30 0D 06 08
        2B 06 01 04 01 7B 05 00 02 01 41


   A secure SNMP Set request packet (it is encrypted).  Note the hash
   was calculated over both the encapsulation (using a zeroed encrypted
   signature field) header and the encrypted packet (ASN.1 encoded).
   Using MD5 and RSA with a 512 bit modulus.  The symmetric key is RC4
   using 40 bits.

        30 81 CA 02 01 02 02 01 00 02 01 00 02 04 30 9D
        96 E9 AC 81 8D 04 08 02 00 00 00 00 00 00 00 04
        81 80 2A 07 77 61 BE E4 9B 16 E6 D0 1A BE 66 B3
        B7 F1 71 22 20 7D D2 9F D0 65 12 8C 0B 42 56 52
        02 B6 66 C9 3E 82 C5 F7 19 95 C3 D8 8A FB BD 6E
        B9 F8 F1 08 47 30 5E 4E 89 9C 9A 0A 3E 47 A2 F9
        83 67 9C 03 66 BE D0 16 C2 2C B9 BD 0D 89 BA 84
        66 87 2D 33 81 65 CA 4B 2E 7D DA D8 C7 00 4C B3
        58 05 43 1F 5A 7D 3B 22 F8 87 94 E8 79 05 76 94
        A8 E4 E4 03 CB BF 79 DE DA FE E1 6A 8A 0E 08 C6
        BA 8F B1 29 9E 84 36 54 A3 C1 A4 35 3A 34 46 E3
        37 01 B2 CB 63 8F DF 21 8C 89 ED 58 81 AB C6 DD
        FB 51 A7 F5 A9 A9 E1 39 B3 99 CB 48 85


   Note: This example uses a smaller RSA modulus than this document
         recommends.


32. Acknowledgements

   I would like to thank the following people for their excellent
   suggestions and comments.

        Don Provan     Novell, Inc., USA
        Denis Pinkas   Bull SA, France



33. References

   Request For Comments
   --------------------

   [1]  RFC 1155, Case, J.D., et. al., Structure and Identification of
        Management Information for TCP/IP-based Internets.
        (SNMPv1), May 1990

   [2]  RFC 1157, Case, J.D., et. al., Simple Network Management Protocol
        (SNMPv1), May 1990

   [3]  RFC 1158, Rose, M.T., Management Information Base for Network
        Management of TCP/IP-based Internets: MIB-II
        May 1990

   [4]  Fougner, R., RFC 1170, Public Key Standards and Licenses, Jan.
        1991.  Public Key Partners, Inc.

   [5]  RFC 1212, Rose, M., et al., Concise MIB Definitions, March 1991

   [6]  RFC 1321, Rivest, R., The MD5 Message-Digest Algorithm.
        April 1992.

   [7]  RFC 1351, Davin, J., et. al., SNMP Administrative Model,
        July 1992

   [8]  RFC 1352, Galvin, J., et. al., SNMP Security Protocols,
        July 1992

   [9]  RFC 1445, Galvin, J., et. al., Administrative Model for version
        2 of the Simple Network Management Protocol (SNMPv2).
        April 1993.

   [10] RFC 1446, Galvin, J., et. al., Security Protocols for version 2
        of the Simple Network Management Protocol (SNMPv2).
        April 1993.

   [11] RFC 1448, Case, J.D., et. al., Protocol Operations for version
        2 of the Simple Network Management Protocol (SNMPv2), April
        1993.

   [12] RFC 1750, Eastlake, D. E., et al., Randomness Recommendations
        for Security

   Patents
   -------

   [13] Meyer, C.H. et. al., USA Patent 3,962,539, Product Block Cipher
        for Data Security.  Held by IBM.  Expired.

   [14] Lai, X., et. al., European Patent  PCT/CH91/00117.  Patent
        pending in USA. International Data Encryption Algorithm (IDEA).
        Held by ETH and Ascom-Tech Ab, Switzerland.

   [15] Rivest, R., et al., USA Patent 4,405,829. Cryptographic
        Communications System and Method.  Held by Public Key Partners.
        This is also known as the RSA public key algorithm.

   Standards
   ---------

   [16] NBS FIPS PUB 46, "Data Encryption Standard", National Bureau of
        Standards, U.S. Deparment of Commerce, Jan. 1977

   [17] NBS FIPS PUB 81, "DES Modes of Operation", National Bureau of
        Standards, U.S. Deparment of Commerce, Dec. 1980

   [18] NBS FIPS PUB 74, "Guidelines for Implementing and Using the
        NBS Data Encryption Standard", National Bureau of Standards,
        U.S. Deparment of Commerce, Apr. 1981

   [19] ANSI X9.17 (Revised), "American National Standard for Financial
        Institution Key Management (Wholesale)", American Bankers
        Association, 1985

   [20] ISO DIS 8732, "Banking Key Management (Wholesale)", Association
        for Payment Clearing Services, London, Dec. 1987

   [21] NIST FIPS PUB 180, "Secure Hash Standard", National Institute
        of Standards and Technology, Federal Information Processing
        Standards Publication, U.S. Department of Commerce,
        May 11, 1993.

   Publications
   ------------

   [22] Hoffman, L., ed., "Building In Big Brother, The Cryptographic
        Policy Debate", Springer-Verlag, 1995

   [23] Robshaw, M., "Security Estimates for 512-bit RSA", RSA
        Laboratories, June 1995.

   [24] Schneier, B., "Untangling Public-Key Cryptography", pp. 16-28,
        Dr. Dobbs Journal, April 1992.

   [25] Schneier, B., "Applied Cryptography", 2nd ed., John Wiley &
        Sons, Inc., 1996.

   [26] Imported and Exported Defense Articles and Services (ITAR),
        Vol. 57, No. 89, Part II, 56 FR 19666, May 7, 1992.
        U.S. Department of State, Bureau of Politico-Military Affairs

   Code
   ----

   [27] Rivest, R.  Ron's Code 2 (RC2) and 4 (RC4).  Variable key size
        encryption algorithms owned by RSA Data Security, Inc.
        Unpublished.  (RC4 was stolen and distributed on the Internet.)

   [28] Zimmerman, P., Pretty Good Privacy, 2.3a source code, 1994.


34. Glossary of Terms

ASN.1,  Abstract Syntax Notation version 1
BXA,    Bureau of Export Administration in the Department of Commerce,
        authorized by the Export Administration Regulations.
DES,    Digital Encryption Standard, a USA symmetric key standard
        [13, 16, 17, 18].
DSA,    Digital Signature Algorithm, part of DSS, a public key algorithm
DSS,    Digital Signature Standard, a USA public key standard
DTC,    Office of Defense Trade Controls in the State Department,
        authorized by the Defense Trade Regulations.
LUC,    Public key algorithm using Lucas functions, invented by Peter
        Smith.
IDEA,   International Digital Encryption Algorithm, a symmetric key
        algorithm [14].
MD,     Message Digest, a one-way hash
MIB,    Management Information Base, used with SNMP
MIT,    Massachusetts Institute of Technology.
NSA,    National Security Agency
PDU,    Packet Data Unit
PKP,    Public Key Partners of Sunnyvale, California, a consortium of
        RSADSI, Cylink, Inc., Stanford University and MIT.
RC,     Ron's Code
RFC,    Request For Comment, Internet standards
RSA,    Rivest-Shamir-Adleman, public key algorithm [15]
RSADSI, RSA Data Security Inc.
SHA,    Secure Hash Algorithm, a one-way hash
SNMP,   Simple Network Management Protocol, see also MIB
SNMPv1, SNMP version 1 (RFCs 1155 1157, 1212)
SNMPv2, SNMP version 2 (RFCs 1441 to 1452)
SNMPSec,SNMP Security (RFCs 1351, 1352)


Security Considerations

   Security issues for SNMP authentication and privacy are discussed
   in this document.


Author Address

Alexander I. Alten
Alten@Novell.Com
(408) 577-8224

Novell, Inc.
Mail Stop F1-42-D2
2180 Fortune Drive
San Jose, CA  95131
USA