Network Working Group K. McCloghrie
Request for Comments: 1353 Hughes LAN Systems, Inc.
J. Davin
MIT Laboratory for Computer Science
J. Galvin
Trusted Information Systems, Inc.
July 1992
Definitions of Managed Objects
for Administration of SNMP Parties
Status of this Memo
This document specifies an IAB standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "IAB
Official Protocol Standards" for the standardization state and status
of this protocol. Distribution of this memo is unlimited.
Abstract
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in TCP/IP-based internets.
In particular, it describes a representation of the SNMP parties
defined in [8] as objects defined according to the Internet Standard
SMI [1]. These definitions are consistent with the SNMP Security
protocols set forth in [9].
Table of Contents
1. The Network Management Framework ........................... 2
2. Objects .................................................... 2
2.1 Format of Definitions ..................................... 3
3. Overview ................................................... 3
3.1 Structure ................................................. 3
3.2 Instance Identifiers ...................................... 3
3.3 Textual Conventions ....................................... 4
4. Definitions ................................................ 4
4.1 The SNMP Party Public Database Group ...................... 9
4.2 The SNMP Party Secrets Database Group ..................... 15
4.3 The SNMP Access Privileges Database Group ................. 18
4.4 The MIB View Database Group ............................... 21
5. Acknowledgments ............................................ 25
6. References ................................................. 25
7. Security Considerations..................................... 26
8. Authors' Addresses.......................................... 26
McCloghrie, Davin, & Galvin [Page 1]
RFC 1353 SNMP Party MIB July 1992
the Internet-standard Network Management Framework consists of three
components. They are:
RFC 1155 which defines the SMI, the mechanisms used for describing
and naming objects for the purpose of management. RFC 1212
defines a more concise description mechanism, which is wholly
consistent with the SMI.
RFC 1156 which defines MIB-I, the core set of managed objects for
the Internet suite of protocols. RFC 1213, defines MIB-II, an
evolution of MIB-I based on implementation experience and new
operational requirements.
RFC 1157 which defines the SNMP, the protocol used for network
access to managed objects.
The Framework permits new objects to be defined for the purpose of
experimentation and evaluation.
Managed objects are accessed via a virtual information store, termed
the Management Information Base or MIB. Objects in the MIB are
defined using the subset of Abstract Syntax Notation One (ASN.1) [5]
defined in the SMI. In particular, each object has a name, a syntax,
and an encoding. The name is an object identifier, an
administratively assigned name, which specifies an object type. The
object type together with an object instance serves to uniquely
identify a specific instantiation of the object. For human
convenience, we often use a textual string, termed the OBJECT
DESCRIPTOR, to also refer to the object type.
The syntax of an object type defines the abstract data structure
corresponding to that object type. The ASN.1 language is used for
this purpose. However, the SMI [1] purposely restricts the ASN.1
constructs which may be used. These restrictions are explicitly made
for simplicity.
The encoding of an object type is simply how that object type is
represented using the object type's syntax. Implicitly tied to the
notion of an object type's syntax and encoding is how the object type
is represented when being transmitted on the network.
The SMI specifies the use of the basic encoding rules of ASN.1 [6],
subject to the additional requirements imposed by the SNMP.
McCloghrie, Davin, & Galvin [Page 2]
RFC 1353 SNMP Party MIB July 1992
Section 4 contains the specification of all object types contained in
this MIB module. The object types are defined using the conventions
defined in the SMI, as amended by the extensions specified in [7].
This MIB contains the definitions for four tables, a number of OBJECT
IDENTIFIER assignments, and some conventions for initial use with
some of the assignments. The four tables are the SNMP Party Public
database, the SNMP Party Secrets database, the SNMP Access Control
database, and the SNMP Views database.
The SNMP Party Public database and the SNMP Party Secrets database
are defined as separate tables specifically for the purpose of
positioning them in different parts of the MIB tree namespace. In
particular, the SNMP Party Secrets database contains secret
information, for which security demands that access to it be limited
to parties which use both authentication and privacy. It is
therefore positioned in a separate branch of the MIB tree so as to
provide for the easiest means of accommodating the required
limitation.
In contrast, the SNMP Party Public database contains public
information about SNMP parties. In particular, it contains the
parties' clocks which need to be read-able (but not write-able) by
unauthenticated queries, since an unauthenticated query of a party's
clock is the first step of the procedure to re-establish clock
synchronization (see [9]).
The objects in this MIB are organized into four groups. All four of
the groups are mandatory for those SNMP implementations that realize
the security framework and mechanisms defined in [8] and [9].
In all four of the tables in this MIB, the object instances are
identified by values which have an underlying syntax of OBJECT
IDENTIFIER. For the Party Public database and the Party Secrets
database, the index variable is the party identifier. For the Access
Control database and the Views database, two index variables are
defined, both of which have a syntax of OBJECT IDENTIFIER. (See the
INDEX clauses in the MIB definitions below for the specific
variables.)
McCloghrie, Davin, & Galvin [Page 3]
RFC 1353 SNMP Party MIB July 1992
According to RFC 1212 [7], section 4.1.6, the syntax of the object(s)
specified in an INDEX clause indicates how to form the instance-
identifier. In particular, for each index object which is object
identifier-valued, its contribution to the instance identifier is:
`n+1' sub-identifiers, where `n' is the number of sub-identifiers
in the value (the first sub-identifier is `n' itself, following
this, each sub-identifier in the value is copied).
The datatypes, Party, Clock, and TAddress, are used as textual
conventions in this document. These textual conventions have NO
effect on either the syntax nor the semantics of any managed object.
Objects defined using these conventions are always encoded by means
of the rules that define their primitive type. Hence, no changes to
the SMI or the SNMP are necessary to accommodate these textual
conventions which are adopted merely for the convenience of readers.
RFC1353-MIB DEFINITIONS ::= BEGIN
IMPORTS
system, mib, private, internet FROM RFC1155-SMI
OBJECT-TYPE FROM RFC-1212;
snmpParties OBJECT IDENTIFIER ::= { mib-2 20 }
partyAdmin OBJECT IDENTIFIER ::= { snmpParties 1 }
partyPublic OBJECT IDENTIFIER ::= { snmpParties 2 }
snmpSecrets OBJECT IDENTIFIER ::= { mib-2 21 }
partyPrivate OBJECT IDENTIFIER ::= { snmpSecrets 1 }
partyAccess OBJECT IDENTIFIER ::= { snmpSecrets 2 }
partyViews OBJECT IDENTIFIER ::= { snmpSecrets 3 }
-- Textual Conventions
-- A textual convention denoting a SNMP party identifier:
Party ::= OBJECT IDENTIFIER
-- A party's authentication clock - a non-negative integer
-- which is incremented as specified/allowed by the party's
-- Authentication Protocol.
-- For noAuth, a party's authentication clock is unused and
McCloghrie, Davin, & Galvin [Page 4]
RFC 1353 SNMP Party MIB July 1992
-- its value is undefined.
-- For md5AuthProtocol, a party's authentication clock is a
-- relative clock with 1-second granularity.
Clock ::= INTEGER (0..2147483647)
-- A textual convention denoting a transport service
-- address.
-- For rfc1351Domain, a TAddress is 6 octets long,
-- the initial 4 octets containing the IP-address in
-- network-byte order and the last 2 containing the
-- UDP port in network-byte order.
TAddress ::= OCTET STRING
--- Definitions of Security Protocols
partyProtocols
OBJECT IDENTIFIER ::= { partyAdmin 1 }
noAuth -- The protocol without authentication
OBJECT IDENTIFIER ::= { partyProtocols 1 }
noPriv -- The protocol without privacy
OBJECT IDENTIFIER ::= { partyProtocols 3 }
desPrivProtocol -- The DES Privacy Protocol
OBJECT IDENTIFIER ::= { partyProtocols 4 }
md5AuthProtocol -- The MD5 Authentication Protocol
OBJECT IDENTIFIER ::= { partyProtocols 5 }
--- definitions of Transport Domains
transportDomains
OBJECT IDENTIFIER ::= { partyAdmin 2 }
rfc1351Domain --- RFC-1351 (SNMP over UDP, using SNMP Parties)
OBJECT IDENTIFIER ::= { transportDomains 1 }
McCloghrie, Davin, & Galvin [Page 5]
RFC 1353 SNMP Party MIB July 1992
--- definitions of Proxy Domains
proxyDomains
OBJECT IDENTIFIER ::= { partyAdmin 3 }
noProxy --- Local operation
OBJECT IDENTIFIER ::= { proxyDomains 1 }
--- Definition of Initial Party Identifiers
-- When devices are installed, they need to be configured
-- with an initial set of SNMP parties. The configuration
-- of SNMP parties requires (among other things) the
-- assignment of several OBJECT IDENTIFIERs. Any local
-- network administration can obtain the delegated
-- authority necessary to assign its own OBJECT
-- IDENTIFIERs. However, to provide for those
-- administrations who have not obtained the necessary
-- authority, this document allocates a branch of the
-- naming tree for use with the following conventions.
initialPartyId
OBJECT IDENTIFIER ::= { partyAdmin 4 }
-- Note these are identified as "initial" party identifiers
-- since these allow secure SNMP communication to proceed,
-- thereby allowing further SNMP parties to be configured
-- through use of the SNMP itself.
-- The following definitions identify a party identifier,
-- and specify the initial values of various object
-- instances indexed by that identifier. In addition,
-- the initial MIB view and access control parameters
-- assigned, by convention, to these parties are identified.
-- Party Identifiers for use as initial SNMP parties
-- at IP address a.b.c.d
-- partyIdentity = { initialPartyId a b c d 1 }
-- partyTDomain = { rfc1351Domain }
-- partyTAddress = a.b.c.d, 161
-- partyProxyFor = { noProxy }
-- partyAuthProtocol = { noAuth }
-- partyAuthClock = 0
-- partySecretsAuthPrivate = ''h (the empty string)
-- partyAuthPublic = ''h (the empty string)
-- partyAuthLifetime = 0
McCloghrie, Davin, & Galvin [Page 6]
RFC 1353 SNMP Party MIB July 1992
-- partyPrivProtocol = { noPriv }
-- partySecretsPrivPrivate = ''h (the empty string)
-- partyPrivPublic = ''h (the empty string)
-- partyIdentity = { initialPartyId a b c d 2 }
-- partyTDomain = { rfc1351Domain }
-- partyTAddress = assigned by local administration
-- partyProxyFor = { noProxy }
-- partyAuthProtocol = { noAuth }
-- partyAuthClock = 0
-- partySecretsAuthPrivate = ''h (the empty string)
-- partyAuthPublic = ''h (the empty string)
-- partyAuthLifetime = 0
-- partyPrivProtocol = { noPriv }
-- partySecretsPrivPrivate = ''h (the empty string)
-- partyPrivPublic = ''h (the empty string)
-- partyIdentity = { initialPartyId a b c d 3 }
-- partyTDomain = { rfc1351Domain }
-- partyTAddress = a.b.c.d, 161
-- partyProxyFor = { noProxy }
-- partyAuthProtocol = { md5AuthProtocol }
-- partyAuthClock = 0
-- partySecretsAuthPrivate = assigned by local administration
-- partyAuthPublic = ''h (the empty string)
-- partyAuthLifetime = 300
-- partyPrivProtocol = { noPriv }
-- partySecretsPrivPrivate = ''h (the empty string)
-- partyPrivPublic = ''h (the empty string)
-- partyIdentity = { initialPartyId a b c d 4 }
-- partyTDomain = { rfc1351Domain }
-- partyTAddress = assigned by local administration
-- partyProxyFor = { noProxy }
-- partyAuthProtocol = { md5AuthProtocol }
-- partyAuthClock = 0
-- partySecretsAuthPrivate = assigned by local administration
-- partyAuthPublic = ''h (the empty string)
-- partyAuthLifetime = 300
-- partyPrivProtocol = { noPriv }
-- partySecretsPrivPrivate = ''h (the empty string)
-- partyPrivPublic = ''h (the empty string)
-- partyIdentity = { initialPartyId a b c d 5 }
-- partyTDomain = { rfc1351Domain }
-- partyTAddress = a.b.c.d, 161
-- partyProxyFor = { noProxy }
-- partyAuthProtocol = { md5AuthProtocol }
McCloghrie, Davin, & Galvin [Page 7]
RFC 1353 SNMP Party MIB July 1992
-- partyAuthClock = 0
-- partySecretsAuthPrivate = assigned by local administration
-- partyAuthPublic = ''h (the empty string)
-- partyAuthLifetime = 300
-- partyPrivProtocol = { desPrivProtocol }
-- partySecretsPrivPrivate = assigned by local administration
-- partyPrivPublic = ''h (the empty string)
-- partyIdentity = { initialPartyId a b c d 6 }
-- partyTDomain = { rfc1351Domain }
-- partyTAddress = assigned by local administration
-- partyProxyFor = { noProxy }
-- partyAuthProtocol = { md5AuthProtocol }
-- partyAuthClock = 0
-- partySecretsAuthPrivate = assigned by local administration
-- partyAuthPublic = ''h (the empty string)
-- partyAuthLifetime = 300
-- partyPrivProtocol = { desPrivProtocol }
-- partySecretsPrivPrivate = assigned by local administration
-- partyPrivPublic = ''h (the empty string)
-- The initial access control parameters assigned, by
-- convention, to these parties are:
-- aclTarget = { initialPartyId a b c d 1 }
-- aclSubject = { initialPartyId a b c d 2 }
-- aclPrivileges = 3 (Get & Get-Next)
-- aclTarget = { initialPartyId a b c d 2 }
-- aclSubject = { initialPartyId a b c d 1 }
-- aclPrivileges = 20 (GetResponse & Trap)
-- aclTarget = { initialPartyId a b c d 3 }
-- aclSubject = { initialPartyId a b c d 4 }
-- aclPrivileges = 11 (Get, Get-Next & Set)
-- aclTarget = { initialPartyId a b c d 4 }
-- aclSubject = { initialPartyId a b c d 3 }
-- aclPrivileges = 20 (GetResponse & Trap)
-- aclTarget = { initialPartyId a b c d 5 }
-- aclSubject = { initialPartyId a b c d 6 }
-- aclPrivileges = 11 (Get, Get-Next & Set)
-- aclTarget = { initialPartyId a b c d 6 }
-- aclSubject = { initialPartyId a b c d 5 }
-- aclPrivileges = 20 (GetResponse & Trap)
McCloghrie, Davin, & Galvin [Page 8]
RFC 1353 SNMP Party MIB July 1992
-- The initial MIB views assigned, by convention, to
-- these parties are:
-- viewParty = { initialPartyId a b c d 1 }
-- viewSubtree = { system }
-- viewStatus = { included }
-- viewMask = { ''h }
-- viewParty = { initialPartyId a b c d 1 }
-- viewSubtree = { snmpParties }
-- viewStatus = { included }
-- viewMask = { ''h }
-- viewParty = { initialPartyId a b c d 3 }
-- viewSubtree = { internet }
-- viewStatus = { included }
-- viewMask = { ''h }
-- viewParty = { initialPartyId a b c d 3 }
-- viewSubtree = { partyPrivate }
-- viewStatus = { excluded }
-- viewMask = { ''h }
-- viewParty = { initialPartyId a b c d 5 }
-- viewSubtree = { internet }
-- viewStatus = { included }
-- viewMask = { ''h }
-- The SNMP Party Public Database Group
--
-- The non-secret party information.
--
-- Implementation of the objects in this group is mandatory.
partyTable OBJECT-TYPE
SYNTAX SEQUENCE OF PartyEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"The SNMP Party Public database.
An agent must ensure that there is, at all times,
a one-to-one correspondence between entries in
this table and entries in the partySecretsTable.
The creation/deletion of instances in this table
via SNMP Set-Requests is not allowed. Instead,
McCloghrie, Davin, & Galvin [Page 9]
RFC 1353 SNMP Party MIB July 1992
entries in this table are created/deleted as a
side-effect of the creation/deletion of
corresponding entries in the partySecretsTable.
Thus, a SNMP Set-Request whose varbinds contain a
reference to a non-existent instance of a
partyTable object, but no reference to the
corresponding instance of a partySecretsTable
object, will be rejected."
::= { partyPublic 1 }
partyEntry OBJECT-TYPE
SYNTAX PartyEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"Locally held non-secret information about a
particular SNMP party, which is available for
access by network management. Note that this does
not include all locally held information about a
party. In particular, it does not include the
'last-timestamp' (i.e., the timestamp of the last
authentic message received) or the 'nonce'
values."
INDEX { partyIdentity }
::= { partyTable 1 }
PartyEntry ::=
SEQUENCE {
partyIdentity
Party,
partyTDomain
OBJECT IDENTIFIER,
partyTAddress
TAddress,
partyProxyFor
Party,
partyAuthProtocol
OBJECT IDENTIFIER,
partyAuthClock
Clock,
partyAuthPublic
OCTET STRING,
partyAuthLifetime
INTEGER,
partyPrivProtocol
OBJECT IDENTIFIER,
partyPrivPublic
McCloghrie, Davin, & Galvin [Page 10]
RFC 1353 SNMP Party MIB July 1992
OCTET STRING,
partyMaxMessageSize
INTEGER,
partyStatus
INTEGER
}
partyIdentity OBJECT-TYPE
SYNTAX Party
ACCESS read-write
STATUS mandatory
DESCRIPTION
"A party identifier uniquely identifying a
particular SNMP party."
::= { partyEntry 1 }
partyTDomain OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
ACCESS read-write
STATUS mandatory
DESCRIPTION
"Indicates the kind of transport service by which
the party receives network management traffic. An
example of a transport domain is 'rfc1351Domain'
(SNMP over UDP)."
DEFVAL { rfc1351Domain }
::= { partyEntry 2 }
partyTAddress OBJECT-TYPE
SYNTAX TAddress
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The transport service address by which the party
receives network management traffic, formatted
according to the corresponding value of
partyTDomain. For rfc1351Domain, partyTAddress is
formatted as a 4-octet IP Address concatenated
with a 2-octet UDP port number."