📄 rfc1503.txt
字号:
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 eachMcCloghrie & 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 theMcCloghrie & 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 contextMcCloghrie & 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. TheseMcCloghrie & 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.
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -