home *** CD-ROM | disk | FTP | other *** search
/ The Hacker's Encyclopedia 1998 / hackers_encyclopedia.iso / rfc / 3 / rfc2265.txt < prev    next >
Encoding:
Text File  |  2003-06-11  |  76.0 KB  |  2,021 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                          B. Wijnen
  8. Request for Comments: 2265                     IBM T. J. Watson Research
  9. Category: Standards Track                                     R. Presuhn
  10.                                                       BMC Software, Inc.
  11.                                                            K. McCloghrie
  12.                                                      Cisco Systems, Inc.
  13.                                                             January 1998
  14.  
  15.              View-based Access Control Model (VACM) for the
  16.                Simple Network Management Protocol (SNMP)
  17.  
  18. Status of this Memo
  19.  
  20.    This document specifies an Internet standards track protocol for the
  21.    Internet community, and requests discussion and suggestions for
  22.    improvements.  Please refer to the current edition of the "Internet
  23.    Official Protocol Standards" (STD 1) for the standardization state
  24.    and status of this protocol.  Distribution of this memo is unlimited.
  25.  
  26. Copyright Notice
  27.  
  28.    Copyright (C) The Internet Society (1997).  All Rights Reserved.
  29.  
  30. Abstract
  31.  
  32.    This document describes the View-based Access Control Model for use
  33.    in the SNMP architecture [RFC2261].  It defines the Elements of
  34.    Procedure for controlling access to management information.  This
  35.    document also includes a MIB for remotely managing the configuration
  36.    parameters for the View-based Access Control Model.
  37.  
  38. Table of Contents
  39.  
  40.    1.  Introduction                                             2
  41.    1.2.  Access Control                                         2
  42.    1.3.  Local Configuration Datastore                          3
  43.    2.  Elements of the Model                                    3
  44.    2.1.  Groups                                                 3
  45.    2.2.  securityLevel                                          4
  46.    2.3.  Contexts                                               4
  47.    2.4.  MIB Views and View Families                            4
  48.    2.4.1.  View Subtree                                         5
  49.    2.4.2.  ViewTreeFamily                                       5
  50.    2.5.  Access Policy                                          6
  51.    3.  Elements of Procedure                                    6
  52.    3.1.  Overview  of isAccessAllowed Process                   8
  53.    3.2.  Processing the isAccessAllowed Service Request         9
  54.    4.  Definitions                                             10
  55.  
  56.  
  57.  
  58. Wijnen, et. al.             Standards Track                     [Page 1]
  59.  
  60. RFC 2265                    VACM for SNMPv3                 January 1998
  61.  
  62.  
  63.    5.  Intellectual Property                                   26
  64.    6.  Acknowledgements                                        27
  65.    7.  Security Considerations                                 28
  66.    7.1.  Recommended Practices                                 28
  67.    7.2.  Defining Groups                                       29
  68.    7.3.  Conformance                                           29
  69.    8.  References                                              29
  70.    9.  Editors' Addresses                                      30
  71.    A.1.  Installation Parameters                               31
  72.    B.  Full Copyright Statement                                36
  73.  
  74. 1.  Introduction
  75.  
  76.    The Architecture for describing Internet Management Frameworks
  77.    [RFC2261] describes that an SNMP engine is composed of:
  78.  
  79.      1) a Dispatcher
  80.      2) a Message Processing Subsystem,
  81.      3) a Security Subsystem, and
  82.      4) an Access Control Subsystem.
  83.  
  84.    Applications make use of the services of these subsystems.
  85.  
  86.    It is important to understand the SNMP architecture and its
  87.    terminology to understand where the View-based Access Control Model
  88.    described in this document fits into the architecture and interacts
  89.    with other subsystems within the architecture.  The reader is
  90.    expected to have read and understood the description and terminology
  91.    of the SNMP architecture, as defined in [RFC2261].
  92.  
  93.    The Access Control Subsystem of an SNMP engine has the responsibility
  94.    for checking whether a specific type of access (read, write, notify)
  95.    to a particular object (instance) is allowed.
  96.  
  97.    It is the purpose of this document to define a specific model of the
  98.    Access Control Subsystem, designated the View-based Access Control
  99.    Model. Note that this is not necessarily the only Access Control
  100.    Model.
  101.  
  102.    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  103.    "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
  104.    document are to be interpreted as described in [RFC2119].
  105.  
  106. 1.2.  Access Control
  107.  
  108.    Access Control occurs (either implicitly or explicitly) in an SNMP
  109.    entity when processing SNMP retrieval or modification request
  110.    messages from an SNMP entity.  For example a Command Responder
  111.  
  112.  
  113.  
  114. Wijnen, et. al.             Standards Track                     [Page 2]
  115.  
  116. RFC 2265                    VACM for SNMPv3                 January 1998
  117.  
  118.  
  119.    application applies Access Control when processing requests that it
  120.    received from a Command Generator application.  These requests
  121.    include these types of operations: GetRequest, GetNextRequest,
  122.    GetBulkRequest, and SetRequest operations.
  123.  
  124.    Access Control also occurs in an SNMP entity when an SNMP
  125.    notification message is generated (by a Notification Originator
  126.    application).  These notification messages include these types of
  127.    operations: InformRequest and SNMPv2-Trap operations.
  128.  
  129.    The View-based Access Control Model defines a set of services that an
  130.    application (such as a Command Responder or a Notification Originator
  131.    application) can use for checking access rights.  It is the
  132.    responsibility of the application to make the proper service calls
  133.    for access checking.
  134.  
  135. 1.3.  Local Configuration Datastore
  136.  
  137.    To implement the model described in this document, an SNMP entity
  138.    needs to retain information about access rights and policies.  This
  139.    information is part of the SNMP engine's Local Configuration
  140.    Datastore (LCD). See [RFC2261] for the definition of LCD.
  141.  
  142.    In order to allow an SNMP entity's LCD to be remotely configured,
  143.    portions of the LCD need to be accessible as managed objects.  A MIB
  144.    module, the View-based Access Control Model Configuration MIB, which
  145.    defines these managed object types is included in this document.
  146.  
  147. 2.  Elements of the Model
  148.  
  149.    This section contains definitions to realize the access control
  150.    service provided by the View-based Access Control Model.
  151.  
  152. 2.1.  Groups
  153.  
  154.    A group is a set of zero or more <securityModel, securityName> tuples
  155.    on whose behalf SNMP management objects can be accessed.  A group
  156.    defines the access rights afforded to all securityNames which belong
  157.    to that group. The combination of a securityModel and a securityName
  158.    maps to at most one group.  A group is identified by a groupName.
  159.  
  160.    The Access Control module assumes that the securityName has already
  161.    been authenticated as needed and provides no further authentication
  162.    of its own.
  163.  
  164.    The View-based Access Control Model uses the securityModel and the
  165.    securityName as inputs to the Access Control module when called to
  166.    check for access rights.  It determines the groupName as a function
  167.  
  168.  
  169.  
  170. Wijnen, et. al.             Standards Track                     [Page 3]
  171.  
  172. RFC 2265                    VACM for SNMPv3                 January 1998
  173.  
  174.  
  175.    of securityModel and securityName.
  176.  
  177. 2.2.  securityLevel
  178.  
  179.    Different access rights for members of a group can be defined for
  180.    different levels of security, i.e., noAuthNoPriv, authNoPriv, and
  181.    authPriv. The securityLevel identifies the level of security that
  182.    will be assumed when checking for access rights.  See the SNMP
  183.    Architecture document [RFC2261] for a definition of securityLevel.
  184.  
  185.    The View-based Access Control Model requires that the securityLevel
  186.    is passed as input to the Access Control module when called to check
  187.    for access rights.
  188.  
  189. 2.3.  Contexts
  190.  
  191.    An SNMP context is a collection of management information accessible
  192.    by an SNMP entity.  An item of management information may exist in
  193.    more than one context.  An SNMP entity potentially has access to many
  194.    contexts.  Details about the naming of management information can be
  195.    found in the SNMP Architecture document [RFC2261].
  196.  
  197.    The View-based Access Control Model defines a vacmContextTable that
  198.    lists the locally available contexts by contextName.
  199.  
  200. 2.4.  MIB Views and View Families
  201.  
  202.    For security reasons, it is often valuable to be able to restrict the
  203.    access rights of some groups to only a subset of the management
  204.    information in the management domain.  To provide this capability,
  205.    access to a context is via a "MIB view" which details a specific set
  206.    of managed object types (and optionally, the specific instances of
  207.    object types) within that context.  For example, for a given context,
  208.    there will typically always be one MIB view which provides access to
  209.    all management information in that context, and often there will be
  210.    other MIB views each of which contains some subset of the
  211.    information.  So, the access allowed for a group can be restricted in
  212.    the desired manner by specifying its rights in terms of the
  213.    particular (subset) MIB view it can access within each appropriate
  214.    context.
  215.  
  216.    Since managed object types (and their instances) are identified via
  217.    the tree-like naming structure of ISO's OBJECT IDENTIFIERs [ISO-
  218.    ASN.1, RFC1902],  it is convenient to define a MIB view as the
  219.    combination of a set of "view subtrees", where each view subtree is a
  220.    subtree within the managed object naming tree.  Thus, a simple MIB
  221.    view (e.g., all managed objects within the Internet Network
  222.    Management Framework) can be defined as a single view subtree, while
  223.  
  224.  
  225.  
  226. Wijnen, et. al.             Standards Track                     [Page 4]
  227.  
  228. RFC 2265                    VACM for SNMPv3                 January 1998
  229.  
  230.  
  231.    more complicated MIB views (e.g., all information relevant to a
  232.    particular network interface) can be represented by the union of
  233.    multiple view subtrees.
  234.  
  235.    While any set of managed objects can be described by the union of
  236.    some number of view subtrees, situations can arise that would require
  237.    a very large number of view subtrees.  This could happen, for
  238.    example, when specifying all columns in one conceptual row of a MIB
  239.    table because they would appear in separate subtrees, one per column,
  240.    each with a very similar format.  Because the formats are similar,
  241.    the required set of subtrees can easily be aggregated into one
  242.    structure.  This structure is named a family of view subtrees after
  243.    the set of subtrees that it conceptually represents.  A family of
  244.    view subtrees can either be included or excluded from a MIB view.
  245.  
  246. 2.4.1.  View Subtree
  247.  
  248.    A view subtree is the set of all MIB object instances which have a
  249.    common ASN.1 OBJECT IDENTIFIER prefix to their names.  A view subtree
  250.    is identified by the OBJECT IDENTIFIER value which is the longest
  251.    OBJECT IDENTIFIER prefix common to all (potential) MIB object
  252.    instances in that subtree.
  253.  
  254. 2.4.2.  ViewTreeFamily
  255.  
  256.    A family of view subtrees is a pairing of an OBJECT IDENTIFIER value
  257.    (called the family name) together with a bit string value (called the
  258.    family mask).  The family mask indicates which sub-identifiers of the
  259.    associated family name are significant to the family's definition.
  260.  
  261.    For each possible managed object instance, that instance belongs to a
  262.    particular ViewTreeFamily if both of the following conditions are
  263.    true:
  264.  
  265.    - the OBJECT IDENTIFIER name of the managed object instance
  266.      contains at least as many sub-identifiers as does the family name,
  267.      and
  268.  
  269.    - each sub-identifier in the OBJECT IDENTIFIER name of the managed
  270.      object instance matches the corresponding sub-identifier of the
  271.      family name whenever the corresponding bit of the associated family
  272.      mask is non-zero.
  273.  
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Wijnen, et. al.             Standards Track                     [Page 5]
  283.  
  284. RFC 2265                    VACM for SNMPv3                 January 1998
  285.  
  286.  
  287.    When the configured value of the family mask is all ones, the view
  288.    subtree family is identical to the single view subtree identified by
  289.    the family name.
  290.  
  291.    When the configured value of the family mask is shorter than required
  292.    to perform the above test, its value is implicitly extended with
  293.    ones.  Consequently, a view subtree family having a family mask of
  294.    zero length always corresponds to a single view subtree.
  295.  
  296. 2.5.  Access Policy
  297.  
  298.    The View-based Access Control Model determines the access rights of a
  299.    group, representing zero or more securityNames which have the same
  300.    access rights.  For a particular context, identified by contextName,
  301.    to which a group, identified by groupName, has access using a
  302.    particular securityModel and securityLevel, that group's access
  303.    rights are given by a read-view, a write-view and a notify-view.
  304.  
  305.    The read-view represents the set of object instances authorized for
  306.    the group when reading objects.  Reading objects occurs when
  307.    processing a retrieval (for example a GetRequest, GetNextRequest,
  308.    GetBulkRequest) operation.
  309.  
  310.    The write-view represents the set of object instances authorized for
  311.    the group when writing objects.  Writing objects occurs when
  312.    processing a write (for example a Set) operation.
  313.  
  314.    The notify-view represents the set of object instances authorized for
  315.    the group when sending objects in a notification, such as when
  316.    sending a notification (for example an Inform or SNMPv2-Trap).
  317.  
  318. 3.  Elements of Procedure
  319.  
  320.    This section describes the procedures followed by an Access Control
  321.    module that implements the View-based Access Control Model when
  322.    checking access rights as requested by an application (for example a
  323.    Command Responder or a Notification Originator application).  The
  324.    abstract service primitive is:
  325.  
  326.      statusInformation =          -- success or errorIndication
  327.          isAccessAllowed(
  328.              securityModel        -- Security Model in use
  329.              securityName         -- principal who wants access
  330.              securityLevel        -- Level of Security
  331.              viewType             -- read, write, or notify view
  332.              contextName          -- context containing variableName
  333.              variableName         -- OID for the managed object
  334.              )
  335.  
  336.  
  337.  
  338. Wijnen, et. al.             Standards Track                     [Page 6]
  339.  
  340. RFC 2265                    VACM for SNMPv3                 January 1998
  341.  
  342.  
  343.    The abstract data elements are:
  344.  
  345.      statusInformation - one of the following:
  346.         accessAllowed  - a MIB view was found and access is granted.
  347.         notInView      - a MIB view was found but access is denied.
  348.                          The variableName is not in the configured
  349.                          MIB view for the specified viewType (e.g., in
  350.                          the relevant entry in the vacmAccessTable).
  351.         noSuchView     - no MIB view found because no view has been
  352.                          configured for specified viewType (e.g., in
  353.                          the relevant entry in the vacmAccessTable).
  354.         noSuchContext  - no MIB view found because of no entry in the
  355.                          vacmContextTable for specified contextName.
  356.         noGroupName    - no MIB view found because no entry has been
  357.                          configured in the vacmSecurityToGroupTable
  358.                          for the specified combination of
  359.                          securityModel and securityName.
  360.         noAccessEntry  - no MIB view found because no entry has been
  361.                          configured in the vacmAccessTable for the
  362.                          specified combination of contextName,
  363.                          groupName (from vacmSecurityToGroupTable),
  364.                          securityModel and securityLevel.
  365.         otherError     - failure, an undefined error occurred.
  366.      securityModel - Security Model under which access is requested.
  367.      securityName  - the principal on whose behalf access is requested.
  368.      securityLevel - Level of Security under which access is requested.
  369.      viewType      - view to be checked (read, write or notify).
  370.      contextName   - context in which access is requested.
  371.      variableName  - object instance to which access is requested.
  372.  
  373.  
  374.  
  375.  
  376.  
  377.  
  378.  
  379.  
  380.  
  381.  
  382.  
  383.  
  384.  
  385.  
  386.  
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394. Wijnen, et. al.             Standards Track                     [Page 7]
  395.  
  396. RFC 2265                    VACM for SNMPv3                 January 1998
  397.  
  398.  
  399. 3.1.  Overview  of isAccessAllowed Process
  400.  
  401.  The following picture shows how the decision for access control is made
  402.  by the View-based Access Control Model.
  403.  
  404.  +--------------------------------------------------------------------+
  405.  |                                                                    |
  406.  |      +-> securityModel -+                                          |
  407.  |      |   (a)            |                                          |
  408.  | who -+                  +-> groupName ----+                        |
  409.  | (1)  |                  |   (x)           |                        |
  410.  |      +-> securityName --+                 |                        |
  411.  |          (b)                              |                        |
  412.  |                                           |                        |
  413.  | where -> contextName ---------------------+                        |
  414.  | (2)      (e)                              |                        |
  415.  |                                           |                        |
  416.  |                                           |                        |
  417.  |      +-> securityModel -------------------+                        |
  418.  |      |   (a)                              |                        |
  419.  | how -+                                    +-> viewName -+          |
  420.  | (3)  |                                    |   (y)       |          |
  421.  |      +-> securityLevel -------------------+             |          |
  422.  |          (c)                              |             +-> yes/no |
  423.  |                                           |             | decision |
  424.  | why ---> viewType (read/write/notify) ----+             | (z)      |
  425.  | (4)      (d)                                            |          |
  426.  |                                                         |          |
  427.  | what --> object-type ------+                            |          |
  428.  | (5)      (m)               |                            |          |
  429.  |                            +-> variableName (OID) ------+          |
  430.  |                            |   (f)                                 |
  431.  | which -> object-instance --+                                       |
  432.  | (6)      (n)                                                       |
  433.  |                                                                    |
  434.  +--------------------------------------------------------------------+
  435.  
  436.  How the decision for isAccessAllowed is made.
  437.  
  438.  1) Inputs to the isAccessAllowed service are:
  439.  
  440.     (a)       securityModel    -- Security Model in use
  441.     (b)       securityName     -- principal who wants to access
  442.     (c)       securityLevel    -- Level of Security
  443.     (d)       viewType         -- read, write, or notify view
  444.     (e)       contextName      -- context containing variableName
  445.     (f)       variableName     -- OID for the managed object
  446.                                -- this is made up of:
  447.  
  448.  
  449.  
  450. Wijnen, et. al.             Standards Track                     [Page 8]
  451.  
  452. RFC 2265                    VACM for SNMPv3                 January 1998
  453.  
  454.  
  455.                                   - object-type (m)
  456.                                   - object-instance (n)
  457.  
  458.  2) The partial "who" (1), represented by the securityModel (a) and
  459.     the securityName (b), are used as the indices (a,b) into the
  460.     vacmSecurityToGroupTable to find a single entry that produces a
  461.     group, represented by groupName (x).
  462.  
  463.  3) The "where" (2), represented by the contextName (e), the "who",
  464.     represented by the groupName (x) from the previous step, and the
  465.     "how" (3), represented by securityModel (a) and securityLevel (c),
  466.     are used as indices (e,x,a,c) into the vacmAccessTable to find a
  467.     single entry that contains three MIB views.
  468.  
  469.  4) The "why" (4), represented by the viewType (d), is used to select
  470.     the proper MIB view, represented by a viewName (y), from the
  471.     vacmAccessEntry selected in the previous step. This viewName (y) is
  472.     an index into the vacmViewTreeFamilyTable and selects the set of
  473.     entries that define the variableNames which are included in or
  474.     excluded from the MIB view identified by the viewName (y).
  475.  
  476.  5) The "what" (5) type of management data and "which" (6) particular
  477.     instance, represented by the variableName (f), is then checked to be
  478.     in the MIB view or not, e.g., the yes/no decision (z).
  479.  
  480. 3.2.  Processing the isAccessAllowed Service Request
  481.  
  482.    This section describes the procedure followed by an Access Control
  483.    module that implements the View-based Access Control Model whenever
  484.    it receives an isAccessAllowed request.
  485.  
  486.    1) The vacmContextTable is consulted for information about
  487.       the SNMP context identified by the contextName.  If information
  488.       about this SNMP context is absent from the table, then an
  489.       errorIndication (noSuchContext) is returned to the calling module.
  490.  
  491.    2) The vacmSecurityToGroupTable is consulted for mapping the
  492.       securityModel and securityName to a groupName.  If the information
  493.       about this combination is absent from the table, then an
  494.       errorIndication (noGroupName) is returned to the calling module.
  495.  
  496.    3) The vacmAccessTable is consulted for information about the
  497.       groupName, contextName, securityModel and securityLevel.  If
  498.       information about this combination is absent from the table, then
  499.       an errorIndication (noAccessEntry) is returned to the calling
  500.       module.
  501.  
  502.  
  503.  
  504.  
  505.  
  506. Wijnen, et. al.             Standards Track                     [Page 9]
  507.  
  508. RFC 2265                    VACM for SNMPv3                 January 1998
  509.  
  510.  
  511.    4) a) If the viewType is "read", then the read view is used for
  512.          checking access rights.
  513.  
  514.       b) If the viewType is "write", then the write view is used for
  515.          checking access rights.
  516.  
  517.       c) If the viewType is "notify", then the notify view is used
  518.          for checking access rights.
  519.  
  520.       If the view to be used is the empty view (zero length viewName)
  521.       then an errorIndication (noSuchView) is returned to the calling
  522.       module.
  523.  
  524.    5) a) If there is no view configured for the specified viewType,
  525.          then an errorIndication (noSuchView) is returned to the calling
  526.          module.
  527.  
  528.       b) If the specified variableName (object instance) is not in the
  529.          MIB view (see DESCRIPTION clause for vacmViewTreeFamilyTable in
  530.          section 4), then an errorIndication (notInView) is returned to
  531.          the calling module.
  532.  
  533.          Otherwise,
  534.  
  535.       c) The specified variableName is in the MIB view.
  536.          A statusInformation of success (accessAllowed) is returned to
  537.          the calling module.
  538.  
  539. 4.  Definitions
  540.  
  541. SNMP-VIEW-BASED-ACM-MIB DEFINITIONS ::= BEGIN
  542.  
  543. IMPORTS
  544.     MODULE-COMPLIANCE, OBJECT-GROUP       FROM SNMPv2-CONF
  545.     MODULE-IDENTITY, OBJECT-TYPE,
  546.     snmpModules                           FROM SNMPv2-SMI
  547.     TestAndIncr,
  548.     RowStatus, StorageType                FROM SNMPv2-TC
  549.     SnmpAdminString,
  550.     SnmpSecurityLevel,
  551.     SnmpSecurityModel                     FROM SNMP-FRAMEWORK-MIB;
  552.  
  553. snmpVacmMIB       MODULE-IDENTITY
  554.     LAST-UPDATED "9711200000Z"            -- 20 Nov 1997, midnight
  555.     ORGANIZATION "SNMPv3 Working Group"
  556.     CONTACT-INFO "WG-email:   snmpv3@tis.com
  557.                   Subscribe:  majordomo@tis.com
  558.                               In message body:  subscribe snmpv3
  559.  
  560.  
  561.  
  562. Wijnen, et. al.             Standards Track                    [Page 10]
  563.  
  564. RFC 2265                    VACM for SNMPv3                 January 1998
  565.  
  566.  
  567.                   Chair:      Russ Mundy
  568.                               Trusted Information Systems
  569.                   postal:     3060 Washington Rd
  570.                               Glenwood MD 21738
  571.                               USA
  572.                   email:      mundy@tis.com
  573.                   phone:      +1-301-854-6889
  574.  
  575.                   Co-editor:  Bert Wijnen
  576.                               IBM T.J. Watson Research
  577.                   postal:     Schagen 33
  578.                               3461 GL Linschoten
  579.                               Netherlands
  580.                   email:      wijnen@vnet.ibm.com
  581.                   phone:      +31-348-432-794
  582.  
  583.                   Co-editor:  Randy Presuhn
  584.                               BMC Software, Inc
  585.                   postal:     1190 Saratoga Avenue, Suite 130
  586.                               San Jose, CA  95129-3433
  587.                               USA
  588.                   email:      rpresuhn@bmc.com
  589.                   phone:      +1-408-556-0720
  590.  
  591.                   Co-editor:  Keith McCloghrie
  592.                               Cisco Systems, Inc.
  593.                   postal:     170 West Tasman Drive
  594.                               San Jose, CA  95134-1706
  595.                               USA
  596.                   email:      kzm@cisco.com
  597.                   phone:      +1-408-526-5260
  598.                  "
  599.     DESCRIPTION  "The management information definitions for the
  600.                   View-based Access Control Model for SNMP.
  601.                  "
  602.     ::= { snmpModules 5 }
  603.  
  604. -- Administrative assignments ****************************************
  605.  
  606. vacmMIBObjects      OBJECT IDENTIFIER ::= { snmpVacmMIB 1 }
  607. vacmMIBConformance  OBJECT IDENTIFIER ::= { snmpVacmMIB 2 }
  608.  
  609. -- Information about Local Contexts **********************************
  610.  
  611. vacmContextTable OBJECT-TYPE
  612.     SYNTAX       SEQUENCE OF VacmContextEntry
  613.     MAX-ACCESS   not-accessible
  614.     STATUS       current
  615.  
  616.  
  617.  
  618. Wijnen, et. al.             Standards Track                    [Page 11]
  619.  
  620. RFC 2265                    VACM for SNMPv3                 January 1998
  621.  
  622.  
  623.     DESCRIPTION "The table of locally available contexts.
  624.  
  625.                  This table provides information to SNMP Command
  626.                  Generator applications so that they can properly
  627.                  configure the vacmAccessTable to control access to
  628.                  all contexts at the SNMP entity.
  629.  
  630.                  This table may change dynamically if the SNMP entity
  631.                  allows that contexts are added/deleted dynamically
  632.                  (for instance when its configuration changes). Such
  633.                  changes would happen only if the management
  634.                  instrumentation at that SNMP entity recognizes more
  635.                  (or fewer) contexts.
  636.  
  637.                  The presence of entries in this table and of entries
  638.                  in the vacmAccessTable are independent.  That is, a
  639.                  context identified by an entry in this table is not
  640.                  necessarily referenced by any entries in the
  641.                  vacmAccessTable; and the context(s) referenced by an
  642.                  entry in the vacmAccessTable does not necessarily
  643.                  currently exist and thus need not be identified by an
  644.                  entry in this table.
  645.  
  646.                  This table must be made accessible via the default
  647.                  context so that Command Responder applications have
  648.                  a standard way of retrieving the information.
  649.  
  650.                  This table is read-only. It cannot be configured via
  651.                  SNMP.
  652.                 "
  653.     ::= { vacmMIBObjects 1 }
  654.  
  655. vacmContextEntry OBJECT-TYPE
  656.     SYNTAX       VacmContextEntry
  657.     MAX-ACCESS   not-accessible
  658.     STATUS       current
  659.     DESCRIPTION "Information about a particular context."
  660.     INDEX       {
  661.                   vacmContextName
  662.                 }
  663.     ::= { vacmContextTable 1 }
  664.  
  665. VacmContextEntry ::= SEQUENCE
  666.     {
  667.         vacmContextName SnmpAdminString
  668.     }
  669.  
  670. vacmContextName  OBJECT-TYPE
  671.  
  672.  
  673.  
  674. Wijnen, et. al.             Standards Track                    [Page 12]
  675.  
  676. RFC 2265                    VACM for SNMPv3                 January 1998
  677.  
  678.  
  679.     SYNTAX       SnmpAdminString (SIZE(0..32))
  680.     MAX-ACCESS   read-only
  681.     STATUS       current
  682.     DESCRIPTION "A human readable name identifying a particular
  683.                  context at a particular SNMP entity.
  684.  
  685.                  The empty contextName (zero length) represents the
  686.                  default context.
  687.                 "
  688.     ::= { vacmContextEntry 1 }
  689.  
  690. -- Information about Groups ******************************************
  691.  
  692. vacmSecurityToGroupTable OBJECT-TYPE
  693.     SYNTAX       SEQUENCE OF VacmSecurityToGroupEntry
  694.     MAX-ACCESS   not-accessible
  695.     STATUS       current
  696.     DESCRIPTION "This table maps a combination of securityModel and
  697.                  securityName into a groupName which is used to define
  698.                  an access control policy for a group of principals.
  699.                 "
  700.     ::= { vacmMIBObjects 2 }
  701.  
  702. vacmSecurityToGroupEntry OBJECT-TYPE
  703.     SYNTAX       VacmSecurityToGroupEntry
  704.     MAX-ACCESS   not-accessible
  705.     STATUS       current
  706.     DESCRIPTION "An entry in this table maps the combination of a
  707.                  securityModel and securityName into a groupName.
  708.                 "
  709.     INDEX       {
  710.                   vacmSecurityModel,
  711.                   vacmSecurityName
  712.                 }
  713.     ::= { vacmSecurityToGroupTable 1 }
  714.  
  715. VacmSecurityToGroupEntry ::= SEQUENCE
  716.     {
  717.         vacmSecurityModel               SnmpSecurityModel,
  718.         vacmSecurityName                SnmpAdminString,
  719.         vacmGroupName                   SnmpAdminString,
  720.         vacmSecurityToGroupStorageType  StorageType,
  721.         vacmSecurityToGroupStatus       RowStatus
  722.     }
  723.  
  724. vacmSecurityModel OBJECT-TYPE
  725.     SYNTAX       SnmpSecurityModel(1..2147483647)
  726.     MAX-ACCESS   not-accessible
  727.  
  728.  
  729.  
  730. Wijnen, et. al.             Standards Track                    [Page 13]
  731.  
  732. RFC 2265                    VACM for SNMPv3                 January 1998
  733.  
  734.  
  735.     STATUS       current
  736.     DESCRIPTION "The Security Model, by which the vacmSecurityName
  737.                  referenced by this entry is provided.
  738.  
  739.                  Note, this object may not take the 'any' (0) value.
  740.                 "
  741.     ::= { vacmSecurityToGroupEntry 1 }
  742.  
  743. vacmSecurityName OBJECT-TYPE
  744.     SYNTAX       SnmpAdminString (SIZE(1..32))
  745.     MAX-ACCESS   not-accessible
  746.     STATUS       current
  747.     DESCRIPTION "The securityName for the principal, represented in a
  748.                  Security Model independent format, which is mapped by
  749.                  this entry to a groupName.
  750.  
  751.                  The securityName for a principal represented in a
  752.                  Security Model independent format.
  753.                 "
  754.     ::= { vacmSecurityToGroupEntry 2 }
  755.  
  756. vacmGroupName    OBJECT-TYPE
  757.     SYNTAX       SnmpAdminString (SIZE(1..32))
  758.     MAX-ACCESS   read-create
  759.     STATUS       current
  760.     DESCRIPTION "The name of the group to which this entry (e.g., the
  761.                  combination of securityModel and securityName)
  762.                  belongs.
  763.  
  764.                  This groupName is used as index into the
  765.                  vacmAccessTable to select an access control policy.
  766.                 "
  767.     ::= { vacmSecurityToGroupEntry 3 }
  768.  
  769. vacmSecurityToGroupStorageType OBJECT-TYPE
  770.     SYNTAX       StorageType
  771.     MAX-ACCESS   read-create
  772.     STATUS       current
  773.     DESCRIPTION "The storage type for this conceptual row.
  774.                  Conceptual rows having the value 'permanent' need not
  775.                  allow write-access to any columnar objects in the row.
  776.                 "
  777.     DEFVAL      { nonVolatile }
  778.     ::= { vacmSecurityToGroupEntry 4 }
  779.  
  780. vacmSecurityToGroupStatus OBJECT-TYPE
  781.     SYNTAX       RowStatus
  782.     MAX-ACCESS   read-create
  783.  
  784.  
  785.  
  786. Wijnen, et. al.             Standards Track                    [Page 14]
  787.  
  788. RFC 2265                    VACM for SNMPv3                 January 1998
  789.  
  790.  
  791.     STATUS       current
  792.     DESCRIPTION "The status of this conceptual row.
  793.  
  794.                  The  RowStatus TC [RFC1903] requires that this
  795.                  DESCRIPTION clause states under which circumstances
  796.                  other objects in this row can be modified:
  797.  
  798.                  The value of this object has no effect on whether
  799.                  other objects in this conceptual row can be modified.
  800.                 "
  801.     ::= { vacmSecurityToGroupEntry 5 }
  802.  
  803. -- Information about Access Rights ***********************************
  804.  
  805. vacmAccessTable  OBJECT-TYPE
  806.     SYNTAX       SEQUENCE OF VacmAccessEntry
  807.     MAX-ACCESS   not-accessible
  808.     STATUS       current
  809.     DESCRIPTION "The table of access rights for groups.
  810.  
  811.                  Each entry is indexed by a contextPrefix, a groupName
  812.                  a securityModel and a securityLevel.  To determine
  813.                  whether access is allowed, one entry from this table
  814.                  needs to be selected and the proper viewName from that
  815.                  entry must be used for access control checking.
  816.  
  817.                  To select the proper entry, follow these steps:
  818.  
  819.                  1) the set of possible matches is formed by the
  820.                     intersection of the following sets of entries:
  821.                       the set of entries with identical vacmGroupName
  822.                       the union of these two sets:
  823.                        - the set with identical vacmAccessContextPrefix
  824.                        - the set of entries with vacmAccessContextMatch
  825.                          value of 'prefix' and matching
  826.                          vacmAccessContextPrefix
  827.                       intersected with the union of these two sets:
  828.                        - the set of entries with identical
  829.                          vacmSecurityModel
  830.                        - the set of entries with vacmSecurityModel
  831.                          value of 'any'
  832.                       intersected with the set of entries with
  833.                       vacmAccessSecurityLevel value less than or equal
  834.                       to the requested securityLevel
  835.  
  836.                  2) if this set has only one member, we're done
  837.                     otherwise, it comes down to deciding how to weight
  838.                     the preferences between ContextPrefixes,
  839.  
  840.  
  841.  
  842. Wijnen, et. al.             Standards Track                    [Page 15]
  843.  
  844. RFC 2265                    VACM for SNMPv3                 January 1998
  845.  
  846.  
  847.                     SecurityModels, and SecurityLevels as follows:
  848.                     a) if the subset of entries with identical
  849.                        securityModels is not empty, discard the rest.
  850.                     b) if the subset of entries with identical
  851.                        vacmAccessContextPrefix is not empty,
  852.                        discard the rest
  853.                     c) discard all entries with ContextPrefixes shorter
  854.                        than the longest one remaining in the set
  855.                     d) select the entry with the highest securityLevel
  856.  
  857.                  Please note that for securityLevel noAuthNoPriv, all
  858.                  groups are really equivalent since the assumption that
  859.                  the securityName has been authenticated does not hold.
  860.                 "
  861.     ::= { vacmMIBObjects 4 }
  862.  
  863. vacmAccessEntry  OBJECT-TYPE
  864.     SYNTAX       VacmAccessEntry
  865.     MAX-ACCESS   not-accessible
  866.     STATUS       current
  867.     DESCRIPTION "An access right configured in the Local Configuration
  868.                  Datastore (LCD) authorizing access to an SNMP context.
  869.                 "
  870.     INDEX       { vacmGroupName,
  871.                   vacmAccessContextPrefix,
  872.                   vacmAccessSecurityModel,
  873.                   vacmAccessSecurityLevel
  874.                 }
  875.     ::= { vacmAccessTable 1 }
  876.  
  877. VacmAccessEntry ::= SEQUENCE
  878.     {
  879.         vacmAccessContextPrefix    SnmpAdminString,
  880.         vacmAccessSecurityModel    SnmpSecurityModel,
  881.         vacmAccessSecurityLevel    SnmpSecurityLevel,
  882.         vacmAccessContextMatch     INTEGER,
  883.         vacmAccessReadViewName     SnmpAdminString,
  884.         vacmAccessWriteViewName    SnmpAdminString,
  885.         vacmAccessNotifyViewName   SnmpAdminString,
  886.         vacmAccessStorageType      StorageType,
  887.         vacmAccessStatus           RowStatus
  888.     }
  889.  
  890. vacmAccessContextPrefix OBJECT-TYPE
  891.     SYNTAX       SnmpAdminString (SIZE(0..32))
  892.     MAX-ACCESS   not-accessible
  893.     STATUS       current
  894.     DESCRIPTION "In order to gain the access rights allowed by this
  895.  
  896.  
  897.  
  898. Wijnen, et. al.             Standards Track                    [Page 16]
  899.  
  900. RFC 2265                    VACM for SNMPv3                 January 1998
  901.  
  902.  
  903.                  conceptual row, a contextName must match exactly
  904.                  (if the value of vacmAccessContextMatch is 'exact')
  905.                  or partially (if the value of vacmAccessContextMatch
  906.                  is 'prefix') to the value of the instance of this
  907.                  object.
  908.                 "
  909.     ::= { vacmAccessEntry 1 }
  910.  
  911. vacmAccessSecurityModel OBJECT-TYPE
  912.     SYNTAX       SnmpSecurityModel
  913.     MAX-ACCESS   not-accessible
  914.     STATUS       current
  915.     DESCRIPTION "In order to gain the access rights allowed by this
  916.                  conceptual row, this securityModel must be in use.
  917.                 "
  918.     ::= { vacmAccessEntry 2 }
  919.  
  920. vacmAccessSecurityLevel OBJECT-TYPE
  921.     SYNTAX       SnmpSecurityLevel
  922.     MAX-ACCESS   not-accessible
  923.     STATUS       current
  924.     DESCRIPTION "The minimum level of security required in order to
  925.                  gain the access rights allowed by this conceptual
  926.                  row.  A securityLevel of noAuthNoPriv is less than
  927.                  authNoPriv which in turn is less than authPriv.
  928.  
  929.                  If multiple entries are equally indexed except for
  930.                  this vacmAccessSecurityLevel index, then the entry
  931.                  which has the highest value for
  932.                  vacmAccessSecurityLevel wins.
  933.                 "
  934.     ::= { vacmAccessEntry 3 }
  935.  
  936. vacmAccessContextMatch OBJECT-TYPE
  937.     SYNTAX       INTEGER
  938.                 { exact (1), -- exact match of prefix and contextName
  939.                   prefix (2) -- Only match to the prefix
  940.                 }
  941.     MAX-ACCESS   read-create
  942.     STATUS       current
  943.     DESCRIPTION "If the value of this object is exact(1), then all
  944.                  rows where the contextName exactly matches
  945.                  vacmAccessContextPrefix are selected.
  946.  
  947.                  If the value of this object is prefix(2), then all
  948.                  rows where the contextName whose starting octets
  949.                  exactly match vacmAccessContextPrefix are selected.
  950.                  This allows for a simple form of wildcarding.
  951.  
  952.  
  953.  
  954. Wijnen, et. al.             Standards Track                    [Page 17]
  955.  
  956. RFC 2265                    VACM for SNMPv3                 January 1998
  957.  
  958.  
  959.                  See also the example in the DESCRIPTION clause of
  960.                  the vacmAccessTable above.
  961.                 "
  962.     ::= { vacmAccessEntry 4 }
  963.  
  964. vacmAccessReadViewName OBJECT-TYPE
  965.     SYNTAX       SnmpAdminString (SIZE(0..32))
  966.     MAX-ACCESS   read-create
  967.     STATUS       current
  968.     DESCRIPTION "The value of an instance of this object identifies
  969.                  the MIB view of the SNMP context to which this
  970.                  conceptual row authorizes read access.
  971.  
  972.                  The identified MIB view is that one for which the
  973.                  vacmViewTreeFamilyViewName has the same value as the
  974.                  instance of this object; if the value is the empty
  975.                  string or if there is no active MIB view having this
  976.                  value of vacmViewTreeFamilyViewName, then no access
  977.                  is granted.
  978.                 "
  979.     DEFVAL      { ''H }   -- the empty string
  980.     ::= { vacmAccessEntry 5 }
  981.  
  982. vacmAccessWriteViewName OBJECT-TYPE
  983.     SYNTAX       SnmpAdminString (SIZE(0..32))
  984.     MAX-ACCESS   read-create
  985.     STATUS       current
  986.     DESCRIPTION "The value of an instance of this object identifies
  987.                  the MIB view of the SNMP context to which this
  988.                  conceptual row authorizes write access.
  989.  
  990.                  The identified MIB view is that one for which the
  991.                  vacmViewTreeFamilyViewName has the same value as the
  992.                  instance of this object; if the value is the empty
  993.                  string or if there is no active MIB view having this
  994.                  value of vacmViewTreeFamilyViewName, then no access
  995.                  is granted.
  996.                 "
  997.     DEFVAL      { ''H }   -- the empty string
  998.     ::= { vacmAccessEntry 6 }
  999.  
  1000. vacmAccessNotifyViewName OBJECT-TYPE
  1001.     SYNTAX       SnmpAdminString (SIZE(0..32))
  1002.     MAX-ACCESS   read-create
  1003.     STATUS       current
  1004.     DESCRIPTION "The value of an instance of this object identifies
  1005.                  the MIB view of the SNMP context to which this
  1006.                  conceptual row authorizes access for notifications.
  1007.  
  1008.  
  1009.  
  1010. Wijnen, et. al.             Standards Track                    [Page 18]
  1011.  
  1012. RFC 2265                    VACM for SNMPv3                 January 1998
  1013.  
  1014.  
  1015.                  The identified MIB view is that one for which the
  1016.                  vacmViewTreeFamilyViewName has the same value as the
  1017.                  instance of this object; if the value is the empty
  1018.                  string or if there is no active MIB view having this
  1019.                  value of vacmViewTreeFamilyViewName, then no access
  1020.                  is granted.
  1021.                 "
  1022.     DEFVAL      { ''H }   -- the empty string
  1023.     ::= { vacmAccessEntry 7 }
  1024.  
  1025. vacmAccessStorageType OBJECT-TYPE
  1026.     SYNTAX       StorageType
  1027.     MAX-ACCESS   read-create
  1028.     STATUS       current
  1029.     DESCRIPTION "The storage type for this conceptual row.
  1030.  
  1031.                  Conceptual rows having the value 'permanent' need not
  1032.                  allow write-access to any columnar objects in the row.
  1033.                 "
  1034.     DEFVAL      { nonVolatile }
  1035.     ::= { vacmAccessEntry 8 }
  1036.  
  1037. vacmAccessStatus OBJECT-TYPE
  1038.     SYNTAX       RowStatus
  1039.     MAX-ACCESS   read-create
  1040.     STATUS       current
  1041.     DESCRIPTION "The status of this conceptual row.
  1042.  
  1043.                  The  RowStatus TC [RFC1903] requires that this
  1044.                  DESCRIPTION clause states under which circumstances
  1045.                  other objects in this row can be modified:
  1046.  
  1047.                  The value of this object has no effect on whether
  1048.                  other objects in this conceptual row can be modified.
  1049.                 "
  1050.     ::= { vacmAccessEntry 9 }
  1051.  
  1052. -- Information about MIB views ***************************************
  1053.  
  1054. -- Support for instance-level granularity is optional.
  1055. --
  1056. -- In some implementations, instance-level access control
  1057. -- granularity may come at a high performance cost.  Managers
  1058. -- should avoid requesting such configurations unnecessarily.
  1059.  
  1060. vacmMIBViews     OBJECT IDENTIFIER ::= { vacmMIBObjects 5 }
  1061.  
  1062. vacmViewSpinLock OBJECT-TYPE
  1063.  
  1064.  
  1065.  
  1066. Wijnen, et. al.             Standards Track                    [Page 19]
  1067.  
  1068. RFC 2265                    VACM for SNMPv3                 January 1998
  1069.  
  1070.  
  1071.     SYNTAX       TestAndIncr
  1072.     MAX-ACCESS   read-write
  1073.     STATUS       current
  1074.     DESCRIPTION "An advisory lock used to allow cooperating SNMP
  1075.                  Command Generator applications to coordinate their
  1076.                  use of the Set operation in creating or modifying
  1077.                  views.
  1078.  
  1079.                  When creating a new view or altering an existing
  1080.                  view, it is important to understand the potential
  1081.                  interactions with other uses of the view.  The
  1082.                  vacmViewSpinLock should be retrieved.  The name of
  1083.                  the view to be created should be determined to be
  1084.                  unique by the SNMP Command Generator application by
  1085.                  consulting the vacmViewTreeFamilyTable.  Finally,
  1086.                  the named view may be created (Set), including the
  1087.                  advisory lock.
  1088.                  If another SNMP Command Generator application has
  1089.                  altered the views in the meantime, then the spin
  1090.                  lock's value will have changed, and so this creation
  1091.                  will fail because it will specify the wrong value for
  1092.                  the spin lock.
  1093.  
  1094.                  Since this is an advisory lock, the use of this lock
  1095.                  is not enforced.
  1096.                 "
  1097.     ::= { vacmMIBViews 1 }
  1098.  
  1099. vacmViewTreeFamilyTable OBJECT-TYPE
  1100.     SYNTAX       SEQUENCE OF VacmViewTreeFamilyEntry
  1101.     MAX-ACCESS   not-accessible
  1102.     STATUS       current
  1103.     DESCRIPTION "Locally held information about families of subtrees
  1104.                  within MIB views.
  1105.  
  1106.                  Each MIB view is defined by two sets of view subtrees:
  1107.                    - the included view subtrees, and
  1108.                    - the excluded view subtrees.
  1109.                  Every such view subtree, both the included and the
  1110.                  excluded ones, is defined in this table.
  1111.  
  1112.                  To determine if a particular object instance is in
  1113.                  a particular MIB view, compare the object instance's
  1114.                  OBJECT IDENTIFIER with each of the MIB view's active
  1115.                  entries in this table.  If none match, then the
  1116.                  object instance is not in the MIB view.  If one or
  1117.                  more match, then the object instance is included in,
  1118.                  or excluded from, the MIB view according to the
  1119.  
  1120.  
  1121.  
  1122. Wijnen, et. al.             Standards Track                    [Page 20]
  1123.  
  1124. RFC 2265                    VACM for SNMPv3                 January 1998
  1125.  
  1126.  
  1127.                  value of vacmViewTreeFamilyType in the entry whose
  1128.                  value of vacmViewTreeFamilySubtree has the most
  1129.                  sub-identifiers.  If multiple entries match and have
  1130.                  the same number of sub-identifiers, then the
  1131.                  lexicographically greatest instance of
  1132.                  vacmViewTreeFamilyType determines the inclusion or
  1133.                  exclusion.
  1134.  
  1135.                  An object instance's OBJECT IDENTIFIER X matches an
  1136.                  active entry in this table when the number of
  1137.                  sub-identifiers in X is at least as many as in the
  1138.                  value of vacmViewTreeFamilySubtree for the entry,
  1139.                  and each sub-identifier in the value of
  1140.                  vacmViewTreeFamilySubtree matches its corresponding
  1141.                  sub-identifier in X.  Two sub-identifiers match
  1142.                  either if the corresponding bit of the value of
  1143.                  vacmViewTreeFamilyMask for the entry is zero (the
  1144.                  'wild card' value), or if they are equal.
  1145.  
  1146.                  A 'family' of subtrees is the set of subtrees defined
  1147.                  by a particular combination of values of
  1148.                  vacmViewTreeFamilySubtree and vacmViewTreeFamilyMask.
  1149.                  In the case where no 'wild card' is defined in the
  1150.                  vacmViewTreeFamilyMask, the family of subtrees reduces
  1151.                  to a single subtree.
  1152.  
  1153.                  When creating or changing MIB views, an SNMP Command
  1154.                  Generator application should utilize the
  1155.                  vacmViewSpinLock to try to avoid collisions. See
  1156.                  DESCRIPTION clause of vacmViewSpinLock.
  1157.  
  1158.                  When creating MIB views, it is strongly advised that
  1159.                  first the 'excluded' vacmViewTreeFamilyEntries are
  1160.                  created and then the 'included' entries.
  1161.  
  1162.                  When deleting MIB views, it is strongly advised that
  1163.                  first the 'included' vacmViewTreeFamilyEntries are
  1164.                  deleted and then the 'excluded' entries.
  1165.  
  1166.                  If a create for an entry for instance-level access
  1167.                  control is received and the implementation does not
  1168.                  support instance-level granularity, then an
  1169.                  inconsistentName error must be returned.
  1170.                 "
  1171.     ::= { vacmMIBViews 2 }
  1172.  
  1173. vacmViewTreeFamilyEntry OBJECT-TYPE
  1174.     SYNTAX       VacmViewTreeFamilyEntry
  1175.  
  1176.  
  1177.  
  1178. Wijnen, et. al.             Standards Track                    [Page 21]
  1179.  
  1180. RFC 2265                    VACM for SNMPv3                 January 1998
  1181.  
  1182.  
  1183.     MAX-ACCESS   not-accessible
  1184.     STATUS       current
  1185.     DESCRIPTION "Information on a particular family of view subtrees
  1186.                  included in or excluded from a particular SNMP
  1187.                  context's MIB view.
  1188.  
  1189.                  Implementations must not restrict the number of
  1190.                  families of view subtrees for a given MIB view,
  1191.                  except as dictated by resource constraints on the
  1192.                  overall number of entries in the
  1193.                  vacmViewTreeFamilyTable.
  1194.  
  1195.                  If no conceptual rows exist in this table for a given
  1196.                  MIB view (viewName), that view may be thought of as
  1197.                  consisting of the empty set of view subtrees.
  1198.                 "
  1199.     INDEX       { vacmViewTreeFamilyViewName,
  1200.                   vacmViewTreeFamilySubtree
  1201.                 }
  1202.     ::= { vacmViewTreeFamilyTable 1 }
  1203.  
  1204. VacmViewTreeFamilyEntry ::= SEQUENCE
  1205.     {
  1206.         vacmViewTreeFamilyViewName     SnmpAdminString,
  1207.         vacmViewTreeFamilySubtree      OBJECT IDENTIFIER,
  1208.         vacmViewTreeFamilyMask         OCTET STRING,
  1209.         vacmViewTreeFamilyType         INTEGER,
  1210.         vacmViewTreeFamilyStorageType  StorageType,
  1211.         vacmViewTreeFamilyStatus       RowStatus
  1212.     }
  1213.  
  1214. vacmViewTreeFamilyViewName OBJECT-TYPE
  1215.     SYNTAX       SnmpAdminString (SIZE(1..32))
  1216.     MAX-ACCESS   not-accessible
  1217.     STATUS       current
  1218.     DESCRIPTION "The human readable name for a family of view subtrees.
  1219.                 "
  1220.     ::= { vacmViewTreeFamilyEntry 1 }
  1221.  
  1222. vacmViewTreeFamilySubtree OBJECT-TYPE
  1223.     SYNTAX       OBJECT IDENTIFIER
  1224.     MAX-ACCESS   not-accessible
  1225.     STATUS       current
  1226.     DESCRIPTION "The MIB subtree which when combined with the
  1227.                  corresponding instance of vacmViewTreeFamilyMask
  1228.                  defines a family of view subtrees.
  1229.                 "
  1230.     ::= { vacmViewTreeFamilyEntry 2 }
  1231.  
  1232.  
  1233.  
  1234. Wijnen, et. al.             Standards Track                    [Page 22]
  1235.  
  1236. RFC 2265                    VACM for SNMPv3                 January 1998
  1237.  
  1238.  
  1239. vacmViewTreeFamilyMask OBJECT-TYPE
  1240.     SYNTAX       OCTET STRING (SIZE (0..16))
  1241.     MAX-ACCESS   read-create
  1242.     STATUS       current
  1243.     DESCRIPTION "The bit mask which, in combination with the
  1244.                  corresponding instance of vacmViewTreeFamilySubtree,
  1245.                  defines a family of view subtrees.
  1246.  
  1247.                  Each bit of this bit mask corresponds to a
  1248.                  sub-identifier of vacmViewTreeFamilySubtree, with the
  1249.                  most significant bit of the i-th octet of this octet
  1250.                  string value (extended if necessary, see below)
  1251.                  corresponding to the (8*i - 7)-th sub-identifier, and
  1252.                  the least significant bit of the i-th octet of this
  1253.                  octet string corresponding to the (8*i)-th
  1254.                  sub-identifier, where i is in the range 1 through 16.
  1255.  
  1256.                  Each bit of this bit mask specifies whether or not
  1257.                  the corresponding sub-identifiers must match when
  1258.                  determining if an OBJECT IDENTIFIER is in this
  1259.                  family of view subtrees; a '1' indicates that an
  1260.                  exact match must occur; a '0' indicates 'wild card',
  1261.                  i.e., any sub-identifier value matches.
  1262.  
  1263.                  Thus, the OBJECT IDENTIFIER X of an object instance
  1264.                  is contained in a family of view subtrees if, for
  1265.                  each sub-identifier of the value of
  1266.                  vacmViewTreeFamilySubtree, either:
  1267.  
  1268.                    the i-th bit of vacmViewTreeFamilyMask is 0, or
  1269.  
  1270.                    the i-th sub-identifier of X is equal to the i-th
  1271.                    sub-identifier of the value of
  1272.                    vacmViewTreeFamilySubtree.
  1273.  
  1274.                  If the value of this bit mask is M bits long and
  1275.                  there are more than M sub-identifiers in the
  1276.                  corresponding instance of vacmViewTreeFamilySubtree,
  1277.                  then the bit mask is extended with 1's to be the
  1278.                  required length.
  1279.  
  1280.                  Note that when the value of this object is the
  1281.                  zero-length string, this extension rule results in
  1282.                  a mask of all-1's being used (i.e., no 'wild card'),
  1283.                  and the family of view subtrees is the one view
  1284.                  subtree uniquely identified by the corresponding
  1285.                  instance of vacmViewTreeFamilySubtree.
  1286.  
  1287.  
  1288.  
  1289.  
  1290. Wijnen, et. al.             Standards Track                    [Page 23]
  1291.  
  1292. RFC 2265                    VACM for SNMPv3                 January 1998
  1293.  
  1294.  
  1295.                  Note that masks of length greater than zero length
  1296.                  do not need to be supported. In this case this
  1297.                  object is made read-only.
  1298.                 "
  1299.     DEFVAL      { ''H }
  1300.     ::= { vacmViewTreeFamilyEntry 3 }
  1301.  
  1302. vacmViewTreeFamilyType OBJECT-TYPE
  1303.     SYNTAX       INTEGER  { included(1), excluded(2) }
  1304.     MAX-ACCESS   read-create
  1305.     STATUS       current
  1306.     DESCRIPTION "Indicates whether the corresponding instances of
  1307.                  vacmViewTreeFamilySubtree and vacmViewTreeFamilyMask
  1308.                  define a family of view subtrees which is included in
  1309.                  or excluded from the MIB view.
  1310.                 "
  1311.     DEFVAL      { included }
  1312.     ::= { vacmViewTreeFamilyEntry 4 }
  1313.  
  1314. vacmViewTreeFamilyStorageType OBJECT-TYPE
  1315.     SYNTAX       StorageType
  1316.     MAX-ACCESS   read-create
  1317.     STATUS       current
  1318.     DESCRIPTION "The storage type for this conceptual row.
  1319.  
  1320.                  Conceptual rows having the value 'permanent' need not
  1321.                  allow write-access to any columnar objects in the row.
  1322.                 "
  1323.     DEFVAL      { nonVolatile }
  1324.     ::= { vacmViewTreeFamilyEntry 5 }
  1325.  
  1326. vacmViewTreeFamilyStatus OBJECT-TYPE
  1327.     SYNTAX       RowStatus
  1328.     MAX-ACCESS   read-create
  1329.     STATUS       current
  1330.     DESCRIPTION "The status of this conceptual row.
  1331.  
  1332.                  The  RowStatus TC [RFC1903] requires that this
  1333.                  DESCRIPTION clause states under which circumstances
  1334.                  other objects in this row can be modified:
  1335.  
  1336.                  The value of this object has no effect on whether
  1337.                  other objects in this conceptual row can be modified.
  1338.                 "
  1339.     ::= { vacmViewTreeFamilyEntry 6 }
  1340.  
  1341. -- Conformance information *******************************************
  1342.  
  1343.  
  1344.  
  1345.  
  1346. Wijnen, et. al.             Standards Track                    [Page 24]
  1347.  
  1348. RFC 2265                    VACM for SNMPv3                 January 1998
  1349.  
  1350.  
  1351. vacmMIBCompliances  OBJECT IDENTIFIER ::= { vacmMIBConformance 1 }
  1352. vacmMIBGroups       OBJECT IDENTIFIER ::= { vacmMIBConformance 2 }
  1353.  
  1354. -- Compliance statements *********************************************
  1355.  
  1356. vacmMIBCompliance MODULE-COMPLIANCE
  1357.     STATUS       current
  1358.     DESCRIPTION "The compliance statement for SNMP engines which
  1359.                  implement the SNMP View-based Access Control Model
  1360.                  configuration MIB.
  1361.                 "
  1362.     MODULE -- this module
  1363.         MANDATORY-GROUPS { vacmBasicGroup }
  1364.  
  1365.         OBJECT        vacmAccessContextMatch
  1366.         MIN-ACCESS    read-only
  1367.         DESCRIPTION  "Write access is not required."
  1368.         OBJECT        vacmAccessReadViewName
  1369.         MIN-ACCESS    read-only
  1370.         DESCRIPTION  "Write access is not required."
  1371.  
  1372.         OBJECT        vacmAccessWriteViewName
  1373.         MIN-ACCESS    read-only
  1374.         DESCRIPTION  "Write access is not required."
  1375.  
  1376.         OBJECT        vacmAccessNotifyViewName
  1377.         MIN-ACCESS    read-only
  1378.         DESCRIPTION  "Write access is not required."
  1379.  
  1380.         OBJECT        vacmAccessStorageType
  1381.         MIN-ACCESS    read-only
  1382.         DESCRIPTION  "Write access is not required."
  1383.  
  1384.         OBJECT        vacmAccessStatus
  1385.         MIN-ACCESS    read-only
  1386.         DESCRIPTION  "Create/delete/modify access to the
  1387.                       vacmAccessTable is not required.
  1388.                      "
  1389.  
  1390.         OBJECT        vacmViewTreeFamilyMask
  1391.         WRITE-SYNTAX  OCTET STRING (SIZE (0))
  1392.         MIN-ACCESS    read-only
  1393.         DESCRIPTION  "Support for configuration via SNMP of subtree
  1394.                       families using wild-cards is not required.
  1395.                      "
  1396.  
  1397.         OBJECT        vacmViewTreeFamilyType
  1398.         MIN-ACCESS    read-only
  1399.  
  1400.  
  1401.  
  1402. Wijnen, et. al.             Standards Track                    [Page 25]
  1403.  
  1404. RFC 2265                    VACM for SNMPv3                 January 1998
  1405.  
  1406.  
  1407.         DESCRIPTION  "Write access is not required."
  1408.  
  1409.         OBJECT        vacmViewTreeFamilyStorageType
  1410.         MIN-ACCESS    read-only
  1411.         DESCRIPTION  "Write access is not required."
  1412.  
  1413.         OBJECT        vacmViewTreeFamilyStatus
  1414.         MIN-ACCESS    read-only
  1415.         DESCRIPTION  "Create/delete/modify access to the
  1416.                       vacmViewTreeFamilyTable is not required.
  1417.                      "
  1418.     ::= { vacmMIBCompliances 1 }
  1419.  
  1420. -- Units of conformance **********************************************
  1421.  
  1422. vacmBasicGroup OBJECT-GROUP
  1423.     OBJECTS {
  1424.               vacmContextName,
  1425.               vacmGroupName,
  1426.               vacmSecurityToGroupStorageType,
  1427.               vacmSecurityToGroupStatus,
  1428.               vacmAccessContextMatch,
  1429.               vacmAccessReadViewName,
  1430.               vacmAccessWriteViewName,
  1431.               vacmAccessNotifyViewName,
  1432.               vacmAccessStorageType,
  1433.               vacmAccessStatus,
  1434.               vacmViewSpinLock,
  1435.               vacmViewTreeFamilyMask,
  1436.               vacmViewTreeFamilyType,
  1437.               vacmViewTreeFamilyStorageType,
  1438.               vacmViewTreeFamilyStatus
  1439.             }
  1440.     STATUS       current
  1441.     DESCRIPTION "A collection of objects providing for remote
  1442.                  configuration of an SNMP engine which implements
  1443.                  the SNMP View-based Access Control Model.
  1444.                 "
  1445.     ::= { vacmMIBGroups 1 }
  1446.  
  1447. END
  1448.  
  1449. 5.  Intellectual Property
  1450.  
  1451.    The IETF takes no position regarding the validity or scope of any
  1452.    intellectual property or other rights that might be claimed to
  1453.    pertain to the implementation or use of the technology described in
  1454.    this document or the extent to which any license under such rights
  1455.  
  1456.  
  1457.  
  1458. Wijnen, et. al.             Standards Track                    [Page 26]
  1459.  
  1460. RFC 2265                    VACM for SNMPv3                 January 1998
  1461.  
  1462.  
  1463.    might or might not be available; neither does it represent that it
  1464.    has made any effort to identify any such rights.  Information on the
  1465.    IETF's procedures with respect to rights in standards-track and
  1466.    standards-related documentation can be found in BCP-11.  Copies of
  1467.    claims of rights made available for publication and any assurances of
  1468.    licenses to be made available, or the result of an attempt made to
  1469.    obtain a general license or permission for the use of such
  1470.    proprietary rights by implementors or users of this specification can
  1471.    be obtained from the IETF Secretariat.
  1472.  
  1473.    The IETF invites any interested party to bring to its attention any
  1474.    copyrights, patents or patent applications, or other proprietary
  1475.    rights which may cover technology that may be required to practice
  1476.    this standard.  Please address the information to the IETF Executive
  1477.    Director.
  1478.  
  1479. 6.  Acknowledgements
  1480.  
  1481.    This document is the result of the efforts of the SNMPv3 Working
  1482.    Group.  Some special thanks are in order to the following SNMPv3 WG
  1483.    members:
  1484.  
  1485.    Dave Battle (SNMP Research, Inc.)
  1486.    Uri Blumenthal (IBM T.J. Watson Research Center)
  1487.    Jeff Case (SNMP Research, Inc.)
  1488.    John Curran (BBN)
  1489.    T. Max Devlin (Hi-TECH Connections)
  1490.    John Flick (Hewlett Packard)
  1491.    David Harrington (Cabletron Systems Inc.)
  1492.    N.C. Hien (IBM T.J. Watson Research Center)
  1493.    Dave Levi (SNMP Research, Inc.)
  1494.    Louis A Mamakos (UUNET Technologies Inc.)
  1495.    Paul Meyer (Secure Computing Corporation)
  1496.    Keith McCloghrie (Cisco Systems)
  1497.    Russ Mundy (Trusted Information Systems, Inc.)
  1498.    Bob Natale (ACE*COMM Corporation)
  1499.    Mike O'Dell (UUNET Technologies Inc.)
  1500.    Dave Perkins (DeskTalk)
  1501.    Peter Polkinghorne (Brunel University)
  1502.    Randy Presuhn (BMC Software, Inc.)
  1503.    David Reid (SNMP Research, Inc.)
  1504.    Shawn Routhier (Epilogue)
  1505.    Juergen Schoenwaelder (TU Braunschweig)
  1506.    Bob Stewart (Cisco Systems)
  1507.    Bert Wijnen (IBM T.J. Watson Research Center)
  1508.  
  1509.  
  1510.  
  1511.  
  1512.  
  1513.  
  1514. Wijnen, et. al.             Standards Track                    [Page 27]
  1515.  
  1516. RFC 2265                    VACM for SNMPv3                 January 1998
  1517.  
  1518.  
  1519.    The document is based on recommendations of the IETF Security and
  1520.    Administrative Framework Evolution for SNMP Advisory Team.  Members
  1521.    of that Advisory Team were:
  1522.  
  1523.    David Harrington (Cabletron Systems Inc.)
  1524.    Jeff Johnson (Cisco Systems)
  1525.    David Levi (SNMP Research Inc.)
  1526.    John Linn (Openvision)
  1527.    Russ Mundy (Trusted Information Systems) chair
  1528.    Shawn Routhier (Epilogue)
  1529.    Glenn Waters (Nortel)
  1530.    Bert Wijnen (IBM T. J. Watson Research Center)
  1531.  
  1532.    As recommended by the Advisory Team and the SNMPv3 Working Group
  1533.    Charter, the design incorporates as much as practical from previous
  1534.    RFCs and drafts. As a result, special thanks are due to the authors
  1535.    of previous designs known as SNMPv2u and SNMPv2*:
  1536.  
  1537.    Jeff Case (SNMP Research, Inc.)
  1538.    David Harrington (Cabletron Systems Inc.)
  1539.    David Levi (SNMP Research, Inc.)
  1540.    Keith McCloghrie (Cisco Systems)
  1541.    Brian O'Keefe (Hewlett Packard)
  1542.    Marshall T. Rose (Dover Beach Consulting)
  1543.    Jon Saperia (BGS Systems Inc.)
  1544.    Steve Waldbusser (International Network Services)
  1545.    Glenn W. Waters (Bell-Northern Research Ltd.)
  1546.  
  1547. 7.  Security Considerations
  1548.  
  1549. 7.1.  Recommended Practices
  1550.  
  1551.    This document is meant for use in the SNMP architecture.  The View-
  1552.    based Access Control Model described in this document checks access
  1553.    rights to management information based on:
  1554.  
  1555.    - contextName, representing a set of management information at the
  1556.      managed system where the Access Control module is running.
  1557.    - groupName, representing a set of zero or more securityNames.
  1558.      The combination of a securityModel and a securityName is mapped
  1559.      into a group in the View-based Access Control Model.
  1560.    - securityModel under which access is requested.
  1561.    - securityLevel under which access is requested.
  1562.    - operation performed on the management information.
  1563.    - MIB views for read, write or notify access.
  1564.  
  1565.  
  1566.  
  1567.  
  1568.  
  1569.  
  1570. Wijnen, et. al.             Standards Track                    [Page 28]
  1571.  
  1572. RFC 2265                    VACM for SNMPv3                 January 1998
  1573.  
  1574.  
  1575.    When the User-based Access Control module is called for checking
  1576.    access rights, it is assumed that the calling module has ensured the
  1577.    authentication and privacy aspects as specified by the securityLevel
  1578.    that is being passed.
  1579.  
  1580.    When creating entries in or deleting entries from the
  1581.    vacmViewFamiliyTreeTable it is important to do such in the sequence
  1582.    as recommended in the DESCRIPTION clause of the vacmViewFamilityTable
  1583.    definition. Otherwise unwanted access may be granted while changing
  1584.    the entries in the table.
  1585.  
  1586. 7.2.  Defining Groups
  1587.  
  1588.    The groupNames are used to give access to a group of zero or more
  1589.    securityNames.  Within the View-Based Access Control Model, a
  1590.    groupName is considered to exist if that groupName is listed in the
  1591.    vacmSecurityToGroupTable.
  1592.  
  1593.    By mapping the combination of a securityModel and securityName into a
  1594.    groupName, an SNMP Command Generator application can add/delete
  1595.    securityNames to/from a group, if proper access is allowed.
  1596.  
  1597.    Further it is important to realize that the grouping of
  1598.    <securityModel, securityName> tuples in the vacmSecurityToGroupTable
  1599.    does not take securityLevel into account. It is therefore important
  1600.    that the security administrator uses the securityLevel index in the
  1601.    vacmAccessTable to separate noAuthNoPriv from authPriv and/or
  1602.    authNoPriv access.
  1603.  
  1604. 7.3.  Conformance
  1605.  
  1606.    For an implementation of the View-based Access Control Model to be
  1607.    conformant, it MUST implement the SNMP-VIEW-BASED-ACM-MIB.  It also
  1608.    SHOULD implement the initial configuration, described in appendix A.
  1609.  
  1610. 8.  References
  1611.  
  1612.    [RFC1902] Case, J., McCloghrie, K., Rose, M. and S., Waldbusser,
  1613.         "Structure of Management Information for Version  2 of the
  1614.         Simple Network Management Protocol (SNMPv2)", RFC 1902, January
  1615.         1996.
  1616.  
  1617.    [RFC1903] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
  1618.         "Textual Conventions for Version 2 of the Simple Network
  1619.         Management Protocol (SNMPv2)", RFC 1903, January 1996.
  1620.  
  1621.    [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
  1622.         Requirement Levels", BCP 14, RFC 2119, March 1997.
  1623.  
  1624.  
  1625.  
  1626. Wijnen, et. al.             Standards Track                    [Page 29]
  1627.  
  1628. RFC 2265                    VACM for SNMPv3                 January 1998
  1629.  
  1630.  
  1631.    [RFC2261] Harrington, D., Presuhn, R., and B. Wijnen,
  1632.         "An Architecture for describing SNMP Management Frameworks", RFC
  1633.         2261, January 1998.
  1634.  
  1635.    [RFC2262] Case, J., Harrington, D., Presuhn, R., and B. Wijnen,
  1636.         "Message Processing and Dispatching for the Simple Network
  1637.         Management Protocol (SNMP)", RFC 2262, January 1998.
  1638.  
  1639.    [RFC2264] Blumenthal, U., and B. Wijnen, "User-based
  1640.         Security Model (USM) for version 3 of the Simple Network
  1641.         Management Protocol (SNMPv3)", RFC 2264, January 1998.
  1642.  
  1643.    [ISO-ASN.1] Information processing systems - Open Systems
  1644.         Interconnection - Specification of Abstract Syntax Notation One
  1645.         (ASN.1), International Organization for Standardization.
  1646.         International Standard 8824, (December, 1987).
  1647.  
  1648. 9.  Editors' Addresses
  1649.  
  1650.    Bert Wijnen
  1651.    IBM T. J. Watson Research
  1652.    Schagen 33
  1653.    3461 GL Linschoten
  1654.    Netherlands
  1655.  
  1656.    EMail:      wijnen@vnet.ibm.com
  1657.    Phone:      +31-348-432-794
  1658.  
  1659.  
  1660.    Randy Presuhn
  1661.    BMC Software, Inc
  1662.    1190 Saratoga Avenue, Suite 130
  1663.    San Jose, CA  95129-3433
  1664.    USA
  1665.  
  1666.    EMail:      rpresuhn@bmc.com
  1667.    Phone:      +1-408-556-0720
  1668.  
  1669.  
  1670.    Keith McCloghrie
  1671.    Cisco Systems, Inc.
  1672.    170 West Tasman Drive
  1673.    San Jose, CA  95134-1706
  1674.    USA
  1675.  
  1676.    EMail:      kzm@cisco.com
  1677.    Phone:      +1-408-526-5260
  1678.  
  1679.  
  1680.  
  1681.  
  1682. Wijnen, et. al.             Standards Track                    [Page 30]
  1683.  
  1684. RFC 2265                    VACM for SNMPv3                 January 1998
  1685.  
  1686.  
  1687. APPENDIX A - Installation
  1688.  
  1689. A.1.  Installation Parameters
  1690.  
  1691.    During installation, an authoritative SNMP engine which supports this
  1692.    View-based Access Control Model SHOULD be configured with several
  1693.    initial parameters.  These include for the View-based Access Control
  1694.    Model:
  1695.  
  1696. 1) A security configuration
  1697.  
  1698.    The choice of security configuration determines if initial
  1699.    configuration is implemented and if so how.  One of three possible
  1700.    choices is selected:
  1701.  
  1702.         - initial-minimum-security-configuration
  1703.         - initial-semi-security-configuration
  1704.         - initial-no-access-configuration
  1705.  
  1706.    In the case of a initial-no-access-configuration, there is no initial
  1707.    configuration, and so the following steps are irrelevant.
  1708.  
  1709. 2) A default context
  1710.  
  1711.    One entry in the vacmContextTable with a contextName of "" (the empty
  1712.    string), representing the default context.  Note that this table gets
  1713.    created automatically if a default context exists.
  1714.  
  1715.                                  no privacy support  privacy support
  1716.                                  ------------------  ---------------
  1717.     vacmContextName              ""                  ""
  1718.  
  1719. 3) An initial group
  1720.  
  1721.    One entry in the vacmSecurityToGroupTable to allow access to group
  1722.    "initial".
  1723.  
  1724.                                  no privacy support  privacy support
  1725.                                  ------------------  ---------------
  1726.   vacmSecurityModel              3 (USM)             3 (USM)
  1727.   vacmSecurityName               "initial"           "initial"
  1728.   vacmGroupName                  "initial"           "initial"
  1729.   vacmSecurityToGroupStorageType anyValidStorageType anyValidStorageType
  1730.   vacmSecurityToGroupStatus      active              active
  1731.  
  1732.  
  1733.  
  1734.  
  1735.  
  1736.  
  1737.  
  1738. Wijnen, et. al.             Standards Track                    [Page 31]
  1739.  
  1740. RFC 2265                    VACM for SNMPv3                 January 1998
  1741.  
  1742.  
  1743. 4) Initial access rights
  1744.  
  1745.    Three entries in the vacmAccessTable as follows:
  1746.  
  1747.    - read-notify access for securityModel USM, securityLevel
  1748.      "noAuthNoPriv" on behalf of securityNames that belong to the group
  1749.      "initial" to the <restricted> MIB view in the default context with
  1750.      contextName "".
  1751.  
  1752.    - read-write-notify access for securityModel USM, securityLevel
  1753.      "authNoPriv" on behalf of securityNames that belong to the group
  1754.      "initial" to the <internet> MIB view in the default context with
  1755.      contextName "".
  1756.  
  1757.    - if privacy is supported,
  1758.      read-write-notify access for securityModel USM, securityLevel
  1759.      "authPriv" on behalf of securityNames that belong to the group
  1760.      "initial" to the <internet> MIB view in the default context with
  1761.      contextName "".
  1762.  
  1763.    That translates into the following entries in the vacmAccessTable.
  1764.    Those columns marked with (index) are index-only objects and are not
  1765.    really present in this table.
  1766.  
  1767.    - One entry to be used for unauthenticated access (noAuthNoPriv):
  1768.  
  1769.  
  1770.                                no privacy support  privacy support
  1771.                                ------------------  ---------------
  1772.     vacmAccessContextPrefix    ""                  ""
  1773.     vacmGroupName     (index)  "initial"           "initial"
  1774.     vacmSecurityModel (index)  3 (USM)             3 (USM)
  1775.     vacmAccessSecurityLevel    noAuthNoPriv        noAuthNoPriv
  1776.     vacmAccessReadViewName     "restricted"        "restricted"
  1777.     vacmAccessWriteViewName    ""                  ""
  1778.     vacmAccessNotifyViewName   "restricted"        "restricted"
  1779.     vacmAccessStorageType      anyValidStorageType anyValidStorageType
  1780.     vacmAccessStatus           active              active
  1781.  
  1782.    - One entry to be used for authenticated access but without
  1783.      privacy (authNoPriv):
  1784.                                no privacy support  privacy support
  1785.                                ------------------  ---------------
  1786.     vacmAccessContextPrefix    ""                  ""
  1787.     vacmGroupName     (index)  "initial"           "initial"
  1788.     vacmSecurityModel (index)  3 (USM)             3 (USM)
  1789.     vacmAccessSecurityLevel    authNoPriv          authNoPriv
  1790.     vacmAccessReadViewName     "internet"          "internet"
  1791.  
  1792.  
  1793.  
  1794. Wijnen, et. al.             Standards Track                    [Page 32]
  1795.  
  1796. RFC 2265                    VACM for SNMPv3                 January 1998
  1797.  
  1798.  
  1799.     vacmAccessWriteViewName    "internet"          "internet"
  1800.     vacmAccessNotifyViewName   "internet"          "internet"
  1801.     vacmAccessStorageType      anyValidStorageType anyValidStorageType
  1802.     vacmAccessStatus           active              active
  1803.  
  1804.    - One entry to be used for authenticated access with privacy
  1805.      (authPriv):
  1806.  
  1807.                                no privacy support  privacy support
  1808.                                ------------------  ---------------
  1809.     vacmAccessContextPrefix                        ""
  1810.     vacmGroupName     (index)                      "initial"
  1811.     vacmSecurityModel (index)                      3 (USM)
  1812.     vacmAccessSecurityLevel                        authPriv
  1813.     vacmAccessReadViewName                         "internet"
  1814.     vacmAccessWriteViewName                        "internet"
  1815.     vacmAccessNotifyViewName                       "internet"
  1816.     vacmAccessStorageType                          anyValidStorageType
  1817.     vacmAccessStatus                               active
  1818.  
  1819. 5) Two MIB views, of which the second one depends on the security
  1820.    configuration.
  1821.  
  1822.    -  One view, the <internet> view, for authenticated access:
  1823.  
  1824.       -  the <internet> MIB view is the following subtree:
  1825.              "internet"  (subtree 1.3.6.1)
  1826.  
  1827.    -  A second view, the <restricted> view, for unauthenticated
  1828.       access.  This view is configured according to the selected
  1829.       security configuration:
  1830.  
  1831.       -  For the initial-no-access-configuration there is no default
  1832.          initial configuration, so no MIB views are pre-scribed.
  1833.  
  1834.       -  For the initial-semi-secure-configuration:
  1835.  
  1836.          the <restricted> MIB view is the union of these subtrees:
  1837.          (a) "system"       (subtree 1.3.6.1.2.1.1)     [RFC1907]
  1838.          (b) "snmp"         (subtree 1.3.6.1.2.1.11)    [RFC1907]
  1839.          (c) "snmpEngine"   (subtree 1.3.6.1.6.3.7.2.1) [RFC2261]
  1840.          (d) "snmpMPDStats" (subtree 1.3.6.1.6.3.8.2.1) [RFC2262]
  1841.          (e) "usmStats"     (subtree 1.3.6.1.6.3.9.2.1) [RFC2264]
  1842.  
  1843.       -  For the initial-minimum-secure-configuration:
  1844.  
  1845.          the <restricted> MIB view is the following subtree.
  1846.              "internet"  (subtree 1.3.6.1)
  1847.  
  1848.  
  1849.  
  1850. Wijnen, et. al.             Standards Track                    [Page 33]
  1851.  
  1852. RFC 2265                    VACM for SNMPv3                 January 1998
  1853.  
  1854.  
  1855.    This translates into the following "internet" entry in the
  1856.    vacmViewTreeFamilyTable:
  1857.  
  1858.                                 minimum-secure      semi-secure
  1859.                                 ----------------    ---------------
  1860.   vacmViewTreeFamilyViewName    "internet"          "internet"
  1861.   vacmViewTreeFamilySubtree     1.3.6.1             1.3.6.1
  1862.   vacmViewTreeFamilyMask        ""                  ""
  1863.   vacmViewTreeFamilyType        1 (included)        1 (included)
  1864.   vacmViewTreeFamilyStorageType anyValidStorageType anyValidStorageType
  1865.   vacmViewTreeFamilyStatus      active              active
  1866.  
  1867.    In addition it translates into the following "restricted" entries
  1868.    in the vacmViewTreeFamilyTable:
  1869.  
  1870.                                 minimum-secure      semi-secure
  1871.                                 ----------------    ---------------
  1872.   vacmViewTreeFamilyViewName    "restricted"        "restricted"
  1873.   vacmViewTreeFamilySubtree     1.3.6.1             1.3.6.1.2.1.1
  1874.   vacmViewTreeFamilyMask        ""                  ""
  1875.   vacmViewTreeFamilyType        1 (included)        1 (included)
  1876.   vacmViewTreeFamilyStorageType anyValidStorageType anyValidStorageType
  1877.   vacmViewTreeFamilyStatus      active              active
  1878.  
  1879.   vacmViewTreeFamilyViewName                        "restricted"
  1880.   vacmViewTreeFamilySubtree                         1.3.6.1.2.1.11
  1881.   vacmViewTreeFamilyMask                            ""
  1882.   vacmViewTreeFamilyType                            1 (included)
  1883.   vacmViewTreeFamilyStorageType                     anyValidStorageType
  1884.   vacmViewTreeFamilyStatus                          active
  1885.  
  1886.   vacmViewTreeFamilyViewName                        "restricted"
  1887.   vacmViewTreeFamilySubtree                         1.3.6.1.6.3.7.2.1
  1888.   vacmViewTreeFamilyMask                            ""
  1889.   vacmViewTreeFamilyType                            1 (included)
  1890.   vacmViewTreeFamilyStorageType                     anyValidStorageType
  1891.   vacmViewTreeFamilyStatus                          active
  1892.  
  1893.   vacmViewTreeFamilyViewName                        "restricted"
  1894.   vacmViewTreeFamilySubtree                         1.3.6.1.6.3.8.2.1
  1895.   vacmViewTreeFamilyMask                            ""
  1896.   vacmViewTreeFamilyType                            1 (included)
  1897.   vacmViewTreeFamilyStorageType                     anyValidStorageType
  1898.   vacmViewTreeFamilyStatus                          active
  1899.  
  1900.   vacmViewTreeFamilyViewName                        "restricted"
  1901.   vacmViewTreeFamilySubtree                         1.3.6.1.6.3.9.2.1
  1902.   vacmViewTreeFamilyMask                            ""
  1903.  
  1904.  
  1905.  
  1906. Wijnen, et. al.             Standards Track                    [Page 34]
  1907.  
  1908. RFC 2265                    VACM for SNMPv3                 January 1998
  1909.  
  1910.  
  1911.   vacmViewTreeFamilyType                            1 (included)
  1912.   vacmViewTreeFamilyStorageType                     anyValidStorageType
  1913.   vacmViewTreeFamilyStatus                          active
  1914.  
  1915.  
  1916.  
  1917.  
  1918.  
  1919.  
  1920.  
  1921.  
  1922.  
  1923.  
  1924.  
  1925.  
  1926.  
  1927.  
  1928.  
  1929.  
  1930.  
  1931.  
  1932.  
  1933.  
  1934.  
  1935.  
  1936.  
  1937.  
  1938.  
  1939.  
  1940.  
  1941.  
  1942.  
  1943.  
  1944.  
  1945.  
  1946.  
  1947.  
  1948.  
  1949.  
  1950.  
  1951.  
  1952.  
  1953.  
  1954.  
  1955.  
  1956.  
  1957.  
  1958.  
  1959.  
  1960.  
  1961.  
  1962. Wijnen, et. al.             Standards Track                    [Page 35]
  1963.  
  1964. RFC 2265                    VACM for SNMPv3                 January 1998
  1965.  
  1966.  
  1967. B.  Full Copyright Statement
  1968.  
  1969.    Copyright (C) The Internet Society (1997).  All Rights Reserved.
  1970.  
  1971.    This document and translations of it may be copied and furnished to
  1972.    others, and derivative works that comment on or otherwise explain it
  1973.    or assist in its implementation may be prepared, copied, published
  1974.    and distributed, in whole or in part, without restriction of any
  1975.    kind, provided that the above copyright notice and this paragraph are
  1976.    included on all such copies and derivative works.  However, this
  1977.    document itself may not be modified in any way, such as by removing
  1978.    the copyright notice or references to the Internet Society or other
  1979.    Internet organizations, except as needed for the purpose of
  1980.    developing Internet standards in which case the procedures for
  1981.    copyrights defined in the Internet Standards process must be
  1982.    followed, or as required to translate it into languages other than
  1983.    English.
  1984.  
  1985.    The limited permissions granted above are perpetual and will not be
  1986.    revoked by the Internet Society or its successors or assigns.
  1987.  
  1988.    This document and the information contained herein is provided on an
  1989.    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
  1990.    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
  1991.    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
  1992.    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
  1993.    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
  1994.  
  1995.  
  1996.  
  1997.  
  1998.  
  1999.  
  2000.  
  2001.  
  2002.  
  2003.  
  2004.  
  2005.  
  2006.  
  2007.  
  2008.  
  2009.  
  2010.  
  2011.  
  2012.  
  2013.  
  2014.  
  2015.  
  2016.  
  2017.  
  2018. Wijnen, et. al.            3
  2019.    3461 GL Linschot               [Page 36]
  2020.  
  2021.