[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 RFC 2265

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

                            14 July 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-01.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 (ACM) for
use in the SNMP architecture [SNMP-ARCH].  It defines the Elements of
Procedure for applying access control to management information.
This document also includes a MIB for remotely managing the
configuration parameters for this ACM.







Wijnen/Presuhn/McCloghrie      Expires December 1997           [Page  1]
^L
Draft      View-based Access Control Model (ACM) for SNMP      July 1997


0.  Issues and Change Log

0.1.  Issues
  - acknowledgements needs expansion
  - 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?
  - reference section must be checked; sync up with other documents
  - 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.

0.2.  Change Log

[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



Wijnen/Presuhn/McCloghrie      Expires December 1997           [Page  2]

Draft      View-based Access Control Model (ACM) for SNMP      July 1997


  - 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 doc (June 12 version).
  - Modifications as agreed at 1st Interim Meeting
    - 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 December 1997           [Page  3]
^L
Draft      View-based Access Control Model (ACM) for SNMP      July 1997


1.  Introduction

   The Architecture for describing Internet Management Frameworks
   [SNMP-ARCH] is composed of multiple subsystems:

     1) a Message Processing Subsystem,
     2) a Security Subsystem,
     3) 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 provides services
   to determine whether access to an object instance is permitted.

   An Access Control Model has the responsibility for checking if
   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 another 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 December 1997           [Page  4]

Draft      View-based Access Control Model (ACM) for SNMP      July 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 December 1997           [Page  5]
^L
Draft      View-based Access Control Model (ACM) for SNMP      July 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.  groupName

   A groupName identifies a group (set) of zero or more securityNames
   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.

   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.  Level of Security (LoS)

   Different access rights for members of a group can be defined for
   different Levels of Security.  The LoS 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 LoS.

   The View-based Access Control Model requires the LoS to be 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 an acmContextTable that
   lists the locally available contexts by contextName.







Wijnen/Presuhn/McCloghrie      Expires December 1997           [Page  6]
^L
Draft      View-based Access Control Model (ACM) for SNMP      July 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, by providing access rights to a group in
   terms of the particular (subset) MIB view it can access for that
   context, then the group is restricted in the desired manner.

   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
   (called the family name) together with a bit string value (called



Wijnen/Presuhn/McCloghrie      Expires December 1997           [Page  7]

Draft      View-based Access Control Model (ACM) for SNMP      July 1997


   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, one or more securityNames which have
   the same access rights).  For a particular context (contextName) to
   which a group (groupName) has access using a particular Security
   Model (securityModel) and Level of Security (LoS), 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.  This occurs
   when sending a notification (for example an Inform or SNMPv2-Trap).





Wijnen/Presuhn/McCloghrie      Expires December 1997           [Page  8]
^L
Draft      View-based Access Control Model (ACM) for SNMP      July 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 interface primitive is:

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

   Where:

     statusInformation
       one of the following:

          accessAllowed  - success (and access is granted).
                           a MIB view was found and access is granted.
          notInView      - success (but access is denied).
                           a MIB view was found but access is denied
                           because the variableName is not in the
                           configured MIB view for the specified
                           viewType (e.g. in the relevant entry in the
                           acmAccessTable).
          noSuchView     - failure, no MIB view found because no view
                           configured for specified viewType (e.g. in
                           the relevant entry in the acmAccessTable).
          noSuchContext  - failure, no MIB view found because no entry
                           in the acmContextTable for the specified
                           contextName.
          noGroupName    - failure, no MIB view found because no entry
                           configured in the acmSecurityToGroupTable
                           for the specified combination of
                           securityModel and securityName.
          noAccessEntry  - failure, no MIB view found because no entry
                           configured in the acmAccessTable for the
                           specified combination of contextName,
                           groupName (as found in the
                           acmSecurityToGroupTable based on
                           securityModel and securityName),
                           securityModel and LoS.
          otherError     - failure, an undefined error occurred.




Wijnen/Presuhn/McCloghrie      Expires December 1997           [Page  9]

