Internet DRAFT - draft-alten-snmp-sec-encap

draft-alten-snmp-sec-encap



HTTP/1.1 200 OK
Date: Mon, 08 Apr 2002 22:29:33 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Wed, 02 Aug 1995 22:00:00 GMT
ETag: "2e7cd4-13604-301ff560"
Accept-Ranges: bytes
Content-Length: 79364
Connection: close
Content-Type: text/plain

INTERNET DRAFT
Expires in six months
<draft-alten-snmp-sec-encap-00.txt>



                   Security Encapsulation of SNMP
                   -------- ------------- -- ----

                         Alexander. I. Alten

                            July 30, 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. 


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 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 doubly
   encrypted using asymmetric (public key) encryption technology, such
   as the RSA algorithm [15].  First the sender encrypts 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 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, a combinatorial
   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.  Distribution might only occur when a manager
   and agent 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 imported 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 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.  The only asymmetric
   algorithms specified are RSA [15] and ElGamal [25].  Symmetric
   algorithms use only one key for both encryption and decryption.
   The only symmetric algorithms specified are; RC2, RC4 [27], DES [13, 
   16, 17, 18], Triple DES [20, 21], and IDEA [14].

   In summary, for authentication data encryption we use the public
   and private keys, while for SNMP packet privacy encryption we use a
   symmetric key.  Note that full SNMP security requires both encrypted
   authentication and SNMP packet 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 prevent an improper manager
      from modifying the MIB.  Denial of service means a valid manager
      could be denied access to an agent.

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


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.

      badPublicKey              The public key is not registered with
                                the agent or is malformed or is too
                                small.

      unsupportedPublicKey      This type of public key is not
                                supported.  RSA is required for all
                                implementations.

      badHash                   The one-way hash is invalid, it did not
                                match the computed hash.

      unsupportedHash           This one-way hash algorithm is not
                                supported.

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

      badSymmetricKey           The symmetric key is malformed.

      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.

      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 doubleAsymmetricEncryptedHash is the computed one-way hash
   of the entire encapsulation, not including this field, and the 
   appended SNMP packet (plain or encrypted).  It encrypted first
   by the sender's private key and then by the receiver's public
   key.  This is called a double asymmetric encryption.

   The final field is the SNMP packet, either plain or encrypted.
   If it is encrypted it actually is composed of two fields, the
   first being the symmetric key, a double asymmetric encryption,
   and the second being the symmetric algorithm encrypted packet.
   

   -- 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),
                       badPublicKey(2),
                       unsupportedPublicKey(3),
                       badHash(4),
                       unsupportedHash(5),
                       badTimeStamp(6),
                       badSymmetricKey(7),
                       tooLargeSymmetricKey(8),
                       unsupportedSymmetricKey(9),
                       noEncryptedDataAllowed(10),
                       badEncryptedData(11)
                   },

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

               doubleAsymmetricEncryptedHash -- Encrypted one-way hash value.
                   DoubleAssymetricEncryptedHash, 

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

           }


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 receive 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.  The encrypted hash and error
      values are set 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 time stamp.  The only exception is
      the double encrypted hash field which is ignored during the
      calculation.  

   4. Double encrypt the hash value, first with the manager's private
      key, then 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 doubly encrypted hash, first using the agent's
      private key, then 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.

   2. Compute a hash of the encapsulation header (see below) and the 
      SNMP packet.  The double encrypted hash field is ignored during
      the calculation.
   
   3. Compare the computed hash and the decrypted hash.  If they are
      equal then proceed.  Otherwise send an authenticated response
      indicating a bad hash 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.  The encrypted hash value
      is set to zero.  Set the error status value.  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 time stamp.  The only exception is
      the double encrypted hash field which is ignored during the
      calculation.

   4. Double encrypt the hash value, first with the agent's private
      key, then 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 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 double encrypted hash field is ignored during
      the calculation.
   
   3. Compare the computed hash and the decrypted 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.  The 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 time stamp.  The only exception is
      the double encrypted hash field which is ignored during the
      calculation.

   4. Double encrypt the hash value, first with the agent's private
      key, then 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 double encrypted hash field is ignored during
      the calculation.
   
   3. Compare the computed hash and the decrypted 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 One-Way Hash  | 
                       |                          | 
   +-------------+     | +----------------------+ |     +------------+
   |             |     | |                      | |     |            |
   |    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 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.  The encrypted hash 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 double asymmetric key encrypted hash field which is
      ignored during the calculation.

   5. Double encrypt the hash value, first with the manager's private
      key, then 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 double asymmetric key encrypted hash, first using the
      agent's private key, then 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.

   2. Compute a hash of the encapsulation header (see below) and the 
      SNMP packet.  The double encrypted hash field is ignored during
      the calculation.
   
   3. Compare the computed hash and the decrypted hash.  If they are
      equal then proceed.  Otherwise send a secure response indicating
      a bad hash 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. Decrypt the symmetric key, first using the agent's private key
      and then the manager's public key.  Then ASN.1 decode and decrypt,
      using the symmetric key, the SNMP packet.  

   Note: If any errors occur, such as a bad public key, 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.  The encrypted hash 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.  The only exception
      is the double asymmetric key encrypted hash field which is
      ignored during the  calculation.

   5. Double encrypt the hash value, first with the agent's private
      key, then 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 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 double encrypted hash field is ignored during
      the calculation.
   
   3. Compare the computed hash and the decrypted 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. ASN.1 decode and decrypt, using the symmetric key, 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 hash, 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 double encrypted hash field which is ignored during the
      calculation.

   4. Double encrypt the hash value, first with the agent's private
      key, then 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 double encrypted hash field is ignored during
      the calculation.
   
   3. Compare the computed hash and the decrypted 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. ASN.1 decode and decrypt, using the symmetric key, the SNMP
      packet.  

   

                     Secure SNMP Transaction or Trap
                      
                       +--------------------------+
                       |                          | 
                       |      Encapsulation       | 
                       |          Header          | 
                       |         using an         | 
                       |  Encrypted One-Way Hash  | 
                       |                          | 
   +-------------+     | +----------------------+ |     +------------+
   |             |     | |                      | |     |            |
   |             |     | |      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,
     exponent    -- 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 Encrypted Data Format

   This is the format of the private key encrypted data format [14].
   For this document the encrypted data will consist only of a
   calculated hash or 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.

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

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

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

   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
   public key encrypted hash or symmetric key.  This is called double
   encryption.  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
        Hash (SIZE(8)),
     encryptedData,
        OCTET STRING
   }

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

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

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


