idnits 2.17.1 draft-ietf-snmpv3-vacm-01.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. ** 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 59 has weird spacing: '...verview of is...' == Line 329 has weird spacing: '...verview of is...' == Line 1491 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 (30 October 1998) is 9310 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 1576, but not defined ** Obsolete undefined reference: RFC 1907 (Obsoleted by RFC 3418) == Unused Reference: 'RFC1902' is defined on line 1393, 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-01 == Outdated reference: A later version (-05) exists of draft-ietf-snmpv3-mpc-01 == Outdated reference: A later version (-05) exists of draft-ietf-snmpv3-usm-v2-02 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 30 October 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 Abstract 39 This document describes the View-based Access Control Model for use 40 in the SNMP architecture [RFC-ARCH]. It defines the Elements of 41 Procedure for controlling access to management information. This 42 document also includes a MIB for remotely managing the configuration 43 parameters for the View-based Access Control Model. 45 Table of Contents 47 1. Introduction 2 48 1.2. Access Control 3 49 1.3. Local Configuration Datastore 3 50 2. Elements of the Model 4 51 2.1. Groups 4 52 2.2. securityLevel 4 53 2.3. Contexts 4 54 2.4. MIB Views and View Families 4 55 2.4.1. View Subtree 5 56 2.4.2. ViewTreeFamily 5 57 2.5. Access Policy 6 58 3. Elements of Procedure 7 59 3.1. Overview of isAccessAllowed Process 8 60 3.2. Processing the isAccessAllowed Service Request 9 61 4. Definitions 10 62 5. Intellectual Property 27 63 6. Acknowledgements 27 64 7. Security Considerations 29 65 7.1. Recommended Practices 29 66 7.2. Defining Groups 29 67 7.3. Conformance 30 68 8. References 30 69 9. Editors' Addresses 31 70 A.1. Installation Parameters 32 71 B. Change Log 36 72 C. Full Copyright Statement 36 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 include these types of operations: GetRequest, GetNextRequest, 114 GetBulkRequest, and SetRequest operations. 116 Access Control also occurs in an SNMP entity when an SNMP 117 notification message is generated (by a Notification Originator 118 application). These notification messages include these types of 119 operations: InformRequest and SNMPv2-Trap operations. 121 The View-based Access Control Model defines a set of services that an 122 application (such as a Command Responder or a Notification Originator 123 application) can use for checking access rights. It is the 124 responsibility of the application to make the proper service calls 125 for access checking. 127 1.3. Local Configuration Datastore 129 To implement the model described in this document, an SNMP entity 130 needs to retain information about access rights and policies. This 131 information is part of the SNMP engine's Local Configuration 132 Datastore (LCD). See [RFC-ARCH] for the definition of LCD. 134 In order to allow an SNMP entity's LCD to be remotely configured, 135 portions of the LCD need to be accessible as managed objects. A MIB 136 module, the View-based Access Control Model Configuration MIB, which 137 defines these managed object types is included in this document. 139 2. Elements of the Model 141 This section contains definitions to realize the access control 142 service provided by the View-based Access Control Model. 144 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 [RFC-ARCH] 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 [RFC-ARCH]. 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 "9809300000Z" -- 30 Sep 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 "9809300000Z" -- 30 Sep 1998, midnight 511 -- RFC-Editor assigns RFCxxxx 512 DESCRIPTION "Clarifications, published as RFCxxxx" 514 REVISION "9711200000Z" -- 20 Nov 1997, midnight 515 DESCRIPTION "Initial version, published as RFC2275" 517 ::= { snmpModules 16 } 519 -- 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 569 } 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. 666 Conceptual rows having the value 'permanent' need not 667 allow write-access to any columnar objects in the row. 668 " 669 DEFVAL { nonVolatile } 670 ::= { vacmSecurityToGroupEntry 4 } 672 vacmSecurityToGroupStatus OBJECT-TYPE 673 SYNTAX RowStatus 674 MAX-ACCESS read-create 675 STATUS current 676 DESCRIPTION "The status of this conceptual row. 678 Until instances of all corresponding columns are 679 appropriately configured, the value of the 680 corresponding instance of the vacmSecurityToGroupStatus 681 column is 'notReady'. 683 In particular, a newly created row cannot be made 684 active until a value has been set for vacmGroupName. 686 The RowStatus TC [RFC1903] requires that this 687 DESCRIPTION clause states under which circumstances 688 other objects in this row can be modified: 690 The value of this object has no effect on whether 691 other objects in this conceptual row can be modified. 692 " 693 ::= { vacmSecurityToGroupEntry 5 } 695 -- Information about Access Rights *********************************** 697 vacmAccessTable OBJECT-TYPE 698 SYNTAX SEQUENCE OF VacmAccessEntry 699 MAX-ACCESS not-accessible 700 STATUS current 701 DESCRIPTION "The table of access rights for groups. 703 Each entry is indexed by a contextPrefix, a groupName 704 a securityModel and a securityLevel. To determine 705 whether access is allowed, one entry from this table 706 needs to be selected and the proper viewName from that 707 entry must be used for access control checking. 709 To select the proper entry, follow these steps: 711 1) the set of possible matches is formed by the 712 intersection of the following sets of entries: 713 the set of entries with identical vacmGroupName 714 the union of these two sets: 715 - the set with identical vacmAccessContextPrefix 716 - the set of entries with vacmAccessContextMatch 717 value of 'prefix' and matching 718 vacmAccessContextPrefix 719 intersected with the union of these two sets: 720 - the set of entries with identical 721 vacmSecurityModel 722 - the set of entries with vacmSecurityModel 723 value of 'any' 724 intersected with the set of entries with 725 vacmAccessSecurityLevel value less than or equal 726 to the requested securityLevel 728 2) if this set has only one member, we're done 729 otherwise, it comes down to deciding how to weight 730 the preferences between ContextPrefixes, 731 SecurityModels, and SecurityLevels as follows: 732 a) if the subset of entries with securityModel 733 matching the securityModel in the message is 734 not empty, then discard the rest. 735 b) if the subset of entries with 736 vacmAccessContextPrefix matching the contextName 737 in the message is not empty, 738 then discard the rest 739 c) discard all entries with ContextPrefixes shorter 740 than the longest one remaining in the set 741 d) select the entry with the highest securityLevel 743 Please note that for securityLevel noAuthNoPriv, all 744 groups are really equivalent since the assumption that 745 the securityName has been authenticated does not hold. 746 " 747 ::= { vacmMIBObjects 4 } 749 vacmAccessEntry OBJECT-TYPE 750 SYNTAX VacmAccessEntry 751 MAX-ACCESS not-accessible 752 STATUS current 753 DESCRIPTION "An access right configured in the Local Configuration 754 Datastore (LCD) authorizing access to an SNMP context. 755 " 756 INDEX { vacmGroupName, 757 vacmAccessContextPrefix, 758 vacmAccessSecurityModel, 759 vacmAccessSecurityLevel 760 } 761 ::= { vacmAccessTable 1 } 763 VacmAccessEntry ::= SEQUENCE 764 { 765 vacmAccessContextPrefix SnmpAdminString, 766 vacmAccessSecurityModel SnmpSecurityModel, 767 vacmAccessSecurityLevel SnmpSecurityLevel, 768 vacmAccessContextMatch INTEGER, 769 vacmAccessReadViewName SnmpAdminString, 770 vacmAccessWriteViewName SnmpAdminString, 771 vacmAccessNotifyViewName SnmpAdminString, 772 vacmAccessStorageType StorageType, 773 vacmAccessStatus RowStatus 774 } 776 vacmAccessContextPrefix OBJECT-TYPE 777 SYNTAX SnmpAdminString (SIZE(0..32)) 778 MAX-ACCESS not-accessible 779 STATUS current 780 DESCRIPTION "In order to gain the access rights allowed by this 781 conceptual row, a contextName must match exactly 782 (if the value of vacmAccessContextMatch is 'exact') 783 or partially (if the value of vacmAccessContextMatch 784 is 'prefix') to the value of the instance of this 785 object. 786 " 787 ::= { vacmAccessEntry 1 } 789 vacmAccessSecurityModel OBJECT-TYPE 790 SYNTAX SnmpSecurityModel 791 MAX-ACCESS not-accessible 792 STATUS current 793 DESCRIPTION "In order to gain the access rights allowed by this 794 conceptual row, this securityModel must be in use. 795 " 796 ::= { vacmAccessEntry 2 } 798 vacmAccessSecurityLevel OBJECT-TYPE 799 SYNTAX SnmpSecurityLevel 800 MAX-ACCESS not-accessible 801 STATUS current 802 DESCRIPTION "The minimum level of security required in order to 803 gain the access rights allowed by this conceptual 804 row. A securityLevel of noAuthNoPriv is less than 805 authNoPriv which in turn is less than authPriv. 807 If multiple entries are equally indexed except for 808 this vacmAccessSecurityLevel index, then the entry 809 which has the highest value for 810 vacmAccessSecurityLevel wins. 811 " 812 ::= { vacmAccessEntry 3 } 814 vacmAccessContextMatch OBJECT-TYPE 815 SYNTAX INTEGER 816 { exact (1), -- exact match of prefix and contextName 817 prefix (2) -- Only match to the prefix 818 } 819 MAX-ACCESS read-create 820 STATUS current 821 DESCRIPTION "If the value of this object is exact(1), then all 822 rows where the contextName exactly matches 823 vacmAccessContextPrefix are selected. 825 If the value of this object is prefix(2), then all 826 rows where the contextName whose starting octets 827 exactly match vacmAccessContextPrefix are selected. 828 This allows for a simple form of wildcarding. 829 See also the example in the DESCRIPTION clause of 830 the vacmAccessTable above. 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. 952 " 953 ::= { vacmMIBViews 1 } 955 vacmViewTreeFamilyTable OBJECT-TYPE 956 SYNTAX SEQUENCE OF VacmViewTreeFamilyEntry 957 MAX-ACCESS not-accessible 958 STATUS current 959 DESCRIPTION "Locally held information about families of subtrees 960 within MIB views. 962 Each MIB view is defined by two sets of view subtrees: 963 - the included view subtrees, and 964 - the excluded view subtrees. 965 Every such view subtree, both the included and the 966 excluded ones, is defined in this table. 968 To determine if a particular object instance is in 969 a particular MIB view, compare the object instance's 970 OBJECT IDENTIFIER with each of the MIB view's active 971 entries in this table. If none match, then the 972 object instance is not in the MIB view. If one or 973 more match, then the object instance is included in, 974 or excluded from, the MIB view according to the 975 value of vacmViewTreeFamilyType in the entry whose 976 value of vacmViewTreeFamilySubtree has the most 977 sub-identifiers. If multiple entries match and have 978 the same number of sub-identifiers, then the 979 lexicographically greatest instance of 980 vacmViewTreeFamilyType determines the inclusion or 981 exclusion. 983 An object instance's OBJECT IDENTIFIER X matches an 984 active entry in this table when the number of 985 sub-identifiers in X is at least as many as in the 986 value of vacmViewTreeFamilySubtree for the entry, 987 and each sub-identifier in the value of 988 vacmViewTreeFamilySubtree matches its corresponding 989 sub-identifier in X. Two sub-identifiers match 990 either if the corresponding bit of the value of 991 vacmViewTreeFamilyMask for the entry is zero (the 992 'wild card' value), or if they are equal. 994 A 'family' of subtrees is the set of subtrees defined 995 by a particular combination of values of 996 vacmViewTreeFamilySubtree and vacmViewTreeFamilyMask. 997 In the case where no 'wild card' is defined in the 998 vacmViewTreeFamilyMask, the family of subtrees reduces 999 to a single subtree. 1001 When creating or changing MIB views, an SNMP Command 1002 Generator application should utilize the 1003 vacmViewSpinLock to try to avoid collisions. See 1004 DESCRIPTION clause of vacmViewSpinLock. 1006 When creating MIB views, it is strongly advised that 1007 first the 'excluded' vacmViewTreeFamilyEntries are 1008 created and then the 'included' entries. 1010 When deleting MIB views, it is strongly advised that 1011 first the 'included' vacmViewTreeFamilyEntries are 1012 deleted and then the 'excluded' entries. 1014 If a create for an entry for instance-level access 1015 control is received and the implementation does not 1016 support instance-level granularity, then an 1017 inconsistentName error must be returned. 1018 " 1019 ::= { vacmMIBViews 2 } 1021 vacmViewTreeFamilyEntry OBJECT-TYPE 1022 SYNTAX VacmViewTreeFamilyEntry 1023 MAX-ACCESS not-accessible 1024 STATUS current 1025 DESCRIPTION "Information on a particular family of view subtrees 1026 included in or excluded from a particular SNMP 1027 context's MIB view. 1029 Implementations must not restrict the number of 1030 families of view subtrees for a given MIB view, 1031 except as dictated by resource constraints on the 1032 overall number of entries in the 1033 vacmViewTreeFamilyTable. 1035 If no conceptual rows exist in this table for a given 1036 MIB view (viewName), that view may be thought of as 1037 consisting of the empty set of view subtrees. 1038 " 1039 INDEX { vacmViewTreeFamilyViewName, 1040 vacmViewTreeFamilySubtree 1041 } 1042 ::= { vacmViewTreeFamilyTable 1 } 1044 VacmViewTreeFamilyEntry ::= SEQUENCE 1045 { 1046 vacmViewTreeFamilyViewName SnmpAdminString, 1047 vacmViewTreeFamilySubtree OBJECT IDENTIFIER, 1048 vacmViewTreeFamilyMask OCTET STRING, 1049 vacmViewTreeFamilyType INTEGER, 1050 vacmViewTreeFamilyStorageType StorageType, 1051 vacmViewTreeFamilyStatus RowStatus 1052 } 1054 vacmViewTreeFamilyViewName OBJECT-TYPE 1055 SYNTAX SnmpAdminString (SIZE(1..32)) 1056 MAX-ACCESS not-accessible 1057 STATUS current 1058 DESCRIPTION "The human readable name for a family of view subtrees. 1059 " 1060 ::= { vacmViewTreeFamilyEntry 1 } 1062 vacmViewTreeFamilySubtree OBJECT-TYPE 1063 SYNTAX OBJECT IDENTIFIER 1064 MAX-ACCESS not-accessible 1065 STATUS current 1066 DESCRIPTION "The MIB subtree which when combined with the 1067 corresponding instance of vacmViewTreeFamilyMask 1068 defines a family of view subtrees. 1069 " 1070 ::= { vacmViewTreeFamilyEntry 2 } 1072 vacmViewTreeFamilyMask OBJECT-TYPE 1073 SYNTAX OCTET STRING (SIZE (0..16)) 1074 MAX-ACCESS read-create 1075 STATUS current 1076 DESCRIPTION "The bit mask which, in combination with the 1077 corresponding instance of vacmViewTreeFamilySubtree, 1078 defines a family of view subtrees. 1080 Each bit of this bit mask corresponds to a 1081 sub-identifier of vacmViewTreeFamilySubtree, with the 1082 most significant bit of the i-th octet of this octet 1083 string value (extended if necessary, see below) 1084 corresponding to the (8*i - 7)-th sub-identifier, and 1085 the least significant bit of the i-th octet of this 1086 octet string corresponding to the (8*i)-th 1087 sub-identifier, where i is in the range 1 through 16. 1089 Each bit of this bit mask specifies whether or not 1090 the corresponding sub-identifiers must match when 1091 determining if an OBJECT IDENTIFIER is in this 1092 family of view subtrees; a '1' indicates that an 1093 exact match must occur; a '0' indicates 'wild card', 1094 i.e., any sub-identifier value matches. 1096 Thus, the OBJECT IDENTIFIER X of an object instance 1097 is contained in a family of view subtrees if, for 1098 each sub-identifier of the value of 1099 vacmViewTreeFamilySubtree, either: 1101 the i-th bit of vacmViewTreeFamilyMask is 0, or 1103 the i-th sub-identifier of X is equal to the i-th 1104 sub-identifier of the value of 1105 vacmViewTreeFamilySubtree. 1107 If the value of this bit mask is M bits long and 1108 there are more than M sub-identifiers in the 1109 corresponding instance of vacmViewTreeFamilySubtree, 1110 then the bit mask is extended with 1's to be the 1111 required length. 1113 Note that when the value of this object is the 1114 zero-length string, this extension rule results in 1115 a mask of all-1's being used (i.e., no 'wild card'), 1116 and the family of view subtrees is the one view 1117 subtree uniquely identified by the corresponding 1118 instance of vacmViewTreeFamilySubtree. 1120 Note that masks of length greater than zero length 1121 do not need to be supported. In this case this 1122 object is made read-only. 1123 " 1124 DEFVAL { ''H } 1125 ::= { vacmViewTreeFamilyEntry 3 } 1127 vacmViewTreeFamilyType OBJECT-TYPE 1128 SYNTAX INTEGER { included(1), excluded(2) } 1129 MAX-ACCESS read-create 1130 STATUS current 1131 DESCRIPTION "Indicates whether the corresponding instances of 1132 vacmViewTreeFamilySubtree and vacmViewTreeFamilyMask 1133 define a family of view subtrees which is included in 1134 or excluded from the MIB view. 1135 " 1136 DEFVAL { included } 1137 ::= { vacmViewTreeFamilyEntry 4 } 1139 vacmViewTreeFamilyStorageType OBJECT-TYPE 1140 SYNTAX StorageType 1141 MAX-ACCESS read-create 1142 STATUS current 1143 DESCRIPTION "The storage type for this conceptual row. 1145 Conceptual rows having the value 'permanent' need not 1146 allow write-access to any columnar objects in the row. 1147 " 1148 DEFVAL { nonVolatile } 1149 ::= { vacmViewTreeFamilyEntry 5 } 1151 vacmViewTreeFamilyStatus OBJECT-TYPE 1152 SYNTAX RowStatus 1153 MAX-ACCESS read-create 1154 STATUS current 1155 DESCRIPTION "The status of this conceptual row. 1157 The RowStatus TC [RFC1903] requires that this 1158 DESCRIPTION clause states under which circumstances 1159 other objects in this row can be modified: 1161 The value of this object has no effect on whether 1162 other objects in this conceptual row can be modified. 1163 " 1164 ::= { vacmViewTreeFamilyEntry 6 } 1166 -- Conformance information ******************************************* 1168 vacmMIBCompliances OBJECT IDENTIFIER ::= { vacmMIBConformance 1 } 1169 vacmMIBGroups OBJECT IDENTIFIER ::= { vacmMIBConformance 2 } 1171 -- Compliance statements ********************************************* 1173 vacmMIBCompliance MODULE-COMPLIANCE 1174 STATUS current 1175 DESCRIPTION "The compliance statement for SNMP engines which 1176 implement the SNMP View-based Access Control Model 1177 configuration MIB. 1178 " 1179 MODULE -- this module 1180 MANDATORY-GROUPS { vacmBasicGroup } 1182 OBJECT vacmAccessContextMatch 1183 MIN-ACCESS read-only 1184 DESCRIPTION "Write access is not required." 1185 OBJECT vacmAccessReadViewName 1186 MIN-ACCESS read-only 1187 DESCRIPTION "Write access is not required." 1189 OBJECT vacmAccessWriteViewName 1190 MIN-ACCESS read-only 1191 DESCRIPTION "Write access is not required." 1193 OBJECT vacmAccessNotifyViewName 1194 MIN-ACCESS read-only 1195 DESCRIPTION "Write access is not required." 1197 OBJECT vacmAccessStorageType 1198 MIN-ACCESS read-only 1199 DESCRIPTION "Write access is not required." 1201 OBJECT vacmAccessStatus 1202 MIN-ACCESS read-only 1203 DESCRIPTION "Create/delete/modify access to the 1204 vacmAccessTable is not required. 1205 " 1207 OBJECT vacmViewTreeFamilyMask 1208 WRITE-SYNTAX OCTET STRING (SIZE (0)) 1209 MIN-ACCESS read-only 1210 DESCRIPTION "Support for configuration via SNMP of subtree 1211 families using wild-cards is not required. 1212 " 1214 OBJECT vacmViewTreeFamilyType 1215 MIN-ACCESS read-only 1216 DESCRIPTION "Write access is not required." 1218 OBJECT vacmViewTreeFamilyStorageType 1219 MIN-ACCESS read-only 1220 DESCRIPTION "Write access is not required." 1222 OBJECT vacmViewTreeFamilyStatus 1223 MIN-ACCESS read-only 1224 DESCRIPTION "Create/delete/modify access to the 1225 vacmViewTreeFamilyTable is not required. 1226 " 1227 ::= { vacmMIBCompliances 1 } 1229 -- Units of conformance ********************************************** 1231 vacmBasicGroup OBJECT-GROUP 1232 OBJECTS { 1233 vacmContextName, 1234 vacmGroupName, 1235 vacmSecurityToGroupStorageType, 1236 vacmSecurityToGroupStatus, 1237 vacmAccessContextMatch, 1238 vacmAccessReadViewName, 1239 vacmAccessWriteViewName, 1240 vacmAccessNotifyViewName, 1241 vacmAccessStorageType, 1242 vacmAccessStatus, 1243 vacmViewSpinLock, 1244 vacmViewTreeFamilyMask, 1245 vacmViewTreeFamilyType, 1246 vacmViewTreeFamilyStorageType, 1247 vacmViewTreeFamilyStatus 1248 } 1249 STATUS current 1250 DESCRIPTION "A collection of objects providing for remote 1251 configuration of an SNMP engine which implements 1252 the SNMP View-based Access Control Model. 1253 " 1254 ::= { vacmMIBGroups 1 } 1256 END 1258 5. Intellectual Property 1260 The IETF takes no position regarding the validity or scope of any 1261 intellectual property or other rights that might be claimed to 1262 pertain to the implementation or use of the technology described in 1263 this document or the extent to which any license under such rights 1264 might or might not be available; neither does it represent that it 1265 has made any effort to identify any such rights. Information on the 1266 IETF's procedures with respect to rights in standards-track and 1267 standards-related documentation can be found in BCP-11. Copies of 1268 claims of rights made available for publication and any assurances of 1269 licenses to be made available, or the result of an attempt made to 1270 obtain a general license or permission for the use of such 1271 proprietary rights by implementors or users of this specification can 1272 be obtained from the IETF Secretariat. 1274 The IETF invites any interested party to bring to its attention any 1275 copyrights, patents or patent applications, or other proprietary 1276 rights which may cover technology that may be required to practice 1277 this standard. Please address the information to the IETF Executive 1278 Director. 1280 6. Acknowledgements 1282 This document is the result of the efforts of the SNMPv3 Working 1283 Group. Some special thanks are in order to the following SNMPv3 WG 1284 members: 1286 Dave Battle (SNMP Research, Inc.) 1287 Uri Blumenthal (IBM T.J. Watson Research Center) 1288 Jeff Case (SNMP Research, Inc.) 1289 John Curran (BBN) 1290 T. Max Devlin (Eltrax Systems) 1291 John Flick (Hewlett Packard) 1292 David Harrington (Cabletron Systems Inc.) 1293 N.C. Hien (IBM T.J. Watson Research Center) 1294 Dave Levi (SNMP Research, Inc.) 1295 Louis A Mamakos (UUNET Technologies Inc.) 1296 Paul Meyer (Secure Computing Corporation) 1297 Keith McCloghrie (Cisco Systems) 1298 Russ Mundy (Trusted Information Systems, Inc.) 1299 Bob Natale (ACE*COMM Corporation) 1300 Mike O'Dell (UUNET Technologies Inc.) 1301 Dave Perkins (DeskTalk) 1302 Peter Polkinghorne (Brunel University) 1303 Randy Presuhn (BMC Software, Inc.) 1304 David Reid (SNMP Research, Inc.) 1305 Shawn Routhier (Epilogue) 1306 Juergen Schoenwaelder (TU Braunschweig) 1307 Bob Stewart (Cisco Systems) 1308 Bert Wijnen (IBM T.J. Watson Research Center) 1310 The document is based on recommendations of the IETF Security and 1311 Administrative Framework Evolution for SNMP Advisory Team. Members 1312 of that Advisory Team were: 1314 David Harrington (Cabletron Systems Inc.) 1315 Jeff Johnson (Cisco Systems) 1316 David Levi (SNMP Research Inc.) 1317 John Linn (Openvision) 1318 Russ Mundy (Trusted Information Systems) chair 1319 Shawn Routhier (Epilogue) 1320 Glenn Waters (Nortel) 1321 Bert Wijnen (IBM T. J. Watson Research Center) 1323 As recommended by the Advisory Team and the SNMPv3 Working Group 1324 Charter, the design incorporates as much as practical from previous 1325 RFCs and drafts. As a result, special thanks are due to the authors 1326 of previous designs known as SNMPv2u and SNMPv2*: 1328 Jeff Case (SNMP Research, Inc.) 1329 David Harrington (Cabletron Systems Inc.) 1330 David Levi (SNMP Research, Inc.) 1331 Keith McCloghrie (Cisco Systems) 1332 Brian O'Keefe (Hewlett Packard) 1333 Marshall T. Rose (Dover Beach Consulting) 1334 Jon Saperia (BGS Systems Inc.) 1335 Steve Waldbusser (International Network Services) 1336 Glenn W. Waters (Bell-Northern Research Ltd.) 1338 7. Security Considerations 1340 7.1. Recommended Practices 1342 This document is meant for use in the SNMP architecture. The View- 1343 based Access Control Model described in this document checks access 1344 rights to management information based on: 1346 - contextName, representing a set of management information at the 1347 managed system where the Access Control module is running. 1348 - groupName, representing a set of zero or more securityNames. 1349 The combination of a securityModel and a securityName is mapped 1350 into a group in the View-based Access Control Model. 1351 - securityModel under which access is requested. 1352 - securityLevel under which access is requested. 1353 - operation performed on the management information. 1354 - MIB views for read, write or notify access. 1356 When the User-based Access Control module is called for checking 1357 access rights, it is assumed that the calling module has ensured the 1358 authentication and privacy aspects as specified by the securityLevel 1359 that is being passed. 1361 When creating entries in or deleting entries from the 1362 vacmViewTreeFamilyTable it is important to do such in the sequence as 1363 recommended in the DESCRIPTION clause of the vacmViewTreeFamilyTable 1364 definition. Otherwise unwanted access may be granted while changing 1365 the entries in the table. 1367 7.2. Defining Groups 1369 The groupNames are used to give access to a group of zero or more 1370 securityNames. Within the View-Based Access Control Model, a 1371 groupName is considered to exist if that groupName is listed in the 1372 vacmSecurityToGroupTable. 1374 By mapping the combination of a securityModel and securityName into a 1375 groupName, an SNMP Command Generator application can add/delete 1376 securityNames to/from a group, if proper access is allowed. 1378 Further it is important to realize that the grouping of 1379 tuples in the vacmSecurityToGroupTable 1380 does not take securityLevel into account. It is therefore important 1381 that the security administrator uses the securityLevel index in the 1382 vacmAccessTable to separate noAuthNoPriv from authPriv and/or 1383 authNoPriv access. 1385 7.3. Conformance 1387 For an implementation of the View-based Access Control Model to be 1388 conformant, it MUST implement the SNMP-VIEW-BASED-ACM-MIB. It also 1389 SHOULD implement the initial configuration, described in appendix A. 1391 8. References 1393 [RFC1902] Case, J., McCloghrie, K., Rose, M. and S., Waldbusser, 1394 "Structure of Management Information for Version 2 of the 1395 Simple Network Management Protocol (SNMPv2)", RFC 1902, January 1396 1996. 1398 [RFC1903] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, 1399 "Textual Conventions for Version 2 of the Simple Network 1400 Management Protocol (SNMPv2)", RFC 1903, January 1996. 1402 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1403 Requirement Levels", BCP 14, RFC 2119, March 1997. 1405 [RFC-ARCH] Harrington, D., Presuhn, R., and B. Wijnen, 1406 "An Architecture for describing SNMP Management Frameworks", 1407 draft-ietf-snmpv3-arch-01, October 1998. 1409 [RFC-MPD] Case, J., Harrington, D., Presuhn, R., and B. Wijnen, 1410 "Message Processing and Dispatching for the Simple Network 1411 Management Protocol (SNMP)", draft-ietf-snmpv3-mpc-01, October 1412 1998. 1414 [RFC-USM] Blumenthal, U., and B. Wijnen, "User-based 1415 Security Model (USM) for version 3 of the Simple Network 1416 Management Protocol (SNMPv3)", draft-ietf-snmpv3-usm-v2-02, 1417 October 1998. 1419 [ISO-ASN.1] Information processing systems - Open Systems 1420 Interconnection - Specification of Abstract Syntax Notation One 1421 (ASN.1), International Organization for Standardization. 1422 International Standard 8824, (December, 1987). 1424 9. Editors' Addresses 1426 Bert Wijnen 1427 IBM T. J. Watson Research 1428 Schagen 33 1429 3461 GL Linschoten 1430 Netherlands 1432 EMail: wijnen@vnet.ibm.com 1433 Phone: +31-348-432-794 1435 Randy Presuhn 1436 BMC Software, Inc 1437 1190 Saratoga Avenue, Suite 130 1438 San Jose, CA 95129-3433 1439 USA 1441 EMail: rpresuhn@bmc.com 1442 Phone: +1-408-556-0720 1444 Keith McCloghrie 1445 Cisco Systems, Inc. 1446 170 West Tasman Drive 1447 San Jose, CA 95134-1706 1448 USA 1450 EMail: kzm@cisco.com 1451 Phone: +1-408-526-5260 1453 APPENDIX A - Installation 1455 A.1. Installation Parameters 1457 During installation, an authoritative SNMP engine which supports this 1458 View-based Access Control Model SHOULD be configured with several 1459 initial parameters. These include for the View-based Access Control 1460 Model: 1462 1) A security configuration 1464 The choice of security configuration determines if initial 1465 configuration is implemented and if so how. One of three possible 1466 choices is selected: 1468 - initial-minimum-security-configuration 1469 - initial-semi-security-configuration 1470 - initial-no-access-configuration 1472 In the case of a initial-no-access-configuration, there is no initial 1473 configuration, and so the following steps are irrelevant. 1475 2) A default context 1477 One entry in the vacmContextTable with a contextName of "" (the empty 1478 string), representing the default context. Note that this table gets 1479 created automatically if a default context exists. 1481 vacmContextName "" 1483 3) An initial group 1485 One entry in the vacmSecurityToGroupTable to allow access to group 1486 "initial". 1488 vacmSecurityModel 3 (USM) 1489 vacmSecurityName "initial" 1490 vacmGroupName "initial" 1491 vacmSecurityToGroupStorageType anyValidStorageType 1492 vacmSecurityToGroupStatus active 1494 4) Initial access rights 1496 Three entries in the vacmAccessTable as follows: 1498 - read-notify access for securityModel USM, securityLevel 1499 "noAuthNoPriv" on behalf of securityNames that belong to the group 1500 "initial" to the MIB view in the default context with 1501 contextName "". 1503 - read-write-notify access for securityModel USM, securityLevel 1504 "authNoPriv" on behalf of securityNames that belong to the group 1505 "initial" to the MIB view in the default context with 1506 contextName "". 1508 - if privacy is supported, 1509 read-write-notify access for securityModel USM, securityLevel 1510 "authPriv" on behalf of securityNames that belong to the group 1511 "initial" to the MIB view in the default context with 1512 contextName "". 1514 That translates into the following entries in the vacmAccessTable. 1516 - One entry to be used for unauthenticated access (noAuthNoPriv): 1518 vacmGroupName "initial" 1519 vacmAccessContextPrefix "" 1520 vacmAccessSecurityModel 3 (USM) 1521 vacmAccessSecurityLevel noAuthNoPriv 1522 vacmAccessContextMatch exact 1523 vacmAccessReadViewName "restricted" 1524 vacmAccessWriteViewName "" 1525 vacmAccessNotifyViewName "restricted" 1526 vacmAccessStorageType anyValidStorageType 1527 vacmAccessStatus active 1529 - One entry to be used for authenticated access but without 1530 privacy (authNoPriv): 1532 vacmGroupName "initial" 1533 vacmAccessContextPrefix "" 1534 vacmAccessSecurityModel 3 (USM) 1535 vacmAccessSecurityLevel authNoPriv 1536 vacmAccessContextMatch exact 1537 vacmAccessReadViewName "internet" 1538 vacmAccessWriteViewName "internet" 1539 vacmAccessNotifyViewName "internet" 1540 vacmAccessStorageType anyValidStorageType 1541 vacmAccessStatus active 1543 - One optional entry to be used for authenticated access with 1544 privacy (authPriv): 1546 vacmGroupName "initial" 1547 vacmAccessContextPrefix "" 1548 vacmAccessSecurityModel 3 (USM) 1549 vacmAccessSecurityLevel authPriv 1550 vacmAccessContextMatch exact 1551 vacmAccessReadViewName "internet" 1552 vacmAccessWriteViewName "internet" 1553 vacmAccessNotifyViewName "internet" 1554 vacmAccessStorageType anyValidStorageType 1555 vacmAccessStatus active 1557 5) Two MIB views, of which the second one depends on the security 1558 configuration. 1560 - One view, the view, for authenticated access: 1562 - the MIB view is the following subtree: 1563 "internet" (subtree 1.3.6.1) 1565 - A second view, the view, for unauthenticated 1566 access. This view is configured according to the selected 1567 security configuration: 1569 - For the initial-no-access-configuration there is no default 1570 initial configuration, so no MIB views are pre-scribed. 1572 - For the initial-semi-secure-configuration: 1574 the MIB view is the union of these subtrees: 1575 (a) "system" (subtree 1.3.6.1.2.1.1) [RFC1907] 1576 (b) "snmp" (subtree 1.3.6.1.2.1.11) [RFC1907] 1577 (c) "snmpEngine" (subtree 1.3.6.1.6.3.10.2.1) [RFC-ARCH] 1578 (d) "snmpMPDStats" (subtree 1.3.6.1.6.3.11.2.1) [RFC-MPD] 1579 (e) "usmStats" (subtree 1.3.6.1.6.3.15.1.1) [RFC-USM] 1581 - For the initial-minimum-secure-configuration: 1583 the MIB view is the following subtree. 1584 "internet" (subtree 1.3.6.1) 1586 This translates into the following "internet" entry in the 1587 vacmViewTreeFamilyTable: 1589 minimum-secure semi-secure 1590 ---------------- --------------- 1591 vacmViewTreeFamilyViewName "internet" "internet" 1592 vacmViewTreeFamilySubtree 1.3.6.1 1.3.6.1 1593 vacmViewTreeFamilyMask "" "" 1594 vacmViewTreeFamilyType 1 (included) 1 (included) 1595 vacmViewTreeFamilyStorageType anyValidStorageType anyValidStorageType 1596 vacmViewTreeFamilyStatus active active 1598 In addition it translates into the following "restricted" entries 1599 in the vacmViewTreeFamilyTable: 1601 minimum-secure semi-secure 1602 ---------------- --------------- 1603 vacmViewTreeFamilyViewName "restricted" "restricted" 1604 vacmViewTreeFamilySubtree 1.3.6.1 1.3.6.1.2.1.1 1605 vacmViewTreeFamilyMask "" "" 1606 vacmViewTreeFamilyType 1 (included) 1 (included) 1607 vacmViewTreeFamilyStorageType anyValidStorageType anyValidStorageType 1608 vacmViewTreeFamilyStatus active active 1610 vacmViewTreeFamilyViewName "restricted" 1611 vacmViewTreeFamilySubtree 1.3.6.1.2.1.11 1612 vacmViewTreeFamilyMask "" 1613 vacmViewTreeFamilyType 1 (included) 1614 vacmViewTreeFamilyStorageType anyValidStorageType 1615 vacmViewTreeFamilyStatus active 1617 vacmViewTreeFamilyViewName "restricted" 1618 vacmViewTreeFamilySubtree 1.3.6.1.6.3.10.2.1 1619 vacmViewTreeFamilyMask "" 1620 vacmViewTreeFamilyType 1 (included) 1621 vacmViewTreeFamilyStorageType anyValidStorageType 1622 vacmViewTreeFamilyStatus active 1624 vacmViewTreeFamilyViewName "restricted" 1625 vacmViewTreeFamilySubtree 1.3.6.1.6.3.11.2.1 1626 vacmViewTreeFamilyMask "" 1627 vacmViewTreeFamilyType 1 (included) 1628 vacmViewTreeFamilyStorageType anyValidStorageType 1629 vacmViewTreeFamilyStatus active 1631 vacmViewTreeFamilyViewName "restricted" 1632 vacmViewTreeFamilySubtree 1.3.6.1.6.3.15.1.1 1633 vacmViewTreeFamilyMask "" 1634 vacmViewTreeFamilyType 1 (included) 1635 vacmViewTreeFamilyStorageType anyValidStorageType 1636 vacmViewTreeFamilyStatus active 1638 B. Change Log 1640 Changes made since RFC2275: 1642 - Added text to vacmSecurityToGroupStatus DESCRIPTION clause to 1643 clarify under which conditions an entry in the 1644 vacmSecurityToGroupTable can be made active. 1645 - Added REVISION clauses to MODULE-IDENTITY 1646 - Clarified text in vacmAccessTable DESCRIPTION clause. 1647 - Added a DEFVAL clause to vacmAccessContextMatch object. 1648 - Corrected various spelling errors and typos. 1649 - Added missing columns in Appendix A and re-arranged for clarity. 1650 - Fixed oids in appendix A. 1651 - Fixed references to new/revised documents 1653 C. Full Copyright Statement 1655 Copyright (C) The Internet Society (1998). All Rights Reserved. 1657 This document and translations of it may be copied and furnished to 1658 others, and derivative works that comment on or otherwise explain it 1659 or assist in its implementation may be prepared, copied, published 1660 and distributed, in whole or in part, without restriction of any 1661 kind, provided that the above copyright notice and this paragraph are 1662 included on all such copies and derivative works. However, this 1663 document itself may not be modified in any way, such as by removing 1664 the copyright notice or references to the Internet Society or other 1665 Internet organizations, except as needed for the purpose of 1666 developing Internet standards in which case the procedures for 1667 copyrights defined in the Internet Standards process must be 1668 followed, or as required to translate it into languages other than 1669 English. 1671 The limited permissions granted above are perpetual and will not be 1672 revoked by the Internet Society or its successors or assigns. 1674 This document and the information contained herein is provided on an 1675 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1676 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1677 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1678 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1679 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.