Draft      View-based Access Control Model (ACM) for SNMP      July 1997


     securityModel
       Security Model under which access is requested.
     securityName
       representing the principal on whose behalf access is requested.
     LoS
       Level of Security under which access is requested.
     viewType
       view to be checked (read, write or notify).
     contextName
       context in which access to variableName is requested.
     variableName
       variable (object instance) to which access is requested.


3.1  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 LCD (acmContextTable) is consulted for information about
      the SNMP context identified by the contextName.  If information
      about this SNMP context is absent from the LCD, then an
      errorIndication (noSuchContext) is returned to the calling
      module.

   2) The LCD (acmSecurityToGroupTable) is consulted for mapping the
      Security Model (securityModel) and principal (securityName) to a
      group (groupName).  If that information about this combination is
      absent from the LCD, then an errorIndication (noGroupName)
      is returned to the calling module.

   3) The LCD (acmAccessTable) is consulted for information about the
      contextName, groupName, securityModel and LoS.  If information
      about this combination is absent from the LCD, 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.

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




Wijnen/Presuhn/McCloghrie      Expires December 1997           [Page 10]


Draft      View-based Access Control Model (ACM) for SNMP      July 1997


      b) If the specified variableName (object instance) is not in the
         MIB view (see DESCRIPTION clause for acmViewTreeFamilyTable 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 December 1997           [Page 11]


^L
Draft      View-based Access Control Model (ACM) for SNMP      July 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,
    SnmpLoS,
    SnmpSecurityModel                     FROM SNMP-FRAMEWORK-MIB;

snmpAcmMIB      MODULE-IDENTITY
    LAST-UPDATED "9707140000Z"            -- 14 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 December 1997           [Page 12]


Draft      View-based Access Control Model (ACM) for SNMP      July 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 ****************************************

acmMIBObjects      OBJECT IDENTIFIER ::= { snmpAcmMIB 1 }
acmMIBConformance  OBJECT IDENTIFIER ::= { snmpAcmMIB 2 }

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

acmContextTable  OBJECT-TYPE
    SYNTAX       SEQUENCE OF AcmContextEntry
    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION "The table of locally available contexts. If a context
                 is listed in this table that does not mean that
                 access to this context has been defined in the
                 acmAccessTable. It just means that the context exists
                 and that MIB objects may exist in this context.

                 This table must be made accessible via the default
                 context.

                 This table is read-only meaning that it cannot be
                 configured via SNMP.

                 This table is provides information to SNMP Command
                 Generator applications so they can properly configure
                 the acmAccessTable to control access to all contexts
                 at the SNMP entity that provides access to the
                 information in these contexts.
                "
    ::= { acmMIBObjects 1 }

acmContextEntry  OBJECT-TYPE
    SYNTAX       AcmContextEntry
    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION "Information about a particular context."
    INDEX       {
                  acmContextName
                }
    ::= { acmContextTable 1 }

AcmContextEntry ::= SEQUENCE
    {



Wijnen/Presuhn/McCloghrie      Expires December 1997           [Page 13]


Draft      View-based Access Control Model (ACM) for SNMP      July 1997


        acmContextName SnmpAdminString
    }

acmContextName   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.
                "
    ::= { acmContextEntry 1 }

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

acmSecurityToGroupTable    OBJECT-TYPE
    SYNTAX       SEQUENCE OF AcmSecurityToGroupEntry
    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION "The table that maps a combination of securityModel
                 and securityName into a groupName which defines an
                 access control policy for a group of principals.
                "
    ::= { acmMIBObjects 2 }

acmSecurityToGroupEntry OBJECT-TYPE
    SYNTAX       AcmSecurityToGroupEntry
    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION "An entry in this table maps the combination of a
                 securityModel and securityName into a groupName.
                "
    INDEX       {
                  acmSecurityModel,
                  acmSecurityName
                }
    ::= { acmSecurityToGroupTable 1 }

AcmSecurityToGroupEntry ::= SEQUENCE
    {
        acmSecurityModel               SnmpSecurityModel,
        acmSecurityName                SnmpAdminString,
        acmGroupName                   SnmpAdminString,
        acmSecurityToGroupStorageType  StorageType,
        acmSecurityToGroupStatus       RowStatus
    }

acmSecurityModel OBJECT-TYPE
    SYNTAX       SnmpSecurityModel
    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION "The Security Model, which is the first index in this



Wijnen/Presuhn/McCloghrie      Expires December 1997           [Page 14]


Draft      View-based Access Control Model (ACM) for SNMP      July 1997


                 table.
                "
    ::= { acmSecurityToGroupEntry 1 }

acmSecurityName  OBJECT-TYPE
    SYNTAX       SnmpAdminString
    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION "The securityName for a principal represented in a
                 Security Model independent format.
                 Used as a second index in this table.
                "
    ::= { acmSecurityToGroupEntry 2 }

acmGroupName     OBJECT-TYPE
    SYNTAX       SnmpAdminString
    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 represents an access control policy
                 and is used as an index in the acmAccessTable.
                "
    ::= { acmSecurityToGroupEntry 3 }

acmSecurityToGroupStorageType 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 }
    ::= { acmSecurityToGroupEntry 4 }

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

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

