rfc1503.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 787 行 · 第 1/3 页

                    contextLocal:            false
                    contextStorageType:      volatile
                    textual handle:          89.0.0.1

                    aclTarget (dest. party): 101
                    aclSubject (src party):  102
                    aclResources (context):  101
                    aclPrivileges:           get, get-next, get-bulk
                    aclStorageType:          volatile

               and the "context resolver" returns a handle to the newly
               created context.

          (4)  Otherwise, if the textual string specifies a domain name
               which resolves to multiple IP addresses, then for each



McCloghrie & Rose                                               [Page 5]

RFC 1503      Automating Administration in SNMPv2 Manager    August 1993


               such IP address, the "context resolver" adds to the local
               party database, a volatile noAuth/noPriv party pair, a
               volatile context, and a volatile access control entry
               allowing interrogation operations, using the
               "initialPartyId" and "initialContextId" conventions.
               Then, the "context resolver" returns a handle identifying
               all of those newly created contexts.

          (5)  Otherwise, if the textual string contains a '/'-
               character, and everything to the left of the first
               occurrence of this character specifies an IP address or a
               domain name which resolves to a single IP address, then
               the "context resolver" adds to the local party database,
               a volatile SNMPv1 party, a volatile context, and a
               volatile access control entry allowing interrogation
               operations.  (The SNMPv1 community string consists of any
               characters following the first occurrence of the '/'-
               character in the textual string.) Then, the "context
               resolver" returns a handle identifying the newly created
               context.

               So, if the application supplied "89.0.0.2/public", then
               the "context resolver" adds the following information to
               the local party database:

                    partyIdentifier:         initialPartyId.89.0.0.2.1
                    partyIndex:              201
                    partyTDomain:            rfc1157Domain
                    partyTAddress:           89.0.0.2:161
                    partyLocal:              false
                    partyAuthProtocol:       rfc1157noAuth
                    partyAuthPrivate:        public
                    partyPrivProtocol:       noPriv
                    partyStorageType:        volatile

                    contextIdentifier:       initialContextId.89.0.0.2.1
                    contextIndex:            201
                    contextLocal:            false
                    contextStorageType:      volatile
                    textual handle:          89.0.0.2

                    aclTarget (dest. party): 201
                    aclSubject (src party):  201
                    aclResources (context):  201
                    aclPrivileges:           get, get-next, get-bulk
                    aclStorageType:          volatile

               and the "context resolver" returns a handle to the the



McCloghrie & Rose                                               [Page 6]

RFC 1503      Automating Administration in SNMPv2 Manager    August 1993


               newly created context.

          (6)  Otherwise, if the textual string contains a '/'-
               character, and everything to the left of the first
               occurrence of this character specifies a domain name
               which resolves to multiple IP addresses, then for each
               such IP address, the "context resolver" adds to the local
               party database, a volatile SNMPv1 party, a volatile
               context, and a volatile access control entry allowing
               interrogation operations.  (The SNMPv1 community string
               consists of any characters following the first occurrence
               of the '/'-character in the textual string.) Then, the
               "context resolver" returns a handle identifying all of
               those newly created contexts.

          (7)  Otherwise, an error is raised.

4.2.  Requesting an Operation

   Later, when an SNMPv2 operation is to be performed, the management
   application supplies a "context handle" and a minimal set of security
   requirements to the management API:

          (1)  If the "context handle" refers to a single context, then
               all access control entries having that context as its
               aclResources, allowing the specified operation, having a
               non-local SNMPv2 party as its aclTarget, which satisfies
               the privacy requirements, and having a local party as its
               aclSubject, which satisfies the authentication
               requirements, are identified.

               So, if the application wanted to issue a get-next
               operation, with no security requirements, and supplied a
               "context handle" identifying context #1, then acl #1
               would be identified.

          (2)  For each such access control entry, the one which
               minimally meets the security requirements is selected for
               use.  If no such entry is identified, and authentication
               requirements are present, then the operation will be not
               performed.

               So, if the application requests a get-next operation,
               with no security requirements, and supplies a "context
               handle" identifying context #1, and step 1 above
               identified acl #1, then because acl #1 satisfies the no-
               security requirements, the operation would be generated
               using acl #1, i.e., using party #1, party #2, and context



McCloghrie & Rose                                               [Page 7]

