doc: Add RFC documents

1 files changed, 2019 insertions, 0 deletions

diff --git a/doc/rfc/rfc2265.txt b/doc/rfc/rfc2265.txt
new file mode 100644
index 0000000..4474101
--- /dev/null
+++ b/doc/rfc/rfc2265.txt
@@ -0,0 +1,2019 @@
+
+
+
+
+
+
+Network Working Group                                          B. Wijnen
+Request for Comments: 2265                     IBM T. J. Watson Research
+Category: Standards Track                                     R. Presuhn
+                                                      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 (1997).  All Rights Reserved.
+
+Abstract
+
+   This document describes the View-based Access Control Model for use
+   in the SNMP architecture [RFC2261].  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                                         2
+   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
+   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
+
+
+
+Wijnen, et. al.             Standards Track                     [Page 1]
+
+RFC 2265                    VACM for SNMPv3                 January 1998
+
+
+   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
+   [RFC2261] 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 [RFC2261].
+
+   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].
+
+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
+
+
+
+Wijnen, et. al.             Standards Track                     [Page 2]
+
+RFC 2265                    VACM for SNMPv3                 January 1998
+
+
+   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 [RFC2261] 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
+   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
+
+
+
+Wijnen, et. al.             Standards Track                     [Page 3]
+
+RFC 2265                    VACM for SNMPv3                 January 1998
+
+
+   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 [RFC2261] 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 [RFC2261].
+
+   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-
+   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
+
+
+
+Wijnen, et. al.             Standards Track                     [Page 4]
+
+RFC 2265                    VACM for SNMPv3                 January 1998
+
+
+   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 2265                    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
+             securityName         -- principal who wants access
+             securityLevel        -- Level of Security
+             viewType             -- read, write, or notify view
+             contextName          -- context containing variableName
+             variableName         -- OID for the managed object
+             )
+
+
+
+Wijnen, et. al.             Standards Track                     [Page 6]
+
+RFC 2265                    VACM for SNMPv3                 January 1998
+
+
+   The abstract data elements are:
+
+     statusInformation - one of the following:
+        accessAllowed  - a MIB view was found and access is granted.
+        notInView      - a MIB view was found but access is denied.
+                         The variableName is not in the configured
+                         MIB view for the specified viewType (e.g., in
+                         the relevant entry in the vacmAccessTable).
+        noSuchView     - no MIB view found because no view has been
+                         configured for specified viewType (e.g., in
+                         the relevant entry in the vacmAccessTable).
+        noSuchContext  - no MIB view found because of no entry in the
+                         vacmContextTable for specified contextName.
+        noGroupName    - no MIB view found because no entry has been
+                         configured in the vacmSecurityToGroupTable
+                         for the specified combination of
+                         securityModel and securityName.
+        noAccessEntry  - no MIB view found because no entry has been
+                         configured in the vacmAccessTable for the
+                         specified combination of contextName,
+                         groupName (from vacmSecurityToGroupTable),
+                         securityModel and securityLevel.
+        otherError     - failure, an undefined error occurred.
+     securityModel - Security Model under which access is requested.
+     securityName  - the principal on whose behalf access is requested.
+     securityLevel - Level of Security under which access is requested.
+     viewType      - view to be checked (read, write or notify).
+     contextName   - context in which access is requested.
+     variableName  - object instance to which access is requested.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wijnen, et. al.             Standards Track                     [Page 7]
+
+RFC 2265                    VACM for SNMPv3                 January 1998
+
+
+3.1.  Overview  of isAccessAllowed Process
+
+ The following picture shows how the decision for access control is made
+ by the View-based Access Control Model.
+
+ +--------------------------------------------------------------------+
+ |                                                                    |
+ |      +-> securityModel -+                                          |
+ |      |   (a)            |                                          |
+ | who -+                  +-> groupName ----+                        |
+ | (1)  |                  |   (x)           |                        |
+ |      +-> securityName --+                 |                        |
+ |          (b)                              |                        |
+ |                                           |                        |
+ | where -> contextName ---------------------+                        |
+ | (2)      (e)                              |                        |
+ |                                           |                        |
+ |                                           |                        |
+ |      +-> securityModel -------------------+                        |
+ |      |   (a)                              |                        |
+ | how -+                                    +-> viewName -+          |
+ | (3)  |                                    |   (y)       |          |
+ |      +-> securityLevel -------------------+             |          |
+ |          (c)                              |             +-> yes/no |
+ |                                           |             | decision |
+ | why ---> viewType (read/write/notify) ----+             | (z)      |
+ | (4)      (d)                                            |          |
+ |                                                         |          |
+ | what --> object-type ------+                            |          |
+ | (5)      (m)               |                            |          |
+ |                            +-> variableName (OID) ------+          |
+ |                            |   (f)                                 |
+ | which -> object-instance --+                                       |
+ | (6)      (n)                                                       |
+ |                                                                    |
+ +--------------------------------------------------------------------+
+
+ How the decision for isAccessAllowed is made.
+
+ 1) Inputs to the isAccessAllowed service are:
+
+    (a)       securityModel    -- Security Model in use
+    (b)       securityName     -- principal who wants to access
+    (c)       securityLevel    -- Level of Security
+    (d)       viewType         -- read, write, or notify view
+    (e)       contextName      -- context containing variableName
+    (f)       variableName     -- OID for the managed object
+                               -- this is made up of:
+
+
+
+Wijnen, et. al.             Standards Track                     [Page 8]
+
+RFC 2265                    VACM for SNMPv3                 January 1998
+
+
+                                  - object-type (m)
+                                  - object-instance (n)
+
+ 2) The partial "who" (1), represented by the securityModel (a) and
+    the securityName (b), are used as the indices (a,b) into the
+    vacmSecurityToGroupTable to find a single entry that produces a
+    group, represented by groupName (x).
+
+ 3) The "where" (2), represented by the contextName (e), the "who",
+    represented by the groupName (x) from the previous step, and the
+    "how" (3), represented by securityModel (a) and securityLevel (c),
+    are used as indices (e,x,a,c) into the vacmAccessTable to find a
+    single entry that contains three MIB views.
+
+ 4) The "why" (4), represented by the viewType (d), is used to select
+    the proper MIB view, represented by a viewName (y), from the
+    vacmAccessEntry selected in the previous step. This viewName (y) is
+    an index into the vacmViewTreeFamilyTable and selects the set of
+    entries that define the variableNames which are included in or
+    excluded from the MIB view identified by the viewName (y).
+
+ 5) The "what" (5) type of management data and "which" (6) particular
+    instance, represented by the variableName (f), is then checked to be
+    in the MIB view or not, e.g., the yes/no decision (z).
+
+3.2.  Processing the isAccessAllowed Service Request
+
+   This section describes the procedure followed by an Access Control
+   module that implements the View-based Access Control Model whenever
+   it receives an isAccessAllowed request.
+
+   1) The vacmContextTable is consulted for information about
+      the SNMP context identified by the contextName.  If information
+      about this SNMP context is absent from the table, then an
+      errorIndication (noSuchContext) is returned to the calling module.
+
+   2) The vacmSecurityToGroupTable is consulted for mapping the
+      securityModel and securityName to a groupName.  If the information
+      about this combination is absent from the table, then an
+      errorIndication (noGroupName) is returned to the calling module.
+
+   3) The vacmAccessTable is consulted for information about the
+      groupName, contextName, securityModel and securityLevel.  If
+      information about this combination is absent from the table, then
+      an errorIndication (noAccessEntry) is returned to the calling
+      module.
+
+
+
+
+
+Wijnen, et. al.             Standards Track                     [Page 9]
+
+RFC 2265                    VACM for SNMPv3                 January 1998
+
+
+   4) a) If the viewType is "read", then the read view is used for
+         checking access rights.
+
+      b) If the viewType is "write", then the write view is used for
+         checking access rights.
+
+      c) If the viewType is "notify", then the notify view is used
+         for checking access rights.
+
+      If the view to be used is the empty view (zero length viewName)
+      then an errorIndication (noSuchView) is returned to the calling
+      module.
+
+   5) a) If there is no view configured for the specified viewType,
+         then an errorIndication (noSuchView) is returned to the calling
+         module.
+
+      b) If the specified variableName (object instance) is not in the
+         MIB view (see DESCRIPTION clause for vacmViewTreeFamilyTable in
+         section 4), then an errorIndication (notInView) is returned to
+         the calling module.
+
+         Otherwise,
+
+      c) The specified variableName is in the MIB view.
+         A statusInformation of success (accessAllowed) is returned to
+         the calling module.
+
+4.  Definitions
+
+SNMP-VIEW-BASED-ACM-MIB DEFINITIONS ::= BEGIN
+
+IMPORTS
+    MODULE-COMPLIANCE, OBJECT-GROUP       FROM SNMPv2-CONF
+    MODULE-IDENTITY, OBJECT-TYPE,
+    snmpModules                           FROM SNMPv2-SMI
+    TestAndIncr,
+    RowStatus, StorageType                FROM SNMPv2-TC
+    SnmpAdminString,
+    SnmpSecurityLevel,
+    SnmpSecurityModel                     FROM SNMP-FRAMEWORK-MIB;
+
+snmpVacmMIB       MODULE-IDENTITY
+    LAST-UPDATED "9711200000Z"            -- 20 Nov 1997, midnight
+    ORGANIZATION "SNMPv3 Working Group"
+    CONTACT-INFO "WG-email:   snmpv3@tis.com
+                  Subscribe:  majordomo@tis.com
+                              In message body:  subscribe snmpv3
+
+
+
+Wijnen, et. al.             Standards Track                    [Page 10]
+
+RFC 2265                    VACM for SNMPv3                 January 1998
+
+
+                  Chair:      Russ Mundy
+                              Trusted Information Systems
+                  postal:     3060 Washington Rd
+                              Glenwood MD 21738
+                              USA
+                  email:      mundy@tis.com
+                  phone:      +1-301-854-6889
+
+                  Co-editor:  Bert Wijnen
+                              IBM T.J. Watson Research
+                  postal:     Schagen 33
+                              3461 GL Linschoten
+                              Netherlands
+                  email:      wijnen@vnet.ibm.com
+                  phone:      +31-348-432-794
+
+                  Co-editor:  Randy Presuhn
+                              BMC Software, Inc
+                  postal:     1190 Saratoga Avenue, Suite 130
+                              San Jose, CA  95129-3433
+                              USA
+                  email:      rpresuhn@bmc.com
+                  phone:      +1-408-556-0720
+
+                  Co-editor:  Keith McCloghrie
+                              Cisco Systems, Inc.
+                  postal:     170 West Tasman Drive
+                              San Jose, CA  95134-1706
+                              USA
+                  email:      kzm@cisco.com
+                  phone:      +1-408-526-5260
+                 "
+    DESCRIPTION  "The management information definitions for the
+                  View-based Access Control Model for SNMP.
+                 "
+    ::= { snmpModules 5 }
+
+-- Administrative assignments ****************************************
+
+vacmMIBObjects      OBJECT IDENTIFIER ::= { snmpVacmMIB 1 }
+vacmMIBConformance  OBJECT IDENTIFIER ::= { snmpVacmMIB 2 }
+
+-- Information about Local Contexts **********************************
+
+vacmContextTable OBJECT-TYPE
+    SYNTAX       SEQUENCE OF VacmContextEntry
+    MAX-ACCESS   not-accessible
+    STATUS       current
+
+
+
+Wijnen, et. al.             Standards Track                    [Page 11]
+
+RFC 2265                    VACM for SNMPv3                 January 1998
+
+
+    DESCRIPTION "The table of locally available contexts.
+
+                 This table provides information to SNMP Command
+                 Generator applications so that they can properly
+                 configure the vacmAccessTable to control access to
+                 all contexts at the SNMP entity.
+
+                 This table may change dynamically if the SNMP entity
+                 allows that contexts are added/deleted dynamically
+                 (for instance when its configuration changes). Such
+                 changes would happen only if the management
+                 instrumentation at that SNMP entity recognizes more
+                 (or fewer) contexts.
+
+                 The presence of entries in this table and of entries
+                 in the vacmAccessTable are independent.  That is, a
+                 context identified by an entry in this table is not
+                 necessarily referenced by any entries in the
+                 vacmAccessTable; and the context(s) referenced by an
+                 entry in the vacmAccessTable does not necessarily
+                 currently exist and thus need not be identified by an
+                 entry in this table.
+
+                 This table must be made accessible via the default
+                 context so that Command Responder applications have
+                 a standard way of retrieving the information.
+
+                 This table is read-only. It cannot be configured via
+                 SNMP.
+                "
+    ::= { vacmMIBObjects 1 }
+
+vacmContextEntry OBJECT-TYPE
+    SYNTAX       VacmContextEntry
+    MAX-ACCESS   not-accessible
+    STATUS       current
+    DESCRIPTION "Information about a particular context."
+    INDEX       {
+                  vacmContextName
+                }
+    ::= { vacmContextTable 1 }
+
+VacmContextEntry ::= SEQUENCE
+    {
+        vacmContextName SnmpAdminString
+    }
+
+vacmContextName  OBJECT-TYPE
+
+
+
+Wijnen, et. al.             Standards Track                    [Page 12]
+
+RFC 2265                    VACM for SNMPv3                 January 1998
+
+
+    SYNTAX       SnmpAdminString (SIZE(0..32))
+    MAX-ACCESS   read-only
+    STATUS       current
+    DESCRIPTION "A human readable name identifying a particular
+                 context at a particular SNMP entity.
+
+                 The empty contextName (zero length) represents the
+                 default context.
+                "
+    ::= { vacmContextEntry 1 }
+
+-- Information about Groups ******************************************
+
+vacmSecurityToGroupTable OBJECT-TYPE
+    SYNTAX       SEQUENCE OF VacmSecurityToGroupEntry
+    MAX-ACCESS   not-accessible
+    STATUS       current
+    DESCRIPTION "This table maps a combination of securityModel and
+                 securityName into a groupName which is used to define
+                 an access control policy for a group of principals.
+                "
+    ::= { vacmMIBObjects 2 }
+
+vacmSecurityToGroupEntry OBJECT-TYPE
+    SYNTAX       VacmSecurityToGroupEntry
+    MAX-ACCESS   not-accessible
+    STATUS       current
+    DESCRIPTION "An entry in this table maps the combination of a
+                 securityModel and securityName into a groupName.
+                "
+    INDEX       {
+                  vacmSecurityModel,
+                  vacmSecurityName
+                }
+    ::= { vacmSecurityToGroupTable 1 }
+
+VacmSecurityToGroupEntry ::= SEQUENCE
+    {
+        vacmSecurityModel               SnmpSecurityModel,
+        vacmSecurityName                SnmpAdminString,
+        vacmGroupName                   SnmpAdminString,
+        vacmSecurityToGroupStorageType  StorageType,
+        vacmSecurityToGroupStatus       RowStatus
+    }
+
+vacmSecurityModel OBJECT-TYPE
+    SYNTAX       SnmpSecurityModel(1..2147483647)
+    MAX-ACCESS   not-accessible
+
+
+
+Wijnen, et. al.             Standards Track                    [Page 13]
+
+RFC 2265                    VACM for SNMPv3                 January 1998
+
+
+    STATUS       current
+    DESCRIPTION "The Security Model, by which the vacmSecurityName
+                 referenced by this entry is provided.
+
+                 Note, this object may not take the 'any' (0) value.
+                "
+    ::= { vacmSecurityToGroupEntry 1 }
+
+vacmSecurityName OBJECT-TYPE
+    SYNTAX       SnmpAdminString (SIZE(1..32))
+    MAX-ACCESS   not-accessible
+    STATUS       current
+    DESCRIPTION "The securityName for the principal, represented in a
+                 Security Model independent format, which is mapped by
+                 this entry to a groupName.
+
+                 The securityName for a principal represented in a
+                 Security Model independent format.
+                "
+    ::= { vacmSecurityToGroupEntry 2 }
+
+vacmGroupName    OBJECT-TYPE
+    SYNTAX       SnmpAdminString (SIZE(1..32))
+    MAX-ACCESS   read-create
+    STATUS       current
+    DESCRIPTION "The name of the group to which this entry (e.g., the
+                 combination of securityModel and securityName)
+                 belongs.
+
+                 This groupName is used as index into the
+                 vacmAccessTable to select an access control policy.
+                "
+    ::= { vacmSecurityToGroupEntry 3 }
+
+vacmSecurityToGroupStorageType OBJECT-TYPE
+    SYNTAX       StorageType
+    MAX-ACCESS   read-create
+    STATUS       current
+    DESCRIPTION "The storage type for this conceptual row.
+                 Conceptual rows having the value 'permanent' need not
+                 allow write-access to any columnar objects in the row.
+                "
+    DEFVAL      { nonVolatile }
+    ::= { vacmSecurityToGroupEntry 4 }
+
+vacmSecurityToGroupStatus OBJECT-TYPE
+    SYNTAX       RowStatus
+    MAX-ACCESS   read-create
+
+
+
+Wijnen, et. al.             Standards Track                    [Page 14]
+
+RFC 2265                    VACM for SNMPv3                 January 1998
+
+
+    STATUS       current
+    DESCRIPTION "The status of this conceptual row.
+
+                 The  RowStatus TC [RFC1903] requires that this
+                 DESCRIPTION clause states under which circumstances
+                 other objects in this row can be modified:
+
+                 The value of this object has no effect on whether
+                 other objects in this conceptual row can be modified.
+                "
+    ::= { vacmSecurityToGroupEntry 5 }
+
+-- Information about Access Rights ***********************************
+
+vacmAccessTable  OBJECT-TYPE
+    SYNTAX       SEQUENCE OF VacmAccessEntry
+    MAX-ACCESS   not-accessible
+    STATUS       current
+    DESCRIPTION "The table of access rights for groups.
+
+                 Each entry is indexed by a contextPrefix, a groupName
+                 a securityModel and a securityLevel.  To determine
+                 whether access is allowed, one entry from this table
+                 needs to be selected and the proper viewName from that
+                 entry must be used for access control checking.
+
+                 To select the proper entry, follow these steps:
+
+                 1) the set of possible matches is formed by the
+                    intersection of the following sets of entries:
+                      the set of entries with identical vacmGroupName
+                      the union of these two sets:
+                       - the set with identical vacmAccessContextPrefix
+                       - the set of entries with vacmAccessContextMatch
+                         value of 'prefix' and matching
+                         vacmAccessContextPrefix
+                      intersected with the union of these two sets:
+                       - the set of entries with identical
+                         vacmSecurityModel
+                       - the set of entries with vacmSecurityModel
+                         value of 'any'
+                      intersected with the set of entries with
+                      vacmAccessSecurityLevel value less than or equal
+                      to the requested securityLevel
+
+                 2) if this set has only one member, we're done
+                    otherwise, it comes down to deciding how to weight
+                    the preferences between ContextPrefixes,
+
+
+
+Wijnen, et. al.             Standards Track                    [Page 15]
+
+RFC 2265                    VACM for SNMPv3                 January 1998
+
+
+                    SecurityModels, and SecurityLevels as follows:
+                    a) if the subset of entries with identical
+                       securityModels is not empty, discard the rest.
+                    b) if the subset of entries with identical
+                       vacmAccessContextPrefix is not empty,
+                       discard the rest
+                    c) discard all entries with ContextPrefixes shorter
+                       than the longest one remaining in the set
+                    d) select the entry with the highest securityLevel
+
+                 Please note that for securityLevel noAuthNoPriv, all
+                 groups are really equivalent since the assumption that
+                 the securityName has been authenticated does not hold.
+                "
+    ::= { vacmMIBObjects 4 }
+
+vacmAccessEntry  OBJECT-TYPE
+    SYNTAX       VacmAccessEntry
+    MAX-ACCESS   not-accessible
+    STATUS       current
+    DESCRIPTION "An access right configured in the Local Configuration
+                 Datastore (LCD) authorizing access to an SNMP context.
+                "
+    INDEX       { vacmGroupName,
+                  vacmAccessContextPrefix,
+                  vacmAccessSecurityModel,
+                  vacmAccessSecurityLevel
+                }
+    ::= { vacmAccessTable 1 }
+
+VacmAccessEntry ::= SEQUENCE
+    {
+        vacmAccessContextPrefix    SnmpAdminString,
+        vacmAccessSecurityModel    SnmpSecurityModel,
+        vacmAccessSecurityLevel    SnmpSecurityLevel,
+        vacmAccessContextMatch     INTEGER,
+        vacmAccessReadViewName     SnmpAdminString,
+        vacmAccessWriteViewName    SnmpAdminString,
+        vacmAccessNotifyViewName   SnmpAdminString,
+        vacmAccessStorageType      StorageType,
+        vacmAccessStatus           RowStatus
+    }
+
+vacmAccessContextPrefix OBJECT-TYPE
+    SYNTAX       SnmpAdminString (SIZE(0..32))
+    MAX-ACCESS   not-accessible
+    STATUS       current
+    DESCRIPTION "In order to gain the access rights allowed by this
+
+
+
+Wijnen, et. al.             Standards Track                    [Page 16]
+
+RFC 2265                    VACM for SNMPv3                 January 1998
+
+
+                 conceptual row, a contextName must match exactly
+                 (if the value of vacmAccessContextMatch is 'exact')
+                 or partially (if the value of vacmAccessContextMatch
+                 is 'prefix') to the value of the instance of this
+                 object.
+                "
+    ::= { vacmAccessEntry 1 }
+
+vacmAccessSecurityModel OBJECT-TYPE
+    SYNTAX       SnmpSecurityModel
+    MAX-ACCESS   not-accessible
+    STATUS       current
+    DESCRIPTION "In order to gain the access rights allowed by this
+                 conceptual row, this securityModel must be in use.
+                "
+    ::= { vacmAccessEntry 2 }
+
+vacmAccessSecurityLevel OBJECT-TYPE
+    SYNTAX       SnmpSecurityLevel
+    MAX-ACCESS   not-accessible
+    STATUS       current
+    DESCRIPTION "The minimum level of security required in order to
+                 gain the access rights allowed by this conceptual
+                 row.  A securityLevel of noAuthNoPriv is less than
+                 authNoPriv which in turn is less than authPriv.
+
+                 If multiple entries are equally indexed except for
+                 this vacmAccessSecurityLevel index, then the entry
+                 which has the highest value for
+                 vacmAccessSecurityLevel wins.
+                "
+    ::= { vacmAccessEntry 3 }
+
+vacmAccessContextMatch OBJECT-TYPE
+    SYNTAX       INTEGER
+                { exact (1), -- exact match of prefix and contextName
+                  prefix (2) -- Only match to the prefix
+                }
+    MAX-ACCESS   read-create
+    STATUS       current
+    DESCRIPTION "If the value of this object is exact(1), then all
+                 rows where the contextName exactly matches
+                 vacmAccessContextPrefix are selected.
+
+                 If the value of this object is prefix(2), then all
+                 rows where the contextName whose starting octets
+                 exactly match vacmAccessContextPrefix are selected.
+                 This allows for a simple form of wildcarding.
+
+
+
+Wijnen, et. al.             Standards Track                    [Page 17]
+
+RFC 2265                    VACM for SNMPv3                 January 1998
+
+
+                 See also the example in the DESCRIPTION clause of
+                 the vacmAccessTable above.
+                "
+    ::= { vacmAccessEntry 4 }
+
+vacmAccessReadViewName OBJECT-TYPE
+    SYNTAX       SnmpAdminString (SIZE(0..32))
+    MAX-ACCESS   read-create
+    STATUS       current
+    DESCRIPTION "The value of an instance of this object identifies
+                 the MIB view of the SNMP context to which this
+                 conceptual row authorizes read access.
+
+                 The identified MIB view is that one for which the
+                 vacmViewTreeFamilyViewName has the same value as the
+                 instance of this object; if the value is the empty
+                 string or if there is no active MIB view having this
+                 value of vacmViewTreeFamilyViewName, then no access
+                 is granted.
+                "
+    DEFVAL      { ''H }   -- the empty string
+    ::= { vacmAccessEntry 5 }
+
+vacmAccessWriteViewName OBJECT-TYPE
+    SYNTAX       SnmpAdminString (SIZE(0..32))
+    MAX-ACCESS   read-create
+    STATUS       current
+    DESCRIPTION "The value of an instance of this object identifies
+                 the MIB view of the SNMP context to which this
+                 conceptual row authorizes write access.
+
+                 The identified MIB view is that one for which the
+                 vacmViewTreeFamilyViewName has the same value as the
+                 instance of this object; if the value is the empty
+                 string or if there is no active MIB view having this
+                 value of vacmViewTreeFamilyViewName, then no access
+                 is granted.
+                "
+    DEFVAL      { ''H }   -- the empty string
+    ::= { vacmAccessEntry 6 }
+
+vacmAccessNotifyViewName OBJECT-TYPE
+    SYNTAX       SnmpAdminString (SIZE(0..32))
+    MAX-ACCESS   read-create
+    STATUS       current
+    DESCRIPTION "The value of an instance of this object identifies
+                 the MIB view of the SNMP context to which this
+                 conceptual row authorizes access for notifications.
+
+
+
+Wijnen, et. al.             Standards Track                    [Page 18]
+
+RFC 2265                    VACM for SNMPv3                 January 1998
+
+
+                 The identified MIB view is that one for which the
+                 vacmViewTreeFamilyViewName has the same value as the
+                 instance of this object; if the value is the empty
+                 string or if there is no active MIB view having this
+                 value of vacmViewTreeFamilyViewName, then no access
+                 is granted.
+                "
+    DEFVAL      { ''H }   -- the empty string
+    ::= { vacmAccessEntry 7 }
+
+vacmAccessStorageType OBJECT-TYPE
+    SYNTAX       StorageType
+    MAX-ACCESS   read-create
+    STATUS       current
+    DESCRIPTION "The storage type for this conceptual row.
+
+                 Conceptual rows having the value 'permanent' need not
+                 allow write-access to any columnar objects in the row.
+                "
+    DEFVAL      { nonVolatile }
+    ::= { vacmAccessEntry 8 }
+
+vacmAccessStatus OBJECT-TYPE
+    SYNTAX       RowStatus
+    MAX-ACCESS   read-create
+    STATUS       current
+    DESCRIPTION "The status of this conceptual row.
+
+                 The  RowStatus TC [RFC1903] requires that this
+                 DESCRIPTION clause states under which circumstances
+                 other objects in this row can be modified:
+
+                 The value of this object has no effect on whether
+                 other objects in this conceptual row can be modified.
+                "
+    ::= { vacmAccessEntry 9 }
+
+-- Information about MIB views ***************************************
+
+-- Support for instance-level granularity is optional.
+--
+-- In some implementations, instance-level access control
+-- granularity may come at a high performance cost.  Managers
+-- should avoid requesting such configurations unnecessarily.
+
+vacmMIBViews     OBJECT IDENTIFIER ::= { vacmMIBObjects 5 }
+
+vacmViewSpinLock OBJECT-TYPE
+
+
+
+Wijnen, et. al.             Standards Track                    [Page 19]
+
+RFC 2265                    VACM for SNMPv3                 January 1998
+
+
+    SYNTAX       TestAndIncr
+    MAX-ACCESS   read-write
+    STATUS       current
+    DESCRIPTION "An advisory lock used to allow cooperating SNMP
+                 Command Generator applications to coordinate their
+                 use of the Set operation in creating or modifying
+                 views.
+
+                 When creating a new view or altering an existing
+                 view, it is important to understand the potential
+                 interactions with other uses of the view.  The
+                 vacmViewSpinLock should be retrieved.  The name of
+                 the view to be created should be determined to be
+                 unique by the SNMP Command Generator application by
+                 consulting the vacmViewTreeFamilyTable.  Finally,
+                 the named view may be created (Set), including the
+                 advisory lock.
+                 If another SNMP Command Generator application has
+                 altered the views in the meantime, then the spin
+                 lock's value will have changed, and so this creation
+                 will fail because it will specify the wrong value for
+                 the spin lock.
+
+                 Since this is an advisory lock, the use of this lock
+                 is not enforced.
+                "
+    ::= { vacmMIBViews 1 }
+
+vacmViewTreeFamilyTable OBJECT-TYPE
+    SYNTAX       SEQUENCE OF VacmViewTreeFamilyEntry
+    MAX-ACCESS   not-accessible
+    STATUS       current
+    DESCRIPTION "Locally held information about families of subtrees
+                 within MIB views.
+
+                 Each MIB view is defined by two sets of view subtrees:
+                   - the included view subtrees, and
+                   - the excluded view subtrees.
+                 Every such view subtree, both the included and the
+                 excluded ones, is defined in this table.
+
+                 To determine if a particular object instance is in
+                 a particular MIB view, compare the object instance's
+                 OBJECT IDENTIFIER with each of the MIB view's active
+                 entries in this table.  If none match, then the
+                 object instance is not in the MIB view.  If one or
+                 more match, then the object instance is included in,
+                 or excluded from, the MIB view according to the
+
+
+
+Wijnen, et. al.             Standards Track                    [Page 20]
+
+RFC 2265                    VACM for SNMPv3                 January 1998
+
+
+                 value of vacmViewTreeFamilyType in the entry whose
+                 value of vacmViewTreeFamilySubtree has the most
+                 sub-identifiers.  If multiple entries match and have
+                 the same number of sub-identifiers, then the
+                 lexicographically greatest instance of
+                 vacmViewTreeFamilyType determines the inclusion or
+                 exclusion.
+
+                 An object instance's OBJECT IDENTIFIER X matches an
+                 active entry in this table when the number of
+                 sub-identifiers in X is at least as many as in the
+                 value of vacmViewTreeFamilySubtree for the entry,
+                 and each sub-identifier in the value of
+                 vacmViewTreeFamilySubtree matches its corresponding
+                 sub-identifier in X.  Two sub-identifiers match
+                 either if the corresponding bit of the value of
+                 vacmViewTreeFamilyMask for the entry is zero (the
+                 'wild card' value), or if they are equal.
+
+                 A 'family' of subtrees is the set of subtrees defined
+                 by a particular combination of values of
+                 vacmViewTreeFamilySubtree and vacmViewTreeFamilyMask.
+                 In the case where no 'wild card' is defined in the
+                 vacmViewTreeFamilyMask, the family of subtrees reduces
+                 to a single subtree.
+
+                 When creating or changing MIB views, an SNMP Command
+                 Generator application should utilize the
+                 vacmViewSpinLock to try to avoid collisions. See
+                 DESCRIPTION clause of vacmViewSpinLock.
+
+                 When creating MIB views, it is strongly advised that
+                 first the 'excluded' vacmViewTreeFamilyEntries are
+                 created and then the 'included' entries.
+
+                 When deleting MIB views, it is strongly advised that
+                 first the 'included' vacmViewTreeFamilyEntries are
+                 deleted and then the 'excluded' entries.
+
+                 If a create for an entry for instance-level access
+                 control is received and the implementation does not
+                 support instance-level granularity, then an
+                 inconsistentName error must be returned.
+                "
+    ::= { vacmMIBViews 2 }
+
+vacmViewTreeFamilyEntry OBJECT-TYPE
+    SYNTAX       VacmViewTreeFamilyEntry
+
+
+
+Wijnen, et. al.             Standards Track                    [Page 21]
+
+RFC 2265                    VACM for SNMPv3                 January 1998
+
+
+    MAX-ACCESS   not-accessible
+    STATUS       current
+    DESCRIPTION "Information on a particular family of view subtrees
+                 included in or excluded from a particular SNMP
+                 context's MIB view.
+
+                 Implementations must not restrict the number of
+                 families of view subtrees for a given MIB view,
+                 except as dictated by resource constraints on the
+                 overall number of entries in the
+                 vacmViewTreeFamilyTable.
+
+                 If no conceptual rows exist in this table for a given
+                 MIB view (viewName), that view may be thought of as
+                 consisting of the empty set of view subtrees.
+                "
+    INDEX       { vacmViewTreeFamilyViewName,
+                  vacmViewTreeFamilySubtree
+                }
+    ::= { vacmViewTreeFamilyTable 1 }
+
+VacmViewTreeFamilyEntry ::= SEQUENCE
+    {
+        vacmViewTreeFamilyViewName     SnmpAdminString,
+        vacmViewTreeFamilySubtree      OBJECT IDENTIFIER,
+        vacmViewTreeFamilyMask         OCTET STRING,
+        vacmViewTreeFamilyType         INTEGER,
+        vacmViewTreeFamilyStorageType  StorageType,
+        vacmViewTreeFamilyStatus       RowStatus
+    }
+
+vacmViewTreeFamilyViewName OBJECT-TYPE
+    SYNTAX       SnmpAdminString (SIZE(1..32))
+    MAX-ACCESS   not-accessible
+    STATUS       current
+    DESCRIPTION "The human readable name for a family of view subtrees.
+                "
+    ::= { vacmViewTreeFamilyEntry 1 }
+
+vacmViewTreeFamilySubtree OBJECT-TYPE
+    SYNTAX       OBJECT IDENTIFIER
+    MAX-ACCESS   not-accessible
+    STATUS       current
+    DESCRIPTION "The MIB subtree which when combined with the
+                 corresponding instance of vacmViewTreeFamilyMask
+                 defines a family of view subtrees.
+                "
+    ::= { vacmViewTreeFamilyEntry 2 }
+
+
+
+Wijnen, et. al.             Standards Track                    [Page 22]
+
+RFC 2265                    VACM for SNMPv3                 January 1998
+
+
+vacmViewTreeFamilyMask OBJECT-TYPE
+    SYNTAX       OCTET STRING (SIZE (0..16))
+    MAX-ACCESS   read-create
+    STATUS       current
+    DESCRIPTION "The bit mask which, in combination with the
+                 corresponding instance of vacmViewTreeFamilySubtree,
+                 defines a family of view subtrees.
+
+                 Each bit of this bit mask corresponds to a
+                 sub-identifier of vacmViewTreeFamilySubtree, with the
+                 most significant bit of the i-th octet of this octet
+                 string value (extended if necessary, see below)
+                 corresponding to the (8*i - 7)-th sub-identifier, and
+                 the least significant bit of the i-th octet of this
+                 octet string corresponding to the (8*i)-th
+                 sub-identifier, where i is in the range 1 through 16.
+
+                 Each bit of this bit mask specifies whether or not
+                 the corresponding sub-identifiers must match when
+                 determining if an OBJECT IDENTIFIER is in this
+                 family of view subtrees; a '1' indicates that an
+                 exact match must occur; a '0' indicates 'wild card',
+                 i.e., any sub-identifier value matches.
+
+                 Thus, the OBJECT IDENTIFIER X of an object instance
+                 is contained in a family of view subtrees if, for
+                 each sub-identifier of the value of
+                 vacmViewTreeFamilySubtree, either:
+
+                   the i-th bit of vacmViewTreeFamilyMask is 0, or
+
+                   the i-th sub-identifier of X is equal to the i-th
+                   sub-identifier of the value of
+                   vacmViewTreeFamilySubtree.
+
+                 If the value of this bit mask is M bits long and
+                 there are more than M sub-identifiers in the
+                 corresponding instance of vacmViewTreeFamilySubtree,
+                 then the bit mask is extended with 1's to be the
+                 required length.
+
+                 Note that when the value of this object is the
+                 zero-length string, this extension rule results in
+                 a mask of all-1's being used (i.e., no 'wild card'),
+                 and the family of view subtrees is the one view
+                 subtree uniquely identified by the corresponding
+                 instance of vacmViewTreeFamilySubtree.
+
+
+
+
+Wijnen, et. al.             Standards Track                    [Page 23]
+
+RFC 2265                    VACM for SNMPv3                 January 1998
+
+
+                 Note that masks of length greater than zero length
+                 do not need to be supported. In this case this
+                 object is made read-only.
+                "
+    DEFVAL      { ''H }
+    ::= { vacmViewTreeFamilyEntry 3 }
+
+vacmViewTreeFamilyType OBJECT-TYPE
+    SYNTAX       INTEGER  { included(1), excluded(2) }
+    MAX-ACCESS   read-create
+    STATUS       current
+    DESCRIPTION "Indicates whether the corresponding instances of
+                 vacmViewTreeFamilySubtree and vacmViewTreeFamilyMask
+                 define a family of view subtrees which is included in
+                 or excluded from the MIB view.
+                "
+    DEFVAL      { included }
+    ::= { vacmViewTreeFamilyEntry 4 }
+
+vacmViewTreeFamilyStorageType OBJECT-TYPE
+    SYNTAX       StorageType
+    MAX-ACCESS   read-create
+    STATUS       current
+    DESCRIPTION "The storage type for this conceptual row.
+
+                 Conceptual rows having the value 'permanent' need not
+                 allow write-access to any columnar objects in the row.
+                "
+    DEFVAL      { nonVolatile }
+    ::= { vacmViewTreeFamilyEntry 5 }
+
+vacmViewTreeFamilyStatus OBJECT-TYPE
+    SYNTAX       RowStatus
+    MAX-ACCESS   read-create
+    STATUS       current
+    DESCRIPTION "The status of this conceptual row.
+
+                 The  RowStatus TC [RFC1903] requires that this
+                 DESCRIPTION clause states under which circumstances
+                 other objects in this row can be modified:
+
+                 The value of this object has no effect on whether
+                 other objects in this conceptual row can be modified.
+                "
+    ::= { vacmViewTreeFamilyEntry 6 }
+
+-- Conformance information *******************************************
+
+
+
+
+Wijnen, et. al.             Standards Track                    [Page 24]
+
+RFC 2265                    VACM for SNMPv3                 January 1998
+
+
+vacmMIBCompliances  OBJECT IDENTIFIER ::= { vacmMIBConformance 1 }
+vacmMIBGroups       OBJECT IDENTIFIER ::= { vacmMIBConformance 2 }
+
+-- Compliance statements *********************************************
+
+vacmMIBCompliance MODULE-COMPLIANCE
+    STATUS       current
+    DESCRIPTION "The compliance statement for SNMP engines which
+                 implement the SNMP View-based Access Control Model
+                 configuration MIB.
+                "
+    MODULE -- this module
+        MANDATORY-GROUPS { vacmBasicGroup }
+
+        OBJECT        vacmAccessContextMatch
+        MIN-ACCESS    read-only
+        DESCRIPTION  "Write access is not required."
+        OBJECT        vacmAccessReadViewName
+        MIN-ACCESS    read-only
+        DESCRIPTION  "Write access is not required."
+
+        OBJECT        vacmAccessWriteViewName
+        MIN-ACCESS    read-only
+        DESCRIPTION  "Write access is not required."
+
+        OBJECT        vacmAccessNotifyViewName
+        MIN-ACCESS    read-only
+        DESCRIPTION  "Write access is not required."
+
+        OBJECT        vacmAccessStorageType
+        MIN-ACCESS    read-only
+        DESCRIPTION  "Write access is not required."
+
+        OBJECT        vacmAccessStatus
+        MIN-ACCESS    read-only
+        DESCRIPTION  "Create/delete/modify access to the
+                      vacmAccessTable is not required.
+                     "
+
+        OBJECT        vacmViewTreeFamilyMask
+        WRITE-SYNTAX  OCTET STRING (SIZE (0))
+        MIN-ACCESS    read-only
+        DESCRIPTION  "Support for configuration via SNMP of subtree
+                      families using wild-cards is not required.
+                     "
+
+        OBJECT        vacmViewTreeFamilyType
+        MIN-ACCESS    read-only
+
+
+
+Wijnen, et. al.             Standards Track                    [Page 25]
+
+RFC 2265                    VACM for SNMPv3                 January 1998
+
+
+        DESCRIPTION  "Write access is not required."
+
+        OBJECT        vacmViewTreeFamilyStorageType
+        MIN-ACCESS    read-only
+        DESCRIPTION  "Write access is not required."
+
+        OBJECT        vacmViewTreeFamilyStatus
+        MIN-ACCESS    read-only
+        DESCRIPTION  "Create/delete/modify access to the
+                      vacmViewTreeFamilyTable is not required.
+                     "
+    ::= { vacmMIBCompliances 1 }
+
+-- Units of conformance **********************************************
+
+vacmBasicGroup OBJECT-GROUP
+    OBJECTS {
+              vacmContextName,
+              vacmGroupName,
+              vacmSecurityToGroupStorageType,
+              vacmSecurityToGroupStatus,
+              vacmAccessContextMatch,
+              vacmAccessReadViewName,
+              vacmAccessWriteViewName,
+              vacmAccessNotifyViewName,
+              vacmAccessStorageType,
+              vacmAccessStatus,
+              vacmViewSpinLock,
+              vacmViewTreeFamilyMask,
+              vacmViewTreeFamilyType,
+              vacmViewTreeFamilyStorageType,
+              vacmViewTreeFamilyStatus
+            }
+    STATUS       current
+    DESCRIPTION "A collection of objects providing for remote
+                 configuration of an SNMP engine which implements
+                 the SNMP View-based Access Control Model.
+                "
+    ::= { vacmMIBGroups 1 }
+
+END
+
+5.  Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   intellectual property or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+
+
+
+Wijnen, et. al.             Standards Track                    [Page 26]
+
+RFC 2265                    VACM for SNMPv3                 January 1998
+
+
+   might or might not be available; neither does it represent that it
+   has made any effort to identify any such rights.  Information on the
+   IETF's procedures with respect to rights in standards-track and
+   standards-related documentation can be found in BCP-11.  Copies of
+   claims of rights made available for publication and any assurances of
+   licenses to be made available, or the result of an attempt made to
+   obtain a general license or permission for the use of such
+   proprietary rights by implementors or users of this specification can
+   be obtained from the IETF Secretariat.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights which may cover technology that may be required to practice
+   this standard.  Please address the information to the IETF Executive
+   Director.
+
+6.  Acknowledgements
+
+   This document is the result of the efforts of the SNMPv3 Working
+   Group.  Some special thanks are in order to the following SNMPv3 WG
+   members:
+
+   Dave Battle (SNMP Research, Inc.)
+   Uri Blumenthal (IBM T.J. Watson Research Center)
+   Jeff Case (SNMP Research, Inc.)
+   John Curran (BBN)
+   T. Max Devlin (Hi-TECH Connections)
+   John Flick (Hewlett Packard)
+   David Harrington (Cabletron Systems Inc.)
+   N.C. Hien (IBM T.J. Watson Research Center)
+   Dave Levi (SNMP Research, Inc.)
+   Louis A Mamakos (UUNET Technologies Inc.)
+   Paul Meyer (Secure Computing Corporation)
+   Keith McCloghrie (Cisco Systems)
+   Russ Mundy (Trusted Information Systems, Inc.)
+   Bob Natale (ACE*COMM Corporation)
+   Mike O'Dell (UUNET Technologies Inc.)
+   Dave Perkins (DeskTalk)
+   Peter Polkinghorne (Brunel University)
+   Randy Presuhn (BMC Software, Inc.)
+   David Reid (SNMP Research, Inc.)
+   Shawn Routhier (Epilogue)
+   Juergen Schoenwaelder (TU Braunschweig)
+   Bob Stewart (Cisco Systems)
+   Bert Wijnen (IBM T.J. Watson Research Center)
+
+
+
+
+
+
+Wijnen, et. al.             Standards Track                    [Page 27]
+
+RFC 2265                    VACM for SNMPv3                 January 1998
+
+
+   The document is based on recommendations of the IETF Security and
+   Administrative Framework Evolution for SNMP Advisory Team.  Members
+   of that Advisory Team were:
+
+   David Harrington (Cabletron Systems Inc.)
+   Jeff Johnson (Cisco Systems)
+   David Levi (SNMP Research Inc.)
+   John Linn (Openvision)
+   Russ Mundy (Trusted Information Systems) chair
+   Shawn Routhier (Epilogue)
+   Glenn Waters (Nortel)
+   Bert Wijnen (IBM T. J. Watson Research Center)
+
+   As recommended by the Advisory Team and the SNMPv3 Working Group
+   Charter, the design incorporates as much as practical from previous
+   RFCs and drafts. As a result, special thanks are due to the authors
+   of previous designs known as SNMPv2u and SNMPv2*:
+
+   Jeff Case (SNMP Research, Inc.)
+   David Harrington (Cabletron Systems Inc.)
+   David Levi (SNMP Research, Inc.)
+   Keith McCloghrie (Cisco Systems)
+   Brian O'Keefe (Hewlett Packard)
+   Marshall T. Rose (Dover Beach Consulting)
+   Jon Saperia (BGS Systems Inc.)
+   Steve Waldbusser (International Network Services)
+   Glenn W. Waters (Bell-Northern Research Ltd.)
+
+7.  Security Considerations
+
+7.1.  Recommended Practices
+
+   This document is meant for use in the SNMP architecture.  The View-
+   based Access Control Model described in this document checks access
+   rights to management information based on:
+
+   - contextName, representing a set of management information at the
+     managed system where the Access Control module is running.
+   - groupName, representing a set of zero or more securityNames.
+     The combination of a securityModel and a securityName is mapped
+     into a group in the View-based Access Control Model.
+   - securityModel under which access is requested.
+   - securityLevel under which access is requested.
+   - operation performed on the management information.
+   - MIB views for read, write or notify access.
+
+
+
+
+
+
+Wijnen, et. al.             Standards Track                    [Page 28]
+
+RFC 2265                    VACM for SNMPv3                 January 1998
+
+
+   When the User-based Access Control module is called for checking
+   access rights, it is assumed that the calling module has ensured the
+   authentication and privacy aspects as specified by the securityLevel
+   that is being passed.
+
+   When creating entries in or deleting entries from the
+   vacmViewFamiliyTreeTable it is important to do such in the sequence
+   as recommended in the DESCRIPTION clause of the vacmViewFamilityTable
+   definition. Otherwise unwanted access may be granted while changing
+   the entries in the table.
+
+7.2.  Defining Groups
+
+   The groupNames are used to give access to a group of zero or more
+   securityNames.  Within the View-Based Access Control Model, a
+   groupName is considered to exist if that groupName is listed in the
+   vacmSecurityToGroupTable.
+
+   By mapping the combination of a securityModel and securityName into a
+   groupName, an SNMP Command Generator application can add/delete
+   securityNames to/from a group, if proper access is allowed.
+
+   Further it is important to realize that the grouping of
+   <securityModel, securityName> tuples in the vacmSecurityToGroupTable
+   does not take securityLevel into account. It is therefore important
+   that the security administrator uses the securityLevel index in the
+   vacmAccessTable to separate noAuthNoPriv from authPriv and/or
+   authNoPriv access.
+
+7.3.  Conformance
+
+   For an implementation of the View-based Access Control Model to be
+   conformant, it MUST implement the SNMP-VIEW-BASED-ACM-MIB.  It also
+   SHOULD implement the initial configuration, described in appendix A.
+
+8.  References
+
+   [RFC1902] Case, J., McCloghrie, K., Rose, M. and S., Waldbusser,
+        "Structure of Management Information for Version  2 of the
+        Simple Network Management Protocol (SNMPv2)", RFC 1902, January
+        1996.
+
+   [RFC1903] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
+        "Textual Conventions for Version 2 of the Simple Network
+        Management Protocol (SNMPv2)", RFC 1903, January 1996.
+
+   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+        Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+
+
+Wijnen, et. al.             Standards Track                    [Page 29]
+
+RFC 2265                    VACM for SNMPv3                 January 1998
+
+
+   [RFC2261] Harrington, D., Presuhn, R., and B. Wijnen,
+        "An Architecture for describing SNMP Management Frameworks", RFC
+        2261, January 1998.
+
+   [RFC2262] Case, J., Harrington, D., Presuhn, R., and B. Wijnen,
+        "Message Processing and Dispatching for the Simple Network
+        Management Protocol (SNMP)", RFC 2262, January 1998.
+
+   [RFC2264] Blumenthal, U., and B. Wijnen, "User-based
+        Security Model (USM) for version 3 of the Simple Network
+        Management Protocol (SNMPv3)", RFC 2264, January 1998.
+
+   [ISO-ASN.1] Information processing systems - Open Systems
+        Interconnection - Specification of Abstract Syntax Notation One
+        (ASN.1), International Organization for Standardization.
+        International Standard 8824, (December, 1987).
+
+9.  Editors' Addresses
+
+   Bert Wijnen
+   IBM T. J. Watson Research
+   Schagen 33
+   3461 GL Linschoten
+   Netherlands
+
+   EMail:      wijnen@vnet.ibm.com
+   Phone:      +31-348-432-794
+
+
+   Randy Presuhn
+   BMC Software, Inc
+   1190 Saratoga Avenue, Suite 130
+   San Jose, CA  95129-3433
+   USA
+
+   EMail:      rpresuhn@bmc.com
+   Phone:      +1-408-556-0720
+
+
+   Keith McCloghrie
+   Cisco Systems, Inc.
+   170 West Tasman Drive
+   San Jose, CA  95134-1706
+   USA
+
+   EMail:      kzm@cisco.com
+   Phone:      +1-408-526-5260
+
+
+
+
+Wijnen, et. al.             Standards Track                    [Page 30]
+
+RFC 2265                    VACM for SNMPv3                 January 1998
+
+
+APPENDIX A - Installation
+
+A.1.  Installation Parameters
+
+   During installation, an authoritative SNMP engine which supports this
+   View-based Access Control Model SHOULD be configured with several
+   initial parameters.  These include for the View-based Access Control
+   Model:
+
+1) A security configuration
+
+   The choice of security configuration determines if initial
+   configuration is implemented and if so how.  One of three possible
+   choices is selected:
+
+        - initial-minimum-security-configuration
+        - initial-semi-security-configuration
+        - initial-no-access-configuration
+
+   In the case of a initial-no-access-configuration, there is no initial
+   configuration, and so the following steps are irrelevant.
+
+2) A default context
+
+   One entry in the vacmContextTable with a contextName of "" (the empty
+   string), representing the default context.  Note that this table gets
+   created automatically if a default context exists.
+
+                                 no privacy support  privacy support
+                                 ------------------  ---------------
+    vacmContextName              ""                  ""
+
+3) An initial group
+
+   One entry in the vacmSecurityToGroupTable to allow access to group
+   "initial".
+
+                                 no privacy support  privacy support
+                                 ------------------  ---------------
+  vacmSecurityModel              3 (USM)             3 (USM)
+  vacmSecurityName               "initial"           "initial"
+  vacmGroupName                  "initial"           "initial"
+  vacmSecurityToGroupStorageType anyValidStorageType anyValidStorageType
+  vacmSecurityToGroupStatus      active              active
+
+
+
+
+
+
+
+Wijnen, et. al.             Standards Track                    [Page 31]
+
+RFC 2265                    VACM for SNMPv3                 January 1998
+
+
+4) Initial access rights
+
+   Three entries in the vacmAccessTable as follows:
+
+   - read-notify access for securityModel USM, securityLevel
+     "noAuthNoPriv" on behalf of securityNames that belong to the group
+     "initial" to the <restricted> MIB view in the default context with
+     contextName "".
+
+   - read-write-notify access for securityModel USM, securityLevel
+     "authNoPriv" on behalf of securityNames that belong to the group
+     "initial" to the <internet> MIB view in the default context with
+     contextName "".
+
+   - if privacy is supported,
+     read-write-notify access for securityModel USM, securityLevel
+     "authPriv" on behalf of securityNames that belong to the group
+     "initial" to the <internet> MIB view in the default context with
+     contextName "".
+
+   That translates into the following entries in the vacmAccessTable.
+   Those columns marked with (index) are index-only objects and are not
+   really present in this table.
+
+   - One entry to be used for unauthenticated access (noAuthNoPriv):
+
+
+                               no privacy support  privacy support
+                               ------------------  ---------------
+    vacmAccessContextPrefix    ""                  ""
+    vacmGroupName     (index)  "initial"           "initial"
+    vacmSecurityModel (index)  3 (USM)             3 (USM)
+    vacmAccessSecurityLevel    noAuthNoPriv        noAuthNoPriv
+    vacmAccessReadViewName     "restricted"        "restricted"
+    vacmAccessWriteViewName    ""                  ""
+    vacmAccessNotifyViewName   "restricted"        "restricted"
+    vacmAccessStorageType      anyValidStorageType anyValidStorageType
+    vacmAccessStatus           active              active
+
+   - One entry to be used for authenticated access but without
+     privacy (authNoPriv):
+                               no privacy support  privacy support
+                               ------------------  ---------------
+    vacmAccessContextPrefix    ""                  ""
+    vacmGroupName     (index)  "initial"           "initial"
+    vacmSecurityModel (index)  3 (USM)             3 (USM)
+    vacmAccessSecurityLevel    authNoPriv          authNoPriv
+    vacmAccessReadViewName     "internet"          "internet"
+
+
+
+Wijnen, et. al.             Standards Track                    [Page 32]
+
+RFC 2265                    VACM for SNMPv3                 January 1998
+
+
+    vacmAccessWriteViewName    "internet"          "internet"
+    vacmAccessNotifyViewName   "internet"          "internet"
+    vacmAccessStorageType      anyValidStorageType anyValidStorageType
+    vacmAccessStatus           active              active
+
+   - One entry to be used for authenticated access with privacy
+     (authPriv):
+
+                               no privacy support  privacy support
+                               ------------------  ---------------
+    vacmAccessContextPrefix                        ""
+    vacmGroupName     (index)                      "initial"
+    vacmSecurityModel (index)                      3 (USM)
+    vacmAccessSecurityLevel                        authPriv
+    vacmAccessReadViewName                         "internet"
+    vacmAccessWriteViewName                        "internet"
+    vacmAccessNotifyViewName                       "internet"
+    vacmAccessStorageType                          anyValidStorageType
+    vacmAccessStatus                               active
+
+5) Two MIB views, of which the second one depends on the security
+   configuration.
+
+   -  One view, the <internet> view, for authenticated access:
+
+      -  the <internet> MIB view is the following subtree:
+             "internet"  (subtree 1.3.6.1)
+
+   -  A second view, the <restricted> view, for unauthenticated
+      access.  This view is configured according to the selected
+      security configuration:
+
+      -  For the initial-no-access-configuration there is no default
+         initial configuration, so no MIB views are pre-scribed.
+
+      -  For the initial-semi-secure-configuration:
+
+         the <restricted> MIB view is the union of these subtrees:
+         (a) "system"       (subtree 1.3.6.1.2.1.1)     [RFC1907]
+         (b) "snmp"         (subtree 1.3.6.1.2.1.11)    [RFC1907]
+         (c) "snmpEngine"   (subtree 1.3.6.1.6.3.7.2.1) [RFC2261]
+         (d) "snmpMPDStats" (subtree 1.3.6.1.6.3.8.2.1) [RFC2262]
+         (e) "usmStats"     (subtree 1.3.6.1.6.3.9.2.1) [RFC2264]
+
+      -  For the initial-minimum-secure-configuration:
+
+         the <restricted> MIB view is the following subtree.
+             "internet"  (subtree 1.3.6.1)
+
+
+
+Wijnen, et. al.             Standards Track                    [Page 33]
+
+RFC 2265                    VACM for SNMPv3                 January 1998
+
+
+   This translates into the following "internet" entry in the
+   vacmViewTreeFamilyTable:
+
+                                minimum-secure      semi-secure
+                                ----------------    ---------------
+  vacmViewTreeFamilyViewName    "internet"          "internet"
+  vacmViewTreeFamilySubtree     1.3.6.1             1.3.6.1
+  vacmViewTreeFamilyMask        ""                  ""
+  vacmViewTreeFamilyType        1 (included)        1 (included)
+  vacmViewTreeFamilyStorageType anyValidStorageType anyValidStorageType
+  vacmViewTreeFamilyStatus      active              active
+
+   In addition it translates into the following "restricted" entries
+   in the vacmViewTreeFamilyTable:
+
+                                minimum-secure      semi-secure
+                                ----------------    ---------------
+  vacmViewTreeFamilyViewName    "restricted"        "restricted"
+  vacmViewTreeFamilySubtree     1.3.6.1             1.3.6.1.2.1.1
+  vacmViewTreeFamilyMask        ""                  ""
+  vacmViewTreeFamilyType        1 (included)        1 (included)
+  vacmViewTreeFamilyStorageType anyValidStorageType anyValidStorageType
+  vacmViewTreeFamilyStatus      active              active
+
+  vacmViewTreeFamilyViewName                        "restricted"
+  vacmViewTreeFamilySubtree                         1.3.6.1.2.1.11
+  vacmViewTreeFamilyMask                            ""
+  vacmViewTreeFamilyType                            1 (included)
+  vacmViewTreeFamilyStorageType                     anyValidStorageType
+  vacmViewTreeFamilyStatus                          active
+
+  vacmViewTreeFamilyViewName                        "restricted"
+  vacmViewTreeFamilySubtree                         1.3.6.1.6.3.7.2.1
+  vacmViewTreeFamilyMask                            ""
+  vacmViewTreeFamilyType                            1 (included)
+  vacmViewTreeFamilyStorageType                     anyValidStorageType
+  vacmViewTreeFamilyStatus                          active
+
+  vacmViewTreeFamilyViewName                        "restricted"
+  vacmViewTreeFamilySubtree                         1.3.6.1.6.3.8.2.1
+  vacmViewTreeFamilyMask                            ""
+  vacmViewTreeFamilyType                            1 (included)
+  vacmViewTreeFamilyStorageType                     anyValidStorageType
+  vacmViewTreeFamilyStatus                          active
+
+  vacmViewTreeFamilyViewName                        "restricted"
+  vacmViewTreeFamilySubtree                         1.3.6.1.6.3.9.2.1
+  vacmViewTreeFamilyMask                            ""
+
+
+
+Wijnen, et. al.             Standards Track                    [Page 34]
+
+RFC 2265                    VACM for SNMPv3                 January 1998
+
+
+  vacmViewTreeFamilyType                            1 (included)
+  vacmViewTreeFamilyStorageType                     anyValidStorageType
+  vacmViewTreeFamilyStatus                          active
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wijnen, et. al.             Standards Track                    [Page 35]
+
+RFC 2265                    VACM for SNMPv3                 January 1998
+
+
+B.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (1997).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wijnen, et. al.             Standards Track                    [Page 36]
+