-- Reverse mapping from groupName into securityName(s) ***************



Wijnen/Presuhn/McCloghrie      Expires December 1997           [Page 15]


Draft      View-based Access Control Model (ACM) for SNMP      July 1997



acmGroupListTable OBJECT-TYPE
    SYNTAX       SEQUENCE OF AcmGroupListEntry
    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION "The acmGroupListTable complements the
                 acmSecurityToGroupTable by providing an efficient
                 means to determine the membership of a given group.
                "
    ::= { acmMIBObjects 3 }

acmGroupListEntry OBJECT-TYPE
    SYNTAX       AcmGroupListEntry
    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION "An entry in this table corresponds to an entry in the
                 acmSecurityToGroupTable, using acmGroupName as its
                 primary key.
                "
    INDEX       {
                  acmGroupName,
                  acmSecurityModel,
                  acmSecurityName
                }
    ::= { acmGroupListTable 1 }

AcmGroupListEntry ::= SEQUENCE
    {
        acmGroupListStatus    RowStatus
    }

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

                 The value is identical to that of the corresponding
                 acmSecurityToGroupEntry's acmSecurityToGroupStatus.
                "
    ::= { acmGroupListEntry 1 }

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

acmAccessTable   OBJECT-TYPE
    SYNTAX       SEQUENCE OF AcmAccessEntry
    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION "The table of group access rights configured in the
                 Local Configuration Datastore (LCD).




Wijnen/Presuhn/McCloghrie      Expires December 1997           [Page 16]