18. Encrypted Hash Format

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

   Step 1: One-way hash computation:

      M = Hash ( Encapsulation-Message, not including  
                 doubleEncryptedHash field )

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

       C1 = Encrypt( M, Sender's Private Key )

   Step 3: Encrypting the private key encrypted hash value with the
           receiver's public key.

       C2 = Encrypt( C1, Receiver's PublicKey )

   DoubleAsymmetricEncryptedHash ::= {
      {
         {
            hash,
               Hash
         },
            PrivateKeyEncryptedData
      },
         PublicKeyEncryptedData
   }


19. 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), ofb(2), cfb(3) },
     vector  -- Used by CBC
        INTEGER OPTIONAL,
     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 {
     key 
        OCTET STRING (SIZE(16))
   }

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


20. Symmetric Key Encrypted Data Format

   This is the format of the symmetric key encrypted data format.
   For this document the encrypted data will consist only of a
   SNMP packet.  

   DoubleAsymmetricEncryptedSymmetricKey ::= {
      {
         {
            symmetricKey,
               SymmetricKey
         },
            PrivateKeyEncryptedData
      },
         PublicKeyEncryptedData
   }

   SymmetricKeyEncryptedData ::= [31] IMPLICIT SEQUENCE {
        doubleAsymmetricEncryptedSymmetricKey,
                DoubleAsymmetricEncryptedSymmetricKey,
        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).


21. 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 }


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


23. 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+.



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


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

   
   Double Asymmetric Encryption
   ----------------------------

   The double asymmetric encryption of the hash and 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 encrypted by a private key, the hash and the symmetric
   key, there is a problem of looking up the correct public key.
   All asymmetic encrypted data, encrypted with either the public or
   private key, has a unique identifier prepended to it.  This allows
   the receiver to find the corresponding key, usually a public key,
   to 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.


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


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


