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

Versions: 00

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]


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