Draft      View-based Access Control Model (ACM) for SNMP      July 1997


                 Each entry is indexed by a contextPrefix, a groupName
                 a securityModel and a Level of Security (LoS).  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, first a match must be
                 found for the contextPrefix.  The procedure for this
                 process depends on the value of acmAccessContextMatch:

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

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

                   For example, if an acmAccessContextPrefix value of
                   'repeater' is used, then both contexts named
                   'repeater1' and 'repeater2' are accessible.

                 Multiple entries could match. In that case:

                 - The entry which has the longest value for
                   acmAccessContextPrefix wins.

                   Otherwise, if still no single winner (e.g. multiple
                   entries have the same acmAccessContextPrefix value,

                 - The entry which has the value 'exact' for the
                   corresponding acmAccessContextMatch, wins.

                   Otherwise, if still no single winner (e.g. multiple
                   entries have a acmAccessContextMatch value 'exact',

                 - Then continue.  At the 4th match to make a final
                   winner will be found if there are still multiple
                   entries.

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

                 The 3rd match to make is for the securityModel.
                 Here an exact match must be found. If no such exact



Wijnen/Presuhn/McCloghrie      Expires December 1997           [Page 17]


Draft      View-based Access Control Model (ACM) for SNMP      July 1997


                 match exists, then an entry that has the 'all' value
                 (see definition of SnmpSecurityModel in [SNMP-ARCH])
                 for the acmAccessSecurityModel is considered to match.

                 The 4th match to make is for the LoS.  Here the LoS
                 at which access is requested must be greater than or
                 equal to the value of the acmAccessLoS.
                 If multiple entries are still considered to match,
                 then the entry which has the lowest value for the
                 corresponding acmAccessLoS wins.
                "
    ::= { acmMIBObjects 4 }

acmAccessEntry   OBJECT-TYPE
    SYNTAX       AcmAccessEntry
    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION "An access right configured in the Local Configuration
                 Datastore (LCD) authorizing access to an SNMP context.
                "
    INDEX       { acmAccessContextPrefix,
                  acmGroupName,
                  acmSecurityModel,
                  acmAccessLoS
                }
    ::= { acmAccessTable 1 }

AcmAccessEntry ::= SEQUENCE
    {
        acmAccessContextPrefix    SnmpAdminString,
        acmAccessLoS              SnmpLoS,
        acmAccessContextMatch     INTEGER,
        acmAccessReadViewName     SnmpAdminString,
        acmAccessWriteViewName    SnmpAdminString,
        acmAccessNotifyViewName   SnmpAdminString,
        acmAccessStorageType      StorageType,
        acmAccessStatus           RowStatus
    }

acmAccessContextPrefix OBJECT-TYPE
    SYNTAX       SnmpAdminString
    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 acmAccessContextMatch is 'exact')
                 or partially (if the value of acmAccessContextMatch
                 is 'prefix') to the value of the instance of this
                 object.
                "
    ::= { acmAccessEntry 1 }



Wijnen/Presuhn/McCloghrie      Expires December 1997           [Page 18]


Draft      View-based Access Control Model (ACM) for SNMP      July 1997



acmAccessLoS     OBJECT-TYPE
    SYNTAX       SnmpLoS
    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.  An LoS of noAuthNoPriv is lower than authNoPriv
                 which in turn is lower than authPriv.

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

acmAccessContextMatch 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 exact is set, then the value of the index part
                 acmAccessContextPrefix of this entry in this table
                 represents a full contextName.

                 If prefix is set, then the value of the index part
                 acmAccessContextPrefix of this entry in this
                 table represents a partial contextName which acts
                 as a prefix so that a simple form of wildcarding
                 is possible.
                "
    ::= { acmAccessEntry 3 }

acmAccessReadViewName OBJECT-TYPE
    SYNTAX       SnmpAdminString
    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
                 acmViewTreeFamilyViewName 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 acmViewTreeFamilyViewName, then no access is
                 granted.
                "
    DEFVAL      { ''H }   -- the empty string



Wijnen/Presuhn/McCloghrie      Expires December 1997           [Page 19]


Draft      View-based Access Control Model (ACM) for SNMP      July 1997


    ::= { acmAccessEntry 4 }

acmAccessWriteViewName OBJECT-TYPE
    SYNTAX       SnmpAdminString
    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
                 acmViewTreeFamilyViewName 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 acmViewTreeFamilyViewName, then no access is
                 granted.
                "
    DEFVAL      { ''H }   -- the empty string
    ::= { acmAccessEntry 5 }

acmAccessNotifyViewName OBJECT-TYPE
    SYNTAX       SnmpAdminString
    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
                 acmViewTreeFamilyViewName 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 acmViewTreeFamilyViewName, then no access is
                 granted.
                "
    DEFVAL      { ''H }   -- the empty string
    ::= { acmAccessEntry 6 }

acmAccessStorageType 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 }
    ::= { acmAccessEntry 7 }

acmAccessStatus  OBJECT-TYPE



Wijnen/Presuhn/McCloghrie      Expires December 1997           [Page 20]


Draft      View-based Access Control Model (ACM) for SNMP      July 1997


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

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

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

-- Support for views having instance-level granularity is optional

acmMIBViews      OBJECT IDENTIFIER ::= { acmMIBObjects 5 }

acmViewSpinLock  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
                 acmViewSpinLock 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 acmViewTreeFamilyTable.  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.
                "
    ::= { acmMIBViews 1 }

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




