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

                            1 August 1997


                             Bert Wijnen
                       IBM T. J. Watson Research
                          wijnen@vnet.ibm.com

                            Randy Presuhn
                          BMC Software, Inc.
                           rpresuhn@bmc.com

                           Keith McCloghrie
                          Cisco Systems, Inc.
                             kzm@cisco.com


                    <draft-ietf-snmpv3-acm-02.txt>


                          Status of this Memo

This document is an Internet-Draft.  Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups.  Note that other groups may also distribute
working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time.  It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as ``work in progress.''

To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow
Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe),
ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).


                          Abstract

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










Wijnen/Presuhn/McCloghrie     Expires February 1998           [Page  1]

Draft    View-based Access Control Model (VACM) for SNMP    August 1997


0.  Issues and Change Log

0.1.  Resolved issues
  - There is a reverse mapping from groupName to securityName, see
    the acmGroupListTable. However, given the amount of object
    we're adding, we may want to remove/postpone this table?
    Resolution: remove for now.
  - Do we need/want the level of detail of errorIndication that
    the isAccessAllowed primitive will return? Those who strongly
    object to the details listed now, better let us know (on the
    mailing list preferably) ASAP.
    Resolution: yes.
  - Should we use human readable strings or integers for an index for
    the tables.
    Resolution. It was decided at the 1st and 2nd interim meeting that
    using human readable strings would be very helpful when humans
    have to configure many of those tables.  We must specify the size
    limits for objects that have a human readable SnmpAdminString and
    which are used for indexing. It seems that a size limit of 32
    is appropriate and acceptable (although tight in some languages).
    Note also, that the issue is not just ACM, it is a general issue
    that applies to all MIBs in all documents.
  - Ensure valid indices.
    Resolution. String based indices now have a size limit to ensure
    that the resulting OIDs for instances will not exceed the limits
    defined in RFC1905.
  - The initial "all-iso" MIB view was not workable.
    Resolution. Define and use the "internet" MIB view instead.


0.2.  Change Log

[version 5.2] - This is the August 1 version.
  - Incorporate comments from Keith
  - Incorporate comments from Randy
  - Add figure to section 3
  - Update References
  - Update acknowledgement section
  - Add reference to RowStatus TC when using RowStatus
  - Spell check once more
  - Paginate
  - Post to I-D repository and SNMPv3 mailing list as:
    <draft-ietf-snmpv3-acm-02.txt>

[version 5.1] - This is the July 28 version.
  - Spell check
  - SMICng check

[version 5.0] - This is the July 24 version.
  - various types and editorial changes
  - Adapt to latest Service Primitives



Wijnen/Presuhn/McCloghrie     Expires February 1998           [Page  2]

Draft    View-based Access Control Model (VACM) for SNMP    August 1997


  - remove acmGroupListTable
  - change index sequence for acmSecurityToGroupTable
  - rename prefix from acm to vacm
  - rename LoS to securityLevel
  - Changes as a result of comments on snmpv3 list
  - use the bridge MIB as an example instead of repeater MIB.
  - rename "security-posture" to "initial-configuration"

[version 4.2] - This is the July 14 version.
  - Address comments by Keith:
    - Renumber section 2.4 to 2.5
    - Add new sections 2.4, 2.4.1, 2.4.2 about MIB Views and Subtrees
      and Families,
    - Use some more precise language at various places.
  - Add reference to RFC2119 about use of SHOULD and MUST
  - rename the acmGroupTable to acmSecurityToGroupTable because that
    much better indicates the function of this table.
  - improved the writeup on statusInformation for the isAccessAllowed
    primitive.
  - paginate and generate table of contents
  - posted as I-D <draft-ietf-snmpv3-acm-01.txt> on 15 July

[version 4.1] - This is the July 12 version.
  - Adapt to latest list of Primitives/Parameters.
  - Handle comments from co-editor Randy
  - Added the SHOULD "initial" configuration
  - Checked the MIB with SMICng

[version 4.0] - This is the July 7 version.
  - Adopt to decisions/comments made are 2nd interim
    - securityName to groupName mapping is in ACM
    - out of the box configurations to be described as SHOULD
    - UTF-8 issue still open, but move to general issue (ARCH)
      where the SnmpAdminString is defined.
    - ACM returns errorIndication based on which the caller
      may increment error counter which may result in a
      Report PDU.
    - No statistics counters are kept in ACM
    - removed viewTable; added acmViewSpinLock
  - Address various comments from co-editors (Randy and Keith)
  - Address comments made on mailing list(s).

[version 3.1] - This is the June 18 version.
  - remove old (resolved) issues
  - list new issues
  - corrections/additions by myself (Bert)
  - corrections based on dbh comments
  - removed change log of before 1st interim meeting.

[version 3.0] - this is the first ACM document (June 12 version).
  - Modifications as agreed at 1st Interim Meeting



Wijnen/Presuhn/McCloghrie     Expires February 1998           [Page  3]

Draft    View-based Access Control Model (VACM) for SNMP    August 1997


    - Make Access Control Module a separate document
    - Use viewName as index instead of an integer
    - add notify_view
    - use SnmpAdminString
    - Other Modification
    - use miId and securityModel
    - add acmGroupTable
    - add/rename Stats counters














































Wijnen/Presuhn/McCloghrie     Expires February 1998           [Page  4]

Draft    View-based Access Control Model (VACM) for SNMP    August 1997


1.  Introduction

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

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

   Applications make use of the services of these subsystems.

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

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

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


1.2.  Access Control

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

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

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






Wijnen/Presuhn/McCloghrie     Expires February 1998           [Page  5]

Draft    View-based Access Control Model (VACM) for SNMP    August 1997


1.3.  Local Configuration Datastore

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

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










































Wijnen/Presuhn/McCloghrie     Expires February 1998           [Page  6]

Draft    View-based Access Control Model (VACM) for SNMP    August 1997


2.  Elements of the Model

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


2.1.  Groups

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

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

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


2.2.  securityLevel

   Different access rights for members of a group can be defined for
   different Levels of Security.  The securityLevel identifies the
   Level of Security that will be assumed when checking for access
   rights.  See the SNMP Architecture document [SNMP-ARCH] for a
   definition of securityLevel.

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


2.3.  Contexts

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

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





Wijnen/Presuhn/McCloghrie     Expires February 1998           [Page  7]

Draft    View-based Access Control Model (VACM) for SNMP    August 1997


2.4.  MIB Views and View Families

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

   Since managed object types (and their instances) are identified via
   the tree-like naming structure of ISO's OBJECT IDENTIFIERs
   [ISO-ASN.1, RFC1902],  it is convenient to define a MIB view as the
   combination of a set of "view subtrees", where each view subtree is
   a subtree within the managed object naming tree.  Thus, a simple
   MIB view (e.g., all managed objects within the Internet Network
   Management Framework) can be defined as a single view subtree,
   while more complicated MIB views (e.g., all information relevant to
   a particular network interface) can be represented by the union of
   multiple view subtrees.

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


2.4.1.  View Subtree

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


2.4.2.  ViewTreeFamily

   A family of view subtrees is a pairing of an OBJECT IDENTIFIER value



Wijnen/Presuhn/McCloghrie     Expires February 1998           [Page  8]

Draft    View-based Access Control Model (VACM) for SNMP    August 1997


   (called the family name) together with a bit string value (called
   the family mask).  The family mask indicates which sub-identifiers
   of the associated family name are significant to the family's
   definition.

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

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

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

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

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


2.5.  Access Policy

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

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

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

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




Wijnen/Presuhn/McCloghrie     Expires February 1998           [Page  9]

Draft    View-based Access Control Model (VACM) for SNMP    August 1997


