idnits 2.17.1 draft-ietf-snmpv3-vacm-00.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 35 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 36 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 74 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** The abstract seems to contain references ([RFCxxx1]), 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 61 has weird spacing: '...verview of is...' == Line 329 has weird spacing: '...verview of is...' == Line 1483 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.) -- 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 1571, but not defined ** Obsolete undefined reference: RFC 1907 (Obsoleted by RFC 3418) == Unused Reference: 'RFC1902' is defined on line 1387, 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) ** Obsolete normative reference: RFC 2271 (ref. 'RFCxxx1') (Obsoleted by RFC 2571) ** Obsolete normative reference: RFC 2272 (ref. 'RFCxxx2') (Obsoleted by RFC 2572) ** Obsolete normative reference: RFC 2274 (ref. 'RFCxxx4') (Obsoleted by RFC 2574) Summary: 16 errors (**), 0 flaws (~~), 10 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 August 1998 | 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 | 30 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific | 31 Rim). 33 Copyright Notice 35 Copyright (C) The Internet Society (1998). All Rights Reserved. 37 Removed IANA note | 39 Abstract 41 This document describes the View-based Access Control Model for use 42 in the SNMP architecture [RFCxxx1]. It defines the Elements of 43 Procedure for controlling access to management information. This 44 document also includes a MIB for remotely managing the configuration 45 parameters for the View-based Access Control Model. 47 Table of Contents 49 1. Introduction 2 50 1.2. Access Control 3 51 1.3. Local Configuration Datastore 3 52 2. Elements of the Model 3 53 2.1. Groups 3 54 2.2. securityLevel 4 55 2.3. Contexts 4 56 2.4. MIB Views and View Families 4 57 2.4.1. View Subtree 5 58 2.4.2. ViewTreeFamily 5 59 2.5. Access Policy 6 60 3. Elements of Procedure 6 61 3.1. Overview of isAccessAllowed Process 8 62 3.2. Processing the isAccessAllowed Service Request 9 63 4. Definitions 10 64 5. Intellectual Property 26 65 6. Acknowledgements 27 66 7. Security Considerations 28 67 7.1. Recommended Practices 28 68 7.2. Defining Groups 29 69 7.3. Conformance 29 70 8. References 29 71 9. Editors' Addresses 30 72 A.1. Installation Parameters 31 73 B. Full Copyright Statement 36 75 1. Introduction 77 The Architecture for describing Internet Management Frameworks 78 [RFCxxx1] describes that an SNMP engine is composed of: 80 1) a Dispatcher 81 2) a Message Processing Subsystem, 82 3) a Security Subsystem, and 83 4) an Access Control Subsystem. 85 Applications make use of the services of these subsystems. 87 It is important to understand the SNMP architecture and its 88 terminology to understand where the View-based Access Control Model 89 described in this document fits into the architecture and interacts 90 with other subsystems within the architecture. The reader is 91 expected to have read and understood the description and terminology 92 of the SNMP architecture, as defined in [RFCxxx1]. 94 The Access Control Subsystem of an SNMP engine has the responsibility 95 for checking whether a specific type of access (read, write, notify) 96 to a particular object (instance) is allowed. 98 It is the purpose of this document to define a specific model of the 99 Access Control Subsystem, designated the View-based Access Control 100 Model. Note that this is not necessarily the only Access Control 101 Model. 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 105 document are to be interpreted as described in [RFC2119]. 107 1.2. Access Control 109 Access Control occurs (either implicitly or explicitly) in an SNMP 110 entity when processing SNMP retrieval or modification request 111 messages from an SNMP entity. For example a Command Responder 112 application applies Access Control when processing requests that it 113 received from a Command Generator application. These requests 114 include these types of operations: GetRequest, GetNextRequest, 115 GetBulkRequest, and SetRequest operations. 117 Access Control also occurs in an SNMP entity when an SNMP 118 notification message is generated (by a Notification Originator 119 application). These notification messages include these types of 120 operations: InformRequest and SNMPv2-Trap operations. 122 The View-based Access Control Model defines a set of services that an 123 application (such as a Command Responder or a Notification Originator 124 application) can use for checking access rights. It is the 125 responsibility of the application to make the proper service calls 126 for access checking. 128 1.3. Local Configuration Datastore 130 To implement the model described in this document, an SNMP entity 131 needs to retain information about access rights and policies. This 132 information is part of the SNMP engine's Local Configuration 133 Datastore (LCD). See [RFCxxx1] for the definition of LCD. 135 In order to allow an SNMP entity's LCD to be remotely configured, 136 portions of the LCD need to be accessible as managed objects. A MIB 137 module, the View-based Access Control Model Configuration MIB, which 138 defines these managed object types is included in this document. 140 2. Elements of the Model 142 This section contains definitions to realize the access control 143 service provided by the View-based Access Control Model. 145 2.1. Groups 146 A group is a set of zero or more tuples 147 on whose behalf SNMP management objects can be accessed. A group 148 defines the access rights afforded to all securityNames which belong 149 to that group. The combination of a securityModel and a securityName 150 maps to at most one group. A group is identified by a groupName. 152 The Access Control module assumes that the securityName has already 153 been authenticated as needed and provides no further authentication 154 of its own. 156 The View-based Access Control Model uses the securityModel and the 157 securityName as inputs to the Access Control module when called to 158 check for access rights. It determines the groupName as a function 159 of securityModel and securityName. 161 2.2. securityLevel 163 Different access rights for members of a group can be defined for 164 different levels of security, i.e., noAuthNoPriv, authNoPriv, and 165 authPriv. The securityLevel identifies the level of security that 166 will be assumed when checking for access rights. See the SNMP 167 Architecture document [RFCxxx1] for a definition of securityLevel. 169 The View-based Access Control Model requires that the securityLevel 170 is passed as input to the Access Control module when called to check 171 for access rights. 173 2.3. Contexts 175 An SNMP context is a collection of management information accessible 176 by an SNMP entity. An item of management information may exist in 177 more than one context. An SNMP entity potentially has access to many 178 contexts. Details about the naming of management information can be 179 found in the SNMP Architecture document [RFCxxx1]. 181 The View-based Access Control Model defines a vacmContextTable that 182 lists the locally available contexts by contextName. 184 2.4. MIB Views and View Families 186 For security reasons, it is often valuable to be able to restrict the 187 access rights of some groups to only a subset of the management 188 information in the management domain. To provide this capability, 189 access to a context is via a "MIB view" which details a specific set 190 of managed object types (and optionally, the specific instances of 191 object types) within that context. For example, for a given context, 192 there will typically always be one MIB view which provides access to 193 all management information in that context, and often there will be 194 other MIB views each of which contains some subset of the 195 information. So, the access allowed for a group can be restricted in 196 the desired manner by specifying its rights in terms of the 197 particular (subset) MIB view it can access within each appropriate 198 context. 200 Since managed object types (and their instances) are identified via 201 the tree-like naming structure of ISO's OBJECT IDENTIFIERs [ISO- 202 ASN.1, RFC1902], it is convenient to define a MIB view as the 203 combination of a set of "view subtrees", where each view subtree is a 204 subtree within the managed object naming tree. Thus, a simple MIB 205 view (e.g., all managed objects within the Internet Network 206 Management Framework) can be defined as a single view subtree, while 207 more complicated MIB views (e.g., all information relevant to a 208 particular network interface) can be represented by the union of 209 multiple view subtrees. 211 While any set of managed objects can be described by the union of 212 some number of view subtrees, situations can arise that would require 213 a very large number of view subtrees. This could happen, for 214 example, when specifying all columns in one conceptual row of a MIB 215 table because they would appear in separate subtrees, one per column, 216 each with a very similar format. Because the formats are similar, 217 the required set of subtrees can easily be aggregated into one 218 structure. This structure is named a family of view subtrees after 219 the set of subtrees that it conceptually represents. A family of 220 view subtrees can either be included or excluded from a MIB view. 222 2.4.1. View Subtree 224 A view subtree is the set of all MIB object instances which have a 225 common ASN.1 OBJECT IDENTIFIER prefix to their names. A view subtree 226 is identified by the OBJECT IDENTIFIER value which is the longest 227 OBJECT IDENTIFIER prefix common to all (potential) MIB object 228 instances in that subtree. 230 2.4.2. ViewTreeFamily 232 A family of view subtrees is a pairing of an OBJECT IDENTIFIER value 233 (called the family name) together with a bit string value (called the 234 family mask). The family mask indicates which sub-identifiers of the 235 associated family name are significant to the family's definition. 237 For each possible managed object instance, that instance belongs to a 238 particular ViewTreeFamily if both of the following conditions are 239 true: 241 - the OBJECT IDENTIFIER name of the managed object instance 242 contains at least as many sub-identifiers as does the family name, 243 and 245 - each sub-identifier in the OBJECT IDENTIFIER name of the managed 246 object instance matches the corresponding sub-identifier of the 247 family name whenever the corresponding bit of the associated family 248 mask is non-zero. 250 When the configured value of the family mask is all ones, the view 251 subtree family is identical to the single view subtree identified by 252 the family name. 254 When the configured value of the family mask is shorter than required 255 to perform the above test, its value is implicitly extended with 256 ones. Consequently, a view subtree family having a family mask of 257 zero length always corresponds to a single view subtree. 259 2.5. Access Policy 261 The View-based Access Control Model determines the access rights of a 262 group, representing zero or more securityNames which have the same 263 access rights. For a particular context, identified by contextName, 264 to which a group, identified by groupName, has access using a 265 particular securityModel and securityLevel, that group's access 266 rights are given by a read-view, a write-view and a notify-view. 268 The read-view represents the set of object instances authorized for 269 the group when reading objects. Reading objects occurs when 270 processing a retrieval (for example a GetRequest, GetNextRequest, 271 GetBulkRequest) operation. 273 The write-view represents the set of object instances authorized for 274 the group when writing objects. Writing objects occurs when 275 processing a write (for example a Set) operation. 277 The notify-view represents the set of object instances authorized for 278 the group when sending objects in a notification, such as when 279 sending a notification (for example an Inform or SNMPv2-Trap). 281 3. Elements of Procedure 283 This section describes the procedures followed by an Access Control 284 module that implements the View-based Access Control Model when 285 checking access rights as requested by an application (for example a 286 Command Responder or a Notification Originator application). The 287 abstract service primitive is: 289 statusInformation = -- success or errorIndication 290 isAccessAllowed( 291 securityModel -- Security Model in use 292 securityName -- principal who wants access 293 securityLevel -- Level of Security 294 viewType -- read, write, or notify view 295 contextName -- context containing variableName 296 variableName -- OID for the managed object 297 ) 299 The abstract data elements are: 301 statusInformation - one of the following: 302 accessAllowed - a MIB view was found and access is granted. 303 notInView - a MIB view was found but access is denied. 304 The variableName is not in the configured 305 MIB view for the specified viewType (e.g., in 306 the relevant entry in the vacmAccessTable). 307 noSuchView - no MIB view found because no view has been 308 configured for specified viewType (e.g., in 309 the relevant entry in the vacmAccessTable). 310 noSuchContext - no MIB view found because of no entry in the 311 vacmContextTable for specified contextName. 312 noGroupName - no MIB view found because no entry has been 313 configured in the vacmSecurityToGroupTable 314 for the specified combination of 315 securityModel and securityName. 316 noAccessEntry - no MIB view found because no entry has been 317 configured in the vacmAccessTable for the 318 specified combination of contextName, 319 groupName (from vacmSecurityToGroupTable), 320 securityModel and securityLevel. 321 otherError - failure, an undefined error occurred. 322 securityModel - Security Model under which access is requested. 323 securityName - the principal on whose behalf access is requested. 324 securityLevel - Level of Security under which access is requested. 325 viewType - view to be checked (read, write or notify). 326 contextName - context in which access is requested. 327 variableName - object instance to which access is requested. 329 3.1. Overview of isAccessAllowed Process 331 The following picture shows how the decision for access control is made 332 by the View-based Access Control Model. 334 +--------------------------------------------------------------------+ 335 | | 336 | +-> securityModel -+ | 337 | | (a) | | 338 | who -+ +-> groupName ----+ | 339 | (1) | | (x) | | 340 | +-> securityName --+ | | 341 | (b) | | 342 | | | 343 | where -> contextName ---------------------+ | 344 | (2) (e) | | 345 | | | 346 | | | 347 | +-> securityModel -------------------+ | 348 | | (a) | | 349 | how -+ +-> viewName -+ | 350 | (3) | | (y) | | 351 | +-> securityLevel -------------------+ | | 352 | (c) | +-> yes/no | 353 | | | decision | 354 | why ---> viewType (read/write/notify) ----+ | (z) | 355 | (4) (d) | | 356 | | | 357 | what --> object-type ------+ | | 358 | (5) (m) | | | 359 | +-> variableName (OID) ------+ | 360 | | (f) | 361 | which -> object-instance --+ | 362 | (6) (n) | 363 | | 364 +--------------------------------------------------------------------+ 366 How the decision for isAccessAllowed is made. 368 1) Inputs to the isAccessAllowed service are: 370 (a) securityModel -- Security Model in use 371 (b) securityName -- principal who wants to access 372 (c) securityLevel -- Level of Security 373 (d) viewType -- read, write, or notify view 374 (e) contextName -- context containing variableName 375 (f) variableName -- OID for the managed object 376 -- this is made up of: 378 - object-type (m) 379 - object-instance (n) 381 2) The partial "who" (1), represented by the securityModel (a) and 382 the securityName (b), are used as the indices (a,b) into the 383 vacmSecurityToGroupTable to find a single entry that produces a 384 group, represented by groupName (x). 386 3) The "where" (2), represented by the contextName (e), the "who", 387 represented by the groupName (x) from the previous step, and the 388 "how" (3), represented by securityModel (a) and securityLevel (c), 389 are used as indices (e,x,a,c) into the vacmAccessTable to find a 390 single entry that contains three MIB views. 392 4) The "why" (4), represented by the viewType (d), is used to select 393 the proper MIB view, represented by a viewName (y), from the 394 vacmAccessEntry selected in the previous step. This viewName (y) is 395 an index into the vacmViewTreeFamilyTable and selects the set of 396 entries that define the variableNames which are included in or 397 excluded from the MIB view identified by the viewName (y). 399 5) The "what" (5) type of management data and "which" (6) particular 400 instance, represented by the variableName (f), is then checked to be 401 in the MIB view or not, e.g., the yes/no decision (z). 403 3.2. Processing the isAccessAllowed Service Request 405 This section describes the procedure followed by an Access Control 406 module that implements the View-based Access Control Model whenever 407 it receives an isAccessAllowed request. 409 1) The vacmContextTable is consulted for information about 410 the SNMP context identified by the contextName. If information 411 about this SNMP context is absent from the table, then an 412 errorIndication (noSuchContext) is returned to the calling module. 414 2) The vacmSecurityToGroupTable is consulted for mapping the 415 securityModel and securityName to a groupName. If the information 416 about this combination is absent from the table, then an 417 errorIndication (noGroupName) is returned to the calling module. 419 3) The vacmAccessTable is consulted for information about the 420 groupName, contextName, securityModel and securityLevel. If 421 information about this combination is absent from the table, then 422 an errorIndication (noAccessEntry) is returned to the calling 423 module. 425 4) a) If the viewType is "read", then the read view is used for 426 checking access rights. 428 b) If the viewType is "write", then the write view is used for 429 checking access rights. 431 c) If the viewType is "notify", then the notify view is used 432 for checking access rights. 434 If the view to be used is the empty view (zero length viewName) 435 then an errorIndication (noSuchView) is returned to the calling 436 module. 438 5) a) If there is no view configured for the specified viewType, 439 then an errorIndication (noSuchView) is returned to the calling 440 module. 442 b) If the specified variableName (object instance) is not in the 443 MIB view (see DESCRIPTION clause for vacmViewTreeFamilyTable in 444 section 4), then an errorIndication (notInView) is returned to 445 the calling module. 447 Otherwise, 449 c) The specified variableName is in the MIB view. 450 A statusInformation of success (accessAllowed) is returned to 451 the calling module. 453 4. Definitions 455 SNMP-VIEW-BASED-ACM-MIB DEFINITIONS ::= BEGIN 457 IMPORTS 458 MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF 459 MODULE-IDENTITY, OBJECT-TYPE, 460 snmpModules FROM SNMPv2-SMI 461 TestAndIncr, 462 RowStatus, StorageType FROM SNMPv2-TC 463 SnmpAdminString, 464 SnmpSecurityLevel, 465 SnmpSecurityModel FROM SNMP-FRAMEWORK-MIB; 467 snmpVacmMIB MODULE-IDENTITY 468 LAST-UPDATED "9808010000Z" -- 01 Aug 1998, midnight 469 ORGANIZATION "SNMPv3 Working Group" 470 CONTACT-INFO "WG-email: snmpv3@tis.com 471 Subscribe: majordomo@tis.com 472 In message body: subscribe snmpv3 474 Chair: Russ Mundy 475 Trusted Information Systems 476 postal: 3060 Washington Rd 477 Glenwood MD 21738 478 USA 479 email: mundy@tis.com 480 phone: +1-301-854-6889 482 Co-editor: Bert Wijnen 483 IBM T.J. Watson Research 484 postal: Schagen 33 485 3461 GL Linschoten 486 Netherlands 487 email: wijnen@vnet.ibm.com 488 phone: +31-348-432-794 490 Co-editor: Randy Presuhn 491 BMC Software, Inc 492 postal: 1190 Saratoga Avenue, Suite 130 493 San Jose, CA 95129-3433 494 USA 495 email: rpresuhn@bmc.com 496 phone: +1-408-556-0720 498 Co-editor: Keith McCloghrie 499 Cisco Systems, Inc. 500 postal: 170 West Tasman Drive 501 San Jose, CA 95134-1706 502 USA 503 email: kzm@cisco.com 504 phone: +1-408-526-5260 505 " 506 DESCRIPTION "The management information definitions for the 507 View-based Access Control Model for SNMP. 508 " 509 -- Revision history 510 REVISION "9808010000Z" -- 01 Aug 1998, midnight 511 DESCRIPTION "Clarifications, published as RFCxxx5" 513 REVISION "9711200000Z" -- 20 Nov 1997, midnight 514 DESCRIPTION "Initial version, published as RFC2275" 516 ::= { snmpModules 16 } 518 -- Administrative assignments **************************************** 520 vacmMIBObjects OBJECT IDENTIFIER ::= { snmpVacmMIB 1 } 521 vacmMIBConformance OBJECT IDENTIFIER ::= { snmpVacmMIB 2 } 523 -- Information about Local Contexts ********************************** 525 vacmContextTable OBJECT-TYPE 526 SYNTAX SEQUENCE OF VacmContextEntry 527 MAX-ACCESS not-accessible 528 STATUS current 529 DESCRIPTION "The table of locally available contexts. 531 This table provides information to SNMP Command 532 Generator applications so that they can properly 533 configure the vacmAccessTable to control access to 534 all contexts at the SNMP entity. 536 This table may change dynamically if the SNMP entity 537 allows that contexts are added/deleted dynamically 538 (for instance when its configuration changes). Such 539 changes would happen only if the management 540 instrumentation at that SNMP entity recognizes more 541 (or fewer) contexts. 543 The presence of entries in this table and of entries 544 in the vacmAccessTable are independent. That is, a 545 context identified by an entry in this table is not 546 necessarily referenced by any entries in the 547 vacmAccessTable; and the context(s) referenced by an 548 entry in the vacmAccessTable does not necessarily 549 currently exist and thus need not be identified by an 550 entry in this table. 552 This table must be made accessible via the default 553 context so that Command Responder applications have 554 a standard way of retrieving the information. 556 This table is read-only. It cannot be configured via 557 SNMP. 558 " 559 ::= { vacmMIBObjects 1 } 561 vacmContextEntry OBJECT-TYPE 562 SYNTAX VacmContextEntry 563 MAX-ACCESS not-accessible 564 STATUS current 565 DESCRIPTION "Information about a particular context." 566 INDEX { 567 vacmContextName 568 } 570 ::= { vacmContextTable 1 } 572 VacmContextEntry ::= SEQUENCE 573 { 574 vacmContextName SnmpAdminString 575 } 577 vacmContextName OBJECT-TYPE 578 SYNTAX SnmpAdminString (SIZE(0..32)) 579 MAX-ACCESS read-only 580 STATUS current 581 DESCRIPTION "A human readable name identifying a particular 582 context at a particular SNMP entity. 584 The empty contextName (zero length) represents the 585 default context. 586 " 587 ::= { vacmContextEntry 1 } 589 -- Information about Groups ****************************************** 591 vacmSecurityToGroupTable OBJECT-TYPE 592 SYNTAX SEQUENCE OF VacmSecurityToGroupEntry 593 MAX-ACCESS not-accessible 594 STATUS current 595 DESCRIPTION "This table maps a combination of securityModel and 596 securityName into a groupName which is used to define 597 an access control policy for a group of principals. 598 " 599 ::= { vacmMIBObjects 2 } 601 vacmSecurityToGroupEntry OBJECT-TYPE 602 SYNTAX VacmSecurityToGroupEntry 603 MAX-ACCESS not-accessible 604 STATUS current 605 DESCRIPTION "An entry in this table maps the combination of a 606 securityModel and securityName into a groupName. 607 " 608 INDEX { 609 vacmSecurityModel, 610 vacmSecurityName 611 } 612 ::= { vacmSecurityToGroupTable 1 } 614 VacmSecurityToGroupEntry ::= SEQUENCE 615 { 616 vacmSecurityModel SnmpSecurityModel, 617 vacmSecurityName SnmpAdminString, 618 vacmGroupName SnmpAdminString, 619 vacmSecurityToGroupStorageType StorageType, 620 vacmSecurityToGroupStatus RowStatus 621 } 623 vacmSecurityModel OBJECT-TYPE 624 SYNTAX SnmpSecurityModel(1..2147483647) 625 MAX-ACCESS not-accessible 626 STATUS current 627 DESCRIPTION "The Security Model, by which the vacmSecurityName 628 referenced by this entry is provided. 630 Note, this object may not take the 'any' (0) value. 631 " 632 ::= { vacmSecurityToGroupEntry 1 } 634 vacmSecurityName OBJECT-TYPE 635 SYNTAX SnmpAdminString (SIZE(1..32)) 636 MAX-ACCESS not-accessible 637 STATUS current 638 DESCRIPTION "The securityName for the principal, represented in a 639 Security Model independent format, which is mapped by 640 this entry to a groupName. 642 The securityName for a principal represented in a 643 Security Model independent format. 644 " 645 ::= { vacmSecurityToGroupEntry 2 } 647 vacmGroupName OBJECT-TYPE 648 SYNTAX SnmpAdminString (SIZE(1..32)) 649 MAX-ACCESS read-create 650 STATUS current 651 DESCRIPTION "The name of the group to which this entry (e.g., the 652 combination of securityModel and securityName) 653 belongs. 655 This groupName is used as index into the 656 vacmAccessTable to select an access control policy. 657 " 658 ::= { vacmSecurityToGroupEntry 3 } 660 vacmSecurityToGroupStorageType OBJECT-TYPE 661 SYNTAX StorageType 662 MAX-ACCESS read-create 663 STATUS current 664 DESCRIPTION "The storage type for this conceptual row. 665 Conceptual rows having the value 'permanent' need not 666 allow write-access to any columnar objects in the row. 667 " 668 DEFVAL { nonVolatile } 669 ::= { vacmSecurityToGroupEntry 4 } 671 vacmSecurityToGroupStatus OBJECT-TYPE 672 SYNTAX RowStatus 673 MAX-ACCESS read-create 674 STATUS current 675 DESCRIPTION "The status of this conceptual row. 677 The RowStatus TC [RFC1903] requires that this 678 DESCRIPTION clause states under which circumstances 679 other objects in this row can be modified: 681 The value of this object has no effect on whether 682 other objects in this conceptual row can be modified. 683 " 684 ::= { vacmSecurityToGroupEntry 5 } 686 -- Information about Access Rights *********************************** 688 vacmAccessTable OBJECT-TYPE 689 SYNTAX SEQUENCE OF VacmAccessEntry 690 MAX-ACCESS not-accessible 691 STATUS current 692 DESCRIPTION "The table of access rights for groups. 694 Each entry is indexed by a contextPrefix, a groupName 695 a securityModel and a securityLevel. To determine 696 whether access is allowed, one entry from this table 697 needs to be selected and the proper viewName from that 698 entry must be used for access control checking. 700 To select the proper entry, follow these steps: 702 1) the set of possible matches is formed by the 703 intersection of the following sets of entries: 704 the set of entries with identical vacmGroupName 705 the union of these two sets: 706 - the set with identical vacmAccessContextPrefix 707 - the set of entries with vacmAccessContextMatch 708 value of 'prefix' and matching 709 vacmAccessContextPrefix 710 intersected with the union of these two sets: 711 - the set of entries with identical 712 vacmSecurityModel 713 - the set of entries with vacmSecurityModel 714 value of 'any' 715 intersected with the set of entries with 716 vacmAccessSecurityLevel value less than or equal 717 to the requested securityLevel 719 2) if this set has only one member, we're done 720 otherwise, it comes down to deciding how to weight 721 the preferences between ContextPrefixes, 722 SecurityModels, and SecurityLevels as follows: 723 a) if the subset of entries with securityModel | 724 matching the securityModel in the message is | 725 not empty, then discard the rest. | 726 b) if the subset of entries with | 727 vacmAccessContextPrefix matching the contextName | 728 in the message is not empty, | 729 then discard the rest | 730 c) discard all entries with ContextPrefixes shorter 731 than the longest one remaining in the set 732 d) select the entry with the highest securityLevel 734 Please note that for securityLevel noAuthNoPriv, all 735 groups are really equivalent since the assumption that 736 the securityName has been authenticated does not hold. 737 " 738 ::= { vacmMIBObjects 4 } 740 vacmAccessEntry OBJECT-TYPE 741 SYNTAX VacmAccessEntry 742 MAX-ACCESS not-accessible 743 STATUS current 744 DESCRIPTION "An access right configured in the Local Configuration 745 Datastore (LCD) authorizing access to an SNMP context. 746 " 747 INDEX { vacmGroupName, 748 vacmAccessContextPrefix, 749 vacmAccessSecurityModel, 750 vacmAccessSecurityLevel 751 } 752 ::= { vacmAccessTable 1 } 754 VacmAccessEntry ::= SEQUENCE 755 { 756 vacmAccessContextPrefix SnmpAdminString, 757 vacmAccessSecurityModel SnmpSecurityModel, 758 vacmAccessSecurityLevel SnmpSecurityLevel, 759 vacmAccessContextMatch INTEGER, 760 vacmAccessReadViewName SnmpAdminString, 761 vacmAccessWriteViewName SnmpAdminString, 762 vacmAccessNotifyViewName SnmpAdminString, 763 vacmAccessStorageType StorageType, 764 vacmAccessStatus RowStatus 765 } 767 vacmAccessContextPrefix OBJECT-TYPE 768 SYNTAX SnmpAdminString (SIZE(0..32)) 769 MAX-ACCESS not-accessible 770 STATUS current 771 DESCRIPTION "In order to gain the access rights allowed by this 772 conceptual row, a contextName must match exactly 773 (if the value of vacmAccessContextMatch is 'exact') 774 or partially (if the value of vacmAccessContextMatch 775 is 'prefix') to the value of the instance of this 776 object. 777 " 778 ::= { vacmAccessEntry 1 } 780 vacmAccessSecurityModel OBJECT-TYPE 781 SYNTAX SnmpSecurityModel 782 MAX-ACCESS not-accessible 783 STATUS current 784 DESCRIPTION "In order to gain the access rights allowed by this 785 conceptual row, this securityModel must be in use. 786 " 787 ::= { vacmAccessEntry 2 } 789 vacmAccessSecurityLevel OBJECT-TYPE 790 SYNTAX SnmpSecurityLevel 791 MAX-ACCESS not-accessible 792 STATUS current 793 DESCRIPTION "The minimum level of security required in order to 794 gain the access rights allowed by this conceptual 795 row. A securityLevel of noAuthNoPriv is less than 796 authNoPriv which in turn is less than authPriv. 798 If multiple entries are equally indexed except for 799 this vacmAccessSecurityLevel index, then the entry 800 which has the highest value for 801 vacmAccessSecurityLevel wins. 802 " 803 ::= { vacmAccessEntry 3 } 805 vacmAccessContextMatch OBJECT-TYPE 806 SYNTAX INTEGER 807 { exact (1), -- exact match of prefix and contextName 808 prefix (2) -- Only match to the prefix 809 } 811 MAX-ACCESS read-create 812 STATUS current 813 DESCRIPTION "If the value of this object is exact(1), then all 814 rows where the contextName exactly matches 815 vacmAccessContextPrefix are selected. 817 If the value of this object is prefix(2), then all 818 rows where the contextName whose starting octets 819 exactly match vacmAccessContextPrefix are selected. 820 This allows for a simple form of wildcarding. 821 See also the example in the DESCRIPTION clause of 822 the vacmAccessTable above. 823 " 824 DEFVAL { exact } | 825 ::= { vacmAccessEntry 4 } 827 vacmAccessReadViewName OBJECT-TYPE 828 SYNTAX SnmpAdminString (SIZE(0..32)) 829 MAX-ACCESS read-create 830 STATUS current 831 DESCRIPTION "The value of an instance of this object identifies 832 the MIB view of the SNMP context to which this 833 conceptual row authorizes read access. 835 The identified MIB view is that one for which the 836 vacmViewTreeFamilyViewName has the same value as the 837 instance of this object; if the value is the empty 838 string or if there is no active MIB view having this 839 value of vacmViewTreeFamilyViewName, then no access 840 is granted. 841 " 842 DEFVAL { ''H } -- the empty string 843 ::= { vacmAccessEntry 5 } 845 vacmAccessWriteViewName OBJECT-TYPE 846 SYNTAX SnmpAdminString (SIZE(0..32)) 847 MAX-ACCESS read-create 848 STATUS current 849 DESCRIPTION "The value of an instance of this object identifies 850 the MIB view of the SNMP context to which this 851 conceptual row authorizes write access. 853 The identified MIB view is that one for which the 854 vacmViewTreeFamilyViewName has the same value as the 855 instance of this object; if the value is the empty 856 string or if there is no active MIB view having this 857 value of vacmViewTreeFamilyViewName, then no access 858 is granted. 860 " 861 DEFVAL { ''H } -- the empty string 862 ::= { vacmAccessEntry 6 } 864 vacmAccessNotifyViewName OBJECT-TYPE 865 SYNTAX SnmpAdminString (SIZE(0..32)) 866 MAX-ACCESS read-create 867 STATUS current 868 DESCRIPTION "The value of an instance of this object identifies 869 the MIB view of the SNMP context to which this 870 conceptual row authorizes access for notifications. 872 The identified MIB view is that one for which the 873 vacmViewTreeFamilyViewName has the same value as the 874 instance of this object; if the value is the empty 875 string or if there is no active MIB view having this 876 value of vacmViewTreeFamilyViewName, then no access 877 is granted. 878 " 879 DEFVAL { ''H } -- the empty string 880 ::= { vacmAccessEntry 7 } 882 vacmAccessStorageType OBJECT-TYPE 883 SYNTAX StorageType 884 MAX-ACCESS read-create 885 STATUS current 886 DESCRIPTION "The storage type for this conceptual row. 888 Conceptual rows having the value 'permanent' need not 889 allow write-access to any columnar objects in the row. 890 " 891 DEFVAL { nonVolatile } 892 ::= { vacmAccessEntry 8 } 894 vacmAccessStatus OBJECT-TYPE 895 SYNTAX RowStatus 896 MAX-ACCESS read-create 897 STATUS current 898 DESCRIPTION "The status of this conceptual row. 900 The RowStatus TC [RFC1903] requires that this 901 DESCRIPTION clause states under which circumstances 902 other objects in this row can be modified: 904 The value of this object has no effect on whether 905 other objects in this conceptual row can be modified. 906 " 907 ::= { vacmAccessEntry 9 } 909 -- Information about MIB views *************************************** 911 -- Support for instance-level granularity is optional. 912 -- 913 -- In some implementations, instance-level access control 914 -- granularity may come at a high performance cost. Managers 915 -- should avoid requesting such configurations unnecessarily. 917 vacmMIBViews OBJECT IDENTIFIER ::= { vacmMIBObjects 5 } 919 vacmViewSpinLock OBJECT-TYPE 920 SYNTAX TestAndIncr 921 MAX-ACCESS read-write 922 STATUS current 923 DESCRIPTION "An advisory lock used to allow cooperating SNMP 924 Command Generator applications to coordinate their 925 use of the Set operation in creating or modifying 926 views. 928 When creating a new view or altering an existing 929 view, it is important to understand the potential 930 interactions with other uses of the view. The 931 vacmViewSpinLock should be retrieved. The name of 932 the view to be created should be determined to be 933 unique by the SNMP Command Generator application by 934 consulting the vacmViewTreeFamilyTable. Finally, 935 the named view may be created (Set), including the 936 advisory lock. 937 If another SNMP Command Generator application has 938 altered the views in the meantime, then the spin 939 lock's value will have changed, and so this creation 940 will fail because it will specify the wrong value for 941 the spin lock. 943 Since this is an advisory lock, the use of this lock 944 is not enforced. 945 " 946 ::= { vacmMIBViews 1 } 948 vacmViewTreeFamilyTable OBJECT-TYPE 949 SYNTAX SEQUENCE OF VacmViewTreeFamilyEntry 950 MAX-ACCESS not-accessible 951 STATUS current 952 DESCRIPTION "Locally held information about families of subtrees 953 within MIB views. 955 Each MIB view is defined by two sets of view subtrees: 957 - the included view subtrees, and 958 - the excluded view subtrees. 959 Every such view subtree, both the included and the 960 excluded ones, is defined in this table. 962 To determine if a particular object instance is in 963 a particular MIB view, compare the object instance's 964 OBJECT IDENTIFIER with each of the MIB view's active 965 entries in this table. If none match, then the 966 object instance is not in the MIB view. If one or 967 more match, then the object instance is included in, 968 or excluded from, the MIB view according to the 969 value of vacmViewTreeFamilyType in the entry whose 970 value of vacmViewTreeFamilySubtree has the most 971 sub-identifiers. If multiple entries match and have 972 the same number of sub-identifiers, then the 973 lexicographically greatest instance of 974 vacmViewTreeFamilyType determines the inclusion or 975 exclusion. 977 An object instance's OBJECT IDENTIFIER X matches an 978 active entry in this table when the number of 979 sub-identifiers in X is at least as many as in the 980 value of vacmViewTreeFamilySubtree for the entry, 981 and each sub-identifier in the value of 982 vacmViewTreeFamilySubtree matches its corresponding 983 sub-identifier in X. Two sub-identifiers match 984 either if the corresponding bit of the value of 985 vacmViewTreeFamilyMask for the entry is zero (the 986 'wild card' value), or if they are equal. 988 A 'family' of subtrees is the set of subtrees defined 989 by a particular combination of values of 990 vacmViewTreeFamilySubtree and vacmViewTreeFamilyMask. 991 In the case where no 'wild card' is defined in the 992 vacmViewTreeFamilyMask, the family of subtrees reduces 993 to a single subtree. 995 When creating or changing MIB views, an SNMP Command 996 Generator application should utilize the 997 vacmViewSpinLock to try to avoid collisions. See 998 DESCRIPTION clause of vacmViewSpinLock. 1000 When creating MIB views, it is strongly advised that 1001 first the 'excluded' vacmViewTreeFamilyEntries are 1002 created and then the 'included' entries. 1004 When deleting MIB views, it is strongly advised that 1005 first the 'included' vacmViewTreeFamilyEntries are 1006 deleted and then the 'excluded' entries. 1008 If a create for an entry for instance-level access 1009 control is received and the implementation does not 1010 support instance-level granularity, then an 1011 inconsistentName error must be returned. 1012 " 1013 ::= { vacmMIBViews 2 } 1015 vacmViewTreeFamilyEntry OBJECT-TYPE 1016 SYNTAX VacmViewTreeFamilyEntry 1017 MAX-ACCESS not-accessible 1018 STATUS current 1019 DESCRIPTION "Information on a particular family of view subtrees 1020 included in or excluded from a particular SNMP 1021 context's MIB view. 1023 Implementations must not restrict the number of 1024 families of view subtrees for a given MIB view, 1025 except as dictated by resource constraints on the 1026 overall number of entries in the 1027 vacmViewTreeFamilyTable. 1029 If no conceptual rows exist in this table for a given 1030 MIB view (viewName), that view may be thought of as 1031 consisting of the empty set of view subtrees. 1032 " 1033 INDEX { vacmViewTreeFamilyViewName, 1034 vacmViewTreeFamilySubtree 1035 } 1036 ::= { vacmViewTreeFamilyTable 1 } 1038 VacmViewTreeFamilyEntry ::= SEQUENCE 1039 { 1040 vacmViewTreeFamilyViewName SnmpAdminString, 1041 vacmViewTreeFamilySubtree OBJECT IDENTIFIER, 1042 vacmViewTreeFamilyMask OCTET STRING, 1043 vacmViewTreeFamilyType INTEGER, 1044 vacmViewTreeFamilyStorageType StorageType, 1045 vacmViewTreeFamilyStatus RowStatus 1046 } 1048 vacmViewTreeFamilyViewName OBJECT-TYPE 1049 SYNTAX SnmpAdminString (SIZE(1..32)) 1050 MAX-ACCESS not-accessible 1051 STATUS current 1052 DESCRIPTION "The human readable name for a family of view subtrees. 1054 " 1055 ::= { vacmViewTreeFamilyEntry 1 } 1057 vacmViewTreeFamilySubtree OBJECT-TYPE 1058 SYNTAX OBJECT IDENTIFIER 1059 MAX-ACCESS not-accessible 1060 STATUS current 1061 DESCRIPTION "The MIB subtree which when combined with the 1062 corresponding instance of vacmViewTreeFamilyMask 1063 defines a family of view subtrees. 1064 " 1065 ::= { vacmViewTreeFamilyEntry 2 } 1067 vacmViewTreeFamilyMask OBJECT-TYPE 1068 SYNTAX OCTET STRING (SIZE (0..16)) 1069 MAX-ACCESS read-create 1070 STATUS current 1071 DESCRIPTION "The bit mask which, in combination with the 1072 corresponding instance of vacmViewTreeFamilySubtree, 1073 defines a family of view subtrees. 1075 Each bit of this bit mask corresponds to a 1076 sub-identifier of vacmViewTreeFamilySubtree, with the 1077 most significant bit of the i-th octet of this octet 1078 string value (extended if necessary, see below) 1079 corresponding to the (8*i - 7)-th sub-identifier, and 1080 the least significant bit of the i-th octet of this 1081 octet string corresponding to the (8*i)-th 1082 sub-identifier, where i is in the range 1 through 16. 1084 Each bit of this bit mask specifies whether or not 1085 the corresponding sub-identifiers must match when 1086 determining if an OBJECT IDENTIFIER is in this 1087 family of view subtrees; a '1' indicates that an 1088 exact match must occur; a '0' indicates 'wild card', 1089 i.e., any sub-identifier value matches. 1091 Thus, the OBJECT IDENTIFIER X of an object instance 1092 is contained in a family of view subtrees if, for 1093 each sub-identifier of the value of 1094 vacmViewTreeFamilySubtree, either: 1096 the i-th bit of vacmViewTreeFamilyMask is 0, or 1098 the i-th sub-identifier of X is equal to the i-th 1099 sub-identifier of the value of 1100 vacmViewTreeFamilySubtree. 1102 If the value of this bit mask is M bits long and 1103 there are more than M sub-identifiers in the 1104 corresponding instance of vacmViewTreeFamilySubtree, 1105 then the bit mask is extended with 1's to be the 1106 required length. 1108 Note that when the value of this object is the 1109 zero-length string, this extension rule results in 1110 a mask of all-1's being used (i.e., no 'wild card'), 1111 and the family of view subtrees is the one view 1112 subtree uniquely identified by the corresponding 1113 instance of vacmViewTreeFamilySubtree. 1115 Note that masks of length greater than zero length 1116 do not need to be supported. In this case this 1117 object is made read-only. 1118 " 1119 DEFVAL { ''H } 1120 ::= { vacmViewTreeFamilyEntry 3 } 1122 vacmViewTreeFamilyType OBJECT-TYPE 1123 SYNTAX INTEGER { included(1), excluded(2) } 1124 MAX-ACCESS read-create 1125 STATUS current 1126 DESCRIPTION "Indicates whether the corresponding instances of 1127 vacmViewTreeFamilySubtree and vacmViewTreeFamilyMask 1128 define a family of view subtrees which is included in 1129 or excluded from the MIB view. 1130 " 1131 DEFVAL { included } 1132 ::= { vacmViewTreeFamilyEntry 4 } 1134 vacmViewTreeFamilyStorageType OBJECT-TYPE 1135 SYNTAX StorageType 1136 MAX-ACCESS read-create 1137 STATUS current 1138 DESCRIPTION "The storage type for this conceptual row. 1140 Conceptual rows having the value 'permanent' need not 1141 allow write-access to any columnar objects in the row. 1142 " 1143 DEFVAL { nonVolatile } 1144 ::= { vacmViewTreeFamilyEntry 5 } 1146 vacmViewTreeFamilyStatus OBJECT-TYPE 1147 SYNTAX RowStatus 1148 MAX-ACCESS read-create 1149 STATUS current 1150 DESCRIPTION "The status of this conceptual row. 1152 The RowStatus TC [RFC1903] requires that this 1153 DESCRIPTION clause states under which circumstances 1154 other objects in this row can be modified: 1156 The value of this object has no effect on whether 1157 other objects in this conceptual row can be modified. 1158 " 1159 ::= { vacmViewTreeFamilyEntry 6 } 1161 -- Conformance information ******************************************* 1163 vacmMIBCompliances OBJECT IDENTIFIER ::= { vacmMIBConformance 1 } 1164 vacmMIBGroups OBJECT IDENTIFIER ::= { vacmMIBConformance 2 } 1166 -- Compliance statements ********************************************* 1168 vacmMIBCompliance MODULE-COMPLIANCE 1169 STATUS current 1170 DESCRIPTION "The compliance statement for SNMP engines which 1171 implement the SNMP View-based Access Control Model 1172 configuration MIB. 1173 " 1174 MODULE -- this module 1175 MANDATORY-GROUPS { vacmBasicGroup } 1177 OBJECT vacmAccessContextMatch 1178 MIN-ACCESS read-only 1179 DESCRIPTION "Write access is not required." 1180 OBJECT vacmAccessReadViewName 1181 MIN-ACCESS read-only 1182 DESCRIPTION "Write access is not required." 1184 OBJECT vacmAccessWriteViewName 1185 MIN-ACCESS read-only 1186 DESCRIPTION "Write access is not required." 1188 OBJECT vacmAccessNotifyViewName 1189 MIN-ACCESS read-only 1190 DESCRIPTION "Write access is not required." 1192 OBJECT vacmAccessStorageType 1193 MIN-ACCESS read-only 1194 DESCRIPTION "Write access is not required." 1196 OBJECT vacmAccessStatus 1197 MIN-ACCESS read-only 1198 DESCRIPTION "Create/delete/modify access to the 1199 vacmAccessTable is not required. 1200 " 1202 OBJECT vacmViewTreeFamilyMask 1203 WRITE-SYNTAX OCTET STRING (SIZE (0)) 1204 MIN-ACCESS read-only 1205 DESCRIPTION "Support for configuration via SNMP of subtree 1206 families using wild-cards is not required. 1207 " 1209 OBJECT vacmViewTreeFamilyType 1210 MIN-ACCESS read-only 1211 DESCRIPTION "Write access is not required." 1213 OBJECT vacmViewTreeFamilyStorageType 1214 MIN-ACCESS read-only 1215 DESCRIPTION "Write access is not required." 1217 OBJECT vacmViewTreeFamilyStatus 1218 MIN-ACCESS read-only 1219 DESCRIPTION "Create/delete/modify access to the 1220 vacmViewTreeFamilyTable is not required. 1221 " 1222 ::= { vacmMIBCompliances 1 } 1224 -- Units of conformance ********************************************** 1226 vacmBasicGroup OBJECT-GROUP 1227 OBJECTS { 1228 vacmContextName, 1229 vacmGroupName, 1230 vacmSecurityToGroupStorageType, 1231 vacmSecurityToGroupStatus, 1232 vacmAccessContextMatch, 1233 vacmAccessReadViewName, 1234 vacmAccessWriteViewName, 1235 vacmAccessNotifyViewName, 1236 vacmAccessStorageType, 1237 vacmAccessStatus, 1238 vacmViewSpinLock, 1239 vacmViewTreeFamilyMask, 1240 vacmViewTreeFamilyType, 1241 vacmViewTreeFamilyStorageType, 1242 vacmViewTreeFamilyStatus 1243 } 1244 STATUS current 1245 DESCRIPTION "A collection of objects providing for remote 1246 configuration of an SNMP engine which implements 1247 the SNMP View-based Access Control Model. 1248 " 1249 ::= { vacmMIBGroups 1 } 1251 END 1253 5. Intellectual Property 1255 The IETF takes no position regarding the validity or scope of any 1256 intellectual property or other rights that might be claimed to 1257 pertain to the implementation or use of the technology described in 1258 this document or the extent to which any license under such rights 1259 might or might not be available; neither does it represent that it 1260 has made any effort to identify any such rights. Information on the 1261 IETF's procedures with respect to rights in standards-track and 1262 standards-related documentation can be found in BCP-11. Copies of 1263 claims of rights made available for publication and any assurances of 1264 licenses to be made available, or the result of an attempt made to 1265 obtain a general license or permission for the use of such 1266 proprietary rights by implementors or users of this specification can 1267 be obtained from the IETF Secretariat. 1269 The IETF invites any interested party to bring to its attention any 1270 copyrights, patents or patent applications, or other proprietary 1271 rights which may cover technology that may be required to practice 1272 this standard. Please address the information to the IETF Executive 1273 Director. 1275 6. Acknowledgements 1277 This document is the result of the efforts of the SNMPv3 Working 1278 Group. Some special thanks are in order to the following SNMPv3 WG 1279 members: 1281 Dave Battle (SNMP Research, Inc.) 1282 Uri Blumenthal (IBM T.J. Watson Research Center) 1283 Jeff Case (SNMP Research, Inc.) 1284 John Curran (BBN) 1285 T. Max Devlin (Hi-TECH Connections) 1286 John Flick (Hewlett Packard) 1287 David Harrington (Cabletron Systems Inc.) 1288 N.C. Hien (IBM T.J. Watson Research Center) 1289 Dave Levi (SNMP Research, Inc.) 1290 Louis A Mamakos (UUNET Technologies Inc.) 1291 Paul Meyer (Secure Computing Corporation) 1292 Keith McCloghrie (Cisco Systems) 1293 Russ Mundy (Trusted Information Systems, Inc.) 1294 Bob Natale (ACE*COMM Corporation) 1295 Mike O'Dell (UUNET Technologies Inc.) 1296 Dave Perkins (DeskTalk) 1297 Peter Polkinghorne (Brunel University) 1298 Randy Presuhn (BMC Software, Inc.) 1299 David Reid (SNMP Research, Inc.) 1300 Shawn Routhier (Epilogue) 1301 Juergen Schoenwaelder (TU Braunschweig) 1302 Bob Stewart (Cisco Systems) 1303 Bert Wijnen (IBM T.J. Watson Research Center) 1304 The document is based on recommendations of the IETF Security and 1305 Administrative Framework Evolution for SNMP Advisory Team. Members 1306 of that Advisory Team were: 1308 David Harrington (Cabletron Systems Inc.) 1309 Jeff Johnson (Cisco Systems) 1310 David Levi (SNMP Research Inc.) 1311 John Linn (Openvision) 1312 Russ Mundy (Trusted Information Systems) chair 1313 Shawn Routhier (Epilogue) 1314 Glenn Waters (Nortel) 1315 Bert Wijnen (IBM T. J. Watson Research Center) 1317 As recommended by the Advisory Team and the SNMPv3 Working Group 1318 Charter, the design incorporates as much as practical from previous 1319 RFCs and drafts. As a result, special thanks are due to the authors 1320 of previous designs known as SNMPv2u and SNMPv2*: 1322 Jeff Case (SNMP Research, Inc.) 1323 David Harrington (Cabletron Systems Inc.) 1324 David Levi (SNMP Research, Inc.) 1325 Keith McCloghrie (Cisco Systems) 1326 Brian O'Keefe (Hewlett Packard) 1327 Marshall T. Rose (Dover Beach Consulting) 1328 Jon Saperia (BGS Systems Inc.) 1329 Steve Waldbusser (International Network Services) 1330 Glenn W. Waters (Bell-Northern Research Ltd.) 1332 7. Security Considerations 1334 7.1. Recommended Practices 1336 This document is meant for use in the SNMP architecture. The View- 1337 based Access Control Model described in this document checks access 1338 rights to management information based on: 1340 - contextName, representing a set of management information at the 1341 managed system where the Access Control module is running. 1342 - groupName, representing a set of zero or more securityNames. 1343 The combination of a securityModel and a securityName is mapped 1344 into a group in the View-based Access Control Model. 1345 - securityModel under which access is requested. 1346 - securityLevel under which access is requested. 1347 - operation performed on the management information. 1348 - MIB views for read, write or notify access. 1350 When the User-based Access Control module is called for checking 1351 access rights, it is assumed that the calling module has ensured the 1352 authentication and privacy aspects as specified by the securityLevel 1353 that is being passed. 1355 When creating entries in or deleting entries from the | 1356 vacmViewFamilyTreeTable it is important to do such in the sequence as | 1357 recommended in the DESCRIPTION clause of the vacmViewFamilyTable 1358 definition. Otherwise unwanted access may be granted while changing 1359 the entries in the table. 1361 7.2. Defining Groups 1363 The groupNames are used to give access to a group of zero or more 1364 securityNames. Within the View-Based Access Control Model, a 1365 groupName is considered to exist if that groupName is listed in the 1366 vacmSecurityToGroupTable. 1368 By mapping the combination of a securityModel and securityName into a 1369 groupName, an SNMP Command Generator application can add/delete 1370 securityNames to/from a group, if proper access is allowed. 1372 Further it is important to realize that the grouping of 1373 tuples in the vacmSecurityToGroupTable 1374 does not take securityLevel into account. It is therefore important 1375 that the security administrator uses the securityLevel index in the 1376 vacmAccessTable to separate noAuthNoPriv from authPriv and/or 1377 authNoPriv access. 1379 7.3. Conformance 1381 For an implementation of the View-based Access Control Model to be 1382 conformant, it MUST implement the SNMP-VIEW-BASED-ACM-MIB. It also 1383 SHOULD implement the initial configuration, described in appendix A. 1385 8. References 1387 [RFC1902] Case, J., McCloghrie, K., Rose, M. and S., Waldbusser, 1388 "Structure of Management Information for Version 2 of the 1389 Simple Network Management Protocol (SNMPv2)", RFC 1902, January 1390 1996. 1392 [RFC1903] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, 1393 "Textual Conventions for Version 2 of the Simple Network 1394 Management Protocol (SNMPv2)", RFC 1903, January 1996. 1396 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1397 Requirement Levels", BCP 14, RFC 2119, March 1997. 1399 [RFCxxx1] Harrington, D., Presuhn, R., and B. Wijnen, 1400 "An Architecture for describing SNMP Management Frameworks", RFC 1401 2271, January 1998. 1403 [RFCxxx2] Case, J., Harrington, D., Presuhn, R., and B. Wijnen, 1404 "Message Processing and Dispatching for the Simple Network 1405 Management Protocol (SNMP)", RFC 2272, January 1998. 1407 [RFCxxx4] Blumenthal, U., and B. Wijnen, "User-based 1408 Security Model (USM) for version 3 of the Simple Network 1409 Management Protocol (SNMPv3)", RFC 2274, January 1998. 1411 [ISO-ASN.1] Information processing systems - Open Systems 1412 Interconnection - Specification of Abstract Syntax Notation One 1413 (ASN.1), International Organization for Standardization. 1414 International Standard 8824, (December, 1987). 1416 9. Editors' Addresses 1418 Bert Wijnen 1419 IBM T. J. Watson Research 1420 Schagen 33 1421 3461 GL Linschoten 1422 Netherlands 1424 EMail: wijnen@vnet.ibm.com 1425 Phone: +31-348-432-794 1427 Randy Presuhn 1428 BMC Software, Inc 1429 1190 Saratoga Avenue, Suite 130 1430 San Jose, CA 95129-3433 1431 USA 1433 EMail: rpresuhn@bmc.com 1434 Phone: +1-408-556-0720 1436 Keith McCloghrie 1437 Cisco Systems, Inc. 1438 170 West Tasman Drive 1439 San Jose, CA 95134-1706 1440 USA 1442 EMail: kzm@cisco.com 1443 Phone: +1-408-526-5260 1445 APPENDIX A - Installation 1447 A.1. Installation Parameters 1449 During installation, an authoritative SNMP engine which supports this 1450 View-based Access Control Model SHOULD be configured with several 1451 initial parameters. These include for the View-based Access Control 1452 Model: 1454 1) A security configuration 1456 The choice of security configuration determines if initial 1457 configuration is implemented and if so how. One of three possible 1458 choices is selected: 1460 - initial-minimum-security-configuration 1461 - initial-semi-security-configuration 1462 - initial-no-access-configuration 1464 In the case of a initial-no-access-configuration, there is no initial 1465 configuration, and so the following steps are irrelevant. 1467 2) A default context 1469 One entry in the vacmContextTable with a contextName of "" (the empty 1470 string), representing the default context. Note that this table gets 1471 created automatically if a default context exists. 1473 vacmContextName "" | 1475 3) An initial group 1477 One entry in the vacmSecurityToGroupTable to allow access to group 1478 "initial". 1480 vacmSecurityModel 3 (USM) | 1481 vacmSecurityName "initial" | 1482 vacmGroupName "initial" | 1483 vacmSecurityToGroupStorageType anyValidStorageType | 1484 vacmSecurityToGroupStatus active | 1486 4) Initial access rights 1488 Three entries in the vacmAccessTable as follows: 1490 - read-notify access for securityModel USM, securityLevel 1491 "noAuthNoPriv" on behalf of securityNames that belong to the group 1492 "initial" to the MIB view in the default context with 1493 contextName "". 1495 - read-write-notify access for securityModel USM, securityLevel 1496 "authNoPriv" on behalf of securityNames that belong to the group 1497 "initial" to the MIB view in the default context with 1498 contextName "". 1500 - if privacy is supported, 1501 read-write-notify access for securityModel USM, securityLevel 1502 "authPriv" on behalf of securityNames that belong to the group 1503 "initial" to the MIB view in the default context with 1504 contextName "". 1506 That translates into the following entries in the vacmAccessTable. 1507 Those columns marked with (index) are index-only objects and are not 1508 really present in this table. 1510 - One entry to be used for unauthenticated access (noAuthNoPriv): | 1512 vacmGroupName "initial" | 1513 vacmAccessContextPrefix "" | 1514 vacmAccessSecurityModel 3 (USM) | 1515 vacmAccessSecurityLevel noAuthNoPriv | 1516 vacmAccessContextMatch exact | 1517 vacmAccessReadViewName "restricted" | 1518 vacmAccessWriteViewName "" | 1519 vacmAccessNotifyViewName "restricted" | 1520 vacmAccessStorageType anyValidStorageType | 1521 vacmAccessStatus active | 1523 - One entry to be used for authenticated access but without | 1524 privacy (authNoPriv): | 1526 vacmGroupName "initial" | 1527 vacmAccessContextPrefix "" | 1528 vacmAccessSecurityModel 3 (USM) | 1529 vacmAccessSecurityLevel authNoPriv | 1530 vacmAccessContextMatch exact | 1531 vacmAccessReadViewName "internet" | 1532 vacmAccessWriteViewName "internet" | 1533 vacmAccessNotifyViewName "internet" | 1534 vacmAccessStorageType anyValidStorageType | 1535 vacmAccessStatus active | 1536 | 1538 - One optional entry to be used for authenticated access with | 1539 privacy (authPriv): | 1540 | 1541 vacmGroupName "initial" | 1542 vacmAccessContextPrefix "" | 1543 vacmAccessSecurityModel 3 (USM) | 1544 vacmAccessSecurityLevel authPriv | 1545 vacmAccessContextMatch exact | 1546 vacmAccessReadViewName "internet" | 1547 vacmAccessWriteViewName "internet" | 1548 vacmAccessNotifyViewName "internet" | 1549 vacmAccessStorageType anyValidStorageType | 1550 vacmAccessStatus active | 1552 5) Two MIB views, of which the second one depends on the security 1553 configuration. 1555 - One view, the view, for authenticated access: 1557 - the MIB view is the following subtree: 1558 "internet" (subtree 1.3.6.1) 1560 - A second view, the view, for unauthenticated 1561 access. This view is configured according to the selected 1562 security configuration: 1564 - For the initial-no-access-configuration there is no default 1565 initial configuration, so no MIB views are pre-scribed. 1567 - For the initial-semi-secure-configuration: 1569 the MIB view is the union of these subtrees: 1570 (a) "system" (subtree 1.3.6.1.2.1.1) [RFC1907] 1571 (b) "snmp" (subtree 1.3.6.1.2.1.11) [RFC1907] 1572 (c) "snmpEngine" (subtree 1.3.6.1.6.3.7.2.1) [RFCxxx1] 1573 (d) "snmpMPDStats" (subtree 1.3.6.1.6.3.8.2.1) [RFCxxx2] 1574 (e) "usmStats" (subtree 1.3.6.1.6.3.9.2.1) [RFCxxx4] 1576 - For the initial-minimum-secure-configuration: 1578 the MIB view is the following subtree. 1579 "internet" (subtree 1.3.6.1) 1581 This translates into the following "internet" entry in the 1582 vacmViewTreeFamilyTable: 1584 minimum-secure semi-secure 1585 ---------------- --------------- 1586 vacmViewTreeFamilyViewName "internet" "internet" 1587 vacmViewTreeFamilySubtree 1.3.6.1 1.3.6.1 1588 vacmViewTreeFamilyMask "" "" 1589 vacmViewTreeFamilyType 1 (included) 1 (included) 1590 vacmViewTreeFamilyStorageType anyValidStorageType anyValidStorageType 1591 vacmViewTreeFamilyStatus active active 1593 In addition it translates into the following "restricted" entries 1594 in the vacmViewTreeFamilyTable: 1596 minimum-secure semi-secure 1597 ---------------- --------------- 1598 vacmViewTreeFamilyViewName "restricted" "restricted" 1599 vacmViewTreeFamilySubtree 1.3.6.1 1.3.6.1.2.1.1 1600 vacmViewTreeFamilyMask "" "" 1601 vacmViewTreeFamilyType 1 (included) 1 (included) 1602 vacmViewTreeFamilyStorageType anyValidStorageType anyValidStorageType 1603 vacmViewTreeFamilyStatus active active 1605 vacmViewTreeFamilyViewName "restricted" 1606 vacmViewTreeFamilySubtree 1.3.6.1.2.1.11 1607 vacmViewTreeFamilyMask "" 1608 vacmViewTreeFamilyType 1 (included) 1609 vacmViewTreeFamilyStorageType anyValidStorageType 1610 vacmViewTreeFamilyStatus active 1612 vacmViewTreeFamilyViewName "restricted" 1613 vacmViewTreeFamilySubtree 1.3.6.1.6.3.7.2.1 1614 vacmViewTreeFamilyMask "" 1615 vacmViewTreeFamilyType 1 (included) 1616 vacmViewTreeFamilyStorageType anyValidStorageType 1617 vacmViewTreeFamilyStatus active 1619 vacmViewTreeFamilyViewName "restricted" 1620 vacmViewTreeFamilySubtree 1.3.6.1.6.3.8.2.1 1621 vacmViewTreeFamilyMask "" 1622 vacmViewTreeFamilyType 1 (included) 1623 vacmViewTreeFamilyStorageType anyValidStorageType 1624 vacmViewTreeFamilyStatus active 1626 vacmViewTreeFamilyViewName "restricted" 1627 vacmViewTreeFamilySubtree 1.3.6.1.6.3.9.2.1 1628 vacmViewTreeFamilyMask "" 1629 vacmViewTreeFamilyType 1 (included) 1630 vacmViewTreeFamilyStorageType anyValidStorageType 1631 vacmViewTreeFamilyStatus active 1633 B. Full Copyright Statement 1635 Copyright (C) The Internet Society (1998). All Rights Reserved. 1637 This document and translations of it may be copied and furnished to 1638 others, and derivative works that comment on or otherwise explain it 1639 or assist in its implementation may be prepared, copied, published 1640 and distributed, in whole or in part, without restriction of any 1641 kind, provided that the above copyright notice and this paragraph are 1642 included on all such copies and derivative works. However, this 1643 document itself may not be modified in any way, such as by removing 1644 the copyright notice or references to the Internet Society or other 1645 Internet organizations, except as needed for the purpose of 1646 developing Internet standards in which case the procedures for 1647 copyrights defined in the Internet Standards process must be 1648 followed, or as required to translate it into languages other than 1649 English. 1651 The limited permissions granted above are perpetual and will not be 1652 revoked by the Internet Society or its successors or assigns. 1654 This document and the information contained herein is provided on an 1655 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1656 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1657 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1658 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1659 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.