rfc2274.txt

RFC 的详细文档！

      SNMP message are protected from disclosure.

   In addition to the principal goal of supporting secure network
   management, the design of this SNMP Security Model is also influenced
   by the following constraints:

   1) When the requirements of effective management in times of
      network stress are inconsistent with those of security, the design
      should prefer the former.

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

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

1.3.  Security Services

   The security services necessary to support the goals of this SNMP
   Security Model are as follows:

   - Data Integrity
     is the provision of the property that data has not been altered or
     destroyed in an unauthorized manner, nor have data sequences been
     altered to an extent greater than can occur non-maliciously.

   - Data Origin Authentication
     is the provision of the property that the claimed identity of the
     user on whose behalf received data was originated is corroborated.

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

   - Message timeliness and limited replay protection
     is the provision of the property that a message whose generation
     time is outside of a specified time window is not accepted.  Note
     that message reordering is not dealt with and can occur in normal
     conditions too.




Blumenthal & Wijnen         Standards Track                     [Page 6]

RFC 2274                     USM for SNMPv3                 January 1998


   For the protocols specified in this memo, it is not possible to
   assure the specific originator of a received SNMP message; rather, it
   is the user on whose behalf the message was originated that is
   authenticated.

   For these protocols, it not possible to obtain data integrity without
   data origin authentication, nor is it possible to obtain data origin
   authentication without data integrity.  Further, there is no
   provision for data confidentiality without both data integrity and
   data origin authentication.

   The security protocols used in this memo are considered acceptably
   secure at the time of writing.  However, the procedures allow for new
   authentication and privacy methods to be specified at a future time
   if the need arises.

1.4.  Module Organization

   The security protocols defined in this memo are split in three
   different modules and each has its specific responsibilities such
   that together they realize the goals and security services described
   above:

   - The authentication module MUST provide for:

     - Data Integrity,

     - Data Origin Authentication

   - The timeliness module MUST provide for:

     - Protection against message delay or replay (to an extent
       greater than can occur through normal operation)

     The privacy module MUST provide for

     - Protection against disclosure of the message payload.

   The timeliness module is fixed for the User-based Security Model
   while there is provision for multiple authentication and/or privacy
   modules, each of which implements a specific authentication or
   privacy protocol respectively.

1.4.1.  Timeliness Module

   Section 3 (Elements of Procedure) uses the timeliness values in an
   SNMP message to do timeliness checking.  The timeliness check is only
   performed if authentication is applied to the message.  Since the



Blumenthal & Wijnen         Standards Track                     [Page 7]

RFC 2274                     USM for SNMPv3                 January 1998


   complete message is checked for integrity, we can assume that the
   timeliness values in a message that passes the authentication module
   are trustworthy.

1.4.2.  Authentication Protocol

   Section 6 describes the HMAC-MD5-96 authentication protocol which is
   the first authentication protocol that MUST be supported with the
   User-based Security Model.  Section 7 describes the HMAC-SHA-96
   authentication protocol which is another authentication protocol that
   SHOULD be supported with the User-based Security Model.  In the
   future additional or replacement authentication protocols may be
   defined as new needs arise.

   The User-based Security Model prescribes that, if authentication is
   used, then the complete message is checked for integrity in the
   authentication module.

   For a message to be authenticated, it needs to pass authentication
   check by the authentication module and the timeliness check which is
   a fixed part of this User-based Security model.

1.4.3.  Privacy Protocol

   Section 8 describes the CBC-DES Symmetric Encryption Protocol which
   is the first privacy protocol to be used with the User-based Security
   Model.  In the future additional or replacement privacy protocols may
   be defined as new needs arise.

   The User-based Security Model prescribes that the scopedPDU is
   protected from disclosure when a message is sent with privacy.

   The User-based Security Model also prescribes that a message needs to
   be authenticated if privacy is in use.

1.5.  Protection against Message Replay, Delay and Redirection

1.5.1.  Authoritative SNMP engine

   In order to protect against message replay, delay and redirection,
   one of the SNMP engines involved in each communication is designated
   to be the authoritative SNMP engine.  When an SNMP message contains a
   payload which expects a response (for example a Get, GetNext,
   GetBulk, Set or Inform PDU), then the receiver of such messages is
   authoritative.  When an SNMP message contains a payload which does
   not expect a response (for example an SNMPv2-Trap, Response or Report
   PDU), then the sender of such a message is authoritative.




Blumenthal & Wijnen         Standards Track                     [Page 8]

RFC 2274                     USM for SNMPv3                 January 1998