3.  Elements of Procedure

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

     statusInformation =          -- success or errorIndication
         isAccessAllowed(
             securityModel        -- Security Model in use
             securityName         -- principal who wants access
             securityLevel        -- Level of Security
             viewType             -- read, write, or notify view
             contextName          -- context containing variableName
             variableName         -- OID for the managed object
             )

   The abstract data elements are:

     statusInformation - one of the following:
        accessAllowed  - a MIB view was found and access is granted.
        notInView      - a MIB view was found but access is denied.
                         The variableName is not in the configured
                         MIB view for the specified viewType (e.g. in
                         the relevant entry in the vacmAccessTable).
        noSuchView     - no MIB view found because no view has been
                         configured for specified viewType (e.g. in
                         the relevant entry in the vacmAccessTable).
        noSuchContext  - no MIB view found because of no entry in the
                         vacmContextTable for specified contextName.
        noGroupName    - no MIB view found because no entry has been
                         configured in the vacmSecurityToGroupTable
                         for the specified combination of
                         securityModel and securityName.
        noAccessEntry  - no MIB view found because no entry has been
                         configured in the vacmAccessTable for the
                         specified combination of contextName,
                         groupName (from vacmSecurityToGroupTable),
                         securityModel and securityLevel.
        otherError     - failure, an undefined error occurred.
     securityModel - Security Model under which access is requested.
     securityName  - the principal on whose behalf access is requested.
     securityLevel - Level of Security under which access is requested.
     viewType      - view to be checked (read, write or notify).
     contextName   - context in which access is requested.
     variableName  - object instance to which access is requested.







Wijnen/Presuhn/McCloghrie     Expires February 1998           [Page 10]


Draft    View-based Access Control Model (VACM) for SNMP    August 1997


3.1.  Overview  of isAccessAllowed Process

 +--------------------------------------------------------------------+
 |                                                                    |
 |      +-> securityModel -+                                          |
 |      |   (a)            |                                          |
 | who -+                  +-> groupName ----+                        |
 | (1)  |                  |   (x)           |                        |
 |      +-> securityName --+                 |                        |
 |          (b)                              |                        |
 |                                           |                        |
 | where -> contextName ---------------------+                        |
 | (2)      (e)                              |                        |
 |                                           |                        |
 |                                           |                        |
 |      +-> securityModel -------------------+                        |
 |      |   (a)                              |                        |
 | how -+                                    +-> viewName -+          |
 | (3)  |                                    |   (y)       |          |
 |      +-> securityLevel -------------------+             |          |
 |          (c)                              |             +-> yes/no |
 |                                           |             | decision |
 | why ---> viewType (read/write/notify) ----+             | (z)      |
 | (4)      (d)                                            |          |
 |                                                         |          |
 | what --> object-type ------+                            |          |
 | (5)      (m)               |                            |          |
 |                            +-> variableName (OID) ------+          |
 |                            |   (f)                                 |
 | which -> object-instance --+                                       |
 | (6)      (n)                                                       |
 |                                                                    |
 +--------------------------------------------------------------------+

 How the decision for isAccessAllowed is made.

 -  Inputs to the isAccessAllowed service are:

    (a)       securityModel    -- Security Model in use
    (b)       securityName     -- principal who wants to access
    (c)       securityLevel    -- Level of Security
    (d)       viewType         -- read, write, or notify view
    (e)       contextName      -- context containing variableName
    (f)       variableName     -- OID for the managed object

 -  The partial "who" (1), represented by the securityModel (a) and
    the securityName (b), are used as the indices (a,b) into the
    vacmSecurityToGroupTable to find a single entry that produces a
    group, represented by groupName (x).

 -  The "where" (2), represented by the contextName (e), the "who",



Wijnen/Presuhn/McCloghrie     Expires February 1998           [Page 11]


Draft    View-based Access Control Model (VACM) for SNMP    August 1997


    represented by the groupName (x) from the previous step, and the
    "how" (3), represented by securityModel (a) and securityLevel (c),
    are used as indices (e,x,a,c) into the vacmAccessTable to find a
    single entry that contains three MIB views.

 -  The "why" (4), represented by the viewType (d), is used to select
    the proper MIB view, represented by a viewName (y), from the
    vacmAccessEntry selected in the previous step. This viewName (y)
    is an index into the vacmViewTreeFamilyTable and selects the set
    of entries that define the variableNames which are included in
    or excluded from the MIB view identified by the viewName (y).

 -  The "what" (5) type of management data and "which" (6) particular
    instance, represented by the variableName (f), is then checked to
    be in the MIB view or not, e.g. the yes/no decision (z).

3.2.  Processing the isAccessAllowed Service Request

   This section describes the procedure followed by an Access Control
   module that implements the View-based Access Control Model
   whenever it receives an isAccessAllowed request.

   1) The vacmContextTable is consulted for information about
      the SNMP context identified by the contextName.  If information
      about this SNMP context is absent from the table, then an
      errorIndication (noSuchContext) is returned to the calling
      module.

   2) The vacmSecurityToGroupTable is consulted for mapping the
      securityModel and securityName to a groupName.  If the
      information about this combination is absent from the table,
      then an errorIndication (noGroupName) is returned to the
      calling module.

   3) The vacmAccessTable is consulted for information about the
      groupName, contextName, securityModel and securityLevel.  If
      information about this combination is absent from the table,
      then an errorIndication (noAccessEntry) is returned to the
      calling module.

   4) a) If the viewType is "read", then the read view is used for
         checking access rights.

      b) If the viewType is "write", then the write view is used for
         checking access rights.

      c) If the viewType is "notify", then the notify view is used
         for checking access rights.

      If the view to be used is the empty view (zero length viewName)
      then an errorIndication (noSuchView) is returned to the calling



Wijnen/Presuhn/McCloghrie     Expires February 1998           [Page 12]


Draft    View-based Access Control Model (VACM) for SNMP    August 1997


      module.

   5) a) If there is no view configured for the specified viewType,
         then an errorIndication (noSuchView) is returned to the
         calling module.

      b) If the specified variableName (object instance) is not in the
         MIB view (see DESCRIPTION clause for vacmViewTreeFamilyTable
         in section 4), then an errorIndication (notInView) is returned
         to the calling module.

         Otherwise,

      c) The specified variableName is in the MIB view.
         A statusInformation of success (accessAllowed) is returned
         to the calling module.






































Wijnen/Presuhn/McCloghrie     Expires February 1998           [Page 13]


Draft    View-based Access Control Model (VACM) for SNMP    August 1997


4.  Definitions

SNMP-VIEW-BASED-ACM-MIB DEFINITIONS ::= BEGIN

IMPORTS
    MODULE-COMPLIANCE, OBJECT-GROUP       FROM SNMPv2-CONF
    MODULE-IDENTITY, OBJECT-TYPE,
    snmpModules                           FROM SNMPv2-SMI
    TestAndIncr,
    RowStatus, StorageType                FROM SNMPv2-TC
    SnmpAdminString,
    SnmpSecurityLevel,
    SnmpSecurityModel                     FROM SNMP-FRAMEWORK-MIB;

snmpVacmMIB       MODULE-IDENTITY
    LAST-UPDATED "9707290000Z"            -- 29 July 1997, midnight
    ORGANIZATION "SNMPv3 Working Group"
    CONTACT-INFO "WG-email:   snmpv3@tis.com
                  Subscribe:  majordomo@tis.com
                              In message body:  subscribe snmpv3

                  Chair:      Russ Mundy
                              Trusted Information Systems
                  postal:     3060 Washington Rd
                              Glenwood MD 21738
                              USA
                  email:      mundy@tis.com
                  phone:      +1-301-854-6889

                  Co-editor:  Bert Wijnen
                              IBM T.J. Watson Research
                  postal:     Schagen 33
                              3461 GL Linschoten
                              Netherlands
                  email:      wijnen@vnet.ibm.com
                  phone:      +31-348-432-794

                  Co-editor:  Randy Presuhn
                              BMC Software, Inc
                  postal:     1190 Saratoga Avenue, Suite 130
                              San Jose, CA  95129-3433
                              USA
                  email:      rpresuhn@bmc.com
                  phone:      +1-408-556-0720

                  Co-editor:  Keith McCloghrie
                              Cisco Systems, Inc.
                  postal:     170 West Tasman Drive
                              San Jose, CA  95134-1706
                              USA
                  email:      kzm@cisco.com



