rfc1910.txt

来自「<VC++网络游戏建摸与实现>源代码」· 文本 代码 · 共 1,516 行 · 第 1/5 页

     message is at least as recent as the last message it received from
     the same source.  An SNMPv2 manager uses received authentic
     messages to advance its notion of time (at the agent).  An  SNMPv2
     manager also evaluates the request-id in received Response messages
     and discards messages which do not correspond to outstanding
     requests.

     These mechanisms provide for the detection of messages whose time
     of generation was not recent in all but one circumstance; this
     circumstance is the delay or replay of a Report  message (sent to a
     manager) when the manager has has not recently communicated with
     the source of the Report message.  In this circumstance, the
     detection guarantees only that the Report message is more recent
     than the last communication between source and destination of the
     Report message.  However, Report messages do not request or contain
     management information, and thus, goal #3 in Section 1.2 above is
     met; further, Report messages can at most cause the manager to
     advance its notion of time (at the agent) by less than the proper
     amount.

     This protection against the threat of message delay or replay does
     not imply nor provide any protection against unauthorized deletion
     or suppression of messages.  Other mechanisms defined independently
     of the security protocol can also be used to detect the re-
     ordering, replay, deletion, or suppression of messages containing
     set operations (e.g., the MIB variable snmpSetSerialNo [15]).

  -  In support of data confidentiality, an encryption algorithm is
     required.  An appropriate portion of the message is encrypted prior
     to being transmitted.



Waters                        Experimental                      [Page 6]

RFC 1910          User-based Security Model for SNMPv2     February 1996


1.4.1.  Digest Authentication Protocol

   The Digest Authentication Protocol defined in this memo provides for:

  -  verifying the integrity of a received message (i.e., the message
     received is the message sent).

     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.

  -  verifying the user on whose behalf the message was generated.

     A secret value known only to SNMPv2 entities authorized to generate
     messages on behalf of this user is both inserted into, and appended
     to, the message prior to the digest computation.  Thus, the
     verification of the user is implicit with the verification of the
     digest.  (Note that the use of two copies of the secret, one near
     the start and one at the end, is recommended by [14].)

  -  verifying that a message sent to/from one SNMPv2 entity cannot be
     replayed to/as-if-from another SNMPv2 entity.

     Included in each message is an identifier unique to the SNMPv2
     agent associated with the sender or intended recipient of the
     message.  Also, each message containing a Response PDU contains a
     request-id which associates the message to a recently generated
     request.

     A Report message sent by one SNMPv2 agent to one SNMPv2 manager can
     potentially be replayed to another SNMPv2 manager.  However, Report
     messages do not request or contain management information, and
     thus, goal #3 in Section 1.2 above is met; further, Report messages
     can at most cause the manager to advance its notion of time (at the
     agent) by less than the correct amount.

  -  detecting messages which were not recently generated.

     A set of time indicators are included in the message, indicating
     the time of generation.  Messages (other than those containing
     Report PDUs) without recent time indicators are not considered
     authentic.  In addition, messages containing Response PDUs have a
     request-id; if the request-id does not match that of a recently
     generated request, then the message is not considered to be
     authentic.





Waters                        Experimental                      [Page 7]

RFC 1910          User-based Security Model for SNMPv2     February 1996


     A Report message sent by an SNMPv2 agent can potentially be
     replayed at a later time to an SNMPv2 manager which has not
     recently communicated with that agent.  However, Report messages do
     not request or contain management information, and thus, goal #3 in
     Section 1.2 above is met; further, Report messages can at most
     cause the manager to advance its notion of time (at the agent) by
     less than the correct amount.

   This protocol uses the MD5 [3] message digest algorithm.  A 128-bit
   digest is calculated over the designated portion of an SNMPv2 message
   and included as part of the message sent to the recipient.  The size
   of both the digest carried in a message and the private
   authentication key is 16 octets.

   This memo allows the same user to be defined on multiple SNMPv2
   agents and managers.  Each SNMPv2 agent maintains a value, agentID,
   which uniquely identifies the agent. This value is included in each
   message sent to/from that agent.  Messages sent from a SNMPv2 dual-
   role entity [1] to a SNMPv2 manager include the agentID value
   maintained by the dual-role entity's agent.  On receipt of a message,
   an agent checks the value to ensure it is the intended recipient, and
   a manager uses the value to ensure that the message is processed
   using the correct state information.

   Each SNMPv2 agent maintains two values, agentBoots and agentTime,
   which taken together provide an indication of time at that agent.
   Both of these values are included in an authenticated message sent
   to/received from that agent.  Authenticated messages sent from a
   SNMPv2 dual-role entity to a SNMPv2 manager include the agentBoots
   and agentTime values maintained by the dual-role entity's agent.  On
   receipt, the values are checked to ensure that the indicated time is
   within a time window of the current time.  The time window represents
   an administrative upper bound on acceptable delivery delay for
   protocol messages.

   For an SNMPv2 manager to generate a message which an agent will
   accept as authentic, and to verify that a message received from that
   agent is authentic, that manager must first achieve time
   synchronization with that agent.  Similarly, for a manger to verify
   that a message received from an SNMPv2 dual-role entity is authentic,
   that manager must first achieve time synchronization with the dual-
   role entity's agent.

