rfc1910.txt

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

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


     For the non-proxy situation:

                      context-A
         Manager <----------------> Agent

     the type of context is:

                           +-----------------+
                           |   context-A     |
         +-----------------+-----------------+
         | Manager         |    remote       |
         +-----------------+-----------------+
         | Agent           |    local        |
         +-----------------+-----------------+
         | agentID         |   of Agent      |
         +-----------------+-----------------+
         | contextSelector | locally unique  |
         +-----------------+-----------------+

     For proxy:

                      context-B               context-C
         Manager <----------------> Proxy <----------------> Agent
                                    Agent

     the type and identity of the contexts are:

                           +-----------------+-----------------+
                           |   context-B     |    context-C    |
         +-----------------+-----------------+-----------------+
         | Manager         |    remote       |       --        |
         +-----------------+-----------------+-----------------+
         | Proxy-Agent     |  local-proxy    |   remote-proxy  |
         +-----------------+-----------------+-----------------+
         | Agent           |      --         |      local      |
         +-----------------+-----------------+-----------------+
         | agentID         | of Proxy agent  |     of Agent    |
         +-----------------+-----------------+-----------------+
         | contextSelector | locally unique  |  locally unique |
         +-----------------+-----------------+-----------------+

   The combination of an agentID value and a context selector provides a
   globally-unique identification of a context.  When a context is
   accessible by multiple agents (e.g., including by proxy SNMPv2
   agents), it has multiple such globally-unique identifications, one
   associated with each agent which can access it. In the example above,
   "context-B" and "context-C" are different names for the same context.




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


2.3.  Quality of Service (qoS)

   Messages are generated with a particular Quality of Service (qoS),
   either:

  -  without authentication and privacy,

  -  with authentication but not privacy,

  -  with authentication and privacy.

   All users are capable of having messages without authentication and
   privacy generated on their behalf.  Users having an authentication
   protocol and an authentication key can have messages with
   authentication but not privacy generated on their behalf. Users
   having an authentication protocol, an authentication key, a privacy
   protocol and a privacy key can have messages with authentication and
   privacy generated on their behalf.

   In addition to its indications of authentication and privacy, the qoS
   may also indicate that the message contains an operation that may
   result in a report PDU being generated (see Section 2.6 below).

2.4.  Access Policy

   An administration's access policy determines the access rights of
   users.  For a particular SNMPv2 context to which a user has access
   using a particular qoS, that user's access rights are given by a list
   of authorized operations, and for a local context, a read-view and a
   write-view.  The read-view is the set of object instances authorized
   for the user when reading objects.  Reading objects occurs when
   processing a retrieval (get, get-next, get-bulk) operation and when
   sending a notification.  The write-view is the set of object
   instances authorized for the user when writing objects.  Writing
   objects occurs when processing a set operation.  A user's access
   rights may be different at different agents.

2.5.  Replay Protection

   Each SNMPv2 agent (or dual-role entity) maintains three objects:

  -  agentID, which is an identifier unique among all agents in (at
     least) an administrative domain;

  -  agentBoots, which is a count of the number of times the agent has
     rebooted/re-initialized since agentID was last configured; and,





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


  -  agentTime, which is the number of seconds since agentBoots was last
     incremented.

   An SNMPv2 agent is always authoritative with respect to these
   variables.  It is the responsibility of an SNMPv2 manager to
   synchronize with the agent, as appropriate.  In the case of an SNMPv2
   dual-role entity sending an Inform-Request, it is that entity acting
   in an agent role which is authoritative with respect to these
   variables for the Inform-Request.

   An agent is required to maintain the values of agentID and agentBoots
   in non-volatile storage.

2.5.1.  agentID

   The agentID value contained in an authenticated message is used to
   defeat attacks in which messages from a manager are replayed to a
   different agent and/or messages from one agent (or dual-role entity)
   are replayed as if from a different agent (or dual-role entity).

   When an agent (or dual-role entity) is first installed, it sets its
   local value of agentID according to a enterprise-specific algorithm
   (see the definition of agentID in Section 4.1).

