idnits 2.17.1 draft-ietf-snmpv2-bcm-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-20) 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 235 has weird spacing: '... noAuth noA...' == Line 237 has weird spacing: '...tDomain tDom...' == Line 238 has weird spacing: '...agtAddr null...' == Line 241 has weird spacing: '...rotocol noAu...' == Line 245 has weird spacing: '...rotocol noPr...' == (11 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 (19 March 1995) is 10625 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 510, 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: 10 errors (**), 0 flaws (~~), 8 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 The Basic Configuration Model for SNMPv2 3 19 March 1995 5 draft-ietf-snmpv2-bcm-ds-00.txt 7 Jeffrey D. Case 8 SNMP Research, Inc. 9 case@snmp.com 11 Keith McCloghrie 12 Cisco Systems, Inc. 13 kzm@cisco.com 15 Marshall T. Rose 16 Dover Beach Consulting, Inc. 17 mrose@dbc.mtview.ca.us 19 Steven Waldbusser 20 Carnegie Mellon University 21 waldbusser@cmu.edu 23 Status of this Memo 25 This document is an Internet Draft. Internet Drafts are working 26 documents of the Internet Engineering Task Force (IETF), its Areas, and 27 its Working Groups. Note that other groups may also distribute working 28 documents as Internet Drafts. 30 Internet Drafts are valid for a maximum of six months and may be 31 updated, replaced, or obsoleted by other documents at any time. It is 32 inappropriate to use Internet Drafts as reference material or to cite 33 them other than as a "work in progress". 35 draft Basic Configuration Model March 1995 37 1. Introduction 39 A network management system contains: several (potentially many) nodes, 40 each with a processing entity, termed an agent, which has access to 41 management instrumentation; at least one management station; and, a 42 management protocol, used to convey management information between the 43 agents and management stations. Operations of the protocol are carried 44 out under an administrative framework which defines both authentication 45 and authorization policies. 47 Network management stations execute management applications which 48 monitor and control network elements. Network elements are devices such 49 as hosts, routers, terminal servers, etc., which are monitored and 50 controlled through access to their management information. 52 The Administrative Infrastructure for SNMPv2 [1] defines how the 53 administrative framework is applied to realize effective network 54 management in a variety of configurations and environments. It is the 55 purpose of this document, the Basic Configuration Model for SNMPv2, to 56 define one such deployment strategy using the administrative framework. 58 1.1. A Note on Terminology 60 For the purpose of exposition, the original Internet-standard Network 61 Management Framework, as described in RFCs 1155, 1157, and 1212, is 62 termed the SNMP version 1 framework (SNMPv1). The current framework is 63 termed the SNMP version 2 framework (SNMPv2). 65 2. Overview 67 The model described here is based on the notion of a basic set of well- 68 known permanent configuration information for an SNMPv2 agent. This 69 permanent information provides a basic set of SNMPv2 parties, a single 70 SNMPv2 context, two views and access control information, by which 71 management information held by the agent can be accessed. 73 This configuration information can be augmented during the lifetime of 74 the agent through the addition of other temporary or permanent parties, 75 contexts, views and access control information. However, the basic set 76 must be configured at installation, and may not be deleted nor reduced 77 in functionality below a minimum level of capability thereafter. By 78 this means, a management application can be assured that the basic set 79 always exists and is always available for use. 81 draft Basic Configuration Model March 1995 83 The basic set always includes four parties, and may include two more. 84 The four parties are a pair of unauthenticated parties and a pair of 85 authenticated parties. If the agent supports encryption, an additional 86 pair of parties supporting both privacy and authentication can also be 87 included. For each pair of parties, one party of the pair represents 88 the agent's SNMPv2 entity, and the other represents an SNMPv2 entity it 89 communicates with. 91 The naming conventions for the basic set of parties and contexts are 92 organized to provide a framework for the naming of additional parties 93 and contexts. 95 3. Naming Conventions 97 3.1. Party Identities 99 The convention for naming parties provides for a set of up to six 100 parties to be used together, named as follows: 102 basicAgentNoAuthPartyID.. 103 basicManagerNoAuthPartyID.. 104 basicAgentAuthPartyID.. 105 basicManagerAuthPartyID.. 106 basicAgentPrivPartyID.. 107 basicManagerPrivPartyID.. 109 where: 111 112 the 12-octet value of agentID.0 [2] for the agent, encoded one 113 sub-identifier per octet. 115 116 An arbitrary length octet-string to produce a unique name for a 117 party, encoded one sub-identifier per octet. 119 basicAgentNoAuthPartyID 120 parties without authenticated or privacy, local to the agent, 122 basicManagerNoAuthPartyID 123 parties without authenticated or privacy, remote from the agent, 125 basicAgentAuthPartyID 126 parties with authenticated but not privacy, local to the agent, 128 draft Basic Configuration Model March 1995 130 basicManagerAuthPartyID 131 parties with authenticated but not privacy, remote from the agent, 133 basicAgentPrivPartyID 134 parties with authenticated and privacy, local to the agent, 136 basicManagerPrivPartyID 137 parties with authenticated and privacy, remote from the agent, 139 The allows unique party names so that each party is used by 140 at most one manager entity at a time. Typically, one manager will 141 communicate with an agent using a particular set of four or six parties 142 which have that agent's agentID [2] and the same qualifier value. 144 3.2. Context Identities 146 The convention for naming contexts provides for the use of multiple 147 context local entities as well as various of context temporal domains: 149 basicContextID... 151 where: 153 154 the 12-octet value of agentID.0 [2] for the agent, encoded one 155 sub-identifier per octet. 157 158 identifies the context's temporal domain, encoded as a single sub- 159 identifier, specifically the value of the last sub-identifier of a 160 context temporal domain defined under temporalDomains [2]: 162 value meaning 163 ----- -------- 164 1 currentTime 165 2 restartTime 167 168 identifies the context's local entity name, encoded as N sub- 169 identifiers, one per octet of the value of contextLocalEntity [2] 170 associated with the context. If contextLocalEntity is the empty 171 string, then is effectively omitted from the context 172 identity. 174 draft Basic Configuration Model March 1995 176 4. Installation Parameters 178 During the installation of an agent, several parameters must be 179 configured. These are: 181 (1) a security posture 183 The choice of security posture determines the extent of the view 184 configured for unauthenticated access. One of three possible 185 choices is selected: 187 minimum-secure, 188 semi-secure, or 189 very-secure. 191 (2) one or more transport service addresses 193 These parameters (see partyTDomain and partyTAddress in [2]) may be 194 specified explicitly, or they may be specified implicitly as the 195 same set of network-layer addresses configured for other uses by 196 the device together with the well-known transport-layer "port" 197 information for the appropriate transport domain [3]. The agent 198 listens on each of these transport service addresses for those 199 parties which are included in the basic set and which are local to 200 it. 202 (3) one or more secrets 204 These are the authentication/privacy secrets for the configured 205 parties. 207 One way to accomplish this is to have the installer enter a 208 "password" for each required secret. The password is then 209 algorithmically converted into the required secret by: forming a 210 string of length 1,048,576 octets by repeating the value of the 211 password as often as necessary, truncating accordingly, and using 212 the resulting string as the input to the MD5 algorithm. The 213 resulting digest is the required secret (see Appendix A). 215 draft Basic Configuration Model March 1995 217 5. Mandatory Installation 219 An agent must instantiate the following parties, context, views and ACLs 220 at the time the agent is installed. This configuration must persist, 221 except that authentication secrets should be changed after installation. 223 5.1. Parties 225 Four parties with as the empty-string: 227 basicAgentNoAuthPartyID. 228 basicManagerNoAuthPartyID. 229 basicAgentAuthPartyID. 230 basicManagerAuthPartyID. 232 The parties are created with these values: 234 Agent Manager Agent Manager 235 party noAuth noAuth Auth Auth 236 ----- ------- ------- ------- ------- 237 TDomain tDomain tDomain tDomain tDomain 238 TAddress agtAddr null agtAddr null 239 MaxMessageSize 240 Local true false true false 241 AuthProtocol noAuth noAuth v2md5AuthProt v2md5AuthProtocol 242 AuthClock 0 0 0 0 243 AuthPrivate ''H ''H 244 AuthPublic ''H ''H ''H ''H 245 PrivProtocol noPriv noPriv noPriv noPriv 246 PrivPrivate ''H ''H ''H ''H 247 PrivPublic ''H ''H ''H ''H 248 StorageType permanent permanent permanent permanent 249 Status active active active active 251 where: 253 254 the standard maximum message size for the indicated transport 255 domain [3]. 257 258 the configured authentication secret. 260 draft Basic Configuration Model March 1995 262 5.2. Contexts 264 One context with as the empty-string, and the value for 265 currentTime: 267 basicContextID..1 269 The context is created with these values: 271 LocalEntity "" 272 LocalTime currentTime 273 ProxyDstParty 0.0 274 ProxySrcParty 0.0 275 ProxyContext 0.0 276 StorageType readOnly 277 Status active 278 Type local 280 5.3. Views 282 Two views are configured as a set of view subtrees, one view for 283 authenticated access and the other for unauthenticated access. The 284 latter is configured according to the selected security posture. 286 For the "very-secure" posture, three view subtrees: 288 view subtree #1 subtree #2 subtree #3 289 ---- ---------- ---------- ---------- 290 Index 291 Subtree internet snmpStats snmpParties 292 Mask ''H ''H ''H 293 Type included included included 294 StorageType readOnly readOnly readOnly 295 Status active active active 297 draft Basic Configuration Model March 1995 299 For the "semi-secure" posture, four view subtrees: 301 view subtree #1 subtree #2 subtree #3 subtree #4 302 ---- ---------- ---------- ---------- ---------- 303 Index 304 Subtree internet snmpStats partyMIB system 305 Mask ''H ''H ''H ''H 306 Type included included included included 307 StorageType readOnly readOnly readOnly readOnly 308 Status active active active active 310 For the "minimum-secure" posture, two view subtrees: 312 view subtree #1 subtree #2 313 ---- ---------- ---------- 314 Index 315 Subtree internet internet 316 Mask ''H ''H 317 Type included included 318 StorageType readOnly readOnly 319 Status active active 321 5.4. ACLs 323 Two ACLs with these values: 325 ACL ACL #1 ACL #2 326 --- ------ ------ 327 Target Agent NoAuth Agent Auth 328 Subject Manager NoAuth Manager Auth 329 Context the mandatory context the mandatory context 330 Privileges get/getNext/getBulk get/getNext/getBulk/set 331 ReadViewIndex 332 WriteViewIndex 0 333 StorageType readOnly readOnly 334 Status active active 336 draft Basic Configuration Model March 1995 338 6. Optional Installation 340 If privacy is supported, the agent must also instantiate the following 341 parties and ACLs at the time the agent is installed. This configuration 342 must persist, except that authentication and privacy secrets should be 343 changed after installation. 345 6.1. Parties 347 Two parties with as the empty-string: 349 basicAgentPrivPartyID. 350 basicManagerPrivPartyID. 352 The parties are created with these values: 354 Agent Manager 355 party Priv Priv 356 ----- ------- ------- 357 TDomain tDomain tDomain 358 TAddress agtAddr null 359 MaxMessageSize 360 Local true false 361 AuthProtocol v2md5AuthProtocol v2md5AuthProtocol 362 AuthClock 0 0 363 AuthPrivate 364 AuthPublic ''H ''H 365 PrivProtocol desPrivProtocol desPrivProtocol 366 PrivPrivate 367 PrivPublic ''H ''H 368 StorageType permanent permanent 369 Status active active 371 where: 373 374 the standard maximum message size for the indicated transport 375 domain. 377 378 the configured authentication secret. 380 381 the configured privacy secret. 383 draft Basic Configuration Model March 1995 385 6.2. ACLs 387 One ACL with these values: 389 ACL ACL #3 390 --- ------ 391 Target Agent Priv 392 Subject Manager Priv 393 Context the mandatory context 394 Privileges get/getNext/getBulk/set 395 ReadViewIndex 396 WriteViewIndex 397 StorageType readOnly 398 Status active 400 draft Basic Configuration Model March 1995 402 7. Agent Discovery 404 The basic configuration described in this memo facilitates communication 405 between a manager and a discovered agent. On discovering that an agent 406 executes a particular transport service address, a manager may proceed 407 to: 409 (1) obtain the value of agentID.0 [2] using maintenance functions. 410 (Note this only applies to non-proxied agents.) 412 (2) query the agent using: 414 dstParty basicAgentNoAuthPartyID. 415 srcParty basicManagerNoAuthPartyID. 416 context basicContextID..1 418 to discover a for which there are a pair of parties 420 basicAgentAuthPartyID.. 421 basicManagerAuthPartyID.. 422 and/or 423 basicAgentPrivPartyID.. 424 basicManagerPrivPartyID.. 426 having authentication/privacy secrets known to the manager. 428 (3) use the set of parties having the determined value of 429 to obtain the set of contexts for which management information is 430 accessible by the agent. 432 Whenever the manager needs to access the management information of any 433 of these discovered contexts, it may then communicate with the agent 434 using the set of parties having the determined value of . 436 Note that it is assumed that only one manager performs discovery at a 437 time, and therefore the above procedure does not require the sharing of 438 parties. This is ensured for the authenticated parties by providing the 439 secrets to only one manager. 441 draft Basic Configuration Model March 1995 443 8. Definitions 445 SNMPv2-BCM-MIB DEFINITIONS ::= BEGIN 447 IMPORTS 448 MODULE-IDENTITY, OBJECT-TYPE, snmpModules 449 FROM SNMPv2-SMI; 451 bcmMIB MODULE-IDENTITY 452 LAST-UPDATED "9503180000Z" 453 ORGANIZATION "IETF SNMPv2 Working Group" 454 CONTACT-INFO 455 " Keith McCloghrie 457 Postal: Cisco Systems, Inc. 458 170 West Tasman Drive, 459 San Jose, CA 95134-1706 460 US 462 Tel: +1 408 526 5260 464 E-mail: kzm@cisco.com" 465 DESCRIPTION 466 "The MIB module for the Basic Configuration Model." 467 ::= { snmpModules 5 } 469 draft Basic Configuration Model March 1995 471 -- administrative assignments 473 bcmAdmin OBJECT IDENTIFIER ::= { bcmMIB 1 } 475 -- parties 477 basicPartyID OBJECT IDENTIFIER ::= { bcmAdmin 1 } 479 basicAgentNoAuthPartyID 480 OBJECT IDENTIFIER ::= { basicPartyID 1 } 481 basicManagerNoAuthPartyID 482 OBJECT IDENTIFIER ::= { basicPartyID 2 } 483 basicAgentAuthPartyID 484 OBJECT IDENTIFIER ::= { basicPartyID 3 } 485 basicManagerAuthPartyID 486 OBJECT IDENTIFIER ::= { basicPartyID 4 } 487 basicAgentPrivPartyID 488 OBJECT IDENTIFIER ::= { basicPartyID 5 } 489 basicManagerPrivPartyID 490 OBJECT IDENTIFIER ::= { basicPartyID 6 } 492 -- contexts 494 basicContextID OBJECT IDENTIFIER ::= { bcmAdmin 2 } 496 END 497 draft Basic Configuration Model March 1995 499 9. Appendix A: Password to Key Algorithm 501 The following code fragment demonstrates the password to key algorithm 502 used when mapping a password to an authentication or privacy key. 504 void password_to_key(password, passwordlen, key) 505 u_char *password; /* IN */ 506 u_int passwordlen; /* IN */ 507 u_char *key; /* OUT - caller supplies pointer to 16 508 octet buffer */ { 509 MDstruct MD; 510 u_char *cp, password_buf[64]; 511 u_long password_index = 0; 512 u_long count = 0, i; 514 MDbegin(&MD); /* initialize MD5 */ 516 /* loop until we've done 1 Megabyte */ 517 while (count < 1048576) { 518 cp = password_buf; 519 for(i = 0; i < 64; i++){ 520 *cp++ = password[ password_index++ % passwordlen ]; 521 /* 522 * Take the next byte of the password, wrapping to the 523 * beginning of the password as necessary. 524 */ 525 } 527 MDupdate(&MD, password_buf, 64 * 8); 528 /* 529 * 1048576 is divisible by 64, so the last MDupdate will be 530 * aligned as well. 531 */ 532 count += 64; 533 } 534 MDupdate(&MD, password_buf, 0); /* tell MD5 we're done */ 535 copy_digest_to_buffer(&MD, key); 536 return; } 538 draft Basic Configuration Model March 1995 540 10. Acknowledgements 542 The authors wish to acknowledge the contributions of the SNMPv2 Working 543 Group in general. In particular, the following individuals 545 Dave Arneson (Cabletron), 546 Uri Blumenthal (IBM), 547 Doug Book (Chipcom), 548 Maria Greene (Ascom Timeplex), 549 Deirdre Kostik (Bellcore), 550 Dave Harrington (Cabletron), 551 Jeff Johnson (Cisco Systems), 552 Brian O'Keefe (Hewlett Packard), 553 Dave Perkins (Bay Networks), 554 Randy Presuhn (Peer Networks), 555 Shawn Routhier (Epilogue), 556 Bob Stewart (Cisco Systems), 557 Kaj Tesink (Bellcore). 559 deserve special thanks for their contributions. 561 draft Basic Configuration Model March 1995 563 11. References 565 [1] Case, J., Galvin, J., McCloghrie, K., Rose, M., and Waldbusser, S., 566 "Administrative Model for version 2 of the Simple Network 567 Management Protocol (SNMPv2)", in progress, SNMP Research, Inc., 568 Trusted Information Systems, Cisco Systems, Dover Beach Consulting, 569 Inc., Carnegie Mellon University, March, 1995. 571 [2] Case, J., Galvin, J., McCloghrie, K., Rose, M., and Waldbusser, S., 572 "Party MIB for version 2 of the Simple Network Management Protocol 573 (SNMPv2)", in progress, SNMP Research, Inc., Trusted Information 574 Systems, Cisco Systems, Dover Beach Consulting, Inc., Carnegie 575 Mellon University, March, 1995. 577 [3] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Transport 578 Mappings for version 2 of the Simple Network Management Protocol 579 (SNMPv2)", in progress, SNMP Research Inc., Cisco Systems, Inc., 580 Dover Beach Consulting, Inc., Carnegie Mellon University, March, 581 1995. 583 draft Basic Configuration Model March 1995 585 12. Security Considerations 587 Each authenticated party needs an authentication secret, and those which 588 employ privacy also need a privacy secret. Appendix A specifies an 589 algorithm by which the initial value of such a secret can be entered as 590 a password. Such an algorithm simplifies the coordination required 591 between a manager and an agent at installation time. However, once 592 installation is complete, these secrets should be changed. 594 The algorithm in Appendix A is provided because human-generated 595 passwords may be less than the 16 octets required by the MD5 596 authentication and DES privacy protocols, and because brute force 597 attacks can be quite easy on a relatively short ASCII character set. 598 Agent implementations (and agent configuration applications) must ensure 599 that passwords are at least 8 characters in length. 601 Because these passwords are used (nearly) directly, it is important that 602 they not be easily guessed. It is suggested that they be composed of 603 mixed-case alphanumeric and punctuation characters that don't form words 604 or phrases that might be found in a dictionary. Longer passwords 605 improve the security of the system. Installers may wish to input 606 multiword phrases to make the password string longer while ensuring that 607 it is memorable. 609 draft Basic Configuration Model March 1995 611 13. Authors' Address 613 Jeffrey D. Case 614 SNMP Research, Inc. 615 3001 Kimberlin Heights Rd. 616 Knoxville, TN 37920-9716 617 US 619 Phone: +1 615 573 1434 620 Email: case@snmp.com 622 Keith McCloghrie 623 Cisco Systems, Inc. 624 170 West Tasman Drive, 625 San Jose, CA 95134-1706 627 Phone: +1 408 526 5260 628 EMail: kzm@cisco.com 630 Marshall T. Rose 631 Dover Beach Consulting, Inc. 632 420 Whisman Court 633 Mountain View, CA 94043-2186 634 US 636 Phone: +1 415 968 1052 637 Email: mrose@dbc.mtview.ca.us 639 Steven Waldbusser 640 Carnegie Mellon University 641 5000 Forbes Ave 642 Pittsburgh, PA 15213 643 US 645 Phone: +1 412 268 6628 646 Email: waldbusser@cmu.edu 648 draft Basic Configuration Model March 1995 650 Table of Contents 652 1 Introduction .................................................... 2 653 1.1 A Note on Terminology ......................................... 2 654 2 Overview ........................................................ 2 655 3 Naming Conventions .............................................. 3 656 3.1 Party Identities .............................................. 3 657 3.2 Context Identities ............................................ 4 658 4 Installation Parameters ......................................... 5 659 5 Mandatory Installation .......................................... 6 660 5.1 Parties ....................................................... 6 661 5.2 Contexts ...................................................... 7 662 5.3 Views ......................................................... 7 663 5.4 ACLs .......................................................... 8 664 6 Optional Installation ........................................... 9 665 6.1 Parties ....................................................... 9 666 6.2 ACLs .......................................................... 10 667 7 Agent Discovery ................................................. 11 668 8 Definitions ..................................................... 12 669 4.1 Administrative Assignments .................................... 13 670 9 Appendix A: Password to Key Algorithm ........................... 14 671 10 Acknowledgements ............................................... 15 672 11 References ..................................................... 16 673 12 Security Considerations ........................................ 17 674 13 Authors' Address ............................................... 18