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