Wijnen/Presuhn/McCloghrie     Expires February 1998           [Page 14]


Draft    View-based Access Control Model (VACM) for SNMP    August 1997


                  phone:      +1-408-526-5260
                 "
    DESCRIPTION  "The management information definitions for the
                  View-based Access Control Model for SNMP.
                 "
    ::= { snmpModules 10 }    -- to be verified with IANA

-- Administrative assignments ****************************************

vacmMIBObjects      OBJECT IDENTIFIER ::= { snmpVacmMIB 1 }
vacmMIBConformance  OBJECT IDENTIFIER ::= { snmpVacmMIB 2 }

-- Information about Local Contexts **********************************

vacmContextTable OBJECT-TYPE
    SYNTAX       SEQUENCE OF VacmContextEntry
    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION "The table of locally available contexts.

                 This table provides information to SNMP Command
                 Generator applications so that they can properly
                 configure the vacmAccessTable to control access to
                 all contexts at the SNMP entity.

                 This table may change dynamically if the SNMP entity
                 allows that contexts are added/deleted dynamically
                 (for instance when its configuration changes). Such
                 changes would happen only if the management
                 instrumentation at that SNMP entity recognizes more
                 (or fewer) contexts.

                 The presence of entries in this table and of entries
                 in the vacmAccessTable are independent.  That is, a
                 context identified by an entry in this table does not
                 need to be referenced by any entries in the
                 vacmAccessTable; and the context(s) referenced by an
                 entry in the vacmAccessTable need not currently exist
                 and thus need not be identified by an entry in this
                 table.

                 This table must be made accessible via the default
                 context so that Command Responder applications have
                 a standard way of retrieving the information.

                 This table is read-only. It cannot be configured via
                 SNMP.
                "
    ::= { vacmMIBObjects 1 }

vacmContextEntry OBJECT-TYPE



Wijnen/Presuhn/McCloghrie     Expires February 1998           [Page 15]


Draft    View-based Access Control Model (VACM) for SNMP    August 1997


    SYNTAX       VacmContextEntry
    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION "Information about a particular context."
    INDEX       {
                  vacmContextName
                }
    ::= { vacmContextTable 1 }

VacmContextEntry ::= SEQUENCE
    {
        vacmContextName SnmpAdminString
    }

vacmContextName  OBJECT-TYPE
    SYNTAX       SnmpAdminString (SIZE(0..32))
    MAX-ACCESS   read-only
    STATUS       current
    DESCRIPTION "A human readable name identifying a particular
                 context at a particular SNMP entity.
                "
    ::= { vacmContextEntry 1 }

-- Information about Groups ******************************************

vacmSecurityToGroupTable OBJECT-TYPE
    SYNTAX       SEQUENCE OF VacmSecurityToGroupEntry
    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION "This table maps a combination of securityModel and
                 securityName into a groupName which is used to define
                 an access control policy for a group of principals.
                "
    ::= { vacmMIBObjects 2 }

vacmSecurityToGroupEntry OBJECT-TYPE
    SYNTAX       VacmSecurityToGroupEntry
    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION "An entry in this table maps the combination of a
                 securityModel and securityName into a groupName.
                "
    INDEX       {
                  vacmSecurityModel,
                  vacmSecurityName
                }
    ::= { vacmSecurityToGroupTable 1 }

VacmSecurityToGroupEntry ::= SEQUENCE
    {
        vacmSecurityModel               SnmpSecurityModel,



Wijnen/Presuhn/McCloghrie     Expires February 1998           [Page 16]


Draft    View-based Access Control Model (VACM) for SNMP    August 1997


        vacmSecurityName                SnmpAdminString,
        vacmGroupName                   SnmpAdminString,
        vacmSecurityToGroupStorageType  StorageType,
        vacmSecurityToGroupStatus       RowStatus
    }

vacmSecurityModel OBJECT-TYPE
    SYNTAX       SnmpSecurityModel(0..254 | 256..2147483647)
    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION "The Security Model, by which the vacmSecurityName
                 referenced by this entry is provided.

                 Note, this object may not take the 'any' (255) value.
                "
    ::= { vacmSecurityToGroupEntry 1 }

vacmSecurityName OBJECT-TYPE
    SYNTAX       SnmpAdminString (SIZE(1..32))
    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION "The securityName for the principal, represented in a
                 Security Model independent format, which is mapped by
                 this entry to a groupName.

                 The securityName for a principal represented in a
                 Security Model independent format.
                "
    ::= { vacmSecurityToGroupEntry 2 }

vacmGroupName    OBJECT-TYPE
    SYNTAX       SnmpAdminString (SIZE(1..32))
    MAX-ACCESS   read-create
    STATUS       current
    DESCRIPTION "The name of the group to which this entry (e.g. the
                 combination of securityModel and securityName)
                 belongs.

                 This groupName is used as index into the
                 vacmAccessTable to select an access control policy.
                "
    ::= { vacmSecurityToGroupEntry 3 }

vacmSecurityToGroupStorageType OBJECT-TYPE
    SYNTAX       StorageType
    MAX-ACCESS   read-create
    STATUS       current
    DESCRIPTION "The storage type for this conceptual row.

                 Conceptual rows having the value 'permanent' need not
                 allow write-access to any columnar objects in the row.



Wijnen/Presuhn/McCloghrie     Expires February 1998           [Page 17]


Draft    View-based Access Control Model (VACM) for SNMP    August 1997


                "
    DEFVAL      { nonVolatile }
    ::= { vacmSecurityToGroupEntry 4 }

vacmSecurityToGroupStatus OBJECT-TYPE
    SYNTAX       RowStatus
    MAX-ACCESS   read-create
    STATUS       current
    DESCRIPTION "The status of this conceptual row.

                 The  RowStatus TC [RFC1903] requires that this
                 DESCRIPTION clause states under which circumstances
                 other objects in this row can be modified:

                 The value of this object has no effect on whether
                 other objects in this conceptual row can be modified.
                "
    ::= { vacmSecurityToGroupEntry 5 }

-- Information about Access Rights ***********************************