2.5.2.  agentBoots and agentTime

   The agentBoots and agentTime values contained in an authenticated
   message are used to defeat attacks in which messages are replayed
   when they are no longer valid.  Through use of agentBoots and
   agentTime, there is no requirement for an SNMPv2 agent to have a
   non-volatile clock which ticks (i.e., increases with the passage of
   time) even when the agent is powered off.  Rather, each time an
   SNMPv2 agent reboots, it retrieves, increments, and then stores
   agentBoots in non-volatile storage, and resets agentTime to zero.

   When an agent (or dual-role entity) is first installed, it sets its
   local values of agentBoots and agentTime to zero.  If agentTime ever
   reaches its maximum value (2147483647), then agentBoots is
   incremented as if the agent has rebooted and agentTime is reset to
   zero and starts incrementing again.

   Each time an agent (or dual-role entity) reboots, any SNMPv2 managers
   holding that agent's values of agentBoots and agentTime need to re-
   synchronize prior to sending correctly authenticated messages to that
   agent (see Section 2.7 for re-synchronization procedures).  Note,
   however, that the procedures do provide for a notification to be
   accepted as authentic by a manager, when sent by an agent which has
   rebooted since the manager last re-synchronized.



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


   If an agent (or dual-role entity) is ever unable to determine its
   latest agentBoots value, then it must set its agentBoots value to
   0xffffffff.

   Whenever the local value of agentBoots has the value 0xffffffff, it
   latches at that value and an authenticated message always causes an
   usecStatsNotInWindows authentication failure.

   In order to reset an agent whose agentBoots value has reached the
   value 0xffffffff, manual intervention is required.  The agent must be
   physically visited and re-configured, either with a new agentID
   value, or with new secret values for the authentication and privacy
   keys of all users known to that agent.

2.5.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.6.  Error Reporting

   While processing a received communication, an SNMPv2 entity may
   determine that the message is unacceptable (see Section 3.2).  In
   this case, the appropriate counter from the snmpGroup [15] or
   usecStatsGroup object groups is incremented and the received message
   is discarded without further processing.

   If an SNMPv2 entity acting in the agent role makes such a
   determination and the qoS indicates that a report may be generated,
   then after incrementing the appropriate counter, it is required to
   generate a message containing a report PDU, with the same user and
   context as the received message, and to send it to the transport
   address which originated the received message.  For all report PDUs,
   except those generated due to incrementing the usecStatsNotInWindows
   counter, the report PDU is unauthenticated.  For those generated due
   to incrementing usecStatsNotInWindows, the report PDU is
   authenticated only if the received message was authenticated.

   The report flag in the qoS may only be set if the message contains a
   Get, GetNext, GetBulk, Set operation.  The report flag should never
   be set for a message that contains a Response, Inform, SNMPv2-Trap or
   Report operation.  Furthermore, a report PDU is never sent by an
   SNMPv2 entity acting in a manager role.






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


2.7.  Time Synchronization

   Time synchronization, required by a management entity in order to
   proceed with authentic communications, has occurred when the
   management entity has obtained local values of agentBoots and
   agentTime from the agent that are within the agent's time window.  To
   remain synchronized, the local values must remain within the agent's
   time window and thus must be kept loosely synchronized with the
   values stored at the agent.  In addition to keeping a local version
   of agentBoots and agentTime, a manager must also keep one other local
   variable, latestReceivedAgentTime.  This value records the highest
   value of agentTime that was received by the manager from the agent
   and is used to eliminate the possibility of replaying messages that
   would prevent the manager's notion of the agentTime from advancing.

   Time synchronization occurs as part of the procedures of receiving a
   message (Section 3.2, step 9d). As such, no explicit time
   synchronization procedure is required by a management entity.  Note,
   that whenever the local value of agentID is changed (e.g., through
   discovery) or when a new secret is configured, the local values of
   agentBoots and latestReceivedAgentTime should be set to zero. This
   will cause the time synchronization to occur when the next authentic
   message is received.

2.8.  Proxy Error Propagation

   When a proxy SNMPv2 agent receives a report PDU from a proxied agent
   and it is determined that a proxy-forwarded request cannot be
   delivered to the proxied agent, then the snmpProxyDrops counter [15]
   is incremented and a report PDU is generated and transmitted to the
   transport address from which the original request was received.
   (Note that the receipt of a report PDU containing snmpProxyDrops as a
   VarBind, is included among the reasons why a proxy-forwarded request
   cannot be delivered.)

2.9.  SNMPv2 Messages Using this Model

   The syntax of an SNMPv2 message using this security model differs
   from that of an SNMPv1 [2] message as follows:

  -  The version component is changed to 2.

  -  The data component contains either a PDU or an OCTET STRING
     containing an encrypted PDU.

   The SNMPv1 community string is now termed the "parameters" component
   and contains a set of administrative information for the message.




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


   Only the PDU is protected from disclosure by the privacy protocol.
   This exposes the administrative information to eavesdroppers.
   However, malicious use of this information is considered to be a
   Traffic Analysis attack against which protection is not provided.

   For an authenticated SNMPv2 message, the message digest is applied to
   the entire message given to the transport service.  As such, message
   generation first privatizes the PDU, then adds the message wrapper,
   and then authenticates the message.