[Internet Engineering Steering Group: Protocol Action: SNMP Security to Proposed]

[James M Galvin <[e-mail]>]

For those folks who are not on the IETF list...

Jim

------- Forwarded Message

Message-ID: <[e-mail]>
Sender:     [e-mail]
From:       Internet Engineering Steering Group <[e-mail].U
	    S>
To:         Bob Braden -- IAB Executive Director <[e-mail]>,
	    Internet Activities Board <[e-mail]>
cc:         Internet Engineering Task Force <[e-mail]>
Date:       Thu, 05 Mar 92 14:55:55 -0500
Subject:    Protocol Action: SNMP Security to Proposed Standard

 
Recommendation:
 
  The IESG recommends to the IAB that the Internet Drafts 

  o "SNMP Administrative Model",
	<draft-ietf-snmpsec-admin-02>,
  o "SNMP Security Protocols" 
	<draft-ietf-snmpsec-protocols-02>, and
  o "Definitions of Managed Objects for Administration of SNMP Parties"
  	<draft-ietf-snmpsec-mib-02>

  be published as Proposed Standards.  These documents are products of
  the SNMP Security Working Group of the IETF.

Abstract:

  The SNMP Security documents specify a model and a mechanism for
  providing security services for communicating SNMP peers.  Mechanisms
  are specified to provide authentication of data origin and integrity
  and to provide privacy in SNMP protocol exchanges.

Technical Summary:

  SNMP ADMINISTRATIVE MODEL

  This memo presents an elaboration of the SNMP administrative model set
  forth in RFC 1157. This model provides a unified conceptual basis for
  administering SNMP protocol entities to support

   o authentication and integrity,

   o privacy,

   o access control, and

   o the cooperation of multiple protocol entities.

  The model described entails the use of distinct identities for peers
  that exchange SNMP messages. Thus, it represents a departure from the
  community-based administrative model set forth in RFC 1157.  By
  unambiguously identifying the source and intended recipient of each
  SNMP message, this new strategy improves upon the historical community
  scheme both by supporting a more convenient access control model and
  allowing for effective use of asymmetric (public key) security
  protocols in the future.

  The principal abstraction of the model is the SNMP "party."  A SNMP
  party is a conceptual, virtual execution context whose operation is
  restricted (for security or other purposes) to an administratively
  defined subset of all possible operations of a particular SNMP
  protocol entity.  Whenever a SNMP protocol entity processes a SNMP
  message, it does so by acting as a SNMP party and is thereby
  restricted to the set of operations defined for that party. The set of
  possible operations specified for a SNMP party may be overlapping or
  disjoint with respect to the sets of other SNMP parties; it may also
  be a proper or improper subset of all possible operations of the SNMP
  protocol entity.

  Architecturally, each SNMP party comprises

   o a single, unique party identity,

   o a single authentication protocol and associated
    parameters by which all protocol messages originated by
    the party are authenticated as to origin and integrity,

   o a single privacy protocol and associated parameters by
    which all protocol messages received by the party are
    protected from disclosure,

   o a single MIB view to which all management operations
    performed by the party are applied, and

   o a logical network location at which the party executes,
    characterized by a transport protocol domain and
    transport addressing information.

SNMP SECURITY PROTOCOLS

  The Simple Network Management Protocol (SNMP) specification (RFC 1157)
  allows for the protection of network management operations by a
  variety of security protocols.  The SNMP administrative model
  described in a companion document provides a framework for securing
  SNMP network management. In the context of that framework, this memo
  defines protocols to support the following three security services:

   o data integrity,

   o data origin authentication, and

   o data confidentiality.

  In the model described in a companion document, each SNMP party is, by
  definition, associated with a single authentication protocol.  The
  authentication protocol defined in this memo also reliably determines
  that the message received is the message that was sent.  It provides a
  data integrity service by having the originator compute a digest over
  an appropriate portion of a message and sending that digest to the
  recipient, with the message, for verification. The data origin
  authentication service is provided by prefixing the message with a
  secret value known only to the originator and recipient, prior to
  computing the digest. Thus, data integrity is supported explicitly
  while data origin authentication is supported implicitly in the
  verification of the digest.

  Similarly, each SNMP party is, by definition, associated with a single
  privacy protocol. The privacy protocol in this memo specifies that
  only authenticated messages may be protected from disclosure.  It
  protects messages from disclosure by encrypting their contents
  according to a secret cryptographic key known only to the originator
  and recipient. The additional functionality afforded by this protocol
  is assumed to justify its additional computational cost.

  The Digest Authentication Protocol depends on the existence of loosely
  synchronized clocks between the originator and recipient of a message.
  The protocol specification makes no assumptions about the strategy by
  which such clocks are synchronized. This memo specifies one strategy
  that is particularly suited to the demands of SNMP network management.

  Both protocols described here require the sharing of secret
  information between the originator of a message and its recipient. The
  protocol specifications assume the existence of the necessary secrets.
  The selection of such secrets and their secure distribution to
  appropriate parties may be accomplished by a variety of strategies.
  This memo specifies one strategy that is particularly suited to the
  demands of SNMP network management.

  These protocols are secure alternatives to the so-called "trivial"
  protocol defined in RFC 1157, although implementation of the trivial
  protocol alone does NOT constitute conformance to this specification.

  The threats against which the specified protocols provide protection
  are: Modification of Information, Masquerade, Message Stream
  Modification, and Disclosure.  Protection against Denial of Service
  and Traffic Analysis threats is not provided. 

DEFINITION OF MANAGED OBJECTS FOR ADMINISTRATION OF SNMP PARTIES

  This memo defines an experimental portion of the Management
  Information Base (MIB) for use with network management protocols in
  TCP/IP-based internets. In particular, it describes a representation
  of the SNMP parties defined in a companion document as objects defined
  according to the Internet Standard SMI (RFC 1155) and the conventions
   of RFC 1212.  These definitions are consistent with the SNMP Security
  protocols set forth in companion documents.

  This MIB contains the definitions for four tables, a number of OBJECT
  IDENTIFIER assignments, and some conventions for initial use with some
  of the assignments.  The four tables are the SNMP Party Public
  database, the SNMP Party Secrets database, the SNMP Access Control
  database, and the SNMP Views database.

  The SNMP Party Public database and the SNMP Party Secrets database are
  defined as separate tables specifically for the purpose of positioning
  them in different parts of the MIB tree namespace.  In particular, the
  SNMP Party Secrets database contains secret information, for which
  security demands that access to it be limited to parties which use
  both authentication and privacy.  It is therefore positioned in a
  separate branch of the MIB tree, at the highest level possible, so as
  to provide for the easiest means of accommodating the required
  limitation.

  In contrast, the SNMP Party Public database contains public
  information about SNMP parties.  In particular, it contains the
  parties' clocks which need to be read-able (but not write-able) by
  unauthenticated queries, since an unauthenticated query of a party's
  clock is the first step of the procedure to re-establish clock
  synchronization.

------- End of Forwarded Message