rfc2275.txt

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

Network Working Group                                          B. Wijnen
Request for Comments: 2275                     IBM T. J. Watson Research
Obsoletes: 2265                                               R. Presuhn
Category: Standards Track                             BMC Software, Inc.
                                                           K. McCloghrie
                                                     Cisco Systems, Inc.
                                                            January 1998

             View-based Access Control Model (VACM) for the
               Simple Network Management Protocol (SNMP)

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

IANA Note

   Due to a clerical error in the assignment of the snmpModules in this
   memo, this RFC provides the corrected number assignment for this
   protocol.  This memo obsoletes RFC 2265.

Abstract

   This document describes the View-based Access Control Model for use
   in the SNMP architecture [RFC2271].  It defines the Elements of
   Procedure for controlling access to management information.  This
   document also includes a MIB for remotely managing the configuration
   parameters for the View-based Access Control Model.

Table of Contents

   1.  Introduction                                             2
   1.2.  Access Control                                         3
   1.3.  Local Configuration Datastore                          3
   2.  Elements of the Model                                    3
   2.1.  Groups                                                 3
   2.2.  securityLevel                                          4
   2.3.  Contexts                                               4
   2.4.  MIB Views and View Families                            4
   2.4.1.  View Subtree                                         5



Wijnen, et. al.             Standards Track                     [Page 1]

RFC 2275                    VACM for SNMPv3                 January 1998


   2.4.2.  ViewTreeFamily                                       5
   2.5.  Access Policy                                          6
   3.  Elements of Procedure                                    6
   3.1.  Overview  of isAccessAllowed Process                   8
   3.2.  Processing the isAccessAllowed Service Request         9
   4.  Definitions                                             10
   5.  Intellectual Property                                   26
   6.  Acknowledgements                                        27
   7.  Security Considerations                                 28
   7.1.  Recommended Practices                                 28
   7.2.  Defining Groups                                       29
   7.3.  Conformance                                           29
   8.  References                                              29
   9.  Editors' Addresses                                      30
   A.1.  Installation Parameters                               31
   B.  Full Copyright Statement                                36

1.  Introduction

   The Architecture for describing Internet Management Frameworks
   [RFC2271] describes that an SNMP engine is composed of:

     1) a Dispatcher
     2) a Message Processing Subsystem,
     3) a Security Subsystem, and
     4) an Access Control Subsystem.

   Applications make use of the services of these subsystems.

   It is important to understand the SNMP architecture and its
   terminology to understand where the View-based Access Control Model
   described in this document fits into the architecture and interacts
   with other subsystems within the architecture.  The reader is
   expected to have read and understood the description and terminology
   of the SNMP architecture, as defined in [RFC2271].

   The Access Control Subsystem of an SNMP engine has the responsibility
   for checking whether a specific type of access (read, write, notify)
   to a particular object (instance) is allowed.

   It is the purpose of this document to define a specific model of the
   Access Control Subsystem, designated the View-based Access Control
   Model. Note that this is not necessarily the only Access Control
   Model.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].



Wijnen, et. al.             Standards Track                     [Page 2]

RFC 2275                    VACM for SNMPv3                 January 1998


1.2.  Access Control

   Access Control occurs (either implicitly or explicitly) in an SNMP
   entity when processing SNMP retrieval or modification request
   messages from an SNMP entity.  For example a Command Responder
   application applies Access Control when processing requests that it
   received from a Command Generator application.  These requests
   include these types of operations: GetRequest, GetNextRequest,
   GetBulkRequest, and SetRequest operations.

   Access Control also occurs in an SNMP entity when an SNMP
   notification message is generated (by a Notification Originator
   application).  These notification messages include these types of
   operations: InformRequest and SNMPv2-Trap operations.

   The View-based Access Control Model defines a set of services that an
   application (such as a Command Responder or a Notification Originator
   application) can use for checking access rights.  It is the
   responsibility of the application to make the proper service calls
   for access checking.

1.3.  Local Configuration Datastore

   To implement the model described in this document, an SNMP entity
   needs to retain information about access rights and policies.  This
   information is part of the SNMP engine's Local Configuration
   Datastore (LCD). See [RFC2271] for the definition of LCD.

   In order to allow an SNMP entity's LCD to be remotely configured,
   portions of the LCD need to be accessible as managed objects.  A MIB
   module, the View-based Access Control Model Configuration MIB, which
   defines these managed object types is included in this document.

2.  Elements of the Model

   This section contains definitions to realize the access control
   service provided by the View-based Access Control Model.

2.1.  Groups

   A group is a set of zero or more <securityModel, securityName> tuples
   on whose behalf SNMP management objects can be accessed.  A group
   defines the access rights afforded to all securityNames which belong
   to that group. The combination of a securityModel and a securityName
   maps to at most one group.  A group is identified by a groupName.

   The Access Control module assumes that the securityName has already
   been authenticated as needed and provides no further authentication



Wijnen, et. al.             Standards Track                     [Page 3]

RFC 2275                    VACM for SNMPv3                 January 1998


   of its own.

   The View-based Access Control Model uses the securityModel and the
   securityName as inputs to the Access Control module when called to
   check for access rights.  It determines the groupName as a function
   of securityModel and securityName.