Wijnen/Presuhn/McCloghrie      Expires December 1997           [Page 21]


Draft      View-based Access Control Model (ACM) for SNMP      July 1997


                 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 included and excluded,
                 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 acmViewTreeFamilyType in the entry whose
                 value of acmViewTreeFamilySubtree has the most
                 sub-identifiers.  If multiple entries match and have
                 the same number of sub-identifiers, then the
                 lexicographically greatest instance of
                 acmViewTreeFamilyType 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 acmViewTreeFamilySubtree for the entry, and
                 each sub-identifier in the value of
                 acmViewTreeFamilySubtree matches its corresponding
                 sub-identifier in X.  Two sub-identifiers match
                 either if the corresponding bit of the value of
                 acmViewTreeFamilyMask 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
                 acmViewTreeFamilySubtree and acmViewTreeFamilyMask.
                 In the case where no 'wild card' is defined in the
                 acmViewTreeFamilyMask, the family of subtrees reduces
                 to a single subtree.

                 When an SNMP Command Generator application wants to
                 create a new MIB view, then it should first obtain
                 the value of the advisory spin lock and a list of
                 existing named views.  It then selects a new
                 non-existing index-value (viewName) for
                 acmViewTreeFamilyViewName.  The SNMP Command Generator
                 application can then start creating entries in the
                 acmViewTreeFamilyTable.  It should include the
                 advisory lock in the Set Operation to ensure that an
                 other such application has not in the meanwhile
                 created new entries with a new (possibly colliding)
                 viewName in this table.



Wijnen/Presuhn/McCloghrie      Expires December 1997           [Page 22]


Draft      View-based Access Control Model (ACM) for SNMP      July 1997



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

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

acmViewTreeFamilyEntry OBJECT-TYPE
    SYNTAX       AcmViewTreeFamilyEntry
    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
                 acmViewTreeFamilyTable.

                 The value of acmViewTreeFamilyViewName in the INDEX
                 clause of this table identifies the MIB view in which
                 this subtree family exists.

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

AcmViewTreeFamilyEntry ::= SEQUENCE
    {
        acmViewTreeFamilyViewName     SnmpAdminString,
        acmViewTreeFamilySubtree      OBJECT IDENTIFIER,
        acmViewTreeFamilyMask         OCTET STRING,
        acmViewTreeFamilyType         INTEGER,
        acmViewTreeFamilyStorageType  StorageType,
        acmViewTreeFamilyStatus       RowStatus
    }

acmViewTreeFamilyViewName OBJECT-TYPE
    SYNTAX       SnmpAdminString
    MAX-ACCESS   not-accessible



Wijnen/Presuhn/McCloghrie      Expires December 1997           [Page 23]


Draft      View-based Access Control Model (ACM) for SNMP      July 1997


    STATUS       current
    DESCRIPTION "The human readable name for a family of view subtrees.
                "
    ::= { acmViewTreeFamilyEntry 1 }

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

acmViewTreeFamilyMask 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 acmViewTreeFamilySubtree,
                 defines a family of view subtrees.

                 Each bit of this bit mask corresponds to a
                 sub-identifier of acmViewTreeFamilySubtree, 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
                 acmViewTreeFamilySubtree, either:

                   the i-th bit of acmViewTreeFamilyMask is 0, or

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

                 If the value of this bit mask is M bits long and



Wijnen/Presuhn/McCloghrie      Expires December 1997           [Page 24]


Draft      View-based Access Control Model (ACM) for SNMP      July 1997


                 there are more than M sub-identifiers in the
                 corresponding instance of acmViewTreeFamilySubtree,
                 then the bit mask is extended with 1's to be the
                 required length.

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

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

acmViewTreeFamilyStorageType 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 }
    ::= { acmViewTreeFamilyEntry 5 }

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

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

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



Wijnen/Presuhn/McCloghrie      Expires December 1997           [Page 25]


Draft      View-based Access Control Model (ACM) for SNMP      July 1997



