[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00 RFC 1352

Network Working Group                                           April 1991
Internet-Draft







                SNMP Security Protocols




                      James M. Galvin
                Trusted Information Systems, Inc.

                      Keith McCloghrie
                   Hughes LAN Systems, Inc.

                       James R. Davin
              MIT Laboratory for Computer Science


                        April 8, 1991







       Contents


       1  Status of this Memo                                 1


       2  Acknowledgements                                    1


       3  Introduction                                        1

          3.1   Threats                                       3

          3.2   Goals and Constraints                         5

          3.3   Security Services                             6

          3.4   Mechanisms                                    6


       4  SNMP Party                                          7


       5  SNMP MD4 Authentication Protocol                   10

          5.1   Generating a Message                         13

          5.2   Receiving a Message                          14


       6  SNMP DES Privacy Protocol                          16

          6.1   Generating a Message                         17

          6.2   Receiving a Message                          18


       7  Clock and Secret Distribution                      19

          7.1   Initial Configuration                        21

          7.2   Clock Distribution                           24

          7.3   Secret Distribution                          25

          7.4   Crash Recovery                               28




       INTERNET-DRAFT                               April 1991


       8  Security Considerations                             30

          8.1   Conformance                                      31

          8.2   Protocol Correctness                               32

             8.2.1   Clock Monotonicity Mechanism             33

             8.2.2   Data Integrity Mechanism                  33

             8.2.3   Data Origin Authentication Mechanism     33

             8.2.4   Restricted Administration Mechanism      34

             8.2.5   Ordered Delivery Mechanism               35

             8.2.6   Message Timeliness Mechanism             36

             8.2.7   Confidentiality Mechanism                 36



























       Galvin, McCloghrie, Davin                           [Page ii]

       INTERNET-DRAFT                               April 1991


       1    Status of this Memo


       This draft document will be submitted to the RFC editor as a
       protocol specification. Distribution of this memo is unlimited.
       Please send comments to the authors: James M. Galvin
       <galvin@tis.com>, Keith McCloghrie <kzm@hls.com>, and
       James R. Davin <jrd@ptt.lcs.mit.edu>.



       2    Acknowledgements


       3    Introduction


       The Simple Network Management Protocol (SNMP)
       specification [1] allows for the protection of network
       management operations by a variety of security protocols.
       The SNMP administrative model described in [2] provides a
       framework for securing SNMP network management. In the
       context of that framework, this memo defines protocols to
       support the following three security services:

          o data integrity,

          o data origin authentication, and

          o data confidentiality.

       In the model described in [2], each SNMP party  is, by
       definition, associated with a single authentication protocol.
       The authentication protocol provides a mechanism by which
       SNMP management communications transmitted by the party
       may be reliably identified as having originated from that
       party. The authentication protocol defined in this memo also
       reliably determines that the message received is the message
       that was sent.

       Similarly, each SNMP party  is, by definition, associated with
       a single privacy protocol. The privacy protocol provides a

       Galvin, McCloghrie, Davin                            [Page 1]

       INTERNET-DRAFT                               April 1991


       mechanism by which SNMP management communications
       transmitted to said party are protected from disclosure. The
       privacy protocol in this memo specifies that only
       authenticated messages may be protected from disclosure.

       These protocols are secure alternatives to the so-called
       "trivial" protocol defined in [1].

       USE OF THE TRIVIAL PROTOCOL ALONE DOES NOT
       CONSTITUTE SECURE NETWORK MANAGEMENT. THEREFORE,
       A NETWORK MANAGEMENT SYSTEM THAT IMPLEMENTS ONLY
       THE TRIVIAL PROTOCOL IS NOT CONFORMANT TO THIS
       SPECIFICATION.

       The SNMP MD4 authentication protocol is described in
       Section 5. It provides a data integrity service by having the
       originator compute a digest over an appropriate portion of a
       message and sending that digest to the recipient, with the
       message, for verification. The data origin authentication
       service is supported by prefixing the message with a secret
       value known only to the originator and recipient, prior to
       computing the digest. Thus, data integrity is supported
       explicitly while data origin authentication is supported
       implicitly in the verification of the digest.

       The SNMP DES privacy protocol is described in Section 6.
       This protocol protects messages from disclosure by encrypting
       their contents according to a secret cryptographic key known
       only to the originator and recipient. The additional
       functionality afforded by this protocol is assumed to justify its
       additional computational cost.

       The SNMP MD4 authentication protocol depends on the
       existence of loosely synchronized clocks between the originator
       and recipient of a message. Maintaining such clocks may be
       accomplished by a variety of strategies. Section 7.2 presents
       one such strategy that is particularly suited to the demands of
       SNMP network management.

       Galvin, McCloghrie, Davin                            [Page 2]

       INTERNET-DRAFT                               April 1991


       Both protocols described here require the sharing of secret
       information between the originator of a message and its
       recipient. The protocol specifications assume the existence of
       the necessary secrets. The selection of such secrets and their
       secure distribution to appropriate parties may be
       accomplished by a variety of strategies. Section 7.3 presents
       one such strategy that is particularly suited to the demands of
       SNMP network management.


       3.1   Threats

       Several of the classical threats to network protocols are
       applicable to the network management problem and therefore
       would be applicable to any SNMP security protocol. Other
       threats are not applicable to the network management
       problem. This section discusses principal threats, secondary
       threats and threats which are of lesser importance.

       The principal threats against which any SNMP security
       protocol should provide protection are:


       Modification of Information.    The SNMP protocol
           provides the means for management stations to
           manipulate the value of objects in a managed agent.
           The modification threat is the danger that some party
           may alter in-transit messages generated by an
           authorized party in such a way as to effect unauthorized
           management operations.

       Masquerade.  The SNMP administrative model includes a
           model of access control. Access control necessarily
           depends on knowledge of the origin of a message. The
           masquerade threat is the danger that management
           operations not authorized for some party may be
           attempted by that party by assuming the identity of
           another party that has the appropriate authorizations.


       Two secondary threats are also identified:

       Galvin, McCloghrie, Davin                            [Page 3]

       INTERNET-DRAFT                               April 1991


       Message Stream Modification.    The SNMP protocol is
           based upon connectionless transport services. The
           message stream modification threat is the danger that
           messages may be arbitrarily re-ordered, delayed or
           replayed to effect unauthorized management operations.
           This threat may arise either by the work of a malicious
           attacker or by the natural operation of a subnetwork
           service. All of these threats must be addressed by a
           security protocol.

       Disclosure.  The disclosure threat is the danger of
           eavesdropping on the exchanges between managed
           agents and a management station. Protecting against
           this threat is mandatory when the SNMP is used to
           administer private parameters on which its security is
           based. Protecting against the disclosure threat may also
           be required as a matter of local policy.


       There are at least two threats that a SNMP security protocol
       need not protect against. No attempt was made to provision
       protection against:


       Denial of Service   A SNMP security protocol need not
           attempt to address the broad range of attacks by which
           service to authorized parties is denied. Indeed, such
           denial-of-service attacks are in many cases
           indistinguishable from the type of network failures with
           which any viable network management protocol must
           cope as a matter of course.

       Traffic Analysis   In addition, a SNMP security protocol need
           not attempt to address traffic analysis attacks. It is
           believed that many traffic patterns are predictable --
           agents are probably managed on a regular basis by a
           relatively small number of management stations -- and
           therefore there is no significant advantage afforded by
           protecting against traffic analysis.


       Galvin, McCloghrie, Davin                            [Page 4]

       INTERNET-DRAFT                               April 1991


       3.2   Goals and Constraints

       Based on the foregoing account of threats in the SNMP
       network management environment, the goals of a SNMP
       security protocol are enumerated below.

         1. The protocol should provide for verification that each
           received SNMP message has not been modified during
           its transmission through the network.

         2. The protocol should provide for verification of the
           identity of the originator of each received SNMP
           message.

         3. The protocol should provide that the apparent time of
           generation for each received SNMP message is recent.

         4. The protocol should provide that the apparent time of
           generation for each received SNMP message is
           subsequent to that for all previously delivered messages
           of similar origin.

         5. The protocol should provide, when necessary, that the
           contents of each received SNMP message are protected
           from disclosure.

       In addition to the principal goal of supporting secure network
       management, the design of a SNMP security protocol is also
       influenced by the following constraints:

         1. When requirements of effective management in times of
           network stress are inconsistent with those of security,
           the former are preferred.

         2. Neither the SNMP nor its underlying security
           mechanisms should depend upon the ready availability
           of other network services (e.g., Network Time Protocol
           (NTP) or secret/key management protocols).

         3. A security mechanism should entail no changes to the
           basic SNMP network management philosophy.


       Galvin, McCloghrie, Davin                            [Page 5]

       INTERNET-DRAFT                               April 1991


       3.3   Security Services

       The security services necessary to support the goals of the
       SNMP security protocol are as follows.


       Data Integrity.   The provision of the property that data and
           data sequences have not been altered or destroyed in an
           unauthorized manner.

       Data Origin Authentication.    The corroboration that the
           claimed origin of received data is correct.

       Data Confidentiality.   The provision of the property that
           information is not made available or disclosed to
           unauthorized individuals, entities or processes.


       The protocols specified in this memo require both data
       integrity and data origin authentication to be used at all
       times. For these protocols, it is not possible to realize data
       integrity without data origin authentication, nor is it possible
       to realize data origin authentication without data integrity.
       Further, there is no provision for data confidentiality without
       both data integrity and data origin authentication.


       3.4   Mechanisms

       The mechanisms chosen to support each of the security
       services and goals of the SNMP security protocols are as
       follows.


          o In support of data integrity, the use of the MD4 [3]
           message digest algorithm is chosen. A 128-bit digest is
           calculated over an appropriate portion of a SNMP
           message and included as part of the message sent to the
           recipient.

          o In support of data origin authentication and data
           integrity, the portion of a SNMP message that is

       Galvin, McCloghrie, Davin                            [Page 6]

       INTERNET-DRAFT                               April 1991


           digested is first prefixed with a secret value shared by
           the originator of that message and its intended recipient.

          o To protect against the threat of message reordering, a
           timestamp value is included in each message generated.
           A recipient evaluates the timestamp to determine if the
           message is recent, and it uses the timestamp to
           determine if the message is ordered relative to other
           messages it has received. In conjunction with other
           readily available information (e.g., the request-id), the
           timestamp also indicates whether or not the message is a
           replay of a previous message.

          o In support of data confidentiality, the use of the Data
           Encryption Standard (DES) [4] in the Cipher Block
           Chaining mode of operation [5] is chosen. An
           appropriate portion of the message is encrypted prior to
           being transmitted to its recipient.



       4    SNMP Party


       Recall from [2], a SNMP party can be represented by an
       ASN.1 value with the following syntax.


          SnmpParty ::= SEQUENCE {
            partyIdentity
               OBJECT IDENTIFIER,
            partyTDomain
               OBJECT IDENTIFIER,
            partyTAddr
               OCTET STRING,
            partyProxyFor
               OBJECT IDENTIFIER,
            partyAuthProt
               OBJECT IDENTIFIER,
            partyAuthClock
               TimeTicks,

       Galvin, McCloghrie, Davin                            [Page 7]

       INTERNET-DRAFT                               April 1991


            partyAuthLastMsg
               TimeTicks,
            partyAuthNonce
               INTEGER,
            partyAuthPrivate
               OCTET STRING,
            partyAuthPublic
               OCTET STRING,
            partyAuthLifetime
               INTEGER,
            partyPrivProt
               OBJECT IDENTIFIER,
            partyPrivPrivate
               OCTET STRING,
            partyPrivPublic
               OCTET STRING
          }



       For each SnmpParty value that supports the generation of
       messages using the SNMP MD4 authentication protocol or the
       receipt of messages via the SNMP DES privacy protocol, the
       significance of each of its components is as follows.

          o Its partyIdentity component is called the identity of
           the party and corresponds to the party identity.

          o Its partyTDomain component is called the transport
           domain and indicates the kind of transport service by
           which the party receives network management traffic.
           An example of a transport domain is rfc1157Domain
           (SNMP over UDP).

          o Its partyTAddr component is called the transport
           addressing information and represents a transport
           service address by which the party receives network
           management traffic.

          o Its partyProxyFor component is called the proxied
           party and represents the identity of a second SNMP

       Galvin, McCloghrie, Davin                            [Page 8]

       INTERNET-DRAFT                               April 1991


           party or other management entity with which
           interaction may be necessary to satisfy received
           management requests. In this context, the value
           noProxy signifies that the party responds to received
           management requests by entirely local mechanisms.

          o Its partyAuthProt component is called the
           authentication protocol and identifies a protocol by
           which all messages generated by the party are
           authenticated as to integrity and origin. In this context,
           the value md4AuthProt, defined in [7], signifies that
           messages generated by the party are authenticated using
           the SNMP MD4 authentication protocol.

          o Its partyAuthClock component is called the
           authentication clock and represents a notion of the
           current time that is specific to the party.

          o Its partyAuthLastMsg component is called the
           ratchet and represents a notion of time associated with
           the most recent, authentic protocol message generated
           by the party.

          o Its partyAuthNonce component is called the nonce
           and represents a monotonically increasing integer
           associated with the most recent, authentic protocol
           message generated by the party. The nonce associated
           with a particular message distinguishes it among all
           others transmitted in the same unit TimeTicks interval.

          o Its partyAuthPrivate component is called the private
           authentication key and represents the secret value
           needed to support the authentication protocol. This
           component is a 16 octet value.

          o Its partyAuthPublic component is called the public
           authentication key and represents any public value that
           may be needed to support the authentication protocol.
           This component is not relevant.

          o Its partyAuthLifetime component is called the
           lifetime and represents an administrative upper bound

       Galvin, McCloghrie, Davin                            [Page 9]

       INTERNET-DRAFT                               April 1991


           on acceptable delivery delay for protocol messages
           generated by the party.

          o Its partyPrivProt component is called the privacy
           protocol and identifies a protocol by which all protocol
           messages received by the party are protected from
           disclosure. In this context, the value desPrivProt,
           defined in [7], signifies that messages received by the
           party are protected from disclosure by the SNMP DES
           privacy protocol.

          o Its partyPrivPrivate component is called the private
           privacy key and represents the secret value needed to
           support the privacy protocol. This component is a 16
           octet value, of which the first 8 octets are a DES key
           and the second 8 octets are a DES Initialization Vector.

          o Its partyPrivPublic component is called the public
           privacy key and represents any public value that may be
           needed to support the privacy protocol. This component
           is not relevant.



       5    SNMP MD4 Authentication Protocol


       This section describes the SNMP MD4 authentication
       protocol. It provides both for verifying the integrity of a
       received message (i.e., the message received is the message
       sent) and for verifying the origin of a message (i.e., the
       reliable identification of the originator). The integrity of the
       message is protected by computing a digest over an
       appropriate portion of a message. The digest is computed by
       the originator of the message, transmitted with the message
       and verified by the recipient of the message.

       A secret value known only to the originator and recipient of
       the message is prefixed to the message prior to the digest
       computation. Thus, the origin of the message is known
       implicitly with the verification of the digest.

       Galvin, McCloghrie, Davin                          [Page 10]

       INTERNET-DRAFT                               April 1991


       Recall from [2], a SNMP management communication is
       represented by an ASN.1 value with the following syntax.


          SnmpMgmtCom ::= [1] IMPLICIT SEQUENCE {
            dstParty
               OBJECT IDENTIFIER,
            srcParty
               OBJECT IDENTIFIER,
            pdu   PDUs
          }



       For each SnmpMgmtCom value that represents a SNMP
       management communication, the following statements are
       true:


          o Its dstParty component is called the destination and
           identifies the SNMP party to which the communication
           is directed.

          o Its srcParty component is called the source and
           identifies the SNMP party from which the
           communication is originated.

          o Its pdu component has the form and significance
           attributed to it in [1]


       Recall from [2], a SNMP authenticated management
       communication is represented by an ASN.1 value with the
       following syntax.


          SnmpAuthMsg ::= [1] IMPLICIT SEQUENCE {
            authInfo
               ANY, - defined by authentication protocol
            authData
               SnmpMgmtCom
          }



       Galvin, McCloghrie, Davin                          [Page 11]

       INTERNET-DRAFT                               April 1991


       For each SnmpAuthMsg value that represents a SNMP
       authenticated management communication, the following
       statements are true:

          o Its authInfo component is called the authentication
           information and represents information required in
           support of the authentication protocol used by the
           SNMP party originating the message. The detailed
           significance of the authentication information is specific
           to the authentication protocol in use; it has no effect on
           the application semantics of the communication other
           than its use by the authentication protocol in
           determining whether the communication is authentic or
           not.

          o Its authData component is called the authentication
           data and represents a SNMP management
           communication.

       In support of the SNMP MD4 authentication protocol, an
       authInfo component is of data type AuthInformation. It is
       represented by an ASN.1 value with the following syntax.


          AuthInformation ::= [1] IMPLICIT SEQUENCE {
            authTimestamp
               TimeTicks,
            authNonce
               INTEGER,
            authDigest
               OCTET STRING
          }



       For each AuthInformation value that represents
       authentication information, the following statements are true:

          o Its authTimestamp component is called the
           authentication timestamp and represents the time of the

       Galvin, McCloghrie, Davin                          [Page 12]

       INTERNET-DRAFT                               April 1991


           generation of the message according to the
           partyAuthClock of the SNMP party that originated it.

          o Its authNonce component is called the authentication
           nonce and represents an integer value evaluated
           according to the authTimestamp value. In particular,
           the granularity of the authentication timestamp limits
           the total number of management communications to 100
           per second. The authentication nonce is a monotonically
           increasing sequence number, that is reset for each new
           authentication timestamp value.

          o Its authDigest component is called the authentication
           digest and represents the digest computed over an
           appropriate portion of the message, where the message is
           temporarily prefixed with a secret value for the purposes
           of computing the digest.


       The SNMP MD4 authentication protocol is identified by the
       ASN.1 object identifier value md4AuthProt.


       5.1   Generating a Message


       This section describes the behavior of a SNMP protocol entity
       when it acts as a SNMP party for which the authentication
       protocol is administratively specified as md4AuthProt.
       Insofar as the behavior of a SNMP protocol entity when
       transmitting protocol messages is defined generically in [2],
       only those aspects of that behavior that are specific to the
       SNMP MD4 authentication protocol are described below. In
       particular, this section describes the encapsulation of a SNMP
       management communication into a SNMP authenticated
       management communication.

       According to [2], a SnmpAuthMsg value is constructed
       during Step 3 of generic processing. In particular, it states the
       authInfo component is constructed according to the
       partyAuthProt value of the SNMP party originating the

       Galvin, McCloghrie, Davin                          [Page 13]

       INTERNET-DRAFT                               April 1991


       message. When that value is md4AuthProt, the procedures
       executed by a SNMP protocol entity whenever either a
       management request or a trap notification is to be transmitted
       by a SNMP party are as follows.


         1. The local database is consulted to determine the
           authentication clock, ratchet, nonce and private
           authentication key of the SNMP party originating the
           message.

         2. The authTimestamp component is set to the retrieved
           authentication clock value.

         3. If the ratchet is equal to the authentication clock, the
           nonce is incremented. Otherwise the nonce is set to zero.
           The authNonce component is set to the nonce value.
           In the local database, the originating SNMP party's
           partyAuthNonce is set to the nonce value and the
           originating SNMP party's partyAuthLastMsg is set to
           the authentication clock.

         4. The authentication digest is temporarily set to the
           private authentication key. The SnmpAuthMsg is
           serialized according to the conventions of [6] and [1]. An
           MD4 digest is computed over this octet sequence
           according to [3]. The authDigest component is set to
           the computed digest value.


       As set forth in [2], the SnmpAuthMsg value is then
       encapsulated according to the appropriate privacy protocol
       into a SnmpPrivMsg value. This latter value is then
       serialized and transmitted to the receiving SNMP party.


       5.2   Receiving a Message


       This section describes the behavior of a SNMP protocol entity
       upon receipt of a protocol message from a SNMP party for
       which the authentication protocol is administratively specified

       Galvin, McCloghrie, Davin                          [Page 14]

       INTERNET-DRAFT                               April 1991


       as md4AuthProt. Insofar as the behavior of a SNMP
       protocol entity when receiving protocol messages is defined
       generically in [2], only those aspects of that behavior that are
       specific to the SNMP MD4 authentication protocol are
       described below.

       According to [2], a SnmpAuthMsg value is evaluated during
       Step 9 of generic processing. In particular, it states the
       SnmpAuthMsg is evaluated according to the
       partyAuthProt value of the SNMP party that originated the
       message. When that value is md4AuthProt, the procedures
       executed by a SNMP protocol entity whenever a management
       communication is received by a SNMP party are as follows.


         1. If the authInfo component value is not an
           AuthInformation value, the message is evaluated as
           unauthentic. Otherwise, the value is extracted from the
           SnmpAuthMsg value.

         2. The local database is consulted to determine the
           authentication clock, ratchet, nonce, private
           authentication key and lifetime of the SNMP party that
           originated the message.

         3. If the authTimestamp component plus the lifetime is
           less than the authentication clock, the message is
           evaluated as unauthentic.

         4. If the authTimestamp component is less than the
           ratchet, the message is evaluated as unauthentic.

         5. If the authTimestamp component is equal to the
           ratchet and if the authNonce component is less than or
           equal to the nonce, the message is evaluated as
           unauthentic.

         6. The authDigest component is extracted and
           temporarily recorded.

         7. A new SnmpAuthMsg is constructed such that its
           authDigest component is set to the private

       Galvin, McCloghrie, Davin                          [Page 15]

       INTERNET-DRAFT                               April 1991


           authentication key and its other components are set to
           the value of the corresponding components in the
           received SnmpAuthMsg. This new SnmpAuthMsg
           value is serialized according to the conventions of [6]
           and [1]. An MD4 digest is computed over this octet
           sequence according to [3].

         8. If the computed digest value is not equal to the
           previously recorded digest value, the message is
           evaluated as unauthentic.

         9. If the authTimestamp component exceeds the ratchet,
           in the local database the originating SNMP party's
           partyAuthLastMsg value is set to the
           authTimestamp value and the originating SNMP
           party's partyAuthNonce value is set to zero.

         10. If the authTimestamp component equals the ratchet,
           in the local database the originating SNMP party's
           partyAuthNonce value is set to the authNonce
           component.


       If the SnmpAuthMsg value is evaluated as unauthentic, an
       authentication failure is noted and the received message is
       discarded without further processing. Otherwise, processing of
       the received message continues as specified in [2].



       6    SNMP DES Privacy Protocol


       This section describes the SNMP DES privacy protocol. It
       provides for protection from disclosure of a received message.
       An appropriate portion of the message is encrypted according
       to a secret key known only to the originator and recipient of
       the message.

       The SNMP DES privacy protocol is identified by the ASN.1
       object identifier value desPrivProt.

       Galvin, McCloghrie, Davin                          [Page 16]

       INTERNET-DRAFT                               April 1991


       Recall from [2], a SNMP private management communication
       is represented by an ASN.1 value with the following syntax.

          SnmpPrivMsg ::= [1] IMPLICIT SEQUENCE {
            privDst
               OBJECT IDENTIFIER,
            privData
               [1] IMPLICIT OCTET STRING
          }



       For each SnmpPrivMsg value that represents a SNMP
       private management communication, the following statements
       are true:

          o Its privDst component is called the private destination
           and identifies the SNMP party to which the
           communication is directed.

          o Its privData component is called the private data and
           represents the (possibly encrypted) serialization
           (according to the conventions of [6] and [1]) of a SNMP
           authenticated management communication (according to
           the conventions of the SNMP MD4 authentication
           protocol).


       6.1   Generating a Message

       This section describes the behavior of a SNMP protocol entity
       when it acts as a SNMP party for which the privacy protocol
       is administratively specified as desPrivProt. Insofar as the
       behavior of a SNMP protocol entity when transmitting a
       protocol message is defined generically in [2], only those
       aspects of that behavior that are specific to the SNMP DES
       privacy protocol are described below. In particular, this
       section describes the encapsulation of a SNMP authenticated
       management communication into a SNMP private
       management communication.

       Galvin, McCloghrie, Davin                          [Page 17]

       INTERNET-DRAFT                               April 1991


       According to [2], a SnmpPrivMsg value is constructed
       during Step 5 of generic processing. In particular, it states the
       privdata component is constructed according to the
       partyPrivProt value of the SNMP party receiving the
       message. When that value is desPrivProt, the procedures
       executed by a SNMP protocol entity whenever either a
       management request or a trap notification is to be transmitted
       by a SNMP party are as follows.


         1. If the SnmpAuthMsg is not authenticated according
           to the conventions of md4AuthProt, the generation of
           the SnmpPrivMsg fails according to a local procedure,
           without further processing.

         2. The local database is consulted to determine the private
           privacy key of the SNMP party receiving the message.
           The encryption key and the initialization vector are
           extracted from the private privacy key.

         3. The SnmpAuthMsg is serialized according to the
           conventions of [6] and [1].

         4. The serialized value is encrypted according to the
           DES [4] in the Cipher Block Chaining mode of
           operation [5], using the extracted encryption key and
           initialization vector.

         5. The privData component is set to the encrypted value.


       As set forth in [2], the SnmpPrivMsg value is then serialized
       and transmitted to the receiving SNMP party.


       6.2   Receiving a Message


       This section describes the behavior of a SNMP protocol entity
       when it acts as a SNMP party for which the privacy protocol
       is administratively specified as desPrivProt. Insofar as the
       behavior of a SNMP protocol entity when receiving a protocol

       Galvin, McCloghrie, Davin                          [Page 18]

       INTERNET-DRAFT                               April 1991


       message is defined generically in [2], only those aspects of that
       behavior that are specific to the SNMP DES privacy protocol
       are described below.

       According to [2], a privData component of a received
       SnmpPrivMsg value is evaluated during Step 4 of generic
       processing. In particular, it states the privData component is
       evaluated according to the partyPrivProt value of the
       SNMP party receiving the message. When that value is
       desPrivProt, the procedures executed by a SNMP protocol
       entity whenever a management communication is received by
       a SNMP party are as follows.


         1. The local database is consulted to determine the private
           privacy key of the SNMP party receiving the message.
           The encryption key and the initialization vector are
           extracted from the private privacy key.

         2. The privData component is decrypted according to the
           DES [4] in the Cipher Block Chaining mode of
           operation [5], using the extracted encryption key and
           initialization vector.


       Processing of the received message continues as specified in [2].



       7    Clock and Secret Distribution


       The protocols described in Sections 5 and 6 assume the
       existence of loosely synchronized clocks and secret values.
       Although a variety of strategies may be employed, there are
       three requirements that apply to any strategy employed.


          o If the value of an authentication clock is decreased, the
           ratchet and private authentication key must be changed
           concurrently.
           When the value of an authentication clock is decreased,
           messages that have been sent with a timestamp value

       Galvin, McCloghrie, Davin                          [Page 19]

       INTERNET-DRAFT                               April 1991


           between the value of the authentication clock and its
           new value may be replayed. Changing the private
           authentication key obviates this threat. However,
           changing the authentication clock and the private
           authentication key is not sufficient to ensure proper
           operation. If the ratchet is not reduced similarly to the
           authentication clock, no message will be considered
           authentic until the value of the authentication clock
           exceeds the value of the ratchet.

          o The private authentication key and private privacy key
           must be known only to the parties requiring knowledge
           of them.

           Protecting the secrets from disclosure is critical to the
           security of the protocols. In particular, if the secrets are
           distributed via a network, the secrets must be protected
           with a protocol that supports confidentiality, e.g., the
           SNMP DES privacy protocol. Further, knowledge of the
           secrets must be as restricted as possible within an
           implementation. In particular, although the secrets may
           be known to one or more persons during the initial
           configuration of a device, the secrets should be
           immediately changed such that their actual value is
           known only to the software. A management station has
           the additional responsibility of recovering the state of all
           parties whenever it boots. This may require recording
           the secrets on a long-term storage device. Access to
           information on this device must be as restricted as is
           practically possible.

          o There must exist at least one SNMP protocol entity that
           assumes the role of a responsible management station.

           This management station is responsible for ensuring that
           all authentication clocks are synchronized and for
           changing the secret values when necessary. Although
           more than one management station may participate in
           the responsibility, their coordination is essential to the
           secure management of the network. The mechanism by
           which multiple management stations ensure that no

       Galvin, McCloghrie, Davin                          [Page 20]

       INTERNET-DRAFT                               April 1991


           more than one of them attempts to synchronize the
           clocks or update the secrets at any one time is a local
           implementation issue.


       This section describes one strategy for maintaining loosely
       synchronized clocks and distributing secret values among
       SNMP parties that support the SNMP MD4 authentication
       protocol and the SNMP DES privacy protocol. First, the
       procedures by which a SNMP protocol entity is initially
       configured are specified. Lastly, the procedures by which a
       SNMP protocol entity recovers from a "crash" are specified.


       7.1   Initial Configuration


       This section describes the initial configuration of a SNMP
       protocol entity that supports the SNMP MD4 authentication
       protocol or both the SNMP MD4 authentication protocol and
       the SNMP DES privacy protocol.

       When a network device is first installed, its initial
       configuration must be done manually, i.e., a person must
       physically visit the device and enter the initial values for each
       SNMP party. This suggests the person will have knowledge of
       the initial secret values. This process may be repeated for
       each SNMP party that is added over time.

       In general, however, the security of a system is enhanced as
       the number of entities that know a secret is reduced.
       Requiring a person to physically visit a device every time a
       SNMP party is configured exposes the secrets unnecessarily.
       In particular, the initial authentication secret is 128 bits long,
       plus 64 bits each for the initial DES key and initialization
       vector. Clearly these values will need to be recorded on a
       medium in order to be transported between a responsible
       management station and a managed agent. Alternatively, a
       small set of SNMP parties may be configured for each SNMP
       protocol entity, one pair of which may be used to initially
       configure all other SNMP parties.

       Galvin, McCloghrie, Davin                          [Page 21]

       INTERNET-DRAFT                               April 1991


       In fact, there is a minimal, useful set of SNMP parties that
       could be configured between each responsible management
       station and managed agent. This minimal set includes one of
       each of the following for both the responsible management
       station and the managed agent.


          o a SNMP party identity with its partyAuthProt and
           partyPrivProt set to noAuth and noPriv,
           respectively

          o a SNMP party identity with its partyAuthProt and
           partyPrivProt set to md4AuthProt and noPriv,
           respectively

          o a SNMP party identity with its partyAuthProt and
           partyPrivProt set to md4AuthProt and
           desPrivProt, respectively


       The last of these SNMP parties in both the responsible
       management station and the managed agent could be used to
       configure all other SNMP parties. It is the only suitable
       identity for this purpose, since it is the only identity that
       supports data confidentiality. Data confidentiality is necessary
       in order to protect the distributed secrets from disclosure to
       unauthorized entities.

       Configuring one pair of SNMP parties to be used to configure
       all other parties has the advantage of only exposing one pair
       of secrets, the secrets used to configure the minimal, useful set
       identified above. To limit this exposure, a management
       station should change these values as its first operation upon
       completion of the initial configuration. In this way, secrets are
       known only to the peers requiring knowledge of them in order
       to communicate.

       The Management Information Base (MIB) document
       supporting these security protocols specifies 6 initial party
       identities and initial values, which, by convention, are assigned
       to the parties and their associated parameters. [7]

       Galvin, McCloghrie, Davin                          [Page 22]

       INTERNET-DRAFT                               April 1991


       All 6 parties should be configured in each new managed agent
       and its responsible management station. The responsible
       management station should be configured before the managed
       agent, since the management station can be used to generate
       the initial secrets and provide them to a person, on a suitable
       medium, for distribution to the managed agent. The following
       sequence of steps specifies how to initially configure a
       managed agent and its responsible management station upon
       its installation.


         1. Determine the initial values for each of the components
           of the SNMP party to be configured. Some of these
           values may be computed by the responsible management
           station, some may be specified in the MIB document
           and some may be administratively determined.

         2. Configure the parties in the responsible management
           station, according to the set of initial values. If the
           management station is computing some initial values to
           be entered into the agent, an appropriate medium must
           be present to record the values.

         3. Configure the parties in the managed agent, according to
           the set of initial values.

         4. The responsible management station must synchronize
           the authentication clock values for each party it shares
           with the managed agent. The following sequence of
           events specifies how this should be done.

            (a) The responsible management station must retrieve
               the authentication clocks for each party to be
               reconfigured. This must be an unauthenticated
               request, since the management station does not
               know if the clocks are synchronized.

            (b) The values received must be used to again retrieve
               the authentication clocks for each party to be
               reconfigured. This must be an authenticated
               request, so the actual values can be verified.

       Galvin, McCloghrie, Davin                          [Page 23]

       INTERNET-DRAFT                               April 1991


            (c) The values received must be used to determine an
               appropriate value for each of the authentication
               clocks. These new values must be distributed to the
               appropriate set of parties in order to synchronize
               the clocks, using an authenticated message.

         5. The responsible management station should change the
           secret values just configured to ensure the actual values
           are known only to the peers requiring knowledge of them
           in order to communicate. To do this, a management
           station generates new secrets for each party to be
           reconfigured and distributes those secrets using a
           protocol that protects them from disclosure, e.g.,
           desPrivProt. (see Section 7.3)

       If the managed agent does not support a protocol that
       protects messages from disclosure, then automatic
       maintenance and configuration of parties is not possible, i.e.,
       the last step above is not possible. The secrets can only be
       changed by a physical visit to the device.

       If there are other SNMP protocol entities requiring knowledge
       of the secrets, the responsible management station must
       distribute the information upon completion of the initial
       configuration. The mechanism used must protect the secrets
       from disclosure to unauthorized entities, e.g., the SNMP DES
       privacy protocol is an acceptable mechanism.


       7.2   Clock Distribution

       A responsible management station must ensure the
       authentication clock value for a particular SNMP party is
       loosely synchronized among all the local databases in which it
       appears. The skew among the clock values must be accounted
       for in the lifetime value, in addition to the expected
       communication delivery delay.

       The detection of a skewed authentication clock may be
       identified by a number of strategies, including knowledge of

       Galvin, McCloghrie, Davin                          [Page 24]

       INTERNET-DRAFT                               April 1991


       the accuracy of the system clock, unauthenticated queries of
       the local database and recognition of authentication failures
       originated by the party.

       The sequence of steps by which a responsible management
       station changes the authentication clock for a particular
       SNMP party is similar to that used to change a secret value.
       (see Section 7.3) However, since the clock value need not be
       protected from disclosure, it is not necessary for the
       destination to support a privacy protocol to distribute clock
       values.

       If the authentication clock for a particular SNMP party ever
       reaches the maximal TimeTicks value,(The value of interest
       may be TimeTicks less lifetime. When authenticating a
       message, its authentication timestamp is added to lifetime and
       compared to the authentication clock. A SNMP protocol
       entity must guarantee that the sum is never greater than the
       maximum TimeTicks value.) the clock must halt at that
       value and the lifetime value must be set to zero. In this state,
       the only authenticated request a managed agent should
       process for this party is one that alters the value of at least its
       authentication clock, private authentication key, ratchet,
       nonce and lifetime. In order to reset these values, the
       responsible management station must set the authentication
       timestamp in the message to the maximum TimeTicks value.
       The nonce value is used to distinguish multiple messages.

       If the value of the authentication clock for a particular SNMP
       party is ever altered such that its new value is less than its old
       value, its ratchet and private authentication key must be
       altered at the same time.



       7.3   Secret Distribution


       This section describes one strategy by which a SNMP protocol
       entity that supports both the SNMP MD4 authentication
       protocol and the SNMP DES privacy protocol can change the

       Galvin, McCloghrie, Davin                          [Page 25]

       INTERNET-DRAFT                               April 1991


       secrets for a particular SNMP party.

       The frequency with which the secrets of a SNMP party should
       be changed is a local administrative issue. However, the more
       frequently a secret is used, the more frequently it should be
       changed. At a minimum, the secrets must be changed at least
       every maximum TimeTicks value.

       The following sequence of steps specifies how a responsible
       management station changes a secret value for a particular
       SNMP party, i.e., how to change the private authentication
       key or the private privacy key.

         1. The responsible management station generates a new
           secret value.

         2. The responsible management station encapsulates a
           SNMP Set request in a SNMP private management
           communication with at least the following properties.

             o Its source supports the SNMP MD4 authentication
               protocol.
             o Its destination supports the SNMP DES privacy
               protocol.

         3. The SNMP private management communication is
           transmitted to its destination.

         4. Upon receiving the request, the recipient processes the
           message according to [1] and [2].

         5. The recipient encapsulates a SNMP Set response in a
           SNMP private management communication with at least
           the following properties.

             o Its source supports the SNMP MD4 authentication
               protocol.
             o Its destination supports the SNMP DES privacy
               protocol.

         6. The SNMP private management communication is
           transmitted to its destination.

       Galvin, McCloghrie, Davin                          [Page 26]

       INTERNET-DRAFT                               April 1991


         7. Upon receiving the response, the responsible
           management station updates its local database with the
           new value.


       If the responsible management station does not receive a
       response to its request, there are two possible causes.


          o The request may not have been delivered to the
           destination.

          o The response may not have been delivered to the
           originator of the request.


       In order to distinguish the two possible error conditions, a
       responsible management station should check the destination
       to see if the change has occurred. Unfortunately, since the
       secret values are unreadable, this is not possible.

       One alternative is to set the public value corresponding to the
       secret being changed to a recognizable, novel value, i.e., set
       partyAuthPublic when changing partyAuthPrivate, or
       set partyPrivPublic when changing partyPrivPrivate. In
       this way, the responsible management station may retrieve the
       public value when a response is not received, and verify if the
       change has taken place.

       One other scenario worthy of mention is using a SNMP party
       to change its own secrets. In this case, the destination will
       change its local database prior to generating a response. Thus,
       the response will be constructed according to the new value.
       However, the responsible management station will not update
       its local database until after the response is received. This
       suggests the responsible management station will actually
       receive a response which will be evaluated as unauthentic.
       The responsible management station may either account for
       this scenario as a special case, or use the mechanism described
       above to verify if the change has taken place, i.e., setting the
       public value to a recognizable, novel value when changing a
       secret value.

       Galvin, McCloghrie, Davin                          [Page 27]

       INTERNET-DRAFT                               April 1991


       7.4   Crash Recovery


       The authentication clock of a SNMP party is a critical
       component of the overall security of the protocols. The
       inclusion of a reliable representation of a clock in a SNMP
       protocol entity enhances the overall security. A reliable clock
       representation continues to increase according to the passage
       of time, even when the local SNMP protocol entity -- due to
       power loss or other system failure -- may not be operating.
       An example of a reliable clock representation is that provided
       by battery-powered clock-calendar devices incorporated into
       some contemporary systems.

       If a managed agent crashes and does not reboot in time for its
       responsible management station to prevent its authentication
       clock from reaching its maximum value, upon reboot the clock
       should be halted at its maximal value. The procedures
       specified in Section 7.2 would then apply.

       If a managed network element supports a reliable clock
       representation,(It is assumed that management stations will
       always support reliable clock representations, where a person
       present during the recovery setting the clock is considered a
       reliable representation.) recovering from a crash requires no
       special actions. For each SNMP party in the local database
       for such a SNMP protocol entity, its identity, authentication
       clock, private authentication key and private privacy key must
       enjoy non-volatile, incorruptible representations. If possible,
       lifetime should also enjoy a non-volatile, incorruptible
       representation. Upon reboot, the remaining elements of each
       SNMP party are set as follows.(It is assumed the only security
       protocols are the two specified in this memo. Should there
       exist other security protocols, the authentication protocol and
       the privacy protocol would also require non-volatile,
       incorruptible representations.)


          o If the private authentication key is not noAuth, the
           authentication protocol is set to md4AuthProt.

       Galvin, McCloghrie, Davin                          [Page 28]

       INTERNET-DRAFT                               April 1991


          o The ratchet is initialized to the value of the
           authentication clock.

          o The nonce is initialized to zero.

          o If the lifetime is not retained, it should be initialized to
           zero.

          o If the private privacy key is not noPriv, the privacy
           protocol is set to desPrivProt.


       Upon detecting that a managed agent has rebooted, a
       responsible management station must reset all other values,
       and the lifetime if it was not retained. In order to reset the
       lifetime, the responsible management station must set the
       authentication timestamp in the message to the sum of the
       authentication clock and lifetime. This is an artificial
       advancement of the authentication timestamp in order to
       guarantee the message will be authentic when received by the
       recipient.

       If, however, a managed network element does not support a
       reliable clock representation, the following set of procedures
       apply to all SNMP protocol entities residing at that element.
       For each SNMP party in the local database for a SNMP
       protocol entity, its identity, private authentication key and
       private privacy key must enjoy non-volatile, incorruptible
       representations. Upon reboot, the remaining elements of each
       SNMP party are set as follows.


          o If the private authentication key is not noAuth, the
           authentication protocol is set to md4AuthProt.

          o The authentication clock is initialized to the maximum
           TimeTicks value.

          o The ratchet is initialized to the maximum TimeTicks
           value.

          o The nonce is initialized to zero.

       Galvin, McCloghrie, Davin                          [Page 29]

       INTERNET-DRAFT                               April 1991


          o The lifetime is initialized to zero.

          o If the private privacy key is not noPriv, the privacy
           protocol is set to desPrivProt.


       In this state, the only authenticated request a managed agent
       should process for this party is one that alters the value of at
       least its authentication clock, private authentication key,
       ratchet, nonce and lifetime. In order to reset these values, the
       responsible management station must set the authentication
       timestamp in the message to the maximum TimeTicks value.
       The nonce value is used to distinguish multiple messages.



       8    Security Considerations


       To address the possibility of message duplication (malicious or
       otherwise), a management station should discard SNMP
       responses for which neither the request-id component nor
       the represented management information corresponds to any
       currently outstanding request.

       Owing to the possible loss or suppression of authentication
       failure traps, due to authentication clock skew or inconsistent
       notions of shared secrets, a management station should not
       interpret an agent's lack of response to an authenticated
       SNMP management communication as a conclusive indication
       of agent or network failure. In order either to facilitate
       administration of a SNMP party for which clock
       synchronization may be lapsed or to provide for continued
       management in times of network stress, a management station
       implementation may provide for arbitrary, artificial
       advancement of the timestamp on locally generated messages.

       The security of a SNMP party based upon the SNMP MD4
       authentication protocol depends upon the magnitude of its
       lifetime: a large lifetime increases the vulnerability to replay
       attacks. Thus, the lifetime for a party must be chosen (by the
       local administration) to be as small as possible, given the

       Galvin, McCloghrie, Davin                          [Page 30]

       INTERNET-DRAFT                               April 1991


       accuracy of clock devices available, relevant round-trip
       communications delays and the frequency with which a
       responsible management station will be able to verify all clock
       values. The implementation of a management station may,
       when explicitly authorized, provide for dynamic adjustment of
       the lifetime in order to accommodate changing network
       conditions.


       8.1   Conformance

       A SNMP protocol entity implementation that claims
       conformance to this memo satisfies the following requirements:

         1. For each SNMP party about which it maintains
           information in a local database, it must, to the maximal
           extent possible, prohibit read-access to the private
           authentication key and private encryption key under all
           circumstances except as required to generate and/or
           validate SNMP messages with respect to that party.
           This prohibition includes prevention of read-access by
           the agent's human operators.

         2. In the event that it loses knowledge of a party's
           parameters, (in particular, the private authentication
           key, private encryption key, authentication clock, or
           ratchet) it must alter its record of these quantities to
           random values, so subsequent interaction with that
           party requires manual redistribution of new secrets and
           other parameters.

         3. For each SNMP party about which it maintains
           information in a local database, it must prohibit
           alterations to its record of the authentication clock for
           that party independently of alterations to its record of
           the private authentication key (unless the clock
           alteration is an advancement).

         4. If it selects new value(s) for a party's secret(s), it must
           avoid bad or obvious choices for said secret(s). Choices

       Galvin, McCloghrie, Davin                          [Page 31]

       INTERNET-DRAFT                               April 1991


           to be avoided are boundary values (such as all-zeros),
           and predictable values (such as the same value as
           previously, or selecting from a predetermined set).

         5. For each SNMP party about which it maintains
           information in a local database, it must never increase
           its record of the lifetime for that party except as may be
           explicitly authorized (via imperative command or
           securely represented configuration information) by the
           responsible network administrator.

         6. For each SNMP party about which it maintains
           information in a local database, it must never allow its
           record of the authentication clock for that party to be
           incremented beyond the maximal TimeTicks value and
           so "roll-over" to zero.


       8.2   Protocol Correctness

       The correctness of these SNMP security protocols with respect
       to the stated goals depends on the following assumptions:

         1. The MD4 message digest algorithm satisfies its design
           criteria.(In particular, it must be computationally
           infeasible to discover two messages that share the same
           digest value.)

         2. The DES cryptographic algorithm satisfies its design
           criteria.(In particular, it must be computationally
           infeasible to determine the cleartext message from the
           ciphertext message without knowledge of the DES key
           used in the transformation.)

         3. Local notions of a party's authentication clock while it is
           associated with a specific key value are monotonically
           non-decreasing (i.e., they never run backwards) in the
           absence of administrative manipulations.

         4. The secrets for a particular SNMP party are known only
           to authorized SNMP protocol entities.

       Galvin, McCloghrie, Davin                          [Page 32]

       INTERNET-DRAFT                               April 1991


         5. Local notions of the authentication clock for a particular
           SNMP party are never altered (except for advancements)
           without also altering the private authentication key.


       For each mechanism of the protocol, an informal account of its
       contribution to the required goals is presented below.


       8.2.1   Clock Monotonicity Mechanism

       By pairing each sequence of a clock's values with a unique key,
       the protocols partially realize goals 3 and 4, and the
       conjunction of this property with assumption 1 above is
       sufficient for the claim that all local notions of a party's
       authentication clock are, in general, non-decreasing with time.


       8.2.2   Data Integrity Mechanism

       The protocols require computation of the MD4 message digest
       computed over the SNMP message prepended by the secret
       for the relevant party. By virtue of this mechanism and
       assumptions 1 and 4, the protocols realize goal 1.

       Normally, the inclusion of the message digest value with the
       digested message would not be sufficient to guarantee data
       integrity, since the digest value can be modified in addition to
       the message while it is enroute. However, since not all of the
       digested message is included in the transmission to the
       destination, it is not possible to substitute both a message and
       a digest value while enroute to a destination.


       8.2.3   Data Origin Authentication Mechanism

       The data integrity mechanism requires the use of a secret
       value known only to communicating parties. By virtue of this
       mechanism and assumptions 1 and 4, the protocols explicitly
       prevent unauthorized modification of messages. Data origin

       Galvin, McCloghrie, Davin                          [Page 33]

       INTERNET-DRAFT                               April 1991


       authentication is implicit if the message digest value can be
       verified. That is, the protocols realize goal 2.


       8.2.4   Restricted Administration Mechanism

       This memo requires that implementations preclude
       administrative alterations of the authentication clock for a
       particular party independently from its private authentication
       key (unless that clock alteration is an advancement). An
       example of an efficient implementation of this restriction is
       provided in a pseudocode fragment below. This pseudocode
       fragment meets the requirements of assumption 5.

       Pseudocode Fragment. Observe that the requirement is not for
       simultaneous alteration but to preclude independent
       alteration. This latter requirement is fairly easily realized in a
       way that is consistent with the defined semantics of the
       SNMP Set operation. Although alteration in a single request
       is clearly more efficient -- and less complicated in the face of
       agent failures -- than alteration in multiple requests, security
       requirements are satisfied by either strategy so long as the
       logical dependency between the clock and the secret is assured.


       Void          partySetKey (party, newKeyValue)

       -
           if (party->clockAltered) -
              party->clockAltered = FALSE;
              party->keyAltered = FALSE;
              party->keyInUse = newKeyValue;
              party->clockInUse = party->clockCache;
           }
           else -
              party->keyAltered = TRUE;
              party->keyCache = newKeyValue;
           }
       }



       Galvin, McCloghrie, Davin                          [Page 34]

       INTERNET-DRAFT                               April 1991


       Void          partySetClock (party, newClockValue)

       -
           if (party->keyAltered) -
              party->keyAltered = FALSE;
              party->clockAltered = FALSE;
              party->clockInUse = newClockValue;
              party->keyInUse = party->keyCache;
           }
           else -
              party->clockAltered = TRUE;
              party->clockCache = newClockValue;
           }
       }


       8.2.5   Ordered Delivery Mechanism

       The definition of the SNMP security protocol requires that, if
       the timestamp value on a received message does not exceed
       the timestamp of the most recent validated message locally
       delivered from the originating party, then that message is not
       delivered. Otherwise, the record of the timestamp for the
       most recent locally delivered validated message is updated.


       if (msgIsValidated) -
           if (timestampOfReceivedMsg >
              party->timestampOfLastDeliveredMsg) -
              party->timestampOfLastDeliveredMsg =
                 timestampOfReceivedMsg;
           }
           else -
              msgIsValidated = FALSE;
           }
       }


       Although not explicitly represented in the pseudocode above,
       in the SNMP MD4 authentication protocol, the ordered

       Galvin, McCloghrie, Davin                          [Page 35]

       INTERNET-DRAFT                               April 1991


       delivery mechanism must ensure that, when the
       authentication timestamp of the received message is equal to
       the ratchet, received messages continue to be delivered as long
       as their nonce values are monotonically increasing. By virtue
       of this mechanism, the protocols realize goal 4.


       8.2.6   Message Timeliness Mechanism

       The definition of the SNMP security protocols requires that, if
       the authentication timestamp value on a received message --
       augmented by an administratively chosen lifetime value -- is
       less than the local notion of the clock for the originating
       SNMP party, the message is not delivered.


       if (timestampOfReceivedMsg +
              party->administrativeLifetime <=
              party->localNotionOfClock) -
              msgIsValidated = FALSE;
       }


       By virtue of this mechanism, the protocols realize goal 3. In
       cases in which the local notions of a particular SNMP party
       clock are moderately well-synchronized, the timeliness
       mechanism effectively limits the age of validly delivered
       messages. Thus, if an attacker diverts all validated messages
       for replay much later, the delay introduced by this attack is
       limited to a period that is proportional to the skew among
       local notions of the party clock.


       8.2.7   Confidentiality Mechanism

       The protocols require the use of the DES when the data
       confidentiality service is required. By virtue of this mechanism
       and assumption 2, the protocols realize goal 5.




       Galvin, McCloghrie, Davin                          [Page 36]

       INTERNET-DRAFT                               April 1991


       References

       [1] Jeffrey D. Case, Mark S. Fedor, Martin L. Schoffstall, and
          James R. Davin. A Simple Network Management Protocol
          (SNMP). RFC 1157, DDN Network Information Center,
          SRI International, May 1990. Obsoletes RFC1098.

       [2] SNMP administrative model. In preparation., March 1991.

       [3] Ronald L. Rivest. The md4 message digest algorithm.
          RFC 1186, DDN Network Information Center, SRI
          International, October 1990.

       [4] FIPS Publication 46-1. Data Encryption Standard.
          National Institute of Standards and Technology, U. S.
          Department of Commerce, Washington, D.C., January
          1977. Federal Information Processing Standard (FIPS).

       [5] FIPS Publication 81. DES Modes of Operation. National
          Institute of Standards and Technology, U. S. Department
          of Commerce, Washington, D.C., December 1980. Federal
          Information Processing Standard (FIPS).

       [6] Information Processing -- Open Systems Interconnection
          -- Specification of Basic Encoding Rules for Abstract
          Syntax Notation One (ASN.1). International Organization
          for Standardization/International Electrotechnical
          Institute, 1987. International Standard 8825.

       [7] Keith McCloghrie, James R. Davin, and James M. Galvin.
          Experimental Definitions of Managed Objects for
          Administration of SNMP Parties. RFC DRAFT, DDN
          Network Information Center, SRI International, 1991.
          Working Draft.









       Galvin, McCloghrie, Davin                          [Page 37]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/