doc: Add RFC documents

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