idnits 2.17.1 draft-ietf-snmpv2-scm-ds-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-23) 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 document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** 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. == 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 117 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 148 has weird spacing: '...stParty use...' == Line 149 has weird spacing: '...rcParty use...' == Line 156 has weird spacing: '...rotocol scm...' == Line 160 has weird spacing: '...rotocol noP...' == Line 242 has weird spacing: '... value mean...' == (15 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 1995) is 10632 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: '64' is mentioned on line 1240, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' Summary: 11 errors (**), 0 flaws (~~), 8 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 draft Simplified Configuration Model March 1995 4 The Simplified Configuration Model for SNMPv2 6 19 March 1995 | 8 draft-ietf-snmpv2-scm-ds-00.txt | 10 Steven Waldbusser 11 Carnegie Mellon University 12 waldbusser@cmu.edu 14 Jeffrey D. Case 15 SNMP Research, Inc. 16 case@snmp.com 18 Keith McCloghrie 19 Cisco Systems, Inc. 20 kzm@cisco.com 22 Marshall T. Rose 23 Dover Beach Consulting, Inc. 24 mrose@dbc.mtview.ca.us 26 Status of this Memo 28 This document is an Internet Draft. Internet Drafts are working 29 documents of the Internet Engineering Task Force (IETF), its Areas, and 30 its Working Groups. Note that other groups may also distribute working 31 documents as Internet Drafts. 33 Internet Drafts are valid for a maximum of six months and may be 34 updated, replaced, or obsoleted by other documents at any time. It is 35 inappropriate to use Internet Drafts as reference material or to cite 36 them other than as a "work in progress". 38 draft Simplified Configuration Model March 1995 40 1. Introduction 42 A network management system contains: several (potentially many) nodes, 43 each with a processing entity, termed an agent, which has access to 44 management instrumentation; at least one management station; and, a 45 management protocol, used to convey management information between the 46 agents and management stations. Operations of the protocol are carried 47 out under an administrative framework which defines both authentication 48 and authorization policies. 50 Network management stations execute management applications which 51 monitor and control network elements. Network elements are devices such 52 as hosts, routers, terminal servers, etc., which are monitored and 53 controlled through access to their management information. 55 The Administrative Infrastructure for SNMPv2 [1] defines how the 56 administrative framework is applied to realize effective network 57 management in a variety of configurations and environments. It is the 58 purpose of this document, the Simplified Configuration Model for SNMPv2, 59 to define one such deployment strategy using the administrative 60 framework. 62 1.1. A Note on Terminology 64 For the purpose of exposition, the original Internet-standard Network 65 Management Framework, as described in RFCs 1155, 1157, and 1212, is 66 termed the SNMP version 1 framework (SNMPv1). The current framework is 67 termed the SNMP version 2 framework (SNMPv2). 69 2. Overview 71 The model describe here is based on the notion of creating transient 72 "management sessions" for use by a management application. Each session 73 is initialized by consulting a user profile, which has been previously 74 configured at the agent. The profile specifies such information as 75 authentication and authorization information, along with a maximum time 76 that a session may be inactive before the agent destroys it. 78 When a session is created, the SNMPv2 parties and corresponding access 79 control information are dynamically created. These parties are used to 80 perform protocol operations. If the management application completes 81 before the management session expires, it may explicitly destroy the 82 session. Regardless, when a session is destroyed, the corresponding 83 draft Simplified Configuration Model March 1995 85 resources (e.g., parties and ACLs), are deleted by the agent. 87 Pictorially: 89 management 90 station agent 91 ---------- ----- 92 user "logs in" 94 request to establish a 95 ----------------------------------------> 96 session for the user 97 agent consults 98 profile for user 99 and creates session 100 <---------------------------------------- 101 identity of session 103 ... 105 user requests operations 107 SNMP requests 108 ----------------------------------------> 109 agent performs 110 operations 111 <---------------------------------------- 112 SNMP responses 114 ... 116 user "logs out" 118 request to destroy the 119 ----------------------------------------> 120 user's session 121 agent deletes 122 session 123 <---------------------------------------- 124 confirmation 126 draft Simplified Configuration Model March 1995 128 3. User-based Maintenance Functions 130 Maintenance functions are defined in [1] as a special means for 131 providing controlled access to an SNMPv2 engine in order to perform 132 operations which are not easily accomplished using the administrative 133 infrastructure. The Simplified Configuration Model defines a class of 134 maintenance functions termed "user-based maintenance functions". As 135 with all maintenance functions, the "parties" and "contexts" employed 136 are not accessible to entities which make use of an SNMPv2 engine, nor 137 are they visible through the SNMPv2-PARTY-MIB [2]. These artifacts of 138 SNMPv2's administrative maintenance facility are not actual parties or 139 contexts. 141 A user-based maintenance function is identified when the context of a 142 management communication has the value userMaintContext, and the source 143 and destination parties identically have the form 144 userMaintParty., where corresponds to an active entry | 145 in the | 146 scmUserTable, i.e., 148 dstParty userMaintParty. 149 srcParty userMaintParty. 150 context userMaintContext 152 Each valid userMaintParty has these characteristics: 154 party value 155 ----- ----- 156 AuthProtocol scmUserAuthProtocol 157 AuthClock '7fffffff'H 158 AuthPrivate password_to_key(scmUserAuthProtocol,scmUserPassword) 159 AuthPublic ''H 160 PrivProtocol noPriv 162 To determine the algorithm that maps scmUserPassword to an 163 authentication key, consult the definition of scmUserAuthProtocol in 164 Section 6. Note that since the clock value for these parties is at the 165 maximum, no replay protection is afforded when a user-based maintenance 166 function is performed. Further note that these parties are configured 167 indirectly, by manipulating the scmUserTable -- it is not possible to 168 specify the instances corresponding to a userMaintParty in an SNMP 169 operation. 171 The access allowed to any pairing of userMaintParty. and 172 userMaintContext is statically defined to be read/write access to all 173 draft Simplified Configuration Model March 1995 175 instances in one (and only one) subtree, userMaintActions. 177 draft Simplified Configuration Model March 1995 179 4. Session Creation Algorithm 181 Sessions are created when the management station issues a user-based 182 maintenance function, which identifies a user configured at the agent. 184 Pictorially: 186 management 187 station agent 188 ---------- ----- 189 user supplies 190 identity and 191 password 193 user-based maintenance function 194 ----------------------------------------> 195 parameters: transport domain and addresses 196 manager's maximum message size 197 manager desires traps 198 manager's desired inactivity 199 time for session 201 agent creates parties 202 and ACLs which realize 203 user's capabilities, 204 secrets for parties are 205 calculated using user's 206 password and a one-time 207 value 209 user-based maintenance function 210 <---------------------------------------- 211 parameters: result indicator 212 identity of session (parties) 213 agent's maximum message size 214 actual inactivity time for 215 session 216 one-time values for secrets 218 manager mirrors 219 parties/ACLs 220 created by agent 222 draft Simplified Configuration Model March 1995 224 4.1. Step 1: Manager Requests Creation - 226 The manager performs a user-based maintenance function consisting of a | 227 getRequest operation containing a variable-binding supplying the | 228 parameters of the session to be created. An agent is not required to | 229 support such a getRequest hvaing more than one variable-binding. The | 230 variable-binding is: | 232 userMaintCreate...... | 234 where: 236 237 identifies the transport domain to be used for the created parties, 238 encoded as a single sub-identifier, specifically the value of the 239 last sub-identifier of a transport domain defined under snmpDomains 240 [3]: 242 value meaning 243 ----- -------- 244 1 snmpUDPDomain 245 2 snmpCLNSDomain 246 3 snmpCONSDomain 247 4 snmpDDPDomain 248 5 snmpIPXDomain 250 | 251 identifies the transport address to be used when the agent sends 252 traps to the manager, encoded as 1+N sub-identifiers, where the 253 first sub-identifier indicates the length of the address, and the 254 remaining sub-identifiers correspond to one octet from that address 255 ([3] defines the address format corresponding to each transport 256 domain). If the manager doesn't desire traps, then this field is 257 encoded as a single sub-identifier having the value zero. 259 | 260 identifies the transport address that the agent listens to when the 261 manager sends traffic, encoded as 1+N sub-identifiers, where the 262 first sub-identifier indicates the length of the address, and the 263 remaining sub-identifiers correspond to one octet from that address 264 ([3] defines the address format corresponding to each transport 265 domain). 267 | 268 identifies the maximum message size which the manager can receive, 270 draft Simplified Configuration Model March 1995 272 encoded as 1 sub-identifier in the range 484 to 65507. 274 | 275 identifies whether the manager wishes to receive traps from the 276 agent, encoded as a single sub-identifier: 278 value meaning 279 ----- -------- 280 0 no traps 281 1 send traps using without authentication or privacy 282 2 send traps using authentication 283 3 send traps using authentication and privacy 285 | 286 identifies the manager's desire for minimum number of contiguous 287 seconds of inactivity for all parties and access control entries 288 created before they are destroyed by the agent, encoded as 1 sub- 289 identifier in the range 1 to 2147483647. 291 4.2. Step 2: Agent Analyzes Request 293 The agent receives the get request from the manager and identifies it as 294 a user-based maintenance function to create a session. 296 The agent examines the parameter encoded in the instance-identifier of 297 the one (and only) variable-binding of the get operation, and if any are 298 unacceptable, it generates a response to the get operation, containing a 299 single octet value: 301 value meaning 302 ----- -------- 303 1 bad tDomain value 304 2 bad mAddr value | 305 3 bad aAddr value | 306 4 bad mMMS value | 307 5 bad mTraps value | 308 6 bad mLinger value | 310 draft Simplified Configuration Model March 1995 312 Otherwise, the agent retrieves the following information: 314 (1) the entry in the scmUserTable which corresponds to the user 315 identified in the management communication; 317 (2) its 12-octet administratively-unique identifier, agentID [2]; | 318 and, 320 (3) the maximum message size which the agent can receive, aMMS. | 322 The agent calculates actualLinger by taking the minimum of mLinger and | 323 the corresponding instance of scmUserLinger. If the value of 324 actualLinger is 2147483647, then the agent sets creationType to 325 nonVolatile, otherwise creationType is set to volatile. 327 The agent computes an integer, sessionID, such that there are no parties 328 known to the agent whose name is any of: 330 scmAgentNoAuthPartyID.. 331 scmManagerNoAuthPartyID.. 332 scmAgentAuthPartyID.. 333 scmManagerAuthPartyID.. 334 scmAgentPrivPartyID.. 335 scmManagerPrivPartyID.. 337 where identifies the agent's unique identifier, encoded as 12 338 sub-identifiers. 340 The agent generates an unpredictable 128-bit quantity, aPad. The agent 341 computes aSecret, based on an algorithm which uses the pairing of the 342 value of partyAuthPrivate for userMaintParty. and aPad -- 343 consult the definition of scmUserAuthProtocol in Section 6. 345 If the value of scmUserPrivProtocol is any value other than noPriv, the 346 agent generates a second unpredictable 128-bit quantity, pPad, and the 347 agent computes pSecret, based on an algorithm which uses the pairing of 348 the value of partyAuthPrivate for userMaintParty. and pPad -- 349 consult the definition of scmUserAuthProtocol in Section 6. 351 draft Simplified Configuration Model March 1995 353 4.3. Step 3: Agent Creates Parties 355 The agent creates four parties named as: 357 scmAgentNoAuthPartyID.. 358 scmManagerNoAuthPartyID.. 359 scmAgentAuthPartyID.. 360 scmManagerAuthPartyID.. 362 where: 364 365 identifies the agent's agentID [2], | 366 encoded as 12 sub-identifiers. 368 369 identifies this session's sessionID, encoded as 1 sub-identifier. 371 The parties are created with these values: 373 Agent Manager Agent Manager 374 party noAuth noAuth Auth Auth 375 ----- ------- ------- ------- ------- 376 TDomain tDomain tDomain tDomain tDomain 377 TAddress aAddr mAddr aAddr mAddr | 378 MaxMessageSize aMMS mMMS aMMS mMMS | 379 Local true false true false 380 AuthProtocol noAuth noAuth scmUserAuth scmUserAuth 381 AuthClock 0 0 0 0 382 AuthPrivate ''H ''H aSecret aSecret 383 AuthPublic ''H ''H ''H ''H 384 PrivProtocol noPriv noPriv noPriv noPriv 385 PrivPrivate ''H ''H ''H ''H 386 PrivPublic ''H ''H ''H ''H 387 StorageType creationType creationType creationType creationType 388 Status active active active active 389 draft Simplified Configuration Model March 1995 391 If the value of scmUserPrivProtocol is any value other than noPriv, then 392 the agent also creates two more parties named as: 394 scmAgentPrivPartyID.. 395 scmManagerPrivPartyID.. 397 and having these values: 399 Agent Manager 400 party Priv Priv 401 ----- ------- ------- 402 TDomain tDomain tDomain 403 TAddress aAddr mAddr | 404 MaxMessageSize aMMS mMMS | 405 Local true false 406 AuthProtocol scmUserAuth scmUserAuth 407 AuthClock 0 0 408 AuthPrivate aSecret aSecret 409 AuthPublic ''H ''H 410 PrivProtocol scmUserPriv scmUserPriv 411 PrivPrivate pSecret pSecret 412 PrivPublic ''H ''H 413 StorageType creationType creationType 414 Status active active 415 draft Simplified Configuration Model March 1995 417 4.4. Step 4: Agent Authorizes Parties 419 For each entry in the scmCapTable whose value of scmCapIndex equals the 420 value of scmUserCapIndex for the user identified in the management 421 communication, the agent performs Step 4a and 4b. 423 4.4.1. Step 4a: Agent Checks Contexts 425 If the context named as: 427 scmContextID... 429 where: 431 432 identifies the agent's agentID, encoded as 12 sub-identifiers. 434 435 identifies the value of scmCapCtxLocalTime, encoded as 1 sub- 436 identifier. 438 439 identifies the value of scmCapCtxLocalEntity, encoded as N 440 (possibly 0) sub-identifiers. 442 does not exist, then the agent creates it: 444 context value 445 ------- ----- 446 Local true 447 View 1 448 LocalEntity scmCapCtxLocalEntity 449 LocalTime scmCapCtxLocalTime 450 (expressed as the equivalent OBJECT IDENTIFIER) 451 ProxyDstParty 0.0 452 ProxySrcParty 0.0 453 ProxyContext 0.0 454 StorageType creationType 455 Status active 456 draft Simplified Configuration Model March 1995 458 4.4.2. Step 4b: Agent Creates Access Control Entries 460 The agent creates 2 entries in the acTable: 462 ac value for ACL #1 value for ACL #2 463 ----- ---------------- ---------------- 464 Target Agent noAuth Agent Auth 465 Subject Manager noAuth Manager Auth 466 Context context from Step 4a context from Step 4a 467 Privileges scmCapNPrivileges scmCapAPrivileges 468 ReadViewIndex scmCapNReadView scmCapAReadView 469 WriteViewIndex scmCapNWriteView scmCapAWriteView 470 StorageType creationType creationType 471 Status active active 473 If the value of mTraps is 1, | 474 then 128 is added to the value of acPrivileges for ACL #1; otherwise, if | 475 the value of mTraps is 2, | 476 then 128 is added to the value of acPrivileges for ACL #2. 478 If the value of scmUserPrivProtocol is any value other than noPriv, then 479 the agent creates a third entry in the acTable: 481 ac value for ACL #3 482 ----- ---------------- 483 Target Agent Priv 484 Subject Manager Priv 485 Context context from Step 4a 486 Privileges scmCapPPrivileges 487 ReadViewIndex scmCapPReadView 488 WriteViewIndex scmCapPWriteView 489 StorageType creationType 490 Status active 492 If the value of mTraps is 3, | 493 then 128 is added to the value of acPrivileges for ACL #3. 495 When an agent already has many activated user sessions, it is | 496 undesirable for the creation of a new session to be denied due to the | 497 inability of the agent to create the additional parties or access | 498 control entries. | 499 As such, if an agent having many active user sessions is unable to | 500 perform Steps 3 or 4 due to lack of party-related resources, the agent | 501 should begin destroying sessions, | 502 in the order least recently used, until sufficient party-related 503 draft Simplified Configuration Model March 1995 505 resources exist to perform Steps 3 and 4. 507 draft Simplified Configuration Model March 1995 509 4.5. Step 5: Agent Responds 511 The agent generates a response to the get operation, an octet string 512 having this value: 514 515 a single octet, containing the value 0. 517 518 12 octets, containing the agent's 12-octet administratively-unique 519 identifier. 521 522 4 octets, encoded as an unsigned integer using network-byte 523 ordering (big-endian encoding). 525 526 2 octets, encoded as an unsigned integer using network-byte 527 ordering (big-endian encoding). 529 530 4 octets, encoded as an unsigned integer using network-byte 531 ordering (big-endian encoding). 533 534 16 octets. 536 537 16 octets. 539 If the value of scmUserPrivProtocol is noPriv, then no pPad value is 540 sent (the aPad value completes the response). 542 4.6. Step 6: Agent Starts Initial Inactivity Timer 544 Upon sending the response to the get operation, the agent starts a 5 + 545 minute timer. If any of the session's 2 or 4 authenticated parties are + 546 used before the timer expires, then the timer is cancelled. Otherwise, + 547 if the timer expires before their use, then all 4 or 6 of the session's + 548 parties and their associated access control entries are immediately + 549 deleted. + 551 By use of this timeout, a created session for which the agent-generated + 552 response is lost, is deleted after after 5 minutes of non-use. + 553 draft Simplified Configuration Model March 1995 555 4.7. Step 7: Manager Analyzes Response + 557 The manager receives the response from the agent and correlates to its 558 earlier request. It then creates mirrors of the parties and access 559 control entries described in Steps 3 and 4b, except that the values of 560 partyLocal are inverted. 562 The manager should then issue an authenticated request which uses the + 563 created session. This usage serves to confirm that the session has been + 564 successfully created, and to cancel the agent's initial inactivity (5- + 565 minute) timer. + 566 draft Simplified Configuration Model March 1995 568 5. Session Destruction Algorithm 570 Sessions are destroyed when the management station issues a user-based 571 maintenance function, which identifies a user configured at the agent. 573 Pictorially: 575 management 576 station agent 577 ---------- ----- 578 application terminates 580 user-based maintenance function 581 ----------------------------------------> 582 parameters: identity of session 584 agent removes parties 585 and ACLs 587 user-based maintenance function 588 <---------------------------------------- 589 parameters: result indicator 591 manager removes 592 mirrored parties/ACLs 594 draft Simplified Configuration Model March 1995 596 5.1. Step 1: Manager Requests Destruction 598 The manager performs a user-based maintenance function consisting of a 599 set operation for 601 userMaintDestroy.0 603 setting it to an octet string having this value: 605 607 where: 609 610 12 octets, containing the agent's 12-octet administratively-unique 611 identifier. 613 614 4 octets, encoded as an unsigned integer using network-byte 615 ordering (big-endian encoding). 617 5.2. Step 2: Agent Analyzes Request and Responds 619 The agent receives the set request from the manager and identifies it as 620 a user-based maintenance function to destroy a session. 622 The agent locates those parties whose name is any of: 624 scmAgentNoAuthPartyID.. 625 scmManagerNoAuthPartyID.. 626 scmAgentAuthPartyID.. 627 scmManagerAuthPartyID.. 628 scmAgentPrivPartyID.. 629 scmManagerPrivPartyID.. 631 If no such parties exist, or if the partyStorageType of any such party 632 isn't volatile, or if the parties weren't created by the user 633 corresponding to this user-based management function, then the agent 634 generates an inconsistentValue response. Otherwise, the agent generates 635 a noError response to the set operation, and deletes all parties and | 636 associated access control entries. | 637 draft Simplified Configuration Model March 1995 639 5.3. Step 3: Manager Analyzes Response 641 The manager receives the response from the agent and correlates to its 642 earlier request. It then destroys the mirrors of the parties and access 643 control entries that it created earlier. 645 draft Simplified Configuration Model March 1995 647 6. Definitions 649 SNMPv2-SCM-MIB DEFINITIONS ::= BEGIN 651 IMPORTS 652 MODULE-IDENTITY, OBJECT-TYPE, snmpModules 653 FROM SNMPv2-SMI 654 DisplayString, RowStatus 655 FROM SNMPv2-TC 656 AccessPrivileges, StorageType, v2md5AuthProtocol, noPriv | 657 FROM SNMPv2-PARTY-MIB; 659 scmMIB MODULE-IDENTITY 660 LAST-UPDATED "9503180000Z" | 661 ORGANIZATION "IETF SNMPv2 Working Group" | 662 CONTACT-INFO 663 " Keith McCloghrie 665 Postal: Cisco Systems, Inc. 666 170 West Tasman Drive, 667 San Jose, CA 95134-1706 668 US 670 Tel: +1 408 526 5260 672 E-mail: kzm@cisco.com" 673 DESCRIPTION 674 "The MIB module for the Simplified Configuration Model." 675 ::= { snmpModules 4 } | 677 draft Simplified Configuration Model March 1995 679 -- administrative assignments 681 scmAdmin OBJECT IDENTIFIER ::= { scmMIB 1 } 683 -- parties under these subtrees are created dynamically by the agent 684 scmPartyID OBJECT IDENTIFIER ::= { scmAdmin 1 } 686 scmAgentNoAuthPartyID 687 OBJECT IDENTIFIER ::= { scmPartyID 1 } 688 scmManagerNoAuthPartyID 689 OBJECT IDENTIFIER ::= { scmPartyID 2 } 690 scmAgentAuthPartyID 691 OBJECT IDENTIFIER ::= { scmPartyID 3 } 692 scmManagerAuthPartyID 693 OBJECT IDENTIFIER ::= { scmPartyID 4 } 694 scmAgentPrivPartyID 695 OBJECT IDENTIFIER ::= { scmPartyID 5 } 696 scmManagerPrivPartyID 697 OBJECT IDENTIFIER ::= { scmPartyID 6 } 699 -- context under this subtree might be created by the agent, 700 -- but normally exist 702 scmContextID OBJECT IDENTIFIER ::= { scmAdmin 2 } 704 -- these are employed by user-based maintenance functions 706 userMaintParty OBJECT IDENTIFIER ::= { scmAdmin 3 } 708 userMaintContext 709 OBJECT IDENTIFIER ::= { 0 1 } 711 draft Simplified Configuration Model March 1995 713 -- object assignments 715 scmMIBObjects OBJECT IDENTIFIER ::= { scmMIB 2 } 717 -- user table 719 scmUserTable OBJECT-TYPE 720 SYNTAX SEQUENCE OF ScmUserEntry 721 MAX-ACCESS not-accessible 722 STATUS current 723 DESCRIPTION 724 "The user table." 725 ::= { scmMIBObjects 1 } 727 scmUserEntry OBJECT-TYPE 728 SYNTAX ScmUserEntry 729 MAX-ACCESS not-accessible 730 STATUS current 731 DESCRIPTION 732 "A conceptual row in the user table." 733 INDEX { IMPLIED scmUserID } 734 ::= { scmUserTable 1 } 736 ScmUserEntry ::= 737 SEQUENCE { 738 scmUserID DisplayString, 739 scmUserPassword OCTET STRING, 740 scmUserAuthProtocol OBJECT IDENTIFIER, 741 scmUserPrivProtocol OBJECT IDENTIFIER, 742 scmUserCapIndex INTEGER, 743 scmUserLinger INTEGER, 744 scmUserStorageType StorageType, 745 scmUserStatus RowStatus 746 } 748 draft Simplified Configuration Model March 1995 750 scmUserID OBJECT-TYPE 751 SYNTAX DisplayString (SIZE (1..64)) 752 MAX-ACCESS not-accessible 753 STATUS current 754 DESCRIPTION 755 "The identity of the user corresponding to this conceptual 756 row." 757 ::= { scmUserEntry 1 } 759 scmUserPassword OBJECT-TYPE 760 SYNTAX OCTET STRING (SIZE (8..128)) 761 MAX-ACCESS read-create 762 STATUS current 763 DESCRIPTION 764 "The user's password. On retrieval, this object has the 765 value of 8 zero-valued octets." 766 ::= { scmUserEntry 2 } 768 draft Simplified Configuration Model March 1995 770 scmUserAuthProtocol OBJECT-TYPE 771 SYNTAX OBJECT IDENTIFIER 772 MAX-ACCESS read-create 773 STATUS current 774 DESCRIPTION 775 "The authentication protocol for this user. This object may 776 never take the value noAuth. 778 Once an instance of this object is created, its value can 779 not be changed. 781 If the value of this object is v2md5AuthProtocol, then two 782 algorithms are defined: 784 To map scmUserPassword to an authentication key for the 785 corresponding userMaintParty: form a string of length 786 1,048,576 octets by repeating the value of scmUserPassword 787 as often as necessary, truncating accordingly, and use the 788 resulting string as the input to the MD5 algorithm. The 789 resulting digest is the authentication key for 790 userMaintParty.. 792 To map the pairing of a user's authentication key and the 793 aPad quantity to the authentication key for a newly 794 created party: append aPad to the value of 795 partyAuthPrivate for userMaintParty., and use the 796 resulting string as the input to the MD5 algorithm. The 797 resulting digest is the authentication key for the newly 798 created party." 799 DEFVAL { v2md5AuthProtocol } 800 ::= { scmUserEntry 3 } 802 draft Simplified Configuration Model March 1995 804 scmUserPrivProtocol OBJECT-TYPE 805 SYNTAX OBJECT IDENTIFIER 806 MAX-ACCESS read-create 807 STATUS current 808 DESCRIPTION 809 "The privacy protocol for this user. The value noPriv 810 signifies that messages received by the party are not 811 protected. 813 Once an instance of this object is created, its value can 814 not be changed. 816 If the value of this object is desPrivProtocol, then one 817 algorithm is defined: 819 To map the pairing of a user's authentication key and the 820 pPad quantity to the privacy key for a newly created 821 party: append pPad to the value of partyAuthPrivate for 822 userMaintParty., and use the resulting string as 823 the input to the MD5 algorithm. The resulting digest is 824 the privacy key for the newly created party." 825 DEFVAL { noPriv } 826 ::= { scmUserEntry 4 } 828 scmUserCapIndex OBJECT-TYPE 829 SYNTAX INTEGER (1..2147483647) 830 MAX-ACCESS read-create 831 STATUS current 832 DESCRIPTION 833 "The value of an instance of this object identifies one or 834 more conceptual rows in the scmCapTable, and has the same 835 value as the instance of scmCapIndex for those conceptual 836 rows." 837 ::= { scmUserEntry 5 } 839 draft Simplified Configuration Model March 1995 841 scmUserLinger OBJECT-TYPE 842 SYNTAX INTEGER (1..2147483647) 843 MAX-ACCESS read-create 844 STATUS current 845 DESCRIPTION 846 "The upper bound on the minimum number of contiguous seconds 847 that a dynamically created party may reside in the agent and 848 neither generate nor receive management communications, 849 before the agent may choose to set the party's status to 850 `destroy(6)'." 851 ::= { scmUserEntry 7 } 853 scmUserStorageType OBJECT-TYPE 854 SYNTAX StorageType 855 MAX-ACCESS read-create 856 STATUS current 857 DESCRIPTION 858 "The storage type for this conceptual row in the 859 scmUserTable." 860 ::= { scmUserEntry 8 } 862 scmUserStatus OBJECT-TYPE 863 SYNTAX RowStatus 864 MAX-ACCESS read-create 865 STATUS current 866 DESCRIPTION 867 "The status of this conceptual row in the scmUserTable. If 868 set to `destroy(6)', then any parties (and associated access 869 control entries) having a storage type of `volatile(2)' 870 which were earlier created for this user have their status 871 set to `destroy(6)'." 872 ::= { scmUserEntry 9 } 874 draft Simplified Configuration Model March 1995 876 -- capabilities table 878 scmCapNextIndex OBJECT-TYPE 879 SYNTAX INTEGER (0..2147483647) 880 MAX-ACCESS read-only 881 STATUS current 882 DESCRIPTION 883 "The next unassigned value of scmCapIndex. The value 0 884 indicates that no unassigned values are available. 886 Reading a non-zero value causes the assignment of the 887 retrieved value for use as the scmCapIndex of a future 888 capability, and thus causes the value of this object to 889 change. - 891 The algorithm for changing scmCapIndex is implementation- + 892 dependent, and the agent may use a subset of values within + 893 1..2147483647, but the agent must guarantee that the value + 894 held by this object is not assigned to any in-use value of + 895 scmCapIndex, e.g., is not pointed to by any other MIB + 896 object. + 898 A management station should create a new MIB view using this 899 algorithm: first, issue a management protocol retrieval 900 operation to obtain the value of scmCapNextIndex -- this 901 value is used as the scmCapIndex of the new capability; and, 902 second, issue a management protocol set operation to create 903 an instance of the scmCapStatus object setting its value to 904 `createAndGo' or `createAndWait' (as specified in the 905 description of the RowStatus textual convention)." 906 ::= { scmMIBObjects 2 } 908 scmCapTable OBJECT-TYPE 909 SYNTAX SEQUENCE OF ScmCapEntry 910 MAX-ACCESS not-accessible 911 STATUS current 912 DESCRIPTION 913 "The capabilities table." 914 ::= { scmMIBObjects 3 } 916 draft Simplified Configuration Model March 1995 918 scmCapEntry OBJECT-TYPE 919 SYNTAX ScmCapEntry 920 MAX-ACCESS not-accessible 921 STATUS current 922 DESCRIPTION 923 "A conceptual row in the capabilities table." 924 INDEX { scmCapIndex, scmCapCtxLocalTime, 925 IMPLIED scmCapCtxLocalEntity } 926 ::= { scmCapTable 1 } 928 ScmCapEntry ::= 929 SEQUENCE { 930 scmCapIndex INTEGER, 931 scmCapCtxLocalTime INTEGER, 932 scmCapCtxLocalEntity OCTET STRING, 933 scmCapNPrivileges AccessPrivileges, 934 scmCapNReadView INTEGER, 935 scmCapNWriteView INTEGER, 936 scmCapAPrivileges AccessPrivileges, 937 scmCapAReadView INTEGER, 938 scmCapAWriteView INTEGER, 939 scmCapPPrivileges AccessPrivileges, 940 scmCapPReadView INTEGER, 941 scmCapPWriteView INTEGER, 942 scmCapStorageType StorageType, 943 scmCapStatus RowStatus 944 } 946 scmCapIndex OBJECT-TYPE 947 SYNTAX INTEGER (1..2147483647) 948 MAX-ACCESS not-accessible 949 STATUS current 950 DESCRIPTION 951 "A unique value for each capability. The value for each 952 capability must remain constant at least from one re- 953 initialization of the entity's network management system to 954 the next re-initialization." 955 ::= { scmCapEntry 1 } 957 draft Simplified Configuration Model March 1995 959 scmCapCtxLocalTime OBJECT-TYPE 960 SYNTAX INTEGER { currentTime(1), restartTime(2) } 961 MAX-ACCESS not-accessible 962 STATUS current 963 DESCRIPTION 964 "The temporal context associated with this capability." 965 ::= { scmCapEntry 2 } 967 scmCapCtxLocalEntity OBJECT-TYPE 968 SYNTAX OCTET STRING (SIZE (0..255)) 969 MAX-ACCESS not-accessible 970 STATUS current 971 DESCRIPTION 972 "The local entity associated with this capability." 973 ::= { scmCapEntry 3 } 975 scmCapNPrivileges OBJECT-TYPE 976 SYNTAX AccessPrivileges 977 MAX-ACCESS read-create 978 STATUS current 979 DESCRIPTION 980 "The access privileges which govern the flow of management 981 information between the user and the agent when 982 communicating using unauthenticated traffic." 983 ::= { scmCapEntry 4 } 985 scmCapNReadView OBJECT-TYPE 986 SYNTAX INTEGER (1..2147483647) 987 MAX-ACCESS read-create 988 STATUS current 989 DESCRIPTION 990 "A reference to a MIB view of a locally accessible entity, 991 when the user requests the get, get-next, or get-bulk 992 operations using unauthenticated traffic; the value of the 993 instance identifies the particular MIB view which has the 994 same value of viewIndex." 995 ::= { scmCapEntry 5 } 997 draft Simplified Configuration Model March 1995 999 scmCapNWriteView OBJECT-TYPE 1000 SYNTAX INTEGER (1..2147483647) 1001 MAX-ACCESS read-create 1002 STATUS current 1003 DESCRIPTION 1004 "A reference to a MIB view of a locally accessible entity, 1005 when the user requests the set operation using 1006 unauthenticated traffic; the value of the instance 1007 identifies the particular MIB view which has the same value 1008 of viewIndex." 1009 ::= { scmCapEntry 6 } 1011 scmCapAPrivileges OBJECT-TYPE 1012 SYNTAX AccessPrivileges 1013 MAX-ACCESS read-create 1014 STATUS current 1015 DESCRIPTION 1016 "The access privileges which govern the flow of management 1017 information between the user and the agent when 1018 communicating using authenticated, but not private, 1019 traffic." 1020 ::= { scmCapEntry 7 } 1022 scmCapAReadView OBJECT-TYPE 1023 SYNTAX INTEGER (1..2147483647) 1024 MAX-ACCESS read-create 1025 STATUS current 1026 DESCRIPTION 1027 "A reference to a MIB view of a locally accessible entity, 1028 when the user requests the get, get-next, or get-bulk 1029 operations using authenticated, but not private, traffic; 1030 the value of the instance identifies the particular MIB view 1031 which has the same value of viewIndex." 1032 ::= { scmCapEntry 8 } 1034 draft Simplified Configuration Model March 1995 1036 scmCapAWriteView OBJECT-TYPE 1037 SYNTAX INTEGER (1..2147483647) 1038 MAX-ACCESS read-create 1039 STATUS current 1040 DESCRIPTION 1041 "A reference to a MIB view of a locally accessible entity, 1042 when the user requests the set operation using 1043 authenticated, but not private, traffic; the value of the 1044 instance identifies the particular MIB view which has the 1045 same value of viewIndex." 1046 ::= { scmCapEntry 9 } 1048 scmCapPPrivileges OBJECT-TYPE 1049 SYNTAX AccessPrivileges 1050 MAX-ACCESS read-create 1051 STATUS current 1052 DESCRIPTION 1053 "The access privileges which govern the flow of management 1054 information between the user and the agent when 1055 communicating using authenticated and private traffic." 1056 ::= { scmCapEntry 10 } 1058 scmCapPReadView OBJECT-TYPE 1059 SYNTAX INTEGER (1..2147483647) 1060 MAX-ACCESS read-create 1061 STATUS current 1062 DESCRIPTION 1063 "A reference to a MIB view of a locally accessible entity, 1064 when the user requests the get, get-next, or get-bulk 1065 operations using authenticated and private traffic; the 1066 value of the instance identifies the particular MIB view 1067 which has the same value of viewIndex." 1068 ::= { scmCapEntry 11 } 1070 draft Simplified Configuration Model March 1995 1072 scmCapPWriteView OBJECT-TYPE 1073 SYNTAX INTEGER (1..2147483647) 1074 MAX-ACCESS read-create 1075 STATUS current 1076 DESCRIPTION 1077 "A reference to a MIB view of a locally accessible entity, 1078 when the user requests the set operation using authenticated 1079 and private traffic; the value of the instance identifies 1080 the particular MIB view which has the same value of 1081 viewIndex." 1082 ::= { scmCapEntry 12 } 1084 scmCapStorageType OBJECT-TYPE 1085 SYNTAX StorageType 1086 MAX-ACCESS read-create 1087 STATUS current 1088 DESCRIPTION 1089 "The storage type for this conceptual row in the 1090 scmCapTable." 1091 ::= { scmCapEntry 13 } 1093 scmCapStatus OBJECT-TYPE 1094 SYNTAX RowStatus 1095 MAX-ACCESS read-create 1096 STATUS current 1097 DESCRIPTION 1098 "The status of this conceptual row in the scmCapTable." 1099 ::= { scmCapEntry 14 } 1101 draft Simplified Configuration Model March 1995 1103 -- maintenance assignments 1105 -- these objects are accessible only to user-based maintenance 1106 -- functions 1108 userMaintActions 1109 OBJECT IDENTIFIER ::= { scmMIB 3 } 1111 userMaintTable OBJECT-TYPE 1112 SYNTAX SEQUENCE OF UserMaintEntry 1113 MAX-ACCESS not-accessible 1114 STATUS current 1115 DESCRIPTION 1116 "A pseudo-table provided to allow indexing for 1117 userMaintCreate." 1118 ::= { userMaintActions 1 } 1120 userMaintEntry OBJECT-TYPE 1121 SYNTAX UserMaintEntry 1122 MAX-ACCESS not-accessible 1123 STATUS current 1124 DESCRIPTION 1125 "Entries in this table are created by the agent dynamically 1126 when processing a getRequest operation, and are deleted | 1127 immediately thereafter. | 1128 As such, entries are not accessible via other retrieval 1129 operations." 1130 INDEX { IMPLIED userMaintIndex } | 1131 ::= { userMaintTable 1 } 1133 UserMaintEntry ::= 1134 SEQUENCE { 1135 userMaintIndex OCTET STRING, 1136 userMaintCreate OCTET STRING 1137 } 1139 draft Simplified Configuration Model March 1995 1141 userMaintIndex OBJECT-TYPE 1142 SYNTAX OCTET STRING 1143 MAX-ACCESS not-accessible 1144 STATUS current 1145 DESCRIPTION 1146 "A pseudo-index provided to allow indexing for | 1147 userMaintCreate. Its value is the BER-encoding of the set | 1148 of OBJECT IDENTIFIER sub-identifiers which a manager appends | 1149 to userMaintCreate in order to supply the parameters for the | 1150 session creation algorithm." | 1151 ::= { userMaintEntry 1 } 1153 userMaintCreate OBJECT-TYPE 1154 SYNTAX OCTET STRING (SIZE (1|39|55)) 1155 MAX-ACCESS read-only 1156 STATUS current 1157 DESCRIPTION 1158 "A getRequest operation on this object is used to invoke the | 1159 session creation algorithm." | 1160 ::= { userMaintEntry 2 } 1162 userMaintDestroy OBJECT-TYPE 1163 SYNTAX OCTET STRING (SIZE (16)) 1164 MAX-ACCESS read-write 1165 STATUS current 1166 DESCRIPTION 1167 "A set operation on this object is used to invoke the 1168 session destruction algorithm. On retrieval, this object 1169 has the value of 16 zero-valued octets." 1170 ::= { userMaintActions 2 } 1172 draft Simplified Configuration Model March 1995 1174 -- conformance information 1176 scmMIBConformance 1177 OBJECT IDENTIFIER ::= { scmMIB 4 } 1179 scmMIBCompliances 1180 OBJECT IDENTIFIER ::= { scmMIBConformance 1 } 1181 scmMIBGroups 1182 OBJECT IDENTIFIER ::= { scmMIBConformance 2 } 1184 -- compliance statements 1186 scmMIBCompliance MODULE-COMPLIANCE 1187 STATUS current 1188 DESCRIPTION 1189 "The compliance statement for SNMPv2 entities which 1190 implement the Simplified Configuration Model." 1191 MODULE -- this module 1192 MANDATORY-GROUPS { scmGroup, userMaintGroup } 1193 ::= { scmMIBCompliances 1 } 1195 draft Simplified Configuration Model March 1995 1197 -- units of conformance 1199 scmGroup OBJECT-GROUP 1200 OBJECTS { scmUserPassword, 1201 scmUserAuthProtocol, scmUserPrivProtocol, 1202 scmUserCapIndex, scmUserLinger, 1203 scmUserStorageType, scmUserStatus, 1204 scmCapNextIndex, 1205 scmCapNPrivileges, scmCapNReadView, scmCapNWriteView, 1206 scmCapAPrivileges, scmCapAReadView, scmCapAWriteView, 1207 scmCapPPrivileges, scmCapPReadView, scmCapPWriteView, 1208 scmCapStorageType, scmCapStatus 1209 } 1210 STATUS current 1211 DESCRIPTION 1212 "A collection of objects providing support for the 1213 Simplified Configuration Model." 1214 ::= { scmMIBGroups 1 } 1216 userMaintGroup OBJECT-GROUP 1217 OBJECTS { userMaintCreate, userMaintDestroy } 1218 STATUS current 1219 DESCRIPTION 1220 "A collection of objects providing support for user-based 1221 maintenance functions." 1222 ::= { scmMIBGroups 2 } 1224 END 1225 draft Simplified Configuration Model March 1995 1227 7. Appendix A: Password to Key Algorithm 1229 The following code fragment demonstrates the password to key algorithm | 1230 used when mapping scmUserPassword to an authentication key for a | 1231 userMaintParty when the | 1232 value of scmUserAuthProtocol is v2md5AuthProtocol: 1234 void v2md5auth_password_to_key(password, passwordlen, key) | 1235 u_char *password; /* IN */ 1236 u_int passwordlen; /* IN */ 1237 u_char *key; /* OUT - caller supplies pointer to 16 1238 octet buffer */ { 1239 MDstruct MD; 1240 u_char *cp, password_buf[64]; 1241 u_long password_index = 0; 1242 u_long count = 0, i; 1244 MDbegin(&MD); /* initialize MD5 */ 1246 /* loop until we've done 1 Megabyte */ 1247 while (count < 1048576) { 1248 cp = password_buf; 1249 for(i = 0; i < 64; i++){ 1250 *cp++ = password[ password_index++ % passwordlen ]; 1251 /* 1252 * Take the next byte of the password, wrapping to the 1253 * beginning of the password as necessary. 1254 */ 1255 } 1257 MDupdate(&MD, password_buf, 64 * 8); 1258 /* 1259 * 1048576 is divisible by 64, so the last MDupdate will be 1260 * aligned as well. 1261 */ 1262 count += 64; 1263 } 1264 MDupdate(&MD, password_buf, 0); /* tell MD5 we're done */ 1265 copy_digest_to_buffer(&MD, key); 1266 return; } 1268 draft Simplified Configuration Model March 1995 1270 8. Acknowledgements 1272 The Simplified Configuration Model is based on the "Simplified Security 1273 Conventions" developed by Steve Waldbusser, and subsequently updated by 1274 the SNMPv2 Working Group. 1276 The authors wish to acknowledge in particular the contributions of the + 1277 following individuals + 1279 Dave Arneson (Cabletron), + 1280 Uri Blumenthal (IBM), + 1281 Doug Book (Chipcom), + 1282 Deirdre Kostik (Bellcore), + 1283 Dave Harrington (Cabletron), + 1284 Jeff Johnson (Cisco Systems), + 1285 Brian O'Keefe (Hewlett Packard), + 1286 Dave Perkins (Bay Networks), + 1287 Randy Presuhn (Peer Networks), + 1288 Shawn Routhier (Epilogue), + 1289 Bob Stewart (Cisco Systems), + 1290 Kaj Tesink (Bellcore). + 1292 draft Simplified Configuration Model March 1995 1294 9. References 1296 [1] Case, J., Galvin, J., McCloghrie, K., Rose, M., and Waldbusser, S., 1297 "Administrative Model for version 2 of the Simple Network 1298 Management Protocol (SNMPv2)", in progress, SNMP Research, Inc., 1299 Trusted Information Systems, Cisco Systems, Dover Beach Consulting, 1300 Inc., Carnegie Mellon University, March, 1995. 1302 [2] Case, J., Galvin, J., McCloghrie, K., Rose, M., and Waldbusser, S., 1303 "Party MIB for version 2 of the Simple Network Management Protocol 1304 (SNMPv2)", in progress, SNMP Research, Inc., Trusted Information 1305 Systems, Cisco Systems, Dover Beach Consulting, Inc., Carnegie 1306 Mellon University, March, 1995. 1308 [3] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Transport 1309 Mappings for version 2 of the Simple Network Management Protocol 1310 (SNMPv2)", in progress, SNMP Research Inc., Cisco Systems, Inc., 1311 Dover Beach Consulting, Inc., Carnegie Mellon University, March, 1312 1995. 1314 draft Simplified Configuration Model March 1995 1316 10. Security Considerations 1318 The mechanisms defined in this document allow "users" to be configured, 1319 and to activate management sessions for them. How "users" are defined 1320 is subject to the security policy of the network administration. For 1321 example, users could be individuals (e.g., "joe" or "jane"), or a 1322 particular role (e.g., "operator" or "administrator"), or a combination 1323 (e.g., "joe-operator", "jane-operator" or "joe-admin"). Furthermore, a 1324 "user" may be a logical entity, such as a manager station application or 1325 set of manager station applications, acting on behalf of a individual or 1326 role, or set of individuals, or set of roles, including combinations. 1327 The mechanisms also allow management capabilities to be defined, where 1328 one or more users can be authorized for a set of capabilities. 1330 A password is defined for each user, and these passwords will often be 1331 generated, remembered, and input by a human. Because human-generated 1332 passwords may be less than the 16 octets required by the MD5 1333 authentication protocols, and because brute force attacks can be quite 1334 easy on a relatively short ASCII character set, passwords are not used 1335 directly, but are instead mapped by the algorithm described in Section 6 1336 and Appendix A. Agent implementations (and agent configuration 1337 applications) must ensure that passwords are at least 8 characters in 1338 length. 1340 Because these passwords are used (nearly) directly, it is very important 1341 that they not be easily guessed. It is suggested that they be composed 1342 of mixed-case alphanumeric and punctuation characters that don't form 1343 words or phrases that might be found in a dictionary. Longer passwords 1344 improve the security of the system. Users may wish to input multiword 1345 phrases to make their password string longer while ensuring that it is 1346 memorable. 1348 Note that there is security risk in configuring the same "user" on | 1349 multiple systems where the same password is used on each system, since | 1350 the compromise of that user's secrets on one system results in the | 1351 compromise of that user on all other systems having the same password. | 1352 There is also greater security risk and less accountability in allowing | 1353 multiple humans to know the password for a given "user". | 1355 Note also that the userMaintParty authentication key for a user is the | 1356 same for all systems on which the user has the same password, and it is | 1357 necessary to store that authentication key on each such system. As | 1358 such, an implementation must, to the maximal extent possible, prohibit | 1359 read-access to these authentication keys under all circumstances except | 1360 as required to generate and/or validate SNMPv2 messages containing | 1361 draft Simplified Configuration Model March 1995 1363 user-based maintenance functions. | 1365 With respect to the replay-ability of user-based maintenance functions, 1366 note that all such operations are effectively idempotent: replaying a 1367 request to create a session results in a new session being created, but 1368 the session has a new unique set of keys, which can be derived only by 1369 an authorized user; similarly, replaying a request to destroy a session 1370 results in an inconsistentValue error. 1372 draft Simplified Configuration Model March 1995 1374 11. Authors' Address 1376 Steven Waldbusser 1377 Carnegie Mellon University 1378 5000 Forbes Ave 1379 Pittsburgh, PA 15213 1380 US 1382 Phone: +1 412 268 6628 1383 Email: waldbusser@cmu.edu 1385 Jeffrey D. Case 1386 SNMP Research, Inc. 1387 3001 Kimberlin Heights Rd. 1388 Knoxville, TN 37920-9716 1389 US 1391 Phone: +1 615 573 1434 1392 Email: case@snmp.com 1394 Keith McCloghrie 1395 Cisco Systems, Inc. 1396 170 West Tasman Drive, 1397 San Jose, CA 95134-1706 1399 Phone: +1 408 526 5260 1400 EMail: kzm@cisco.com 1402 Marshall T. Rose 1403 Dover Beach Consulting, Inc. 1404 420 Whisman Court 1405 Mountain View, CA 94043-2186 1406 US 1408 Phone: +1 415 968 1052 1409 Email: mrose@dbc.mtview.ca.us 1411 draft Simplified Configuration Model March 1995 1413 Table of Contents 1415 1 Introduction .................................................... 2 1416 1.1 A Note on Terminology ......................................... 2 1417 2 Overview ........................................................ 2 1418 3 User-based Maintenance Functions ................................ 4 1419 4 Session Creation Algorithm ...................................... 6 1420 4.1 Step 1: Manager Requests Creation ............................. 7 1421 4.2 Step 2: Agent Analyzes Request ................................ 8 1422 4.3 Step 3: Agent Creates Parties ................................. 10 1423 4.4 Step 4: Agent Authorizes Parties .............................. 12 1424 4.4.1 Step 4a: Agent Checks Contexts .............................. 12 1425 4.4.2 Step 4b: Agent Creates Access Control Entries ............... 13 1426 4.5 Step 5: Agent Responds ........................................ 15 1427 4.6 Step 6: Agent Starts Initial Inactivity Timer ................. 15 1428 4.7 Step 7: Manager Analyzes Response ............................. 16 1429 5 Session Destruction Algorithm ................................... 17 1430 5.1 Step 1: Manager Requests Destruction .......................... 18 1431 5.2 Step 2: Agent Analyzes Request and Responds ................... 18 1432 5.3 Step 3: Manager Analyzes Response ............................. 19 1433 6 Definitions ..................................................... 20 1434 6.1 Administrative Assignments .................................... 21 1435 6.2 Object Assignments ............................................ 22 1436 6.3 Maintenance Assignments ....................................... 33 1437 6.4 Conformance Information ....................................... 35 1438 6.4.1 Compliance Statements ....................................... 35 1439 6.4.2 Units of Conformance ........................................ 36 1440 7 Appendix A: Password to Key Algorithm ........................... 37 1441 8 Acknowledgements ................................................ 38 1442 9 References ...................................................... 39 1443 10 Security Considerations ........................................ 40 1444 11 Authors' Address ............................................... 42