View-based Access Control Model for the
Simple Network Management Protocol (SNMP)
14 July 1997
Bert Wijnen
IBM T. J. Watson Research
wijnen@vnet.ibm.com
Randy Presuhn
BMC Software, Inc.
rpresuhn@bmc.com
Keith McCloghrie
Cisco Systems, Inc.
kzm@cisco.com
<draft-ietf-snmpv3-acm-01.txt>
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as ``work in progress.''
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow
Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe),
ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
Abstract
This document describes the View-based Access Control Model (ACM) for
use in the SNMP architecture [SNMP-ARCH]. It defines the Elements of
Procedure for applying access control to management information.
This document also includes a MIB for remotely managing the
configuration parameters for this ACM.
Wijnen/Presuhn/McCloghrie Expires December 1997 [Page 1]
^L
Draft View-based Access Control Model (ACM) for SNMP July 1997
0. Issues and Change Log
0.1. Issues
- acknowledgements needs expansion
- There is a reverse mapping from groupName to securityName, see
the acmGroupListTable. However, given the amount of object
we're adding, we may want to remove/postpone this table?
- reference section must be checked; sync up with other documents
- Do we need/want the level of detail of errorIndication that
the isAccessAllowed primitive will return? Those who strongly
object to the details listed now, better let us know (on the
mailing list preferably) ASAP.
0.2. Change Log
[version 4.2] - This is the July 14 version.
- Address comments by Keith:
- Renumber section 2.4 to 2.5
- Add new sections 2.4, 2.4.1, 2.4.2 about MIB Views and Subtrees
and Families,
- Use some more precise language at various places.
- Add reference to RFC2119 about use of SHOULD and MUST
- rename the acmGroupTable to acmSecurityToGroupTable because that
much better indicates the function of this table.
- improved the writeup on statusInformation for the isAccessAllowed
primitive.
- paginate and generate table of contents
- posted as I-D <draft-ietf-snmpv3-acm-01.txt> on 15 July
[version 4.1] - This is the July 12 version.
- Adapt to latest list of Primitives/Parameters.
- Handle comments from co-editor Randy
- Added the SHOULD "initial" configuration
- Checked the MIB with SMICng
[version 4.0] - This is the July 7 version.
- Adopt to decisions/comments made are 2nd interim
- securityName to groupName mapping is in ACM
- out of the box configurations to be described as SHOULD
- UTF-8 issue still open, but move to general issue (ARCH)
where the SnmpAdminString is defined.
- ACM returns errorIndication based on which the caller
may increment error counter which may result in a
Report PDU.
- No statistics counters are kept in ACM
- removed viewTable; added acmViewSpinLock
- Address various comments from co-editors (Randy and Keith)
- Address comments made on mailing list(s).
[version 3.1] - This is the June 18 version.
- remove old (resolved) issues
Wijnen/Presuhn/McCloghrie Expires December 1997 [Page 2]
Draft View-based Access Control Model (ACM) for SNMP July 1997
- list new issues
- corrections/additions by myself (Bert)
- corrections based on dbh comments
- removed change log of before 1st interim meeting.
[version 3.0] - this is the first ACM doc (June 12 version).
- Modifications as agreed at 1st Interim Meeting
- Make Access Control Module a separate document
- Use viewName as index instead of an integer
- add notify_view
- use SnmpAdminString
- Other Modification
- use miId and securityModel
- add acmGroupTable
- add/rename Stats counters
Wijnen/Presuhn/McCloghrie Expires December 1997 [Page 3]
^L
Draft View-based Access Control Model (ACM) for SNMP July 1997
1. Introduction
The Architecture for describing Internet Management Frameworks
[SNMP-ARCH] is composed of multiple subsystems:
1) a Message Processing Subsystem,
2) a Security Subsystem,
3) an Access Control Subsystem,
Applications make use of the services of these subsystems.
It is important to understand the SNMP architecture and its
terminology to understand where the View-based Access Control
Model described in this document fits into the architecture and
interacts with other subsystems within the architecture. The
reader is expected to have read and understood the description and
terminology of the SNMP architecture, as defined in [SNMP-ARCH].
The Access Control Subsystem of an SNMP engine provides services
to determine whether access to an object instance is permitted.
An Access Control Model has the responsibility for checking if
a specific type of access (read, write, notify) to a particular
object (instance) is allowed.
It is the purpose of this document to define a specific model of
the Access Control Subsystem, designated the View-based Access
Control Model.
1.2. Access Control
Access Control occurs (either implicitly or explicitly) in an SNMP
entity when processing SNMP retrieval or modification request
messages from another SNMP entity. For example a Command Responder
application applies Access Control when processing requests that it
received from a Command Generator application. These requests
include these types of operations: GetRequest, GetNextRequest,
GetBulkRequest, and SetRequest operations.
Access Control also occurs in an SNMP entity when an SNMP
notification message is generated (by a Notification Originator
application). These notification messages include these types of
operations: InformRequest and SNMPv2-trap operations.
The View-based Access Control Model defines a set of services that
an application (such as a Command Responder or a Notification
Originator application) can use for checking access rights.
It is the responsibility of the application to make the proper
service calls for access checking.
Wijnen/Presuhn/McCloghrie Expires December 1997 [Page 4]
Draft View-based Access Control Model (ACM) for SNMP July 1997
1.3. Local Configuration Datastore
To implement the model described in this document, an SNMP entity
needs to retain information about access rights and policies.
This information is part of the SNMP engine's Local Configuration
Datastore (LCD). See [SNMP-ARCH] for the definition of LCD.
In order to allow an SNMP entity's LCD to be remotely configured,
portions of the LCD need to be accessible as managed objects.
A MIB module, the View-based Access Control Model Configuration
MIB, which defines these managed object types is included in
this document.
Wijnen/Presuhn/McCloghrie Expires December 1997 [Page 5]
^L
Draft View-based Access Control Model (ACM) for SNMP July 1997
2. Elements of the Model
This section contains definitions to realize the access control
service provided by the View-based Access Control Model.
2.1. groupName
A groupName identifies a group (set) of zero or more securityNames
on whose behalf SNMP management objects can be accessed. A group
defines the access rights afforded to all securityNames which
belong to that group. The combination of a securityModel and a
securityName maps to at most one group.
The Access Control module assumes that the securityName has already
been authenticated as needed and provides no further authentication
of its own.
The View-based Access Control Model uses the securityModel and the
securityName as inputs to the Access Control module when called to
check for access rights. It determines the groupName as a function
of securityModel and securityName.
2.2. Level of Security (LoS)
Different access rights for members of a group can be defined for
different Levels of Security. The LoS identifies the Level of
Security that will be assumed when checking for access rights. See
the SNMP Architecture document [SNMP-ARCH] for a definition of LoS.
The View-based Access Control Model requires the LoS to be passed
as input to the Access Control module when called to check for
access rights.
2.3. Contexts
An SNMP context is a collection of management information
accessible by an SNMP entity. An item of management information
may exist in more than one context. An SNMP entity potentially
has access to many contexts. Details about the naming of
management information can be found in the SNMP Architecture
document [SNMP-ARCH].
The View-based Access Control Model defines an acmContextTable that
lists the locally available contexts by contextName.
Wijnen/Presuhn/McCloghrie Expires December 1997 [Page 6]
^L
Draft View-based Access Control Model (ACM) for SNMP July 1997
2.4. MIB Views and View Families
For security reasons, it is often valuable to be able to restrict
the access rights of some groups to only a subset of the management
information in the management domain. To provide this capability,
access to a context is via a "MIB view" which details a specific
set of managed object types (and optionally, the specific instances
of object types) within that context. For example, for a given
context, there will typically always be one MIB view which provides
access to all management information in that context, and often
there will be other MIB views each of which contains some subset of
the information. So, by providing access rights to a group in
terms of the particular (subset) MIB view it can access for that
context, then the group is restricted in the desired manner.
Since managed object types (and their instances) are identified via
the tree-like naming structure of ISO's OBJECT IDENTIFIERs
[ISO-ASN.1, RFC1902], it is convenient to define a MIB view as the
combination of a set of "view subtrees", where each view subtree is
a subtree within the managed object naming tree. Thus, a simple
MIB view (e.g., all managed objects within the Internet Network
Management Framework) can be defined as a single view subtree,
while more complicated MIB views (e.g., all information relevant to
a particular network interface) can be represented by the union of
multiple view subtrees.
While any set of managed objects can be described by the union of
some number of view subtrees, situations can arise that would
require a very large number of view subtrees. This could happen,
for example, when specifying all columns in one conceptual row of a
MIB table because they would appear in separate subtrees, one per
column, each with a very similar format. Because the formats are
similar, the required set of subtrees can easily be aggregated into
one structure. This structure is named a family of view subtrees
after the set of subtrees that it conceptually represents. A family
of view subtrees can either be included or excluded from a MIB view.
2.4.1. View Subtree
A view subtree is the set of all MIB object instances which have a
common ASN.1 OBJECT IDENTIFIER prefix to their names. A view
subtree is identified by the OBJECT IDENTIFIER value which is the
longest OBJECT IDENTIFIER prefix common to all (potential) MIB
object instances in that subtree.
2.4.2. ViewTreeFamily
A family of view subtrees is a pairing of an OBJECT IDENTIFIER value
(called the family name) together with a bit string value (called
Wijnen/Presuhn/McCloghrie Expires December 1997 [Page 7]
Draft View-based Access Control Model (ACM) for SNMP July 1997
the family mask). The family mask indicates which sub-identifiers
of the associated family name are significant to the family's
definition.
For each possible managed object instance, that instance belongs to
a particular ViewTreeFamily if both of the following conditions
are true:
- the OBJECT IDENTIFIER name of the managed object instance contains
at least as many sub-identifiers as does the family name, and
- each sub-identifier in the OBJECT IDENTIFIER name of the managed
object instance matches the corresponding sub-identifier of the
family name whenever the corresponding bit of the associated
family mask is non-zero.
When the configured value of the family mask is all ones, the view
subtree family is identical to the single view subtree identified
by the family name.
When the configured value of the family mask is shorter than
required to perform the above test, its value is implicitly
extended with ones. Consequently, a view subtree family having a
family mask of zero length always corresponds to a single view
subtree.
2.5. Access Policy
The View-based Access Control Model determines the access rights
of a group (representing zero, one or more securityNames which have
the same access rights). For a particular context (contextName) to
which a group (groupName) has access using a particular Security
Model (securityModel) and Level of Security (LoS), that group's
access rights are given by a read-view, a write-view and a
notify-view.
The read-view represents the set of object instances authorized for
the group when reading objects. Reading objects occurs when
processing a retrieval (for example a GetRequest, GetNextRequest,
GetBulkRequest) operation.
The write-view represents the set of object instances authorized for
the group when writing objects. Writing objects occurs when
processing a write (for example a Set) operation.
The notify-view represents the set of object instances authorized
for the group when sending objects in a notification. This occurs
when sending a notification (for example an Inform or SNMPv2-Trap).
Wijnen/Presuhn/McCloghrie Expires December 1997 [Page 8]
^L
Draft View-based Access Control Model (ACM) for SNMP July 1997
3. Elements of Procedure
This section describes the procedures followed by an Access Control
module, that implements the View-based Access Control Model, when
checking access rights as requested by an application (for example
a Command Responder or a Notification Originator application).
The abstract service interface primitive is:
statusInformation = -- success or errorIndication
isAccessAllowed(
securityModel -- Security Model in use
securityName -- principal who wants to access
LoS -- Level of Security
viewType -- read, write, or notify view
contextName -- context containing variableName
variableName -- OID for the managed object
)
Where:
statusInformation
one of the following:
accessAllowed - success (and access is granted).
a MIB view was found and access is granted.
notInView - success (but access is denied).
a MIB view was found but access is denied
because the variableName is not in the
configured MIB view for the specified
viewType (e.g. in the relevant entry in the
acmAccessTable).
noSuchView - failure, no MIB view found because no view
configured for specified viewType (e.g. in
the relevant entry in the acmAccessTable).
noSuchContext - failure, no MIB view found because no entry
in the acmContextTable for the specified
contextName.
noGroupName - failure, no MIB view found because no entry
configured in the acmSecurityToGroupTable
for the specified combination of
securityModel and securityName.
noAccessEntry - failure, no MIB view found because no entry
configured in the acmAccessTable for the
specified combination of contextName,
groupName (as found in the
acmSecurityToGroupTable based on
securityModel and securityName),
securityModel and LoS.
otherError - failure, an undefined error occurred.
Wijnen/Presuhn/McCloghrie Expires December 1997 [Page 9]
Draft View-based Access Control Model (ACM) for SNMP July 1997
securityModel
Security Model under which access is requested.
securityName
representing the principal on whose behalf access is requested.
LoS
Level of Security under which access is requested.
viewType
view to be checked (read, write or notify).
contextName
context in which access to variableName is requested.
variableName
variable (object instance) to which access is requested.
3.1 Processing the isAccessAllowed Service Request
This section describes the procedure followed by an Access Control
module, that implements the View-based Access Control Model,
whenever it receives an isAccessAllowed request.
1) The LCD (acmContextTable) is consulted for information about
the SNMP context identified by the contextName. If information
about this SNMP context is absent from the LCD, then an
errorIndication (noSuchContext) is returned to the calling
module.
2) The LCD (acmSecurityToGroupTable) is consulted for mapping the
Security Model (securityModel) and principal (securityName) to a
group (groupName). If that information about this combination is
absent from the LCD, then an errorIndication (noGroupName)
is returned to the calling module.
3) The LCD (acmAccessTable) is consulted for information about the
contextName, groupName, securityModel and LoS. If information
about this combination is absent from the LCD, then an
errorIndication (noAccessEntry) is returned to the calling
module.
4) a) If the viewType is "read", then the read view is used for
checking access rights.
b) If the viewType is "write", then the write view is used for
checking access rights.
c) If the viewType is "notify", then the notify view is used
for checking access rights.
5) a) If there is no view configured for the specified viewType,
then an errorIndication (noSuchView) is returned to the
calling module.
Wijnen/Presuhn/McCloghrie Expires December 1997 [Page 10]
Draft View-based Access Control Model (ACM) for SNMP July 1997
b) If the specified variableName (object instance) is not in the
MIB view (see DESCRIPTION clause for acmViewTreeFamilyTable in
section 4), then an errorIndication (notInView) is returned
to the calling module.
Otherwise,
c) The specified variableName is in the MIB view.
A statusInformation of success (accessAllowed) is returned
to the calling module.
Wijnen/Presuhn/McCloghrie Expires December 1997 [Page 11]
^L
Draft View-based Access Control Model (ACM) for SNMP July 1997
4. Definitions
SNMP-VIEW-BASED-ACM-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF
MODULE-IDENTITY, OBJECT-TYPE,
snmpModules FROM SNMPv2-SMI
TestAndIncr,
RowStatus, StorageType FROM SNMPv2-TC
SnmpAdminString,
SnmpLoS,
SnmpSecurityModel FROM SNMP-FRAMEWORK-MIB;
snmpAcmMIB MODULE-IDENTITY
LAST-UPDATED "9707140000Z" -- 14 July 1997, midnight
ORGANIZATION "SNMPv3 Working Group"
CONTACT-INFO "WG-email: snmpv3@tis.com
Subscribe: majordomo@tis.com
In message body: subscribe snmpv3
Chair: Russ Mundy
Trusted Information Systems
postal: 3060 Washington Rd
Glenwood MD 21738
USA
email: mundy@tis.com
phone: +1-301-854-6889
Co-editor: Bert Wijnen
IBM T.J. Watson Research
postal: Schagen 33
3461 GL Linschoten
Netherlands
email: wijnen@vnet.ibm.com
phone: +31-348-432-794
Co-editor: Randy Presuhn
BMC Software, Inc
postal: 1190 Saratoga Avenue, Suite 130
San Jose, CA 95129-3433
USA
email: rpresuhn@bmc.com
phone: +1-408-556-0720
Co-editor: Keith McCloghrie
Cisco Systems, Inc.
postal: 170 West Tasman Drive
San Jose, CA 95134-1706
USA
email: kzm@cisco.com
Wijnen/Presuhn/McCloghrie Expires December 1997 [Page 12]
Draft View-based Access Control Model (ACM) for SNMP July 1997
phone: +1-408-526-5260
"
DESCRIPTION "The management information definitions for the
View-based Access Control Model for SNMP.
"
::= { snmpModules 10 } -- to be verified with IANA
-- Administrative assignments ****************************************
acmMIBObjects OBJECT IDENTIFIER ::= { snmpAcmMIB 1 }
acmMIBConformance OBJECT IDENTIFIER ::= { snmpAcmMIB 2 }
-- Information about Local Contexts **********************************
acmContextTable OBJECT-TYPE
SYNTAX SEQUENCE OF AcmContextEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "The table of locally available contexts. If a context
is listed in this table that does not mean that
access to this context has been defined in the
acmAccessTable. It just means that the context exists
and that MIB objects may exist in this context.
This table must be made accessible via the default
context.
This table is read-only meaning that it cannot be
configured via SNMP.
This table is provides information to SNMP Command
Generator applications so they can properly configure
the acmAccessTable to control access to all contexts
at the SNMP entity that provides access to the
information in these contexts.
"
::= { acmMIBObjects 1 }
acmContextEntry OBJECT-TYPE
SYNTAX AcmContextEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "Information about a particular context."
INDEX {
acmContextName
}
::= { acmContextTable 1 }
AcmContextEntry ::= SEQUENCE
{
Wijnen/Presuhn/McCloghrie Expires December 1997 [Page 13]
Draft View-based Access Control Model (ACM) for SNMP July 1997
acmContextName SnmpAdminString
}
acmContextName OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE(0..32))
MAX-ACCESS read-only
STATUS current
DESCRIPTION "A human readable name identifying a particular
context at a particular SNMP entity.
"
::= { acmContextEntry 1 }
-- Information about Groups ******************************************
acmSecurityToGroupTable OBJECT-TYPE
SYNTAX SEQUENCE OF AcmSecurityToGroupEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "The table that maps a combination of securityModel
and securityName into a groupName which defines an
access control policy for a group of principals.
"
::= { acmMIBObjects 2 }
acmSecurityToGroupEntry OBJECT-TYPE
SYNTAX AcmSecurityToGroupEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "An entry in this table maps the combination of a
securityModel and securityName into a groupName.
"
INDEX {
acmSecurityModel,
acmSecurityName
}
::= { acmSecurityToGroupTable 1 }
AcmSecurityToGroupEntry ::= SEQUENCE
{
acmSecurityModel SnmpSecurityModel,
acmSecurityName SnmpAdminString,
acmGroupName SnmpAdminString,
acmSecurityToGroupStorageType StorageType,
acmSecurityToGroupStatus RowStatus
}
acmSecurityModel OBJECT-TYPE
SYNTAX SnmpSecurityModel
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "The Security Model, which is the first index in this
Wijnen/Presuhn/McCloghrie Expires December 1997 [Page 14]
Draft View-based Access Control Model (ACM) for SNMP July 1997
table.
"
::= { acmSecurityToGroupEntry 1 }
acmSecurityName OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "The securityName for a principal represented in a
Security Model independent format.
Used as a second index in this table.
"
::= { acmSecurityToGroupEntry 2 }
acmGroupName OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-create
STATUS current
DESCRIPTION "The name of the group to which this entry (e.g. the
combination of securityModel and securityName)
belongs.
This groupName represents an access control policy
and is used as an index in the acmAccessTable.
"
::= { acmSecurityToGroupEntry 3 }
acmSecurityToGroupStorageType OBJECT-TYPE
SYNTAX StorageType
MAX-ACCESS read-create
STATUS current
DESCRIPTION "The storage type for this conceptual row.
Conceptual rows having the value 'permanent' need not
allow write-access to any columnar objects in the row.
"
DEFVAL { nonVolatile }
::= { acmSecurityToGroupEntry 4 }
acmSecurityToGroupStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION "The status of this conceptual row.
The value of this object has no effect on whether
other objects in this conceptual row can be modified.
"
::= { acmSecurityToGroupEntry 5 }
-- Reverse mapping from groupName into securityName(s) ***************
Wijnen/Presuhn/McCloghrie Expires December 1997 [Page 15]
Draft View-based Access Control Model (ACM) for SNMP July 1997
acmGroupListTable OBJECT-TYPE
SYNTAX SEQUENCE OF AcmGroupListEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "The acmGroupListTable complements the
acmSecurityToGroupTable by providing an efficient
means to determine the membership of a given group.
"
::= { acmMIBObjects 3 }
acmGroupListEntry OBJECT-TYPE
SYNTAX AcmGroupListEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "An entry in this table corresponds to an entry in the
acmSecurityToGroupTable, using acmGroupName as its
primary key.
"
INDEX {
acmGroupName,
acmSecurityModel,
acmSecurityName
}
::= { acmGroupListTable 1 }
AcmGroupListEntry ::= SEQUENCE
{
acmGroupListStatus RowStatus
}
acmGroupListStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The status of this conceptual row.
The value is identical to that of the corresponding
acmSecurityToGroupEntry's acmSecurityToGroupStatus.
"
::= { acmGroupListEntry 1 }
-- Information about Access Rights ***********************************
acmAccessTable OBJECT-TYPE
SYNTAX SEQUENCE OF AcmAccessEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "The table of group access rights configured in the
Local Configuration Datastore (LCD).
Wijnen/Presuhn/McCloghrie Expires December 1997 [Page 16]
Draft View-based Access Control Model (ACM) for SNMP July 1997
Each entry is indexed by a contextPrefix, a groupName
a securityModel and a Level of Security (LoS). To
determine whether access is allowed, one entry from
this table needs to be selected and the proper
viewName from that entry must be used for access
control checking.
To select the proper entry, first a match must be
found for the contextPrefix. The procedure for this
process depends on the value of acmAccessContextMatch:
- exact
In this case, the acmAccessContextPrefix represents
an exact contextName, and so the name must match
exactly.
- prefix
In this case, the acmAccessContextPrefix represents
a prefix of a contextName, so that (a limited form
of) wildcarding is possible. The value of
acmAccessContextPrefix must match with the first
part of the contextName to which access is
requested.
For example, if an acmAccessContextPrefix value of
'repeater' is used, then both contexts named
'repeater1' and 'repeater2' are accessible.
Multiple entries could match. In that case:
- The entry which has the longest value for
acmAccessContextPrefix wins.
Otherwise, if still no single winner (e.g. multiple
entries have the same acmAccessContextPrefix value,
- The entry which has the value 'exact' for the
corresponding acmAccessContextMatch, wins.
Otherwise, if still no single winner (e.g. multiple
entries have a acmAccessContextMatch value 'exact',
- Then continue. At the 4th match to make a final
winner will be found if there are still multiple
entries.
The second match to make is for the groupName.
Here an exact match must be found.
The 3rd match to make is for the securityModel.
Here an exact match must be found. If no such exact
Wijnen/Presuhn/McCloghrie Expires December 1997 [Page 17]
Draft View-based Access Control Model (ACM) for SNMP July 1997
match exists, then an entry that has the 'all' value
(see definition of SnmpSecurityModel in [SNMP-ARCH])
for the acmAccessSecurityModel is considered to match.
The 4th match to make is for the LoS. Here the LoS
at which access is requested must be greater than or
equal to the value of the acmAccessLoS.
If multiple entries are still considered to match,
then the entry which has the lowest value for the
corresponding acmAccessLoS wins.
"
::= { acmMIBObjects 4 }
acmAccessEntry OBJECT-TYPE
SYNTAX AcmAccessEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "An access right configured in the Local Configuration
Datastore (LCD) authorizing access to an SNMP context.
"
INDEX { acmAccessContextPrefix,
acmGroupName,
acmSecurityModel,
acmAccessLoS
}
::= { acmAccessTable 1 }
AcmAccessEntry ::= SEQUENCE
{
acmAccessContextPrefix SnmpAdminString,
acmAccessLoS SnmpLoS,
acmAccessContextMatch INTEGER,
acmAccessReadViewName SnmpAdminString,
acmAccessWriteViewName SnmpAdminString,
acmAccessNotifyViewName SnmpAdminString,
acmAccessStorageType StorageType,
acmAccessStatus RowStatus
}
acmAccessContextPrefix OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "In order to gain the access rights allowed by this
conceptual row, a contextName must match exactly
(if the value of acmAccessContextMatch is 'exact')
or partially (if the value of acmAccessContextMatch
is 'prefix') to the value of the instance of this
object.
"
::= { acmAccessEntry 1 }
Wijnen/Presuhn/McCloghrie Expires December 1997 [Page 18]
Draft View-based Access Control Model (ACM) for SNMP July 1997
acmAccessLoS OBJECT-TYPE
SYNTAX SnmpLoS
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "The minimum level of security required in order to
gain the access rights allowed by this conceptual
row. An LoS of noAuthNoPriv is lower than authNoPriv
which in turn is lower than authPriv.
If multiple entries are equally indexed except for
this acmAccessLoS index, then the entry which has
the lowest value for acmAccessLoS wins.
"
::= { acmAccessEntry 2 }
acmAccessContextMatch OBJECT-TYPE
SYNTAX INTEGER
{ exact (1), -- exact match of prefix and contextName
prefix (2) -- Only match to the prefix
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION "If exact is set, then the value of the index part
acmAccessContextPrefix of this entry in this table
represents a full contextName.
If prefix is set, then the value of the index part
acmAccessContextPrefix of this entry in this
table represents a partial contextName which acts
as a prefix so that a simple form of wildcarding
is possible.
"
::= { acmAccessEntry 3 }
acmAccessReadViewName OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-create
STATUS current
DESCRIPTION "The value of an instance of this object identifies
the MIB view of the SNMP context to which this
conceptual row authorizes read access.
The identified MIB view is that one for which the
acmViewTreeFamilyViewName has the same value as the
instance of this object; if the value is the empty
string or if there is no active MIB view having this
value of acmViewTreeFamilyViewName, then no access is
granted.
"
DEFVAL { ''H } -- the empty string
Wijnen/Presuhn/McCloghrie Expires December 1997 [Page 19]
Draft View-based Access Control Model (ACM) for SNMP July 1997
::= { acmAccessEntry 4 }
acmAccessWriteViewName OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-create
STATUS current
DESCRIPTION "The value of an instance of this object identifies
the MIB view of the SNMP context to which this
conceptual row authorizes write access.
The identified MIB view is that one for which the
acmViewTreeFamilyViewName has the same value as the
instance of this object; if the value is the empty
string or if there is no active MIB view having this
value of acmViewTreeFamilyViewName, then no access is
granted.
"
DEFVAL { ''H } -- the empty string
::= { acmAccessEntry 5 }
acmAccessNotifyViewName OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-create
STATUS current
DESCRIPTION "The value of an instance of this object identifies
the MIB view of the SNMP context to which this
conceptual row authorizes access for notifications.
The identified MIB view is that one for which the
acmViewTreeFamilyViewName has the same value as the
instance of this object; if the value is the empty
string or if there is no active MIB view having this
value of acmViewTreeFamilyViewName, then no access is
granted.
"
DEFVAL { ''H } -- the empty string
::= { acmAccessEntry 6 }
acmAccessStorageType OBJECT-TYPE
SYNTAX StorageType
MAX-ACCESS read-create
STATUS current
DESCRIPTION "The storage type for this conceptual row.
Conceptual rows having the value 'permanent' need not
allow write-access to any columnar objects in the row.
"
DEFVAL { nonVolatile }
::= { acmAccessEntry 7 }
acmAccessStatus OBJECT-TYPE
Wijnen/Presuhn/McCloghrie Expires December 1997 [Page 20]
Draft View-based Access Control Model (ACM) for SNMP July 1997
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION "The status of this conceptual row.
The value of this object has no effect on whether
other objects in this conceptual row can be modified.
"
::= { acmAccessEntry 8 }
-- Information about MIB views ***************************************
-- Support for views having instance-level granularity is optional
acmMIBViews OBJECT IDENTIFIER ::= { acmMIBObjects 5 }
acmViewSpinLock OBJECT-TYPE
SYNTAX TestAndIncr
MAX-ACCESS read-write
STATUS current
DESCRIPTION "An advisory lock used to allow cooperating SNMP
Command Generator applications to coordinate their
use of the Set operation in creating view subtrees.
When creating a new view or altering an existing
view, it is important to understand the potential
interactions with other uses of the view. The
acmViewSpinLock should be retrieved. The name of the
view to be created should be determined to be unique
by the SNMP Command Generator application by
consulting the acmViewTreeFamilyTable. Finally, the
named view may be created (Set), including the
advisory lock.
If another SNMP Command Generator application has
altered the views in the meantime, then the spin
lock's value will have changed, and so this creation
will fail because it will specify the wrong value for
the spin lock.
Since this is an advisory lock, the use of this lock
is not enforced.
"
::= { acmMIBViews 1 }
acmViewTreeFamilyTable OBJECT-TYPE
SYNTAX SEQUENCE OF AcmViewTreeFamilyEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "Locally held information about families of subtrees
within MIB views.
Wijnen/Presuhn/McCloghrie Expires December 1997 [Page 21]
Draft View-based Access Control Model (ACM) for SNMP July 1997
Each MIB view is defined by two sets of view subtrees:
- the included view subtrees, and
- the excluded view subtrees.
Every such view subtree, both included and excluded,
is defined in this table.
To determine if a particular object instance is in
a particular MIB view, compare the object instance's
OBJECT IDENTIFIER with each of the MIB view's active
entries in this table. If none match, then the
object instance is not in the MIB view. If one or
more match, then the object instance is included in,
or excluded from, the MIB view according to the
value of acmViewTreeFamilyType in the entry whose
value of acmViewTreeFamilySubtree has the most
sub-identifiers. If multiple entries match and have
the same number of sub-identifiers, then the
lexicographically greatest instance of
acmViewTreeFamilyType determines the inclusion or
exclusion.
An object instance's OBJECT IDENTIFIER X matches an
active entry in this table when the number of
sub-identifiers in X is at least as many as in the
value of acmViewTreeFamilySubtree for the entry, and
each sub-identifier in the value of
acmViewTreeFamilySubtree matches its corresponding
sub-identifier in X. Two sub-identifiers match
either if the corresponding bit of the value of
acmViewTreeFamilyMask for the entry is zero (the
'wild card' value), or if they are equal.
A 'family' of subtrees is the set of subtrees defined
by a particular combination of values of
acmViewTreeFamilySubtree and acmViewTreeFamilyMask.
In the case where no 'wild card' is defined in the
acmViewTreeFamilyMask, the family of subtrees reduces
to a single subtree.
When an SNMP Command Generator application wants to
create a new MIB view, then it should first obtain
the value of the advisory spin lock and a list of
existing named views. It then selects a new
non-existing index-value (viewName) for
acmViewTreeFamilyViewName. The SNMP Command Generator
application can then start creating entries in the
acmViewTreeFamilyTable. It should include the
advisory lock in the Set Operation to ensure that an
other such application has not in the meanwhile
created new entries with a new (possibly colliding)
viewName in this table.
Wijnen/Presuhn/McCloghrie Expires December 1997 [Page 22]
Draft View-based Access Control Model (ACM) for SNMP July 1997
When creating MIB views, it is strongly advised that
first the 'excluded' acmViewTreeFamilyEntries are
created and then the 'included' entries.
When deleting MIB views, it is strongly advised that
first the 'included' acmViewTreeFamilyEntries are
deleted and then the 'excluded' entries.
"
::= { acmMIBViews 2 }
acmViewTreeFamilyEntry OBJECT-TYPE
SYNTAX AcmViewTreeFamilyEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "Information on a particular family of view subtrees
included in or excluded from a particular SNMP
context's MIB view.
Implementations must not restrict the number of
families of view subtrees for a given MIB view,
except as dictated by resource constraints on the
overall number of entries in the
acmViewTreeFamilyTable.
The value of acmViewTreeFamilyViewName in the INDEX
clause of this table identifies the MIB view in which
this subtree family exists.
A MIB view (viewName) for which there are no
conceptual rows in this table is the empty set of
view subtrees.
"
INDEX { acmViewTreeFamilyViewName,
acmViewTreeFamilySubtree
}
::= { acmViewTreeFamilyTable 1 }
AcmViewTreeFamilyEntry ::= SEQUENCE
{
acmViewTreeFamilyViewName SnmpAdminString,
acmViewTreeFamilySubtree OBJECT IDENTIFIER,
acmViewTreeFamilyMask OCTET STRING,
acmViewTreeFamilyType INTEGER,
acmViewTreeFamilyStorageType StorageType,
acmViewTreeFamilyStatus RowStatus
}
acmViewTreeFamilyViewName OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS not-accessible
Wijnen/Presuhn/McCloghrie Expires December 1997 [Page 23]
Draft View-based Access Control Model (ACM) for SNMP July 1997
STATUS current
DESCRIPTION "The human readable name for a family of view subtrees.
"
::= { acmViewTreeFamilyEntry 1 }
acmViewTreeFamilySubtree OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "The MIB subtree which when combined with the
corresponding instance of acmViewTreeFamilyMask
defines a family of view subtrees.
"
::= { acmViewTreeFamilyEntry 2 }
acmViewTreeFamilyMask OBJECT-TYPE
SYNTAX OCTET STRING (SIZE (0..16))
MAX-ACCESS read-create
STATUS current
DESCRIPTION "The bit mask which, in combination with the
corresponding instance of acmViewTreeFamilySubtree,
defines a family of view subtrees.
Each bit of this bit mask corresponds to a
sub-identifier of acmViewTreeFamilySubtree, with the
most significant bit of the i-th octet of this octet
string value (extended if necessary, see below)
corresponding to the (8*i - 7)-th sub-identifier, and
the least significant bit of the i-th octet of this
octet string corresponding to the (8*i)-th
sub-identifier, where i is in the range 1 through 16.
Each bit of this bit mask specifies whether or not
the corresponding sub-identifiers must match when
determining if an OBJECT IDENTIFIER is in this
family of view subtrees; a '1' indicates that an
exact match must occur; a '0' indicates 'wild card',
i.e., any sub-identifier value matches.
Thus, the OBJECT IDENTIFIER X of an object instance
is contained in a family of view subtrees if, for
each sub-identifier of the value of
acmViewTreeFamilySubtree, either:
the i-th bit of acmViewTreeFamilyMask is 0, or
the i-th sub-identifier of X is equal to the i-th
sub-identifier of the value of
acmViewTreeFamilySubtree.
If the value of this bit mask is M bits long and
Wijnen/Presuhn/McCloghrie Expires December 1997 [Page 24]
Draft View-based Access Control Model (ACM) for SNMP July 1997
there are more than M sub-identifiers in the
corresponding instance of acmViewTreeFamilySubtree,
then the bit mask is extended with 1's to be the
required length.
Note that when the value of this object is the
zero-length string, this extension rule results in
a mask of all-1's being used (i.e., no 'wild card'),
and the family of view subtrees is the one view
subtree uniquely identified by the corresponding
instance of acmViewTreeFamilySubtree.
"
DEFVAL { ''H }
::= { acmViewTreeFamilyEntry 3 }
acmViewTreeFamilyType OBJECT-TYPE
SYNTAX INTEGER { included(1), excluded(2) }
MAX-ACCESS read-create
STATUS current
DESCRIPTION "The indication of whether the corresponding instances
of acmViewTreeFamilySubtree and acmViewTreeFamilyMask
define a family of view subtrees which is included in
or excluded from the MIB view.
"
DEFVAL { included }
::= { acmViewTreeFamilyEntry 4 }
acmViewTreeFamilyStorageType OBJECT-TYPE
SYNTAX StorageType
MAX-ACCESS read-create
STATUS current
DESCRIPTION "The storage type for this conceptual row.
Conceptual rows having the value 'permanent' need not
allow write-access to any columnar objects in the row.
"
DEFVAL { nonVolatile }
::= { acmViewTreeFamilyEntry 5 }
acmViewTreeFamilyStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION "The status of this conceptual row.
The value of this object has no effect on whether
other objects in this conceptual row can be modified.
"
::= { acmViewTreeFamilyEntry 6 }
-- Conformance information *******************************************
Wijnen/Presuhn/McCloghrie Expires December 1997 [Page 25]
Draft View-based Access Control Model (ACM) for SNMP July 1997
acmMIBCompliances OBJECT IDENTIFIER ::= { acmMIBConformance 1 }
acmMIBGroups OBJECT IDENTIFIER ::= { acmMIBConformance 2 }
-- Compliance statements *********************************************
acmMIBCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION "The compliance statement for SNMP engines which
implement the SNMP View-based Access Control Model
configuration MIB.
"
MODULE -- this module
MANDATORY-GROUPS { acmBasicGroup }
OBJECT acmAccessContextMatch
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT acmAccessReadViewName
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT acmAccessWriteViewName
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT acmAccessNotifyViewName
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT acmAccessStorageType
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT acmAccessStatus
MIN-ACCESS read-only
DESCRIPTION "Create access to the acmAccessTable
is not required.
"
OBJECT acmViewTreeFamilyMask
WRITE-SYNTAX OCTET STRING (SIZE (0))
MIN-ACCESS read-only
DESCRIPTION "Support for configuration via SNMP of subtree
families using wild-cards is not required.
"
OBJECT acmViewTreeFamilyType
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
Wijnen/Presuhn/McCloghrie Expires December 1997 [Page 26]
Draft View-based Access Control Model (ACM) for SNMP July 1997
OBJECT acmViewTreeFamilyStorageType
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT acmViewTreeFamilyStatus
MIN-ACCESS read-only
DESCRIPTION "Create access to the acmViewTreeFamilyTable
is not required.
"
::= { acmMIBCompliances 1 }
-- Units of conformance **********************************************
acmBasicGroup OBJECT-GROUP
OBJECTS {
acmContextName,
acmGroupName,
acmSecurityToGroupStorageType,
acmSecurityToGroupStatus,
acmGroupListStatus,
acmAccessContextMatch,
acmAccessReadViewName,
acmAccessWriteViewName,
acmAccessNotifyViewName,
acmAccessStorageType,
acmAccessStatus,
acmViewSpinLock,
acmViewTreeFamilyMask,
acmViewTreeFamilyType,
acmViewTreeFamilyStorageType,
acmViewTreeFamilyStatus
}
STATUS current
DESCRIPTION "A collection of objects providing for remote
configuration of an SNMP engine which implements
the SNMP View-based Access Control Model (ACM).
"
::= { acmMIBGroups 1 }
END
Wijnen/Presuhn/McCloghrie Expires December 1997 [Page 27]
^L
Draft View-based Access Control Model (ACM) for SNMP July 1997
5. Security Considerations
5.1. Recommended Practices
This document is meant for use in the SNMP architecture. The
View-based Access Control Model (ACM) described in this document
checks access rights to management information based on:
- contextName, representing a set of management information at the
managed system where the Access Control module is running.
- groupName, representing a group or set of zero, one or more
securityNames. The combination of a securityModel and a
securityName is mapped into a group in the View-based Access
Control Model.
- securityModel used for the transmission of an SNMP message.
- Level of Security (LoS) used for the transmission of an SNMP
message.
- operation performed on the management information.
- MIB views for read, write or notify access.
When the User-based Access Control module (ACM) is called for
checking access rights, it is assumed that the calling module has
ensured the authentication and privacy aspects as specified by the
Level of Security (LoS) that is being passed.
5.2. Defining Groups
The groupNames are used to give access to a group of zero, one or
more securityNames. Within the ACM, a groupName is considered to
exist if that groupName is listed in the acmSecurityToGroupTable.
By mapping the combination of a securityModel and securityName into
a groupName, an SNMP Command Generator application can add/delete
securityNames to/from a group, that is if proper access is allowed.
5.3. Conformance
For an implementation of the View-based Access Control Model to be
conformant, it MUST implement the SNMP-VIEW-BASED-ACM-MIB. It also
SHOULD [RFC2119] implement the initial configuration, described in
appendix A.
Wijnen/Presuhn/McCloghrie Expires December 1997 [Page 28]
^L
Draft View-based Access Control Model (ACM) for SNMP July 1997
6. Editor's Addresses
Co-editor: Bert Wijnen
IBM T. J. Watson Research
postal: Schagen 33
3461 GL Linschoten
Netherlands
email: wijnen@vnet.ibm.com
phone: +31-348-432-794
Co-editor: Randy Presuhn
BMC Software, Inc
postal: 1190 Saratoga Avenue, Suite 130
San Jose, CA 95129-3433
USA
email: rpresuhn@bmc.com
phone: +1-408-556-0720
Co-editor: Keith McCloghrie
Cisco Systems, Inc.
postal: 170 West Tasman Drive
San Jose, CA 95134-1706
USA
email: kzm@cisco.com
phone: +1-408-526-5260
7. Acknowledgements
This document describes the work of the SNMP Security and
Administrative Framework Evolution team, comprised of
David Harrington (Cabletron Systems Inc.)
Jeff Johnson (Cisco)
David Levi (SNMP Research Inc.)
John Linn (Openvision)
Russ Mundy (Trusted Information Systems) chair
Shawn Routhier (Epilogue)
Glenn Waters (Nortel)
Bert Wijnen (IBM T. J. Watson Research)
Wijnen/Presuhn/McCloghrie Expires December 1997 [Page 29]
^L
Draft View-based Access Control Model (ACM) for SNMP July 1997
8. References
[RFC1902] The SNMPv2 Working Group, Case, J., McCloghrie, K.,
Rose, M., and S., Waldbusser, "Structure of Management
Information for Version 2 of the Simple Network Management
Protocol (SNMPv2)", RFC 1905, January 1996.
[RFC1905] The SNMPv2 Working Group, Case, J., McCloghrie, K.,
Rose, M., and S., Waldbusser, "Protocol Operations for
Version 2 of the Simple Network Management Protocol (SNMPv2)",
RFC 1905, January 1996.
[RFC1906] The SNMPv2 Working Group, Case, J., McCloghrie, K.,
Rose, M., and S. Waldbusser, "Transport Mappings for
Version 2 of the Simple Network Management Protocol (SNMPv2)",
RFC 1906, January 1996.
[RFC1907] The SNMPv2 Working Group, Case, J., McCloghrie, K.,
Rose, M., and S. Waldbusser, "Management Information Base for
Version 2 of the Simple Network Management Protocol (SNMPv2)",
RFC 1907, January 1996.
[RFC1908] The SNMPv2 Working Group, Case, J., McCloghrie, K.,
Rose, M., and S. Waldbusser, "Coexistence between Version 1
and Version 2 of the Internet-standard Network Management
Framework", RFC 1908, January 1996.
[RFC2119] Network Working Group, Bradner, S., "Key words for use in
RFCs to Indicate Requirement Levels", RFC 2119, March 1997.
[SNMP-ARCH] The SNMPv3 Working Group, Harrington, D., Wijnen, B.,
"An Architecture for describing Internet Management Frameworks",
draft-ietf-snmpv3-next-gen-arch-02.txt, June 1997.
[SNMPv3-MPC] The SNMPv3 Working Group, Wijnen, B., Harrington, D.,
"Message Processing and Control Model for version 3 of the Simple
Network Management Protocol (SNMPv3)",
draft-ietf-snmpv3-mpc-00.txt, July 1997.
[SNMPv3-USM] The SNMPv3 Working Group, Blumenthal, U., Wijnen, B.,
"The User-Based Security Model for Version 3 of the Simple
Network Management Protocol (SNMPv3)",
draft-ietf-snmpv3-usm-00.txt, July 1997.
[ISO-ASN.1] Information processing systems - Open Systems
Interconnection - Specification of Abstract Syntax Notation One
(ASN.1), International Organization for Standardization.
International Standard 8824, (December, 1987).
Wijnen/Presuhn/McCloghrie Expires December 1997 [Page 30]
^L
Draft View-based Access Control Model (ACM) for SNMP July 1997
APPENDIX A - Installation
A.1. Installation Parameters
During installation, an authoritative SNMP engine SHOULD (in the
meaning as defined in [RFC2119]) be configured with several initial
parameters. These include for the View-based Access Control Model:
1) A security posture
The choice of security posture determines if initial configuration
is implemented and if so how. One of three possible choices
is selected:
minimum-secure,
semi-secure,
very-secure (i.e. no-initial-configuration)
In the case of a very-secure posture, there is no initial
configuration, and so the following steps are irrelevant.
2) A default context
One entry in the acmContextTable with a contextName of "" (the
empty string), representing the default context. Note that this
table gets created automatically if a default context exists.
no privacy support privacy support
------------------ ---------------
acmContextName "" ""
3) An initial group
One entry in the acmSecurityToGroupTable to allow access to group
"initial".
no privacy support privacy support
------------------ ---------------
acmSecurityModel 3 (USM) 3 (USM)
acmSecurityName "initial" "initial"
acmGroupName "initial" "initial"
acmSecurityToGroupStorageType anyValidStorageType anyValidStorageType
acmSecurityToGroupStatus active active
4) An initial acmGroupListTable
Those columns marked with (index) are index-only objects and are
not really present in this table. Note that this table gets created
automatically because of the configuration of the initial group.
One entry in the acmGroupListTable as follows:
Wijnen/Presuhn/McCloghrie Expires December 1997 [Page 31]
Draft View-based Access Control Model (ACM) for SNMP July 1997
no privacy support privacy support
------------------ ---------------
acmGroupName (index) "initial" "initial"
acmSecurityModel (index) 3 (USM) 3 (USM)
acmSecurityName (index) "initial" "initial"
acmGroupListStatus active active
5) Initial access rights
Three entries in the acmAccessTable as follows:
- read-notify access for securityModel USM, LoS "noAuthNoPriv"
on behalf of securityNames that belong to the group "initial" to
the <restricted> MIB view in the context with contextName "".
- read-write-notify access for securityModel USM, LoS "authNoPriv"
on behalf of securityNames that belong to the group "initial" to
the <all> MIB view in the context with contextName "".
- if privacy is supported,
read-write-notify access for securityModel USM for LoS "authPriv"
on behalf of securityNames that belong to the group "initial" to
the <all> MIB view in the context with contextName "".
That translates into the following entries in the acmAccessTable.
Those columns marked with (index) are index-only objects and are
not really present in this table at all.
- One entry to be used for unauthenticated access (noAuthNoPriv):
no privacy support privacy support
------------------ ---------------
acmAccessContextPrefix "" ""
acmGroupName (index) "initial" "initial"
acmSecurityModel (index) 3 (USM) 3 (USM)
acmAccessLoS noAuthNoPriv noAuthNoPriv
acmAccessReadViewName "restricted" "restricted"
acmAccessWriteViewName "" ""
acmAccessNotifyViewName "restricted" "restricted"
acmAccessStorageType anyValidStorageType anyValidStorageType
acmAccessStatus active active
- One entry to be used for authenticated access but without
privacy (authNoPriv):
no privacy support privacy support
------------------ ---------------
acmAccessContextPrefix "" ""
acmGroupName (index) "initial" "initial"
acmSecurityModel (index) 3 (USM) 3 (USM)
Wijnen/Presuhn/McCloghrie Expires December 1997 [Page 32]
Draft View-based Access Control Model (ACM) for SNMP July 1997
acmAccessLoS authNoPriv authNoPriv
acmAccessReadViewName "all-iso" "all-iso"
acmAccessWriteViewName "all-iso" "all-iso"
acmAccessNotifyViewName "all-iso" "all-iso"
acmAccessStorageType anyValidStorageType anyValidStorageType
acmAccessStatus active active
- One entry to be used for authenticated access with privacy
(authPriv):
no privacy support privacy support
------------------ ---------------
acmAccessContextPrefix ""
acmGroupName (index) "initial"
acmSecurityModel (index) 3 (USM)
acmAccessLoS authPriv
acmAccessReadViewName "all-iso"
acmAccessWriteViewName "all-iso"
acmAccessNotifyViewName "all-iso"
acmAccessStorageType anyValidStorageType
acmAccessStatus active
Note however, that this last entry is also covered by the
entry that allows authNoPriv access because the authPriv access
is a better LoS than the authNoPriv.
6) Two MIB views depending on the security posture.
- One view (the <all-iso> view) for authenticated access:
- the <all-iso> MIB view is the following subtree:
"iso" (subtree 1)
- A second view (the <restricted> view) for unauthenticated
access. This view is configured according to the selected
security posture:
- For the "very-secure" posture there is no default initial
configuration, so no MIB views are pre-scribed.
- For the "semi-secure" posture:
the <restricted> MIB view is the union of these subtrees:
(a) "system" (subtree 1.3.6.1.2.1.1) [RFC1907]
(b) "snmp" (subtree 1.3.6.1.2.1.11) [RFC1907]
(c) "snmpEngine" (subtree 1.3.6.1.6.3.7.2.1) [SNMP-ARCH]
(d) "snmpV3Stats" (subtree 1.3.6.1.6.3.8.2.1) [SNMPv3-MPC]
(e) "usmStats" (subtree 1.3.6.1.6.3.9.2.1) [SNMPv3-USM]
- For the "minimum-secure" posture:
Wijnen/Presuhn/McCloghrie Expires December 1997 [Page 33]
Draft View-based Access Control Model (ACM) for SNMP July 1997
the <restricted> MIB view is the following subtree.
"iso" (subtree 1)
This translates into the following "all-iso" entry in the
acmViewTreeFamilyTable:
minimum-secure semi-secure
---------------- ---------------
acmViewTreeFamilyViewName "all-iso" "all-iso"
acmViewTreeFamilySubtree 1 1
acmViewTreeFamilyMask "" ""
acmViewTreeFamilyType 1 (included) 1 (included)
acmViewTreeFamilyStorageType anyValidStorageType anyValidStorageType
acmViewTreeFamilyStatus active active
This translates into the following "restricted" entries in the
acmViewTreeFamilyTable:
minimum-secure semi-secure
---------------- ---------------
acmViewTreeFamilyViewName "restricted" "restricted"
acmViewTreeFamilySubtree 1 1.3.6.1.2.1.1
acmViewTreeFamilyMask " " ""
acmViewTreeFamilyType 1 (included) 1 (included)
acmViewTreeFamilyStorageType anyValidStorageType anyValidStorageType
acmViewTreeFamilyStatus active active
acmViewTreeFamilyViewName "restricted"
acmViewTreeFamilySubtree 1.3.6.1.2.1.11
acmViewTreeFamilyMask ""
acmViewTreeFamilyType 1 (included)
acmViewTreeFamilyStorageType anyValidStorageType
acmViewTreeFamilyStatus active
acmViewTreeFamilyViewName "restricted"
acmViewTreeFamilySubtree 1.3.6.1.6.3.7.2.1
acmViewTreeFamilyMask ""
acmViewTreeFamilyType 1 (included)
acmViewTreeFamilyStorageType anyValidStorageType
acmViewTreeFamilyStatus active
acmViewTreeFamilyViewName "restricted"
acmViewTreeFamilySubtree 1.3.6.1.6.3.8.2.1
acmViewTreeFamilyMask ""
acmViewTreeFamilyType 1 (included)
acmViewTreeFamilyStorageType anyValidStorageType
acmViewTreeFamilyStatus active
acmViewTreeFamilyViewName "restricted"
acmViewTreeFamilySubtree 1.3.6.1.6.3.9.2.1
acmViewTreeFamilyMask ""
Wijnen/Presuhn/McCloghrie Expires December 1997 [Page 34]
Draft View-based Access Control Model (ACM) for SNMP July 1997
acmViewTreeFamilyType 1 (included)
acmViewTreeFamilyStorageType anyValidStorageType
acmViewTreeFamilyStatus active
Wijnen/Presuhn/McCloghrie Expires December 1997 [Page 35]
Draft View-based Access Control Model (ACM) for SNMP July 1997
Table of Contents
0. Issues and Change Log 2
0.1. Issues 2
0.2. Change Log 2
1. Introduction 4
1.2. Access Control 4
1.3. Local Configuration Datastore 5
2. Elements of the Model 6
2.1. groupName 6
2.2. Level of Security (LoS) 6
2.3. Contexts 6
2.4. MIB Views and View Families 7
2.4.1. View Subtree 7
2.4.2. ViewTreeFamily 7
2.5. Access Policy 8
3. Elements of Procedure 9
3.1 Processing the isAccessAllowed Service Request 10
4. Definitions 12
5. Security Considerations 28
5.1. Recommended Practices 28
5.2. Defining Groups 28
5.3. Conformance 28
6. Editor's Addresses 29
7. Acknowledgements 29
8. References 30
A.1. Installation Parameters 31
Wijnen/Presuhn/McCloghrie Expires December 1997 [Page 36]