vacmAccessTable  OBJECT-TYPE
    SYNTAX       SEQUENCE OF VacmAccessEntry
    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION "The table of access rights for groups.

                 Each entry is indexed by a contextPrefix, a groupName
                 a securityModel and a securityLevel.  To determine
                 whether access is allowed, one entry from this table
                 needs to be selected and the proper viewName from that
                 entry must be used for access control checking.

                 To select the proper entry, these matches must be made:

              1. The first match to make is for the groupName.
                 Here an exact match must be found.

              2. Second, a match must be found for the contextPrefix.
                 The procedure for this process depends on the value of
                 vacmAccessContextMatch:

                 a. exact
                    In this case, the vacmAccessContextPrefix
                    represents an exact contextName, and so the name
                    must match exactly.

                 b. prefix
                    In this case, the vacmAccessContextPrefix
                    represents a prefix of a contextName, so that (a
                    limited form of) wildcarding is possible.  The value
                    of vacmAccessContextPrefix must match with the first
                    part of the contextName to which access is
                    requested.

                    For example, if a vacmAccessContextPrefix value
                    of 'bridge' is used, then both contexts named
                    'bridge1' and 'bridge2' are accessible.

                 Multiple entries could match. In that case,
                 matching continues using the following procedure:

                 1. if only one entry has the longest value for
                    vacmAccessContextPrefix, then that entry wins.

                 2. otherwise, if only one entry has the value 'exact'
                    for the corresponding vacmAccessContextMatch, then
                    that entry wins.

                 3. otherwise, continue.  At the 4th match to make a
                    final winner will be found.

              3. The 3rd match to make is for the securityModel.
                 Here an exact match must be found. If no such exact
                 match exists, then an entry that has the 'any' (255)
                 value, (see definition of SnmpSecurityModel in
                 [SNMP-ARCH]) for the vacmAccessSecurityModel is
                 considered to match.

              4. The 4th match to make is for the securityLevel.  Here
                 the securityLevel at which access is requested must be
                 greater than or equal to the value of the
                 vacmAccessSecurityLevel. If multiple entries are still
                 considered to match, then the entry which has the
                 highest value for the corresponding
                 vacmAccessSecurityLevel wins.

                 Note that implementations are not required to make the
                 matches in the above order providing the same result
                 is achieved.
                "
    ::= { vacmMIBObjects 4 }

vacmAccessEntry  OBJECT-TYPE
    SYNTAX       VacmAccessEntry
    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION "An access right configured in the Local Configuration
                 Datastore (LCD) authorizing access to an SNMP context.
                "
    INDEX       { vacmGroupName,
                  vacmAccessContextPrefix,
                  vacmSecurityModel,
                  vacmAccessSecurityLevel
                }
    ::= { vacmAccessTable 1 }

VacmAccessEntry ::= SEQUENCE
    {
        vacmAccessContextPrefix    SnmpAdminString,
        vacmAccessSecurityLevel    SnmpSecurityLevel,
        vacmAccessContextMatch     INTEGER,
        vacmAccessReadViewName     SnmpAdminString,
        vacmAccessWriteViewName    SnmpAdminString,
        vacmAccessNotifyViewName   SnmpAdminString,
        vacmAccessStorageType      StorageType,
        vacmAccessStatus           RowStatus
    }

vacmAccessContextPrefix OBJECT-TYPE
    SYNTAX       SnmpAdminString (SIZE(0..32))
    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION "In order to gain the access rights allowed by this
                 conceptual row, a contextName must match exactly
                 (if the value of vacmAccessContextMatch is 'exact')
                 or partially (if the value of vacmAccessContextMatch
                 is 'prefix') to the value of the instance of this
                 object.
                "



Wijnen/Presuhn/McCloghrie     Expires February 1998           [Page 18]


Draft    View-based Access Control Model (VACM) for SNMP    August 1997


    ::= { vacmAccessEntry 1 }

vacmAccessSecurityLevel OBJECT-TYPE
    SYNTAX       SnmpSecurityLevel
    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION "The minimum level of security required in order to
                 gain the access rights allowed by this conceptual
                 row.  A securityLevel of noAuthNoPriv is less than
                 authNoPriv which in turn is less than authPriv.

                 If multiple entries are equally indexed except for
                 this vacmAccessSecurityLevel index, then the entry
                 which has the highest value for
                 vacmAccessSecurityLevel wins.
                "
    ::= { vacmAccessEntry 2 }

vacmAccessContextMatch OBJECT-TYPE
    SYNTAX       INTEGER
                { exact (1), -- exact match of prefix and contextName
                  prefix (2) -- Only match to the prefix
                }
    MAX-ACCESS   read-create
    STATUS       current
    DESCRIPTION "If the value of this object is exact(1), then all
                 rows where the contextName exactly matches
                 vacmAccessContextPrefix are selected.

                 If the value of this object is prefix(2), then all
                 rows where the contextName whose starting octets
                 exactly match vacmAccessContextPrefix are selected.
                 This allows for a simple form of wildcarding.
                 See also the example in the DESCRIPTION clause of
                 the vacmAccessTable above.
                "
    ::= { vacmAccessEntry 3 }

vacmAccessReadViewName OBJECT-TYPE
    SYNTAX       SnmpAdminString (SIZE(0..32))
    MAX-ACCESS   read-create
    STATUS       current
    DESCRIPTION "The value of an instance of this object identifies
                 the MIB view of the SNMP context to which this
                 conceptual row authorizes read access.

                 The identified MIB view is that one for which the
                 vacmViewTreeFamilyViewName has the same value as the
                 instance of this object; if the value is the empty
                 string or if there is no active MIB view having this
                 value of vacmViewTreeFamilyViewName, then no access



Wijnen/Presuhn/McCloghrie     Expires February 1998           [Page 19]


Draft    View-based Access Control Model (VACM) for SNMP    August 1997


                 is granted.
                "
    DEFVAL      { ''H }   -- the empty string
    ::= { vacmAccessEntry 4 }

vacmAccessWriteViewName OBJECT-TYPE
    SYNTAX       SnmpAdminString (SIZE(0..32))
    MAX-ACCESS   read-create
    STATUS       current
    DESCRIPTION "The value of an instance of this object identifies
                 the MIB view of the SNMP context to which this
                 conceptual row authorizes write access.

                 The identified MIB view is that one for which the
                 vacmViewTreeFamilyViewName has the same value as the
                 instance of this object; if the value is the empty
                 string or if there is no active MIB view having this
                 value of vacmViewTreeFamilyViewName, then no access
                 is granted.
                "
    DEFVAL      { ''H }   -- the empty string
    ::= { vacmAccessEntry 5 }

vacmAccessNotifyViewName OBJECT-TYPE
    SYNTAX       SnmpAdminString (SIZE(0..32))
    MAX-ACCESS   read-create
    STATUS       current
    DESCRIPTION "The value of an instance of this object identifies
                 the MIB view of the SNMP context to which this
                 conceptual row authorizes access for notifications.

                 The identified MIB view is that one for which the
                 vacmViewTreeFamilyViewName has the same value as the
                 instance of this object; if the value is the empty
                 string or if there is no active MIB view having this
                 value of vacmViewTreeFamilyViewName, then no access
                 is granted.
                "
    DEFVAL      { ''H }   -- the empty string
    ::= { vacmAccessEntry 6 }

vacmAccessStorageType OBJECT-TYPE
    SYNTAX       StorageType
    MAX-ACCESS   read-create
    STATUS       current
    DESCRIPTION "The storage type for this conceptual row.

                 Conceptual rows having the value 'permanent' need not
                 allow write-access to any columnar objects in the row.
                "
    DEFVAL      { nonVolatile }



Wijnen/Presuhn/McCloghrie     Expires February 1998           [Page 20]


Draft    View-based Access Control Model (VACM) for SNMP    August 1997


    ::= { vacmAccessEntry 7 }

vacmAccessStatus OBJECT-TYPE
    SYNTAX       RowStatus
    MAX-ACCESS   read-create
    STATUS       current
    DESCRIPTION "The status of this conceptual row.

                 The  RowStatus TC [RFC1903] requires that this
                 DESCRIPTION clause states under which circumstances
                 other objects in this row can be modified:

                 The value of this object has no effect on whether
                 other objects in this conceptual row can be modified.
                "
    ::= { vacmAccessEntry 8 }

-- Information about MIB views ***************************************

-- Support for views with wildcarding (e.g., for instance-level
-- granularity) is optional.

vacmMIBViews     OBJECT IDENTIFIER ::= { vacmMIBObjects 5 }

