Internet DRAFT - draft-ietf-snmpv2-control-mib
draft-ietf-snmpv2-control-mib
HTTP/1.1 200 OK
Date: Tue, 09 Apr 2002 08:19:01 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Tue, 08 Aug 1995 22:00:00 GMT
ETag: "323a93-67c4-3027de60"
Accept-Ranges: bytes
Content-Length: 26564
Connection: close
Content-Type: text/plain
Internet Draft Access Control MIB for SNMPv2 Aug 1995
Access Control MIB
for Version 2 of the
Simple Network Management Protocol (SNMPv2)
1 Aug 1995
draft-ietf-snmpv2-control-mib-00.txt
David Harrington
Cabletron Systems, Inc.
dbh@ctron.com
Sandeep Asija
Cabletron Systems, Inc.
asija@ctron.com
Daniel O. Mahoney II
Cabletron Systems, Inc.
dmahoney@ctron.com
David Arneson
Cabletron Systems, Inc.
arneson@ctron.com
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 and defines a portion of the Management Information
Base (MIB) for use with the Simple Network Management Protocol version 2.
In particular, it defines objects for specifying access to data and protocol
operations for specified security entities. The method of applying access
control is dependent on the security model in use, but the specification of
access policy is security model independent.
Expires January 1996 [Page 1]
Internet Draft Access Control MIB for SNMPv2 Aug 1995
1. Introduction
A management system contains: several (potentially many) nodes, each
with a processing entity, termed an agent, which has access to
management instrumentation; at least one management station; and, a
management protocol, used to convey management information between the
agents and management stations. Operations of the protocol are carried
out under an administrative framework which defines authentication,
authorization, access control, and privacy policies.
Management stations execute management applications which monitor and
control managed elements. Managed elements are devices such as hosts,
routers, terminal servers, etc., which are monitored and controlled via
access to their management information.
Management information is viewed as a collection of managed objects,
residing in a virtual information store, termed the Management
Information Base (MIB). Collections of related objects are defined in
MIB modules. These modules are written using a subset of OSI's Abstract
Syntax Notation One (ASN.1) [1], termed the Structure of Management
Information (SMI) [2].
The model described here is largely derived from the work of the SNMPv2
Working Group, as published in RFC1445 and RFC1447, and subsequent internet
drafts. The administrative model described in those RFCs and drafts was
determined to be inappropriate for some users, especially the required
security framework.
It is the purpose of this document, the Access Control MIB for SNMPv2, to
define how access control entries can be applied to realize effective
control of managed data in a variety of configurations and environments in
a model which can be used with a variety of security frameworks, commonly
referred to as admin models.
It is the purpose of this document to define the properties associated with
SNMPv2 access control filters, and to define managed objects which correspond
to those properties, and to do so without dependence on a specific security
or admin model.
1.1 Acknowledgements
Much of this document was taken directly from the draft of the SNMPv2
Working Group published draft, draft-ietf-snmpv2-party-ds-02.txt, authored
by Jeffrey D. Case, James Galvin, Keith McCloghrie, Marshall T. Rose, and
Steven Waldbusser.
The authors wish to acknowledge the contributions of the SNMPv2 Working
Group in general.
Harrington [Page 2]
Internet Draft Access Control MIB for SNMPv2 Aug 1995
1.2. A Note on Terminology
For the purpose of exposition, the original Internet-standard Network
Management Framework, as described in RFCs 1155, 1157, and 1212, is
termed the SNMP version 1 framework (SNMPv1). The current framework is
termed the SNMP version 2 framework (SNMPv2).
2. Overview
For security reasons, it is valuable to restrict the operations
allowed on the management information within a particular context for
a particular security entity or entities. For example, one management
application might be allowed to only read the values of objects, another
may be allowed to modify the values of some objects, a third may be
authorized to send informs to another manager, and a fourth may be
authorized to be sent a notification (trap) in response to unusual events.
2.1. Authorization: Access Control
An SNMPv2 message is associated with a datafilter and may be associated
with zero or more security entities. The datafilter determines the set
of management information being accessed by the message, and the security
entities are used for applying access control policies.
Access control is specified as a set of local access entries, where each
entry is a combination of datafilter and security entities against which
to compare a received message. The method of specifying and comparing the
security entities is dependent on the admin model.
Each access control entry specifies the set of operations which are allowed
to be performed on the data by the security entities. If the datafilter or
the security entities specified by the received message are not a valid
combination, or the operation requested is not one of the operations allowed
for the combination, then the requested access is denied.
2.2. SNMPv2 Access Control Policy
An SNMPv2 access control policy is a specification of zero or more security
entities and a local datafilter. The access policy specifies the
authorized types of SNMPv2 operations for the security entities when
accessing the objects contained in the management information subset
specified by the context and MIB views referenced by the datafilter.
Each such access control entry, called an ACL (for historical reasons),
includes the following attributes:
accDataFilterIdentity -
the datafilterIdentity which identifies the management information
subset on which requested management operations are to be performed,
including which context contains the information, and which views
are authorized for read-based or write-based operations.
accSecurityModel -
the security model to use to interpret accSecurityIdentity
Harrington [Page 3]
Internet Draft Access Control MIB for SNMPv2 Aug 1995
accSecurityIdentity -
An admin-model specific formatted octet string containing information
required to determine the security entities against which to apply
access control policy. The interpretation of this octet string is
defined by the admin model.
accPrivileges -
the types of SNMPv2 operations on the particular data subset that are
authorized for SNMPv2 messages for the specified security entities.
An SNMPv2 entity's LCD includes information on all ACLs containing local
access control policies. An SNMPv2 manager may also include remote ACLs
in its LCD in order to determine which operations are authorized by
particular security entities for a particular remote context.
The application of SNMPv2 access control policy is performed:
o on receipt of GetRequest, GetNextRequest, GetBulkRequest, and
SetRequest operations; and
o prior to transmission of SNMPv2-Trap and Inform operations (the
procedures by which this access-control is performed are specified
in [3], and in the protocol documents for the selected security model).
Note that application of SNMPv2 access control policy is never performed
for Response nor Report operations.
2.3. Maintenance Function ACL
An ACL entry for use with maintenance functions shall be defined
by the admin model, if the admin model requires the use of maintenance
functions.
3. Definitions
SNMPv2-ACCESS-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, snmpModules
FROM SNMPv2-SMI
TEXTUAL-CONVENTION, RowStatus, StorageType
FROM SNMPv2-TC
MODULE-COMPLIANCE, OBJECT-GROUP
FROM SNMPv2-CONF;
Harrington [Page 4]
Internet Draft Access Control MIB for SNMPv2 Aug 1995
accessMIB MODULE-IDENTITY
LAST-UPDATED "9503190000Z"
ORGANIZATION "IETF SNMPv2 Working Group"
CONTACT-INFO
" David Harrington
Postal: Cabletron Systems Inc.
ATTN: David Harrington
Engineering - Durham
P.O. Box 5005
Rochester NH 03866-5005
USA
Phone: +1 603 337 7357
Email: dbh@ctron.com"
DESCRIPTION
"The MIB module describing SNMPv2 access control structures."
REVISION "9508010000Z"
DESCRIPTION
"The initial revision of the MIB module from which this is
derived was published as RFC 1447."
::= { snmpModules xxxx }
-- textual conventions
AccessPrivileges ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"A set of access privileges which specify the authorized set
of management operations permitted on the associated
management information.
These privileges are specified as a sum of values, where
each value specifies a SNMPv2 PDU type by which an operation
may be requested. The value for a particular PDU type is
computed as 2 raised to the value of the ASN.1 context-specific
tag for the appropriate SNMPv2 PDU type. The values (for the
tags defined in [3]) are:
Get : 1
GetNext : 2
(unused : 4)
Set : 8
(unused : 16)
GetBulk : 32
Inform : 64
SNMPv2-Trap : 128
The null set is represented by the value zero."
SYNTAX INTEGER (0..255)
Harrington [Page 5]
Internet Draft Access Control MIB for SNMPv2 Aug 1995
-- administrative assignments
accessAdmin OBJECT IDENTIFIER ::= { accessMIB 1 }
-- object assignments
accessMIBObjects
OBJECT IDENTIFIER ::= { accessMIB 2 }
-- SNMPv2 access privileges
snmpAccess OBJECT IDENTIFIER ::= { accessMIBObjects 3 }
accTable OBJECT-TYPE
SYNTAX SEQUENCE OF AccEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The access privileges database."
::= { snmpAccess 2 }
accEntry OBJECT-TYPE
SYNTAX AccEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Each conceptual row in this table represents an individual
access policy, called an ACL (for historical reasons).
An ACL specifies the access privileges authorized for
communication via accSecurityIdentity concerning information
delimited by a particular SNMPv2 datafilter.
For each conceptual row in this table which is retained
across a re-initialization of the entity's network management
system, the combination of the accSecurityIdentity values of
the referenced entities and the accDataFilterIdentity value of
the referenced data must be the same after the re-initialization
as it was before the re-initialization, even if the values of
accSecurityIdentity and accDataFilterIdentity vary."
INDEX { accDataFilterIdentity, accSecurityModel, accSecurityIdentity }
::= { accTable 1 }
Harrington [Page 6]
Internet Draft Access Control MIB for SNMPv2 Aug 1995
AccEntry ::=
SEQUENCE {
accDataFilterIdentity OBJECT IDENTIFIER,
accSecurityModel INTEGER,
accSecurityIdentity OCTET STRING,
accPrivileges AccessPrivileges,
accStorageType StorageType,
accStatus RowStatus
}
accDataFilterIdentity OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The value of this instance identifies the SNMPv2 datafilter
associated with a particular set of access privileges."
::= { accEntry 1 }
accSecurityModel OBJECT-TYPE
SYNTAX INTEGER (0..65535)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The security model to use to interpret accSecurityIdentity."
::= { accEntry 2 }
accSecurityIdentity OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..128))
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Admin-model specific information for identifying a security
entity or entities for which access control will be applied
relative to the data described by the accDataFilterIdentity.
The format of accSecurityIdentity and the interpretation
of the value of accSecurityIdentity shall be specified by the
admin model identified in accSecurityModel."
::= { accEntry 4 }
accPrivileges OBJECT-TYPE
SYNTAX AccessPrivileges
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The access privileges authorized for communication concerning
the managed information contained in the particular subset of
SNMPv2 data identified by accDataFilterIdentity."
DEFVAL { 35 } -- Get, Get-Next & Get-Bulk
::= { accEntry 5 }
Harrington [Page 7]
Internet Draft Access Control MIB for SNMPv2 Aug 1995
accStorageType OBJECT-TYPE
SYNTAX StorageType
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The storage type for this conceptual row in the accTable.
Conceptual rows having the value 'permanent' need not allow
write-access to any columnar objects in the row."
DEFVAL { nonVolatile }
::= { accEntry 6 }
accStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The status of this conceptual row in the accTable.
For those columnar objects which permit write-access, their
value in an existing conceptual row can be changed
irrespective of the value of accStatus for that row.
A conceptual row in this table is not qualified for
activation until the context it references is active.
A conceptual row in this table is immediately made notInService
whenever the status of the context it references is made
notInService. A conceptual row in this table is immediately
destroyed whenever the context it references is destroyed.
A conceptual row in this table is not qualified for
activation until the security entities it references are
active. A conceptual row in this table is immediately made
notInService whenever the status of the security entities it
references are made notInService. A conceptual row in this table
is immediately destroyed whenever the security entities it
references are destroyed."
::= { accEntry 7 }
-- conformance information
accessMIBConformance
OBJECT IDENTIFIER ::= { accessMIB 3 }
accessMIBCompliances
OBJECT IDENTIFIER ::= { accessMIBConformance 1 }
accessMIBGroups
OBJECT IDENTIFIER ::= { accessMIBConformance 2 }
Harrington [Page 8]
Internet Draft Access Control MIB for SNMPv2 Aug 1995
-- compliance statements
accessCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for SNMPv2 entities which
implement the Access MIB."
MODULE -- this module
MANDATORY-GROUPS { accessMIBGroup }
::= { accessMIBCompliances 1 }
-- units of conformance
accessMIBGroup OBJECT-GROUP
OBJECTS { accSecurityIdentity, accPrivileges, accStorageType, accStatus }
STATUS current
DESCRIPTION
"The collection of objects allowing the description and
configuration of SNMPv2 access control entries."
::= { accessMIBGroups 1 }
4. Usage Examples
4.1. Party-based Security Model Agent Configuration
This section presents an example configuration for a SNMPv2 agent using
a party-based security model. Table 1 presents information about the local
access policy known by the agent and by the manager.
accEntry:
SecurityModel: <999>
SecurityIdentity: <gracie><george>
DataFilterIdentity: df_device5
Privileges: Get/GetNext/GetBulk/SNMPv2-Trap
DataFilter:
Context: device5
ReadView: all
WriteView: empty
Table 1: Access Information for a sample party-based model
Suppose that the SNMPv2 manager wishes to interrogate management information
about the SNMPv2 datafilter named "df_device5", by issuing an SNMPv2 GetNext
request message. The manager consults its LCD to discover that
management information for datafilter "df_device5" is available using
security model #999, using an agent party named gracie, and managing party
george to access that datafilter.
Harrington [Page 9]
Internet Draft Access Control MIB for SNMPv2 Aug 1995
The manager assembles, serializes, and transmits the request according to
security model. The agent receives the message, and processes the security
according to the requirements of the security model.
The received message is processed only if the agent's access control method
for security model #999 authorizes GetNext request operations by the
specified security entities with respect to the datafilter "df_device5".
During the processing of the received request, each specified item of
management information is accessed only as authorized by the relevant
MIB view.
4.2. User-based Security Model Agent Configuration
This section presents an example configuration for a SNMPv2 agent using
a user-based security model. Table 2 presents information about the local
access policy known by the agent and by the manager.
accEntry:
SecurityModel: <300>
SecurityIdentity: <ollie>
DataFilterIdentity: df_device5
Privileges: Get/GetNext/GetBulk/Set/SNMPv2-Trap
DataFilter:
Context: device5
ReadView: all
WriteView: 17
Table 2: User-based Security Model Access Information
Suppose that the SNMPv2 manager wishes to modify management information
in the SNMPv2 datafilter named "df_device5", by issuing an SNMPv2 Set
request message. The manager consults its LCD to discover that management
information for datafilter "df_device5" is writable through the agent's user
named ollie operating under security model #300 to access that datafilter.
If the manager chooses to maintain a copy of remote views in its LCD, it
can verify that the objects to be written are within the constraints of the
remote view #17 within context "device5" before proceeding.
The manager assembles, serializes, and transmits the request according to
security model. The agent receives the message, and processes the security
according to the requirements of the security model.
The received message is processed only if the agent's access control method
for security model #300 authorizes Set request operations by user "ollie"
with respect to the datafilter "df_device5". During the processing of the
received request, each specified item of management information is accessed
only as authorized by the relevant MIB view.
Harrington [Page 10]
Internet Draft Access Control MIB for SNMPv2 Aug 1995
4.3. Community-based Security Model Agent Configuration
This section presents an example configuration for a SNMPv2 agent using
a community-based authentication model [4]. Table 3 presents information
about the local access policy known by the agent and by the manager.
accEntry:
SecurityModel: <123>
SecurityIdentity: <private>
DataFilterIdentity: df_device5
Privileges: Get/GetNext/GetBulk/Set/SNMPv2-Trap
DataFilter:
Context: "private"
ReadView: all
WriteView: all
Table 3: Community-based Security Model Access Information
Suppose that the SNMPv2 manager wishes to modify management information
in the SNMPv2 datafilter named "df_device5", by issuing an SNMPv2 Set
request message. The manager consults its LCD to discover that management
information for datafilter "df_device5" is writable through the agent's
community string "private" under security model #123 to access that datafilter.
The manager assembles, serializes, and transmits the request according to
security model. The agent receives the message, and processes the security
according to the requirements of the security model.
The received message is processed only if the agent's access control method
for security model #123 authorizes Set request operations by community
"private" with respect to the datafilter "df_device5". During the processing
of the received request, each specified item of management information is
accessed only as authorized by the relevant MIB view.
5. References
[1] Information processing systems - Open Systems Interconnection
Specification of Abstract Syntax Notation One (ASN.1),
International Organization for Standardization. International
Standard 8824, (December, 1987).
[2] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Structure
of Management Information for Version 2 of the Simple Network
Management Protocol (SNMPv2)", Internet Draft, SNMP Research, Inc.,
Cisco Systems, Dover Beach Consulting, Inc., Carnegie Mellon
University, May 1995.
Harrington [Page 11]
Internet Draft Access Control MIB for SNMPv2 Aug 1995
[3] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Protocol
Operations for Version 2 of the Simple Network Management Protocol
(SNMPv2)", Internet Draft, SNMP Research, Inc., Cisco Systems,
Dover Beach Consulting, Inc., Carnegie Mellon University, May 1995.
[4] Case, J., Fedor, M., Schoffstall, M., Davin, J., "Simple Network
Management Protocol", STD 15, RFC 1157, SNMP Research, Performance
Systems International, MIT Laboratory for Computer Science, May
1990.
6. Security Considerations
In order to participate in the administrative model set forth in this
memo, SNMPv2 implementations must support local, non-volatile storage of
the LCD. Accordingly, every attempt has been made to minimize the
amount of non-volatile storage required.
7. Authors' Addresses
Daniel O. Mahoney II
Cabletron Systems, Inc.
ATTN: Dan Mahoney
Engineering - Durham
P.O. Box 5005
Rochester NH 03866-5005
US
Phone: +1 603 337 7355
Email: dmahoney@ctron.com
Sandeep Asija
Cabletron Systems, Inc.
ATTN: Sandeep Asija
Engineering - Durham
P.O. Box 5005
Rochester NH 03866-5005
US
Phone: +1 603 337 7185
Email: asija@ctron.com
David Harrington
Cabletron Systems, Inc.
ATTN: David Harrington
Engineering - Durham
P.O. Box 5005
Rochester NH 03866-5005
US
Harrington [Page 12]
Internet Draft Access Control MIB for SNMPv2 Aug 1995
Phone: +1 603 337 7357
Email: dbh@ctron.com
David Arneson
Cabletron Systems, Inc.
ATTN: David Arneson
Engineering - Merrimack
P.O. Box 5005
Rochester NH 03866-5005
US
Phone: +1 603 337 5238
Email: arneson@ctron.com
Harrington [Page 13]
Internet Draft Access Control MIB for SNMPv2 Aug 1995
Table of Contents
1 Introduction .................................................... 2
1.1 Acknowledgements .............................................. 2
1.2 A Note on Terminology ......................................... 3
2 Overview ........................................................ 3
2.1 Authorization ................................................. 3
2.2 SNMPv2 Access Control Policy .................................. 4
2.3 Maintenance Function ACL ...................................... 4
3 Definitions ..................................................... 4
4 Usage Examples .................................................. 9
4.1 Party-based Security Model Agent Configuration ................ 9
4.2 User-based Security Model Agent Configuration ................. 10
4.3 Community-based Security Model Agent Configuration ............ 11
5 References ...................................................... 11
6 Security Considerations ......................................... 12
7 Authors' Addresses .............................................. 12
Expires January 1996 [Page 14]