2.2.  securityLevel

   Different access rights for members of a group can be defined for
   different levels of security, i.e., noAuthNoPriv, authNoPriv, and
   authPriv. The securityLevel identifies the level of security that
   will be assumed when checking for access rights.  See the SNMP
   Architecture document [RFC2271] for a definition of securityLevel.

   The View-based Access Control Model requires that the securityLevel
   is passed as input to the Access Control module when called to check
   for access rights.

2.3.  Contexts

   An SNMP context is a collection of management information accessible
   by an SNMP entity.  An item of management information may exist in
   more than one context.  An SNMP entity potentially has access to many
   contexts.  Details about the naming of management information can be
   found in the SNMP Architecture document [RFC2271].

   The View-based Access Control Model defines a vacmContextTable that
   lists the locally available contexts by contextName.

2.4.  MIB Views and View Families

   For security reasons, it is often valuable to be able to restrict the
   access rights of some groups to only a subset of the management
   information in the management domain.  To provide this capability,
   access to a context is via a "MIB view" which details a specific set
   of managed object types (and optionally, the specific instances of
   object types) within that context.  For example, for a given context,
   there will typically always be one MIB view which provides access to
   all management information in that context, and often there will be
   other MIB views each of which contains some subset of the
   information.  So, the access allowed for a group can be restricted in
   the desired manner by specifying its rights in terms of the
   particular (subset) MIB view it can access within each appropriate
   context.

   Since managed object types (and their instances) are identified via
   the tree-like naming structure of ISO's OBJECT IDENTIFIERs [ISO-



Wijnen, et. al.             Standards Track                     [Page 4]

RFC 2275                    VACM for SNMPv3                 January 1998


   ASN.1, RFC1902],  it is convenient to define a MIB view as the
   combination of a set of "view subtrees", where each view subtree is a
   subtree within the managed object naming tree.  Thus, a simple MIB
   view (e.g., all managed objects within the Internet Network
   Management Framework) can be defined as a single view subtree, while
   more complicated MIB views (e.g., all information relevant to a
   particular network interface) can be represented by the union of
   multiple view subtrees.

   While any set of managed objects can be described by the union of
   some number of view subtrees, situations can arise that would require
   a very large number of view subtrees.  This could happen, for
   example, when specifying all columns in one conceptual row of a MIB
   table because they would appear in separate subtrees, one per column,
   each with a very similar format.  Because the formats are similar,
   the required set of subtrees can easily be aggregated into one
   structure.  This structure is named a family of view subtrees after
   the set of subtrees that it conceptually represents.  A family of
   view subtrees can either be included or excluded from a MIB view.

2.4.1.  View Subtree

   A view subtree is the set of all MIB object instances which have a
   common ASN.1 OBJECT IDENTIFIER prefix to their names.  A view subtree
   is identified by the OBJECT IDENTIFIER value which is the longest
   OBJECT IDENTIFIER prefix common to all (potential) MIB object
   instances in that subtree.

2.4.2.  ViewTreeFamily

   A family of view subtrees is a pairing of an OBJECT IDENTIFIER value
   (called the family name) together with a bit string value (called the
   family mask).  The family mask indicates which sub-identifiers of the
   associated family name are significant to the family's definition.

   For each possible managed object instance, that instance belongs to a
   particular ViewTreeFamily if both of the following conditions are
   true:

   - the OBJECT IDENTIFIER name of the managed object instance
     contains at least as many sub-identifiers as does the family name,
     and

   - each sub-identifier in the OBJECT IDENTIFIER name of the managed
     object instance matches the corresponding sub-identifier of the
     family name whenever the corresponding bit of the associated family
     mask is non-zero.




Wijnen, et. al.             Standards Track                     [Page 5]

RFC 2275                    VACM for SNMPv3                 January 1998


   When the configured value of the family mask is all ones, the view
   subtree family is identical to the single view subtree identified by
   the family name.

   When the configured value of the family mask is shorter than required
   to perform the above test, its value is implicitly extended with
   ones.  Consequently, a view subtree family having a family mask of
   zero length always corresponds to a single view subtree.

2.5.  Access Policy

   The View-based Access Control Model determines the access rights of a
   group, representing zero or more securityNames which have the same
   access rights.  For a particular context, identified by contextName,
   to which a group, identified by groupName, has access using a
   particular securityModel and securityLevel, that group's access
   rights are given by a read-view, a write-view and a notify-view.

   The read-view represents the set of object instances authorized for
   the group when reading objects.  Reading objects occurs when
   processing a retrieval (for example a GetRequest, GetNextRequest,
   GetBulkRequest) operation.

   The write-view represents the set of object instances authorized for
   the group when writing objects.  Writing objects occurs when
   processing a write (for example a Set) operation.

   The notify-view represents the set of object instances authorized for
   the group when sending objects in a notification, such as when
   sending a notification (for example an Inform or SNMPv2-Trap).

3.  Elements of Procedure

   This section describes the procedures followed by an Access Control
   module that implements the View-based Access Control Model when
   checking access rights as requested by an application (for example a
   Command Responder or a Notification Originator application).  The
   abstract service primitive is:

     statusInformation =          -- success or errorIndication
         isAccessAllowed(
             securityModel        -- Security Model in use