28. 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),
                       badPublicKey(2),
                       unsupportedPublicKey(3),
                       badHash(4),
                       unsupportedHash(5),
                       badTimeStamp(6),
                       badSymmetricKey(7),
                       tooLargeSymmetricKey(8),
                       unsupportedSymmetricKey(9),
                       noEncryptedDataAllowed(10),
                       badEncryptedData(11)
                   },

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

               doubleAsymmetricEncryptedHash -- Encrypted one-way hash value.
                   DoubleAssymetricEncryptedHash, 

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

           }

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


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

   The variable binding ASN.1 encoding.

        30 0D 06 08 2B 06 01 04 01 7B 05 00 02 01 41

   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 

   Using RSA, lets say that our manager's private key is <d=79, 
   n=3337> and it's public key is <e=1019, n=3337>.  The agent has our
   public key.  The largest power of two less than 3337 is 2048 (2^11),
   which means any data to be encrypted should be broken into blocks of
   11 bits each.

   To add authentication we need to build the encapsulation header and
   then calculate the hash.

   The version value is 2, the opaque value is 0, and the error status
   is 0.  For this example the data is not encrypted so the encrypted
   symmetric key is null.

   Say the time stamp is 2998021248 seconds (roughly Jan. 1995).
   In hexadecimal it is B2B22C80.

   The variable binding ASN.1 encoding of the time stamp.

        02 04 B2 B2 2C 80

   The MD5 hash calculation is over the following octets, without the
   doubly encrypted hash field.  

        30 38 02 01 02 02 01 00 02 01 00 02 04 B2 B2 2C
        80 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 128 bit MD5 hash result (message digest).

        54 E8 BE 7B 9A 03 F3 6C B7 14 21 58 3D A7 92 F5 

   The ASN.1 encoding of it.

        A0 10 54 E8 BE 7B 9A 03 F3 6C B7 14 21 58 3D A7
        92 F5 

   Break it into thirteen 11-bit data chunks.

        M13 M12 M11  M10  M9 M8   M7  M6  M5  M4  M3   M2  M1
             2A 3A2  7CF 39A 1F  4DB 16E 142  AC  F6  4F2 2F5 (hex)
             42 930 1999 922 31 1243 366 322 172 246 1266 757 (dec)

        C1  =  757^79 (mod 3337) =  599 (257 hex)
        C2  = 1266^79 (mod 3337) = 1299 (513 hex)
        C3  =  246^79 (mod 3337) = 3248 (CB0 hex)
        C4  =  172^79 (mod 3337) = 1468 (5BC hex)
        C5  =  322^79 (mod 3337) = 2929 (B71 hex)
        C6  =  366^79 (mod 3337) = 1055 (41F hex)
        C7  = 1243^79 (mod 3337) = 1155 (483 hex)
        C8  =   31^79 (mod 3337) = 3301 (CE5 hex)
        C9  =  922^79 (mod 3337) =   70 (046 hex)
        C10 = 1999^79 (mod 3337) = 1836 (72C hex)
        C11 =  930^79 (mod 3337) = 3029 (BD5 hex)
        C12 =   42^79 (mod 3337) = 2973 (B9D hex)
        C13 =  888^79 (mod 3337) = 1655 (677 hex)

   Recombining the thirteen 12-bit encrypted data chunks gives the
   manager's private key encrypted MD5 hash.

        06 77 B9 DB D5 72 CD 4F CE 54 83 41 FB 71 5B CC
        B0 51 32 57

   The the ASN.1 encoding of it (with key identifier).

        A8 20 A0 08 7B 9A 03 F3 6C B7 14 21 04 12 06 77
        B9 DB D5 72 C0 46 CE 54 83 41 FB 71 5B CC B0 51
        32 57

   In turn, this is encrypted by the agent's public key,

        2A 3A 27 CF 39 A1 F4 02 04 B2 DB 16 E1 42 AC F6
        4F 22 F5 B2 2C 80 2B A3 6F BD 72 61 FC 5F 14 B5
        3A AC FA

   And then ASN.1 encoded.

        AC 2F A0 08 9B BD 5D DC F4 EC 45 38 04 23 2A 3A
        27 CF 39 A1 F4 02 04 B2 DB 16 E1 42 AC F6 4F 22
        F5 B2 2C 80 2B A3 6F BD 72 61 FC 5F 14 B5 3A AC 
        FA

   The authenticated SNMP Set request packet.

        30 69 02 01 02 02 01 00 02 01 00 02 04 B2 B2 2C
        80 AC 2F A0 08 9B BD 5D DC F4 EC 45 38 04 23 2A
        3A 27 CF 39 A1 F4 02 04 B2 DB 16 E1 42 AC F6 4F
        22 F5 B2 2C 80 2B A3 6F BD 72 61 FC 5F 14 B5 3A
        AC FA 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 (minus hash field) header
   and the encrypted packet (ASN.1 encoded).  The symmetric key is RC4
   using 40 bits (5 octets, 6 when encrypted by an asymmetric key).

        30 84 02 01 02 02 01 00 02 01 00 02 04 B2 B2 2C
        80 AC 2F A0 08 9B BD 5D DC F4 EC 45 38 04 23 F9
        B2 7F 58 6B 12 BA F2 F6 2F 51 0F 24 B2 3A CA 7B
        AD F2 0F 31 24 35 CC 2A 44 2A 6F CB 60 4E 21 5C
        B1 1D BF 01 41 AC 14 A2 12 A0 08 83 54 CE 4F CD
        D5 DB B9 04 06 3A 7C 91 42 2D 6E B1 27 5A B4 6F
        16 A2 A4 22 C9 01 B4 32 6B BD 21 4E 22 53 20 CA
        C8 12 CA FF 1D 57 FF 72 0F BB 32 AF F6 4F 9C E4
        75 4B 6F 02 23 C9

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


30. Acknowledgements




31. 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] ??, 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", John Wiley & Sons, 1994.
 
   [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.


32. 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.
Advanced Access Applications Division
Member of Technical Staff
Mail Stop F1-42-D2
2180 Fortune Drive
San Jose, CA  95131  
USA