1.4.2.  Symmetric Encryption Protocol

   The Symmetric Encryption Protocol defined in this memo provides
   support for data confidentiality through the use of the Data
   Encryption Standard (DES) in the Cipher Block Chaining mode of



Waters                        Experimental                      [Page 8]

RFC 1910          User-based Security Model for SNMPv2     February 1996


   operation.  The designated portion of an SNMPv2 message is encrypted
   and included as part of the message sent to the recipient.

   Two organizations have published specifications defining the DES: the
   National Institute of Standards and Technology (NIST) [5] and the
   American National Standards Institute [6].  There is a companion
   Modes of Operation specification for each definition (see [7] and
   [8], respectively).

   The NIST has published three additional documents that implementors
   may find useful.

  -  There is a document with guidelines for implementing and using the
     DES, including functional specifications for the DES and its modes
     of operation [9].

  -  There is a specification of a validation test suite for the DES
     [10].  The suite is designed to test all aspects of the DES and is
     useful for pinpointing specific problems.

  -  There is a specification of a maintenance test for the DES [11].
     The test utilizes a minimal amount of data and processing to test
     all components of the DES.  It provides a simple yes-or-no
     indication of correct operation and is useful to run as part of an
     initialization step, e.g., when a computer reboots.

   This Symmetric Encryption Protocol specifies that the size of the
   privacy key is 16 octets, of which the first 8 octets are a DES key
   and the second 8 octets are a DES Initialization Vector.  The 64-bit
   DES key in the first 8 octets of the private key is a 56 bit quantity
   used directly by the algorithm plus 8 parity bits - arranged so that
   one parity bit is the least significant bit of each octet.  The
   setting of the parity bits is ignored by this protocol.

   The length of an octet sequence to be encrypted by the DES must be an
   integral multiple of 8.  When encrypting, the data is padded at the
   end as necessary; the actual pad value is irrelevant.

   If the length of the octet sequence to be decrypted is not an
   integral multiple of 8 octets, the processing of the octet sequence
   is halted and an appropriate exception noted.  When decrypting, the
   padding is ignored.









Waters                        Experimental                      [Page 9]

RFC 1910          User-based Security Model for SNMPv2     February 1996


2.  Elements of the Model

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

2.1.  SNMPv2 Users

   Management operations using this security model make use of a defined
   set of user identities.  For any SNMPv2 user on whose behalf
   management operations are authorized at a particular SNMPv2 agent,
   that agent must have knowledge of that user.  A SNMPv2 manager that
   wishes to communicate with a particular agent must also have
   knowledge of a user known to that agent, including knowledge of the
   applicable attributes of that user.  Similarly, a SNMPv2 manager that
   wishes to receive messages from a SNMPv2 dual-role entity must have
   knowledge of the user on whose behalf the dual-role entity sends the
   message.

   A user and its attributes are defined as follows:

<userName>
     An octet string representing the name of the user.

<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.  One such protocol is defined in this memo: the
     Digest Authentication Protocol.

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

<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 Symmetric Encryption Protocol.

<privPrivateKey>
     If messages sent on behalf of this user can be protected from
     disclosure, the (private) privacy key for use with the privacy
     protocol.  Note that a user's privacy key will normally be
     different at different agents.





Waters                        Experimental                     [Page 10]

RFC 1910          User-based Security Model for SNMPv2     February 1996


2.2.  Contexts and Context Selectors

   An SNMPv2 context is a collection of management information
   accessible (locally or via proxy) by an SNMPv2 agent.  An item of
   management information may exist in more than one context.  An SNMPv2
   agent potentially has access to many contexts.  Each SNMPv2 message
   contains a context selector which unambiguously identifies an SNMPv2
   context accessible by the SNMPv2 agent to which the message is
   directed or by the SNMPv2 agent associated with the sender of the
   message.

   For a local SNMPv2 context which is realized by an SNMPv2 entity,
   that SNMPv2 entity uses locally-defined mechanisms to access the
   management information identified by the SNMPv2 context.

   For a proxy SNMPv2 context, the SNMPv2 entity acts as a proxy SNMPv2
   agent to access the management information identified by the SNMPv2
   context.

   The term remote SNMPv2 context is used at an SNMPv2 manager to
   indicate a SNMPv2 context (either local or proxy) which is not
   realized by the local SNMPv2 entity (i.e., the local SNMPv2 entity
   uses neither locally-defined mechanisms, nor acts as a proxy SNMPv2
   agent to access the management information identified by the SNMPv2
   context).

   Proxy SNMPv2 contexts are further categorized as either local-proxy
   contexts or remote-proxy contexts.  A proxy SNMPv2 agent receives
   Get/GetNext/GetBulk/Set operations for a local-proxy context, and
   forwards them with a remote-proxy context; it receives SNMPv2-Trap
   and Inform operations for a remote-proxy context, and forwards them
   with a local-proxy context; for Response operations, a proxy SNMPv2
   agent receives them with either a local-proxy or remote-proxy
   context, and forwards them with a remote-proxy or local-proxy
   context, respectively.