summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc1353.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc1353.txt')
-rw-r--r--doc/rfc/rfc1353.txt1459
1 files changed, 1459 insertions, 0 deletions
diff --git a/doc/rfc/rfc1353.txt b/doc/rfc/rfc1353.txt
new file mode 100644
index 0000000..8ba4a84
--- /dev/null
+++ b/doc/rfc/rfc1353.txt
@@ -0,0 +1,1459 @@
+
+
+
+
+
+
+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
+
+
+1. The Network Management Framework
+
+ 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.
+
+2. Objects
+
+ 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
+
+
+2.1. Format of Definitions
+
+ 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].
+
+3. Overview
+
+3.1. Structure
+
+ 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].
+
+3.2. Instance Identifiers
+
+ 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).
+
+3.3. Textual Conventions
+
+ 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.
+
+4. Definitions
+
+ 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."
+ DEFVAL { '000000000000'h }
+ ::= { partyEntry 3 }
+
+ partyProxyFor OBJECT-TYPE
+ SYNTAX Party
+ ACCESS read-write
+ STATUS mandatory
+ DESCRIPTION
+ "The identity of a second SNMP party or other
+
+
+
+McCloghrie, Davin, & Galvin [Page 11]
+
+RFC 1353 SNMP Party MIB July 1992
+
+
+ management entity with which interaction may be
+ necessary to satisfy received management requests.
+ In this context, the distinguished value { noProxy
+ } signifies that the party responds to received
+ management requests by entirely local mechanisms."
+ DEFVAL { noProxy }
+ ::= { partyEntry 4 }
+
+ partyAuthProtocol OBJECT-TYPE
+ SYNTAX OBJECT IDENTIFIER
+ ACCESS read-write
+ STATUS mandatory
+ DESCRIPTION
+ "The authentication protocol by which all messages
+ generated by the party are authenticated as to
+ origin and integrity. In this context, the value
+ { noAuth } signifies that messages generated by
+ the party are not authenticated."
+ DEFVAL { md5AuthProtocol }
+ ::= { partyEntry 5 }
+
+ partyAuthClock OBJECT-TYPE
+ SYNTAX Clock
+ ACCESS read-write
+ STATUS mandatory
+ DESCRIPTION
+ "The authentication clock which represents the
+ local notion of the current time specific to the
+ party. This value must not be decremented unless
+ the party's secret information is changed
+ simultaneously, at which time the party's nonce
+ and last-timestamp values must also be reset to
+ zero, and the new value of the clock,
+ respectively."
+ DEFVAL { 0 }
+ ::= { partyEntry 6 }
+
+ partyAuthPublic OBJECT-TYPE
+ SYNTAX OCTET STRING -- for md5AuthProtocol: (SIZE (0..16))
+ ACCESS read-write
+ STATUS mandatory
+ DESCRIPTION
+ "A publically-readable value for the party.
+
+ Depending on the party's authentication protocol,
+ this value may be needed to support the party's
+ authentication protocol. Alternatively, it may be
+ used by a manager during the procedure for
+
+
+
+McCloghrie, Davin, & Galvin [Page 12]
+
+RFC 1353 SNMP Party MIB July 1992
+
+
+ altering secret information about a party. (For
+ example, by altering the value of an instance of
+ this object in the same SNMP Set-Request used to
+ update an instance of partyAuthPrivate, a
+ subsequent Get-Request can determine if the Set-
+ Request was successful in the event that no
+ response to the Set-Request is received, see RFC
+ 1352.)
+
+ The length of the value is dependent on the
+ party's authentication protocol. If not used by
+ the authentication protocol, it is recommended
+ that agents support values of any length up to and
+ including the length of the corresponding
+ partyAuthPrivate object."
+ DEFVAL { ''h } -- the empty string
+ ::= { partyEntry 7 }
+
+ partyAuthLifetime OBJECT-TYPE
+ SYNTAX INTEGER (0..2147483647)
+ ACCESS read-write
+ STATUS mandatory
+ DESCRIPTION
+ "The lifetime (in units of seconds) which
+ represents an administrative upper bound on
+ acceptable delivery delay for protocol messages
+ generated by the party."
+ DEFVAL { 300 }
+ ::= { partyEntry 8 }
+
+ partyPrivProtocol OBJECT-TYPE
+ SYNTAX OBJECT IDENTIFIER
+ ACCESS read-write
+ STATUS mandatory
+ DESCRIPTION
+ "The privacy protocol by which all protocol
+ messages received by the party are protected from
+ disclosure. In this context, the value { noPriv }
+ signifies that messages received by the party are
+ not protected."
+ DEFVAL { noPriv }
+ ::= { partyEntry 9 }
+
+ partyPrivPublic OBJECT-TYPE
+ SYNTAX OCTET STRING -- for desPrivProtocol: (SIZE (0..16))
+ ACCESS read-write
+ STATUS mandatory
+ DESCRIPTION
+
+
+
+McCloghrie, Davin, & Galvin [Page 13]
+
+RFC 1353 SNMP Party MIB July 1992
+
+
+ "A publically-readable value for the party.
+
+ Depending on the party's privacy protocol, this
+ value may be needed to support the party's privacy
+ protocol. Alternatively, it may be used by a
+ manager as a part of its procedure for altering
+ secret information about a party. (For example,
+ by altering the value of an instance of this
+ object in the same SNMP Set-Request used to update
+ an instance of partyPrivPrivate, a subsequent
+ Get-Request can determine if the Set-Request was
+ successful in the event that no response to the
+ Set-Request is received, see RFC 1352.)
+
+ The length of the value is dependent on the
+ party's privacy protocol. If not used by the
+ privacy protocol, it is recommended that agents
+ support values of any length up to and including
+ the length of the corresponding partyPrivPrivate
+ object."
+ DEFVAL { ''h } -- the empty string
+ ::= { partyEntry 10 }
+
+ partyMaxMessageSize OBJECT-TYPE
+ SYNTAX INTEGER (484..65507)
+ ACCESS read-write
+ STATUS mandatory
+ DESCRIPTION
+ "The maximum length in octets of a SNMP message
+ which this party will accept. For parties which
+ execute at an agent, the agent initializes this
+ object to the maximum length supported by the
+ agent, and does not let the object be set to any
+ larger value. For parties which do not execute at
+ the agent, the agent must allow the manager to set
+ this object to any legal value, even if it is
+ larger than the agent can generate."
+ DEFVAL { 484 }
+ ::= { partyEntry 11 }
+
+ partyStatus OBJECT-TYPE
+ SYNTAX INTEGER { valid(1), invalid(2) }
+ ACCESS read-only
+ STATUS mandatory
+ DESCRIPTION
+ "The status of the locally-held information on a
+ particular SNMP party.
+
+
+
+
+McCloghrie, Davin, & Galvin [Page 14]
+
+RFC 1353 SNMP Party MIB July 1992
+
+
+ The instance of this object for a particular party
+ and the instance of partySecretsStatus for the
+ same party always have the same value.
+
+ This object will typically provide unrestricted
+ read-only access to the status of parties. In
+ contrast, partySecretsStatus will typically
+ provide restricted read-write access to the status
+ of parties."
+ ::= { partyEntry 12 }
+
+
+ -- The SNMP Party Secrets Database Group
+
+ -- The secret party information
+ --
+ -- Implementation of the objects in this group is mandatory.
+
+ partySecretsTable OBJECT-TYPE
+ SYNTAX SEQUENCE OF PartySecretsEntry
+ ACCESS not-accessible
+ STATUS mandatory
+ DESCRIPTION
+ "The SNMP Party Secrets database."
+ ::= { partyPrivate 1 }
+
+ partySecretsEntry OBJECT-TYPE
+ SYNTAX PartySecretsEntry
+ ACCESS not-accessible
+ STATUS mandatory
+ DESCRIPTION
+ "Locally held secret information about a
+ particular SNMP party, which is available for
+ access by network management.
+
+ When a SNMP Set-Request is used to update the
+ values of instances of objects in this table, it
+ is recommended that the same SNMP Set-Request also
+ alter the value of a non-secret object instance
+ (e.g., an instance of partyAuthPublic or
+ partyPrivPublic). This allows a Get-Request of
+ that non-secret object instance to determine if
+ the Set-Request was successful in the event that
+ no response which matches the Set-Request is
+ received, see RFC 1352."
+ INDEX { partySecretsIdentity }
+ ::= { partySecretsTable 1 }
+
+
+
+
+McCloghrie, Davin, & Galvin [Page 15]
+
+RFC 1353 SNMP Party MIB July 1992
+
+
+ PartySecretsEntry ::=
+ SEQUENCE {
+ partySecretsIdentity
+ Party,
+ partySecretsAuthPrivate
+ OCTET STRING,
+ partySecretsPrivPrivate
+ OCTET STRING,
+ partySecretsStatus
+ INTEGER
+ }
+
+ partySecretsIdentity OBJECT-TYPE
+ SYNTAX Party
+ ACCESS read-write
+ STATUS mandatory
+ DESCRIPTION
+ "A party identifier uniquely identifying a
+ particular SNMP party."
+ ::= { partySecretsEntry 1 }
+
+ partySecretsAuthPrivate OBJECT-TYPE
+ SYNTAX OCTET STRING -- for md5AuthProtocol: (SIZE (16))
+ ACCESS read-write
+ STATUS mandatory
+ DESCRIPTION
+ "An encoding of the party's private authentication
+ key which may be needed to support the
+ authentication protocol. Although the value of
+ this variable may be altered by a management
+ operation (e.g., a SNMP Set-Request), its value
+ can never be retrieved by a management operation:
+ when read, the value of this variable is the zero
+ length OCTET STRING.
+
+ The private authentication key is NOT directly
+ represented by the value of this variable, but
+ rather it is represented according to an encoding.
+ This encoding is the bitwise exclusive-OR of the
+ old key with the new key, i.e., of the old private
+ authentication key (prior to the alteration) with
+ the new private authentication key (after the
+ alteration). Thus, when processing a received
+ protocol Set operation, the new private
+ authentication key is obtained from the value of
+ this variable as the result of a bitwise
+ exclusive-OR of the variable's value and the old
+ private authentication key. In calculating the
+
+
+
+McCloghrie, Davin, & Galvin [Page 16]
+
+RFC 1353 SNMP Party MIB July 1992
+
+
+ exclusive-OR, if the old key is shorter than the
+ new key, zero-valued padding is appended to the
+ old key. If no value for the old key exists, a
+ zero-length OCTET STRING is used in the
+ calculation."
+ DEFVAL { ''h } -- the empty string
+ ::= { partySecretsEntry 2 }
+
+ partySecretsPrivPrivate OBJECT-TYPE
+ SYNTAX OCTET STRING -- for desPrivProtocol: (SIZE (16))
+ ACCESS read-write
+ STATUS mandatory
+ DESCRIPTION
+ "An encoding of the party's private encryption key
+ which may be needed to support the privacy
+ protocol. Although the value of this variable may
+ be altered by a management operation (e.g., a SNMP
+ Set-Request), its value can never be retrieved by
+ a management operation: when read, the value of
+ this variable is the zero length OCTET STRING.
+
+ The private encryption key is NOT directly
+ represented by the value of this variable, but
+ rather it is represented according to an encoding.
+ This encoding is the bitwise exclusive-OR of the
+ old key with the new key, i.e., of the old private
+ encryption key (prior to the alteration) with the
+ new private encryption key (after the alteration).
+ Thus, when processing a received protocol Set
+ operation, the new private encryption key is
+ obtained from the value of this variable as the
+ result of a bitwise exclusive-OR of the variable's
+ value and the old private encryption key. In
+ calculating the exclusive-OR, if the old key is
+ shorter than the new key, zero-valued padding is
+ appended to the old key. If no value for the old
+ key exists, a zero-length OCTET STRING is used in
+ the calculation."
+ DEFVAL { ''h } -- the empty string
+ ::= { partySecretsEntry 3 }
+
+ partySecretsStatus OBJECT-TYPE
+ SYNTAX INTEGER { valid(1), invalid(2) }
+ ACCESS read-write
+ STATUS mandatory
+ DESCRIPTION
+ "The status of the locally-held information on a
+ particular SNMP party.
+
+
+
+McCloghrie, Davin, & Galvin [Page 17]
+
+RFC 1353 SNMP Party MIB July 1992
+
+
+ Setting an instance of this object to the value
+ 'valid(1)' has the effect of ensuring that valid
+ local knowledge exists for the corresponding
+ party. For valid local knowledge to exist, there
+ must be corresponding instances of each object in
+ this table and in the partyTable. Thus, the
+ creation of instances in the partyTable (but not
+ in the aclTable or viewTable) occurs as a direct
+ result of the creation of instances in this table.
+
+ Setting an instance of this object to the value
+ 'invalid(2)' has the effect of invalidating all
+ local knowledge of the corresponding party,
+ including the invalidating of any/all entries in
+ the partyTable, the partySecretsTable, the
+ aclTable, and the viewTable which reference said
+ party.
+
+ It is an implementation-specific matter as to
+ whether the agent removes an invalidated entry
+ from the table. Accordingly, management stations
+ must be prepared to receive from agents tabular
+ information corresponding to entries not currently
+ in use. Proper interpretation of such entries
+ requires examination of the relevant
+ partySecretsStatus object."
+ DEFVAL { valid }
+ ::= { partySecretsEntry 4 }
+
+
+ -- The SNMP Access Privileges Database Group
+
+ -- This group of objects allows the SNMP itself to be used to
+ -- configure new SNMP parties, or to manipulate the access
+ -- privileges of existing parties.
+ --
+ -- Implementation of the objects in this group is mandatory.
+
+
+ aclTable OBJECT-TYPE
+ SYNTAX SEQUENCE OF AclEntry
+ ACCESS not-accessible
+ STATUS mandatory
+ DESCRIPTION
+ "The access privileges database."
+ ::= { partyAccess 1 }
+
+
+
+
+
+McCloghrie, Davin, & Galvin [Page 18]
+
+RFC 1353 SNMP Party MIB July 1992
+
+
+ aclEntry OBJECT-TYPE
+ SYNTAX AclEntry
+ ACCESS not-accessible
+ STATUS mandatory
+ DESCRIPTION
+ "The access privileges for a particular requesting
+ SNMP party in accessing a particular target SNMP
+ party."
+ INDEX { aclTarget, aclSubject }
+ ::= { aclTable 1 }
+
+ AclEntry ::=
+ SEQUENCE {
+ aclTarget
+ Party,
+ aclSubject
+ Party,
+ aclPrivileges
+ INTEGER,
+ aclStatus
+ INTEGER
+ }
+
+ aclTarget OBJECT-TYPE
+ SYNTAX Party
+ ACCESS read-write
+ STATUS mandatory
+ DESCRIPTION
+ "The target SNMP party whose performance of
+ management operations is constrained by this set
+ of access privileges."
+ ::= { aclEntry 1 }
+
+ aclSubject OBJECT-TYPE
+ SYNTAX Party
+ ACCESS read-write
+ STATUS mandatory
+ DESCRIPTION
+ "The subject SNMP party whose requests for
+ management operations to be performed is
+ constrained by this set of access privileges."
+ ::= { aclEntry 2 }
+
+ aclPrivileges OBJECT-TYPE
+ SYNTAX INTEGER (0..31)
+ ACCESS read-write
+ STATUS mandatory
+ DESCRIPTION
+
+
+
+McCloghrie, Davin, & Galvin [Page 19]
+
+RFC 1353 SNMP Party MIB July 1992
+
+
+ "The access privileges which govern what
+ management operations a particular target party
+ may perform when requested by a particular subject
+ party. These privileges are specified as a sum of
+ values, where each value specifies a SNMP PDU type
+ by which the subject party may request a permitted
+ operation. 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 SNMP PDU
+ type. The values (for the tags defined in RFC
+ 1157) are defined in RFC 1351 as:
+
+ Get : 1
+ GetNext : 2
+ GetResponse : 4
+ Set : 8
+ Trap : 16
+
+ The null set is represented by the value zero."
+ DEFVAL { 3 } -- Get & Get-Next
+ ::= { aclEntry 3 }
+
+ aclStatus OBJECT-TYPE
+ SYNTAX INTEGER { valid(1), invalid(2) }
+ ACCESS read-write
+ STATUS mandatory
+ DESCRIPTION
+ "The status of the access privileges for a
+ particular requesting SNMP party in accessing a
+ particular target SNMP party. Setting an instance
+ of this object to the value 'invalid(2)' has the
+ effect of invalidating the corresponding access
+ privileges.
+
+ It is an implementation-specific matter as to
+ whether the agent removes an invalidated entry
+ from the table. Accordingly, management stations
+ must be prepared to receive from agents tabular
+ information corresponding to entries not currently
+ in use. Proper interpretation of such entries
+ requires examination of the relevant aclStatus
+ object."
+ DEFVAL { valid }
+ ::= { aclEntry 4 }
+
+
+
+
+
+
+
+McCloghrie, Davin, & Galvin [Page 20]
+
+RFC 1353 SNMP Party MIB July 1992
+
+
+ -- The MIB View Database Group
+
+ -- This group of objects allows the SNMP itself to be used to
+ -- configure new SNMP parties, or to manipulate the MIB
+ -- MIB views of existing parties.
+ --
+ -- Implementation of the objects in this group is mandatory.
+
+
+ viewTable OBJECT-TYPE
+ SYNTAX SEQUENCE OF ViewEntry
+ ACCESS not-accessible
+ STATUS mandatory
+ DESCRIPTION
+ "The table contained in the local database which
+ defines local MIB views. Each SNMP party has a
+ single MIB view which is defined by two
+ collections of view subtrees: the included view
+ subtrees, and the excluded view subtrees. Every
+ such subtree, both included and excluded, is
+ defined in this table.
+
+ To determine if a particular object instance is in
+ a particular SNMP party's MIB view, compare the
+ object instance's Object Identifier with each
+ entry (for this party) 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 viewStatus in the
+ entry whose value of viewSubtree has the most
+ sub-identifiers. If multiple entries match and
+ have the same number of sub-identifiers, then the
+ lexicographically greatest instance of viewStatus
+ determines the inclusion or exclusion.
+
+ An object instance's Object Identifier X matches
+ an entry in this table when the number of sub-
+ identifiers in X is at least as many as in the
+ value of viewSubtree for the entry, and each sub-
+ identifier in the value of viewSubtree matches its
+ corresponding sub-identifier in X. Two sub-
+ identifiers match either if the corresponding bit
+ of viewMask is zero (the 'wild card' value), or if
+ they are equal.
+
+ Due to this 'wild card' capability, we introduce
+ the term, a 'family' of view subtrees, to refer to
+
+
+
+McCloghrie, Davin, & Galvin [Page 21]
+
+RFC 1353 SNMP Party MIB July 1992
+
+
+ the set of subtrees defined by a particular
+ combination of values of viewSubtree and viewMask.
+ In the case where no 'wild card' is defined in
+ viewMask, the family of view subtrees reduces to a
+ single view subtree."
+ ::= { partyViews 1 }
+
+ viewEntry OBJECT-TYPE
+ SYNTAX ViewEntry
+ ACCESS not-accessible
+ STATUS mandatory
+ DESCRIPTION
+ "Information on a particular family of view
+ subtrees included in or excluded from a particular
+ SNMP party's MIB view."
+ INDEX { viewParty, viewSubtree }
+ ::= { viewTable 1 }
+
+ ViewEntry ::=
+ SEQUENCE {
+ viewParty
+ Party,
+ viewSubtree
+ OBJECT IDENTIFIER,
+ viewStatus
+ INTEGER,
+ viewMask
+ OCTET STRING
+ }
+
+ viewParty OBJECT-TYPE
+ SYNTAX Party
+ ACCESS read-write
+ STATUS mandatory
+ DESCRIPTION
+ "The SNMP party whose single MIB view includes or
+ excludes a particular family of view subtrees."
+ ::= { viewEntry 1 }
+
+ viewSubtree OBJECT-TYPE
+ SYNTAX OBJECT IDENTIFIER
+ ACCESS read-write
+ STATUS mandatory
+ DESCRIPTION
+ "The view subtree which, in combination with the
+ corresponding instance of viewMask, defines a
+ family of view subtrees. This family is included
+ in, or excluded from the particular SNMP party's
+
+
+
+McCloghrie, Davin, & Galvin [Page 22]
+
+RFC 1353 SNMP Party MIB July 1992
+
+
+ MIB view, according to the value of the
+ corresponding instance of viewStatus."
+ ::= { viewEntry 2 }
+
+ viewStatus OBJECT-TYPE
+ SYNTAX INTEGER {
+ included(1),
+ excluded(2),
+ invalid(3)
+ }
+ ACCESS read-write
+ STATUS mandatory
+ DESCRIPTION
+ "The status of a particular family of view
+ subtrees within the particular SNMP party's MIB
+ view. The value 'included(1)' indicates that the
+ corresponding instances of viewSubtree and
+ viewMask define a family of view subtrees included
+ in the MIB view. The value 'excluded(2)'
+ indicates that the corresponding instances of
+ viewSubtree and viewMask define a family of view
+ subtrees excluded from the MIB view.
+
+ Setting an instance of this object to the value
+ 'invalid(3)' has the effect of invalidating the
+ presence or absence of the corresponding family of
+ view subtrees in the corresponding SNMP party's
+ MIB view.
+
+ It is an implementation-specific matter as to
+ whether the agent removes an invalidated entry
+ from the table. Accordingly, management stations
+ must be prepared to receive from agents tabular
+ information corresponding to entries not currently
+ in use. Proper interpretation of such entries
+ requires examination of the relevant viewStatus
+ object."
+ DEFVAL { included }
+ ::= { viewEntry 3 }
+
+ viewMask OBJECT-TYPE
+ SYNTAX OCTET STRING (SIZE (0..16))
+ ACCESS read-write
+ STATUS mandatory
+ DESCRIPTION
+ "The bit mask which, in combination with the
+ corresponding instance of viewSubtree, defines a
+ family of view subtrees.
+
+
+
+McCloghrie, Davin, & Galvin [Page 23]
+
+RFC 1353 SNMP Party MIB July 1992
+
+
+ Each bit of this bit mask corresponds to a sub-
+ identifier of viewSubtree, 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 the following criteria are met:
+
+ for each sub-identifier of the value of
+ viewSubtree, either:
+
+ the i-th bit of viewMask is 0, or
+
+ the i-th sub-identifier of X is equal to
+ the i-th sub-identifier of the value of
+ viewSubtree.
+
+ If the value of this bit mask is M bits long and
+ there are more than M sub-identifiers in the
+ corresponding instance of viewSubtree, 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 viewSubtree."
+ DEFVAL { ''h }
+ ::= { viewEntry 4 }
+
+
+ END
+
+
+
+
+McCloghrie, Davin, & Galvin [Page 24]
+
+RFC 1353 SNMP Party MIB July 1992
+
+
+5. Acknowledgments
+
+ This document was produced on behalf of the SNMP Security Working
+ Group of the Internet Engineering Task Force. The authors wish to
+ thank the members of the working group, and others who contributed to
+ this effort.
+
+6. References
+
+ [1] Rose, M., and K. McCloghrie, "Structure and Identification of
+ Management Information for TCP/IP based internets", RFC 1155,
+ Performance Systems International, Hughes LAN Systems, May 1990.
+
+ [2] McCloghrie, K., and M. Rose, "Management Information Base for
+ Network Management of TCP/IP-based Internets", RFC 1156, Hughes
+ LAN Systems and Performance Systems International, May 1990.
+
+ [3] Case, J., M. Fedor, M. Schoffstall, and J. Davin, The Simple
+ Network Management Protocol", RFC 1157, University of Tennessee
+ at Knoxville, Performance Systems International, Performance
+ Systems International, and the MIT Laboratory for Computer
+ Science, May 1990.
+
+ [4] McCloghrie K., and M. Rose, Editors, "Management Information Base
+ for Network Management of TCP/IP-based internets", RFC 1213,
+ Performance Systems International, March 1991.
+
+ [5] Information processing systems - Open Systems Interconnection -
+ Specification of Abstract Syntax Notation One (ASN.1),
+ International Organization for Standardization, International
+ Standard 8824, December 1987.
+
+ [6] Information processing systems - Open Systems Interconnection -
+ Specification of Basic Encoding Rules for Abstract Notation One
+ (ASN.1), International Organization for Standardization,
+ International Standard 8825, December 1987.
+
+ [7] Rose, M., and K. McCloghrie, Editors, "Concise MIB Definitions",
+ RFC 1212, Performance Systems International, Hughes LAN Systems,
+ March 1991.
+
+ [8] Davin, J., Galvin, J., and K. McCloghrie, "SNMP Administrative
+ Model", RFC 1351, MIT Laboratory for Computer Science, Trusted
+ Information Systems, Inc., Hughes LAN Systems, Inc., July 1992.
+
+ [9] Galvin, J., McCloghrie, K., and J. Davin, "SNMP Security
+ Protocols", RFC 1352, Trusted Information Systems, Inc., Hughes
+ LAN Systems, Inc., MIT Laboratory for Computer Science, July
+
+
+
+McCloghrie, Davin, & Galvin [Page 25]
+
+RFC 1353 SNMP Party MIB July 1992
+
+
+ 1992.
+
+Security Considerstions
+
+ Security issues are discussed in section 3.1. and in RFCs 1351 and
+ 1352.
+
+Authors' Addresses
+
+ Keith McCloghrie
+ Hughes LAN Systems, Inc.
+ Mountain View, CA 94043
+
+ Phone: (415) 966-7934
+ EMail: kzm@hls.com
+
+
+ James R. Davin
+ MIT Laboratory for Computer Science
+ 545 Technology Square
+ Cambridge, MA 02139
+
+ Phone: (617) 253-6020
+ EMail: jrd@ptt.lcs.mit.edu
+
+
+ James M. Galvin
+ Trusted Information Systems, Inc.
+ 3060 Washington Road, Route 97
+ Glenwood, MD 21738
+
+ Phone: (301) 854-6889
+ EMail: galvin@tis.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+McCloghrie, Davin, & Galvin [Page 26]
+ \ No newline at end of file