vacmViewSpinLock OBJECT-TYPE
    SYNTAX       TestAndIncr
    MAX-ACCESS   read-write
    STATUS       current
    DESCRIPTION "An advisory lock used to allow cooperating SNMP
                 Command Generator applications to coordinate their
                 use of the Set operation in creating view subtrees.

                 When creating a new view or altering an existing
                 view, it is important to understand the potential
                 interactions with other uses of the view.  The
                 vacmViewSpinLock should be retrieved.  The name of
                 the view to be created should be determined to be
                 unique by the SNMP Command Generator application by
                 consulting the vacmViewTreeFamilyTable.  Finally,
                 the named view may be created (Set), including the
                 advisory lock.
                 If another SNMP Command Generator application has
                 altered the views in the meantime, then the spin
                 lock's value will have changed, and so this creation
                 will fail because it will specify the wrong value for
                 the spin lock.

                 Since this is an advisory lock, the use of this lock
                 is not enforced.
                "
    ::= { vacmMIBViews 1 }



Wijnen/Presuhn/McCloghrie     Expires February 1998           [Page 21]


Draft    View-based Access Control Model (VACM) for SNMP    August 1997



vacmViewTreeFamilyTable OBJECT-TYPE
    SYNTAX       SEQUENCE OF VacmViewTreeFamilyEntry
    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION "Locally held information about families of subtrees
                 within MIB views.

                 Each MIB view is defined by two sets of view subtrees:
                   - the included view subtrees, and
                   - the excluded view subtrees.
                 Every such view subtree, both the included and the
                 excluded ones, is defined in this table.

                 To determine if a particular object instance is in
                 a particular MIB view, compare the object instance's
                 OBJECT IDENTIFIER with each of the MIB view's active
                 entries in this table.  If none match, then the
                 object instance is not in the MIB view.  If one or
                 more match, then the object instance is included in,
                 or excluded from, the MIB view according to the
                 value of vacmViewTreeFamilyType in the entry whose
                 value of vacmViewTreeFamilySubtree has the most
                 sub-identifiers.  If multiple entries match and have
                 the same number of sub-identifiers, then the
                 lexicographically greatest instance of
                 vacmViewTreeFamilyType determines the inclusion or
                 exclusion.

                 An object instance's OBJECT IDENTIFIER X matches an
                 active entry in this table when the number of
                 sub-identifiers in X is at least as many as in the
                 value of vacmViewTreeFamilySubtree for the entry,
                 and each sub-identifier in the value of
                 vacmViewTreeFamilySubtree matches its corresponding
                 sub-identifier in X.  Two sub-identifiers match
                 either if the corresponding bit of the value of
                 vacmViewTreeFamilyMask for the entry is zero (the
                 'wild card' value), or if they are equal.

                 A 'family' of subtrees is the set of subtrees defined
                 by a particular combination of values of
                 vacmViewTreeFamilySubtree and vacmViewTreeFamilyMask.
                 In the case where no 'wild card' is defined in the
                 vacmViewTreeFamilyMask, the family of subtrees reduces
                 to a single subtree.

                 When creating or changing MIB views, an SNMP Command
                 Generator application should utilize the
                 vacmViewSpinLock to try to avoid collisions. See
                 DESCRIPTION clause of vacmViewSpinLock.



Wijnen/Presuhn/McCloghrie     Expires February 1998           [Page 22]


Draft    View-based Access Control Model (VACM) for SNMP    August 1997



                 When creating MIB views, it is strongly advised that
                 first the 'excluded' vacmViewTreeFamilyEntries are
                 created and then the 'included' entries.

                 When deleting MIB views, it is strongly advised that
                 first the 'included' vacmViewTreeFamilyEntries are
                 deleted and then the 'excluded' entries.
                "
    ::= { vacmMIBViews 2 }

vacmViewTreeFamilyEntry OBJECT-TYPE
    SYNTAX       VacmViewTreeFamilyEntry
    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION "Information on a particular family of view subtrees
                 included in or excluded from a particular SNMP
                 context's MIB view.

                 Implementations must not restrict the number of
                 families of view subtrees for a given MIB view,
                 except as dictated by resource constraints on the
                 overall number of entries in the
                 vacmViewTreeFamilyTable.

                 A MIB view (viewName) for which there are no
                 conceptual rows in this table is the empty set of
                 view subtrees.
                "
    INDEX       { vacmViewTreeFamilyViewName,
                  vacmViewTreeFamilySubtree
                }
    ::= { vacmViewTreeFamilyTable 1 }

VacmViewTreeFamilyEntry ::= SEQUENCE
    {
        vacmViewTreeFamilyViewName     SnmpAdminString,
        vacmViewTreeFamilySubtree      OBJECT IDENTIFIER,
        vacmViewTreeFamilyMask         OCTET STRING,
        vacmViewTreeFamilyType         INTEGER,
        vacmViewTreeFamilyStorageType  StorageType,
        vacmViewTreeFamilyStatus       RowStatus
    }

vacmViewTreeFamilyViewName OBJECT-TYPE
    SYNTAX       SnmpAdminString (SIZE(1..32))
    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION "The human readable name for a family of view subtrees.
                "
    ::= { vacmViewTreeFamilyEntry 1 }



Wijnen/Presuhn/McCloghrie     Expires February 1998           [Page 23]


Draft    View-based Access Control Model (VACM) for SNMP    August 1997



vacmViewTreeFamilySubtree OBJECT-TYPE
    SYNTAX       OBJECT IDENTIFIER
    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION "The MIB subtree which when combined with the
                 corresponding instance of vacmViewTreeFamilyMask
                 defines a family of view subtrees.
                "
    ::= { vacmViewTreeFamilyEntry 2 }

vacmViewTreeFamilyMask OBJECT-TYPE
    SYNTAX       OCTET STRING (SIZE (0..16))
    MAX-ACCESS   read-create
    STATUS       current
    DESCRIPTION "The bit mask which, in combination with the
                 corresponding instance of vacmViewTreeFamilySubtree,
                 defines a family of view subtrees.

                 Each bit of this bit mask corresponds to a
                 sub-identifier of vacmViewTreeFamilySubtree, with the
                 most significant bit of the i-th octet of this octet
                 string value (extended if necessary, see below)
                 corresponding to the (8*i - 7)-th sub-identifier, and
                 the least significant bit of the i-th octet of this
                 octet string corresponding to the (8*i)-th
                 sub-identifier, where i is in the range 1 through 16.

                 Each bit of this bit mask specifies whether or not
                 the corresponding sub-identifiers must match when
                 determining if an OBJECT IDENTIFIER is in this
                 family of view subtrees; a '1' indicates that an
                 exact match must occur; a '0' indicates 'wild card',
                 i.e., any sub-identifier value matches.

                 Thus, the OBJECT IDENTIFIER X of an object instance
                 is contained in a family of view subtrees if, for
                 each sub-identifier of the value of
                 vacmViewTreeFamilySubtree, either:

                   the i-th bit of vacmViewTreeFamilyMask is 0, or

                   the i-th sub-identifier of X is equal to the i-th
                   sub-identifier of the value of
                   vacmViewTreeFamilySubtree.

                 If the value of this bit mask is M bits long and
                 there are more than M sub-identifiers in the
                 corresponding instance of vacmViewTreeFamilySubtree,
                 then the bit mask is extended with 1's to be the
                 required length.



Wijnen/Presuhn/McCloghrie     Expires February 1998           [Page 24]


Draft    View-based Access Control Model (VACM) for SNMP    August 1997



                 Note that when the value of this object is the
                 zero-length string, this extension rule results in
                 a mask of all-1's being used (i.e., no 'wild card'),
                 and the family of view subtrees is the one view
                 subtree uniquely identified by the corresponding
                 instance of vacmViewTreeFamilySubtree.

                 Note that masks of length greater than zero length
                 do not need to be supported.
                "
    DEFVAL      { ''H }
    ::= { vacmViewTreeFamilyEntry 3 }