acmMIBCompliances  OBJECT IDENTIFIER ::= { acmMIBConformance 1 }
acmMIBGroups       OBJECT IDENTIFIER ::= { acmMIBConformance 2 }

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

acmMIBCompliance 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 { acmBasicGroup }

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

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

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

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

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

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

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

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



Wijnen/Presuhn/McCloghrie      Expires December 1997           [Page 26]


Draft      View-based Access Control Model (ACM) for SNMP      July 1997



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

        OBJECT        acmViewTreeFamilyStatus
        MIN-ACCESS    read-only
        DESCRIPTION  "Create access to the acmViewTreeFamilyTable
                      is not required.
                     "
    ::= { acmMIBCompliances 1 }

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

acmBasicGroup OBJECT-GROUP
    OBJECTS {
              acmContextName,
              acmGroupName,
              acmSecurityToGroupStorageType,
              acmSecurityToGroupStatus,
              acmGroupListStatus,
              acmAccessContextMatch,
              acmAccessReadViewName,
              acmAccessWriteViewName,
              acmAccessNotifyViewName,
              acmAccessStorageType,
              acmAccessStatus,
              acmViewSpinLock,
              acmViewTreeFamilyMask,
              acmViewTreeFamilyType,
              acmViewTreeFamilyStorageType,
              acmViewTreeFamilyStatus
            }
    STATUS       current
    DESCRIPTION "A collection of objects providing for remote
                 configuration of an SNMP engine which implements
                 the SNMP View-based Access Control Model (ACM).
                "
    ::= { acmMIBGroups 1 }

END













Wijnen/Presuhn/McCloghrie      Expires December 1997           [Page 27]


^L
Draft      View-based Access Control Model (ACM) for SNMP      July 1997


5.  Security Considerations


5.1.  Recommended Practices

   This document is meant for use in the SNMP architecture.  The
   View-based Access Control Model (ACM) 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 group or set of zero, one or more
     securityNames.  The combination of a securityModel and a
     securityName is mapped into a group in the View-based Access
     Control Model.
   - securityModel used for the transmission of an SNMP message.
   - Level of Security (LoS) used for the transmission of an SNMP
     message.
   - operation performed on the management information.
   - MIB views for read, write or notify access.

   When the User-based Access Control module (ACM) is called for
   checking access rights, it is assumed that the calling module has
   ensured the authentication and privacy aspects as specified by the
   Level of Security (LoS) that is being passed.


5.2.  Defining Groups

   The groupNames are used to give access to a group of zero, one or
   more securityNames.  Within the ACM, a groupName is considered to
   exist if that groupName is listed in the acmSecurityToGroupTable.
   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, that is 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 December 1997           [Page 28]


^L
Draft      View-based Access Control Model (ACM) for SNMP      July 1997


6.  Editor's 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


7.  Acknowledgements

This document describes the work of the SNMP Security and
Administrative Framework Evolution team, comprised of

    David Harrington (Cabletron Systems Inc.)
    Jeff Johnson (Cisco)
    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)














Wijnen/Presuhn/McCloghrie      Expires December 1997           [Page 29]


^L
Draft      View-based Access Control Model (ACM) for SNMP      July 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 1905, 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 Internet Management Frameworks",
     draft-ietf-snmpv3-next-gen-arch-02.txt, June 1997.

[SNMPv3-MPC] The SNMPv3 Working Group, Wijnen, B., Harrington, D.,
     "Message Processing and Control Model for version 3 of the Simple
     Network Management Protocol (SNMPv3)",
     draft-ietf-snmpv3-mpc-00.txt, July 1997.

[SNMPv3-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-00.txt, July 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 December 1997           [Page 30]


^L
Draft      View-based Access Control Model (ACM) for SNMP      July 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 posture

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

         minimum-secure,
         semi-secure,
         very-secure (i.e. no-initial-configuration)

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

2) A default context

   One entry in the acmContextTable 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
                                 ------------------  ---------------
     acmContextName              ""                  ""

