rfc2264.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   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)
              )




Blumenthal & Wijnen         Standards Track                    [Page 11]

RFC 2264                     USM for SNMPv3                 January 1998


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.

   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.








Blumenthal & Wijnen         Standards Track                    [Page 12]

RFC 2264                     USM for SNMPv3                 January 1998


   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.

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



Blumenthal & Wijnen         Standards Track                    [Page 13]

RFC 2264                     USM for SNMPv3                 January 1998


   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 [RFC2261]).

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.

   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



Blumenthal & Wijnen         Standards Track                    [Page 14]

RFC 2264                     USM for SNMPv3                 January 1998


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





Blumenthal & Wijnen         Standards Track                    [Page 15]

RFC 2264                     USM for SNMPv3                 January 1998


   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 [RFC2262]).

   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(1..32)),
           -- authentication protocol specific parameters
              msgAuthenticationParameters  OCTET STRING,
           -- privacy protocol specific parameters
              msgPrivacyParameters         OCTET STRING
          }
   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.