RFC 1503      Automating Administration in SNMPv2 Manager    August 1993


               #1.

          (3)  Otherwise, all access control entries having the (single)
               context as its aclResources, allowing the specified
               operation, and having a non-local SNMPv1 party as its
               aclTarget, are identified.  If no such entry is
               identified, then the operation will not performed.
               Otherwise, any of the identified access control entries
               may be selected for use.

               The effect of separating out step 3 is to prefer SNMPv2
               communications over SNMPv1 communications.

          (4)  If the "context handle" refers to more than one context,
               then all access control entries whose aclResources refers
               any one of the contexts, are identified.  For each such
               context, step 2 is performed, and any (e.g., the first)
               access control entry identified is selected for use.  If
               no access control entry is identified, then step 3 is
               performed for each such context, and any (e.g., the
               first) access control entry identified is selected for
               use.

               So, if the application wanted to issue a get-bulk
               operation, with no security requirements, and supplied a
               "context handle" identifying contexts #1 and #2, then
               acls #1 and #2 would be identified in step 1; and, in
               step 2, party #1, party #2, and context #1 would be
               selected.

               However, if the application wanted to issue an
               authenticated get-bulk operation, and supplied a "context
               handle" identifying contexts #1 and #2, then acls #1 and
               #2 would still be identified in step 1; but, in step 2,
               only acl #2 satisfies the security requirement, and so,
               party #3, party #4, and context #2 would be selected.

          (5)  If no access control entry is identified, then an error
               is raised.

   Note that for steps 1 and 3, an implementation might choose to pre-
   compute (i.e., cache) for each context those access control entries
   having that context as its aclResources.

5.  Determining and Using Maintenance Knowledge

   When using authentication services, two "maintenance" tasks may have
   to be performed: clock synchronization and secret update.  These



McCloghrie & Rose                                               [Page 8]

RFC 1503      Automating Administration in SNMPv2 Manager    August 1993


   tasks should be performed transparently, independent of the
   management applications, and without user/administrator intervention.
   In order to operate transparently, the SNMP protocol engine must
   maintain "maintenance knowledge" (knowledge of which parties and
   contexts to use).  It is useful for this maintenance knowledge to be
   determined at run-time, rather than being directly configured by an
   administrator.

   One approach to achieve this is as follows: the first time that the
   SNMP protocol engine determines that it will be communicating with
   another SNMPv2 entity, the SNMP protocol engine first consults its
   local party database and then interrogates its peer, before engaging
   in the actual communications.

   Note that with such an approach, both the clock synchronization
   knowledge, and the secret update knowledge, associated with a party,
   can each be represented as (a pointer to) an access control entry.
   Further note that once an implementation has computed this knowledge,
   it might choose to retain this knowledge across restarts.

5.1.  Determination of Synchronization Knowledge

   To determine maintenance knowledge for clock synchronization:

          (1)  The SNMP protocol engine examines each active, non-local,
               noAuth party.

               So, this would be party #1.

          (2)  For each such party, P, all access control entries having
               that party as its aclTarget, and allowing the get-bulk
               operation, are identified.

               So, for party #1, this would be acl #1.

          (3)  For each such access control entry, A, at least one
               active, non-local, md5Auth party, Q, must be present
               which meets the following criteria:

            -  the transport domain and address of P and Q are
               identical;

            -  an access control entry, B, exists having either: Q as
               its aclTarget and a local party, R, as its aclSubject,
               or, Q as its aclSubject and a local party, R, as its
               aclTarget; and,

            -  no clock synchronization knowledge is known for R.



McCloghrie & Rose                                               [Page 9]

RFC 1503      Automating Administration in SNMPv2 Manager    August 1993


               So, for acl #1, party #3 is identified as having the same
               transport domain and address as party #1, and being
               present as the aclTarget in acl #2, which has local party
               #4 as the aclSubject.

          (4)  Whenever such a party, Q, is present, then all instances
               of the "partyAuthProtocol" and "partyAuthClock" objects
               are retrieved via the get-bulk operator using the parties
               and context identified by the access control entry, A.

               So, party #1, party #2, and context #1 would be used to
               sweep these two columns on the agent.

          (5)  Only those instances corresponding to parties in the
               local database, which have no clock synchronization
               knowledge, and are local mdAuth parties, are examined.