idnits 2.17.1 draft-ietf-snmpv3-acm-03.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-19) 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 9 longer pages, the longest (page 39) being 60 lines 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. ** There are 179 instances of too long lines in the document, the longest one being 55 characters in excess of 72. ** The abstract seems to contain references ([SNMP-ARCH]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 4 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 491 has weird spacing: '...verview of is...' == Line 1654 has weird spacing: '...support priva...' == Line 1663 has weird spacing: '...support priva...' == Line 1700 has weird spacing: '...support priva...' == Line 1705 has weird spacing: '...tyLevel noA...' == (4 more instances...) == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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: 'RFC1907' is mentioned on line 1763, but not defined ** Obsolete undefined reference: RFC 1907 (Obsoleted by RFC 3418) == Missing Reference: 'SNMP-USM' is mentioned on line 1766, but not defined == Unused Reference: 'RFC1902' is defined on line 1597, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1902 (Obsoleted by RFC 2578) ** Obsolete normative reference: RFC 1903 (Obsoleted by RFC 2579) == Outdated reference: A later version (-06) exists of draft-ietf-snmpv3-next-gen-arch-05 == Outdated reference: A later version (-06) exists of draft-ietf-snmpv3-v3mpc-model-03 Summary: 14 errors (**), 0 flaws (~~), 15 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 View-based Access Control Model (VACM) for the 3 Simple Network Management Protocol (SNMP) 5 30 September 1997 2 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 for use 41 in the SNMP architecture [SNMP-ARCH]. It defines the Elements of 42 Procedure for controlling access to management information. This 43 document also includes a MIB for remotely managing the configuration 44 parameters for the View-based Access Control Model. 46 Wijnen/Presuhn/McCloghrie Expires March 1998 [Page 1] 47 Draft View-based Access Control Model (ACM) for SNMP September 1997 49 0. Issues and Change Log 51 When we go to RFC status, we will remove all the text of section 0. 2 53 0.1. Resolved issues 54 - There is a reverse mapping from groupName to securityName, see 55 the vacmGroupListTable. However, given the amount of object 56 we're adding, we may want to remove/postpone this table? 57 Resolution: remove for now. 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) as soon as possible. 62 Resolution: yes. 63 - Should we use human readable strings or integers for an index for 64 the tables. 65 Resolution. It was decided at the 1st and 2nd interim meeting that 66 using human readable strings would be very helpful when humans 67 have to configure many of those tables. We must specify the size 68 limits for objects that have a human readable SnmpAdminString and 69 which are used for indexing. It seems that a size limit of 32 70 is appropriate and acceptable (although tight in some languages). 71 Note also, that the issue is not just ACM, it is a general issue 72 that applies to all MIBs in all documents. 73 - Ensure valid indices. 74 Resolution. String based indices now have a size limit to ensure 75 that the resulting OIDs for instances will not exceed the limits 76 defined in RFC1905. 77 - The initial "all-iso" MIB view was not workable. 78 Resolution. Define and use the "internet" MIB view instead. 80 0.2. Change Log 82 [version 6.2] - This is the September 30 version 2 83 - these changes are marked with a revision-code "2" in right margin 2 84 - fix writeup of vacmAccessTable (comments Dave Levi) 2 85 - Quick spell check. 2 86 - SMICng compile the mib to verify correct syntax 2 87 - paginate. 2 88 - post as I-D: 2 89 2 90 [version 6.1] - This is the September 29 version | 91 - these changes are marked with a revision-code "|" in right margin | 92 - fixes based on comments by Dave Levy and Jeff Case | ! 93 - use vacmAccessSecurityModel as the index in vacmAccessTable | 94 - add text to section 1 to explain usage of SHOULD, MUST and such. | 95 - add a comma too e.g. and i.e. occurrences. | 96 - remove any un-referenced references from "references" section. | 97 - Quick spell check. | 98 - SMICng compile the mib to verify correct syntax | 100 Wijnen/Presuhn/McCloghrie Expires March 1998 [Page 2] 101 Draft View-based Access Control Model (ACM) for SNMP September 1997 103 | 104 [version 6.0] - This is the September 22 version | 105 - these changes are marked with a revision-code "|" in right margin | 106 - Be more specific on instance level granularity in | 107 vacmViewTreeFamilyTable | 108 - Add clarifying text to sections 5.1 and 5.2 | 109 - add clarifying text to vacmContextName DESCRIPTION clause | 110 - mark references that are (for now) just placeholders and not | 111 really referenced. | 112 - added text about not needing to support instance-level granularity | 113 for access control. Also explained what a manager can expect in | 114 that case. | 115 - Some changes based on Dave Perkins comments | 116 - viewSpinLock DESCRIPTION clause | 117 - diagram intro in section 3.1 | 118 - Some changes based on JDC comments | 119 - change in appendix A. | 120 - numbered the bullets in section 3.1 for easier reference. | 121 - New writeup for selection of proper entry from vacmAccessTable | 122 - Added vacmAccessSecurityModel in vacmAccessTable, which can take | 123 a value of any; had to renumber other columns as a result. | 124 - some more text changes to clarify text better. | 125 | 127 [version 5.2] - This is the August 1 version. 128 - Incorporate comments from Keith 129 - Incorporate comments from Randy 130 - Add figure to section 3 131 - Update References 132 - Update acknowledgement section 133 - Add reference to RowStatus TC when using RowStatus 134 - Spell check once more 135 - Paginate 136 - Post to I-D repository and SNMPv3 mailing list as: 137 139 [version 5.1] - This is the July 28 version. 140 - Spell check 141 - SMICng check 143 [version 5.0] - This is the July 24 version. 144 - various types and editorial changes 145 - Adapt to latest Service Primitives 146 - remove vacmGroupListTable 147 - change index sequence for vacmSecurityToGroupTable 148 - rename prefix from acm to vacm 149 - rename LoS to securityLevel 150 - Changes as a result of comments on snmpv3 list 151 - use the bridge MIB as an example instead of repeater MIB. 152 - rename "security-posture" to "initial-configuration" 154 Wijnen/Presuhn/McCloghrie Expires March 1998 [Page 3] 155 Draft View-based Access Control Model (ACM) for SNMP September 1997 157 [version 4.2] - This is the July 14 version. 158 - Address comments by Keith: 159 - Renumber section 2.4 to 2.5 160 - Add new sections 2.4, 2.4.1, 2.4.2 about MIB Views and Subtrees 161 and Families, 162 - Use some more precise language at various places. 163 - Add reference to RFC2119 about use of SHOULD and MUST 164 - rename the acmGroupTable to acmSecurityToGroupTable because that 165 much better indicates the function of this table. 166 - improved the writeup on statusInformation for the isAccessAllowed 167 primitive. 168 - paginate and generate table of contents 169 - posted as I-D on 15 July 171 [version 4.1] - This is the July 12 version. 172 - Adapt to latest list of Primitives/Parameters. 173 - Handle comments from co-editor Randy 174 - Added the SHOULD "initial" configuration 175 - Checked the MIB with SMICng 177 [version 4.0] - This is the July 7 version. 178 - Adopt to decisions/comments made are 2nd interim 179 - securityName to groupName mapping is in ACM 180 - out of the box configurations to be described as SHOULD 181 - UTF-8 issue still open, but move to general issue (ARCH) 182 where the SnmpAdminString is defined. 183 - ACM returns errorIndication based on which the caller 184 may increment error counter which may result in a 185 Report PDU. 186 - No statistics counters are kept in ACM 187 - removed viewTable; added acmViewSpinLock 188 - Address various comments from co-editors (Randy and Keith) 189 - Address comments made on mailing list(s). 191 [version 3.1] - This is the June 18 version. 192 - remove old (resolved) issues 193 - list new issues 194 - corrections/additions by myself (Bert) 195 - corrections based on dbh comments 196 - removed change log of before 1st interim meeting. 198 [version 3.0] - this is the first ACM document (June 12 version). 199 - Modifications as agreed at 1st Interim Meeting 200 - Make Access Control Module a separate document 201 - Use viewName as index instead of an integer 202 - add notify_view 203 - use SnmpAdminString 204 - Other Modification 205 - use miId and securityModel 206 - add acmGroupTable 207 - add/rename Stats counters 209 Wijnen/Presuhn/McCloghrie Expires March 1998 [Page 4] 210 Draft View-based Access Control Model (ACM) for SNMP September 1997 212 1. Introduction 214 The Architecture for describing Internet Management Frameworks 215 [SNMP-ARCH] describes that an SNMP engine is composed of: 217 1) a Dispatcher 218 2) a Message Processing Subsystem, 219 3) a Security Subsystem, and 220 4) an Access Control Subsystem. 222 Applications make use of the services of these subsystems. 224 It is important to understand the SNMP architecture and its 225 terminology to understand where the View-based Access Control 226 Model described in this document fits into the architecture and 227 interacts with other subsystems within the architecture. The 228 reader is expected to have read and understood the description and 229 terminology of the SNMP architecture, as defined in [SNMP-ARCH]. 231 The Access Control Subsystem of an SNMP engine has the 232 responsibility for checking whether a specific type of access 233 (read, write, notify) to a particular object (instance) is allowed. 235 It is the purpose of this document to define a specific model of 236 the Access Control Subsystem, designated the View-based Access 237 Control Model. Note that this is not necessarily the only Access | 238 Control Model. | 240 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | 241 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | 242 document are to be interpreted as described in [RFC2119]. | 244 1.2. Access Control 246 Access Control occurs (either implicitly or explicitly) in an SNMP 247 entity when processing SNMP retrieval or modification request 248 messages from an SNMP entity. For example a Command Responder 249 application applies Access Control when processing requests that it 250 received from a Command Generator application. These requests 251 include these types of operations: GetRequest, GetNextRequest, 252 GetBulkRequest, and SetRequest operations. 254 Access Control also occurs in an SNMP entity when an SNMP 255 notification message is generated (by a Notification Originator 256 application). These notification messages include these types of 257 operations: InformRequest and SNMPv2-Trap operations. 259 The View-based Access Control Model defines a set of services that 260 an application (such as a Command Responder or a Notification 261 Originator application) can use for checking access rights. 262 It is the responsibility of the application to make the proper 264 Wijnen/Presuhn/McCloghrie Expires March 1998 [Page 5] 265 Draft View-based Access Control Model (ACM) for SNMP September 1997 267 service calls for access checking. 269 1.3. Local Configuration Datastore 271 To implement the model described in this document, an SNMP entity 272 needs to retain information about access rights and policies. 273 This information is part of the SNMP engine's Local Configuration 274 Datastore (LCD). See [SNMP-ARCH] for the definition of LCD. 276 In order to allow an SNMP entity's LCD to be remotely configured, 277 portions of the LCD need to be accessible as managed objects. 278 A MIB module, the View-based Access Control Model Configuration 279 MIB, which defines these managed object types is included in 280 this document. 282 Wijnen/Presuhn/McCloghrie Expires March 1998 [Page 6] 283 Draft View-based Access Control Model (ACM) for SNMP September 1997 285 2. Elements of the Model 287 This section contains definitions to realize the access control 288 service provided by the View-based Access Control Model. 290 2.1. Groups 292 A group is a set of zero or more 293 tuples on whose behalf SNMP management objects can be accessed. 294 A group defines the access rights afforded to all securityNames 295 which belong to that group. The combination of a securityModel 296 and a securityName maps to at most one group. A group is 297 identified by a groupName. 299 The Access Control module assumes that the securityName has already 300 been authenticated as needed and provides no further authentication 301 of its own. 303 The View-based Access Control Model uses the securityModel and the 304 securityName as inputs to the Access Control module when called to 305 check for access rights. It determines the groupName as a function 306 of securityModel and securityName. 308 2.2. securityLevel 310 Different access rights for members of a group can be defined for 311 different levels of security, i.e., noAuthNoPriv, authNoPriv, and | 312 authPriv. The securityLevel identifies the level of security that | 313 will be assumed when checking for access rights. See the SNMP | 314 Architecture document [SNMP-ARCH] for a definition of securityLevel. | 316 The View-based Access Control Model requires that the securityLevel 317 is passed as input to the Access Control module when called to check 318 for access rights. 320 2.3. Contexts 322 An SNMP context is a collection of management information 323 accessible by an SNMP entity. An item of management information 324 may exist in more than one context. An SNMP entity potentially 325 has access to many contexts. Details about the naming of 326 management information can be found in the SNMP Architecture 327 document [SNMP-ARCH]. 329 The View-based Access Control Model defines a vacmContextTable that 330 lists the locally available contexts by contextName. 332 Wijnen/Presuhn/McCloghrie Expires March 1998 [Page 7] 333 Draft View-based Access Control Model (ACM) for SNMP September 1997 335 2.4. MIB Views and View Families 337 For security reasons, it is often valuable to be able to restrict 338 the access rights of some groups to only a subset of the management 339 information in the management domain. To provide this capability, 340 access to a context is via a "MIB view" which details a specific 341 set of managed object types (and optionally, the specific instances 342 of object types) within that context. For example, for a given 343 context, there will typically always be one MIB view which provides 344 access to all management information in that context, and often 345 there will be other MIB views each of which contains some subset of 346 the information. So, the access allowed for a group can be 347 restricted in the desired manner by specifying its rights in terms 348 of the particular (subset) MIB view it can access within each 349 appropriate context. 351 Since managed object types (and their instances) are identified via 352 the tree-like naming structure of ISO's OBJECT IDENTIFIERs 353 [ISO-ASN.1, RFC1902], it is convenient to define a MIB view as the 354 combination of a set of "view subtrees", where each view subtree is 355 a subtree within the managed object naming tree. Thus, a simple 356 MIB view (e.g., all managed objects within the Internet Network 357 Management Framework) can be defined as a single view subtree, 358 while more complicated MIB views (e.g., all information relevant to 359 a particular network interface) can be represented by the union of 360 multiple view subtrees. 362 While any set of managed objects can be described by the union of 363 some number of view subtrees, situations can arise that would 364 require a very large number of view subtrees. This could happen, 365 for example, when specifying all columns in one conceptual row of a 366 MIB table because they would appear in separate subtrees, one per 367 column, each with a very similar format. Because the formats are 368 similar, the required set of subtrees can easily be aggregated into 369 one structure. This structure is named a family of view subtrees 370 after the set of subtrees that it conceptually represents. A family 371 of view subtrees can either be included or excluded from a MIB view. 373 2.4.1. View Subtree 375 A view subtree is the set of all MIB object instances which have a 376 common ASN.1 OBJECT IDENTIFIER prefix to their names. A view 377 subtree is identified by the OBJECT IDENTIFIER value which is the 378 longest OBJECT IDENTIFIER prefix common to all (potential) MIB 379 object instances in that subtree. 381 2.4.2. ViewTreeFamily 383 A family of view subtrees is a pairing of an OBJECT IDENTIFIER value 385 Wijnen/Presuhn/McCloghrie Expires March 1998 [Page 8] 386 Draft View-based Access Control Model (ACM) for SNMP September 1997 388 (called the family name) together with a bit string value (called 389 the family mask). The family mask indicates which sub-identifiers 390 of the associated family name are significant to the family's 391 definition. 393 For each possible managed object instance, that instance belongs to 394 a particular ViewTreeFamily if both of the following conditions 395 are true: 397 - the OBJECT IDENTIFIER name of the managed object instance contains 398 at least as many sub-identifiers as does the family name, and 400 - each sub-identifier in the OBJECT IDENTIFIER name of the managed 401 object instance matches the corresponding sub-identifier of the 402 family name whenever the corresponding bit of the associated 403 family mask is non-zero. 405 When the configured value of the family mask is all ones, the view 406 subtree family is identical to the single view subtree identified 407 by the family name. 409 When the configured value of the family mask is shorter than 410 required to perform the above test, its value is implicitly 411 extended with ones. Consequently, a view subtree family having a 412 family mask of zero length always corresponds to a single view 413 subtree. 415 2.5. Access Policy 417 The View-based Access Control Model determines the access rights 418 of a group, representing zero or more securityNames which have 419 the same access rights. For a particular context, identified by 420 contextName, to which a group, identified by groupName, has access 421 using a particular securityModel and securityLevel, that group's 422 access rights are given by a read-view, a write-view and a 423 notify-view. 425 The read-view represents the set of object instances authorized for 426 the group when reading objects. Reading objects occurs when 427 processing a retrieval (for example a GetRequest, GetNextRequest, 428 GetBulkRequest) operation. 430 The write-view represents the set of object instances authorized for 431 the group when writing objects. Writing objects occurs when 432 processing a write (for example a Set) operation. 434 The notify-view represents the set of object instances authorized 435 for the group when sending objects in a notification, such as 436 when sending a notification (for example an Inform or SNMPv2-Trap). 438 Wijnen/Presuhn/McCloghrie Expires March 1998 [Page 9] 439 Draft View-based Access Control Model (ACM) for SNMP September 1997 441 3. Elements of Procedure 443 This section describes the procedures followed by an Access Control 444 module that implements the View-based Access Control Model when 445 checking access rights as requested by an application (for example 446 a Command Responder or a Notification Originator application). 447 The abstract service primitive is: 449 statusInformation = -- success or errorIndication 450 isAccessAllowed( 451 securityModel -- Security Model in use 452 securityName -- principal who wants access 453 securityLevel -- Level of Security 454 viewType -- read, write, or notify view 455 contextName -- context containing variableName 456 variableName -- OID for the managed object 457 ) 459 The abstract data elements are: 461 statusInformation - one of the following: 462 accessAllowed - a MIB view was found and access is granted. 463 notInView - a MIB view was found but access is denied. 464 The variableName is not in the configured 465 MIB view for the specified viewType (e.g., in | 466 the relevant entry in the vacmAccessTable). 467 noSuchView - no MIB view found because no view has been 468 configured for specified viewType (e.g., in | 469 the relevant entry in the vacmAccessTable). 470 noSuchContext - no MIB view found because of no entry in the 471 vacmContextTable for specified contextName. 472 noGroupName - no MIB view found because no entry has been 473 configured in the vacmSecurityToGroupTable 474 for the specified combination of 475 securityModel and securityName. 476 noAccessEntry - no MIB view found because no entry has been 477 configured in the vacmAccessTable for the 478 specified combination of contextName, 479 groupName (from vacmSecurityToGroupTable), 480 securityModel and securityLevel. 481 otherError - failure, an undefined error occurred. 482 securityModel - Security Model under which access is requested. 483 securityName - the principal on whose behalf access is requested. 484 securityLevel - Level of Security under which access is requested. 485 viewType - view to be checked (read, write or notify). 486 contextName - context in which access is requested. 487 variableName - object instance to which access is requested. 489 Draft View-based Access Control Model (ACM) for SNMP September 1997 491 3.1. Overview of isAccessAllowed Process 493 The following picture shows how the decision for access control is | 494 made by the View-based Access Control Model. | 495 | 496 +--------------------------------------------------------------------+ 497 | | 498 | +-> securityModel -+ | 499 | | (a) | | 500 | who -+ +-> groupName ----+ | 501 | (1) | | (x) | | 502 | +-> securityName --+ | | 503 | (b) | | 504 | | | 505 | where -> contextName ---------------------+ | 506 | (2) (e) | | 507 | | | 508 | | | 509 | +-> securityModel -------------------+ | 510 | | (a) | | 511 | how -+ +-> viewName -+ | 512 | (3) | | (y) | | 513 | +-> securityLevel -------------------+ | | 514 | (c) | +-> yes/no | 515 | | | decision | 516 | why ---> viewType (read/write/notify) ----+ | (z) | 517 | (4) (d) | | 518 | | | 519 | what --> object-type ------+ | | 520 | (5) (m) | | | 521 | +-> variableName (OID) ------+ | 522 | | (f) | 523 | which -> object-instance --+ | 524 | (6) (n) | 525 | | 526 +--------------------------------------------------------------------+ 528 How the decision for isAccessAllowed is made. 530 1) Inputs to the isAccessAllowed service are: | 532 (a) securityModel -- Security Model in use 533 (b) securityName -- principal who wants to access 534 (c) securityLevel -- Level of Security 535 (d) viewType -- read, write, or notify view 536 (e) contextName -- context containing variableName 537 (f) variableName -- OID for the managed object 538 -- this is made up of: | 539 - object-type (m) | 540 - object-instance (n) | 542 Draft View-based Access Control Model (ACM) for SNMP September 1997 544 2) The partial "who" (1), represented by the securityModel (a) and 545 the securityName (b), are used as the indices (a,b) into the 546 vacmSecurityToGroupTable to find a single entry that produces a 547 group, represented by groupName (x). 549 3) The "where" (2), represented by the contextName (e), the "who", | 550 represented by the groupName (x) from the previous step, and the 551 "how" (3), represented by securityModel (a) and securityLevel (c), 552 are used as indices (e,x,a,c) into the vacmAccessTable to find a 553 single entry that contains three MIB views. 555 4) The "why" (4), represented by the viewType (d), is used to select | 556 the proper MIB view, represented by a viewName (y), from the 557 vacmAccessEntry selected in the previous step. This viewName (y) 558 is an index into the vacmViewTreeFamilyTable and selects the set 559 of entries that define the variableNames which are included in 560 or excluded from the MIB view identified by the viewName (y). 562 5) The "what" (5) type of management data and "which" (6) particular | 563 instance, represented by the variableName (f), is then checked to 564 be in the MIB view or not, e.g., the yes/no decision (z). | 566 3.2. Processing the isAccessAllowed Service Request 568 This section describes the procedure followed by an Access Control 569 module that implements the View-based Access Control Model 570 whenever it receives an isAccessAllowed request. 572 1) The vacmContextTable is consulted for information about 573 the SNMP context identified by the contextName. If information 574 about this SNMP context is absent from the table, then an 575 errorIndication (noSuchContext) is returned to the calling 576 module. 578 2) The vacmSecurityToGroupTable is consulted for mapping the 579 securityModel and securityName to a groupName. If the 580 information about this combination is absent from the table, 581 then an errorIndication (noGroupName) is returned to the 582 calling module. 584 3) The vacmAccessTable is consulted for information about the 585 groupName, contextName, securityModel and securityLevel. If 586 information about this combination is absent from the table, 587 then an errorIndication (noAccessEntry) is returned to the 588 calling module. 590 4) a) If the viewType is "read", then the read view is used for 591 checking access rights. 593 b) If the viewType is "write", then the write view is used for 594 checking access rights. 596 Draft View-based Access Control Model (ACM) for SNMP September 1997 598 c) If the viewType is "notify", then the notify view is used 599 for checking access rights. 601 If the view to be used is the empty view (zero length viewName) 602 then an errorIndication (noSuchView) is returned to the calling 603 module. 605 5) a) If there is no view configured for the specified viewType, 606 then an errorIndication (noSuchView) is returned to the 607 calling module. 609 b) If the specified variableName (object instance) is not in the 610 MIB view (see DESCRIPTION clause for vacmViewTreeFamilyTable 611 in section 4), then an errorIndication (notInView) is returned 612 to the calling module. 614 Otherwise, 616 c) The specified variableName is in the MIB view. 617 A statusInformation of success (accessAllowed) is returned 618 to the calling module. 620 Draft View-based Access Control Model (ACM) for SNMP September 1997 622 4. Definitions 624 SNMP-VIEW-BASED-ACM-MIB DEFINITIONS ::= BEGIN 626 IMPORTS 627 MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF 628 MODULE-IDENTITY, OBJECT-TYPE, 629 snmpModules FROM SNMPv2-SMI 630 TestAndIncr, 631 RowStatus, StorageType FROM SNMPv2-TC 632 SnmpAdminString, 633 SnmpSecurityLevel, 634 SnmpSecurityModel FROM SNMP-FRAMEWORK-MIB; 636 snmpVacmMIB MODULE-IDENTITY 637 LAST-UPDATED "9709290000Z" -- 29 Sep 1997, midnight | 638 ORGANIZATION "SNMPv3 Working Group" 639 CONTACT-INFO "WG-email: snmpv3@tis.com 640 Subscribe: majordomo@tis.com 641 In message body: subscribe snmpv3 643 Chair: Russ Mundy 644 Trusted Information Systems 645 postal: 3060 Washington Rd 646 Glenwood MD 21738 647 USA 648 email: mundy@tis.com 649 phone: +1-301-854-6889 651 Co-editor: Bert Wijnen 652 IBM T.J. Watson Research 653 postal: Schagen 33 654 3461 GL Linschoten 655 Netherlands 656 email: wijnen@vnet.ibm.com 657 phone: +31-348-432-794 659 Co-editor: Randy Presuhn 660 BMC Software, Inc 661 postal: 1190 Saratoga Avenue, Suite 130 662 San Jose, CA 95129-3433 663 USA 664 email: rpresuhn@bmc.com 665 phone: +1-408-556-0720 667 Co-editor: Keith McCloghrie 668 Cisco Systems, Inc. 669 postal: 170 West Tasman Drive 670 San Jose, CA 95134-1706 671 USA 672 email: kzm@cisco.com 674 Draft View-based Access Control Model (ACM) for SNMP September 1997 676 phone: +1-408-526-5260 677 " 678 DESCRIPTION "The management information definitions for the 679 View-based Access Control Model for SNMP. 680 " 681 ::= { snmpModules 10 } -- to be verified with IANA 683 -- Administrative assignments **************************************** 685 vacmMIBObjects OBJECT IDENTIFIER ::= { snmpVacmMIB 1 } 686 vacmMIBConformance OBJECT IDENTIFIER ::= { snmpVacmMIB 2 } 688 -- Information about Local Contexts ********************************** 690 vacmContextTable OBJECT-TYPE 691 SYNTAX SEQUENCE OF VacmContextEntry 692 MAX-ACCESS not-accessible 693 STATUS current 694 DESCRIPTION "The table of locally available contexts. 696 This table provides information to SNMP Command 697 Generator applications so that they can properly 698 configure the vacmAccessTable to control access to 699 all contexts at the SNMP entity. 701 This table may change dynamically if the SNMP entity 702 allows that contexts are added/deleted dynamically 703 (for instance when its configuration changes). Such 704 changes would happen only if the management 705 instrumentation at that SNMP entity recognizes more 706 (or fewer) contexts. 708 The presence of entries in this table and of entries 709 in the vacmAccessTable are independent. That is, a 710 context identified by an entry in this table is not | 711 necessarily referenced by any entries in the | 712 vacmAccessTable; and the context(s) referenced by an 713 entry in the vacmAccessTable does not necessarily | 714 currently exist and thus need not be identified by an | 715 entry in this table. | 717 This table must be made accessible via the default 718 context so that Command Responder applications have 719 a standard way of retrieving the information. 721 This table is read-only. It cannot be configured via 722 SNMP. 723 " 724 ::= { vacmMIBObjects 1 } 726 vacmContextEntry OBJECT-TYPE 727 Draft View-based Access Control Model (ACM) for SNMP September 1997 729 SYNTAX VacmContextEntry 730 MAX-ACCESS not-accessible 731 STATUS current 732 DESCRIPTION "Information about a particular context." 733 INDEX { 734 vacmContextName 735 } 736 ::= { vacmContextTable 1 } 738 VacmContextEntry ::= SEQUENCE 739 { 740 vacmContextName SnmpAdminString 741 } 743 vacmContextName OBJECT-TYPE 744 SYNTAX SnmpAdminString (SIZE(0..32)) 745 MAX-ACCESS read-only 746 STATUS current 747 DESCRIPTION "A human readable name identifying a particular 748 context at a particular SNMP entity. 749 | 750 The empty contextName (zero length) represents the | 751 default context. | 752 " 753 ::= { vacmContextEntry 1 } 755 -- Information about Groups ****************************************** 757 vacmSecurityToGroupTable OBJECT-TYPE 758 SYNTAX SEQUENCE OF VacmSecurityToGroupEntry 759 MAX-ACCESS not-accessible 760 STATUS current 761 DESCRIPTION "This table maps a combination of securityModel and 762 securityName into a groupName which is used to define 763 an access control policy for a group of principals. 764 " 765 ::= { vacmMIBObjects 2 } 767 vacmSecurityToGroupEntry OBJECT-TYPE 768 SYNTAX VacmSecurityToGroupEntry 769 MAX-ACCESS not-accessible 770 STATUS current 771 DESCRIPTION "An entry in this table maps the combination of a 772 securityModel and securityName into a groupName. 773 " 774 INDEX { 775 vacmSecurityModel, 776 vacmSecurityName 777 } 778 ::= { vacmSecurityToGroupTable 1 } 780 Draft View-based Access Control Model (ACM) for SNMP September 1997 782 VacmSecurityToGroupEntry ::= SEQUENCE 783 { 784 vacmSecurityModel SnmpSecurityModel, 785 vacmSecurityName SnmpAdminString, 786 vacmGroupName SnmpAdminString, 787 vacmSecurityToGroupStorageType StorageType, 788 vacmSecurityToGroupStatus RowStatus 789 } 791 vacmSecurityModel OBJECT-TYPE 792 SYNTAX SnmpSecurityModel(1..2147483647) | 793 MAX-ACCESS not-accessible 794 STATUS current 795 DESCRIPTION "The Security Model, by which the vacmSecurityName 796 referenced by this entry is provided. 798 Note, this object may not take the 'any' (0) value. | 799 " 800 ::= { vacmSecurityToGroupEntry 1 } 802 vacmSecurityName OBJECT-TYPE 803 SYNTAX SnmpAdminString (SIZE(1..32)) 804 MAX-ACCESS not-accessible 805 STATUS current 806 DESCRIPTION "The securityName for the principal, represented in a 807 Security Model independent format, which is mapped by 808 this entry to a groupName. 810 The securityName for a principal represented in a 811 Security Model independent format. 812 " 813 ::= { vacmSecurityToGroupEntry 2 } 815 vacmGroupName OBJECT-TYPE 816 SYNTAX SnmpAdminString (SIZE(1..32)) 817 MAX-ACCESS read-create 818 STATUS current 819 DESCRIPTION "The name of the group to which this entry (e.g., the | 820 combination of securityModel and securityName) 821 belongs. 823 This groupName is used as index into the 824 vacmAccessTable to select an access control policy. 825 " 826 ::= { vacmSecurityToGroupEntry 3 } 828 vacmSecurityToGroupStorageType OBJECT-TYPE 829 SYNTAX StorageType 830 MAX-ACCESS read-create 831 STATUS current 832 DESCRIPTION "The storage type for this conceptual row. 834 Draft View-based Access Control Model (ACM) for SNMP September 1997 836 Conceptual rows having the value 'permanent' need not 837 allow write-access to any columnar objects in the row. 838 " 839 DEFVAL { nonVolatile } 840 ::= { vacmSecurityToGroupEntry 4 } 842 vacmSecurityToGroupStatus OBJECT-TYPE 843 SYNTAX RowStatus 844 MAX-ACCESS read-create 845 STATUS current 846 DESCRIPTION "The status of this conceptual row. 848 The RowStatus TC [RFC1903] requires that this 849 DESCRIPTION clause states under which circumstances 850 other objects in this row can be modified: 852 The value of this object has no effect on whether 853 other objects in this conceptual row can be modified. 854 " 855 ::= { vacmSecurityToGroupEntry 5 } 857 -- Information about Access Rights *********************************** 859 vacmAccessTable OBJECT-TYPE 860 SYNTAX SEQUENCE OF VacmAccessEntry 861 MAX-ACCESS not-accessible 862 STATUS current 863 DESCRIPTION "The table of access rights for groups. 865 Each entry is indexed by a contextPrefix, a groupName 866 a securityModel and a securityLevel. To determine 867 whether access is allowed, one entry from this table 868 needs to be selected and the proper viewName from that 869 entry must be used for access control checking. 871 To select the proper entry, follow these steps: | 872 | 873 1) the set of possible matches is formed by the | 874 intersection of the following sets of entries: | 875 the set of entries with identical vacmGroupName | 876 the union of these two sets: | 877 - the set with identical vacmAccessContextPrefix | 878 - the set of entries with vacmAccessContextMatch | 879 value of 'prefix' and matching | 880 vacmAccessContextPrefix | 881 intersected with the union of these two sets: | 882 - the set of entries with identical | 883 vacmSecurityModel | 884 - the set of entries with vacmSecurityModel | 885 value of 'any' | 887 Draft View-based Access Control Model (ACM) for SNMP September 1997 889 intersected with the set of entries with | 890 vacmAccessSecurityLevel value less than or equal 2 891 to the requested securityLevel 2 892 | 893 2) if this set has only one member, we're done | 894 otherwise, it comes down to deciding how to weight | 895 the preferences between ContextPrefixes, | 896 SecurityModels, and SecurityLevels as follows: | 897 a) if the subset of entries with identical | 898 securityModels is not empty, discard the rest. | 899 b) if the subset of entries with identical | 900 vacmAccessContextPrefix is not empty, | 901 discard the rest | 902 c) discard all entries with ContextPrefixes shorter | 903 than the longest one remaining in the set | 904 d) select the entry with the highest securityLevel | 905 | 906 Please note that for securityLevel noAuthNoPriv, all | 907 groups are really equivalent since the assumption that | 908 the securityName has been authenticated does not hold. | 909 " 910 ::= { vacmMIBObjects 4 } 912 vacmAccessEntry OBJECT-TYPE 913 SYNTAX VacmAccessEntry 914 MAX-ACCESS not-accessible 915 STATUS current 916 DESCRIPTION "An access right configured in the Local Configuration 917 Datastore (LCD) authorizing access to an SNMP context. 918 " 919 INDEX { vacmGroupName, 920 vacmAccessContextPrefix, 921 vacmAccessSecurityModel, | 922 vacmAccessSecurityLevel 923 } 924 ::= { vacmAccessTable 1 } 926 VacmAccessEntry ::= SEQUENCE 927 { 928 vacmAccessContextPrefix SnmpAdminString, 929 vacmAccessSecurityModel SnmpSecurityModel, | 930 vacmAccessSecurityLevel SnmpSecurityLevel, 931 vacmAccessContextMatch INTEGER, 932 vacmAccessReadViewName SnmpAdminString, 933 vacmAccessWriteViewName SnmpAdminString, 934 vacmAccessNotifyViewName SnmpAdminString, 935 vacmAccessStorageType StorageType, 936 vacmAccessStatus RowStatus 937 } 939 vacmAccessContextPrefix OBJECT-TYPE 940 Draft View-based Access Control Model (ACM) for SNMP September 1997 942 SYNTAX SnmpAdminString (SIZE(0..32)) 943 MAX-ACCESS not-accessible 944 STATUS current 945 DESCRIPTION "In order to gain the access rights allowed by this 946 conceptual row, a contextName must match exactly 947 (if the value of vacmAccessContextMatch is 'exact') 948 or partially (if the value of vacmAccessContextMatch 949 is 'prefix') to the value of the instance of this 950 object. 951 " 952 ::= { vacmAccessEntry 1 } 954 vacmAccessSecurityModel OBJECT-TYPE | 955 SYNTAX SnmpSecurityModel | 956 MAX-ACCESS not-accessible | 957 STATUS current | 958 DESCRIPTION "In order to gain the access rights allowed by this | 959 conceptual row, this securityModel must be in use. | 960 " | 961 ::= { vacmAccessEntry 2 } | 963 vacmAccessSecurityLevel OBJECT-TYPE 964 SYNTAX SnmpSecurityLevel 965 MAX-ACCESS not-accessible 966 STATUS current 967 DESCRIPTION "The minimum level of security required in order to 968 gain the access rights allowed by this conceptual 969 row. A securityLevel of noAuthNoPriv is less than 970 authNoPriv which in turn is less than authPriv. 972 If multiple entries are equally indexed except for 973 this vacmAccessSecurityLevel index, then the entry 974 which has the highest value for 975 vacmAccessSecurityLevel wins. 976 " 977 ::= { vacmAccessEntry 3 } | 979 vacmAccessContextMatch OBJECT-TYPE 980 SYNTAX INTEGER 981 { exact (1), -- exact match of prefix and contextName 982 prefix (2) -- Only match to the prefix 983 } 984 MAX-ACCESS read-create 985 STATUS current 986 DESCRIPTION "If the value of this object is exact(1), then all 987 rows where the contextName exactly matches 988 vacmAccessContextPrefix are selected. 990 If the value of this object is prefix(2), then all 991 rows where the contextName whose starting octets 992 exactly match vacmAccessContextPrefix are selected. 994 Draft View-based Access Control Model (ACM) for SNMP September 1997 996 This allows for a simple form of wildcarding. 997 See also the example in the DESCRIPTION clause of 998 the vacmAccessTable above. 999 " 1000 ::= { vacmAccessEntry 4 } | 1002 vacmAccessReadViewName OBJECT-TYPE 1003 SYNTAX SnmpAdminString (SIZE(0..32)) 1004 MAX-ACCESS read-create 1005 STATUS current 1006 DESCRIPTION "The value of an instance of this object identifies 1007 the MIB view of the SNMP context to which this 1008 conceptual row authorizes read access. 1010 The identified MIB view is that one for which the 1011 vacmViewTreeFamilyViewName has the same value as the 1012 instance of this object; if the value is the empty 1013 string or if there is no active MIB view having this 1014 value of vacmViewTreeFamilyViewName, then no access 1015 is granted. 1016 " 1017 DEFVAL { ''H } -- the empty string 1018 ::= { vacmAccessEntry 5 } | 1020 vacmAccessWriteViewName OBJECT-TYPE 1021 SYNTAX SnmpAdminString (SIZE(0..32)) 1022 MAX-ACCESS read-create 1023 STATUS current 1024 DESCRIPTION "The value of an instance of this object identifies 1025 the MIB view of the SNMP context to which this 1026 conceptual row authorizes write access. 1028 The identified MIB view is that one for which the 1029 vacmViewTreeFamilyViewName has the same value as the 1030 instance of this object; if the value is the empty 1031 string or if there is no active MIB view having this 1032 value of vacmViewTreeFamilyViewName, then no access 1033 is granted. 1034 " 1035 DEFVAL { ''H } -- the empty string 1036 ::= { vacmAccessEntry 6 } | 1038 vacmAccessNotifyViewName OBJECT-TYPE 1039 SYNTAX SnmpAdminString (SIZE(0..32)) 1040 MAX-ACCESS read-create 1041 STATUS current 1042 DESCRIPTION "The value of an instance of this object identifies 1043 the MIB view of the SNMP context to which this 1044 conceptual row authorizes access for notifications. 1046 The identified MIB view is that one for which the 1048 Draft View-based Access Control Model (ACM) for SNMP September 1997 1050 vacmViewTreeFamilyViewName has the same value as the 1051 instance of this object; if the value is the empty 1052 string or if there is no active MIB view having this 1053 value of vacmViewTreeFamilyViewName, then no access 1054 is granted. 1055 " 1056 DEFVAL { ''H } -- the empty string 1057 ::= { vacmAccessEntry 7 } | 1059 vacmAccessStorageType OBJECT-TYPE 1060 SYNTAX StorageType 1061 MAX-ACCESS read-create 1062 STATUS current 1063 DESCRIPTION "The storage type for this conceptual row. 1065 Conceptual rows having the value 'permanent' need not 1066 allow write-access to any columnar objects in the row. 1067 " 1068 DEFVAL { nonVolatile } 1069 ::= { vacmAccessEntry 8 } | 1071 vacmAccessStatus OBJECT-TYPE 1072 SYNTAX RowStatus 1073 MAX-ACCESS read-create 1074 STATUS current 1075 DESCRIPTION "The status of this conceptual row. 1077 The RowStatus TC [RFC1903] requires that this 1078 DESCRIPTION clause states under which circumstances 1079 other objects in this row can be modified: 1081 The value of this object has no effect on whether 1082 other objects in this conceptual row can be modified. 1083 " 1084 ::= { vacmAccessEntry 9 } | 1086 -- Information about MIB views *************************************** 1088 -- Support for instance-level granularity is optional. | 1089 -- | 1090 -- In some implementations, instance-level access control | 1091 -- granularity may come at a high performance cost. Managers | 1092 -- should avoid requesting such configurations unnecessarily. | 1094 vacmMIBViews OBJECT IDENTIFIER ::= { vacmMIBObjects 5 } 1096 vacmViewSpinLock OBJECT-TYPE 1097 SYNTAX TestAndIncr 1098 MAX-ACCESS read-write 1099 STATUS current 1100 DESCRIPTION "An advisory lock used to allow cooperating SNMP 1102 Draft View-based Access Control Model (ACM) for SNMP September 1997 1104 Command Generator applications to coordinate their 1105 use of the Set operation in creating or modifying | 1106 views. | 1108 When creating a new view or altering an existing 1109 view, it is important to understand the potential 1110 interactions with other uses of the view. The 1111 vacmViewSpinLock should be retrieved. The name of 1112 the view to be created should be determined to be 1113 unique by the SNMP Command Generator application by 1114 consulting the vacmViewTreeFamilyTable. Finally, 1115 the named view may be created (Set), including the 1116 advisory lock. 1117 If another SNMP Command Generator application has 1118 altered the views in the meantime, then the spin 1119 lock's value will have changed, and so this creation 1120 will fail because it will specify the wrong value for 1121 the spin lock. 1123 Since this is an advisory lock, the use of this lock 1124 is not enforced. 1125 " 1126 ::= { vacmMIBViews 1 } 1128 vacmViewTreeFamilyTable OBJECT-TYPE 1129 SYNTAX SEQUENCE OF VacmViewTreeFamilyEntry 1130 MAX-ACCESS not-accessible 1131 STATUS current 1132 DESCRIPTION "Locally held information about families of subtrees 1133 within MIB views. 1135 Each MIB view is defined by two sets of view subtrees: 1136 - the included view subtrees, and 1137 - the excluded view subtrees. 1138 Every such view subtree, both the included and the 1139 excluded ones, is defined in this table. 1141 To determine if a particular object instance is in 1142 a particular MIB view, compare the object instance's 1143 OBJECT IDENTIFIER with each of the MIB view's active 1144 entries in this table. If none match, then the 1145 object instance is not in the MIB view. If one or 1146 more match, then the object instance is included in, 1147 or excluded from, the MIB view according to the 1148 value of vacmViewTreeFamilyType in the entry whose 1149 value of vacmViewTreeFamilySubtree has the most 1150 sub-identifiers. If multiple entries match and have 1151 the same number of sub-identifiers, then the 1152 lexicographically greatest instance of 1153 vacmViewTreeFamilyType determines the inclusion or 1154 exclusion. 1156 Draft View-based Access Control Model (ACM) for SNMP September 1997 1158 An object instance's OBJECT IDENTIFIER X matches an 1159 active entry in this table when the number of 1160 sub-identifiers in X is at least as many as in the 1161 value of vacmViewTreeFamilySubtree for the entry, 1162 and each sub-identifier in the value of 1163 vacmViewTreeFamilySubtree matches its corresponding 1164 sub-identifier in X. Two sub-identifiers match 1165 either if the corresponding bit of the value of 1166 vacmViewTreeFamilyMask for the entry is zero (the 1167 'wild card' value), or if they are equal. 1169 A 'family' of subtrees is the set of subtrees defined 1170 by a particular combination of values of 1171 vacmViewTreeFamilySubtree and vacmViewTreeFamilyMask. 1172 In the case where no 'wild card' is defined in the 1173 vacmViewTreeFamilyMask, the family of subtrees reduces 1174 to a single subtree. 1176 When creating or changing MIB views, an SNMP Command 1177 Generator application should utilize the 1178 vacmViewSpinLock to try to avoid collisions. See 1179 DESCRIPTION clause of vacmViewSpinLock. 1181 When creating MIB views, it is strongly advised that 1182 first the 'excluded' vacmViewTreeFamilyEntries are 1183 created and then the 'included' entries. 1185 When deleting MIB views, it is strongly advised that 1186 first the 'included' vacmViewTreeFamilyEntries are 1187 deleted and then the 'excluded' entries. 1188 | 1189 If a create for an entry for instance-level access | 1190 control is received and the implementation does not | 1191 support instance-level granularity, then an | 1192 inconsistentName error must be returned. | 1193 " 1194 ::= { vacmMIBViews 2 } 1196 vacmViewTreeFamilyEntry OBJECT-TYPE 1197 SYNTAX VacmViewTreeFamilyEntry 1198 MAX-ACCESS not-accessible 1199 STATUS current 1200 DESCRIPTION "Information on a particular family of view subtrees 1201 included in or excluded from a particular SNMP 1202 context's MIB view. 1204 Implementations must not restrict the number of 1205 families of view subtrees for a given MIB view, 1206 except as dictated by resource constraints on the 1207 overall number of entries in the 1209 Draft View-based Access Control Model (ACM) for SNMP September 1997 1211 vacmViewTreeFamilyTable. 1213 If no conceptual rows exist in this table for a given | 1214 MIB view (viewName), that view may be thought of as | 1215 consisting of the empty set of view subtrees. | 1216 " 1217 INDEX { vacmViewTreeFamilyViewName, 1218 vacmViewTreeFamilySubtree 1219 } 1220 ::= { vacmViewTreeFamilyTable 1 } 1222 VacmViewTreeFamilyEntry ::= SEQUENCE 1223 { 1224 vacmViewTreeFamilyViewName SnmpAdminString, 1225 vacmViewTreeFamilySubtree OBJECT IDENTIFIER, 1226 vacmViewTreeFamilyMask OCTET STRING, 1227 vacmViewTreeFamilyType INTEGER, 1228 vacmViewTreeFamilyStorageType StorageType, 1229 vacmViewTreeFamilyStatus RowStatus 1230 } 1232 vacmViewTreeFamilyViewName OBJECT-TYPE 1233 SYNTAX SnmpAdminString (SIZE(1..32)) 1234 MAX-ACCESS not-accessible 1235 STATUS current 1236 DESCRIPTION "The human readable name for a family of view subtrees. 1237 " 1238 ::= { vacmViewTreeFamilyEntry 1 } 1240 vacmViewTreeFamilySubtree OBJECT-TYPE 1241 SYNTAX OBJECT IDENTIFIER 1242 MAX-ACCESS not-accessible 1243 STATUS current 1244 DESCRIPTION "The MIB subtree which when combined with the 1245 corresponding instance of vacmViewTreeFamilyMask 1246 defines a family of view subtrees. 1247 " 1248 ::= { vacmViewTreeFamilyEntry 2 } 1250 vacmViewTreeFamilyMask OBJECT-TYPE 1251 SYNTAX OCTET STRING (SIZE (0..16)) 1252 MAX-ACCESS read-create 1253 STATUS current 1254 DESCRIPTION "The bit mask which, in combination with the 1255 corresponding instance of vacmViewTreeFamilySubtree, 1256 defines a family of view subtrees. 1258 Each bit of this bit mask corresponds to a 1259 sub-identifier of vacmViewTreeFamilySubtree, with the 1260 most significant bit of the i-th octet of this octet 1261 string value (extended if necessary, see below) 1263 Draft View-based Access Control Model (ACM) for SNMP September 1997 1265 corresponding to the (8*i - 7)-th sub-identifier, and 1266 the least significant bit of the i-th octet of this 1267 octet string corresponding to the (8*i)-th 1268 sub-identifier, where i is in the range 1 through 16. 1270 Each bit of this bit mask specifies whether or not 1271 the corresponding sub-identifiers must match when 1272 determining if an OBJECT IDENTIFIER is in this 1273 family of view subtrees; a '1' indicates that an 1274 exact match must occur; a '0' indicates 'wild card', 1275 i.e., any sub-identifier value matches. 1277 Thus, the OBJECT IDENTIFIER X of an object instance 1278 is contained in a family of view subtrees if, for 1279 each sub-identifier of the value of 1280 vacmViewTreeFamilySubtree, either: 1282 the i-th bit of vacmViewTreeFamilyMask is 0, or 1284 the i-th sub-identifier of X is equal to the i-th 1285 sub-identifier of the value of 1286 vacmViewTreeFamilySubtree. 1288 If the value of this bit mask is M bits long and 1289 there are more than M sub-identifiers in the 1290 corresponding instance of vacmViewTreeFamilySubtree, 1291 then the bit mask is extended with 1's to be the 1292 required length. 1294 Note that when the value of this object is the 1295 zero-length string, this extension rule results in 1296 a mask of all-1's being used (i.e., no 'wild card'), 1297 and the family of view subtrees is the one view 1298 subtree uniquely identified by the corresponding 1299 instance of vacmViewTreeFamilySubtree. 1301 Note that masks of length greater than zero length 1302 do not need to be supported. In this case this | 1303 object is made read-only. | 1304 " 1305 DEFVAL { ''H } 1306 ::= { vacmViewTreeFamilyEntry 3 } 1308 vacmViewTreeFamilyType OBJECT-TYPE 1309 SYNTAX INTEGER { included(1), excluded(2) } 1310 MAX-ACCESS read-create 1311 STATUS current 1312 DESCRIPTION "Indicates whether the corresponding instances of 1313 vacmViewTreeFamilySubtree and vacmViewTreeFamilyMask 1314 define a family of view subtrees which is included in 1315 or excluded from the MIB view. 1317 Draft View-based Access Control Model (ACM) for SNMP September 1997 1319 " 1320 DEFVAL { included } 1321 ::= { vacmViewTreeFamilyEntry 4 } 1323 vacmViewTreeFamilyStorageType OBJECT-TYPE 1324 SYNTAX StorageType 1325 MAX-ACCESS read-create 1326 STATUS current 1327 DESCRIPTION "The storage type for this conceptual row. 1329 Conceptual rows having the value 'permanent' need not 1330 allow write-access to any columnar objects in the row. 1331 " 1332 DEFVAL { nonVolatile } 1333 ::= { vacmViewTreeFamilyEntry 5 } 1335 vacmViewTreeFamilyStatus OBJECT-TYPE 1336 SYNTAX RowStatus 1337 MAX-ACCESS read-create 1338 STATUS current 1339 DESCRIPTION "The status of this conceptual row. 1341 The RowStatus TC [RFC1903] requires that this 1342 DESCRIPTION clause states under which circumstances 1343 other objects in this row can be modified: 1345 The value of this object has no effect on whether 1346 other objects in this conceptual row can be modified. 1347 " 1348 ::= { vacmViewTreeFamilyEntry 6 } 1350 -- Conformance information ******************************************* 1352 vacmMIBCompliances OBJECT IDENTIFIER ::= { vacmMIBConformance 1 } 1353 vacmMIBGroups OBJECT IDENTIFIER ::= { vacmMIBConformance 2 } 1355 -- Compliance statements ********************************************* 1357 vacmMIBCompliance MODULE-COMPLIANCE 1358 STATUS current 1359 DESCRIPTION "The compliance statement for SNMP engines which 1360 implement the SNMP View-based Access Control Model 1361 configuration MIB. 1362 " 1363 MODULE -- this module 1364 MANDATORY-GROUPS { vacmBasicGroup } 1366 OBJECT vacmAccessContextMatch 1367 MIN-ACCESS read-only 1368 DESCRIPTION "Write access is not required." 1370 Draft View-based Access Control Model (ACM) for SNMP September 1997 1372 OBJECT vacmAccessReadViewName 1373 MIN-ACCESS read-only 1374 DESCRIPTION "Write access is not required." 1376 OBJECT vacmAccessWriteViewName 1377 MIN-ACCESS read-only 1378 DESCRIPTION "Write access is not required." 1380 OBJECT vacmAccessNotifyViewName 1381 MIN-ACCESS read-only 1382 DESCRIPTION "Write access is not required." 1384 OBJECT vacmAccessStorageType 1385 MIN-ACCESS read-only 1386 DESCRIPTION "Write access is not required." 1388 OBJECT vacmAccessStatus 1389 MIN-ACCESS read-only 1390 DESCRIPTION "Create/delete/modify access to the | 1391 vacmAccessTable is not required. | 1392 " 1394 OBJECT vacmViewTreeFamilyMask 1395 WRITE-SYNTAX OCTET STRING (SIZE (0)) 1396 MIN-ACCESS read-only 1397 DESCRIPTION "Support for configuration via SNMP of subtree 1398 families using wild-cards is not required. 1399 " 1401 OBJECT vacmViewTreeFamilyType 1402 MIN-ACCESS read-only 1403 DESCRIPTION "Write access is not required." 1405 OBJECT vacmViewTreeFamilyStorageType 1406 MIN-ACCESS read-only 1407 DESCRIPTION "Write access is not required." 1409 OBJECT vacmViewTreeFamilyStatus 1410 MIN-ACCESS read-only 1411 DESCRIPTION "Create/delete/modify access to the | 1412 vacmViewTreeFamilyTable is not required. | 1413 " 1414 ::= { vacmMIBCompliances 1 } 1416 -- Units of conformance ********************************************** 1418 vacmBasicGroup OBJECT-GROUP 1419 OBJECTS { 1420 vacmContextName, 1421 vacmGroupName, 1422 vacmSecurityToGroupStorageType, 1424 Draft View-based Access Control Model (ACM) for SNMP September 1997 1426 vacmSecurityToGroupStatus, 1427 vacmAccessContextMatch, 1428 vacmAccessReadViewName, 1429 vacmAccessWriteViewName, 1430 vacmAccessNotifyViewName, 1431 vacmAccessStorageType, 1432 vacmAccessStatus, 1433 vacmViewSpinLock, 1434 vacmViewTreeFamilyMask, 1435 vacmViewTreeFamilyType, 1436 vacmViewTreeFamilyStorageType, 1437 vacmViewTreeFamilyStatus 1438 } 1439 STATUS current 1440 DESCRIPTION "A collection of objects providing for remote 1441 configuration of an SNMP engine which implements 1442 the SNMP View-based Access Control Model. 1443 " 1444 ::= { vacmMIBGroups 1 } 1446 END 1447 Draft View-based Access Control Model (ACM) for SNMP September 1997 1449 5. Security Considerations 1451 5.1. Recommended Practices 1453 This document is meant for use in the SNMP architecture. The 1454 View-based Access Control Model described in this document checks 1455 access rights to management information based on: 1457 - contextName, representing a set of management information at the 1458 managed system where the Access Control module is running. 1459 - groupName, representing a set of zero or more securityNames. 1460 The combination of a securityModel and a securityName is mapped 1461 into a group in the View-based Access Control Model. 1462 - securityModel under which access is requested. 1463 - securityLevel under which access is requested. 1464 - operation performed on the management information. 1465 - MIB views for read, write or notify access. 1467 When the User-based Access Control module is called for checking 1468 access rights, it is assumed that the calling module has ensured 1469 the authentication and privacy aspects as specified by the 1470 securityLevel that is being passed. 1472 When creating entries in or deleting entries from the | 1473 vacmViewFamiliyTreeTable it is important to do such in the sequence 2 1474 as recommended in the DESCRIPTION clause of the vacmViewFamilityTable 2 1475 definition. Otherwise unwanted access may be granted while changing | 1476 the entries in the table. | 1478 5.2. Defining Groups 1480 The groupNames are used to give access to a group of zero or more 1481 securityNames. Within the View-Based Access Control Model, a 1482 groupName is considered to exist if that groupName is listed in the 1483 vacmSecurityToGroupTable. 1485 By mapping the combination of a securityModel and securityName into 1486 a groupName, an SNMP Command Generator application can add/delete 1487 securityNames to/from a group, if proper access is allowed. 1488 | 1489 Further it is important to realize that the grouping of | 1490 tuples in the vacmSecurityToGroupTable 2 1491 does not take securityLevel into account. It is therefore important | 1492 that the security administrator uses the securityLevel index in the | 1493 vacmAccessTable to separate noAuthNoPriv from authPriv and/or 2 1494 authNoPriv access. 1496 5.3. Conformance 1498 For an implementation of the View-based Access Control Model to be 1500 Draft View-based Access Control Model (ACM) for SNMP September 1997 1502 conformant, it MUST implement the SNMP-VIEW-BASED-ACM-MIB. It also 1503 SHOULD implement the initial configuration, described in appendix A. | 1505 Draft View-based Access Control Model (ACM) for SNMP September 1997 1507 6. Editors' Addresses 1509 Co-editor: Bert Wijnen 1510 IBM T. J. Watson Research 1511 postal: Schagen 33 1512 3461 GL Linschoten 1513 Netherlands 1514 email: wijnen@vnet.ibm.com 1515 phone: +31-348-432-794 1517 Co-editor: Randy Presuhn 1518 BMC Software, Inc 1519 postal: 1190 Saratoga Avenue, Suite 130 1520 San Jose, CA 95129-3433 1521 USA 1522 email: rpresuhn@bmc.com 1523 phone: +1-408-556-0720 1525 Co-editor: Keith McCloghrie 1526 Cisco Systems, Inc. 1527 postal: 170 West Tasman Drive 1528 San Jose, CA 95134-1706 1529 USA 1530 email: kzm@cisco.com 1531 phone: +1-408-526-5260 1533 7. Acknowledgements 1535 This document is the result of the efforts of the SNMPv3 Working Group. 1536 Some special thanks are in order to the following SNMPv3 WG members: 1538 Dave Battle (SNMP Research, Inc.) 1539 Uri Blumenthal (IBM T.J. Watson Research Center) 1540 Jeff Case (SNMP Research, Inc.) 1541 John Curran (BBN) 1542 T. Max Devlin (Hi-TECH Connections) 1543 John Flick (Hewlett Packard) 1544 David Harrington (Cabletron Systems Inc.) 1545 N.C. Hien (IBM T.J. Watson Research Center) 1546 Dave Levi (SNMP Research, Inc.) 1547 Louis A Mamakos (UUNET Technologies Inc.) 1548 Paul Meyer (Secure Computing Corporation) 1549 Keith McCloghrie (Cisco Systems) 1550 Russ Mundy (Trusted Information Systems, Inc.) 1551 Bob Natale (ACE*COMM Corporation) 1552 Mike O'Dell (UUNET Technologies Inc.) 1553 Dave Perkins (DeskTalk) 1554 Peter Polkinghorne (Brunel University) 1555 Randy Presuhn (BMC Software, Inc.) 1556 David Reid (SNMP Research, Inc.) 1558 Draft View-based Access Control Model (ACM) for SNMP September 1997 1560 Shawn Routhier (Epilogue) 1561 Juergen Schoenwaelder (TU Braunschweig) 1562 Bob Stewart (Cisco Systems) 1563 Bert Wijnen (IBM T.J. Watson Research Center) 1565 The document is based on recommendations of the IETF Security and 1566 Administrative Framework Evolution for SNMP Advisory Team. 1567 Members of that Advisory Team were: 1569 David Harrington (Cabletron Systems Inc.) 1570 Jeff Johnson (Cisco Systems) 1571 David Levi (SNMP Research Inc.) 1572 John Linn (Openvision) 1573 Russ Mundy (Trusted Information Systems) chair 1574 Shawn Routhier (Epilogue) 1575 Glenn Waters (Nortel) 1576 Bert Wijnen (IBM T. J. Watson Research Center) 1578 As recommended by the Advisory Team and the SNMPv3 Working Group 1579 Charter, the design incorporates as much as practical from previous 1580 RFCs and drafts. As a result, special thanks are due to the authors 1581 of previous designs known as SNMPv2u and SNMPv2*: 1583 Jeff Case (SNMP Research, Inc.) 1584 David Harrington (Cabletron Systems Inc.) 1585 David Levi (SNMP Research, Inc.) 1586 Keith McCloghrie (Cisco Systems) 1587 Brian O'Keefe (Hewlett Packard) 1588 Marshall T. Rose (Dover Beach Consulting) 1589 Jon Saperia (BGS Systems Inc.) 1590 Steve Waldbusser (International Network Services) 1591 Glenn W. Waters (Bell-Northern Research Ltd.) 1593 Draft View-based Access Control Model (ACM) for SNMP September 1997 1595 8. References 1597 [RFC1902] The SNMPv2 Working Group, Case, J., McCloghrie, K., 1598 Rose, M., and S., Waldbusser, "Structure of Management 1599 Information for Version 2 of the Simple Network Management 1600 Protocol (SNMPv2)", RFC 1902, January 1996. 1602 [RFC1903] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., | 1603 and S. Waldbusser, "Textual Conventions for Version 2 of the Simple | 1604 Network Management Protocol (SNMPv2)", RFC 1903, January 1996. | 1605 | 1606 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2 1607 Requirement Levels", RFC 2119, BCP 14, March 1997. 2 1609 [SNMP-ARCH] The SNMPv3 Working Group, Harrington, D., Wijnen, B., 2 1610 Presuhn, R., "An Architecture for describing SNMP Management 2 1611 Frameworks", draft-ietf-snmpv3-next-gen-arch-05.txt, 2 1612 September 1997. 2 1614 [SNMP-MPD] The SNMPv3 Working Group, Case, J., Harrington, D., 2 1615 Wijnen, B., Presuhn, R., "Message Processing and Dispatching for 2 1616 the Simple Network Management Protocol (SNMP)", 2 1617 draft-ietf-snmpv3-v3mpc-model-03.txt, September 1997. 2 1619 [ISO-ASN.1] Information processing systems - Open Systems 1620 Interconnection - Specification of Abstract Syntax Notation One 1621 (ASN.1), International Organization for Standardization. 1622 International Standard 8824, (December, 1987). 1624 Draft View-based Access Control Model (ACM) for SNMP September 1997 1626 APPENDIX A - Installation 1628 A.1. Installation Parameters 1630 During installation, an authoritative SNMP engine which supports this | 1631 View-based Access Control Model SHOULD be configured with several | 1632 initial parameters. | 1633 These include for the View-based Access Control Model: 1635 1) A security configuration 1637 The choice of security configuration determines if initial 1638 configuration is implemented and if so how. 1639 One of three possible choices is selected: 1641 - initial-minimum-security-configuration 1642 - initial-semi-security-configuration 1643 - initial-no-access-configuration 1645 In the case of a initial-no-access-configuration, there is no 1646 initial configuration, and so the following steps are irrelevant. 1648 2) A default context 1650 One entry in the vacmContextTable with a contextName of "" (the 1651 empty string), representing the default context. Note that this 1652 table gets created automatically if a default context exists. 1654 no privacy support privacy support 1655 ------------------ --------------- 1656 vacmContextName "" "" 1658 3) An initial group 1660 One entry in the vacmSecurityToGroupTable to allow access to group 1661 "initial". 1663 no privacy support privacy support 1664 ------------------ --------------- 1665 vacmSecurityModel 3 (USM) 3 (USM) 1666 vacmSecurityName "initial" "initial" 1667 vacmGroupName "initial" "initial" 1668 vacmSecurityToGroupStorageType anyValidStorageType anyValidStorageType 1669 vacmSecurityToGroupStatus active active 1671 4) Initial access rights 1673 Three entries in the vacmAccessTable as follows: 1675 - read-notify access for securityModel USM, securityLevel 1676 "noAuthNoPriv" on behalf of securityNames that belong to the 1678 Draft View-based Access Control Model (ACM) for SNMP September 1997 1680 group "initial" to the MIB view in the default 1681 context with contextName "". 1683 - read-write-notify access for securityModel USM, securityLevel 1684 "authNoPriv" on behalf of securityNames that belong to the 1685 group "initial" to the MIB view in the default context 1686 with contextName "". 1688 - if privacy is supported, 1689 read-write-notify access for securityModel USM, securityLevel 1690 "authPriv" on behalf of securityNames that belong to the group 1691 "initial" to the MIB view in the default context with 1692 contextName "". 1694 That translates into the following entries in the vacmAccessTable. 1695 Those columns marked with (index) are index-only objects and are 1696 not really present in this table. 1698 - One entry to be used for unauthenticated access (noAuthNoPriv): 1700 no privacy support privacy support 1701 ------------------ --------------- 1702 vacmAccessContextPrefix "" "" 1703 vacmGroupName (index) "initial" "initial" 1704 vacmSecurityModel (index) 3 (USM) 3 (USM) 1705 vacmAccessSecurityLevel noAuthNoPriv noAuthNoPriv 1706 vacmAccessReadViewName "restricted" "restricted" 1707 vacmAccessWriteViewName "" "" 1708 vacmAccessNotifyViewName "restricted" "restricted" 1709 vacmAccessStorageType anyValidStorageType anyValidStorageType 1710 vacmAccessStatus active active 1712 - One entry to be used for authenticated access but without 1713 privacy (authNoPriv): 1714 no privacy support privacy support 1715 ------------------ --------------- 1716 vacmAccessContextPrefix "" "" 1717 vacmGroupName (index) "initial" "initial" 1718 vacmSecurityModel (index) 3 (USM) 3 (USM) 1719 vacmAccessSecurityLevel authNoPriv authNoPriv 1720 vacmAccessReadViewName "internet" "internet" 1721 vacmAccessWriteViewName "internet" "internet" 1722 vacmAccessNotifyViewName "internet" "internet" 1723 vacmAccessStorageType anyValidStorageType anyValidStorageType 1724 vacmAccessStatus active active 1726 - One entry to be used for authenticated access with privacy 1727 (authPriv): 1729 no privacy support privacy support 1730 ------------------ --------------- 1732 Draft View-based Access Control Model (ACM) for SNMP September 1997 1734 vacmAccessContextPrefix "" 1735 vacmGroupName (index) "initial" 1736 vacmSecurityModel (index) 3 (USM) 1737 vacmAccessSecurityLevel authPriv 1738 vacmAccessReadViewName "internet" 1739 vacmAccessWriteViewName "internet" 1740 vacmAccessNotifyViewName "internet" 1741 vacmAccessStorageType anyValidStorageType 1742 vacmAccessStatus active 1744 5) Two MIB views, of which the second one depends on the security 1745 configuration. 1747 - One view, the view, for authenticated access: 1749 - the MIB view is the following subtree: 1750 "internet" (subtree 1.3.6.1) 1752 - A second view, the view, for unauthenticated 1753 access. This view is configured according to the selected 1754 security configuration: 1756 - For the initial-no-access-configuration there is no default 1757 initial configuration, so no MIB views are pre-scribed. 1759 - For the initial-semi-secure-configuration: 1761 the MIB view is the union of these subtrees: 1762 (a) "system" (subtree 1.3.6.1.2.1.1) [RFC1907] 1763 (b) "snmp" (subtree 1.3.6.1.2.1.11) [RFC1907] 1764 (c) "snmpEngine" (subtree 1.3.6.1.6.3.7.2.1) [SNMP-ARCH] 1765 (d) "snmpMPDStats" (subtree 1.3.6.1.6.3.8.2.1) [SNMP-MPD] 1766 (e) "usmStats" (subtree 1.3.6.1.6.3.9.2.1) [SNMP-USM] 1768 - For the initial-minimum-secure-configuration: 1770 the MIB view is the following subtree. 1771 "internet" (subtree 1.3.6.1) 1773 This translates into the following "internet" entry in the 1774 vacmViewTreeFamilyTable: 1776 minimum-secure semi-secure 1777 ---------------- --------------- 1778 vacmViewTreeFamilyViewName "internet" "internet" 1779 vacmViewTreeFamilySubtree 1.3.6.1 1.3.6.1 1780 vacmViewTreeFamilyMask "" "" 1781 vacmViewTreeFamilyType 1 (included) 1 (included) 1782 vacmViewTreeFamilyStorageType anyValidStorageType anyValidStorageType 1783 vacmViewTreeFamilyStatus active active 1785 Draft View-based Access Control Model (ACM) for SNMP September 1997 1787 In addition it translates into the following "restricted" entries 1788 in the vacmViewTreeFamilyTable: 1790 minimum-secure semi-secure 1791 ---------------- --------------- 1792 vacmViewTreeFamilyViewName "restricted" "restricted" 1793 vacmViewTreeFamilySubtree 1.3.6.1 1.3.6.1.2.1.1 1794 vacmViewTreeFamilyMask "" "" 1795 vacmViewTreeFamilyType 1 (included) 1 (included) 1796 vacmViewTreeFamilyStorageType anyValidStorageType anyValidStorageType 1797 vacmViewTreeFamilyStatus active active 1799 vacmViewTreeFamilyViewName "restricted" 1800 vacmViewTreeFamilySubtree 1.3.6.1.2.1.11 1801 vacmViewTreeFamilyMask "" 1802 vacmViewTreeFamilyType 1 (included) 1803 vacmViewTreeFamilyStorageType anyValidStorageType 1804 vacmViewTreeFamilyStatus active 1806 vacmViewTreeFamilyViewName "restricted" 1807 vacmViewTreeFamilySubtree 1.3.6.1.6.3.7.2.1 1808 vacmViewTreeFamilyMask "" 1809 vacmViewTreeFamilyType 1 (included) 1810 vacmViewTreeFamilyStorageType anyValidStorageType 1811 vacmViewTreeFamilyStatus active 1813 vacmViewTreeFamilyViewName "restricted" 1814 vacmViewTreeFamilySubtree 1.3.6.1.6.3.8.2.1 1815 vacmViewTreeFamilyMask "" 1816 vacmViewTreeFamilyType 1 (included) 1817 vacmViewTreeFamilyStorageType anyValidStorageType 1818 vacmViewTreeFamilyStatus active 1820 vacmViewTreeFamilyViewName "restricted" 1821 vacmViewTreeFamilySubtree 1.3.6.1.6.3.9.2.1 1822 vacmViewTreeFamilyMask "" 1823 vacmViewTreeFamilyType 1 (included) 1824 vacmViewTreeFamilyStorageType anyValidStorageType 1825 vacmViewTreeFamilyStatus active 1827 Draft View-based Access Control Model (ACM) for SNMP September 1997 1829 Table of Contents 1831 0. Issues and Change Log 2 1832 0.1. Resolved issues 2 1833 0.2. Change Log 2 1834 1. Introduction 5 1835 1.2. Access Control 5 1836 1.3. Local Configuration Datastore 6 1837 2. Elements of the Model 7 1838 2.1. Groups 7 1839 2.2. securityLevel 7 1840 2.3. Contexts 7 1841 2.4. MIB Views and View Families 8 1842 2.4.1. View Subtree 8 1843 2.4.2. ViewTreeFamily 8 1844 2.5. Access Policy 9 1845 3. Elements of Procedure 10 1846 3.1. Overview of isAccessAllowed Process 11 1847 3.2. Processing the isAccessAllowed Service Request 12 1848 4. Definitions 14 1849 5. Security Considerations 30 1850 5.1. Recommended Practices 30 1851 5.2. Defining Groups 30 1852 5.3. Conformance 30 1853 6. Editors' Addresses 32 1854 7. Acknowledgements 32 1855 8. References 34 1856 A.1. Installation Parameters 35