idnits 2.17.1 draft-ietf-snmpv3-vacm-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- 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 36 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 37 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 ([RFC-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: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 58 has weird spacing: '...verview of is...' == Line 327 has weird spacing: '...verview of is...' == Line 1522 has weird spacing: '...ageType anyV...' -- 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 (20 January 1999) is 9200 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) == Missing Reference: 'RFC1907' is mentioned on line 1593, but not defined ** Obsolete undefined reference: RFC 1907 (Obsoleted by RFC 3418) == Unused Reference: 'RFC1902' is defined on line 1424, 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 (-05) exists of draft-ietf-snmpv3-arch-03 == Outdated reference: A later version (-05) exists of draft-ietf-snmpv3-mpc-03 == Outdated reference: A later version (-05) exists of draft-ietf-snmpv3-usm-v2-04 Summary: 12 errors (**), 0 flaws (~~), 13 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SNMPv3 Working Group B. Wijnen 3 Internet-Draft IBM T. J. Watson Research 4 Will Obsolete: RFC2275 R. Presuhn 5 BMC Software, Inc. 6 K. McCloghrie 7 Cisco Systems, Inc. 8 20 January 1999 10 View-based Access Control Model (VACM) for the 11 Simple Network Management Protocol (SNMP) 13 15 Status of this Memo 17 This document is an Internet-Draft. Internet-Drafts are working 18 documents of the Internet Engineering Task Force (IETF), its areas, 19 and its working groups. Note that other groups may also distribute 20 working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet- Drafts as reference 25 material or to cite them other than as ``work in progress.'' 27 To learn the current status of any Internet-Draft, please check the 28 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 29 Directories on ftp.ietf.org (US East Coast), nic.nordu.net (Europe), 30 ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 32 Copyright Notice 34 Copyright (C) The Internet Society (1999). All Rights Reserved. 36 Abstract 38 This document describes the View-based Access Control Model for use 39 in the SNMP architecture [RFC-ARCH]. It defines the Elements of 40 Procedure for controlling access to management information. This 41 document also includes a MIB for remotely managing the configuration 42 parameters for the View-based Access Control Model. 44 Table of Contents 46 1. Introduction 2 47 1.2. Access Control 3 48 1.3. Local Configuration Datastore 3 49 2. Elements of the Model 4 50 2.1. Groups 4 51 2.2. securityLevel 4 52 2.3. Contexts 4 53 2.4. MIB Views and View Families 4 54 2.4.1. View Subtree 5 55 2.4.2. ViewTreeFamily 5 56 2.5. Access Policy 6 57 3. Elements of Procedure 7 58 3.1. Overview of isAccessAllowed Process 8 59 3.2. Processing the isAccessAllowed Service Request 9 60 4. Definitions 10 61 5. Intellectual Property 27 62 6. Acknowledgements 28 63 7. Security Considerations 29 64 7.1. Recommended Practices 29 65 7.2. Defining Groups 30 66 7.3. Conformance 30 67 7.4. Access to the SNMP-VIEW-BASED-ACM-MIB 30 68 8. References 31 69 9. Editors' Addresses 32 70 A.1. Installation Parameters 33 71 B. Change Log 37 72 C. Full Copyright Statement 37 74 1. Introduction 76 The Architecture for describing Internet Management Frameworks [RFC- 77 ARCH] describes that an SNMP engine is composed of: 79 1) a Dispatcher 80 2) a Message Processing Subsystem, 81 3) a Security Subsystem, and 82 4) an Access Control Subsystem. 84 Applications make use of the services of these subsystems. 86 It is important to understand the SNMP architecture and its 87 terminology to understand where the View-based Access Control Model 88 described in this document fits into the architecture and interacts 89 with other subsystems within the architecture. The reader is 90 expected to have read and understood the description and terminology 91 of the SNMP architecture, as defined in [RFC-ARCH]. 93 The Access Control Subsystem of an SNMP engine has the responsibility 94 for checking whether a specific type of access (read, write, notify) 95 to a particular object (instance) is allowed. 97 It is the purpose of this document to define a specific model of the 98 Access Control Subsystem, designated the View-based Access Control 99 Model. Note that this is not necessarily the only Access Control 100 Model. 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 104 document are to be interpreted as described in [RFC2119]. 106 1.2. Access Control 108 Access Control occurs (either implicitly or explicitly) in an SNMP 109 entity when processing SNMP retrieval or modification request 110 messages from an SNMP entity. For example a Command Responder 111 application applies Access Control when processing requests that it 112 received from a Command Generator application. These requests 113 contain Read Class and Write Class PDUs as defined in [RFC-ARCH]. 115 Access Control also occurs in an SNMP entity when an SNMP 116 notification message is generated (by a Notification Originator 117 application). These notification messages contain Notification Class 118 PDUs as defined in [RFC-ARCH]. 120 The View-based Access Control Model defines a set of services that an 121 application (such as a Command Responder or a Notification Originator 122 application) can use for checking access rights. It is the 123 responsibility of the application to make the proper service calls 124 for access checking. 126 1.3. Local Configuration Datastore 128 To implement the model described in this document, an SNMP entity 129 needs to retain information about access rights and policies. This 130 information is part of the SNMP engine's Local Configuration 131 Datastore (LCD). See [RFC-ARCH] for the definition of LCD. 133 In order to allow an SNMP entity's LCD to be remotely configured, 134 portions of the LCD need to be accessible as managed objects. A MIB 135 module, the View-based Access Control Model Configuration MIB, which 136 defines these managed object types is included in this document. 138 2. Elements of the Model 140 This section contains definitions to realize the access control 141 service provided by the View-based Access Control Model. 143 2.1. Groups 145 A group is a set of zero or more tuples 146 on whose behalf SNMP management objects can be accessed. A group 147 defines the access rights afforded to all securityNames which belong 148 to that group. The combination of a securityModel and a securityName 149 maps to at most one group. A group is identified by a groupName. 151 The Access Control module assumes that the securityName has already 152 been authenticated as needed and provides no further authentication 153 of its own. 155 The View-based Access Control Model uses the securityModel and the 156 securityName as inputs to the Access Control module when called to 157 check for access rights. It determines the groupName as a function 158 of securityModel and securityName. 160 2.2. securityLevel 162 Different access rights for members of a group can be defined for 163 different levels of security, i.e., noAuthNoPriv, authNoPriv, and 164 authPriv. The securityLevel identifies the level of security that 165 will be assumed when checking for access rights. See the SNMP 166 Architecture document [RFC-ARCH] for a definition of securityLevel. 168 The View-based Access Control Model requires that the securityLevel 169 is passed as input to the Access Control module when called to check 170 for access rights. 172 2.3. Contexts 174 An SNMP context is a collection of management information accessible 175 by an SNMP entity. An item of management information may exist in 176 more than one context. An SNMP entity potentially has access to many 177 contexts. Details about the naming of management information can be 178 found in the SNMP Architecture document [RFC-ARCH]. 180 The View-based Access Control Model defines a vacmContextTable that 181 lists the locally available contexts by contextName. 183 2.4. MIB Views and View Families 185 For security reasons, it is often valuable to be able to restrict the 186 access rights of some groups to only a subset of the management 187 information in the management domain. To provide this capability, 188 access to a context is via a "MIB view" which details a specific set 189 of managed object types (and optionally, the specific instances of 190 object types) within that context. For example, for a given context, 191 there will typically always be one MIB view which provides access to 192 all management information in that context, and often there will be 193 other MIB views each of which contains some subset of the 194 information. So, the access allowed for a group can be restricted in 195 the desired manner by specifying its rights in terms of the 196 particular (subset) MIB view it can access within each appropriate 197 context. 199 Since managed object types (and their instances) are identified via 200 the tree-like naming structure of ISO's OBJECT IDENTIFIERs [ISO- 201 ASN.1, RFC1902], it is convenient to define a MIB view as the 202 combination of a set of "view subtrees", where each view subtree is a 203 subtree within the managed object naming tree. Thus, a simple MIB 204 view (e.g., all managed objects within the Internet Network 205 Management Framework) can be defined as a single view subtree, while 206 more complicated MIB views (e.g., all information relevant to a 207 particular network interface) can be represented by the union of 208 multiple view subtrees. 210 While any set of managed objects can be described by the union of 211 some number of view subtrees, situations can arise that would require 212 a very large number of view subtrees. This could happen, for 213 example, when specifying all columns in one conceptual row of a MIB 214 table because they would appear in separate subtrees, one per column, 215 each with a very similar format. Because the formats are similar, 216 the required set of subtrees can easily be aggregated into one 217 structure. This structure is named a family of view subtrees after 218 the set of subtrees that it conceptually represents. A family of 219 view subtrees can either be included or excluded from a MIB view. 221 2.4.1. View Subtree 223 A view subtree is the set of all MIB object instances which have a 224 common ASN.1 OBJECT IDENTIFIER prefix to their names. A view subtree 225 is identified by the OBJECT IDENTIFIER value which is the longest 226 OBJECT IDENTIFIER prefix common to all (potential) MIB object 227 instances in that subtree. 229 2.4.2. ViewTreeFamily 231 A family of view subtrees is a pairing of an OBJECT IDENTIFIER value 232 (called the family name) together with a bit string value (called the 233 family mask). The family mask indicates which sub-identifiers of the 234 associated family name are significant to the family's definition. 236 For each possible managed object instance, that instance belongs to a 237 particular ViewTreeFamily if both of the following conditions are 238 true: 240 - the OBJECT IDENTIFIER name of the managed object instance 241 contains at least as many sub-identifiers as does the family name, 242 and 244 - each sub-identifier in the OBJECT IDENTIFIER name of the managed 245 object instance matches the corresponding sub-identifier of the 246 family name whenever the corresponding bit of the associated family 247 mask is non-zero. 249 When the configured value of the family mask is all ones, the view 250 subtree family is identical to the single view subtree identified by 251 the family name. 253 When the configured value of the family mask is shorter than required 254 to perform the above test, its value is implicitly extended with 255 ones. Consequently, a view subtree family having a family mask of 256 zero length always corresponds to a single view subtree. 258 2.5. Access Policy 260 The View-based Access Control Model determines the access rights of a 261 group, representing zero or more securityNames which have the same 262 access rights. For a particular context, identified by contextName, 263 to which a group, identified by groupName, has access using a 264 particular securityModel and securityLevel, that group's access 265 rights are given by a read-view, a write-view and a notify-view. 267 The read-view represents the set of object instances authorized for 268 the group when reading objects. Reading objects occurs when 269 processing a retrieval operation (when handling Read Class PDUs). 271 The write-view represents the set of object instances authorized for 272 the group when writing objects. Writing objects occurs when 273 processing a write operation (when handling Write Class PDUs). 275 The notify-view represents the set of object instances authorized for 276 the group when sending objects in a notification, such as when 277 sending a notification (when sending Notification Class PDUs). 279 3. Elements of Procedure 281 This section describes the procedures followed by an Access Control 282 module that implements the View-based Access Control Model when 283 checking access rights as requested by an application (for example a 284 Command Responder or a Notification Originator application). The 285 abstract service primitive is: 287 statusInformation = -- success or errorIndication 288 isAccessAllowed( 289 securityModel -- Security Model in use 290 securityName -- principal who wants access 291 securityLevel -- Level of Security 292 viewType -- read, write, or notify view 293 contextName -- context containing variableName 294 variableName -- OID for the managed object 295 ) 297 The abstract data elements are: 299 statusInformation - one of the following: 300 accessAllowed - a MIB view was found and access is granted. 301 notInView - a MIB view was found but access is denied. 302 The variableName is not in the configured 303 MIB view for the specified viewType (e.g., in 304 the relevant entry in the vacmAccessTable). 305 noSuchView - no MIB view found because no view has been 306 configured for specified viewType (e.g., in 307 the relevant entry in the vacmAccessTable). 308 noSuchContext - no MIB view found because of no entry in the 309 vacmContextTable for specified contextName. 310 noGroupName - no MIB view found because no entry has been 311 configured in the vacmSecurityToGroupTable 312 for the specified combination of 313 securityModel and securityName. 314 noAccessEntry - no MIB view found because no entry has been 315 configured in the vacmAccessTable for the 316 specified combination of contextName, 317 groupName (from vacmSecurityToGroupTable), 318 securityModel and securityLevel. 319 otherError - failure, an undefined error occurred. 320 securityModel - Security Model under which access is requested. 321 securityName - the principal on whose behalf access is requested. 322 securityLevel - Level of Security under which access is requested. 323 viewType - view to be checked (read, write or notify). 324 contextName - context in which access is requested. 325 variableName - object instance to which access is requested. 327 3.1. Overview of isAccessAllowed Process 329 The following picture shows how the decision for access control is made 330 by the View-based Access Control Model. 332 +--------------------------------------------------------------------+ 333 | | 334 | +-> securityModel -+ | 335 | | (a) | | 336 | who -+ +-> groupName ----+ | 337 | (1) | | (x) | | 338 | +-> securityName --+ | | 339 | (b) | | 340 | | | 341 | where -> contextName ---------------------+ | 342 | (2) (e) | | 343 | | | 344 | | | 345 | +-> securityModel -------------------+ | 346 | | (a) | | 347 | how -+ +-> viewName -+ | 348 | (3) | | (y) | | 349 | +-> securityLevel -------------------+ | | 350 | (c) | +-> yes/no | 351 | | | decision | 352 | why ---> viewType (read/write/notify) ----+ | (z) | 353 | (4) (d) | | 354 | | | 355 | what --> object-type ------+ | | 356 | (5) (m) | | | 357 | +-> variableName (OID) ------+ | 358 | | (f) | 359 | which -> object-instance --+ | 360 | (6) (n) | 361 | | 362 +--------------------------------------------------------------------+ 364 How the decision for isAccessAllowed is made. 366 1) Inputs to the isAccessAllowed service are: 368 (a) securityModel -- Security Model in use 369 (b) securityName -- principal who wants to access 370 (c) securityLevel -- Level of Security 371 (d) viewType -- read, write, or notify view 372 (e) contextName -- context containing variableName 373 (f) variableName -- OID for the managed object 374 -- this is made up of: 376 - object-type (m) 377 - object-instance (n) 379 2) The partial "who" (1), represented by the securityModel (a) and 380 the securityName (b), are used as the indices (a,b) into the 381 vacmSecurityToGroupTable to find a single entry that produces a 382 group, represented by groupName (x). 384 3) The "where" (2), represented by the contextName (e), the "who", 385 represented by the groupName (x) from the previous step, and the 386 "how" (3), represented by securityModel (a) and securityLevel (c), 387 are used as indices (e,x,a,c) into the vacmAccessTable to find a 388 single entry that contains three MIB views. 390 4) The "why" (4), represented by the viewType (d), is used to select 391 the proper MIB view, represented by a viewName (y), from the 392 vacmAccessEntry selected in the previous step. This viewName (y) is 393 an index into the vacmViewTreeFamilyTable and selects the set of 394 entries that define the variableNames which are included in or 395 excluded from the MIB view identified by the viewName (y). 397 5) The "what" (5) type of management data and "which" (6) particular 398 instance, represented by the variableName (f), is then checked to be 399 in the MIB view or not, e.g., the yes/no decision (z). 401 3.2. Processing the isAccessAllowed Service Request 403 This section describes the procedure followed by an Access Control 404 module that implements the View-based Access Control Model whenever 405 it receives an isAccessAllowed request. 407 1) The vacmContextTable is consulted for information about 408 the SNMP context identified by the contextName. If information 409 about this SNMP context is absent from the table, then an 410 errorIndication (noSuchContext) is returned to the calling module. 412 2) The vacmSecurityToGroupTable is consulted for mapping the 413 securityModel and securityName to a groupName. If the information 414 about this combination is absent from the table, then an 415 errorIndication (noGroupName) is returned to the calling module. 417 3) The vacmAccessTable is consulted for information about the 418 groupName, contextName, securityModel and securityLevel. If 419 information about this combination is absent from the table, then 420 an errorIndication (noAccessEntry) is returned to the calling 421 module. 423 4) a) If the viewType is "read", then the read view is used for 424 checking access rights. 426 b) If the viewType is "write", then the write view is used for 427 checking access rights. 429 c) If the viewType is "notify", then the notify view is used 430 for checking access rights. 432 If the view to be used is the empty view (zero length viewName) 433 then an errorIndication (noSuchView) is returned to the calling 434 module. 436 5) a) If there is no view configured for the specified viewType, 437 then an errorIndication (noSuchView) is returned to the calling 438 module. 440 b) If the specified variableName (object instance) is not in the 441 MIB view (see DESCRIPTION clause for vacmViewTreeFamilyTable in 442 section 4), then an errorIndication (notInView) is returned to 443 the calling module. 445 Otherwise, 447 c) The specified variableName is in the MIB view. 448 A statusInformation of success (accessAllowed) is returned to 449 the calling module. 451 4. Definitions 453 SNMP-VIEW-BASED-ACM-MIB DEFINITIONS ::= BEGIN 455 IMPORTS 456 MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF 457 MODULE-IDENTITY, OBJECT-TYPE, 458 snmpModules FROM SNMPv2-SMI 459 TestAndIncr, 460 RowStatus, StorageType FROM SNMPv2-TC 461 SnmpAdminString, 462 SnmpSecurityLevel, 463 SnmpSecurityModel FROM SNMP-FRAMEWORK-MIB; 465 snmpVacmMIB MODULE-IDENTITY 466 LAST-UPDATED "9901200000Z" -- 20 Jan 1999, midnight 467 ORGANIZATION "SNMPv3 Working Group" 468 CONTACT-INFO "WG-email: snmpv3@tis.com 469 Subscribe: majordomo@tis.com 470 In message body: subscribe snmpv3 472 Chair: Russ Mundy 473 Trusted Information Systems 474 postal: 3060 Washington Rd 475 Glenwood MD 21738 476 USA 477 email: mundy@tis.com 478 phone: +1-301-854-6889 480 Co-editor: Bert Wijnen 481 IBM T.J. Watson Research 482 postal: Schagen 33 483 3461 GL Linschoten 484 Netherlands 485 email: wijnen@vnet.ibm.com 486 phone: +31-348-432-794 488 Co-editor: Randy Presuhn 489 BMC Software, Inc 490 postal: 965 Stewart Drive 491 Sunnyvale, CA 94086 492 USA 493 email: randy_presuhn@bmc.com 494 phone: +1-408-616-3100 496 Co-editor: Keith McCloghrie 497 Cisco Systems, Inc. 498 postal: 170 West Tasman Drive 499 San Jose, CA 95134-1706 500 USA 501 email: kzm@cisco.com 502 phone: +1-408-526-5260 503 " 504 DESCRIPTION "The management information definitions for the 505 View-based Access Control Model for SNMP. 506 " 507 -- Revision history 508 REVISION "9901200000Z" -- 20 Jan 1999, midnight 509 -- RFC-Editor assigns RFCxxxx 510 DESCRIPTION "Clarifications, published as RFCxxxx" 512 REVISION "9711200000Z" -- 20 Nov 1997, midnight 513 DESCRIPTION "Initial version, published as RFC2275" 515 ::= { snmpModules 16 } 517 -- Administrative assignments **************************************** 518 vacmMIBObjects OBJECT IDENTIFIER ::= { snmpVacmMIB 1 } 519 vacmMIBConformance OBJECT IDENTIFIER ::= { snmpVacmMIB 2 } 521 -- Information about Local Contexts ********************************** 523 vacmContextTable OBJECT-TYPE 524 SYNTAX SEQUENCE OF VacmContextEntry 525 MAX-ACCESS not-accessible 526 STATUS current 527 DESCRIPTION "The table of locally available contexts. 529 This table provides information to SNMP Command 530 Generator applications so that they can properly 531 configure the vacmAccessTable to control access to 532 all contexts at the SNMP entity. 534 This table may change dynamically if the SNMP entity 535 allows that contexts are added/deleted dynamically 536 (for instance when its configuration changes). Such 537 changes would happen only if the management 538 instrumentation at that SNMP entity recognizes more 539 (or fewer) contexts. 541 The presence of entries in this table and of entries 542 in the vacmAccessTable are independent. That is, a 543 context identified by an entry in this table is not 544 necessarily referenced by any entries in the 545 vacmAccessTable; and the context(s) referenced by an 546 entry in the vacmAccessTable does not necessarily 547 currently exist and thus need not be identified by an 548 entry in this table. 550 This table must be made accessible via the default 551 context so that Command Responder applications have 552 a standard way of retrieving the information. 554 This table is read-only. It cannot be configured via 555 SNMP. 556 " 557 ::= { vacmMIBObjects 1 } 559 vacmContextEntry OBJECT-TYPE 560 SYNTAX VacmContextEntry 561 MAX-ACCESS not-accessible 562 STATUS current 563 DESCRIPTION "Information about a particular context." 564 INDEX { 565 vacmContextName 567 } 568 ::= { vacmContextTable 1 } 570 VacmContextEntry ::= SEQUENCE 571 { 572 vacmContextName SnmpAdminString 573 } 575 vacmContextName OBJECT-TYPE 576 SYNTAX SnmpAdminString (SIZE(0..32)) 577 MAX-ACCESS read-only 578 STATUS current 579 DESCRIPTION "A human readable name identifying a particular 580 context at a particular SNMP entity. 582 The empty contextName (zero length) represents the 583 default context. 584 " 585 ::= { vacmContextEntry 1 } 587 -- Information about Groups ****************************************** 589 vacmSecurityToGroupTable OBJECT-TYPE 590 SYNTAX SEQUENCE OF VacmSecurityToGroupEntry 591 MAX-ACCESS not-accessible 592 STATUS current 593 DESCRIPTION "This table maps a combination of securityModel and 594 securityName into a groupName which is used to define 595 an access control policy for a group of principals. 596 " 597 ::= { vacmMIBObjects 2 } 599 vacmSecurityToGroupEntry OBJECT-TYPE 600 SYNTAX VacmSecurityToGroupEntry 601 MAX-ACCESS not-accessible 602 STATUS current 603 DESCRIPTION "An entry in this table maps the combination of a 604 securityModel and securityName into a groupName. 605 " 606 INDEX { 607 vacmSecurityModel, 608 vacmSecurityName 609 } 610 ::= { vacmSecurityToGroupTable 1 } 612 VacmSecurityToGroupEntry ::= SEQUENCE 613 { 614 vacmSecurityModel SnmpSecurityModel, 615 vacmSecurityName SnmpAdminString, 616 vacmGroupName SnmpAdminString, 617 vacmSecurityToGroupStorageType StorageType, 618 vacmSecurityToGroupStatus RowStatus 619 } 621 vacmSecurityModel OBJECT-TYPE 622 SYNTAX SnmpSecurityModel(1..2147483647) 623 MAX-ACCESS not-accessible 624 STATUS current 625 DESCRIPTION "The Security Model, by which the vacmSecurityName 626 referenced by this entry is provided. 628 Note, this object may not take the 'any' (0) value. 629 " 630 ::= { vacmSecurityToGroupEntry 1 } 632 vacmSecurityName OBJECT-TYPE 633 SYNTAX SnmpAdminString (SIZE(1..32)) 634 MAX-ACCESS not-accessible 635 STATUS current 636 DESCRIPTION "The securityName for the principal, represented in a 637 Security Model independent format, which is mapped by 638 this entry to a groupName. 639 " 640 ::= { vacmSecurityToGroupEntry 2 } 642 vacmGroupName OBJECT-TYPE 643 SYNTAX SnmpAdminString (SIZE(1..32)) 644 MAX-ACCESS read-create 645 STATUS current 646 DESCRIPTION "The name of the group to which this entry (e.g., the 647 combination of securityModel and securityName) 648 belongs. 650 This groupName is used as index into the 651 vacmAccessTable to select an access control policy. 652 However, a value in this table does not imply that an 653 instance with the value exists in table vacmAccesTable. 654 " 655 ::= { vacmSecurityToGroupEntry 3 } 657 vacmSecurityToGroupStorageType OBJECT-TYPE 658 SYNTAX StorageType 659 MAX-ACCESS read-create 660 STATUS current 661 DESCRIPTION "The storage type for this conceptual row. 662 Conceptual rows having the value 'permanent' need not 663 allow write-access to any columnar objects in the row. 664 " 665 DEFVAL { nonVolatile } 666 ::= { vacmSecurityToGroupEntry 4 } 668 vacmSecurityToGroupStatus OBJECT-TYPE 669 SYNTAX RowStatus 670 MAX-ACCESS read-create 671 STATUS current 672 DESCRIPTION "The status of this conceptual row. 674 Until instances of all corresponding columns are 675 appropriately configured, the value of the 676 corresponding instance of the vacmSecurityToGroupStatus 677 column is 'notReady'. 679 In particular, a newly created row cannot be made 680 active until a value has been set for vacmGroupName. 682 The RowStatus TC [RFC1903] requires that this 683 DESCRIPTION clause states under which circumstances 684 other objects in this row can be modified: 686 The value of this object has no effect on whether 687 other objects in this conceptual row can be modified. 688 " 689 ::= { vacmSecurityToGroupEntry 5 } 691 -- Information about Access Rights *********************************** 693 vacmAccessTable OBJECT-TYPE 694 SYNTAX SEQUENCE OF VacmAccessEntry 695 MAX-ACCESS not-accessible 696 STATUS current 697 DESCRIPTION "The table of access rights for groups. 699 Each entry is indexed by a groupName, a contextPrefix, 700 a securityModel and a securityLevel. To determine 701 whether access is allowed, one entry from this table 702 needs to be selected and the proper viewName from that 703 entry must be used for access control checking. 705 To select the proper entry, follow these steps: 707 1) the set of possible matches is formed by the 708 intersection of the following sets of entries: 709 the set of entries with identical vacmGroupName 710 the union of these two sets: 712 - the set with identical vacmAccessContextPrefix 713 - the set of entries with vacmAccessContextMatch 714 value of 'prefix' and matching 715 vacmAccessContextPrefix 716 intersected with the union of these two sets: 717 - the set of entries with identical 718 vacmSecurityModel 719 - the set of entries with vacmSecurityModel 720 value of 'any' 721 intersected with the set of entries with 722 vacmAccessSecurityLevel value less than or equal 723 to the requested securityLevel 725 2) if this set has only one member, we're done 726 otherwise, it comes down to deciding how to weight 727 the preferences between ContextPrefixes, 728 SecurityModels, and SecurityLevels as follows: 729 a) if the subset of entries with securityModel 730 matching the securityModel in the message is 731 not empty, then discard the rest. 732 b) if the subset of entries with 733 vacmAccessContextPrefix matching the contextName 734 in the message is not empty, 735 then discard the rest 736 c) discard all entries with ContextPrefixes shorter 737 than the longest one remaining in the set 738 d) select the entry with the highest securityLevel 740 Please note that for securityLevel noAuthNoPriv, all 741 groups are really equivalent since the assumption that 742 the securityName has been authenticated does not hold. 743 " 744 ::= { vacmMIBObjects 4 } 746 vacmAccessEntry OBJECT-TYPE 747 SYNTAX VacmAccessEntry 748 MAX-ACCESS not-accessible 749 STATUS current 750 DESCRIPTION "An access right configured in the Local Configuration 751 Datastore (LCD) authorizing access to an SNMP context. 753 Entries in this table can use an instance value for 754 object vacmGroupName even if no entry in table 755 vacmAccessSecurityToGroupTable has a corresponding 756 value for object vacmGroupName. 757 " 758 INDEX { vacmGroupName, 759 vacmAccessContextPrefix, 760 vacmAccessSecurityModel, 761 vacmAccessSecurityLevel 762 } 763 ::= { vacmAccessTable 1 } 765 VacmAccessEntry ::= SEQUENCE 766 { 767 vacmAccessContextPrefix SnmpAdminString, 768 vacmAccessSecurityModel SnmpSecurityModel, 769 vacmAccessSecurityLevel SnmpSecurityLevel, 770 vacmAccessContextMatch INTEGER, 771 vacmAccessReadViewName SnmpAdminString, 772 vacmAccessWriteViewName SnmpAdminString, 773 vacmAccessNotifyViewName SnmpAdminString, 774 vacmAccessStorageType StorageType, 775 vacmAccessStatus RowStatus 776 } 778 vacmAccessContextPrefix OBJECT-TYPE 779 SYNTAX SnmpAdminString (SIZE(0..32)) 780 MAX-ACCESS not-accessible 781 STATUS current 782 DESCRIPTION "In order to gain the access rights allowed by this 783 conceptual row, a contextName must match exactly 784 (if the value of vacmAccessContextMatch is 'exact') 785 or partially (if the value of vacmAccessContextMatch 786 is 'prefix') to the value of the instance of this 787 object. 788 " 789 ::= { vacmAccessEntry 1 } 791 vacmAccessSecurityModel OBJECT-TYPE 792 SYNTAX SnmpSecurityModel 793 MAX-ACCESS not-accessible 794 STATUS current 795 DESCRIPTION "In order to gain the access rights allowed by this 796 conceptual row, this securityModel must be in use. 797 " 798 ::= { vacmAccessEntry 2 } 800 vacmAccessSecurityLevel OBJECT-TYPE 801 SYNTAX SnmpSecurityLevel 802 MAX-ACCESS not-accessible 803 STATUS current 804 DESCRIPTION "The minimum level of security required in order to 805 gain the access rights allowed by this conceptual 806 row. A securityLevel of noAuthNoPriv is less than 807 authNoPriv which in turn is less than authPriv. 809 If multiple entries are equally indexed except for 810 this vacmAccessSecurityLevel index, then the entry 811 which has the highest value for 812 vacmAccessSecurityLevel is selected. 813 " 814 ::= { vacmAccessEntry 3 } 816 vacmAccessContextMatch OBJECT-TYPE 817 SYNTAX INTEGER 818 { exact (1), -- exact match of prefix and contextName 819 prefix (2) -- Only match to the prefix 820 } 821 MAX-ACCESS read-create 822 STATUS current 823 DESCRIPTION "If the value of this object is exact(1), then all 824 rows where the contextName exactly matches 825 vacmAccessContextPrefix are selected. 827 If the value of this object is prefix(2), then all 828 rows where the contextName whose starting octets 829 exactly match vacmAccessContextPrefix are selected. 830 This allows for a simple form of wildcarding. 831 " 832 DEFVAL { exact } 833 ::= { vacmAccessEntry 4 } 835 vacmAccessReadViewName OBJECT-TYPE 836 SYNTAX SnmpAdminString (SIZE(0..32)) 837 MAX-ACCESS read-create 838 STATUS current 839 DESCRIPTION "The value of an instance of this object identifies 840 the MIB view of the SNMP context to which this 841 conceptual row authorizes read access. 843 The identified MIB view is that one for which the 844 vacmViewTreeFamilyViewName has the same value as the 845 instance of this object; if the value is the empty 846 string or if there is no active MIB view having this 847 value of vacmViewTreeFamilyViewName, then no access 848 is granted. 849 " 850 DEFVAL { ''H } -- the empty string 851 ::= { vacmAccessEntry 5 } 853 vacmAccessWriteViewName OBJECT-TYPE 854 SYNTAX SnmpAdminString (SIZE(0..32)) 855 MAX-ACCESS read-create 856 STATUS current 857 DESCRIPTION "The value of an instance of this object identifies 858 the MIB view of the SNMP context to which this 859 conceptual row authorizes write access. 861 The identified MIB view is that one for which the 862 vacmViewTreeFamilyViewName has the same value as the 863 instance of this object; if the value is the empty 864 string or if there is no active MIB view having this 865 value of vacmViewTreeFamilyViewName, then no access 866 is granted. 867 " 868 DEFVAL { ''H } -- the empty string 869 ::= { vacmAccessEntry 6 } 871 vacmAccessNotifyViewName OBJECT-TYPE 872 SYNTAX SnmpAdminString (SIZE(0..32)) 873 MAX-ACCESS read-create 874 STATUS current 875 DESCRIPTION "The value of an instance of this object identifies 876 the MIB view of the SNMP context to which this 877 conceptual row authorizes access for notifications. 879 The identified MIB view is that one for which the 880 vacmViewTreeFamilyViewName has the same value as the 881 instance of this object; if the value is the empty 882 string or if there is no active MIB view having this 883 value of vacmViewTreeFamilyViewName, then no access 884 is granted. 885 " 886 DEFVAL { ''H } -- the empty string 887 ::= { vacmAccessEntry 7 } 889 vacmAccessStorageType OBJECT-TYPE 890 SYNTAX StorageType 891 MAX-ACCESS read-create 892 STATUS current 893 DESCRIPTION "The storage type for this conceptual row. 895 Conceptual rows having the value 'permanent' need not 896 allow write-access to any columnar objects in the row. 897 " 898 DEFVAL { nonVolatile } 899 ::= { vacmAccessEntry 8 } 901 vacmAccessStatus OBJECT-TYPE 902 SYNTAX RowStatus 903 MAX-ACCESS read-create 904 STATUS current 905 DESCRIPTION "The status of this conceptual row. 907 The RowStatus TC [RFC1903] requires that this 908 DESCRIPTION clause states under which circumstances 909 other objects in this row can be modified: 911 The value of this object has no effect on whether 912 other objects in this conceptual row can be modified. 913 " 914 ::= { vacmAccessEntry 9 } 916 -- Information about MIB views *************************************** 918 -- Support for instance-level granularity is optional. 919 -- 920 -- In some implementations, instance-level access control 921 -- granularity may come at a high performance cost. Managers 922 -- should avoid requesting such configurations unnecessarily. 924 vacmMIBViews OBJECT IDENTIFIER ::= { vacmMIBObjects 5 } 926 vacmViewSpinLock OBJECT-TYPE 927 SYNTAX TestAndIncr 928 MAX-ACCESS read-write 929 STATUS current 930 DESCRIPTION "An advisory lock used to allow cooperating SNMP 931 Command Generator applications to coordinate their 932 use of the Set operation in creating or modifying 933 views. 935 When creating a new view or altering an existing 936 view, it is important to understand the potential 937 interactions with other uses of the view. The 938 vacmViewSpinLock should be retrieved. The name of 939 the view to be created should be determined to be 940 unique by the SNMP Command Generator application by 941 consulting the vacmViewTreeFamilyTable. Finally, 942 the named view may be created (Set), including the 943 advisory lock. 944 If another SNMP Command Generator application has 945 altered the views in the meantime, then the spin 946 lock's value will have changed, and so this creation 947 will fail because it will specify the wrong value for 948 the spin lock. 950 Since this is an advisory lock, the use of this lock 951 is not enforced. 953 " 954 ::= { vacmMIBViews 1 } 956 vacmViewTreeFamilyTable OBJECT-TYPE 957 SYNTAX SEQUENCE OF VacmViewTreeFamilyEntry 958 MAX-ACCESS not-accessible 959 STATUS current 960 DESCRIPTION "Locally held information about families of subtrees 961 within MIB views. 963 Each MIB view is defined by two sets of view subtrees: 964 - the included view subtrees, and 965 - the excluded view subtrees. 966 Every such view subtree, both the included and the 967 excluded ones, is defined in this table. 969 To determine if a particular object instance is in 970 a particular MIB view, compare the object instance's 971 OBJECT IDENTIFIER with each of the MIB view's active 972 entries in this table. If none match, then the 973 object instance is not in the MIB view. If one or 974 more match, then the object instance is included in, 975 or excluded from, the MIB view according to the 976 value of vacmViewTreeFamilyType in the entry whose 977 value of vacmViewTreeFamilySubtree has the most 978 sub-identifiers. If multiple entries match and have 979 the same number of sub-identifiers (when wildcarding 980 is specified with the value of vacmViewTreeFamilyMask), 981 then the lexicographically greatest instance of 982 vacmViewTreeFamilyType determines the inclusion or 983 exclusion. 985 An object instance's OBJECT IDENTIFIER X matches an 986 active entry in this table when the number of 987 sub-identifiers in X is at least as many as in the 988 value of vacmViewTreeFamilySubtree for the entry, 989 and each sub-identifier in the value of 990 vacmViewTreeFamilySubtree matches its corresponding 991 sub-identifier in X. Two sub-identifiers match 992 either if the corresponding bit of the value of 993 vacmViewTreeFamilyMask for the entry is zero (the 994 'wild card' value), or if they are equal. 996 A 'family' of subtrees is the set of subtrees defined 997 by a particular combination of values of 998 vacmViewTreeFamilySubtree and vacmViewTreeFamilyMask. 999 In the case where no 'wild card' is defined in the 1000 vacmViewTreeFamilyMask, the family of subtrees reduces 1001 to a single subtree. 1003 When creating or changing MIB views, an SNMP Command 1004 Generator application should utilize the 1005 vacmViewSpinLock to try to avoid collisions. See 1006 DESCRIPTION clause of vacmViewSpinLock. 1008 When creating MIB views, it is strongly advised that 1009 first the 'excluded' vacmViewTreeFamilyEntries are 1010 created and then the 'included' entries. 1012 When deleting MIB views, it is strongly advised that 1013 first the 'included' vacmViewTreeFamilyEntries are 1014 deleted and then the 'excluded' entries. 1016 If a create for an entry for instance-level access 1017 control is received and the implementation does not 1018 support instance-level granularity, then an 1019 inconsistentName error must be returned. 1020 " 1021 ::= { vacmMIBViews 2 } 1023 vacmViewTreeFamilyEntry OBJECT-TYPE 1024 SYNTAX VacmViewTreeFamilyEntry 1025 MAX-ACCESS not-accessible 1026 STATUS current 1027 DESCRIPTION "Information on a particular family of view subtrees 1028 included in or excluded from a particular SNMP 1029 context's MIB view. 1031 Implementations must not restrict the number of 1032 families of view subtrees for a given MIB view, 1033 except as dictated by resource constraints on the 1034 overall number of entries in the 1035 vacmViewTreeFamilyTable. 1037 If no conceptual rows exist in this table for a given 1038 MIB view (viewName), that view may be thought of as 1039 consisting of the empty set of view subtrees. 1040 " 1041 INDEX { vacmViewTreeFamilyViewName, 1042 vacmViewTreeFamilySubtree 1043 } 1044 ::= { vacmViewTreeFamilyTable 1 } 1046 VacmViewTreeFamilyEntry ::= SEQUENCE 1047 { 1048 vacmViewTreeFamilyViewName SnmpAdminString, 1049 vacmViewTreeFamilySubtree OBJECT IDENTIFIER, 1050 vacmViewTreeFamilyMask OCTET STRING, 1051 vacmViewTreeFamilyType INTEGER, 1052 vacmViewTreeFamilyStorageType StorageType, 1053 vacmViewTreeFamilyStatus RowStatus 1054 } 1056 vacmViewTreeFamilyViewName OBJECT-TYPE 1057 SYNTAX SnmpAdminString (SIZE(1..32)) 1058 MAX-ACCESS not-accessible 1059 STATUS current 1060 DESCRIPTION "The human readable name for a family of view subtrees. 1061 " 1062 ::= { vacmViewTreeFamilyEntry 1 } 1064 vacmViewTreeFamilySubtree OBJECT-TYPE 1065 SYNTAX OBJECT IDENTIFIER 1066 MAX-ACCESS not-accessible 1067 STATUS current 1068 DESCRIPTION "The MIB subtree which when combined with the 1069 corresponding instance of vacmViewTreeFamilyMask 1070 defines a family of view subtrees. 1071 " 1072 ::= { vacmViewTreeFamilyEntry 2 } 1074 vacmViewTreeFamilyMask OBJECT-TYPE 1075 SYNTAX OCTET STRING (SIZE (0..16)) 1076 MAX-ACCESS read-create 1077 STATUS current 1078 DESCRIPTION "The bit mask which, in combination with the 1079 corresponding instance of vacmViewTreeFamilySubtree, 1080 defines a family of view subtrees. 1082 Each bit of this bit mask corresponds to a 1083 sub-identifier of vacmViewTreeFamilySubtree, with the 1084 most significant bit of the i-th octet of this octet 1085 string value (extended if necessary, see below) 1086 corresponding to the (8*i - 7)-th sub-identifier, and 1087 the least significant bit of the i-th octet of this 1088 octet string corresponding to the (8*i)-th 1089 sub-identifier, where i is in the range 1 through 16. 1091 Each bit of this bit mask specifies whether or not 1092 the corresponding sub-identifiers must match when 1093 determining if an OBJECT IDENTIFIER is in this 1094 family of view subtrees; a '1' indicates that an 1095 exact match must occur; a '0' indicates 'wild card', 1096 i.e., any sub-identifier value matches. 1098 Thus, the OBJECT IDENTIFIER X of an object instance 1099 is contained in a family of view subtrees if, for 1100 each sub-identifier of the value of 1101 vacmViewTreeFamilySubtree, either: 1103 the i-th bit of vacmViewTreeFamilyMask is 0, or 1105 the i-th sub-identifier of X is equal to the i-th 1106 sub-identifier of the value of 1107 vacmViewTreeFamilySubtree. 1109 If the value of this bit mask is M bits long and 1110 there are more than M sub-identifiers in the 1111 corresponding instance of vacmViewTreeFamilySubtree, 1112 then the bit mask is extended with 1's to be the 1113 required length. 1115 Note that when the value of this object is the 1116 zero-length string, this extension rule results in 1117 a mask of all-1's being used (i.e., no 'wild card'), 1118 and the family of view subtrees is the one view 1119 subtree uniquely identified by the corresponding 1120 instance of vacmViewTreeFamilySubtree. 1122 Note that masks of length greater than zero length 1123 do not need to be supported. In this case this 1124 object is made read-only. 1125 " 1126 DEFVAL { ''H } 1127 ::= { vacmViewTreeFamilyEntry 3 } 1129 vacmViewTreeFamilyType OBJECT-TYPE 1130 SYNTAX INTEGER { included(1), excluded(2) } 1131 MAX-ACCESS read-create 1132 STATUS current 1133 DESCRIPTION "Indicates whether the corresponding instances of 1134 vacmViewTreeFamilySubtree and vacmViewTreeFamilyMask 1135 define a family of view subtrees which is included in 1136 or excluded from the MIB view. 1137 " 1138 DEFVAL { included } 1139 ::= { vacmViewTreeFamilyEntry 4 } 1141 vacmViewTreeFamilyStorageType OBJECT-TYPE 1142 SYNTAX StorageType 1143 MAX-ACCESS read-create 1144 STATUS current 1145 DESCRIPTION "The storage type for this conceptual row. 1147 Conceptual rows having the value 'permanent' need not 1148 allow write-access to any columnar objects in the row. 1149 " 1150 DEFVAL { nonVolatile } 1151 ::= { vacmViewTreeFamilyEntry 5 } 1153 vacmViewTreeFamilyStatus OBJECT-TYPE 1154 SYNTAX RowStatus 1155 MAX-ACCESS read-create 1156 STATUS current 1157 DESCRIPTION "The status of this conceptual row. 1159 The RowStatus TC [RFC1903] requires that this 1160 DESCRIPTION clause states under which circumstances 1161 other objects in this row can be modified: 1163 The value of this object has no effect on whether 1164 other objects in this conceptual row can be modified. 1165 " 1166 ::= { vacmViewTreeFamilyEntry 6 } 1168 -- Conformance information ******************************************* 1170 vacmMIBCompliances OBJECT IDENTIFIER ::= { vacmMIBConformance 1 } 1171 vacmMIBGroups OBJECT IDENTIFIER ::= { vacmMIBConformance 2 } 1173 -- Compliance statements ********************************************* 1175 vacmMIBCompliance MODULE-COMPLIANCE 1176 STATUS current 1177 DESCRIPTION "The compliance statement for SNMP engines which 1178 implement the SNMP View-based Access Control Model 1179 configuration MIB. 1180 " 1181 MODULE -- this module 1182 MANDATORY-GROUPS { vacmBasicGroup } 1184 OBJECT vacmAccessContextMatch 1185 MIN-ACCESS read-only 1186 DESCRIPTION "Write access is not required." 1187 OBJECT vacmAccessReadViewName 1188 MIN-ACCESS read-only 1189 DESCRIPTION "Write access is not required." 1191 OBJECT vacmAccessWriteViewName 1192 MIN-ACCESS read-only 1193 DESCRIPTION "Write access is not required." 1195 OBJECT vacmAccessNotifyViewName 1196 MIN-ACCESS read-only 1197 DESCRIPTION "Write access is not required." 1199 OBJECT vacmAccessStorageType 1200 MIN-ACCESS read-only 1201 DESCRIPTION "Write access is not required." 1203 OBJECT vacmAccessStatus 1204 MIN-ACCESS read-only 1205 DESCRIPTION "Create/delete/modify access to the 1206 vacmAccessTable is not required. 1207 " 1209 OBJECT vacmViewFamilySubTree 1210 DESCRIPTION "Support for instance level granularity is 1211 optional. 1212 " 1214 OBJECT vacmViewTreeFamilyMask 1215 WRITE-SYNTAX OCTET STRING (SIZE (0)) 1216 MIN-ACCESS read-only 1217 DESCRIPTION "Support for configuration via SNMP of subtree 1218 families using wild-cards is not required. 1219 " 1221 OBJECT vacmViewTreeFamilyType 1222 MIN-ACCESS read-only 1223 DESCRIPTION "Write access is not required." 1225 OBJECT vacmViewTreeFamilyStorageType 1226 MIN-ACCESS read-only 1227 DESCRIPTION "Write access is not required." 1229 OBJECT vacmViewTreeFamilyStatus 1230 MIN-ACCESS read-only 1231 DESCRIPTION "Create/delete/modify access to the 1232 vacmViewTreeFamilyTable is not required. 1233 " 1234 ::= { vacmMIBCompliances 1 } 1236 -- Units of conformance ********************************************** 1238 vacmBasicGroup OBJECT-GROUP 1239 OBJECTS { 1240 vacmContextName, 1241 vacmGroupName, 1242 vacmSecurityToGroupStorageType, 1243 vacmSecurityToGroupStatus, 1244 vacmAccessContextMatch, 1245 vacmAccessReadViewName, 1246 vacmAccessWriteViewName, 1247 vacmAccessNotifyViewName, 1248 vacmAccessStorageType, 1249 vacmAccessStatus, 1250 vacmViewSpinLock, 1251 vacmViewTreeFamilyMask, 1252 vacmViewTreeFamilyType, 1253 vacmViewTreeFamilyStorageType, 1254 vacmViewTreeFamilyStatus 1255 } 1256 STATUS current 1257 DESCRIPTION "A collection of objects providing for remote 1258 configuration of an SNMP engine which implements 1259 the SNMP View-based Access Control Model. 1260 " 1261 ::= { vacmMIBGroups 1 } 1263 END 1265 5. Intellectual Property 1267 The IETF takes no position regarding the validity or scope of any 1268 intellectual property or other rights that might be claimed to 1269 pertain to the implementation or use of the technology described in 1270 this document or the extent to which any license under such rights 1271 might or might not be available; neither does it represent that it 1272 has made any effort to identify any such rights. Information on the 1273 IETF's procedures with respect to rights in standards-track and 1274 standards-related documentation can be found in BCP-11. Copies of 1275 claims of rights made available for publication and any assurances of 1276 licenses to be made available, or the result of an attempt made to 1277 obtain a general license or permission for the use of such 1278 proprietary rights by implementors or users of this specification can 1279 be obtained from the IETF Secretariat. 1281 The IETF invites any interested party to bring to its attention any 1282 copyrights, patents or patent applications, or other proprietary 1283 rights which may cover technology that may be required to practice 1284 this standard. Please address the information to the IETF Executive 1285 Director. 1287 6. Acknowledgements 1289 This document is the result of the efforts of the SNMPv3 Working 1290 Group. Some special thanks are in order to the following SNMPv3 WG 1291 members: 1293 Harald Tveit Alvestrand (Maxware) 1294 Dave Battle (SNMP Research, Inc.) 1295 Alan Beard (Disney Worldwide Services) 1296 Paul Berrevoets (SWI Systemware/Halcyon Inc.) 1297 Martin Bjorklund (Ericsson) 1298 Uri Blumenthal (IBM T.J. Watson Research Center) 1299 Jeff Case (SNMP Research, Inc.) 1300 John Curran (BBN) 1301 Mike Daniele (Compaq Computer Corporation) 1302 T. Max Devlin (Eltrax Systems) 1303 John Flick (Hewlett Packard) 1304 Rob Frye (MCI) 1305 Wes Hardaker (U.C.Davis, Information Technology - D.C.A.S.) 1306 David Harrington (Cabletron Systems Inc.) 1307 Lauren Heintz (BMC Software, Inc.) 1308 N.C. Hien (IBM T.J. Watson Research Center) 1309 Michael Kirkham (InterWorking Labs, Inc.) 1310 Dave Levi (SNMP Research, Inc.) 1311 Louis A Mamakos (UUNET Technologies Inc.) 1312 Joe Marzot (Nortel Networks) 1313 Paul Meyer (Secure Computing Corporation) 1314 Keith McCloghrie (Cisco Systems) 1315 Bob Moore (IBM) 1316 Russ Mundy (TIS Labs at Network Associates) 1317 Bob Natale (ACE*COMM Corporation) 1318 Mike O'Dell (UUNET Technologies Inc.) 1319 Dave Perkins (DeskTalk) 1320 Peter Polkinghorne (Brunel University) 1321 Randy Presuhn (BMC Software, Inc.) 1322 David Reeder (TIS Labs at Network Associates) 1323 David Reid (SNMP Research, Inc.) 1324 Aleksey Romanov (Quality Quorum) 1325 Shawn Routhier (Epilogue) 1326 Juergen Schoenwaelder (TU Braunschweig) 1327 Bob Stewart (Cisco Systems) 1328 Mike Thatcher (Independent Consultant) 1329 Bert Wijnen (IBM T.J. Watson Research Center) 1331 The document is based on recommendations of the IETF Security and 1332 Administrative Framework Evolution for SNMP Advisory Team. Members 1333 of that Advisory Team were: 1335 David Harrington (Cabletron Systems Inc.) 1336 Jeff Johnson (Cisco Systems) 1337 David Levi (SNMP Research Inc.) 1338 John Linn (Openvision) 1339 Russ Mundy (Trusted Information Systems) chair 1340 Shawn Routhier (Epilogue) 1341 Glenn Waters (Nortel) 1342 Bert Wijnen (IBM T. J. Watson Research Center) 1344 As recommended by the Advisory Team and the SNMPv3 Working Group 1345 Charter, the design incorporates as much as practical from previous 1346 RFCs and drafts. As a result, special thanks are due to the authors 1347 of previous designs known as SNMPv2u and SNMPv2*: 1349 Jeff Case (SNMP Research, Inc.) 1350 David Harrington (Cabletron Systems Inc.) 1351 David Levi (SNMP Research, Inc.) 1352 Keith McCloghrie (Cisco Systems) 1353 Brian O'Keefe (Hewlett Packard) 1354 Marshall T. Rose (Dover Beach Consulting) 1355 Jon Saperia (BGS Systems Inc.) 1356 Steve Waldbusser (International Network Services) 1357 Glenn W. Waters (Bell-Northern Research Ltd.) 1359 7. Security Considerations 1361 7.1. Recommended Practices 1363 This document is meant for use in the SNMP architecture. The View- 1364 based Access Control Model described in this document checks access 1365 rights to management information based on: 1367 - contextName, representing a set of management information at the 1368 managed system where the Access Control module is running. 1369 - groupName, representing a set of zero or more securityNames. 1370 The combination of a securityModel and a securityName is mapped 1371 into a group in the View-based Access Control Model. 1372 - securityModel under which access is requested. 1373 - securityLevel under which access is requested. 1374 - operation performed on the management information. 1375 - MIB views for read, write or notify access. 1377 When the User-based Access Control module is called for checking 1378 access rights, it is assumed that the calling module has ensured the 1379 authentication and privacy aspects as specified by the securityLevel 1380 that is being passed. 1382 When creating entries in or deleting entries from the 1383 vacmViewTreeFamilyTable it is important to do such in the sequence as 1384 recommended in the DESCRIPTION clause of the vacmViewTreeFamilyTable 1385 definition. Otherwise unwanted access may be granted while changing 1386 the entries in the table. 1388 7.2. Defining Groups 1390 The groupNames are used to give access to a group of zero or more 1391 securityNames. Within the View-Based Access Control Model, a 1392 groupName is considered to exist if that groupName is listed in the 1393 vacmSecurityToGroupTable. 1395 By mapping the combination of a securityModel and securityName into a 1396 groupName, an SNMP Command Generator application can add/delete 1397 securityNames to/from a group, if proper access is allowed. 1399 Further it is important to realize that the grouping of 1400 tuples in the vacmSecurityToGroupTable 1401 does not take securityLevel into account. It is therefore important 1402 that the security administrator uses the securityLevel index in the 1403 vacmAccessTable to separate noAuthNoPriv from authPriv and/or 1404 authNoPriv access. 1406 7.3. Conformance 1408 For an implementation of the View-based Access Control Model to be 1409 conformant, it MUST implement the SNMP-VIEW-BASED-ACM-MIB according 1410 to the vacmMIBCompliance. It also SHOULD implement the initial 1411 configuration, described in appendix A. 1413 7.4. Access to the SNMP-VIEW-BASED-ACM-MIB 1415 The objects in this MIB control the access to all MIB data that is 1416 accessible via the SNMP engine and they may be considered sensitive 1417 in many environments. It is important to closely control (both read 1418 and write) access to these to these MIB objects by using 1419 appropriately configured Access Control models (for example the 1420 View-based Access Control Model as specified in this document). 1422 8. References 1424 [RFC1902] Case, J., McCloghrie, K., Rose, M. and S., Waldbusser, 1425 "Structure of Management Information for Version 2 of the 1426 Simple Network Management Protocol (SNMPv2)", RFC 1902, January 1427 1996. 1429 [RFC1903] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, 1430 "Textual Conventions for Version 2 of the Simple Network 1431 Management Protocol (SNMPv2)", RFC 1903, January 1996. 1433 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1434 Requirement Levels", BCP 14, RFC 2119, March 1997. 1436 [RFC-ARCH] Harrington, D., Presuhn, R., and B. Wijnen, 1437 "An Architecture for describing SNMP Management Frameworks", 1438 draft-ietf-snmpv3-arch-03, January 1999. 1440 [RFC-MPD] Case, J., Harrington, D., Presuhn, R., and B. Wijnen, 1441 "Message Processing and Dispatching for the Simple Network 1442 Management Protocol (SNMP)", draft-ietf-snmpv3-mpc-03, January 1443 1999. 1445 [RFC-USM] Blumenthal, U., and B. Wijnen, "User-based 1446 Security Model (USM) for version 3 of the Simple Network 1447 Management Protocol (SNMPv3)", draft-ietf-snmpv3-usm-v2-04, 1448 January 1999. 1450 [ISO-ASN.1] Information processing systems - Open Systems 1451 Interconnection - Specification of Abstract Syntax Notation One 1452 (ASN.1), International Organization for Standardization. 1453 International Standard 8824, (December, 1987). 1455 9. Editors' Addresses 1457 Bert Wijnen 1458 IBM T. J. Watson Research 1459 Schagen 33 1460 3461 GL Linschoten 1461 Netherlands 1463 EMail: wijnen@vnet.ibm.com 1464 Phone: +31-348-432-794 1466 Randy Presuhn 1467 BMC Software, Inc 1468 965 Stewart Drive 1469 Sunnyvale, CA 94086 1470 USA 1472 EMail: randy_presuhn@bmc.com 1473 Phone: +1-408-616-3100 1475 Keith McCloghrie 1476 Cisco Systems, Inc. 1477 170 West Tasman Drive 1478 San Jose, CA 95134-1706 1479 USA 1481 EMail: kzm@cisco.com 1482 Phone: +1-408-526-5260 1484 APPENDIX A - Installation 1486 A.1. Installation Parameters 1488 During installation, an authoritative SNMP engine which supports this 1489 View-based Access Control Model SHOULD be configured with several 1490 initial parameters. These include for the View-based Access Control 1491 Model: 1493 1) A security configuration 1495 The choice of security configuration determines if initial 1496 configuration is implemented and if so how. One of three possible 1497 choices is selected: 1499 - initial-minimum-security-configuration 1500 - initial-semi-security-configuration 1501 - initial-no-access-configuration 1503 In the case of a initial-no-access-configuration, there is no initial 1504 configuration, and so the following steps are irrelevant. 1506 2) A default context 1508 One entry in the vacmContextTable with a contextName of "" (the empty 1509 string), representing the default context. Note that this table gets 1510 created automatically if a default context exists. 1512 vacmContextName "" 1514 3) An initial group 1516 One entry in the vacmSecurityToGroupTable to allow access to group 1517 "initial". 1519 vacmSecurityModel 3 (USM) 1520 vacmSecurityName "initial" 1521 vacmGroupName "initial" 1522 vacmSecurityToGroupStorageType anyValidStorageType 1523 vacmSecurityToGroupStatus active 1525 4) Initial access rights 1527 Three entries in the vacmAccessTable as follows: 1529 - read-notify access for securityModel USM, securityLevel 1530 "noAuthNoPriv" on behalf of securityNames that belong to the group 1531 "initial" to the MIB view in the default context with 1532 contextName "". 1534 - read-write-notify access for securityModel USM, securityLevel 1535 "authNoPriv" on behalf of securityNames that belong to the group 1536 "initial" to the MIB view in the default context with 1537 contextName "". 1539 - if privacy is supported, 1540 read-write-notify access for securityModel USM, securityLevel 1541 "authPriv" on behalf of securityNames that belong to the group 1542 "initial" to the MIB view in the default context with 1543 contextName "". 1545 That translates into the following entries in the vacmAccessTable. 1547 - One entry to be used for unauthenticated access (noAuthNoPriv): 1549 vacmGroupName "initial" 1550 vacmAccessContextPrefix "" 1551 vacmAccessSecurityModel 3 (USM) 1552 vacmAccessSecurityLevel noAuthNoPriv 1553 vacmAccessContextMatch exact 1554 vacmAccessReadViewName "restricted" 1555 vacmAccessWriteViewName "" 1556 vacmAccessNotifyViewName "restricted" 1557 vacmAccessStorageType anyValidStorageType 1558 vacmAccessStatus active 1560 - One entry to be used for authenticated access (authNoPriv) 1561 with optional privacy (NoPriv): 1563 vacmGroupName "initial" 1564 vacmAccessContextPrefix "" 1565 vacmAccessSecurityModel 3 (USM) 1566 vacmAccessSecurityLevel authNoPriv 1567 vacmAccessContextMatch exact 1568 vacmAccessReadViewName "internet" 1569 vacmAccessWriteViewName "internet" 1570 vacmAccessNotifyViewName "internet" 1571 vacmAccessStorageType anyValidStorageType 1572 vacmAccessStatus active 1574 5) Two MIB views, of which the second one depends on the security 1575 configuration. 1577 - One view, the view, for authenticated access: 1579 - the MIB view is the following subtree: 1580 "internet" (subtree 1.3.6.1) 1582 - A second view, the view, for unauthenticated 1583 access. This view is configured according to the selected 1584 security configuration: 1586 - For the initial-no-access-configuration there is no default 1587 initial configuration, so no MIB views are pre-scribed. 1589 - For the initial-semi-secure-configuration: 1591 the MIB view is the union of these subtrees: 1592 (a) "system" (subtree 1.3.6.1.2.1.1) [RFC1907] 1593 (b) "snmp" (subtree 1.3.6.1.2.1.11) [RFC1907] 1594 (c) "snmpEngine" (subtree 1.3.6.1.6.3.10.2.1) [RFC-ARCH] 1595 (d) "snmpMPDStats" (subtree 1.3.6.1.6.3.11.2.1) [RFC-MPD] 1596 (e) "usmStats" (subtree 1.3.6.1.6.3.15.1.1) [RFC-USM] 1598 - For the initial-minimum-secure-configuration: 1600 the MIB view is the following subtree. 1601 "internet" (subtree 1.3.6.1) 1603 This translates into the following "internet" entry in the 1604 vacmViewTreeFamilyTable: 1606 minimum-secure semi-secure 1607 ---------------- --------------- 1608 vacmViewTreeFamilyViewName "internet" "internet" 1609 vacmViewTreeFamilySubtree 1.3.6.1 1.3.6.1 1610 vacmViewTreeFamilyMask "" "" 1611 vacmViewTreeFamilyType 1 (included) 1 (included) 1612 vacmViewTreeFamilyStorageType anyValidStorageType anyValidStorageType 1613 vacmViewTreeFamilyStatus active active 1614 In addition it translates into the following "restricted" entries 1615 in the vacmViewTreeFamilyTable: 1617 minimum-secure semi-secure 1618 ---------------- --------------- 1619 vacmViewTreeFamilyViewName "restricted" "restricted" 1620 vacmViewTreeFamilySubtree 1.3.6.1 1.3.6.1.2.1.1 1621 vacmViewTreeFamilyMask "" "" 1622 vacmViewTreeFamilyType 1 (included) 1 (included) 1623 vacmViewTreeFamilyStorageType anyValidStorageType anyValidStorageType 1624 vacmViewTreeFamilyStatus active active 1626 vacmViewTreeFamilyViewName "restricted" 1627 vacmViewTreeFamilySubtree 1.3.6.1.2.1.11 1628 vacmViewTreeFamilyMask "" 1629 vacmViewTreeFamilyType 1 (included) 1630 vacmViewTreeFamilyStorageType anyValidStorageType 1631 vacmViewTreeFamilyStatus active 1633 vacmViewTreeFamilyViewName "restricted" 1634 vacmViewTreeFamilySubtree 1.3.6.1.6.3.10.2.1 1635 vacmViewTreeFamilyMask "" 1636 vacmViewTreeFamilyType 1 (included) 1637 vacmViewTreeFamilyStorageType anyValidStorageType 1638 vacmViewTreeFamilyStatus active 1640 vacmViewTreeFamilyViewName "restricted" 1641 vacmViewTreeFamilySubtree 1.3.6.1.6.3.11.2.1 1642 vacmViewTreeFamilyMask "" 1643 vacmViewTreeFamilyType 1 (included) 1644 vacmViewTreeFamilyStorageType anyValidStorageType 1645 vacmViewTreeFamilyStatus active 1647 vacmViewTreeFamilyViewName "restricted" 1648 vacmViewTreeFamilySubtree 1.3.6.1.6.3.15.1.1 1649 vacmViewTreeFamilyMask "" 1650 vacmViewTreeFamilyType 1 (included) 1651 vacmViewTreeFamilyStorageType anyValidStorageType 1652 vacmViewTreeFamilyStatus active 1654 B. Change Log 1656 Changes made since RFC2275: 1658 - Added text to vacmSecurityToGroupStatus DESCRIPTION clause to 1659 clarify under which conditions an entry in the 1660 vacmSecurityToGroupTable can be made active. 1661 - Added REVISION clauses to MODULE-IDENTITY 1662 - Clarified text in vacmAccessTable DESCRIPTION clause. 1663 - Added a DEFVAL clause to vacmAccessContextMatch object. 1664 - Added missing columns in Appendix A and re-arranged for clarity. 1665 - Fixed oids in appendix A. 1666 - Use the PDU Class terminology instead of RFC1905 PDU types. 1667 - Added section 7.4 about access control to the MIB. 1668 - Fixed references to new/revised documents 1669 - Fix Editor contact information. 1670 - fixed spelling errors 1671 - removed one vacmAccesEntry from sample in appendix A. 1672 - made some more clarifications. 1673 - updated acknowledgement section. 1675 C. Full Copyright Statement 1677 Copyright (C) The Internet Society (1999). All Rights Reserved. 1679 This document and translations of it may be copied and furnished to 1680 others, and derivative works that comment on or otherwise explain it 1681 or assist in its implementation may be prepared, copied, published 1682 and distributed, in whole or in part, without restriction of any 1683 kind, provided that the above copyright notice and this paragraph are 1684 included on all such copies and derivative works. However, this 1685 document itself may not be modified in any way, such as by removing 1686 the copyright notice or references to the Internet Society or other 1687 Internet organizations, except as needed for the purpose of 1688 developing Internet standards in which case the procedures for 1689 copyrights defined in the Internet Standards process must be 1690 followed, or as required to translate it into languages other than 1691 English. 1693 The limited permissions granted above are perpetual and will not be 1694 revoked by the Internet Society or its successors or assigns. 1696 This document and the information contained herein is provided on an 1697 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1698 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1699 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1700 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1701 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.