idnits 2.17.1 draft-ietf-snmpv3-acm-01.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 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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 == The page length should not exceed 58 lines per page, but there was 10 longer pages, the longest (page 3) being 177 lines == It seems as if not all pages are separated by form feeds - found 25 form feeds but 36 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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. ** The abstract seems to contain references ([SNMP-ARCH]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 1427 has weird spacing: '...support priva...' == Line 1436 has weird spacing: '...support priva...' == Line 1452 has weird spacing: '...support priva...' == Line 1482 has weird spacing: '...support priva...' == Line 1496 has weird spacing: '...support priva...' == (1 more instance...) == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (14 July 1997) is 9780 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) == Unused Reference: 'RFC1902' is defined on line 1351, but no explicit reference was found in the text == Unused Reference: 'RFC1905' is defined on line 1356, but no explicit reference was found in the text == Unused Reference: 'RFC1906' is defined on line 1361, but no explicit reference was found in the text == Unused Reference: 'RFC1908' is defined on line 1371, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1905 (ref. 'RFC1902') (Obsoleted by RFC 3416) -- Duplicate reference: RFC1905, mentioned in 'RFC1905', was also mentioned in 'RFC1902'. ** Obsolete normative reference: RFC 1905 (Obsoleted by RFC 3416) ** Obsolete normative reference: RFC 1906 (Obsoleted by RFC 3417) ** Obsolete normative reference: RFC 1907 (Obsoleted by RFC 3418) ** Obsolete normative reference: RFC 1908 (Obsoleted by RFC 2576) == Outdated reference: A later version (-06) exists of draft-ietf-snmpv3-next-gen-arch-02 == Outdated reference: A later version (-05) exists of draft-ietf-snmpv3-mpc-00 == Outdated reference: A later version (-03) exists of draft-ietf-snmpv3-usm-00 Summary: 15 errors (**), 0 flaws (~~), 17 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 View-based Access Control Model for the 3 Simple Network Management Protocol (SNMP) 5 14 July 1997 7 Bert Wijnen 8 IBM T. J. Watson Research 9 wijnen@vnet.ibm.com 11 Randy Presuhn 12 BMC Software, Inc. 13 rpresuhn@bmc.com 15 Keith McCloghrie 16 Cisco Systems, Inc. 17 kzm@cisco.com 19 21 Status of this Memo 23 This document is an Internet-Draft. Internet-Drafts are working 24 documents of the Internet Engineering Task Force (IETF), its areas, 25 and its working groups. Note that other groups may also distribute 26 working documents as Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet- Drafts as reference 31 material or to cite them other than as ``work in progress.'' 33 To learn the current status of any Internet-Draft, please check the 34 ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow 35 Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), 36 ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 38 Abstract 40 This document describes the View-based Access Control Model (ACM) for 41 use in the SNMP architecture [SNMP-ARCH]. It defines the Elements of 42 Procedure for applying access control to management information. 43 This document also includes a MIB for remotely managing the 44 configuration parameters for this ACM. 46 Wijnen/Presuhn/McCloghrie Expires December 1997 [Page 1] 47 ^L 48 Draft View-based Access Control Model (ACM) for SNMP July 1997 50 0. Issues and Change Log 52 0.1. Issues 53 - acknowledgements needs expansion 54 - There is a reverse mapping from groupName to securityName, see 55 the acmGroupListTable. However, given the amount of object 56 we're adding, we may want to remove/postpone this table? 57 - reference section must be checked; sync up with other documents 58 - Do we need/want the level of detail of errorIndication that 59 the isAccessAllowed primitive will return? Those who strongly 60 object to the details listed now, better let us know (on the 61 mailing list preferably) ASAP. 63 0.2. Change Log 65 [version 4.2] - This is the July 14 version. 66 - Address comments by Keith: 67 - Renumber section 2.4 to 2.5 68 - Add new sections 2.4, 2.4.1, 2.4.2 about MIB Views and Subtrees 69 and Families, 70 - Use some more precise language at various places. 71 - Add reference to RFC2119 about use of SHOULD and MUST 72 - rename the acmGroupTable to acmSecurityToGroupTable because that 73 much better indicates the function of this table. 74 - improved the writeup on statusInformation for the isAccessAllowed 75 primitive. 76 - paginate and generate table of contents 77 - posted as I-D on 15 July 79 [version 4.1] - This is the July 12 version. 80 - Adapt to latest list of Primitives/Parameters. 81 - Handle comments from co-editor Randy 82 - Added the SHOULD "initial" configuration 83 - Checked the MIB with SMICng 85 [version 4.0] - This is the July 7 version. 86 - Adopt to decisions/comments made are 2nd interim 87 - securityName to groupName mapping is in ACM 88 - out of the box configurations to be described as SHOULD 89 - UTF-8 issue still open, but move to general issue (ARCH) 90 where the SnmpAdminString is defined. 91 - ACM returns errorIndication based on which the caller 92 may increment error counter which may result in a 93 Report PDU. 94 - No statistics counters are kept in ACM 95 - removed viewTable; added acmViewSpinLock 96 - Address various comments from co-editors (Randy and Keith) 97 - Address comments made on mailing list(s). 99 [version 3.1] - This is the June 18 version. 100 - remove old (resolved) issues 102 Wijnen/Presuhn/McCloghrie Expires December 1997 [Page 2] 103 - list new issues 104 - corrections/additions by myself (Bert) 105 - corrections based on dbh comments 106 - removed change log of before 1st interim meeting. 108 [version 3.0] - this is the first ACM doc (June 12 version). 109 - Modifications as agreed at 1st Interim Meeting 110 - Make Access Control Module a separate document 111 - Use viewName as index instead of an integer 112 - add notify_view 113 - use SnmpAdminString 114 - Other Modification 115 - use miId and securityModel 116 - add acmGroupTable 117 - add/rename Stats counters 119 Wijnen/Presuhn/McCloghrie Expires December 1997 [Page 3] 120 ^L 121 Draft View-based Access Control Model (ACM) for SNMP July 1997 123 1. Introduction 125 The Architecture for describing Internet Management Frameworks 126 [SNMP-ARCH] is composed of multiple subsystems: 128 1) a Message Processing Subsystem, 129 2) a Security Subsystem, 130 3) an Access Control Subsystem, 132 Applications make use of the services of these subsystems. 134 It is important to understand the SNMP architecture and its 135 terminology to understand where the View-based Access Control 136 Model described in this document fits into the architecture and 137 interacts with other subsystems within the architecture. The 138 reader is expected to have read and understood the description and 139 terminology of the SNMP architecture, as defined in [SNMP-ARCH]. 141 The Access Control Subsystem of an SNMP engine provides services 142 to determine whether access to an object instance is permitted. 144 An Access Control Model has the responsibility for checking if 145 a specific type of access (read, write, notify) to a particular 146 object (instance) is allowed. 148 It is the purpose of this document to define a specific model of 149 the Access Control Subsystem, designated the View-based Access 150 Control Model. 152 1.2. Access Control 154 Access Control occurs (either implicitly or explicitly) in an SNMP 155 entity when processing SNMP retrieval or modification request 156 messages from another SNMP entity. For example a Command Responder 157 application applies Access Control when processing requests that it 158 received from a Command Generator application. These requests 159 include these types of operations: GetRequest, GetNextRequest, 160 GetBulkRequest, and SetRequest operations. 162 Access Control also occurs in an SNMP entity when an SNMP 163 notification message is generated (by a Notification Originator 164 application). These notification messages include these types of 165 operations: InformRequest and SNMPv2-trap operations. 167 The View-based Access Control Model defines a set of services that 168 an application (such as a Command Responder or a Notification 169 Originator application) can use for checking access rights. 170 It is the responsibility of the application to make the proper 171 service calls for access checking. 173 Wijnen/Presuhn/McCloghrie Expires December 1997 [Page 4] 174 1.3. Local Configuration Datastore 176 To implement the model described in this document, an SNMP entity 177 needs to retain information about access rights and policies. 178 This information is part of the SNMP engine's Local Configuration 179 Datastore (LCD). See [SNMP-ARCH] for the definition of LCD. 181 In order to allow an SNMP entity's LCD to be remotely configured, 182 portions of the LCD need to be accessible as managed objects. 183 A MIB module, the View-based Access Control Model Configuration 184 MIB, which defines these managed object types is included in 185 this document. 187 Wijnen/Presuhn/McCloghrie Expires December 1997 [Page 5] 188 ^L 189 Draft View-based Access Control Model (ACM) for SNMP July 1997 191 2. Elements of the Model 193 This section contains definitions to realize the access control 194 service provided by the View-based Access Control Model. 196 2.1. groupName 198 A groupName identifies a group (set) of zero or more securityNames 199 on whose behalf SNMP management objects can be accessed. A group 200 defines the access rights afforded to all securityNames which 201 belong to that group. The combination of a securityModel and a 202 securityName maps to at most one group. 204 The Access Control module assumes that the securityName has already 205 been authenticated as needed and provides no further authentication 206 of its own. 208 The View-based Access Control Model uses the securityModel and the 209 securityName as inputs to the Access Control module when called to 210 check for access rights. It determines the groupName as a function 211 of securityModel and securityName. 213 2.2. Level of Security (LoS) 215 Different access rights for members of a group can be defined for 216 different Levels of Security. The LoS identifies the Level of 217 Security that will be assumed when checking for access rights. See 218 the SNMP Architecture document [SNMP-ARCH] for a definition of LoS. 220 The View-based Access Control Model requires the LoS to be passed 221 as input to the Access Control module when called to check for 222 access rights. 224 2.3. Contexts 226 An SNMP context is a collection of management information 227 accessible by an SNMP entity. An item of management information 228 may exist in more than one context. An SNMP entity potentially 229 has access to many contexts. Details about the naming of 230 management information can be found in the SNMP Architecture 231 document [SNMP-ARCH]. 233 The View-based Access Control Model defines an acmContextTable that 234 lists the locally available contexts by contextName. 236 Wijnen/Presuhn/McCloghrie Expires December 1997 [Page 6] 237 ^L 238 Draft View-based Access Control Model (ACM) for SNMP July 1997 240 2.4. MIB Views and View Families 242 For security reasons, it is often valuable to be able to restrict 243 the access rights of some groups to only a subset of the management 244 information in the management domain. To provide this capability, 245 access to a context is via a "MIB view" which details a specific 246 set of managed object types (and optionally, the specific instances 247 of object types) within that context. For example, for a given 248 context, there will typically always be one MIB view which provides 249 access to all management information in that context, and often 250 there will be other MIB views each of which contains some subset of 251 the information. So, by providing access rights to a group in 252 terms of the particular (subset) MIB view it can access for that 253 context, then the group is restricted in the desired manner. 255 Since managed object types (and their instances) are identified via 256 the tree-like naming structure of ISO's OBJECT IDENTIFIERs 257 [ISO-ASN.1, RFC1902], it is convenient to define a MIB view as the 258 combination of a set of "view subtrees", where each view subtree is 259 a subtree within the managed object naming tree. Thus, a simple 260 MIB view (e.g., all managed objects within the Internet Network 261 Management Framework) can be defined as a single view subtree, 262 while more complicated MIB views (e.g., all information relevant to 263 a particular network interface) can be represented by the union of 264 multiple view subtrees. 266 While any set of managed objects can be described by the union of 267 some number of view subtrees, situations can arise that would 268 require a very large number of view subtrees. This could happen, 269 for example, when specifying all columns in one conceptual row of a 270 MIB table because they would appear in separate subtrees, one per 271 column, each with a very similar format. Because the formats are 272 similar, the required set of subtrees can easily be aggregated into 273 one structure. This structure is named a family of view subtrees 274 after the set of subtrees that it conceptually represents. A family 275 of view subtrees can either be included or excluded from a MIB view. 277 2.4.1. View Subtree 279 A view subtree is the set of all MIB object instances which have a 280 common ASN.1 OBJECT IDENTIFIER prefix to their names. A view 281 subtree is identified by the OBJECT IDENTIFIER value which is the 282 longest OBJECT IDENTIFIER prefix common to all (potential) MIB 283 object instances in that subtree. 285 2.4.2. ViewTreeFamily 287 A family of view subtrees is a pairing of an OBJECT IDENTIFIER value 288 (called the family name) together with a bit string value (called 290 Wijnen/Presuhn/McCloghrie Expires December 1997 [Page 7] 291 the family mask). The family mask indicates which sub-identifiers 292 of the associated family name are significant to the family's 293 definition. 295 For each possible managed object instance, that instance belongs to 296 a particular ViewTreeFamily if both of the following conditions 297 are true: 299 - the OBJECT IDENTIFIER name of the managed object instance contains 300 at least as many sub-identifiers as does the family name, and 302 - each sub-identifier in the OBJECT IDENTIFIER name of the managed 303 object instance matches the corresponding sub-identifier of the 304 family name whenever the corresponding bit of the associated 305 family mask is non-zero. 307 When the configured value of the family mask is all ones, the view 308 subtree family is identical to the single view subtree identified 309 by the family name. 311 When the configured value of the family mask is shorter than 312 required to perform the above test, its value is implicitly 313 extended with ones. Consequently, a view subtree family having a 314 family mask of zero length always corresponds to a single view 315 subtree. 317 2.5. Access Policy 319 The View-based Access Control Model determines the access rights 320 of a group (representing zero, one or more securityNames which have 321 the same access rights). For a particular context (contextName) to 322 which a group (groupName) has access using a particular Security 323 Model (securityModel) and Level of Security (LoS), that group's 324 access rights are given by a read-view, a write-view and a 325 notify-view. 327 The read-view represents the set of object instances authorized for 328 the group when reading objects. Reading objects occurs when 329 processing a retrieval (for example a GetRequest, GetNextRequest, 330 GetBulkRequest) operation. 332 The write-view represents the set of object instances authorized for 333 the group when writing objects. Writing objects occurs when 334 processing a write (for example a Set) operation. 336 The notify-view represents the set of object instances authorized 337 for the group when sending objects in a notification. This occurs 338 when sending a notification (for example an Inform or SNMPv2-Trap). 340 Wijnen/Presuhn/McCloghrie Expires December 1997 [Page 8] 341 ^L 342 Draft View-based Access Control Model (ACM) for SNMP July 1997 344 3. Elements of Procedure 346 This section describes the procedures followed by an Access Control 347 module, that implements the View-based Access Control Model, when 348 checking access rights as requested by an application (for example 349 a Command Responder or a Notification Originator application). 351 The abstract service interface primitive is: 353 statusInformation = -- success or errorIndication 354 isAccessAllowed( 355 securityModel -- Security Model in use 356 securityName -- principal who wants to access 357 LoS -- Level of Security 358 viewType -- read, write, or notify view 359 contextName -- context containing variableName 360 variableName -- OID for the managed object 361 ) 363 Where: 365 statusInformation 366 one of the following: 368 accessAllowed - success (and access is granted). 369 a MIB view was found and access is granted. 370 notInView - success (but access is denied). 371 a MIB view was found but access is denied 372 because the variableName is not in the 373 configured MIB view for the specified 374 viewType (e.g. in the relevant entry in the 375 acmAccessTable). 376 noSuchView - failure, no MIB view found because no view 377 configured for specified viewType (e.g. in 378 the relevant entry in the acmAccessTable). 379 noSuchContext - failure, no MIB view found because no entry 380 in the acmContextTable for the specified 381 contextName. 382 noGroupName - failure, no MIB view found because no entry 383 configured in the acmSecurityToGroupTable 384 for the specified combination of 385 securityModel and securityName. 386 noAccessEntry - failure, no MIB view found because no entry 387 configured in the acmAccessTable for the 388 specified combination of contextName, 389 groupName (as found in the 390 acmSecurityToGroupTable based on 391 securityModel and securityName), 392 securityModel and LoS. 393 otherError - failure, an undefined error occurred. 395 Wijnen/Presuhn/McCloghrie Expires December 1997 [Page 9] 396 securityModel 397 Security Model under which access is requested. 398 securityName 399 representing the principal on whose behalf access is requested. 400 LoS 401 Level of Security under which access is requested. 402 viewType 403 view to be checked (read, write or notify). 404 contextName 405 context in which access to variableName is requested. 406 variableName 407 variable (object instance) to which access is requested. 409 3.1 Processing the isAccessAllowed Service Request 411 This section describes the procedure followed by an Access Control 412 module, that implements the View-based Access Control Model, 413 whenever it receives an isAccessAllowed request. 415 1) The LCD (acmContextTable) is consulted for information about 416 the SNMP context identified by the contextName. If information 417 about this SNMP context is absent from the LCD, then an 418 errorIndication (noSuchContext) is returned to the calling 419 module. 421 2) The LCD (acmSecurityToGroupTable) is consulted for mapping the 422 Security Model (securityModel) and principal (securityName) to a 423 group (groupName). If that information about this combination is 424 absent from the LCD, then an errorIndication (noGroupName) 425 is returned to the calling module. 427 3) The LCD (acmAccessTable) is consulted for information about the 428 contextName, groupName, securityModel and LoS. If information 429 about this combination is absent from the LCD, then an 430 errorIndication (noAccessEntry) is returned to the calling 431 module. 433 4) a) If the viewType is "read", then the read view is used for 434 checking access rights. 436 b) If the viewType is "write", then the write view is used for 437 checking access rights. 439 c) If the viewType is "notify", then the notify view is used 440 for checking access rights. 442 5) a) If there is no view configured for the specified viewType, 443 then an errorIndication (noSuchView) is returned to the 444 calling module. 446 b) If the specified variableName (object instance) is not in the 447 MIB view (see DESCRIPTION clause for acmViewTreeFamilyTable in 448 section 4), then an errorIndication (notInView) is returned 449 to the calling module. 451 Otherwise, 453 c) The specified variableName is in the MIB view. 454 A statusInformation of success (accessAllowed) is returned 455 to the calling module. 457 ^L 459 4. Definitions 461 SNMP-VIEW-BASED-ACM-MIB DEFINITIONS ::= BEGIN 463 IMPORTS 464 MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF 465 MODULE-IDENTITY, OBJECT-TYPE, 466 snmpModules FROM SNMPv2-SMI 467 TestAndIncr, 468 RowStatus, StorageType FROM SNMPv2-TC 469 SnmpAdminString, 470 SnmpLoS, 471 SnmpSecurityModel FROM SNMP-FRAMEWORK-MIB; 473 snmpAcmMIB MODULE-IDENTITY 474 LAST-UPDATED "9707140000Z" -- 14 July 1997, midnight 475 ORGANIZATION "SNMPv3 Working Group" 476 CONTACT-INFO "WG-email: snmpv3@tis.com 477 Subscribe: majordomo@tis.com 478 In message body: subscribe snmpv3 480 Chair: Russ Mundy 481 Trusted Information Systems 482 postal: 3060 Washington Rd 483 Glenwood MD 21738 484 USA 485 email: mundy@tis.com 486 phone: +1-301-854-6889 488 Co-editor: Bert Wijnen 489 IBM T.J. Watson Research 490 postal: Schagen 33 491 3461 GL Linschoten 492 Netherlands 493 email: wijnen@vnet.ibm.com 494 phone: +31-348-432-794 496 Co-editor: Randy Presuhn 497 BMC Software, Inc 498 postal: 1190 Saratoga Avenue, Suite 130 499 San Jose, CA 95129-3433 500 USA 501 email: rpresuhn@bmc.com 502 phone: +1-408-556-0720 504 Co-editor: Keith McCloghrie 505 Cisco Systems, Inc. 506 postal: 170 West Tasman Drive 507 San Jose, CA 95134-1706 508 USA 509 email: kzm@cisco.com 510 phone: +1-408-526-5260 511 " 513 DESCRIPTION "The management information definitions for the 514 View-based Access Control Model for SNMP. 515 " 516 ::= { snmpModules 10 } -- to be verified with IANA 518 -- Administrative assignments **************************************** 520 acmMIBObjects OBJECT IDENTIFIER ::= { snmpAcmMIB 1 } 521 acmMIBConformance OBJECT IDENTIFIER ::= { snmpAcmMIB 2 } 523 -- Information about Local Contexts ********************************** 525 acmContextTable OBJECT-TYPE 526 SYNTAX SEQUENCE OF AcmContextEntry 527 MAX-ACCESS not-accessible 528 STATUS current 529 DESCRIPTION "The table of locally available contexts. If a context 530 is listed in this table that does not mean that 531 access to this context has been defined in the 532 acmAccessTable. It just means that the context exists 533 and that MIB objects may exist in this context. 535 This table must be made accessible via the default 536 context. 538 This table is read-only meaning that it cannot be 539 configured via SNMP. 541 This table is provides information to SNMP Command 542 Generator applications so they can properly configure 543 the acmAccessTable to control access to all contexts 544 at the SNMP entity that provides access to the 545 information in these contexts. 546 " 547 ::= { acmMIBObjects 1 } 549 acmContextEntry OBJECT-TYPE 550 SYNTAX AcmContextEntry 551 MAX-ACCESS not-accessible 552 STATUS current 553 DESCRIPTION "Information about a particular context." 554 INDEX { 555 acmContextName 556 } 557 ::= { acmContextTable 1 } 559 AcmContextEntry ::= SEQUENCE 560 { 561 acmContextName SnmpAdminString 562 } 564 acmContextName OBJECT-TYPE 565 SYNTAX SnmpAdminString (SIZE(0..32)) 566 MAX-ACCESS read-only 567 STATUS current 568 DESCRIPTION "A human readable name identifying a particular 569 context at a particular SNMP entity. 570 " 571 ::= { acmContextEntry 1 } 573 -- Information about Groups ****************************************** 575 acmSecurityToGroupTable OBJECT-TYPE 576 SYNTAX SEQUENCE OF AcmSecurityToGroupEntry 577 MAX-ACCESS not-accessible 578 STATUS current 579 DESCRIPTION "The table that maps a combination of securityModel 580 and securityName into a groupName which defines an 581 access control policy for a group of principals. 582 " 583 ::= { acmMIBObjects 2 } 585 acmSecurityToGroupEntry OBJECT-TYPE 586 SYNTAX AcmSecurityToGroupEntry 587 MAX-ACCESS not-accessible 588 STATUS current 589 DESCRIPTION "An entry in this table maps the combination of a 590 securityModel and securityName into a groupName. 591 " 592 INDEX { 593 acmSecurityModel, 594 acmSecurityName 595 } 596 ::= { acmSecurityToGroupTable 1 } 598 AcmSecurityToGroupEntry ::= SEQUENCE 599 { 600 acmSecurityModel SnmpSecurityModel, 601 acmSecurityName SnmpAdminString, 602 acmGroupName SnmpAdminString, 603 acmSecurityToGroupStorageType StorageType, 604 acmSecurityToGroupStatus RowStatus 605 } 607 acmSecurityModel OBJECT-TYPE 608 SYNTAX SnmpSecurityModel 609 MAX-ACCESS not-accessible 610 STATUS current 611 DESCRIPTION "The Security Model, which is the first index in this 612 table. 613 " 614 ::= { acmSecurityToGroupEntry 1 } 616 acmSecurityName OBJECT-TYPE 617 SYNTAX SnmpAdminString 618 MAX-ACCESS not-accessible 619 STATUS current 620 DESCRIPTION "The securityName for a principal represented in a 621 Security Model independent format. 622 Used as a second index in this table. 623 " 624 ::= { acmSecurityToGroupEntry 2 } 626 acmGroupName OBJECT-TYPE 627 SYNTAX SnmpAdminString 628 MAX-ACCESS read-create 629 STATUS current 630 DESCRIPTION "The name of the group to which this entry (e.g. the 631 combination of securityModel and securityName) 632 belongs. 634 This groupName represents an access control policy 635 and is used as an index in the acmAccessTable. 636 " 637 ::= { acmSecurityToGroupEntry 3 } 639 acmSecurityToGroupStorageType OBJECT-TYPE 640 SYNTAX StorageType 641 MAX-ACCESS read-create 642 STATUS current 643 DESCRIPTION "The storage type for this conceptual row. 645 Conceptual rows having the value 'permanent' need not 646 allow write-access to any columnar objects in the row. 647 " 648 DEFVAL { nonVolatile } 649 ::= { acmSecurityToGroupEntry 4 } 651 acmSecurityToGroupStatus OBJECT-TYPE 652 SYNTAX RowStatus 653 MAX-ACCESS read-create 654 STATUS current 655 DESCRIPTION "The status of this conceptual row. 657 The value of this object has no effect on whether 658 other objects in this conceptual row can be modified. 659 " 660 ::= { acmSecurityToGroupEntry 5 } 662 -- Reverse mapping from groupName into securityName(s) *************** 663 acmGroupListTable OBJECT-TYPE 664 SYNTAX SEQUENCE OF AcmGroupListEntry 665 MAX-ACCESS not-accessible 666 STATUS current 667 DESCRIPTION "The acmGroupListTable complements the 668 acmSecurityToGroupTable by providing an efficient 669 means to determine the membership of a given group. 670 " 671 ::= { acmMIBObjects 3 } 673 acmGroupListEntry OBJECT-TYPE 674 SYNTAX AcmGroupListEntry 675 MAX-ACCESS not-accessible 676 STATUS current 677 DESCRIPTION "An entry in this table corresponds to an entry in the 678 acmSecurityToGroupTable, using acmGroupName as its 679 primary key. 680 " 681 INDEX { 682 acmGroupName, 683 acmSecurityModel, 684 acmSecurityName 685 } 686 ::= { acmGroupListTable 1 } 688 AcmGroupListEntry ::= SEQUENCE 689 { 690 acmGroupListStatus RowStatus 691 } 693 acmGroupListStatus OBJECT-TYPE 694 SYNTAX RowStatus 695 MAX-ACCESS read-only 696 STATUS current 697 DESCRIPTION "The status of this conceptual row. 699 The value is identical to that of the corresponding 700 acmSecurityToGroupEntry's acmSecurityToGroupStatus. 701 " 702 ::= { acmGroupListEntry 1 } 704 -- Information about Access Rights *********************************** 706 acmAccessTable OBJECT-TYPE 707 SYNTAX SEQUENCE OF AcmAccessEntry 708 MAX-ACCESS not-accessible 709 STATUS current 710 DESCRIPTION "The table of group access rights configured in the 711 Local Configuration Datastore (LCD). 713 Each entry is indexed by a contextPrefix, a groupName 714 a securityModel and a Level of Security (LoS). To 715 determine whether access is allowed, one entry from 716 this table needs to be selected and the proper 717 viewName from that entry must be used for access 718 control checking. 720 To select the proper entry, first a match must be 721 found for the contextPrefix. The procedure for this 722 process depends on the value of acmAccessContextMatch: 724 - exact 725 In this case, the acmAccessContextPrefix represents 726 an exact contextName, and so the name must match 727 exactly. 729 - prefix 730 In this case, the acmAccessContextPrefix represents 731 a prefix of a contextName, so that (a limited form 732 of) wildcarding is possible. The value of 733 acmAccessContextPrefix must match with the first 734 part of the contextName to which access is 735 requested. 737 For example, if an acmAccessContextPrefix value of 738 'repeater' is used, then both contexts named 739 'repeater1' and 'repeater2' are accessible. 741 Multiple entries could match. In that case: 743 - The entry which has the longest value for 744 acmAccessContextPrefix wins. 746 Otherwise, if still no single winner (e.g. multiple 747 entries have the same acmAccessContextPrefix value, 749 - The entry which has the value 'exact' for the 750 corresponding acmAccessContextMatch, wins. 752 Otherwise, if still no single winner (e.g. multiple 753 entries have a acmAccessContextMatch value 'exact', 755 - Then continue. At the 4th match to make a final 756 winner will be found if there are still multiple 757 entries. 759 The second match to make is for the groupName. 760 Here an exact match must be found. 762 The 3rd match to make is for the securityModel. 763 Here an exact match must be found. If no such exact 764 match exists, then an entry that has the 'all' value 765 (see definition of SnmpSecurityModel in [SNMP-ARCH]) 766 for the acmAccessSecurityModel is considered to match. 768 The 4th match to make is for the LoS. Here the LoS 769 at which access is requested must be greater than or 770 equal to the value of the acmAccessLoS. 771 If multiple entries are still considered to match, 772 then the entry which has the lowest value for the 773 corresponding acmAccessLoS wins. 774 " 775 ::= { acmMIBObjects 4 } 777 acmAccessEntry OBJECT-TYPE 778 SYNTAX AcmAccessEntry 779 MAX-ACCESS not-accessible 780 STATUS current 781 DESCRIPTION "An access right configured in the Local Configuration 782 Datastore (LCD) authorizing access to an SNMP context. 783 " 784 INDEX { acmAccessContextPrefix, 785 acmGroupName, 786 acmSecurityModel, 787 acmAccessLoS 788 } 789 ::= { acmAccessTable 1 } 791 AcmAccessEntry ::= SEQUENCE 792 { 793 acmAccessContextPrefix SnmpAdminString, 794 acmAccessLoS SnmpLoS, 795 acmAccessContextMatch INTEGER, 796 acmAccessReadViewName SnmpAdminString, 797 acmAccessWriteViewName SnmpAdminString, 798 acmAccessNotifyViewName SnmpAdminString, 799 acmAccessStorageType StorageType, 800 acmAccessStatus RowStatus 801 } 803 acmAccessContextPrefix OBJECT-TYPE 804 SYNTAX SnmpAdminString 805 MAX-ACCESS not-accessible 806 STATUS current 807 DESCRIPTION "In order to gain the access rights allowed by this 808 conceptual row, a contextName must match exactly 809 (if the value of acmAccessContextMatch is 'exact') 810 or partially (if the value of acmAccessContextMatch 811 is 'prefix') to the value of the instance of this 812 object. 813 " 814 ::= { acmAccessEntry 1 } 816 acmAccessLoS OBJECT-TYPE 817 SYNTAX SnmpLoS 818 MAX-ACCESS not-accessible 819 STATUS current 820 DESCRIPTION "The minimum level of security required in order to 821 gain the access rights allowed by this conceptual 822 row. An LoS of noAuthNoPriv is lower than authNoPriv 823 which in turn is lower than authPriv. 825 If multiple entries are equally indexed except for 826 this acmAccessLoS index, then the entry which has 827 the lowest value for acmAccessLoS wins. 828 " 829 ::= { acmAccessEntry 2 } 831 acmAccessContextMatch OBJECT-TYPE 832 SYNTAX INTEGER 833 { exact (1), -- exact match of prefix and contextName 834 prefix (2) -- Only match to the prefix 835 } 836 MAX-ACCESS read-create 837 STATUS current 838 DESCRIPTION "If exact is set, then the value of the index part 839 acmAccessContextPrefix of this entry in this table 840 represents a full contextName. 842 If prefix is set, then the value of the index part 843 acmAccessContextPrefix of this entry in this 844 table represents a partial contextName which acts 845 as a prefix so that a simple form of wildcarding 846 is possible. 847 " 848 ::= { acmAccessEntry 3 } 850 acmAccessReadViewName OBJECT-TYPE 851 SYNTAX SnmpAdminString 852 MAX-ACCESS read-create 853 STATUS current 854 DESCRIPTION "The value of an instance of this object identifies 855 the MIB view of the SNMP context to which this 856 conceptual row authorizes read access. 858 The identified MIB view is that one for which the 859 acmViewTreeFamilyViewName has the same value as the 860 instance of this object; if the value is the empty 861 string or if there is no active MIB view having this 862 value of acmViewTreeFamilyViewName, then no access is 863 granted. 864 " 865 DEFVAL { ''H } -- the empty string 866 ::= { acmAccessEntry 4 } 868 acmAccessWriteViewName OBJECT-TYPE 869 SYNTAX SnmpAdminString 870 MAX-ACCESS read-create 871 STATUS current 872 DESCRIPTION "The value of an instance of this object identifies 873 the MIB view of the SNMP context to which this 874 conceptual row authorizes write access. 876 The identified MIB view is that one for which the 877 acmViewTreeFamilyViewName has the same value as the 878 instance of this object; if the value is the empty 879 string or if there is no active MIB view having this 880 value of acmViewTreeFamilyViewName, then no access is 881 granted. 882 " 883 DEFVAL { ''H } -- the empty string 884 ::= { acmAccessEntry 5 } 886 acmAccessNotifyViewName OBJECT-TYPE 887 SYNTAX SnmpAdminString 888 MAX-ACCESS read-create 889 STATUS current 890 DESCRIPTION "The value of an instance of this object identifies 891 the MIB view of the SNMP context to which this 892 conceptual row authorizes access for notifications. 894 The identified MIB view is that one for which the 895 acmViewTreeFamilyViewName has the same value as the 896 instance of this object; if the value is the empty 897 string or if there is no active MIB view having this 898 value of acmViewTreeFamilyViewName, then no access is 899 granted. 900 " 901 DEFVAL { ''H } -- the empty string 902 ::= { acmAccessEntry 6 } 904 acmAccessStorageType OBJECT-TYPE 905 SYNTAX StorageType 906 MAX-ACCESS read-create 907 STATUS current 908 DESCRIPTION "The storage type for this conceptual row. 910 Conceptual rows having the value 'permanent' need not 911 allow write-access to any columnar objects in the row. 912 " 913 DEFVAL { nonVolatile } 914 ::= { acmAccessEntry 7 } 916 acmAccessStatus OBJECT-TYPE 917 SYNTAX RowStatus 918 MAX-ACCESS read-create 919 STATUS current 920 DESCRIPTION "The status of this conceptual row. 922 The value of this object has no effect on whether 923 other objects in this conceptual row can be modified. 924 " 925 ::= { acmAccessEntry 8 } 927 -- Information about MIB views *************************************** 929 -- Support for views having instance-level granularity is optional 931 acmMIBViews OBJECT IDENTIFIER ::= { acmMIBObjects 5 } 933 acmViewSpinLock OBJECT-TYPE 934 SYNTAX TestAndIncr 935 MAX-ACCESS read-write 936 STATUS current 937 DESCRIPTION "An advisory lock used to allow cooperating SNMP 938 Command Generator applications to coordinate their 939 use of the Set operation in creating view subtrees. 941 When creating a new view or altering an existing 942 view, it is important to understand the potential 943 interactions with other uses of the view. The 944 acmViewSpinLock should be retrieved. The name of the 945 view to be created should be determined to be unique 946 by the SNMP Command Generator application by 947 consulting the acmViewTreeFamilyTable. Finally, the 948 named view may be created (Set), including the 949 advisory lock. 950 If another SNMP Command Generator application has 951 altered the views in the meantime, then the spin 952 lock's value will have changed, and so this creation 953 will fail because it will specify the wrong value for 954 the spin lock. 956 Since this is an advisory lock, the use of this lock 957 is not enforced. 958 " 959 ::= { acmMIBViews 1 } 961 acmViewTreeFamilyTable OBJECT-TYPE 962 SYNTAX SEQUENCE OF AcmViewTreeFamilyEntry 963 MAX-ACCESS not-accessible 964 STATUS current 965 DESCRIPTION "Locally held information about families of subtrees 966 within MIB views. 968 Each MIB view is defined by two sets of view subtrees: 969 - the included view subtrees, and 970 - the excluded view subtrees. 971 Every such view subtree, both included and excluded, 972 is defined in this table. 974 To determine if a particular object instance is in 975 a particular MIB view, compare the object instance's 976 OBJECT IDENTIFIER with each of the MIB view's active 977 entries in this table. If none match, then the 978 object instance is not in the MIB view. If one or 979 more match, then the object instance is included in, 980 or excluded from, the MIB view according to the 981 value of acmViewTreeFamilyType in the entry whose 982 value of acmViewTreeFamilySubtree has the most 983 sub-identifiers. If multiple entries match and have 984 the same number of sub-identifiers, then the 985 lexicographically greatest instance of 986 acmViewTreeFamilyType determines the inclusion or 987 exclusion. 989 An object instance's OBJECT IDENTIFIER X matches an 990 active entry in this table when the number of 991 sub-identifiers in X is at least as many as in the 992 value of acmViewTreeFamilySubtree for the entry, and 993 each sub-identifier in the value of 994 acmViewTreeFamilySubtree matches its corresponding 995 sub-identifier in X. Two sub-identifiers match 996 either if the corresponding bit of the value of 997 acmViewTreeFamilyMask for the entry is zero (the 998 'wild card' value), or if they are equal. 1000 A 'family' of subtrees is the set of subtrees defined 1001 by a particular combination of values of 1002 acmViewTreeFamilySubtree and acmViewTreeFamilyMask. 1003 In the case where no 'wild card' is defined in the 1004 acmViewTreeFamilyMask, the family of subtrees reduces 1005 to a single subtree. 1007 When an SNMP Command Generator application wants to 1008 create a new MIB view, then it should first obtain 1009 the value of the advisory spin lock and a list of 1010 existing named views. It then selects a new 1011 non-existing index-value (viewName) for 1012 acmViewTreeFamilyViewName. The SNMP Command Generator 1013 application can then start creating entries in the 1014 acmViewTreeFamilyTable. It should include the 1015 advisory lock in the Set Operation to ensure that an 1016 other such application has not in the meanwhile 1017 created new entries with a new (possibly colliding) 1018 viewName in this table. 1020 When creating MIB views, it is strongly advised that 1021 first the 'excluded' acmViewTreeFamilyEntries are 1022 created and then the 'included' entries. 1024 When deleting MIB views, it is strongly advised that 1025 first the 'included' acmViewTreeFamilyEntries are 1026 deleted and then the 'excluded' entries. 1027 " 1028 ::= { acmMIBViews 2 } 1030 acmViewTreeFamilyEntry OBJECT-TYPE 1031 SYNTAX AcmViewTreeFamilyEntry 1032 MAX-ACCESS not-accessible 1033 STATUS current 1034 DESCRIPTION "Information on a particular family of view subtrees 1035 included in or excluded from a particular SNMP 1036 context's MIB view. 1038 Implementations must not restrict the number of 1039 families of view subtrees for a given MIB view, 1040 except as dictated by resource constraints on the 1041 overall number of entries in the 1042 acmViewTreeFamilyTable. 1044 The value of acmViewTreeFamilyViewName in the INDEX 1045 clause of this table identifies the MIB view in which 1046 this subtree family exists. 1048 A MIB view (viewName) for which there are no 1049 conceptual rows in this table is the empty set of 1050 view subtrees. 1051 " 1052 INDEX { acmViewTreeFamilyViewName, 1053 acmViewTreeFamilySubtree 1054 } 1055 ::= { acmViewTreeFamilyTable 1 } 1057 AcmViewTreeFamilyEntry ::= SEQUENCE 1058 { 1059 acmViewTreeFamilyViewName SnmpAdminString, 1060 acmViewTreeFamilySubtree OBJECT IDENTIFIER, 1061 acmViewTreeFamilyMask OCTET STRING, 1062 acmViewTreeFamilyType INTEGER, 1063 acmViewTreeFamilyStorageType StorageType, 1064 acmViewTreeFamilyStatus RowStatus 1065 } 1067 acmViewTreeFamilyViewName OBJECT-TYPE 1068 SYNTAX SnmpAdminString 1069 MAX-ACCESS not-accessible 1070 STATUS current 1071 DESCRIPTION "The human readable name for a family of view subtrees. 1072 " 1073 ::= { acmViewTreeFamilyEntry 1 } 1075 acmViewTreeFamilySubtree OBJECT-TYPE 1076 SYNTAX OBJECT IDENTIFIER 1077 MAX-ACCESS not-accessible 1078 STATUS current 1079 DESCRIPTION "The MIB subtree which when combined with the 1080 corresponding instance of acmViewTreeFamilyMask 1081 defines a family of view subtrees. 1082 " 1083 ::= { acmViewTreeFamilyEntry 2 } 1085 acmViewTreeFamilyMask OBJECT-TYPE 1086 SYNTAX OCTET STRING (SIZE (0..16)) 1087 MAX-ACCESS read-create 1088 STATUS current 1089 DESCRIPTION "The bit mask which, in combination with the 1090 corresponding instance of acmViewTreeFamilySubtree, 1091 defines a family of view subtrees. 1093 Each bit of this bit mask corresponds to a 1094 sub-identifier of acmViewTreeFamilySubtree, with the 1095 most significant bit of the i-th octet of this octet 1096 string value (extended if necessary, see below) 1097 corresponding to the (8*i - 7)-th sub-identifier, and 1098 the least significant bit of the i-th octet of this 1099 octet string corresponding to the (8*i)-th 1100 sub-identifier, where i is in the range 1 through 16. 1102 Each bit of this bit mask specifies whether or not 1103 the corresponding sub-identifiers must match when 1104 determining if an OBJECT IDENTIFIER is in this 1105 family of view subtrees; a '1' indicates that an 1106 exact match must occur; a '0' indicates 'wild card', 1107 i.e., any sub-identifier value matches. 1109 Thus, the OBJECT IDENTIFIER X of an object instance 1110 is contained in a family of view subtrees if, for 1111 each sub-identifier of the value of 1112 acmViewTreeFamilySubtree, either: 1114 the i-th bit of acmViewTreeFamilyMask is 0, or 1116 the i-th sub-identifier of X is equal to the i-th 1117 sub-identifier of the value of 1118 acmViewTreeFamilySubtree. 1120 If the value of this bit mask is M bits long and 1121 there are more than M sub-identifiers in the 1122 corresponding instance of acmViewTreeFamilySubtree, 1123 then the bit mask is extended with 1's to be the 1124 required length. 1126 Note that when the value of this object is the 1127 zero-length string, this extension rule results in 1128 a mask of all-1's being used (i.e., no 'wild card'), 1129 and the family of view subtrees is the one view 1130 subtree uniquely identified by the corresponding 1131 instance of acmViewTreeFamilySubtree. 1132 " 1133 DEFVAL { ''H } 1134 ::= { acmViewTreeFamilyEntry 3 } 1136 acmViewTreeFamilyType OBJECT-TYPE 1137 SYNTAX INTEGER { included(1), excluded(2) } 1138 MAX-ACCESS read-create 1139 STATUS current 1140 DESCRIPTION "The indication of whether the corresponding instances 1141 of acmViewTreeFamilySubtree and acmViewTreeFamilyMask 1142 define a family of view subtrees which is included in 1143 or excluded from the MIB view. 1144 " 1145 DEFVAL { included } 1146 ::= { acmViewTreeFamilyEntry 4 } 1148 acmViewTreeFamilyStorageType OBJECT-TYPE 1149 SYNTAX StorageType 1150 MAX-ACCESS read-create 1151 STATUS current 1152 DESCRIPTION "The storage type for this conceptual row. 1154 Conceptual rows having the value 'permanent' need not 1155 allow write-access to any columnar objects in the row. 1156 " 1157 DEFVAL { nonVolatile } 1158 ::= { acmViewTreeFamilyEntry 5 } 1160 acmViewTreeFamilyStatus OBJECT-TYPE 1161 SYNTAX RowStatus 1162 MAX-ACCESS read-create 1163 STATUS current 1164 DESCRIPTION "The status of this conceptual row. 1166 The value of this object has no effect on whether 1167 other objects in this conceptual row can be modified. 1168 " 1169 ::= { acmViewTreeFamilyEntry 6 } 1171 -- Conformance information ******************************************* 1172 acmMIBCompliances OBJECT IDENTIFIER ::= { acmMIBConformance 1 } 1173 acmMIBGroups OBJECT IDENTIFIER ::= { acmMIBConformance 2 } 1175 -- Compliance statements ********************************************* 1177 acmMIBCompliance MODULE-COMPLIANCE 1178 STATUS current 1179 DESCRIPTION "The compliance statement for SNMP engines which 1180 implement the SNMP View-based Access Control Model 1181 configuration MIB. 1182 " 1183 MODULE -- this module 1184 MANDATORY-GROUPS { acmBasicGroup } 1186 OBJECT acmAccessContextMatch 1187 MIN-ACCESS read-only 1188 DESCRIPTION "Write access is not required." 1190 OBJECT acmAccessReadViewName 1191 MIN-ACCESS read-only 1192 DESCRIPTION "Write access is not required." 1194 OBJECT acmAccessWriteViewName 1195 MIN-ACCESS read-only 1196 DESCRIPTION "Write access is not required." 1198 OBJECT acmAccessNotifyViewName 1199 MIN-ACCESS read-only 1200 DESCRIPTION "Write access is not required." 1202 OBJECT acmAccessStorageType 1203 MIN-ACCESS read-only 1204 DESCRIPTION "Write access is not required." 1206 OBJECT acmAccessStatus 1207 MIN-ACCESS read-only 1208 DESCRIPTION "Create access to the acmAccessTable 1209 is not required. 1210 " 1212 OBJECT acmViewTreeFamilyMask 1213 WRITE-SYNTAX OCTET STRING (SIZE (0)) 1214 MIN-ACCESS read-only 1215 DESCRIPTION "Support for configuration via SNMP of subtree 1216 families using wild-cards is not required. 1217 " 1219 OBJECT acmViewTreeFamilyType 1220 MIN-ACCESS read-only 1221 DESCRIPTION "Write access is not required." 1222 OBJECT acmViewTreeFamilyStorageType 1223 MIN-ACCESS read-only 1224 DESCRIPTION "Write access is not required." 1226 OBJECT acmViewTreeFamilyStatus 1227 MIN-ACCESS read-only 1228 DESCRIPTION "Create access to the acmViewTreeFamilyTable 1229 is not required. 1230 " 1231 ::= { acmMIBCompliances 1 } 1233 -- Units of conformance ********************************************** 1235 acmBasicGroup OBJECT-GROUP 1236 OBJECTS { 1237 acmContextName, 1238 acmGroupName, 1239 acmSecurityToGroupStorageType, 1240 acmSecurityToGroupStatus, 1241 acmGroupListStatus, 1242 acmAccessContextMatch, 1243 acmAccessReadViewName, 1244 acmAccessWriteViewName, 1245 acmAccessNotifyViewName, 1246 acmAccessStorageType, 1247 acmAccessStatus, 1248 acmViewSpinLock, 1249 acmViewTreeFamilyMask, 1250 acmViewTreeFamilyType, 1251 acmViewTreeFamilyStorageType, 1252 acmViewTreeFamilyStatus 1253 } 1254 STATUS current 1255 DESCRIPTION "A collection of objects providing for remote 1256 configuration of an SNMP engine which implements 1257 the SNMP View-based Access Control Model (ACM). 1258 " 1259 ::= { acmMIBGroups 1 } 1261 END 1263 ^L 1264 5. Security Considerations 1266 5.1. Recommended Practices 1268 This document is meant for use in the SNMP architecture. The 1269 View-based Access Control Model (ACM) described in this document 1270 checks access rights to management information based on: 1272 - contextName, representing a set of management information at the 1273 managed system where the Access Control module is running. 1274 - groupName, representing a group or set of zero, one or more 1275 securityNames. The combination of a securityModel and a 1276 securityName is mapped into a group in the View-based Access 1277 Control Model. 1278 - securityModel used for the transmission of an SNMP message. 1279 - Level of Security (LoS) used for the transmission of an SNMP 1280 message. 1281 - operation performed on the management information. 1282 - MIB views for read, write or notify access. 1284 When the User-based Access Control module (ACM) is called for 1285 checking access rights, it is assumed that the calling module has 1286 ensured the authentication and privacy aspects as specified by the 1287 Level of Security (LoS) that is being passed. 1289 5.2. Defining Groups 1291 The groupNames are used to give access to a group of zero, one or 1292 more securityNames. Within the ACM, a groupName is considered to 1293 exist if that groupName is listed in the acmSecurityToGroupTable. 1294 By mapping the combination of a securityModel and securityName into 1295 a groupName, an SNMP Command Generator application can add/delete 1296 securityNames to/from a group, that is if proper access is allowed. 1298 5.3. Conformance 1300 For an implementation of the View-based Access Control Model to be 1301 conformant, it MUST implement the SNMP-VIEW-BASED-ACM-MIB. It also 1302 SHOULD [RFC2119] implement the initial configuration, described in 1303 appendix A. 1305 ^L 1307 6. Editor's Addresses 1309 Co-editor: Bert Wijnen 1310 IBM T. J. Watson Research 1311 postal: Schagen 33 1312 3461 GL Linschoten 1313 Netherlands 1314 email: wijnen@vnet.ibm.com 1315 phone: +31-348-432-794 1317 Co-editor: Randy Presuhn 1318 BMC Software, Inc 1319 postal: 1190 Saratoga Avenue, Suite 130 1320 San Jose, CA 95129-3433 1321 USA 1322 email: rpresuhn@bmc.com 1323 phone: +1-408-556-0720 1325 Co-editor: Keith McCloghrie 1326 Cisco Systems, Inc. 1327 postal: 170 West Tasman Drive 1328 San Jose, CA 95134-1706 1329 USA 1330 email: kzm@cisco.com 1331 phone: +1-408-526-5260 1333 7. Acknowledgements 1335 This document describes the work of the SNMP Security and 1336 Administrative Framework Evolution team, comprised of 1338 David Harrington (Cabletron Systems Inc.) 1339 Jeff Johnson (Cisco) 1340 David Levi (SNMP Research Inc.) 1341 John Linn (Openvision) 1342 Russ Mundy (Trusted Information Systems) chair 1343 Shawn Routhier (Epilogue) 1344 Glenn Waters (Nortel) 1345 Bert Wijnen (IBM T. J. Watson Research) 1347 ^L 1349 8. References 1351 [RFC1902] The SNMPv2 Working Group, Case, J., McCloghrie, K., 1352 Rose, M., and S., Waldbusser, "Structure of Management 1353 Information for Version 2 of the Simple Network Management 1354 Protocol (SNMPv2)", RFC 1905, January 1996. 1356 [RFC1905] The SNMPv2 Working Group, Case, J., McCloghrie, K., 1357 Rose, M., and S., Waldbusser, "Protocol Operations for 1358 Version 2 of the Simple Network Management Protocol (SNMPv2)", 1359 RFC 1905, January 1996. 1361 [RFC1906] The SNMPv2 Working Group, Case, J., McCloghrie, K., 1362 Rose, M., and S. Waldbusser, "Transport Mappings for 1363 Version 2 of the Simple Network Management Protocol (SNMPv2)", 1364 RFC 1906, January 1996. 1366 [RFC1907] The SNMPv2 Working Group, Case, J., McCloghrie, K., 1367 Rose, M., and S. Waldbusser, "Management Information Base for 1368 Version 2 of the Simple Network Management Protocol (SNMPv2)", 1369 RFC 1907, January 1996. 1371 [RFC1908] The SNMPv2 Working Group, Case, J., McCloghrie, K., 1372 Rose, M., and S. Waldbusser, "Coexistence between Version 1 1373 and Version 2 of the Internet-standard Network Management 1374 Framework", RFC 1908, January 1996. 1376 [RFC2119] Network Working Group, Bradner, S., "Key words for use in 1377 RFCs to Indicate Requirement Levels", RFC 2119, March 1997. 1379 [SNMP-ARCH] The SNMPv3 Working Group, Harrington, D., Wijnen, B., 1380 "An Architecture for describing Internet Management Frameworks", 1381 draft-ietf-snmpv3-next-gen-arch-02.txt, June 1997. 1383 [SNMPv3-MPC] The SNMPv3 Working Group, Wijnen, B., Harrington, D., 1384 "Message Processing and Control Model for version 3 of the Simple 1385 Network Management Protocol (SNMPv3)", 1386 draft-ietf-snmpv3-mpc-00.txt, July 1997. 1388 [SNMPv3-USM] The SNMPv3 Working Group, Blumenthal, U., Wijnen, B., 1389 "The User-Based Security Model for Version 3 of the Simple 1390 Network Management Protocol (SNMPv3)", 1391 draft-ietf-snmpv3-usm-00.txt, July 1997. 1393 [ISO-ASN.1] Information processing systems - Open Systems 1394 Interconnection - Specification of Abstract Syntax Notation One 1395 (ASN.1), International Organization for Standardization. 1396 International Standard 8824, (December, 1987). 1398 ^L 1400 APPENDIX A - Installation 1402 A.1. Installation Parameters 1404 During installation, an authoritative SNMP engine SHOULD (in the 1405 meaning as defined in [RFC2119]) be configured with several initial 1406 parameters. These include for the View-based Access Control Model: 1408 1) A security posture 1410 The choice of security posture determines if initial configuration 1411 is implemented and if so how. One of three possible choices 1412 is selected: 1414 minimum-secure, 1415 semi-secure, 1416 very-secure (i.e. no-initial-configuration) 1418 In the case of a very-secure posture, there is no initial 1419 configuration, and so the following steps are irrelevant. 1421 2) A default context 1423 One entry in the acmContextTable with a contextName of "" (the 1424 empty string), representing the default context. Note that this 1425 table gets created automatically if a default context exists. 1427 no privacy support privacy support 1428 ------------------ --------------- 1429 acmContextName "" "" 1431 3) An initial group 1433 One entry in the acmSecurityToGroupTable to allow access to group 1434 "initial". 1436 no privacy support privacy support 1437 ------------------ --------------- 1438 acmSecurityModel 3 (USM) 3 (USM) 1439 acmSecurityName "initial" "initial" 1440 acmGroupName "initial" "initial" 1441 acmSecurityToGroupStorageType anyValidStorageType anyValidStorageType 1442 acmSecurityToGroupStatus active active 1444 4) An initial acmGroupListTable 1446 Those columns marked with (index) are index-only objects and are 1447 not really present in this table. Note that this table gets created 1448 automatically because of the configuration of the initial group. 1450 One entry in the acmGroupListTable as follows: 1452 no privacy support privacy support 1453 ------------------ --------------- 1454 acmGroupName (index) "initial" "initial" 1455 acmSecurityModel (index) 3 (USM) 3 (USM) 1456 acmSecurityName (index) "initial" "initial" 1457 acmGroupListStatus active active 1459 5) Initial access rights 1461 Three entries in the acmAccessTable as follows: 1463 - read-notify access for securityModel USM, LoS "noAuthNoPriv" 1464 on behalf of securityNames that belong to the group "initial" to 1465 the MIB view in the context with contextName "". 1467 - read-write-notify access for securityModel USM, LoS "authNoPriv" 1468 on behalf of securityNames that belong to the group "initial" to 1469 the MIB view in the context with contextName "". 1471 - if privacy is supported, 1472 read-write-notify access for securityModel USM for LoS "authPriv" 1473 on behalf of securityNames that belong to the group "initial" to 1474 the MIB view in the context with contextName "". 1476 That translates into the following entries in the acmAccessTable. 1477 Those columns marked with (index) are index-only objects and are 1478 not really present in this table at all. 1480 - One entry to be used for unauthenticated access (noAuthNoPriv): 1482 no privacy support privacy support 1483 ------------------ --------------- 1484 acmAccessContextPrefix "" "" 1485 acmGroupName (index) "initial" "initial" 1486 acmSecurityModel (index) 3 (USM) 3 (USM) 1487 acmAccessLoS noAuthNoPriv noAuthNoPriv 1488 acmAccessReadViewName "restricted" "restricted" 1489 acmAccessWriteViewName "" "" 1490 acmAccessNotifyViewName "restricted" "restricted" 1491 acmAccessStorageType anyValidStorageType anyValidStorageType 1492 acmAccessStatus active active 1494 - One entry to be used for authenticated access but without 1495 privacy (authNoPriv): 1496 no privacy support privacy support 1497 ------------------ --------------- 1498 acmAccessContextPrefix "" "" 1499 acmGroupName (index) "initial" "initial" 1500 acmSecurityModel (index) 3 (USM) 3 (USM) 1501 acmAccessLoS authNoPriv authNoPriv 1502 acmAccessReadViewName "all-iso" "all-iso" 1503 acmAccessWriteViewName "all-iso" "all-iso" 1504 acmAccessNotifyViewName "all-iso" "all-iso" 1505 acmAccessStorageType anyValidStorageType anyValidStorageType 1506 acmAccessStatus active active 1508 - One entry to be used for authenticated access with privacy 1509 (authPriv): 1511 no privacy support privacy support 1512 ------------------ --------------- 1513 acmAccessContextPrefix "" 1514 acmGroupName (index) "initial" 1515 acmSecurityModel (index) 3 (USM) 1516 acmAccessLoS authPriv 1517 acmAccessReadViewName "all-iso" 1518 acmAccessWriteViewName "all-iso" 1519 acmAccessNotifyViewName "all-iso" 1520 acmAccessStorageType anyValidStorageType 1521 acmAccessStatus active 1523 Note however, that this last entry is also covered by the 1524 entry that allows authNoPriv access because the authPriv access 1525 is a better LoS than the authNoPriv. 1527 6) Two MIB views depending on the security posture. 1529 - One view (the view) for authenticated access: 1531 - the MIB view is the following subtree: 1532 "iso" (subtree 1) 1534 - A second view (the view) for unauthenticated 1535 access. This view is configured according to the selected 1536 security posture: 1538 - For the "very-secure" posture there is no default initial 1539 configuration, so no MIB views are pre-scribed. 1541 - For the "semi-secure" posture: 1543 the MIB view is the union of these subtrees: 1544 (a) "system" (subtree 1.3.6.1.2.1.1) [RFC1907] 1545 (b) "snmp" (subtree 1.3.6.1.2.1.11) [RFC1907] 1546 (c) "snmpEngine" (subtree 1.3.6.1.6.3.7.2.1) [SNMP-ARCH] 1547 (d) "snmpV3Stats" (subtree 1.3.6.1.6.3.8.2.1) [SNMPv3-MPC] 1548 (e) "usmStats" (subtree 1.3.6.1.6.3.9.2.1) [SNMPv3-USM] 1550 - For the "minimum-secure" posture: 1552 the MIB view is the following subtree. 1553 "iso" (subtree 1) 1555 This translates into the following "all-iso" entry in the 1556 acmViewTreeFamilyTable: 1558 minimum-secure semi-secure 1559 ---------------- --------------- 1560 acmViewTreeFamilyViewName "all-iso" "all-iso" 1561 acmViewTreeFamilySubtree 1 1 1562 acmViewTreeFamilyMask "" "" 1563 acmViewTreeFamilyType 1 (included) 1 (included) 1564 acmViewTreeFamilyStorageType anyValidStorageType anyValidStorageType 1565 acmViewTreeFamilyStatus active active 1567 This translates into the following "restricted" entries in the 1568 acmViewTreeFamilyTable: 1570 minimum-secure semi-secure 1571 ---------------- --------------- 1572 acmViewTreeFamilyViewName "restricted" "restricted" 1573 acmViewTreeFamilySubtree 1 1.3.6.1.2.1.1 1574 acmViewTreeFamilyMask " " "" 1575 acmViewTreeFamilyType 1 (included) 1 (included) 1576 acmViewTreeFamilyStorageType anyValidStorageType anyValidStorageType 1577 acmViewTreeFamilyStatus active active 1579 acmViewTreeFamilyViewName "restricted" 1580 acmViewTreeFamilySubtree 1.3.6.1.2.1.11 1581 acmViewTreeFamilyMask "" 1582 acmViewTreeFamilyType 1 (included) 1583 acmViewTreeFamilyStorageType anyValidStorageType 1584 acmViewTreeFamilyStatus active 1586 acmViewTreeFamilyViewName "restricted" 1587 acmViewTreeFamilySubtree 1.3.6.1.6.3.7.2.1 1588 acmViewTreeFamilyMask "" 1589 acmViewTreeFamilyType 1 (included) 1590 acmViewTreeFamilyStorageType anyValidStorageType 1591 acmViewTreeFamilyStatus active 1593 acmViewTreeFamilyViewName "restricted" 1594 acmViewTreeFamilySubtree 1.3.6.1.6.3.8.2.1 1595 acmViewTreeFamilyMask "" 1596 acmViewTreeFamilyType 1 (included) 1597 acmViewTreeFamilyStorageType anyValidStorageType 1598 acmViewTreeFamilyStatus active 1600 acmViewTreeFamilyViewName "restricted" 1601 acmViewTreeFamilySubtree 1.3.6.1.6.3.9.2.1 1602 acmViewTreeFamilyMask "" 1603 acmViewTreeFamilyType 1 (included) 1604 acmViewTreeFamilyStorageType anyValidStorageType 1605 acmViewTreeFamilyStatus active 1607 Table of Contents 1609 0. Issues and Change Log 2 1610 0.1. Issues 2 1611 0.2. Change Log 2 1612 1. Introduction 4 1613 1.2. Access Control 4 1614 1.3. Local Configuration Datastore 5 1615 2. Elements of the Model 6 1616 2.1. groupName 6 1617 2.2. Level of Security (LoS) 6 1618 2.3. Contexts 6 1619 2.4. MIB Views and View Families 7 1620 2.4.1. View Subtree 7 1621 2.4.2. ViewTreeFamily 7 1622 2.5. Access Policy 8 1623 3. Elements of Procedure 9 1624 3.1 Processing the isAccessAllowed Service Request 10 1625 4. Definitions 12 1626 5. Security Considerations 28 1627 5.1. Recommended Practices 28 1628 5.2. Defining Groups 28 1629 5.3. Conformance 28 1630 6. Editor's Addresses 29 1631 7. Acknowledgements 29 1632 8. References 30 1633 A.1. Installation Parameters 31