vacmViewTreeFamilyType OBJECT-TYPE
    SYNTAX       INTEGER  { included(1), excluded(2) }
    MAX-ACCESS   read-create
    STATUS       current
    DESCRIPTION "Indicates whether the corresponding instances of
                 vacmViewTreeFamilySubtree and vacmViewTreeFamilyMask
                 define a family of view subtrees which is included in
                 or excluded from the MIB view.
                "
    DEFVAL      { included }
    ::= { vacmViewTreeFamilyEntry 4 }

vacmViewTreeFamilyStorageType OBJECT-TYPE
    SYNTAX       StorageType
    MAX-ACCESS   read-create
    STATUS       current
    DESCRIPTION "The storage type for this conceptual row.

                 Conceptual rows having the value 'permanent' need not
                 allow write-access to any columnar objects in the row.
                "
    DEFVAL      { nonVolatile }
    ::= { vacmViewTreeFamilyEntry 5 }

vacmViewTreeFamilyStatus OBJECT-TYPE
    SYNTAX       RowStatus
    MAX-ACCESS   read-create
    STATUS       current
    DESCRIPTION "The status of this conceptual row.

                 The  RowStatus TC [RFC1903] requires that this
                 DESCRIPTION clause states under which circumstances
                 other objects in this row can be modified:

                 The value of this object has no effect on whether
                 other objects in this conceptual row can be modified.
                "



Wijnen/Presuhn/McCloghrie     Expires February 1998           [Page 25]


Draft    View-based Access Control Model (VACM) for SNMP    August 1997


    ::= { vacmViewTreeFamilyEntry 6 }

-- Conformance information *******************************************

vacmMIBCompliances  OBJECT IDENTIFIER ::= { vacmMIBConformance 1 }
vacmMIBGroups       OBJECT IDENTIFIER ::= { vacmMIBConformance 2 }

-- Compliance statements *********************************************

vacmMIBCompliance MODULE-COMPLIANCE
    STATUS       current
    DESCRIPTION "The compliance statement for SNMP engines which
                 implement the SNMP View-based Access Control Model
                 configuration MIB.
                "
    MODULE -- this module
        MANDATORY-GROUPS { vacmBasicGroup }

        OBJECT        vacmAccessContextMatch
        MIN-ACCESS    read-only
        DESCRIPTION  "Write access is not required."

        OBJECT        vacmAccessReadViewName
        MIN-ACCESS    read-only
        DESCRIPTION  "Write access is not required."

        OBJECT        vacmAccessWriteViewName
        MIN-ACCESS    read-only
        DESCRIPTION  "Write access is not required."

        OBJECT        vacmAccessNotifyViewName
        MIN-ACCESS    read-only
        DESCRIPTION  "Write access is not required."

        OBJECT        vacmAccessStorageType
        MIN-ACCESS    read-only
        DESCRIPTION  "Write access is not required."

        OBJECT        vacmAccessStatus
        MIN-ACCESS    read-only
        DESCRIPTION  "Create access to the vacmAccessTable
                      is not required.
                     "

        OBJECT        vacmViewTreeFamilyMask
        WRITE-SYNTAX  OCTET STRING (SIZE (0))
        MIN-ACCESS    read-only
        DESCRIPTION  "Support for configuration via SNMP of subtree
                      families using wild-cards is not required.
                     "




Wijnen/Presuhn/McCloghrie     Expires February 1998           [Page 26]


Draft    View-based Access Control Model (VACM) for SNMP    August 1997


        OBJECT        vacmViewTreeFamilyType
        MIN-ACCESS    read-only
        DESCRIPTION  "Write access is not required."

        OBJECT        vacmViewTreeFamilyStorageType
        MIN-ACCESS    read-only
        DESCRIPTION  "Write access is not required."

        OBJECT        vacmViewTreeFamilyStatus
        MIN-ACCESS    read-only
        DESCRIPTION  "Create access to the vacmViewTreeFamilyTable
                      is not required.
                     "
    ::= { vacmMIBCompliances 1 }

-- Units of conformance **********************************************

vacmBasicGroup OBJECT-GROUP
    OBJECTS {
              vacmContextName,
              vacmGroupName,
              vacmSecurityToGroupStorageType,
              vacmSecurityToGroupStatus,
              vacmAccessContextMatch,
              vacmAccessReadViewName,
              vacmAccessWriteViewName,
              vacmAccessNotifyViewName,
              vacmAccessStorageType,
              vacmAccessStatus,
              vacmViewSpinLock,
              vacmViewTreeFamilyMask,
              vacmViewTreeFamilyType,
              vacmViewTreeFamilyStorageType,
              vacmViewTreeFamilyStatus
            }
    STATUS       current
    DESCRIPTION "A collection of objects providing for remote
                 configuration of an SNMP engine which implements
                 the SNMP View-based Access Control Model.
                "
    ::= { vacmMIBGroups 1 }

END











Wijnen/Presuhn/McCloghrie     Expires February 1998           [Page 27]


Draft    View-based Access Control Model (VACM) for SNMP    August 1997


5.  Security Considerations


5.1.  Recommended Practices

   This document is meant for use in the SNMP architecture.  The
   View-based Access Control Model described in this document checks
   access rights to management information based on:

   - contextName, representing a set of management information at the
     managed system where the Access Control module is running.
   - groupName, representing a set of zero or more securityNames.
     The combination of a securityModel and a securityName is mapped
     into a group in the View-based Access Control Model.
   - securityModel under which access is requested.
   - securityLevel under which access is requested.
   - operation performed on the management information.
   - MIB views for read, write or notify access.

   When the User-based Access Control module is called for checking
   access rights, it is assumed that the calling module has ensured
   the authentication and privacy aspects as specified by the
   securityLevel that is being passed.


5.2.  Defining Groups

   The groupNames are used to give access to a group of zero or more
   securityNames.  Within the View-Based Access Control Model, a
   groupName is considered to exist if that groupName is listed in the
   vacmSecurityToGroupTable.

   By mapping the combination of a securityModel and securityName into
   a groupName, an SNMP Command Generator application can add/delete
   securityNames to/from a group, if proper access is allowed.


5.3.  Conformance

   For an implementation of the View-based Access Control Model to be
   conformant, it MUST implement the SNMP-VIEW-BASED-ACM-MIB.  It also
   SHOULD [RFC2119] implement the initial configuration, described in
   appendix A.











Wijnen/Presuhn/McCloghrie     Expires February 1998           [Page 28]


Draft    View-based Access Control Model (VACM) for SNMP    August 1997


6.  Editors' Addresses

   Co-editor:  Bert Wijnen
               IBM T. J. Watson Research
   postal:     Schagen 33
               3461 GL Linschoten
               Netherlands
   email:      wijnen@vnet.ibm.com
   phone:      +31-348-432-794

   Co-editor:  Randy Presuhn
               BMC Software, Inc
   postal:     1190 Saratoga Avenue, Suite 130
               San Jose, CA  95129-3433
               USA
   email:      rpresuhn@bmc.com
   phone:      +1-408-556-0720

   Co-editor:  Keith McCloghrie
               Cisco Systems, Inc.
   postal:     170 West Tasman Drive
               San Jose, CA  95134-1706
               USA
   email:      kzm@cisco.com
   phone:      +1-408-526-5260





























Wijnen/Presuhn/McCloghrie     Expires February 1998           [Page 29]


Draft    View-based Access Control Model (VACM) for SNMP    August 1997


7.  Acknowledgements

