rfc3414.txt

开发snmp的开发包有两个开放的SNMP开发库

Blumenthal & Wijnen         Standards Track                    [Page 11]

RFC 3414                     USM for SNMPv3                December 2002


1.6.2. User-based Security Model Primitives for Privacy

   The User-based Security Model provides the following internal
   primitives to pass data back and forth between the Security Model
   itself and the privacy service:

   statusInformation =
     encryptData(
     IN    encryptKey               -- secret key for encryption
     IN    dataToEncrypt            -- data to encrypt (scopedPDU)
     OUT   encryptedData            -- encrypted data (encryptedPDU)
     OUT   privParameters           -- filled in by service provider
           )

   statusInformation =
     decryptData(
     IN    decryptKey               -- secret key for decrypting
     IN    privParameters           -- as received on the wire
     IN    encryptedData            -- encrypted data (encryptedPDU)
     OUT   decryptedData            -- decrypted data (scopedPDU)
           )

2. Elements of the Model

   This section contains definitions required to realize the security
   model defined by this memo.

2.1. User-based Security Model Users

   Management operations using this Security Model make use of a defined
   set of user identities.  For any user on whose behalf management
   operations are authorized at a particular SNMP engine, that SNMP
   engine must have knowledge of that user.  An SNMP engine that wishes
   to communicate with another SNMP engine must also have knowledge of a
   user known to that engine, including knowledge of the applicable
   attributes of that user.

   A user and its attributes are defined as follows:

   userName
      A string representing the name of the user.

   securityName
      A human-readable string representing the user in a format that is
      Security Model independent.  There is a one-to-one relationship
      between userName and securityName.





Blumenthal & Wijnen         Standards Track                    [Page 12]

RFC 3414                     USM for SNMPv3                December 2002


   authProtocol
      An indication of whether messages sent on behalf of this user can
      be authenticated, and if so, the type of authentication protocol
      which is used.  Two such protocols are defined in this memo:

      - the HMAC-MD5-96 authentication protocol.
      - the HMAC-SHA-96 authentication protocol.

   authKey
      If messages sent on behalf of this user can be authenticated, the
      (private) authentication key for use with the authentication
      protocol.  Note that a user's authentication key will normally be
      different at different authoritative SNMP engines.  The authKey is
      not accessible via SNMP.  The length requirements of the authKey
      are defined by the authProtocol in use.

   authKeyChange and authOwnKeyChange
      The only way to remotely update the authentication key.  Does that
      in a secure manner, so that the update can be completed without
      the need to employ privacy protection.

   privProtocol
      An indication of whether messages sent on behalf of this user can
      be protected from disclosure, and if so, the type of privacy
      protocol which is used.  One such protocol is defined in this
      memo:  the CBC-DES Symmetric Encryption Protocol.

   privKey
      If messages sent on behalf of this user can be en/decrypted, the
      (private) privacy key for use with the privacy protocol.  Note
      that a user's privacy key will normally be different at different
      authoritative SNMP engines.  The privKey is not accessible via
      SNMP.  The length requirements of the privKey are defined by the
      privProtocol in use.

   privKeyChange and privOwnKeyChange
      The only way to remotely update the encryption key.  Does that in
      a secure manner, so that the update can be completed without the
      need to employ privacy protection.

2.2. Replay Protection

   Each SNMP engine maintains three objects:

   - snmpEngineID, which (at least within an administrative domain)
     uniquely and unambiguously identifies an SNMP engine.





Blumenthal & Wijnen         Standards Track                    [Page 13]

RFC 3414                     USM for SNMPv3                December 2002


   - snmpEngineBoots, which is a count of the number of times the SNMP
     engine has re-booted/re-initialized since snmpEngineID was last
     configured; and,

   - snmpEngineTime, which is the number of seconds since the
     snmpEngineBoots counter was last incremented.

   Each SNMP engine is always authoritative with respect to these
   objects in its own SNMP entity.  It is the responsibility of a non-
   authoritative SNMP engine to synchronize with the authoritative SNMP
   engine, as appropriate.

   An authoritative SNMP engine is required to maintain the values of
   its snmpEngineID and snmpEngineBoots in non-volatile storage.

2.2.1. msgAuthoritativeEngineID

   The msgAuthoritativeEngineID value contained in an authenticated
   message is used to defeat attacks in which messages from one SNMP
   engine to another SNMP engine are replayed to a different SNMP
   engine.  It represents the snmpEngineID at the authoritative SNMP
   engine involved in the exchange of the message.

   When an authoritative SNMP engine is first installed, it sets its
   local value of snmpEngineID according to a enterprise-specific
   algorithm (see the definition of the Textual Convention for
   SnmpEngineID in the SNMP Architecture document [RFC3411]).

2.2.2. msgAuthoritativeEngineBoots and msgAuthoritativeEngineTime

   The msgAuthoritativeEngineBoots and msgAuthoritativeEngineTime values
   contained in an authenticated message are used to defeat attacks in
   which messages are replayed when they are no longer valid.  They
   represent the snmpEngineBoots and snmpEngineTime values at the
   authoritative SNMP engine involved in the exchange of the message.

   Through use of snmpEngineBoots and snmpEngineTime, there is no
   requirement for an SNMP engine to have a non-volatile clock which
   ticks (i.e., increases with the passage of time) even when the
   SNMP engine is powered off.  Rather, each time an SNMP engine
   re-boots, it retrieves, increments, and then stores snmpEngineBoots
   in non-volatile storage, and resets snmpEngineTime to zero.

   When an SNMP engine is first installed, it sets its local values of
   snmpEngineBoots and snmpEngineTime to zero.  If snmpEngineTime ever
   reaches its maximum value (2147483647), then snmpEngineBoots is
   incremented as if the SNMP engine has re-booted and snmpEngineTime is
   reset to zero and starts incrementing again.



