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