This document is the result of the efforts of the SNMPv3 Working Group.
Some special thanks are in order to the following SNMPv3 WG members:

    Dave Battle (SNMP Research, Inc.)
    Uri Blumenthal (IBM T.J. Watson Research Center)
    Jeff Case (SNMP Research, Inc.)
    John Curran (BBN)
    T. Max Devlin (Hi-TECH Connections)
    John Flick (Hewlett Packard)
    David Harrington (Cabletron Systems Inc.)
    N.C. Hien (IBM T.J. Watson Research Center)
    Dave Levi (SNMP Research, Inc.)
    Louis A Mamakos (UUNET Technologies Inc.)
    Paul Meyer (Secure Computing Corporation)
    Keith McCloghrie (Cisco Systems)
    Russ Mundy (Trusted Information Systems, Inc.)
    Bob Natale (ACE*COMM Corporation)
    Mike O'Dell (UUNET Technologies Inc.)
    Dave Perkins (DeskTalk)
    Peter Polkinghorne (Brunel University)
    Randy Presuhn (BMC Software, Inc.)
    David Reid (SNMP Research, Inc.)
    Shawn Routhier (Epilogue)
    Juergen Schoenwaelder (TU Braunschweig)
    Bob Stewart (Cisco Systems)
    Bert Wijnen (IBM T.J. Watson Research Center)

The document is based on recommendations of the IETF Security and
Administrative Framework Evolution for SNMP Advisory Team.
Members of that Advisory Team were:

    David Harrington (Cabletron Systems Inc.)
    Jeff Johnson (Cisco Systems)
    David Levi (SNMP Research Inc.)
    John Linn (Openvision)
    Russ Mundy (Trusted Information Systems) chair
    Shawn Routhier (Epilogue)
    Glenn Waters (Nortel)
    Bert Wijnen (IBM T. J. Watson Research Center)

As recommended by the Advisory Team and the SNMPv3 Working Group
Charter, the design incorporates as much as practical from previous
RFCs and drafts. As a result, special thanks are due to the authors
of previous designs known as SNMPv2u and SNMPv2*:

    Jeff Case (SNMP Research, Inc.)
    David Harrington (Cabletron Systems Inc.)
    David Levi (SNMP Research, Inc.)
    Keith McCloghrie (Cisco Systems)



Wijnen/Presuhn/McCloghrie     Expires February 1998           [Page 30]


Draft    View-based Access Control Model (VACM) for SNMP    August 1997


    Brian O'Keefe (Hewlett Packard)
    Marshall T. Rose (Dover Beach Consulting)
    Jon Saperia (BGS Systems Inc.)
    Steve Waldbusser (International Network Services)
    Glenn W. Waters (Bell-Northern Research Ltd.)

















































Wijnen/Presuhn/McCloghrie     Expires February 1998           [Page 31]


Draft    View-based Access Control Model (VACM) for SNMP    August 1997


8.  References

[RFC1902] The SNMPv2 Working Group, Case, J., McCloghrie, K.,
     Rose, M., and S., Waldbusser, "Structure of Management
     Information for Version  2 of the Simple Network Management
     Protocol (SNMPv2)", RFC 1902, January 1996.

[RFC1905] The SNMPv2 Working Group, Case, J., McCloghrie, K.,
     Rose, M., and S., Waldbusser, "Protocol Operations for
     Version 2 of the Simple Network Management Protocol (SNMPv2)",
     RFC 1905, January 1996.

[RFC1906] The SNMPv2 Working Group, Case, J., McCloghrie, K.,
     Rose, M., and S. Waldbusser, "Transport Mappings for
     Version 2 of the Simple Network Management Protocol (SNMPv2)",
     RFC 1906, January 1996.

[RFC1907] The SNMPv2 Working Group, Case, J., McCloghrie, K.,
     Rose, M., and S. Waldbusser, "Management Information Base for
     Version 2 of the Simple Network Management Protocol (SNMPv2)",
     RFC 1907, January 1996.

[RFC1908] The SNMPv2 Working Group, Case, J., McCloghrie, K.,
     Rose, M., and S. Waldbusser, "Coexistence between Version 1
     and Version 2 of the Internet-standard Network Management
     Framework", RFC 1908, January 1996.

[RFC2119] Network Working Group, Bradner, S., "Key words for use in
     RFCs to Indicate Requirement Levels", RFC 2119, March 1997.

[SNMP-ARCH] The SNMPv3 Working Group, Harrington, D., Wijnen, B.,
     "An Architecture for describing SNMP Management Frameworks",
     draft-ietf-snmpv3-next-gen-arch-04.txt, August 1997.

[SNMP-MPD] The SNMPv3 Working Group, Case, J., Harrington, D.,
     Wijnen, B., "Message Processing and Dispatching for the Simple
     Network Management Protocol (SNMP)",
     draft-ietf-snmpv3-mpc-03.txt, August 1997

[SNMP-USM] The SNMPv3 Working Group, Blumenthal, U., Wijnen, B.,
     "The User-Based Security Model for Version 3 of the Simple
     Network Management Protocol (SNMPv3)",
     draft-ietf-snmpv3-usm-01.txt, August 1997.

[SNMP-ACM] The SNMPv3 Working Group, Wijnen, B., Presuhn, R.,
     McCloghrie, K., "View-based Access Control Model for the Simple
     Network Management Protocol (SNMP)",
     draft-ietf-snmpv3-acm-02.txt, August 1997.

[SNMP-APPL] The SNMPv3 Working Group, Levi, D. B., Meyer, P.,
     Stewart, B., "SNMPv3 Applications",



Wijnen/Presuhn/McCloghrie     Expires February 1998           [Page 32]


Draft    View-based Access Control Model (VACM) for SNMP    August 1997


     <draft-ietf-snmpv3-appl-01.txt>, August 1997

[ISO-ASN.1] Information processing systems - Open Systems
     Interconnection - Specification of Abstract Syntax Notation One
     (ASN.1), International Organization for Standardization.
     International Standard 8824, (December, 1987).
















































Wijnen/Presuhn/McCloghrie     Expires February 1998           [Page 33]


Draft    View-based Access Control Model (VACM) for SNMP    August 1997


APPENDIX A - Installation

A.1.  Installation Parameters

During installation, an authoritative SNMP engine SHOULD (in the
meaning as defined in [RFC2119]) be configured with several initial
parameters.  These include for the View-based Access Control Model:

1) A security configuration

   The choice of security configuration determines if initial
   configuration is implemented and if so how.
   One of three possible choices is selected:

     - initial-minimum-security-configuration
     - initial-semi-security-configuration
     - initial-no-access-configuration

   In the case of a initial-no-access-configuration, there is no
   initial configuration, and so the following steps are irrelevant.

2) A default context

   One entry in the vacmContextTable with a contextName of "" (the
   empty string), representing the default context.  Note that this
   table gets created automatically if a default context exists.

                                 no privacy support  privacy support
                                 ------------------  ---------------
    vacmContextName              ""                  ""

3) An initial group

   One entry in the vacmSecurityToGroupTable to allow access to group
   "initial".

                                 no privacy support  privacy support
                                 ------------------  ---------------
  vacmSecurityModel              3 (USM)             3 (USM)
  vacmSecurityName               "initial"           "initial"
  vacmGroupName                  "initial"           "initial"
  vacmSecurityToGroupStorageType anyValidStorageType anyValidStorageType
  vacmSecurityToGroupStatus      active              active

4) Initial access rights

   Three entries in the vacmAccessTable as follows:

   - read-notify access for securityModel USM, securityLevel
     "noAuthNoPriv" on behalf of securityNames that belong to the
     group "initial" to the <restricted> MIB view in the default



Wijnen/Presuhn/McCloghrie     Expires February 1998           [Page 34]