3) An initial group

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

                                 no privacy support  privacy support
                                 ------------------  ---------------
   acmSecurityModel              3 (USM)             3 (USM)
   acmSecurityName               "initial"           "initial"
   acmGroupName                  "initial"           "initial"
   acmSecurityToGroupStorageType anyValidStorageType anyValidStorageType
   acmSecurityToGroupStatus      active              active

4) An initial acmGroupListTable

   Those columns marked with (index) are index-only objects and are
   not really present in this table.  Note that this table gets created
   automatically because of the configuration of the initial group.

   One entry in the acmGroupListTable as follows:



Wijnen/Presuhn/McCloghrie      Expires December 1997           [Page 31]


Draft      View-based Access Control Model (ACM) for SNMP      July 1997



                                 no privacy support  privacy support
                                 ------------------  ---------------
     acmGroupName     (index)    "initial"           "initial"
     acmSecurityModel (index)    3 (USM)             3 (USM)
     acmSecurityName  (index)    "initial"           "initial"
     acmGroupListStatus          active              active


5) Initial access rights

   Three entries in the acmAccessTable as follows:

   - read-notify access for securityModel USM, LoS "noAuthNoPriv"
     on behalf of securityNames that belong to the group "initial" to
     the <restricted> MIB view in the context with contextName "".

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

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

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

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

                               no privacy support  privacy support
                               ------------------  ---------------
     acmAccessContextPrefix    ""                  ""
     acmGroupName     (index)  "initial"           "initial"
     acmSecurityModel (index)  3 (USM)             3 (USM)
     acmAccessLoS              noAuthNoPriv        noAuthNoPriv
     acmAccessReadViewName     "restricted"        "restricted"
     acmAccessWriteViewName    ""                  ""
     acmAccessNotifyViewName   "restricted"        "restricted"
     acmAccessStorageType      anyValidStorageType anyValidStorageType
     acmAccessStatus           active              active

   - One entry to be used for authenticated access but without
     privacy (authNoPriv):
                               no privacy support  privacy support
                               ------------------  ---------------
     acmAccessContextPrefix    ""                  ""
     acmGroupName     (index)  "initial"           "initial"
     acmSecurityModel (index)  3 (USM)             3 (USM)



Wijnen/Presuhn/McCloghrie      Expires December 1997           [Page 32]


Draft      View-based Access Control Model (ACM) for SNMP      July 1997


     acmAccessLoS              authNoPriv          authNoPriv
     acmAccessReadViewName     "all-iso"           "all-iso"
     acmAccessWriteViewName    "all-iso"           "all-iso"
     acmAccessNotifyViewName   "all-iso"           "all-iso"
     acmAccessStorageType      anyValidStorageType anyValidStorageType
     acmAccessStatus           active              active

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

                               no privacy support  privacy support
                               ------------------  ---------------
     acmAccessContextPrefix                        ""
     acmGroupName     (index)                      "initial"
     acmSecurityModel (index)                      3 (USM)
     acmAccessLoS                                  authPriv
     acmAccessReadViewName                         "all-iso"
     acmAccessWriteViewName                        "all-iso"
     acmAccessNotifyViewName                       "all-iso"
     acmAccessStorageType                          anyValidStorageType
     acmAccessStatus                               active

     Note however, that this last entry is also covered by the
     entry that allows authNoPriv access because the authPriv access
     is a better LoS than the authNoPriv.

6) Two MIB views depending on the security posture.

   -  One view (the <all-iso> view) for authenticated access:

      -  the <all-iso> MIB view is the following subtree:
             "iso"  (subtree 1)

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

      -  For the "very-secure" posture there is no default initial
         configuration, so no MIB views are pre-scribed.

      -  For the "semi-secure" posture:

         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) "snmpV3Stats" (subtree 1.3.6.1.6.3.8.2.1) [SNMPv3-MPC]
         (e) "usmStats"    (subtree 1.3.6.1.6.3.9.2.1) [SNMPv3-USM]

      -  For the "minimum-secure" posture:




Wijnen/Presuhn/McCloghrie      Expires December 1997           [Page 33]