Blumenthal & Wijnen         Standards Track                    [Page 14]

RFC 3414                     USM for SNMPv3                December 2002


   Each time an authoritative SNMP engine re-boots, any SNMP engines
   holding that authoritative SNMP engine's values of snmpEngineBoots
   and snmpEngineTime need to re-synchronize prior to sending correctly
   authenticated messages to that authoritative SNMP engine (see Section
   2.3 for (re-)synchronization procedures).  Note, however, that the
   procedures do provide for a notification to be accepted as authentic
   by a receiving SNMP engine, when sent by an authoritative SNMP engine
   which has re-booted since the receiving SNMP engine last (re-
   )synchronized.


   If an authoritative SNMP engine is ever unable to determine its
   latest snmpEngineBoots value, then it must set its snmpEngineBoots
   value to 2147483647.

   Whenever the local value of snmpEngineBoots has the value 2147483647
   it latches at that value and an authenticated message always causes
   an notInTimeWindow authentication failure.

   In order to reset an SNMP engine whose snmpEngineBoots value has
   reached the value 2147483647, manual intervention is required.  The
   engine must be physically visited and re-configured, either with a
   new snmpEngineID value, or with new secret values for the
   authentication and privacy protocols of all users known to that SNMP
   engine.  Note that even if an SNMP engine re-boots once a second that
   it would still take approximately 68 years before the max value of
   2147483647 would be reached.

2.2.3. Time Window

   The Time Window is a value that specifies the window of time in which
   a message generated on behalf of any user is valid.  This memo
   specifies that the same value of the Time Window, 150 seconds, is
   used for all users.

2.3. Time Synchronization

   Time synchronization, required by a non-authoritative SNMP engine
   in order to proceed with authentic communications, has occurred
   when the non-authoritative SNMP engine has obtained a local notion
   of the authoritative SNMP engine's values of snmpEngineBoots and
   snmpEngineTime from the authoritative SNMP engine.  These values
   must be (and remain) within the authoritative SNMP engine's Time
   Window.  So the local notion of the authoritative SNMP engine's
   values must be kept loosely synchronized with the values stored
   at the authoritative SNMP engine.  In addition to keeping a local
   copy of snmpEngineBoots and snmpEngineTime from the authoritative
   SNMP engine, a non-authoritative SNMP engine must also keep one



Blumenthal & Wijnen         Standards Track                    [Page 15]

RFC 3414                     USM for SNMPv3                December 2002


   local variable, latestReceivedEngineTime.  This value records the
   highest value of snmpEngineTime that was received by the
   non-authoritative SNMP engine from the authoritative SNMP engine
   and is used to eliminate the possibility of replaying messages
   that would prevent the non-authoritative SNMP engine's notion of
   the snmpEngineTime from advancing.

   A non-authoritative SNMP engine must keep local notions of these
   values (snmpEngineBoots, snmpEngineTime and latestReceivedEngineTime)
   for each authoritative SNMP engine with which it wishes to
   communicate.  Since each authoritative SNMP engine is uniquely and
   unambiguously identified by its value of snmpEngineID, the
   non-authoritative SNMP engine may use this value as a key in order to
   cache its local notions of these values.

   Time synchronization occurs as part of the procedures of receiving an
   SNMP message (Section 3.2, step 7b).  As such, no explicit time
   synchronization procedure is required by a non-authoritative SNMP
   engine.  Note, that whenever the local value of snmpEngineID is
   changed (e.g., through discovery) or when secure communications are
   first established with an authoritative SNMP engine, the local values
   of snmpEngineBoots and latestReceivedEngineTime should be set to
   zero.  This will cause the time synchronization to occur when the
   next authentic message is received.

2.4. SNMP Messages Using this Security Model

   The syntax of an SNMP message using this Security Model adheres to
   the message format defined in the version-specific Message Processing
   Model document (for example [RFC3412]).

   The field msgSecurityParameters in SNMPv3 messages has a data type of
   OCTET STRING.  Its value is the BER serialization of the following
   ASN.1 sequence:

   USMSecurityParametersSyntax DEFINITIONS IMPLICIT TAGS ::= BEGIN

      UsmSecurityParameters ::=
          SEQUENCE {
           -- global User-based security parameters
              msgAuthoritativeEngineID     OCTET STRING,
              msgAuthoritativeEngineBoots  INTEGER (0..2147483647),
              msgAuthoritativeEngineTime   INTEGER (0..2147483647),
              msgUserName                  OCTET STRING (SIZE(0..32)),
           -- authentication protocol specific parameters
              msgAuthenticationParameters  OCTET STRING,
           -- privacy protocol specific parameters
              msgPrivacyParameters         OCTET STRING



Blumenthal & Wijnen         Standards Track                    [Page 16]

RFC 3414                     USM for SNMPv3                December 2002


          }
   END

   The fields of this sequence are:

   - The msgAuthoritativeEngineID specifies the snmpEngineID of the
     authoritative SNMP engine involved in the exchange of the message.

   - The msgAuthoritativeEngineBoots specifies the snmpEngineBoots value
     at the authoritative SNMP engine involved in the exchange of the
     message.

   - The msgAuthoritativeEngineTime specifies the snmpEngineTime value
     at the authoritative SNMP engine involved in the exchange of the
     message.

   - The msgUserName specifies the user (principal) on whose behalf the
     message is being exchanged.  Note that a zero-length userName will
     not match any user, but it can be used for snmpEngineID discovery.