idnits 2.17.1 draft-ietf-snmpsec-admin-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-27) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** Expected the document's filename to be given on the first page, but didn't find any ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 88 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 8 instances of too long lines in the document, the longest one being 2 characters in excess of 72. == There are 25 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 32 has weird spacing: '... and inten...' == Line 66 has weird spacing: '...w (see secti...' == Line 67 has weird spacing: '...agement opera...' == Line 71 has weird spacing: '...terized by a...' == Line 119 has weird spacing: '... o Its party...' == (83 more instances...) == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (April 1991) is 12066 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Historic RFC: RFC 1157 (ref. '1') -- Possible downref: Non-RFC (?) normative reference: ref. '3' Summary: 15 errors (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT April 1991 4 SNMP Administrative Model 6 DRAFT 8 April 8, 1991 10 1 Introduction 12 This paper presents an elaboration of the SNMP administrative 13 model set forth in [1]. This model provides a unified conceptual 14 basis for administering SNMP protocol entities to support 16 o authentication and integrity, 18 o privacy, 20 o access control, and 22 o the cooperation of multiple protocol entities. 24 This paper also describes how the elaborated administrative 25 model is applied to realize effective network management in a 26 variety of configurations and environments. 28 The model described here entails the use of distinct identities 29 for peers that exchange SNMP messages. Thus, it represents 30 a departure from the community-based administrative model 31 set forth in [1]. By unambiguously identifying the source 32 and intended recipient of each SNMP message, this new 33 strategy improves upon the historical community scheme both 34 by supporting a more convenient access control model and 35 allowing for effective use of asymmetric (public key) security 36 protocols in the future. 38 2 Elements of the Model 40 2.1 SNMP Party 42 A SNMP party is a conceptual, virtual execution context whose 43 operation is restricted (for security or other purposes) to an 44 administratively defined subset of all possible operations of a 45 particular SNMP protocol entity (see section 2.2). Whenever 46 a SNMP protocol entity processes a SNMP message, it does 47 so by acting as a SNMP party and is thereby restricted to the 48 set of operations defined for that party. The set of possible 49 operations specified for a SNMP party may be overlapping or 50 disjoint with respect to the sets of other SNMP parties; it may 51 also be a proper or improper subset of all possible operations 52 of the SNMP protocol entity. 54 Architecturally, each SNMP party comprises 56 o a single, unique party identity, 58 o a single authentication protocol and associated param- 59 eters by which all protocol messages originated by the 60 party are authenticated as to origin and integrity, 62 o a single privacy protocol and associated secret by which 63 all protocol messages received by the party are protected 64 from disclosure, 66 o a single MIB view (see section 2.6) to which all 67 management operations performed by the party are 68 applied, and 70 o a logical network location at which the party executes, 71 characterized by a transport protocol domain and 72 transport addressing information. 74 Conceptually, each SNMP party can be represented by an 75 ASN.1 value with the syntax 76 SnmpParty ::= SEQUENCE { 77 partyIdentity 78 OBJECT IDENTIFIER, 79 partyTDomain 80 OBJECT IDENTIFIER, 81 partyTAddr 82 OCTET STRING, 83 partyProxyFor 84 OBJECT IDENTIFIER, 85 partyAuthProt 86 OBJECT IDENTIFIER, 87 partyAuthClock 88 TimeTicks, 89 partyAuthLastMsg 90 TimeTicks, 91 partyAuthNonce 92 INTEGER, 93 partyAuthPrivate 94 OCTET STRING, 95 partyAuthPublic 96 OCTET STRING, 97 partyAuthLifetime 98 INTEGER, 99 partyPrivProt 100 OBJECT IDENTIFIER, 101 partyPrivPrivate 102 OCTET STRING, 103 partyPrivPublic 104 OCTET STRING 105 } 107 For each SnmpParty value that represents a SNMP party, the 108 following statements are true: 110 o Its partyIdentity component is called the identity of the 111 party and corresponds to the party identity. 113 o Its partyTDomain component is called the transport 114 domain and indicates the kind of transport service by 115 which the party receives network management traffic. 116 An example of a transport domain is rfc1157Domain 117 (SNMP over UDP). 119 o Its partyTAddr component is called the transport 120 addressing information and represents a transport service 121 address by which the party receives network management 122 traffic. 124 o Its partyProxyFor component is called the proxied party 125 and represents the identity of a second SNMP party or 126 other management entity with which interaction may be 127 necessary to satisfy received management requests. In 128 this context, the value noProxy signifies that the party 129 responds to received management requests by entirely 130 local mechanisms. 132 o Its partyAuthProt component is called the authentica- 133 tion protocol and identifies a protocol by which all mes- 134 sages generated by the party are authenticated as to origin 135 and integrity. In this context, the value noAuth signifies 136 that messages generated by the party are not authenti- 137 cated as to origin and integrity. 139 o Its partyAuthClock component is called the authenti- 140 cation clock and represents a notion of the current time 141 that is specific to the party. The significance of this com- 142 ponent is specific to the authentication protocol. 144 o Its partyAuthLastMsg component is called the ratchet 145 and represents a notion of time associated with the most 146 recent, authentic protocol message generated by the party. 147 The significance of this component is specific to the 148 authentication protocol. 150 o Its partyAuthNonce component is called the nonce 151 and represents an integer associated with the most 152 recent, authentic protocol message generated by the party. 153 The significance of this component is specific to the 154 authentication protocol. 156 o Its partyAuthPrivate component is called the private 157 authentication key and represents any secret value that 158 may be needed to support the authentication protocol. 159 The significance of this component is specific to the 160 authentication protocol. 162 o Its partyAuthPublic component is called the public 163 authentication key and represents any public value that 164 may be needed to support the authentication protocol. 165 The significance of this component is specific to the 166 authentication protocol. 168 o Its partyAuthLifetime component is called the lifetime 169 and represents an administrative upper bound on 170 acceptable delivery delay for protocol messages generated 171 by the party. The significance of this component is specific 172 to the authentication protocol. 174 o Its partyPrivProt component is called the privacy 175 protocol and identifies a protocol by which all protocol 176 messages received by the party are protected from 177 disclosure. In this context, the value noPriv signifies 178 that messages received by the party are not protected 179 from disclosure. 181 o Its partyPrivPrivate component is called the private 182 privacy key and represents any secret value that may be 183 needed to support the privacy protocol. 185 o Its partyPrivPublic component is called the public 186 privacy key and represents any public value that may be 187 needed to support the privacy protocol. 189 If, for all SNMP parties realized by a SNMP protocol entity, the 190 authentication protocol is noAuth and the privacy protocol is 191 noPriv, then that protocol entity is called non-secure. 193 2.2 SNMP Protocol Entity 195 A SNMP protocol entity is an actual process which performs 196 network management operations by generating and/or respond- 197 ing to SNMP protocol messages in the manner specified in [1]. 198 When a protocol entity is acting as a particular SNMP party 199 (see section 2.1), the operation of that entity must be restricted 200 to the subset of all possible operations that is administratively 201 defined for that party. 203 By definition, the operation of a SNMP protocol entity requires 204 no concurrency between processing of any single protocol 205 message (by a particular SNMP party) and processing of any 206 other protocol message (by a potentially different SNMP party). 207 Accordingly, implementation of a SNMP protocol entity to 208 support more than one party need not be multi-threaded. 209 However, there may be situations where implementors may 210 choose to use multi-threading. 212 Architecturally, every SNMP protocol entity maintains a local 213 database that represents all SNMP parties known to it -- those 214 whose operation is performed locally, those whose operation 215 is performed through communication with remote proxied 216 parties, and those whose operation is performed by remote 217 parties. In addition, every SNMP protocol entity maintains 218 a local database that represents an access control policy (see 219 section 2.11) that defines the access privileges associated with 220 known SNMP parties. 222 2.3 SNMP Management Station 224 A SNMP management station is the operational role assumed 225 by a SNMP party when it initiates SNMP management 226 operations by the generation of appropriate SNMP protocol 227 messages or when it receives and processes trap notifications. 229 Sometimes, the term SNMP management station is applied to 230 partial implementations of the SNMP (in graphics workstations, 231 for example) that focus upon this operational role. Such partial 232 implementations may provide for convenient, local invocation of 233 management services, but they may provide little or no support 234 for performing SNMP management operations on behalf of 235 remote protocol users. 237 2.4 SNMP Agent 239 A SNMP agent is the operational role assumed by a SNMP 240 party when it performs SNMP management operations in 241 response to received SNMP protocol messages such as those 242 generated by a SNMP management station (see section 2.3). 244 Sometimes, the term SNMP agent is applied to partial 245 implementations of the SNMP (in embedded systems, for 246 example) that focus upon this operational role. Such partial 247 implementations provide for realization of SNMP management 248 operations on behalf of remote users of management services, 249 but they may provide little or no support for local invocation 250 of such services. 252 2.5 View Subtree 254 A view subtree is the set of all MIB object instances 255 which have a common ASN.1 OBJECT IDENTIFIER 256 prefix to their names. A view subtree is identified by 257 the OBJECT IDENTIFIER value which is the longest 258 OBJECT IDENTIFIER prefix common to all (potential) 259 MIB object instances in that subtree. 261 2.6 MIB View 263 A MIB view is a subset of the set of all instances of all object 264 types defined according to the Internet-standard SMI [2] (i.e., 265 of the universal set of all instances of all MIB objects), subject 266 to the following constraints: 268 o Each element of a MIB view is uniquely named by 269 an ASN.1 OBJECT IDENTIFIER value. As such, 270 identically named instances of a particular object type 271 (e.g., in different agents) must be contained within 272 different MIB views. That is, a particular object instance 273 name resolves within a particular MIB view to at most 274 one object instance. 276 o Every MIB view is defined as a collection of view subtrees 277 that are mutually disjoint. 279 2.7 SNMP Management Communication 281 A SNMP management communication is a communication 282 from one specified SNMP party to a second specified SNMP 283 party about management information that is represented in the 284 MIB view of the appropriate party. In particular, a SNMP 285 management communication may be: 287 o a query by the originating party about information in the 288 MIB view of the addressed party (e.g., getRequest and 289 getNextRequest); 291 o an indicative assertion to the addressed party about 292 information in the MIB view of the originating party (e.g., 293 getResponse or trapNotification); or 295 o an imperative assertion by the originating party about 296 information in the MIB view of the addressed party (e.g., 297 setRequest). 299 A management communication is represented by an ASN.1 300 value with the syntax 302 SnmpMgmtCom ::= [1] IMPLICIT SEQUENCE { 303 dstParty 304 OBJECT IDENTIFIER, 306 srcParty 307 OBJECT IDENTIFIER, 308 pdu 309 PDUs 310 } 312 For each SnmpMgmtCom value that represents a SNMP 313 management communication, the following statements are true: 315 o Its dstParty component is called the destination and 316 identifies the SNMP party to which the communication 317 is directed. 319 o Its srcParty component is called the source and identifies 320 the SNMP party from which the communication is 321 originated. 323 o Its pdu component has the form and significance 324 attributed to it in [1]. 326 2.8 SNMP Authenticated Management Commu- 327 nication 329 A SNMP authenticated management communication is a SNMP 330 management communication (see section 2.7) for which the 331 originating SNMP party is (possibly) reliably identified and for 332 which the integrity of the transmission of the communication 333 is (possibly) protected. An authenticated management 334 communication is represented by an ASN.1 value with the 335 syntax 337 SnmpAuthMsg ::= [1] IMPLICIT SEQUENCE { 338 authInfo 339 ANY, - defined by authentication protocol 340 authData 341 SnmpMgmtCom 343 } 345 For each SnmpAuthMsg value that represents a SNMP 346 authenticated management communication, the following 347 statements are true: 349 o Its authInfo component is called the authentication 350 information and represents information required in 351 support of the authentication protocol used by the 352 SNMP party originating the message. The detailed 353 significance of the authentication information is specific to 354 the authentication protocol in use; it has no effect on the 355 application semantics of the communication other than its 356 use by the authentication protocol in determining whether 357 the communication is authentic or not. 359 o Its authData component is called the authentication data 360 and represents a SNMP management communication. 362 2.9 SNMP Private Management Communication 364 A SNMP private management communication is a SNMP 365 authenticated management communication (see section 2.8) 366 that is (possibly) protected from disclosure. A private 367 management communication is represented by an ASN.1 value 368 with the syntax 370 SnmpPrivMsg ::= [1] IMPLICIT SEQUENCE { 371 privDst 372 OBJECT IDENTIFIER, 373 privData 374 [1] IMPLICIT OCTET STRING 375 } 377 For each SnmpPrivMsg value that represents a SNMP private 378 management communication, the following statements are true: 380 o Its privDst component is called the private destination 381 and identifies the SNMP party to which the communica- 382 tion is directed. 384 o Its privData component is called the private data 385 and represents the (possibly encrypted) serialization 386 (according to the conventions of [3] and [1]) of a 387 SNMP authenticated management communication (see 388 section 2.8). 390 2.10 SNMP Management Communication Class 392 A SNMP management communication class corresponds to 393 a specific SNMP PDU type defined in [1]. A management 394 communication class is represented by an ASN.1 INTEGER 395 value according to the type of the identifying PDU (see Table 1). 397 The value by which a communication class is represented is 398 computed as 2 raised to the value of the ASN.1 context-specific 399 tag for the appropriate SNMP PDU. 401 A set of management communication classes is represented 402 by the ASN.1 INTEGER value that is the sum of the 403 representations of the communication classes in that set. The 404 null set is represented by the value zero. 406 Get 1 407 GetNext 2 408 GetResponse 4 409 Set 8 410 Trap 16 412 Table 1: Management Communication Classes 414 2.11 SNMP Access Control Policy 416 A SNMP access control policy is a specification of a local access 417 policy in terms of the network management communication 418 classes which are authorized between particular SNMP parties. 419 Architecturally, such a specification comprises three parts: 421 o the targets of SNMP access control - the SNMP parties 422 that may perform management operations as requested by 423 management communications received from other parties, 425 o the subjects of SNMP access control - the SNMP 426 parties that may request, by sending management 427 communications to other parties, that management 428 operations be performed, and 430 o the policy that specifies the SNMP management commu- 431 nications classes that a particular subject is authorized to 432 request of a particular target. 434 Access to individual MIB object instances is determined 435 implicitly since by definition each (target) SNMP party 436 performs operations on exactly one MIB view. Thus, defining 437 the permitted access of a (reliably) identified subject party to a 438 particular target party effectively defines the access permitted 439 by that subject to that target's MIB view and, accordingly, to 440 particular MIB object instances. 442 Conceptually, a SNMP access policy is represented by a 443 collection of ASN.1 values with the following syntax: 445 AclEntry ::= SEQUENCE { 446 aclTarget 447 OBJECT IDENTIFIER, 448 aclSubject 449 OBJECT IDENTIFIER, 450 aclPrivileges 451 INTEGER 452 } 454 For each such value that represents one part of a SNMP access 455 policy the following statements are true: 457 o Its aclTarget component is called the target and identifies 458 the SNMP party to which the partial policy permits 459 access. 461 o Its aclSubject component is called the subject and 462 identifies the SNMP party to which the partial policy 463 grants privileges. 465 o Its aclPrivileges component is called the privileges and 466 represents a set of SNMP management communication 467 classes that are authorized to be processed by the specified 468 target party when received from the specified subject 469 party. 471 2.12 SNMP Proxy Party 473 A SNMP proxy party is a SNMP party that performs 474 management operations by communicating with another, 475 logically remote party. 477 When communication between a logically remote party and 478 a SNMP proxy party is via the SNMP (over any transport 479 protocol), then the proxy party is called a SNMP native proxy 480 party. There are multiple reasons why a SNMP native proxy 481 party might be used. For example, deployment of SNMP native 482 proxy parties is a means whereby the processing or bandwidth 483 costs of management may be amortized or shifted -- thereby 484 facilitating the construction of large management systems. 486 When communication between a logically remote party and a 487 SNMP proxy party is not via the SNMP, then the proxy party 488 is called a SNMP foreign proxy party. Deployment of foreign 489 proxy parties is a means whereby otherwise unmanageable 490 devices or portions of an internet may be managed via the 491 SNMP. 493 The transparency principle that defines the behavior of a SNMP 494 party in general applies to a SNMP proxy party. In particular: 496 The manner in which one SNMP party processes 497 SNMP protocol messages received from another 498 SNMP party is entirely transparent to the latter. 500 The transparency principle derives directly from the historical 501 SNMP philosophy of divorcing architecture from implementa- 502 tion. To this dichotomy are attributable many of the most valu- 503 able benefits in both the information and distribution models 504 of the management framework, and it is the architectural cor- 505 nerstone upon which large management systems may be built. 506 Consistent with this philosophy, although the implementation 507 of SNMP proxy agents in certain environments may resemble 508 that of a transport-layer bridge, this particular implementa- 509 tion strategy (or any other!) does not merit special recognition 510 either in the SNMP management architecture or in standard 511 mechanisms for proxy administration. 513 Implicit in the transparency principle is the requirement that 514 the semantics of SNMP management operations are preserved 515 between any two SNMP peers. In particular, the "as if 516 simultaneous" semantics of a Set operation are extremely 517 difficult to guarantee if its scope extends to management 518 information resident at multiple network locations. For this 519 reason, proxy configurations that admit Set operations that 520 apply to information at multiple locations are discouraged, 521 although such operations are not explicitly precluded by the 522 architecture in those rare cases where they might be supported 523 in a conformant way. 525 Also implicit in the transparency principle is the requirement 526 that the interaction between a management station and a proxy 527 agent not supply information to the station about the nature or 528 progress of the mechanisms by which its requests are realized. 530 That is, it should seem -- except for any distinction in an 531 underlying transport address -- to the management station as 532 if it were interacting directly with the proxied device. Thus, 533 a timeout in the communication between a proxy agent and 534 its proxied device should be represented as a timeout in the 535 communication between the management station and the proxy 536 agent. Similarly, an error response from a proxied device should 537 -- as much as possible -- be represented by the corresponding 538 error response in the interaction between the proxy agent and 539 management station. 541 2.13 Procedures 543 This section describes the procedures followed by a SNMP 544 protocol entity in processing SNMP messages. These 545 procedures are independent of the particular authentication and 546 privacy protocols that may be in use. 548 2.13.1 Generating a Request 550 This section describes the procedure followed by a SNMP 551 protocol entity whenever either a management request or a trap 552 notification is to be transmitted by a SNMP party. 554 1. An ASN.1 SnmpMgmtCom value is constructed for 555 which the srcParty component identifies the originating 556 party, for which the dstParty component identifies the 557 receiving party, and for which the other component 558 specifies the desired management operation. 560 2. The local database is consulted to determine the 561 authentication protocol and other relevant information for 562 the originating SNMP party. 564 3. An ASN.1 SnmpAuthMsg value is constructed with the 565 following properties: 567 o Its authInfo component is constructed according 568 to the authentication protocol specified for the 569 originating party. 570 In particular, if the authentication protocol for the 571 originating SNMP party is identified as noAuth, 572 then this component corresponds to the OCTET 573 STRING value of zero length. 574 o Its authData component is the constructed Snmp- 575 MgmtCom value. 577 4. The local database is consulted to determine the privacy 578 protocol and other relevant information for the receiving 579 SNMP party. 581 5. An ASN.1 SnmpPrivMsg value is constructed with the 582 following properties: 584 o Its privDst component identifies the receiving 585 SNMP party. 586 o Its privData component is the (possibly encrypted) 587 serialization of the SnmpAuthMsg value according 588 to the conventions of [3] and [1]. 589 In particular, if the privacy protocol for the receiving 590 SNMP party is identified as noPriv, then the 591 privData component is unencrypted. Otherwise, 592 the privData component is processed according to 593 the privacy protocol. 595 6. The constructed SnmpPrivMsg value is serialized 596 according to the conventions of [3] and [1]. 598 7. The serialized SnmpPrivMsg value is transmitted using 599 the transport address and transport domain for the 600 receiving SNMP party. 602 2.13.2 Processing a Received Communication 604 This section describes the procedure followed by a SNMP 605 protocol entity whenever a management communication is 606 received. 608 1. If the received message is not the serialization (according 609 to the conventions of [3] and [1]) of an ASN.1 610 SnmpPrivMsg value, then that message is discarded 611 without further processing. 613 2. The local database is consulted for information about 614 the receiving SNMP party identified by the privDst 615 component of the SnmpPrivMsg value. 617 3. If information about the receiving SNMP party is absent 618 from the local database, or specifies a transport domain 619 and address which indicates that the receiving party's 620 operation is not performed by the local SNMP protocol 621 entity, then the received message is discarded without 622 further processing. 624 4. An ASN.1 OCTET STRING value is constructed 625 (possibly by decryption) from the privData component 626 of said SnmpPrivMsg value according to the privacy 627 protocol in use. 629 In particular, if the privacy protocol recorded for the party 630 is identified as noPriv, then the OCTET STRING 631 value corresponds exactly to the privData component 632 of the SnmpPrivMsg value. 634 5. If the OCTET STRING value is not the serialization 635 (according to the conventions of [3] and [1]) of an ASN.1 636 SnmpAuthMsg value, then the received message is 637 discarded without further processing. 639 6. If the dstParty component of the authData component 640 of the obtained SnmpAuthMsg value is not the same 641 as the privDst component of the SnmpPrivMsg value, 642 then the received message is discarded without further 643 processing. 645 7. The local database is consulted for information about the 646 originating SNMP party identified by the srcParty com- 647 ponent of the authData component of the SnmpAu- 648 thMsg value. 650 8. If information about the originating SNMP party is absent 651 from the local database, then the received message is 652 discarded without further processing. 654 9. The obtained SnmpAuthMsg value is evaluated accord- 655 ing to the authentication protocol and other relevant in- 656 formation associated with the originating SNMP party in 657 the local database. 659 In particular, if the authentication protocol is identified 660 as noAuth, then the SnmpAuthMsg value is always 661 evaluated as authentic. 663 10. If the SnmpAuthMsg value is evaluated as unauthentic, 664 then the received message is discarded without further 665 processing, and an authentication failure is noted. 667 11. The ASN.1 SnmpMgmtCom value is extracted from the 668 authData component of the SnmpAuthMsg value. 670 12. The local database is consulted for access privileges 671 permitted by the local access policy to the originating 672 SNMP party with respect to the receiving SNMP party. 674 13. The management communication class is determined from 675 the ASN.1 tag value associated with the SnmpMgmt- 676 Com value. 678 14. If the management communication class is not among the 679 access privileges, then the received message is discarded 680 after first checking if the class is not 16 (i.e., not a trap), 681 and if so, generating a response to the originating SNMP 682 party on behalf of the receiving SNMP party for which the 683 var-bind-list and request-id components are identical 684 to those of the received request, and for which the value 685 of the error-index component is zero, and for which the 686 value of the error-status component is readOnly. 688 15. If the proxied party associated with the receiving SNMP 689 party in the local database is identified as noProxy, 690 then the SNMP management communication represented 691 by the SnmpMgmtCom value is performed by the 692 receiving SNMP protocol entity with respect to the MIB 693 view identified with the receiving SNMP party identity 694 according to the procedures set forth in [1]. 696 16. If the proxied party associated with the receiving 697 SNMP party in the local database is not identified as 698 noProxy, then the SNMP management communication 699 represented by the SnmpMgmtCom value is performed 700 by appropriate cooperation between the receiving SNMP 701 party and the identified proxied party. 703 In particular, if the transport domain associated with 704 the identified proxied party in the local database is 705 rfc1157Domain, then the operation requested by the 706 received message is performed by the generation of a 707 corresponding request to the proxied party on behalf of 708 the receiving party. If the received message requires a 709 response from the local SNMP protocol entity, then that 710 response is subsequently generated from the response (if 711 any) received from the proxied party corresponding to the 712 newly generated request. 714 2.13.3 Generating a Response 716 This section describes the procedure followed by a SNMP 717 protocol entity whenever a response to a management request 718 is generated. 720 The procedure for generating a response to a SNMP 721 management request is identical to the procedure for 722 transmitting a request (see section 2.13.1), except for the 723 derivation of the transport domain and address information. 724 In this case, the response is transmitted using the transport 725 domain and address (not from the local database but) from 726 which the corresponding request originated. 728 3 Application of the Model 730 This section describes how the administrative model set forth 731 above is applied to realize effective network management in a 732 variety of configurations and environments. Several types of 733 administrative configurations are identified and examples are 734 given of how each may be realized. 736 3.1 Non-Secure Minimal Agent Configuration 738 This section presents an example configuration for a minimal, 739 non-secure SNMP agent that interacts with one or more SNMP 740 management stations. Table 2 presents information about 741 SNMP parties that is known both to the minimal agent and 742 to the manager, while Table 3 presents similarly common 743 information about the local access policy. 745 As represented in Table 2, the example agent party operates 746 at UDP port 161 at IP address 1.2.3.4 using the party identity 747 gracie; the example manager operates at UDP port 2001 at 748 IP address 1.2.3.5 using the identity george. At minimum, 749 a non-secure SNMP agent implementation must provide for 750 administrative configuration (and non-volatile storage) of the 751 identities and transport addresses of two SNMP parties: itself 752 and a remote peer. Strictly speaking, other information about 753 these two parties (including access policy information) need not 754 be configurable. 756 Suppose that the managing party george wishes to interrogate 757 the agent named gracie by issuing a SNMP GetNext request 758 message. The manager consults its local database of party 759 information. Because the authentication protocol for the party 760 george is recorded as noAuth, the GetNext request message 761 generated by the manager is not authenticated as to origin and 762 integrity. Because, according to the manager's database, the 763 privacy protocol for the party gracie is noPriv, the GetNext 764 request message is not protected from disclosure. Rather, it is 765 simply assembled, serialized, and transmitted to the transport 766 Identity gracie george 767 (agent) (manager) 768 Domain rfc1157 rfc1157 769 Address 1.2.3.4, 161 1.2.3.5, 2001 770 Proxied Party noProxy noProxy 771 Auth Prot noAuth noAuth 772 Auth Priv Key "" "" 773 Auth Pub Key "" "" 774 Auth Clock 0 0 775 Auth Last Msg 0 0 776 Auth Lifetime 0 0 777 Priv Prot noPriv noPriv 778 Priv Priv Key "" "" 779 Priv Pub Key "" "" 781 Table 2: Party Information for Minimal Agent 783 Target Subject Privileges 784 gracie george 3 785 george gracie 20 787 Table 3: Access Information for Minimal Agent 789 address (IP address 1.2.3.4, UDP port 161) associated in the 790 manager's database with the party gracie. 792 When the GetNext request message is received at the agent, 793 the identity of the party to which it is directed (gracie) is 794 extracted from the message, and the receiving protocol entity 795 consults its local database of party information. Because the 796 privacy protocol for the party gracie is recorded as noPriv, the 797 received message is assumed to not be protected from disclosure. 798 Similarly, the identity of the originating party (george) is 799 extracted, and the local party database is consulted. Because 800 the authentication protocol for the party george is recorded 801 as noAuth, the received message is immediately accepted as 802 authentic. 804 The received message is fully processed only if the access 805 policy database local to the agent authorizes GetNext request 806 communications by the party george with respect to the 807 agent party gracie. The access policy database presented as 808 Table 3 authorizes such communications (as well as GetNext 809 operations). 811 When the received request is processed, a GetResponse message 812 is generated by the agent gracie for the originating peer 813 george. Because the authentication protocol for gracie 814 is recorded in the local party database as noAuth, the 815 GetResponse message generated by the manager is not 816 authenticated as to origin or integrity. Because, according 817 to the local database, the privacy protocol for the party 818 george is noPriv, the response message is not protected from 819 disclosure. Rather, as required by [1], the response message is 820 directed to the transport address from which the corresponding 821 request originated -- without regard for the transport address 822 associated with george in the local database. 824 When the generated response is received by the manager, the 825 identity of the party to which it is directed (george) is extracted 826 from the message, and the manager consults its local database 827 of party information. Because the privacy protocol for the party 828 george is recorded as noPriv, the received response is assumed 829 not to be protected from disclosure. Similarly, the identity of 830 the originating party (gracie) is extracted, and the local party 831 database is consulted. Because the authentication protocol for 832 the party gracie is recorded as noAuth, the received response 833 is immediately accepted as authentic. 835 The received message is fully processed only if the access 836 policy database local to the agent authorizes GetResponse 837 communications by the party gracie with respect to the 838 manager party george. The access policy database presented 839 as Table 3 authorizes such response messages (as well as Trap 840 messages). 842 3.2 Secure Minimal Agent Configuration 844 This section presents an example configuration for a secure, 845 minimal SNMP agent that interacts with a single SNMP 846 management station. Table 4 presents information about 847 SNMP parties that is known both to the minimal agent and 848 to the manager, while Table 5 presents similarly common 849 information about the local access policy. 851 The interaction of manager and agent in this configuration is 852 very similar to that sketched above for the non-secure minimal 853 agent -- except that all protocol messages are authenticated 854 as to origin and integrity and protected from disclosure. This 855 example requires encryption in order to support distribution of 856 secret keys via the SNMP itself. A more elaborate example 857 comprising an additional pair of SNMP parties could support 858 the exchange of non-secret information in authenticated 859 messages without incurring the cost of encryption. 861 As represented in Table 4, the example agent party operates 862 at UDP port 161 at IP address 1.2.3.4 using the party identity 863 ollie; the example manager operates at UDP port 2001 at IP 864 address 1.2.3.5 using the identity stan. At minimum, a secure 865 SNMP agent implementation must provide for administrative 866 configuration (and non-volatile storage) of relevant information 867 Identity ollie stan 868 (agent) (manager) 869 Domain rfc1157 rfc1157 870 Address 1.2.3.4, 161 1.2.3.5, 2001 871 Proxied Party noProxy noProxy 872 Auth Prot md4AuthProt md4AuthProt 873 Auth Priv Key "ABCD" "EFGH" 874 Auth Pub Key "" "" 875 Auth Clock 0 0 876 Auth Last Msg 0 0 877 Auth Lifetime 500 500 878 Priv Prot desPrivProt desPrivProt 879 Priv Priv Key "JKLM" "QRST" 880 Priv Pub Key "" "" 882 Table 4: Party Information for Secure Minimal Agent 884 Target Subject Privileges 885 ollie stan 3 886 stan ollie 20 888 Table 5: Access Information for Secure Minimal Agent 890 about two SNMP parties: itself and a remote peer. Both 891 ollie and stan authenticate all messages that they generate 892 by using the SNMP authentication protocol md4AuthProt 893 and their distinct, private authentication keys. Although these 894 private authentication key values ("ABCD" and "EFGH") are 895 presented here for expository purposes, knowledge of private 896 authentication keys is not normally afforded to human beings 897 and is confined to those portions of the protocol implementation 898 that require it. 900 Using the md4AuthProt, the public authentication key 901 for each SNMP party is irrelevant. Also, because the 902 md4AuthProt is symmetric in character, the private 903 authentication key for each party must be known to another 904 SNMP party with which authenticated communication is 905 desired. In contrast, asymmetric (public key) authentication 906 protocols would not depend upon sharing of a private key for 907 their operation. Although the administrative model set forth 908 here can easily accommodate asymmetric protocols, none are 909 currently defined for use with the SNMP. 911 All protocol messages originated by the party stan are 912 encrypted on transmission using the desPrivProt privacy 913 protocol and the private key "QRST"; they are decrypted 914 upon reception according to the same protocol and key. 915 Similarly, all messages originated by the party ollie are 916 encrypted on transmission using the desPrivProt protocol and 917 private authentication key "JKLM"; they are correspondingly 918 decrypted on reception. 920 3.3 Proxy Configuration 922 This section presents example configurations for SNMP 923 proxy management. On the one hand, proxy management 924 via a so-called foreign proxy configuration provides the 925 capability to manage non-SNMP devices; on the other, it 926 allows an administrator to shift the computational burden 927 of rich management functionality away from network devices 928 whose primary task is not management, via a native proxy 929 configuration. Among a variety of other benefits, to the extent 930 that SNMP proxy agents function as points of aggregation for 931 management information, configurations of this sort may also 932 reduce the bandwidth requirements of large-scale management 933 activities. 935 3.3.1 Foreign Proxy Configuration 937 This section presents an example configuration by which a 938 SNMP management station may manage network elements 939 that do not themselves support the SNMP. This configuration 940 centers on a SNMP proxy agent that performs SNMP 941 management operations by communicating with a non-SNMP 942 device using a proprietary protocol. 944 Table 6 presents information about SNMP parties that is 945 recorded in the local database of the SNMP proxy agent. 946 Table 7 presents information about SNMP parties that is 947 recorded in the local database of the SNMP management 948 station. Table 8 presents information about the access policy 949 specified by the local administration. 951 As represented in Table 6, the proxy agent party operates at 952 UDP port 161 at IP address 1.2.3.5 using the party identity 953 moe; the example manager operates at UDP port 2002 at 954 IP address 1.2.3.4 using the identity larry. Both larry 955 and moe authenticate all messages that they generate by 956 using the protocol md4AuthProt and their distinct, private 957 authentication keys. Although these private authentication 958 key values ("ABCD" and "EFGH") are presented here for 959 expository purposes, knowledge of private keys is not normally 960 afforded to human beings and is confined to those portions of 961 the protocol implementation that require it. 963 Using the md4AuthProt, the public authentication key 964 for each SNMP party is irrelevant. Also, because the 965 md4AuthProt is symmetric in character, the private 966 Identity larry moe curly 967 (manager) (proxy) (proxied) 968 Domain rfc1157 rfc1157 acmeMgmtPrtcl 969 Address 1.2.3.4, 2002 1.2.3.5, 161 0x98765432 970 Proxied Party noProxy curly noProxy 971 Auth Prot md4AuthProt md4AuthProt noAuth 972 Auth Priv Key "ABCD" "EFGH" "" 973 Auth Pub Key "" "" "" 974 Auth Clock 0 0 0 975 Auth Last Msg 0 0 0 976 Auth Lifetime 500 500 0 977 Priv Prot noPriv noPriv noPriv 978 Priv Priv Key "" "" "" 979 Priv Pub Key "" "" "" 981 Table 6: Party Information for Proxy Agent 983 Identity larry moe 984 (manager) (proxy) 985 Domain rfc1157 rfc1157 986 Address 1.2.3.4, 2002 1.2.3.5, 161 987 Proxied Party noProxy noProxy 988 Auth Prot md4AuthProt md4AuthProt 989 Auth Priv Key "ABCD" "EFGH" 990 Auth Pub Key "" "" 991 Auth Clock 0 0 992 Auth Last Msg 0 0 993 Auth Lifetime 500 500 994 Priv Prot noPriv noPriv 995 Priv Priv Key "" "" 996 Priv Pub Key "" "" 998 Table 7: Party Information for Management Station 1000 authentication key for each party must be known to another 1001 SNMP party with which authenticated communication is 1002 desired. In contrast, asymmetric (public key) authentication 1003 protocols would not depend upon sharing of a private key for 1004 their operation. Although the administrative model set forth 1005 here can easily accommodate asymmetric protocols, none are 1006 currently defined for use with the SNMP. 1008 Although all SNMP agents that use cryptographic keys in 1009 their communication with other protocol entities will almost 1010 certainly engage in private SNMP exchanges to distribute those 1011 keys, in order to simplify this example, neither the management 1012 station nor the proxy agent sends or receives private SNMP 1013 communications. Thus, the privacy protocol for each of them 1014 is recorded as noPriv. 1016 The party curly does not send or receive SNMP protocol 1017 messages; rather, all communication with that party proceeds 1018 via a hypothetical proprietary protocol identified by the 1019 value acmeMgmtPrtcl. Because the party curly does not 1020 participate in the SNMP, many of the attributes recorded for 1021 that party in a local database are ignored. 1023 In order to interrogate the proprietary device associated with 1024 the party curly, the management station larry constructs a 1025 SNMP GetNext request and transmits it to the party moe 1026 operating (see Table 7) at UDP port 161, and IP address 1.2.3.5. 1027 This request is authenticated using the private authentication 1028 key "ABCD." 1030 When that request is received by the party moe, the originator 1031 of the message is verified as being the party larry by using 1032 local knowledge (see Table 6) of the private authentication key 1033 "ABCD." Because party larry is authorized to issue GetNext 1034 requests with respect to party moe by the relevant access 1035 control policy (Table 8), the request is accepted. Because 1036 the local database records the proxied party for party moe as 1037 curly, the request is satisfied by its translation into appropriate 1038 operations of the acmeMgmtPrtcl directed at party curly. 1039 These new operations are transmitted to the party curly at 1040 the address 0x98765432 in the acmeMgmtPrtcl domain. 1042 When and if the proprietary protocol exchange between the 1043 proxy agent and the proprietary device concludes, a SNMP 1044 GetResponse management operation is constructed by the 1045 SNMP party moe to represent the results. This response 1046 communication is authenticated as to origin and integrity 1047 using the authentication protocol md4AuthProt and private 1048 authentication key "EFGH" specified for transmissions from 1049 party moe. It is then transmitted the SNMP party larry 1050 operating at the management station at IP address 1.2.3.4 1051 and UDP port 2002 (the source address for the corresponding 1052 request). 1054 When this response is received by the party larry, the 1055 originator of the message is verified as being the party moe by 1056 using local knowledge (see Table 7) of the private authentication 1057 key "EFGH." Because party moe is authorized to issue Get 1058 responses with respect to party larry by the relevant access 1059 control policy (Table 8), the response is accepted, and the 1060 interrogation of the proprietary device is complete. 1062 It is especially useful to observe that the database of SNMP 1063 parties recorded at the proxy agent (Table 6) need be 1064 neither static nor configured exclusively by the management 1065 station. For instance, suppose that, in this example, the 1066 acmeMgmtPrtcl was a proprietary, MAC-layer mechanism 1067 for managing stations attached to a local area network. In such 1068 an environment, the SNMP party moe would reside at a SNMP 1069 proxy agent attached to such a LAN and could, by participating 1070 in the LAN protocols, detect the attachment and disconnection 1071 of various stations on the LAN. In this scenario, the SNMP 1072 proxy agent could easily adjust its local database of SNMP 1073 parties to support indirect management of the LAN stations 1074 by the SNMP management station. For each new LAN station 1075 detected, the SNMP proxy agent would add to its database 1076 both an entry analogous to that for party curly (representing 1077 the new LAN station itself) and an entry analogous to that for 1078 party moe (representing a proxy for that new station in the 1079 SNMP domain). 1081 By using the SNMP to interrogate the database of parties held 1082 locally by the SNMP proxy agent, a SNMP management station 1083 can discover and interact with new stations as they are attached 1084 to the LAN. 1086 3.3.2 Native Proxy Configuration 1088 This section presents an example configuration that supports 1089 SNMP native proxy operations -- indirect interaction between 1090 a SNMP agent and a management station that is mediated by 1091 a second SNMP (proxy) agent. 1093 This example configuration is highly similar to that presented 1094 in the discussion of SNMP foreign proxy in the previous 1095 section. In this example, however, the party associated with 1096 the identity curly receives messages via the SNMP, and, 1097 accordingly interacts with the SNMP proxy agent moe using 1098 authenticated SNMP communications. 1100 Table 9 presents information about SNMP parties that is 1101 recorded in the local database of the SNMP proxy agent. 1102 Table 7 presents information about SNMP parties that is 1103 recorded in the local database of the SNMP management 1104 station. Table 10 presents information about the access policy 1105 specified by the local administration. 1107 As represented in Table 9, the proxy agent party operates at 1108 UDP port 161 at IP address 1.2.3.5 using the party identity 1109 moe; the example manager operates at UDP port 2003 at 1110 IP address 1.2.3.4 using the identity larry; the proxied party 1111 operates at UDP port 161 at IP address 1.2.3.6 using the 1112 party identity curly. All three SNMP parties authenticate 1113 all messages that they generate as to origin and integrity by 1114 using the authentication protocol md4AuthProt and their 1115 distinct, private authentication keys. Although these private 1116 key values ("ABCD," "EFGH," and "JKLM") are presented 1117 here for expository purposes, knowledge of private keys is not 1118 Target Subject Privileges 1119 moe larry 3 1120 larry moe 20 1122 Table 8: Access Information for Foreign Proxy 1124 Identity larry moe curly 1125 (manager) (proxy) (proxied) 1126 Domain rfc1157 rfc1157 rfc1157 1127 Address 1.2.3.4, 2003 1.2.3.5, 161 1.2.3.6, 161 1128 Proxied Party noProxy curly noProxy 1129 Auth Prot md4AuthProt md4AuthProt md4AuthProt 1130 Auth Priv Key "ABCD" "EFGH" "JKLM" 1131 Auth Pub Key "" "" "" 1132 Auth Clock 0 0 0 1133 Auth Last Msg 0 0 0 1134 Auth Lifetime 500 500 500 1135 Priv Prot noPriv noPriv noPriv 1136 Priv Priv Key "" "" "" 1137 Priv Pub Key "" "" "" 1139 Table 9: Party Information for Proxy Agent 1141 Target Subject Privileges 1142 moe larry 3 1143 larry moe 20 1144 curly moe 3 1145 moe curly 20 1147 Table 10: Access Information for Native Proxy 1149 normally afforded to human beings and is confined to those 1150 portions of the protocol implementation that require it. 1152 In order to interrogate the proxied device associated with the 1153 party curly, the management station larry constructs a SNMP 1154 GetNext request and transmits it to the party moe operating 1155 (see Table 7) at UDP port 161, and IP address 1.2.3.5. This 1156 request is authenticated using the private authentication key 1157 "ABCD." 1159 When that request is received by the party moe, the originator 1160 of the message is verified as being the party larry by using 1161 local knowledge (see Table 9) of the private authentication key 1162 "ABCD." Because party larry is authorized to issue GetNext 1163 (and Get) requests with respect to party moe by the relevant 1164 access control policy (Table 10), the request is accepted. 1165 Because the local database records the proxied party for party 1166 moe as curly, the request is satisfied by its translation into 1167 a corresponding SNMP GetNext request directed from party 1168 moe to party curly. This new communication is authenticated 1169 using the private authentication key "EFGH" and transmitted 1170 to party curly at the IP address 1.2.3.6. 1172 When this new request is received by the party curly, the 1173 originator of the message is verified as being the party moe by 1174 using local knowledge (see Table 9) of the private authentication 1175 key "EFGH." Because party moe is authorized to issue 1176 GetNext (and Get) requests with respect to party curly by 1177 the relevant access control policy (Table 10), the request is 1178 accepted. Because the local database records the proxied party 1179 for party curly as noProxy, the GetNext request is satisfied 1180 by local mechanisms. A SNMP Get response representing 1181 the results of the query is then generated by party curly. 1182 This response communication is authenticated as to origin and 1183 integrity using the private authentication key "JKLM" and 1184 transmitted to party moe at IP address 1.2.3.5 (the source 1185 address for the corresponding request). 1187 When this response is received by party moe, the originator 1188 of the message is verified as being the party curly by using 1189 local knowledge (see Table 9) of the private authentication 1190 key "JKLM." Because party curly is authorized to issue Get 1191 responses with respect to party moe by the relevant access 1192 control policy (Table 10), the response is not rejected. Instead, 1193 it is translated into a GetNext response that corresponds to 1194 the original GetNext request from party larry. This response 1195 is authenticated as to origin and integrity using the private 1196 authentication key "EFGH" and is transmitted to the party 1197 larry at IP address 1.2.3.5 (the source address for the original 1198 request). 1200 When this response is received by the party larry, the 1201 originator of the message is verified as being the party moe by 1202 using local knowledge (see Table 7) of the private authentication 1203 key "EFGH." Because party moe is authorized to issue Get 1204 responses with respect to party larry by the relevant access 1205 control policy (Table 10), the response is accepted, and the 1206 interrogation is complete. 1208 3.4 Public Key Configuration 1210 This section presents an example configuration predicated upon 1211 a hypothetical security protocol. This hypothetical protocol 1212 would be based on asymmetric (public key) cryptography 1213 as a means for providing data origin authentication (but 1214 not protection against disclosure). This example illustrates 1215 the consistency of the administrative model with public key 1216 technology, and the extension of the example to support 1217 protection against disclosure should be apparent. 1219 The example configuration comprises a single SNMP agent that 1220 interacts with a single SNMP management station. Tables 11 1221 and 12 present information about SNMP parties that is by 1222 the agent and manager, respectively, while Table 5 presents 1223 information about the local access policy that is known to both 1224 manager and agent. 1226 As represented in Table 11, the example agent party 1227 Identity ollie stan 1228 (agent) (manager) 1229 Domain rfc1157 rfc1157 1230 Address 1.2.3.4, 161 1.2.3.5, 2004 1231 Proxied Party noProxy noProxy 1232 Auth Prot pkAuthProt pkAuthProt 1233 Auth Priv Key "ABCD" "" 1234 Auth Pub Key "" "efgh" 1235 Auth Clock 0 0 1236 Auth Last Msg 0 0 1237 Auth Lifetime 500 500 1238 Priv Prot noPriv noPriv 1239 Priv Priv Key "" "" 1240 Priv Pub Key "" "" 1242 Table 11: Party Information for Public Key Agent 1244 Identity ollie stan 1245 (agent) (manager) 1246 Domain rfc1157 rfc1157 1247 Address 1.2.3.4, 161 1.2.3.5, 2004 1248 Proxied Party noProxy noProxy 1249 Auth Prot pkAuthProt pkAuthProt 1250 Auth Priv Key "" "EFGH" 1251 Auth Pub Key "abcd" "" 1252 Auth Clock 0 0 1253 Auth Last Msg 0 0 1254 Auth Lifetime 500 500 1255 Priv Prot noPriv noPriv 1256 Priv Priv Key "" "" 1257 Priv Pub Key "" "" 1259 Table 12: Party Information for Public Key Management 1260 Station 1261 operates at UDP port 161 at IP address 1.2.3.4 using 1262 the party identity ollie; the example manager operates at 1263 UDP port 2004 at IP address 1.2.3.5 using the identity 1264 stan. Both ollie and stan authenticate all messages 1265 that they generate as to origin and integrity by using the 1266 hypothetical SNMP authentication protocol pkAuthProt and 1267 their distinct, private authentication keys. Although these 1268 private authentication key values ("ABCD" and "EFGH") are 1269 presented here for expository purposes, knowledge of private 1270 keys is not normally afforded to human beings and is confined 1271 to those portions of the protocol implementation that require 1272 it. 1274 In most respects, the interaction between manager and agent 1275 in this configuration is almost identical to that in the example 1276 of the minimal, secure SNMP agent described above. The 1277 most significant difference is that neither SNMP party in the 1278 public key configuration has knowledge of the private key by 1279 which the other party authenticates its transmissions as to their 1280 origin and integrity. Instead, for each received authenticated 1281 SNMP communication, the identity of the originator is verified 1282 by applying an asymmetric cryptographic algorithm to the 1283 received message together with the public authentication key 1284 for the originating party. Thus, in this configuration, the agent 1285 knows the manager's public key ("efgh") but not its private key 1286 ("EFGH"); similarly, the manager knows the agent's public key 1287 ("abcd") but not its private key ("ABCD"). 1289 For simplicity, privacy protocols are not addressed in this 1290 example configuration, although their use would be necessary 1291 to the secure, automated distribution of secret keys. 1293 4 Compatibility 1295 Ideally, all SNMP management stations and agents would 1296 communicate exclusively using the secure facilities described 1297 in this memo. In reality, many SNMP agents may implement 1298 only the insecure SNMP mechanisms described in [1] for some 1299 time to come. 1301 New SNMP agent implementations should never implement 1302 both the insecure mechanisms of [1] and the facilities described 1303 here. Rather, consistent with the SNMP philosophy, the 1304 burden of supporting both sorts of communication should fall 1305 entirely upon managers. Perhaps the best way to realize 1306 both old and new modes of communication is by the use of 1307 a SNMP proxy agent deployed locally on the same system 1308 with a management station implementation. The management 1309 station implementation itself operates exclusively by using the 1310 newer, secure modes of communication, and the local proxy 1311 agent translates the requests of the manager into older, insecure 1312 modes as needed. 1314 It should be noted that proxy agent implementations may 1315 require additional information beyond that described in this 1316 memo in order to accomplish the requisite translation tasks 1317 implicit in the definition of the proxy function. This 1318 information could easily be retrieved from a filestore. 1320 5 Security Considerations 1322 It is important to note that, in the example configuration 1323 for native proxy operations presented in this memo, the use 1324 of symmetric cryptography does not securely prevent direct 1325 communication between the SNMP management station and 1326 the proxied SNMP agent. 1328 While secure isolation of the management station and the 1329 proxied agent can, according to the administrative model set 1330 forth in this memo, be realized using symmetric cryptography, 1331 the required configuration is more complex and is not described 1332 in this memo. Rather, it is recommended that native proxy 1333 configurations that require secure isolation of management 1334 station from proxied agent be implemented using security 1335 protocols based on asymmetric (or "public key") cryptography. 1337 In order to participate in the administrative model set forth in 1338 this memo, SNMP implementations must support local, non- 1339 volatile storage of the local party database. Accordingly, every 1340 attempt has been made to minimize the amount of non-volatile 1341 storage required. 1343 References 1345 [1] Jeffrey D. Case, Mark S. Fedor, Martin L. Schoffstall, and 1346 James R. Davin. A Simple Network Management Protocol. 1347 Request for Comments 1157, DDN Network Information 1348 Center, SRI International, May 1990. 1350 [2] Marshall T. Rose and Keith McCloghrie. Structure and 1351 Identification of Management Information for TCP/IP 1352 based internets. Request for Comments 1155, DDN Network 1353 Information Center, SRI International, May 1990. 1355 [3] Information Processing -- Open Systems Interconnection -- 1356 Specification of Basic Encoding Rules for Abstract Syntax 1357 Notation One (ASN.1). International Organization for 1358 Standardization/International Electrotechnical Institute, 1359 1987. International Standard 8825. 1361 Contents 1363 1 Introduction 1 1365 2 Elements of the Model 2 1367 2.1 SNMP Party 2 1369 2.2 SNMP Protocol Entity 6 1371 2.3 SNMP Management Station 6 1373 2.4 SNMP Agent 7 1375 2.5 View Subtree 7 1377 2.6 MIB View 7 1379 2.7 SNMP Management Communication 8 1381 2.8 SNMP Authenticated Management Communica- 1382 tion 9 1384 2.9 SNMP Private Management Communication 10 1386 2.10 SNMP Management Communication Class 11 1388 2.11 SNMP Access Control Policy 12 1390 2.12 SNMP Proxy Party 13 1392 2.13 Procedures 15 1394 2.13.1 Generating a Request 15 1396 2.13.2 Processing a Received Communication 16 1398 2.13.3 Generating a Response 19 1400 3 Application of the Model 20 1402 3.1 Non-Secure Minimal Agent Configuration 20 1403 3.2 Secure Minimal Agent Configuration 23 1405 3.3 Proxy Configuration 25 1407 3.3.1 Foreign Proxy Configuration 26 1409 3.3.2 Native Proxy Configuration 30 1411 3.4 Public Key Configuration 33 1413 4 Compatibility 35 1415 5 Security Considerations 36