Draft    View-based Access Control Model (VACM) for SNMP    August 1997


     context with contextName "".

   - read-write-notify access for securityModel USM, securityLevel
     "authNoPriv" on behalf of securityNames that belong to the
     group "initial" to the <internet> MIB view in the default context
     with contextName "".

   - if privacy is supported,
     read-write-notify access for securityModel USM, securityLevel
     "authPriv" on behalf of securityNames that belong to the group
     "initial" to the <internet> MIB view in the default context with
     contextName "".

   That translates into the following entries in the vacmAccessTable.
   Those columns marked with (index) are index-only objects and are
   not really present in this table.

   - One entry to be used for unauthenticated access (noAuthNoPriv):

                               no privacy support  privacy support
                               ------------------  ---------------
    vacmAccessContextPrefix    ""                  ""
    vacmGroupName     (index)  "initial"           "initial"
    vacmSecurityModel (index)  3 (USM)             3 (USM)
    vacmAccessSecurityLevel    noAuthNoPriv        noAuthNoPriv
    vacmAccessReadViewName     "restricted"        "restricted"
    vacmAccessWriteViewName    ""                  ""
    vacmAccessNotifyViewName   "restricted"        "restricted"
    vacmAccessStorageType      anyValidStorageType anyValidStorageType
    vacmAccessStatus           active              active

   - One entry to be used for authenticated access but without
     privacy (authNoPriv):
                               no privacy support  privacy support
                               ------------------  ---------------
    vacmAccessContextPrefix    ""                  ""
    vacmGroupName     (index)  "initial"           "initial"
    vacmSecurityModel (index)  3 (USM)             3 (USM)
    vacmAccessSecurityLevel    authNoPriv          authNoPriv
    vacmAccessReadViewName     "internet"          "internet"
    vacmAccessWriteViewName    "internet"          "internet"
    vacmAccessNotifyViewName   "internet"          "internet"
    vacmAccessStorageType      anyValidStorageType anyValidStorageType
    vacmAccessStatus           active              active

   - One entry to be used for authenticated access with privacy
     (authPriv):

                               no privacy support  privacy support
                               ------------------  ---------------
    vacmAccessContextPrefix                        ""



Wijnen/Presuhn/McCloghrie     Expires February 1998           [Page 35]


Draft    View-based Access Control Model (VACM) for SNMP    August 1997


    vacmGroupName     (index)                      "initial"
    vacmSecurityModel (index)                      3 (USM)
    vacmAccessSecurityLevel                        authPriv
    vacmAccessReadViewName                         "internet"
    vacmAccessWriteViewName                        "internet"
    vacmAccessNotifyViewName                       "internet"
    vacmAccessStorageType                          anyValidStorageType
    vacmAccessStatus                               active

5) Two MIB views, of which the second one depends on the security
   configuration.

   -  One view, the <internet> view, for authenticated access:

      -  the <internet> MIB view is the following subtree:
             "internet"  (subtree 1.3.6.1)

   -  A second view, the <restricted> view, for unauthenticated
      access.  This view is configured according to the selected
      security configuration:

      -  For the initial-no-access-configuration there is no default
         initial configuration, so no MIB views are pre-scribed.

      -  For the initial-semi-secure-configuration:

         the <restricted> MIB view is the union of these subtrees:
         (a) "system"       (subtree 1.3.6.1.2.1.1)     [RFC1907]
         (b) "snmp"         (subtree 1.3.6.1.2.1.11)    [RFC1907]
         (c) "snmpEngine"   (subtree 1.3.6.1.6.3.7.2.1) [SNMP-ARCH]
         (d) "snmpMPDStats" (subtree 1.3.6.1.6.3.8.2.1) [SNMP-MPD]
         (e) "usmStats"     (subtree 1.3.6.1.6.3.9.2.1) [SNMP-USM]

      -  For the initial-minimum-secure-configuration:

         the <restricted> MIB view is the following subtree.
             "internet"  (subtree 1.3.6.1)

   This translates into the following "internet" entry in the
   vacmViewTreeFamilyTable:

                                minimum-secure      semi-secure
                                ----------------    ---------------
  vacmViewTreeFamilyViewName    "internet"          "internet"
  vacmViewTreeFamilySubtree     1.3.6.1             1.3.6.1
  vacmViewTreeFamilyMask        ""                  ""
  vacmViewTreeFamilyType        1 (included)        1 (included)
  vacmViewTreeFamilyStorageType anyValidStorageType anyValidStorageType
  vacmViewTreeFamilyStatus      active              active

   In addition it translates into the following "restricted" entries



Wijnen/Presuhn/McCloghrie     Expires February 1998           [Page 36]


Draft    View-based Access Control Model (VACM) for SNMP    August 1997


   in the vacmViewTreeFamilyTable:

                                minimum-secure      semi-secure
                                ----------------    ---------------
  vacmViewTreeFamilyViewName    "restricted"        "restricted"
  vacmViewTreeFamilySubtree     1.3.6.1             1.3.6.1.2.1.1
  vacmViewTreeFamilyMask        ""                  ""
  vacmViewTreeFamilyType        1 (included)        1 (included)
  vacmViewTreeFamilyStorageType anyValidStorageType anyValidStorageType
  vacmViewTreeFamilyStatus      active              active

  vacmViewTreeFamilyViewName                        "restricted"
  vacmViewTreeFamilySubtree                         1.3.6.1.2.1.11
  vacmViewTreeFamilyMask                            ""
  vacmViewTreeFamilyType                            1 (included)
  vacmViewTreeFamilyStorageType                     anyValidStorageType
  vacmViewTreeFamilyStatus                          active

  vacmViewTreeFamilyViewName                        "restricted"
  vacmViewTreeFamilySubtree                         1.3.6.1.6.3.7.2.1
  vacmViewTreeFamilyMask                            ""
  vacmViewTreeFamilyType                            1 (included)
  vacmViewTreeFamilyStorageType                     anyValidStorageType
  vacmViewTreeFamilyStatus                          active

  vacmViewTreeFamilyViewName                        "restricted"
  vacmViewTreeFamilySubtree                         1.3.6.1.6.3.8.2.1
  vacmViewTreeFamilyMask                            ""
  vacmViewTreeFamilyType                            1 (included)
  vacmViewTreeFamilyStorageType                     anyValidStorageType
  vacmViewTreeFamilyStatus                          active

  vacmViewTreeFamilyViewName                        "restricted"
  vacmViewTreeFamilySubtree                         1.3.6.1.6.3.9.2.1
  vacmViewTreeFamilyMask                            ""
  vacmViewTreeFamilyType                            1 (included)
  vacmViewTreeFamilyStorageType                     anyValidStorageType
  vacmViewTreeFamilyStatus                          active
















Wijnen/Presuhn/McCloghrie     Expires February 1998           [Page 37]


Draft    View-based Access Control Model (VACM) for SNMP    August 1997


Table of Contents

0.  Issues and Change Log                                             2
0.1.  Resolved issues                                                 2
0.2.  Change Log                                                      2
1.  Introduction                                                      5
1.2.  Access Control                                                  5
1.3.  Local Configuration Datastore                                   6
2.  Elements of the Model                                             7
2.1.  Groups                                                          7
2.2.  securityLevel                                                   7
2.3.  Contexts                                                        7
2.4.  MIB Views and View Families                                     8
2.4.1.  View Subtree                                                  8
2.4.2.  ViewTreeFamily                                                8
2.5.  Access Policy                                                   9
3.  Elements of Procedure                                            10
3.1.  Overview  of isAccessAllowed Process                           11
3.2.  Processing the isAccessAllowed Service Request                 12
4.  Definitions                                                      14
5.  Security Considerations                                          28
5.1.  Recommended Practices                                          28
5.2.  Defining Groups                                                28
5.3.  Conformance                                                    28
6.  Editors' Addresses                                               29
7.  Acknowledgements                                                 30
8.  References                                                       32
A.1.  Installation Parameters                                        34




























Wijnen/Presuhn/McCloghrie     Expires February 1998           [Page 38]