1.5.2.  Mechanisms

   The following mechanisms are used:

   1) To protect against the threat of message delay or replay (to an
      extent greater than can occur through normal operation), a set of
      timeliness indicators (for the authoritative SNMP engine) are
      included in each message generated.  An SNMP engine evaluates the
      timeliness indicators to determine if a received message is
      recent.  An SNMP engine may evaluate the timeliness indicators to
      ensure that a received message is at least as recent as the last
      message it received from the same source.  A non-authoritative
      SNMP engine uses received authentic messages to advance its notion
      of the timeliness indicators at the remote authoritative source.

      An SNMP engine MUST also use a mechanism to match incoming
      Responses to outstanding Requests and it MUST drop any Responses
      that do not match an outstanding request. For example, a msgID can
      be inserted in every message to cater for this functionality.

      These mechanisms provide for the detection of authenticated
      messages whose time of generation was not recent.

      This protection against the threat of message delay or replay does
      not imply nor provide any protection against unauthorized deletion
      or suppression of messages.  Also, an SNMP engine may not be able
      to detect message reordering if all the messages involved are sent
      within the Time Window interval.  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
      [RFC1907]).

   2) Verification that a message sent to/from one authoritative SNMP
      engine cannot be replayed to/as-if-from another authoritative SNMP
      engine.

      Included in each message is an identifier unique to the
      authoritative SNMP engine associated with the sender or intended
      recipient of the message.

      A Report, Response or Trap message sent by an authoritative SNMP
      engine to one non-authoritative SNMP engine can potentially be
      replayed to another non-authoritative SNMP engine. The latter
      non-authoritative SNMP engine might (if it knows about the same
      userName with the same secrets at the authoritative SNMP engine)
      as a result update its notion of timeliness indicators of the
      authoritative SNMP engine, but that is not considered a threat.



Blumenthal & Wijnen         Standards Track                     [Page 9]

RFC 2274                     USM for SNMPv3                 January 1998


      In this case, A Report or Response message will be discarded by
      the Message Processing Model, because there should not be an
      outstanding Request message. A Trap will possibly be accepted.
      Again, that is not considered a threat, because the communication
      was authenticated and timely. It is as if the authoritative SNMP
      engine was configured to start sending Traps to the second SNMP
      engine, which theoretically can happen without the knowledge of
      the second SNMP engine anyway. Anyway, the second SNMP engine may
      not expect to receive this Trap, but is allowed to see the
      management information contained in it.

   3) Detection of messages which were not recently generated.

      A set of time indicators are included in the message, indicating
      the time of generation.  Messages without recent time indicators
      are not considered authentic.  In addition, an SNMP engine MUST
      drop any Responses that do not match an outstanding request. This
      however is the responsibility of the Message Processing Model.

   This memo allows the same user to be defined on multiple SNMP
   engines.  Each SNMP engine maintains a value, snmpEngineID, which
   uniquely identifies the SNMP engine.  This value is included in each
   message sent to/from the SNMP engine that is authoritative (see
   section 1.5.1).  On receipt of a message, an authoritative SNMP
   engine checks the value to ensure that it is the intended recipient,
   and a non-authoritative SNMP engine uses the value to ensure that the
   message is processed using the correct state information.

   Each SNMP engine maintains two values, snmpEngineBoots and
   snmpEngineTime, which taken together provide an indication of time at
   that SNMP engine.  Both of these values are included in an
   authenticated message sent to/received from that SNMP engine.  On
   receipt, the values are checked to ensure that the indicated
   timeliness value 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 SNMP engine to generate a message which an authoritative SNMP
   engine will accept as authentic, and to verify that a message
   received from that authoritative SNMP engine is authentic, such an
   SNMP engine must first achieve timeliness synchronization with the
   authoritative SNMP engine. See section 2.3.

1.6.  Abstract Service Interfaces.

   Abstract service interfaces have been defined to describe the
   conceptual interfaces between the various subsystems within an SNMP
   entity. Similarly a set of abstract service interfaces have been



Blumenthal & Wijnen         Standards Track                    [Page 10]

RFC 2274                     USM for SNMPv3                 January 1998


   defined within the User-based Security Model (USM) to describe the
   conceptual interfaces between the generic USM services and the self-
   contained authentication and privacy services.

   These abstract service interfaces are defined by a set of primitives
   that define the services provided and the abstract data elements that
   must be passed when the services are invoked. This section lists the
   primitives that have been defined for the User-based Security Model.

1.6.1.  User-based Security Model Primitives for Authentication

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

   statusInformation =