Draft      View-based Access Control Model (ACM) for SNMP      July 1997


         the <restricted> MIB view is the following subtree.
             "iso"  (subtree 1)

   This translates into the following "all-iso" entry in the
   acmViewTreeFamilyTable:

                                minimum-secure      semi-secure
                                ----------------    ---------------
   acmViewTreeFamilyViewName    "all-iso"           "all-iso"
   acmViewTreeFamilySubtree     1                   1
   acmViewTreeFamilyMask        ""                  ""
   acmViewTreeFamilyType        1 (included)        1 (included)
   acmViewTreeFamilyStorageType anyValidStorageType anyValidStorageType
   acmViewTreeFamilyStatus      active              active

   This translates into the following "restricted" entries in the
   acmViewTreeFamilyTable:

                                minimum-secure      semi-secure
                                ----------------    ---------------
   acmViewTreeFamilyViewName    "restricted"        "restricted"
   acmViewTreeFamilySubtree     1                   1.3.6.1.2.1.1
   acmViewTreeFamilyMask        " "                  ""
   acmViewTreeFamilyType        1 (included)        1 (included)
   acmViewTreeFamilyStorageType anyValidStorageType anyValidStorageType
   acmViewTreeFamilyStatus      active              active

   acmViewTreeFamilyViewName                        "restricted"
   acmViewTreeFamilySubtree                         1.3.6.1.2.1.11
   acmViewTreeFamilyMask                            ""
   acmViewTreeFamilyType                            1 (included)
   acmViewTreeFamilyStorageType                     anyValidStorageType
   acmViewTreeFamilyStatus                          active

   acmViewTreeFamilyViewName                        "restricted"
   acmViewTreeFamilySubtree                         1.3.6.1.6.3.7.2.1
   acmViewTreeFamilyMask                            ""
   acmViewTreeFamilyType                            1 (included)
   acmViewTreeFamilyStorageType                     anyValidStorageType
   acmViewTreeFamilyStatus                          active

   acmViewTreeFamilyViewName                        "restricted"
   acmViewTreeFamilySubtree                         1.3.6.1.6.3.8.2.1
   acmViewTreeFamilyMask                            ""
   acmViewTreeFamilyType                            1 (included)
   acmViewTreeFamilyStorageType                     anyValidStorageType
   acmViewTreeFamilyStatus                          active

   acmViewTreeFamilyViewName                        "restricted"
   acmViewTreeFamilySubtree                         1.3.6.1.6.3.9.2.1
   acmViewTreeFamilyMask                            ""



Wijnen/Presuhn/McCloghrie      Expires December 1997           [Page 34]


Draft      View-based Access Control Model (ACM) for SNMP      July 1997


   acmViewTreeFamilyType                            1 (included)
   acmViewTreeFamilyStorageType                     anyValidStorageType
   acmViewTreeFamilyStatus                          active



















































Wijnen/Presuhn/McCloghrie      Expires December 1997           [Page 35]


Draft      View-based Access Control Model (ACM) for SNMP      July 1997


Table of Contents

0.  Issues and Change Log                                              2
0.1.  Issues                                                           2
0.2.  Change Log                                                       2
1.  Introduction                                                       4
1.2.  Access Control                                                   4
1.3.  Local Configuration Datastore                                    5
2.  Elements of the Model                                              6
2.1.  groupName                                                        6
2.2.  Level of Security (LoS)                                          6
2.3.  Contexts                                                         6
2.4.  MIB Views and View Families                                      7
2.4.1.  View Subtree                                                   7
2.4.2.  ViewTreeFamily                                                 7
2.5.  Access Policy                                                    8
3.  Elements of Procedure                                              9
3.1  Processing the isAccessAllowed Service Request                   10
4.  Definitions                                                       12
5.  Security Considerations                                           28
5.1.  Recommended Practices                                           28
5.2.  Defining Groups                                                 28
5.3.  Conformance                                                     28
6.  Editor's Addresses                                                29
7.  Acknowledgements                                                  29
8.  References                                                        30
A.1.  Installation Parameters                                         31





























Wijnen/Presuhn/McCloghrie      Expires December 1997           [Page 36]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/