idnits 2.17.1 draft-ietf-snmpv3-acm-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Found some kind of copyright notice around line 33 but it does not match any copyright boilerplate known by this tool. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing 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 8 longer pages, the longest (page 2) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** 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 247 instances of too long lines in the document, the longest one being 55 characters in excess of 72. == 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 506 has weird spacing: '...verview of is...' == Line 1634 has weird spacing: '...support priva...' == Line 1643 has weird spacing: '...support priva...' == Line 1677 has weird spacing: '...support priva...' == (4 more instances...) == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC1907' is mentioned on line 1738, but not defined ** Obsolete undefined reference: RFC 1907 (Obsoleted by RFC 3418) == Missing Reference: 'SNMP-USM' is mentioned on line 1741, but not defined == Unused Reference: 'RFC1902' is defined on line 1553, 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) Summary: 13 errors (**), 0 flaws (~~), 14 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT B. Wijnen 3 3 IBM T. J. Watson Research 3 4 R. Presuhn 3 5 BMC Software, Inc. 3 6 K. McCloghrie 3 7 Cisco Systems, Inc. 3 8 28 October 1997 3 10 View-based Access Control Model (VACM) for the 11 Simple Network Management Protocol (SNMP) 12 3 14 Status of this Memo 16 This document is an Internet-Draft. Internet-Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its areas, 18 and its working groups. Note that other groups may also distribute 19 working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet- Drafts as reference 24 material or to cite them other than as ``work in progress.'' 26 To learn the current status of any Internet-Draft, please check the 27 ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow 28 Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), 29 ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 31 Copyright Notice 3 32 3 33 Copyright (C) The Internet Society (1997). All Rights Reserved. 3 34 3 35 Abstract 37 This document describes the View-based Access Control Model for use 38 in the SNMP architecture [SNMP-ARCH]. It defines the Elements of 39 Procedure for controlling access to management information. This 40 document also includes a MIB for remotely managing the configuration 41 parameters for the View-based Access Control Model. 43 SNMPv3 Working Group Expires April 1998 [Page 1] 44 Table of Contents 46 0. Issues and Change Log 3 47 0.1. Resolved issues 3 48 0.2. Change Log 3 49 1. Introduction 7 50 1.2. Access Control 7 51 1.3. Local Configuration Datastore 8 52 2. Elements of the Model 9 53 2.1. Groups 9 54 2.2. securityLevel 9 55 2.3. Contexts 9 56 2.4. MIB Views and View Families 10 57 2.4.1. View Subtree 10 58 2.4.2. ViewTreeFamily 10 59 2.5. Access Policy 11 60 3. Elements of Procedure 12 61 3.1. Overview of isAccessAllowed Process 13 62 3.2. Processing the isAccessAllowed Service Request 14 63 4. Definitions 16 64 5. Intellectual Property 32 65 6. Acknowledgements 33 66 7. Security Considerations 34 67 7.1. Recommended Practices 34 68 7.2. Defining Groups 34 69 7.3. Conformance 35 70 8. References 36 71 9. Editors' Addresses 36 72 A.1. Installation Parameters 38 73 B. Full Copyright Statement 41 75 SNMPv3 Working Group Expires April 1998 [Page 2] 76 0. Issues and Change Log 78 When we go to RFC status, we will remove all the text of section 0. 2 80 0.1. Resolved issues 81 - There is a reverse mapping from groupName to securityName, see 82 the vacmGroupListTable. However, given the amount of object 83 we're adding, we may want to remove/postpone this table? 84 Resolution: remove for now. 85 - Do we need/want the level of detail of errorIndication that 86 the isAccessAllowed primitive will return? Those who strongly 87 object to the details listed now, better let us know (on the 88 mailing list preferably) as soon as possible. 89 Resolution: yes. 90 - Should we use human readable strings or integers for an index for 91 the tables. 92 Resolution. It was decided at the 1st and 2nd interim meeting that 93 using human readable strings would be very helpful when humans 94 have to configure many of those tables. We must specify the size 95 limits for objects that have a human readable SnmpAdminString and 96 which are used for indexing. It seems that a size limit of 32 97 is appropriate and acceptable (although tight in some languages). 98 Note also, that the issue is not just ACM, it is a general issue 99 that applies to all MIBs in all documents. 100 - Ensure valid indices. 101 Resolution. String based indices now have a size limit to ensure 102 that the resulting OIDs for instances will not exceed the limits 103 defined in RFC1905. 104 - The initial "all-iso" MIB view was not workable. 105 Resolution. Define and use the "internet" MIB view instead. 107 0.2. Change Log 109 [version 6.3] - This is the October 28 version 3 110 - these changes are marked with a revision-code "3" in right margin 3 111 - Adjusted layout per RFC 2223. 3 112 - Added copyright statements required by RFC 2026. 3 113 - post as I-D: 3 115 [version 6.2] - This is the September 30 version 2 116 - these changes are marked with a revision-code "2" in right margin 2 117 - fix writeup of vacmAccessTable (comments Dave Levi) 2 118 - Quick spell check. 2 119 - SMICng compile the mib to verify correct syntax 2 120 - paginate. 2 121 - post as I-D: 2 122 2 123 [version 6.1] - This is the September 29 version | 124 - these changes are marked with a revision-code "|" in right margin | 125 - fixes based on comments by Dave Levy and Jeff Case | ! 127 SNMPv3 Working Group Expires April 1998 [Page 3] 128 - use vacmAccessSecurityModel as the index in vacmAccessTable | 129 - add text to section 1 to explain usage of SHOULD, MUST and such. | 130 - add a comma too e.g. and i.e. occurrences. | 131 - remove any un-referenced references from "references" section. | 132 - Quick spell check. | 133 - SMICng compile the mib to verify correct syntax | 134 | 135 [version 6.0] - This is the September 22 version | 136 - these changes are marked with a revision-code "|" in right margin | 137 - Be more specific on instance level granularity in | 138 vacmViewTreeFamilyTable | 139 - Add clarifying text to sections 5.1 and 5.2 | 140 - add clarifying text to vacmContextName DESCRIPTION clause | 141 - mark references that are (for now) just placeholders and not | 142 really referenced. | 143 - added text about not needing to support instance-level granularity | 144 for access control. Also explained what a manager can expect in | 145 that case. | 146 - Some changes based on Dave Perkins comments | 147 - viewSpinLock DESCRIPTION clause | 148 - diagram intro in section 3.1 | 149 - Some changes based on JDC comments | 150 - change in appendix A. | 151 - numbered the bullets in section 3.1 for easier reference. | 152 - New writeup for selection of proper entry from vacmAccessTable | 153 - Added vacmAccessSecurityModel in vacmAccessTable, which can take | 154 a value of any; had to renumber other columns as a result. | 155 - some more text changes to clarify text better. | 156 | 158 [version 5.2] - This is the August 1 version. 159 - Incorporate comments from Keith 160 - Incorporate comments from Randy 161 - Add figure to section 3 162 - Update References 163 - Update acknowledgement section 164 - Add reference to RowStatus TC when using RowStatus 165 - Spell check once more 166 - Paginate 167 - Post to I-D repository and SNMPv3 mailing list as: 168 170 [version 5.1] - This is the July 28 version. 171 - Spell check 172 - SMICng check 174 [version 5.0] - This is the July 24 version. 175 - various types and editorial changes 176 - Adapt to latest Service Primitives 177 - remove vacmGroupListTable 178 - change index sequence for vacmSecurityToGroupTable 180 SNMPv3 Working Group Expires April 1998 [Page 4] 181 - rename prefix from acm to vacm 182 - rename LoS to securityLevel 183 - Changes as a result of comments on snmpv3 list 184 - use the bridge MIB as an example instead of repeater MIB. 185 - rename "security-posture" to "initial-configuration" 187 [version 4.2] - This is the July 14 version. 188 - Address comments by Keith: 189 - Renumber section 2.4 to 2.5 190 - Add new sections 2.4, 2.4.1, 2.4.2 about MIB Views and Subtrees 191 and Families, 192 - Use some more precise language at various places. 193 - Add reference to RFC2119 about use of SHOULD and MUST 194 - rename the acmGroupTable to acmSecurityToGroupTable because that 195 much better indicates the function of this table. 196 - improved the writeup on statusInformation for the isAccessAllowed 197 primitive. 198 - paginate and generate table of contents 199 - posted as I-D on 15 July 201 [version 4.1] - This is the July 12 version. 202 - Adapt to latest list of Primitives/Parameters. 203 - Handle comments from co-editor Randy 204 - Added the SHOULD "initial" configuration 205 - Checked the MIB with SMICng 207 [version 4.0] - This is the July 7 version. 208 - Adopt to decisions/comments made are 2nd interim 209 - securityName to groupName mapping is in ACM 210 - out of the box configurations to be described as SHOULD 211 - UTF-8 issue still open, but move to general issue (ARCH) 212 where the SnmpAdminString is defined. 213 - ACM returns errorIndication based on which the caller 214 may increment error counter which may result in a 215 Report PDU. 216 - No statistics counters are kept in ACM 217 - removed viewTable; added acmViewSpinLock 218 - Address various comments from co-editors (Randy and Keith) 219 - Address comments made on mailing list(s). 221 [version 3.1] - This is the June 18 version. 222 - remove old (resolved) issues 223 - list new issues 224 - corrections/additions by myself (Bert) 225 - corrections based on dbh comments 226 - removed change log of before 1st interim meeting. 228 [version 3.0] - this is the first ACM document (June 12 version). 229 - Modifications as agreed at 1st Interim Meeting 230 - Make Access Control Module a separate document 231 - Use viewName as index instead of an integer 233 SNMPv3 Working Group Expires April 1998 [Page 5] 234 - add notify_view 235 - use SnmpAdminString 236 - Other Modification 237 - use miId and securityModel 238 - add acmGroupTable 239 - add/rename Stats counters 241 SNMPv3 Working Group Expires April 1998 [Page 6] 242 1. Introduction 244 The Architecture for describing Internet Management Frameworks 245 [SNMP-ARCH] describes that an SNMP engine is composed of: 247 1) a Dispatcher 248 2) a Message Processing Subsystem, 249 3) a Security Subsystem, and 250 4) an Access Control Subsystem. 252 Applications make use of the services of these subsystems. 254 It is important to understand the SNMP architecture and its 255 terminology to understand where the View-based Access Control 256 Model described in this document fits into the architecture and 257 interacts with other subsystems within the architecture. The 258 reader is expected to have read and understood the description and 259 terminology of the SNMP architecture, as defined in [SNMP-ARCH]. 261 The Access Control Subsystem of an SNMP engine has the 262 responsibility for checking whether a specific type of access 263 (read, write, notify) to a particular object (instance) is allowed. 265 It is the purpose of this document to define a specific model of 266 the Access Control Subsystem, designated the View-based Access 267 Control Model. Note that this is not necessarily the only Access | 268 Control Model. | 270 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | 271 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | 272 document are to be interpreted as described in [RFC2119]. | 274 1.2. Access Control 276 Access Control occurs (either implicitly or explicitly) in an SNMP 277 entity when processing SNMP retrieval or modification request 278 messages from an SNMP entity. For example a Command Responder 279 application applies Access Control when processing requests that it 280 received from a Command Generator application. These requests 281 include these types of operations: GetRequest, GetNextRequest, 282 GetBulkRequest, and SetRequest operations. 284 Access Control also occurs in an SNMP entity when an SNMP 285 notification message is generated (by a Notification Originator 286 application). These notification messages include these types of 287 operations: InformRequest and SNMPv2-Trap operations. 289 The View-based Access Control Model defines a set of services that 290 an application (such as a Command Responder or a Notification 291 Originator application) can use for checking access rights. 292 It is the responsibility of the application to make the proper 294 SNMPv3 Working Group Expires April 1998 [Page 7] 295 service calls for access checking. 297 1.3. Local Configuration Datastore 299 To implement the model described in this document, an SNMP entity 300 needs to retain information about access rights and policies. 301 This information is part of the SNMP engine's Local Configuration 302 Datastore (LCD). See [SNMP-ARCH] for the definition of LCD. 304 In order to allow an SNMP entity's LCD to be remotely configured, 305 portions of the LCD need to be accessible as managed objects. 306 A MIB module, the View-based Access Control Model Configuration 307 MIB, which defines these managed object types is included in 308 this document. 310 SNMPv3 Working Group Expires April 1998 [Page 8] 311 2. Elements of the Model 313 This section contains definitions to realize the access control 314 service provided by the View-based Access Control Model. 316 2.1. Groups 318 A group is a set of zero or more 319 tuples on whose behalf SNMP management objects can be accessed. 320 A group defines the access rights afforded to all securityNames 321 which belong to that group. The combination of a securityModel 322 and a securityName maps to at most one group. A group is 323 identified by a groupName. 325 The Access Control module assumes that the securityName has already 326 been authenticated as needed and provides no further authentication 327 of its own. 329 The View-based Access Control Model uses the securityModel and the 330 securityName as inputs to the Access Control module when called to 331 check for access rights. It determines the groupName as a function 332 of securityModel and securityName. 334 2.2. securityLevel 336 Different access rights for members of a group can be defined for 337 different levels of security, i.e., noAuthNoPriv, authNoPriv, and | 338 authPriv. The securityLevel identifies the level of security that | 339 will be assumed when checking for access rights. See the SNMP | 340 Architecture document [SNMP-ARCH] for a definition of securityLevel. | 342 The View-based Access Control Model requires that the securityLevel 343 is passed as input to the Access Control module when called to check 344 for access rights. 346 2.3. Contexts 348 An SNMP context is a collection of management information 349 accessible by an SNMP entity. An item of management information 350 may exist in more than one context. An SNMP entity potentially 351 has access to many contexts. Details about the naming of 352 management information can be found in the SNMP Architecture 353 document [SNMP-ARCH]. 355 The View-based Access Control Model defines a vacmContextTable that 356 lists the locally available contexts by contextName. 358 SNMPv3 Working Group Expires April 1998 [Page 9] 359 2.4. MIB Views and View Families 361 For security reasons, it is often valuable to be able to restrict 362 the access rights of some groups to only a subset of the management 363 information in the management domain. To provide this capability, 364 access to a context is via a "MIB view" which details a specific 365 set of managed object types (and optionally, the specific instances 366 of object types) within that context. For example, for a given 367 context, there will typically always be one MIB view which provides 368 access to all management information in that context, and often 369 there will be other MIB views each of which contains some subset of 370 the information. So, the access allowed for a group can be 371 restricted in the desired manner by specifying its rights in terms 372 of the particular (subset) MIB view it can access within each 373 appropriate context. 375 Since managed object types (and their instances) are identified via 376 the tree-like naming structure of ISO's OBJECT IDENTIFIERs 377 [ISO-ASN.1, RFC1902], it is convenient to define a MIB view as the 378 combination of a set of "view subtrees", where each view subtree is 379 a subtree within the managed object naming tree. Thus, a simple 380 MIB view (e.g., all managed objects within the Internet Network 381 Management Framework) can be defined as a single view subtree, 382 while more complicated MIB views (e.g., all information relevant to 383 a particular network interface) can be represented by the union of 384 multiple view subtrees. 386 While any set of managed objects can be described by the union of 387 some number of view subtrees, situations can arise that would 388 require a very large number of view subtrees. This could happen, 389 for example, when specifying all columns in one conceptual row of a 390 MIB table because they would appear in separate subtrees, one per 391 column, each with a very similar format. Because the formats are 392 similar, the required set of subtrees can easily be aggregated into 393 one structure. This structure is named a family of view subtrees 394 after the set of subtrees that it conceptually represents. A family 395 of view subtrees can either be included or excluded from a MIB view. 397 2.4.1. View Subtree 399 A view subtree is the set of all MIB object instances which have a 400 common ASN.1 OBJECT IDENTIFIER prefix to their names. A view 401 subtree is identified by the OBJECT IDENTIFIER value which is the 402 longest OBJECT IDENTIFIER prefix common to all (potential) MIB 403 object instances in that subtree. 405 2.4.2. ViewTreeFamily 407 A family of view subtrees is a pairing of an OBJECT IDENTIFIER value 408 (called the family name) together with a bit string value (called 409 the family mask). The family mask indicates which sub-identifiers 410 of the associated family name are significant to the family's 411 definition. 413 For each possible managed object instance, that instance belongs to 414 a particular ViewTreeFamily if both of the following conditions 415 are true: 417 - the OBJECT IDENTIFIER name of the managed object instance contains 418 at least as many sub-identifiers as does the family name, and 420 - each sub-identifier in the OBJECT IDENTIFIER name of the managed 421 object instance matches the corresponding sub-identifier of the 422 family name whenever the corresponding bit of the associated 423 family mask is non-zero. 425 When the configured value of the family mask is all ones, the view 426 subtree family is identical to the single view subtree identified 427 by the family name. 429 When the configured value of the family mask is shorter than 430 required to perform the above test, its value is implicitly 431 extended with ones. Consequently, a view subtree family having a 432 family mask of zero length always corresponds to a single view 433 subtree. 435 2.5. Access Policy 437 The View-based Access Control Model determines the access rights 438 of a group, representing zero or more securityNames which have 439 the same access rights. For a particular context, identified by 440 contextName, to which a group, identified by groupName, has access 441 using a particular securityModel and securityLevel, that group's 442 access rights are given by a read-view, a write-view and a 443 notify-view. 445 The read-view represents the set of object instances authorized for 446 the group when reading objects. Reading objects occurs when 447 processing a retrieval (for example a GetRequest, GetNextRequest, 448 GetBulkRequest) operation. 450 The write-view represents the set of object instances authorized for 451 the group when writing objects. Writing objects occurs when 452 processing a write (for example a Set) operation. 454 The notify-view represents the set of object instances authorized 455 for the group when sending objects in a notification, such as 456 when sending a notification (for example an Inform or SNMPv2-Trap). 458 3. Elements of Procedure 460 This section describes the procedures followed by an Access Control 461 module that implements the View-based Access Control Model when 462 checking access rights as requested by an application (for example 463 a Command Responder or a Notification Originator application). 464 The abstract service primitive is: 466 statusInformation = -- success or errorIndication 467 isAccessAllowed( 468 securityModel -- Security Model in use 469 securityName -- principal who wants access 470 securityLevel -- Level of Security 471 viewType -- read, write, or notify view 472 contextName -- context containing variableName 473 variableName -- OID for the managed object 474 ) 476 The abstract data elements are: 478 statusInformation - one of the following: 479 accessAllowed - a MIB view was found and access is granted. 480 notInView - a MIB view was found but access is denied. 481 The variableName is not in the configured 482 MIB view for the specified viewType (e.g., in | 483 the relevant entry in the vacmAccessTable). 484 noSuchView - no MIB view found because no view has been 485 configured for specified viewType (e.g., in | 486 the relevant entry in the vacmAccessTable). 487 noSuchContext - no MIB view found because of no entry in the 488 vacmContextTable for specified contextName. 489 noGroupName - no MIB view found because no entry has been 490 configured in the vacmSecurityToGroupTable 491 for the specified combination of 492 securityModel and securityName. 493 noAccessEntry - no MIB view found because no entry has been 494 configured in the vacmAccessTable for the 495 specified combination of contextName, 496 groupName (from vacmSecurityToGroupTable), 497 securityModel and securityLevel. 498 otherError - failure, an undefined error occurred. 499 securityModel - Security Model under which access is requested. 500 securityName - the principal on whose behalf access is requested. 501 securityLevel - Level of Security under which access is requested. 502 viewType - view to be checked (read, write or notify). 503 contextName - context in which access is requested. 504 variableName - object instance to which access is requested. 506 3.1. Overview of isAccessAllowed Process 508 The following picture shows how the decision for access control is | 509 made by the View-based Access Control Model. | 510 | 511 +--------------------------------------------------------------------+ 512 | | 513 | +-> securityModel -+ | 514 | | (a) | | 515 | who -+ +-> groupName ----+ | 516 | (1) | | (x) | | 517 | +-> securityName --+ | | 518 | (b) | | 519 | | | 520 | where -> contextName ---------------------+ | 521 | (2) (e) | | 522 | | | 523 | | | 524 | +-> securityModel -------------------+ | 525 | | (a) | | 526 | how -+ +-> viewName -+ | 527 | (3) | | (y) | | 528 | +-> securityLevel -------------------+ | | 529 | (c) | +-> yes/no | 530 | | | decision | 531 | why ---> viewType (read/write/notify) ----+ | (z) | 532 | (4) (d) | | 533 | | | 534 | what --> object-type ------+ | | 535 | (5) (m) | | | 536 | +-> variableName (OID) ------+ | 537 | | (f) | 538 | which -> object-instance --+ | 539 | (6) (n) | 540 | | 541 +--------------------------------------------------------------------+ 543 How the decision for isAccessAllowed is made. 545 1) Inputs to the isAccessAllowed service are: | 547 (a) securityModel -- Security Model in use 548 (b) securityName -- principal who wants to access 549 (c) securityLevel -- Level of Security 550 (d) viewType -- read, write, or notify view 551 (e) contextName -- context containing variableName 552 (f) variableName -- OID for the managed object 553 -- this is made up of: | 554 - object-type (m) | 555 - object-instance (n) | 557 2) The partial "who" (1), represented by the securityModel (a) and 558 the securityName (b), are used as the indices (a,b) into the 559 vacmSecurityToGroupTable to find a single entry that produces a 560 group, represented by groupName (x). 562 3) The "where" (2), represented by the contextName (e), the "who", | 563 represented by the groupName (x) from the previous step, and the 564 "how" (3), represented by securityModel (a) and securityLevel (c), 565 are used as indices (e,x,a,c) into the vacmAccessTable to find a 566 single entry that contains three MIB views. 568 4) The "why" (4), represented by the viewType (d), is used to select | 569 the proper MIB view, represented by a viewName (y), from the 570 vacmAccessEntry selected in the previous step. This viewName (y) 571 is an index into the vacmViewTreeFamilyTable and selects the set 572 of entries that define the variableNames which are included in 573 or excluded from the MIB view identified by the viewName (y). 575 5) The "what" (5) type of management data and "which" (6) particular | 576 instance, represented by the variableName (f), is then checked to 577 be in the MIB view or not, e.g., the yes/no decision (z). | 579 3.2. Processing the isAccessAllowed Service Request 581 This section describes the procedure followed by an Access Control 582 module that implements the View-based Access Control Model 583 whenever it receives an isAccessAllowed request. 585 1) The vacmContextTable is consulted for information about 586 the SNMP context identified by the contextName. If information 587 about this SNMP context is absent from the table, then an 588 errorIndication (noSuchContext) is returned to the calling 589 module. 591 2) The vacmSecurityToGroupTable is consulted for mapping the 592 securityModel and securityName to a groupName. If the 593 information about this combination is absent from the table, 594 then an errorIndication (noGroupName) is returned to the 595 calling module. 597 3) The vacmAccessTable is consulted for information about the 598 groupName, contextName, securityModel and securityLevel. If 599 information about this combination is absent from the table, 600 then an errorIndication (noAccessEntry) is returned to the 601 calling module. 603 4) a) If the viewType is "read", then the read view is used for 604 checking access rights. 606 b) If the viewType is "write", then the write view is used for 607 checking access rights. 609 c) If the viewType is "notify", then the notify view is used 610 for checking access rights. 612 If the view to be used is the empty view (zero length viewName) 613 then an errorIndication (noSuchView) is returned to the calling 614 module. 616 5) a) If there is no view configured for the specified viewType, 617 then an errorIndication (noSuchView) is returned to the 618 calling module. 620 b) If the specified variableName (object instance) is not in the 621 MIB view (see DESCRIPTION clause for vacmViewTreeFamilyTable 622 in section 4), then an errorIndication (notInView) is returned 623 to the calling module. 625 Otherwise, 627 c) The specified variableName is in the MIB view. 628 A statusInformation of success (accessAllowed) is returned 629 to the calling module. 631 4. Definitions 633 SNMP-VIEW-BASED-ACM-MIB DEFINITIONS ::= BEGIN 635 IMPORTS 636 MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF 637 MODULE-IDENTITY, OBJECT-TYPE, 638 snmpModules FROM SNMPv2-SMI 639 TestAndIncr, 640 RowStatus, StorageType FROM SNMPv2-TC 641 SnmpAdminString, 642 SnmpSecurityLevel, 643 SnmpSecurityModel FROM SNMP-FRAMEWORK-MIB; 645 snmpVacmMIB MODULE-IDENTITY 646 LAST-UPDATED "9709290000Z" -- 29 Sep 1997, midnight | 647 ORGANIZATION "SNMPv3 Working Group" 648 CONTACT-INFO "WG-email: snmpv3@tis.com 649 Subscribe: majordomo@tis.com 650 In message body: subscribe snmpv3 652 Chair: Russ Mundy 653 Trusted Information Systems 654 postal: 3060 Washington Rd 655 Glenwood MD 21738 656 USA 657 email: mundy@tis.com 658 phone: +1-301-854-6889 660 Co-editor: Bert Wijnen 661 IBM T.J. Watson Research 662 postal: Schagen 33 663 3461 GL Linschoten 664 Netherlands 665 email: wijnen@vnet.ibm.com 666 phone: +31-348-432-794 668 Co-editor: Randy Presuhn 669 BMC Software, Inc 670 postal: 1190 Saratoga Avenue, Suite 130 671 San Jose, CA 95129-3433 672 USA 673 email: rpresuhn@bmc.com 674 phone: +1-408-556-0720 676 Co-editor: Keith McCloghrie 677 Cisco Systems, Inc. 678 postal: 170 West Tasman Drive 679 San Jose, CA 95134-1706 680 USA 681 email: kzm@cisco.com 682 phone: +1-408-526-5260 683 " 684 DESCRIPTION "The management information definitions for the 685 View-based Access Control Model for SNMP. 686 " 687 ::= { snmpModules 10 } -- to be verified with IANA 689 -- Administrative assignments **************************************** 691 vacmMIBObjects OBJECT IDENTIFIER ::= { snmpVacmMIB 1 } 692 vacmMIBConformance OBJECT IDENTIFIER ::= { snmpVacmMIB 2 } 694 -- Information about Local Contexts ********************************** 696 vacmContextTable OBJECT-TYPE 697 SYNTAX SEQUENCE OF VacmContextEntry 698 MAX-ACCESS not-accessible 699 STATUS current 700 DESCRIPTION "The table of locally available contexts. 702 This table provides information to SNMP Command 703 Generator applications so that they can properly 704 configure the vacmAccessTable to control access to 705 all contexts at the SNMP entity. 707 This table may change dynamically if the SNMP entity 708 allows that contexts are added/deleted dynamically 709 (for instance when its configuration changes). Such 710 changes would happen only if the management 711 instrumentation at that SNMP entity recognizes more 712 (or fewer) contexts. 714 The presence of entries in this table and of entries 715 in the vacmAccessTable are independent. That is, a 716 context identified by an entry in this table is not | 717 necessarily referenced by any entries in the | 718 vacmAccessTable; and the context(s) referenced by an 719 entry in the vacmAccessTable does not necessarily | 720 currently exist and thus need not be identified by an | 721 entry in this table. | 723 This table must be made accessible via the default 724 context so that Command Responder applications have 725 a standard way of retrieving the information. 727 This table is read-only. It cannot be configured via 728 SNMP. 729 " 730 ::= { vacmMIBObjects 1 } 732 vacmContextEntry OBJECT-TYPE 733 SYNTAX VacmContextEntry 734 MAX-ACCESS not-accessible 735 STATUS current 736 DESCRIPTION "Information about a particular context." 737 INDEX { 738 vacmContextName 739 } 740 ::= { vacmContextTable 1 } 742 VacmContextEntry ::= SEQUENCE 743 { 744 vacmContextName SnmpAdminString 745 } 747 vacmContextName OBJECT-TYPE 748 SYNTAX SnmpAdminString (SIZE(0..32)) 749 MAX-ACCESS read-only 750 STATUS current 751 DESCRIPTION "A human readable name identifying a particular 752 context at a particular SNMP entity. 753 | 754 The empty contextName (zero length) represents the | 755 default context. | 756 " 757 ::= { vacmContextEntry 1 } 759 -- Information about Groups ****************************************** 761 vacmSecurityToGroupTable OBJECT-TYPE 762 SYNTAX SEQUENCE OF VacmSecurityToGroupEntry 763 MAX-ACCESS not-accessible 764 STATUS current 765 DESCRIPTION "This table maps a combination of securityModel and 766 securityName into a groupName which is used to define 767 an access control policy for a group of principals. 768 " 769 ::= { vacmMIBObjects 2 } 771 vacmSecurityToGroupEntry OBJECT-TYPE 772 SYNTAX VacmSecurityToGroupEntry 773 MAX-ACCESS not-accessible 774 STATUS current 775 DESCRIPTION "An entry in this table maps the combination of a 776 securityModel and securityName into a groupName. 777 " 778 INDEX { 779 vacmSecurityModel, 780 vacmSecurityName 781 } 782 ::= { vacmSecurityToGroupTable 1 } 784 VacmSecurityToGroupEntry ::= SEQUENCE 785 { 786 vacmSecurityModel SnmpSecurityModel, 787 vacmSecurityName SnmpAdminString, 788 vacmGroupName SnmpAdminString, 789 vacmSecurityToGroupStorageType StorageType, 790 vacmSecurityToGroupStatus RowStatus 791 } 793 vacmSecurityModel OBJECT-TYPE 794 SYNTAX SnmpSecurityModel(1..2147483647) | 795 MAX-ACCESS not-accessible 796 STATUS current 797 DESCRIPTION "The Security Model, by which the vacmSecurityName 798 referenced by this entry is provided. 800 Note, this object may not take the 'any' (0) value. | 801 " 802 ::= { vacmSecurityToGroupEntry 1 } 804 vacmSecurityName OBJECT-TYPE 805 SYNTAX SnmpAdminString (SIZE(1..32)) 806 MAX-ACCESS not-accessible 807 STATUS current 808 DESCRIPTION "The securityName for the principal, represented in a 809 Security Model independent format, which is mapped by 810 this entry to a groupName. 812 The securityName for a principal represented in a 813 Security Model independent format. 814 " 815 ::= { vacmSecurityToGroupEntry 2 } 817 vacmGroupName OBJECT-TYPE 818 SYNTAX SnmpAdminString (SIZE(1..32)) 819 MAX-ACCESS read-create 820 STATUS current 821 DESCRIPTION "The name of the group to which this entry (e.g., the | 822 combination of securityModel and securityName) 823 belongs. 825 This groupName is used as index into the 826 vacmAccessTable to select an access control policy. 827 " 828 ::= { vacmSecurityToGroupEntry 3 } 830 vacmSecurityToGroupStorageType OBJECT-TYPE 831 SYNTAX StorageType 832 MAX-ACCESS read-create 833 STATUS current 834 DESCRIPTION "The storage type for this conceptual row. 836 Conceptual rows having the value 'permanent' need not 837 allow write-access to any columnar objects in the row. 838 " 839 DEFVAL { nonVolatile } 840 ::= { vacmSecurityToGroupEntry 4 } 842 vacmSecurityToGroupStatus OBJECT-TYPE 843 SYNTAX RowStatus 844 MAX-ACCESS read-create 845 STATUS current 846 DESCRIPTION "The status of this conceptual row. 848 The RowStatus TC [RFC1903] requires that this 849 DESCRIPTION clause states under which circumstances 850 other objects in this row can be modified: 852 The value of this object has no effect on whether 853 other objects in this conceptual row can be modified. 854 " 855 ::= { vacmSecurityToGroupEntry 5 } 857 -- Information about Access Rights *********************************** 859 vacmAccessTable OBJECT-TYPE 860 SYNTAX SEQUENCE OF VacmAccessEntry 861 MAX-ACCESS not-accessible 862 STATUS current 863 DESCRIPTION "The table of access rights for groups. 865 Each entry is indexed by a contextPrefix, a groupName 866 a securityModel and a securityLevel. To determine 867 whether access is allowed, one entry from this table 868 needs to be selected and the proper viewName from that 869 entry must be used for access control checking. 871 To select the proper entry, follow these steps: | 872 | 873 1) the set of possible matches is formed by the | 874 intersection of the following sets of entries: | 875 the set of entries with identical vacmGroupName | 876 the union of these two sets: | 877 - the set with identical vacmAccessContextPrefix | 878 - the set of entries with vacmAccessContextMatch | 879 value of 'prefix' and matching | 880 vacmAccessContextPrefix | 881 intersected with the union of these two sets: | 882 - the set of entries with identical | 883 vacmSecurityModel | 884 - the set of entries with vacmSecurityModel | 885 value of 'any' | 887 intersected with the set of entries with | 888 vacmAccessSecurityLevel value less than or equal 2 889 to the requested securityLevel 2 890 | 891 2) if this set has only one member, we're done | 892 otherwise, it comes down to deciding how to weight | 893 the preferences between ContextPrefixes, | 894 SecurityModels, and SecurityLevels as follows: | 895 a) if the subset of entries with identical | 896 securityModels is not empty, discard the rest. | 897 b) if the subset of entries with identical | 898 vacmAccessContextPrefix is not empty, | 899 discard the rest | 900 c) discard all entries with ContextPrefixes shorter | 901 than the longest one remaining in the set | 902 d) select the entry with the highest securityLevel | 903 | 904 Please note that for securityLevel noAuthNoPriv, all | 905 groups are really equivalent since the assumption that | 906 the securityName has been authenticated does not hold. | 907 " 908 ::= { vacmMIBObjects 4 } 910 vacmAccessEntry OBJECT-TYPE 911 SYNTAX VacmAccessEntry 912 MAX-ACCESS not-accessible 913 STATUS current 914 DESCRIPTION "An access right configured in the Local Configuration 915 Datastore (LCD) authorizing access to an SNMP context. 916 " 917 INDEX { vacmGroupName, 918 vacmAccessContextPrefix, 919 vacmAccessSecurityModel, | 920 vacmAccessSecurityLevel 921 } 922 ::= { vacmAccessTable 1 } 924 VacmAccessEntry ::= SEQUENCE 925 { 926 vacmAccessContextPrefix SnmpAdminString, 927 vacmAccessSecurityModel SnmpSecurityModel, | 928 vacmAccessSecurityLevel SnmpSecurityLevel, 929 vacmAccessContextMatch INTEGER, 930 vacmAccessReadViewName SnmpAdminString, 931 vacmAccessWriteViewName SnmpAdminString, 932 vacmAccessNotifyViewName SnmpAdminString, 933 vacmAccessStorageType StorageType, 934 vacmAccessStatus RowStatus 935 } 937 vacmAccessContextPrefix OBJECT-TYPE 938 SYNTAX SnmpAdminString (SIZE(0..32)) 939 MAX-ACCESS not-accessible 940 STATUS current 941 DESCRIPTION "In order to gain the access rights allowed by this 942 conceptual row, a contextName must match exactly 943 (if the value of vacmAccessContextMatch is 'exact') 944 or partially (if the value of vacmAccessContextMatch 945 is 'prefix') to the value of the instance of this 946 object. 947 " 948 ::= { vacmAccessEntry 1 } 950 vacmAccessSecurityModel OBJECT-TYPE | 951 SYNTAX SnmpSecurityModel | 952 MAX-ACCESS not-accessible | 953 STATUS current | 954 DESCRIPTION "In order to gain the access rights allowed by this | 955 conceptual row, this securityModel must be in use. | 956 " | 957 ::= { vacmAccessEntry 2 } | 959 vacmAccessSecurityLevel OBJECT-TYPE 960 SYNTAX SnmpSecurityLevel 961 MAX-ACCESS not-accessible 962 STATUS current 963 DESCRIPTION "The minimum level of security required in order to 964 gain the access rights allowed by this conceptual 965 row. A securityLevel of noAuthNoPriv is less than 966 authNoPriv which in turn is less than authPriv. 968 If multiple entries are equally indexed except for 969 this vacmAccessSecurityLevel index, then the entry 970 which has the highest value for 971 vacmAccessSecurityLevel wins. 972 " 973 ::= { vacmAccessEntry 3 } | 975 vacmAccessContextMatch OBJECT-TYPE 976 SYNTAX INTEGER 977 { exact (1), -- exact match of prefix and contextName 978 prefix (2) -- Only match to the prefix 979 } 980 MAX-ACCESS read-create 981 STATUS current 982 DESCRIPTION "If the value of this object is exact(1), then all 983 rows where the contextName exactly matches 984 vacmAccessContextPrefix are selected. 986 If the value of this object is prefix(2), then all 987 rows where the contextName whose starting octets 988 exactly match vacmAccessContextPrefix are selected. 990 This allows for a simple form of wildcarding. 991 See also the example in the DESCRIPTION clause of 992 the vacmAccessTable above. 993 " 994 ::= { vacmAccessEntry 4 } | 996 vacmAccessReadViewName OBJECT-TYPE 997 SYNTAX SnmpAdminString (SIZE(0..32)) 998 MAX-ACCESS read-create 999 STATUS current 1000 DESCRIPTION "The value of an instance of this object identifies 1001 the MIB view of the SNMP context to which this 1002 conceptual row authorizes read access. 1004 The identified MIB view is that one for which the 1005 vacmViewTreeFamilyViewName has the same value as the 1006 instance of this object; if the value is the empty 1007 string or if there is no active MIB view having this 1008 value of vacmViewTreeFamilyViewName, then no access 1009 is granted. 1010 " 1011 DEFVAL { ''H } -- the empty string 1012 ::= { vacmAccessEntry 5 } | 1014 vacmAccessWriteViewName OBJECT-TYPE 1015 SYNTAX SnmpAdminString (SIZE(0..32)) 1016 MAX-ACCESS read-create 1017 STATUS current 1018 DESCRIPTION "The value of an instance of this object identifies 1019 the MIB view of the SNMP context to which this 1020 conceptual row authorizes write access. 1022 The identified MIB view is that one for which the 1023 vacmViewTreeFamilyViewName has the same value as the 1024 instance of this object; if the value is the empty 1025 string or if there is no active MIB view having this 1026 value of vacmViewTreeFamilyViewName, then no access 1027 is granted. 1028 " 1029 DEFVAL { ''H } -- the empty string 1030 ::= { vacmAccessEntry 6 } | 1032 vacmAccessNotifyViewName OBJECT-TYPE 1033 SYNTAX SnmpAdminString (SIZE(0..32)) 1034 MAX-ACCESS read-create 1035 STATUS current 1036 DESCRIPTION "The value of an instance of this object identifies 1037 the MIB view of the SNMP context to which this 1038 conceptual row authorizes access for notifications. 1040 The identified MIB view is that one for which the 1041 vacmViewTreeFamilyViewName has the same value as the 1042 instance of this object; if the value is the empty 1043 string or if there is no active MIB view having this 1044 value of vacmViewTreeFamilyViewName, then no access 1045 is granted. 1046 " 1047 DEFVAL { ''H } -- the empty string 1048 ::= { vacmAccessEntry 7 } | 1050 vacmAccessStorageType OBJECT-TYPE 1051 SYNTAX StorageType 1052 MAX-ACCESS read-create 1053 STATUS current 1054 DESCRIPTION "The storage type for this conceptual row. 1056 Conceptual rows having the value 'permanent' need not 1057 allow write-access to any columnar objects in the row. 1058 " 1059 DEFVAL { nonVolatile } 1060 ::= { vacmAccessEntry 8 } | 1062 vacmAccessStatus OBJECT-TYPE 1063 SYNTAX RowStatus 1064 MAX-ACCESS read-create 1065 STATUS current 1066 DESCRIPTION "The status of this conceptual row. 1068 The RowStatus TC [RFC1903] requires that this 1069 DESCRIPTION clause states under which circumstances 1070 other objects in this row can be modified: 1072 The value of this object has no effect on whether 1073 other objects in this conceptual row can be modified. 1074 " 1075 ::= { vacmAccessEntry 9 } | 1077 -- Information about MIB views *************************************** 1079 -- Support for instance-level granularity is optional. | 1080 -- | 1081 -- In some implementations, instance-level access control | 1082 -- granularity may come at a high performance cost. Managers | 1083 -- should avoid requesting such configurations unnecessarily. | 1085 vacmMIBViews OBJECT IDENTIFIER ::= { vacmMIBObjects 5 } 1087 vacmViewSpinLock OBJECT-TYPE 1088 SYNTAX TestAndIncr 1089 MAX-ACCESS read-write 1090 STATUS current 1091 DESCRIPTION "An advisory lock used to allow cooperating SNMP 1092 Command Generator applications to coordinate their 1093 use of the Set operation in creating or modifying | 1094 views. | 1096 When creating a new view or altering an existing 1097 view, it is important to understand the potential 1098 interactions with other uses of the view. The 1099 vacmViewSpinLock should be retrieved. The name of 1100 the view to be created should be determined to be 1101 unique by the SNMP Command Generator application by 1102 consulting the vacmViewTreeFamilyTable. Finally, 1103 the named view may be created (Set), including the 1104 advisory lock. 1105 If another SNMP Command Generator application has 1106 altered the views in the meantime, then the spin 1107 lock's value will have changed, and so this creation 1108 will fail because it will specify the wrong value for 1109 the spin lock. 1111 Since this is an advisory lock, the use of this lock 1112 is not enforced. 1113 " 1114 ::= { vacmMIBViews 1 } 1116 vacmViewTreeFamilyTable OBJECT-TYPE 1117 SYNTAX SEQUENCE OF VacmViewTreeFamilyEntry 1118 MAX-ACCESS not-accessible 1119 STATUS current 1120 DESCRIPTION "Locally held information about families of subtrees 1121 within MIB views. 1123 Each MIB view is defined by two sets of view subtrees: 1124 - the included view subtrees, and 1125 - the excluded view subtrees. 1126 Every such view subtree, both the included and the 1127 excluded ones, is defined in this table. 1129 To determine if a particular object instance is in 1130 a particular MIB view, compare the object instance's 1131 OBJECT IDENTIFIER with each of the MIB view's active 1132 entries in this table. If none match, then the 1133 object instance is not in the MIB view. If one or 1134 more match, then the object instance is included in, 1135 or excluded from, the MIB view according to the 1136 value of vacmViewTreeFamilyType in the entry whose 1137 value of vacmViewTreeFamilySubtree has the most 1138 sub-identifiers. If multiple entries match and have 1139 the same number of sub-identifiers, then the 1140 lexicographically greatest instance of 1141 vacmViewTreeFamilyType determines the inclusion or 1142 exclusion. 1144 An object instance's OBJECT IDENTIFIER X matches an 1145 active entry in this table when the number of 1146 sub-identifiers in X is at least as many as in the 1147 value of vacmViewTreeFamilySubtree for the entry, 1148 and each sub-identifier in the value of 1149 vacmViewTreeFamilySubtree matches its corresponding 1150 sub-identifier in X. Two sub-identifiers match 1151 either if the corresponding bit of the value of 1152 vacmViewTreeFamilyMask for the entry is zero (the 1153 'wild card' value), or if they are equal. 1155 A 'family' of subtrees is the set of subtrees defined 1156 by a particular combination of values of 1157 vacmViewTreeFamilySubtree and vacmViewTreeFamilyMask. 1158 In the case where no 'wild card' is defined in the 1159 vacmViewTreeFamilyMask, the family of subtrees reduces 1160 to a single subtree. 1162 When creating or changing MIB views, an SNMP Command 1163 Generator application should utilize the 1164 vacmViewSpinLock to try to avoid collisions. See 1165 DESCRIPTION clause of vacmViewSpinLock. 1167 When creating MIB views, it is strongly advised that 1168 first the 'excluded' vacmViewTreeFamilyEntries are 1169 created and then the 'included' entries. 1171 When deleting MIB views, it is strongly advised that 1172 first the 'included' vacmViewTreeFamilyEntries are 1173 deleted and then the 'excluded' entries. 1174 | 1175 If a create for an entry for instance-level access | 1176 control is received and the implementation does not | 1177 support instance-level granularity, then an | 1178 inconsistentName error must be returned. | 1179 " 1180 ::= { vacmMIBViews 2 } 1182 vacmViewTreeFamilyEntry OBJECT-TYPE 1183 SYNTAX VacmViewTreeFamilyEntry 1184 MAX-ACCESS not-accessible 1185 STATUS current 1186 DESCRIPTION "Information on a particular family of view subtrees 1187 included in or excluded from a particular SNMP 1188 context's MIB view. 1190 Implementations must not restrict the number of 1191 families of view subtrees for a given MIB view, 1192 except as dictated by resource constraints on the 1193 overall number of entries in the 1194 vacmViewTreeFamilyTable. 1196 If no conceptual rows exist in this table for a given | 1197 MIB view (viewName), that view may be thought of as | 1198 consisting of the empty set of view subtrees. | 1199 " 1200 INDEX { vacmViewTreeFamilyViewName, 1201 vacmViewTreeFamilySubtree 1202 } 1203 ::= { vacmViewTreeFamilyTable 1 } 1205 VacmViewTreeFamilyEntry ::= SEQUENCE 1206 { 1207 vacmViewTreeFamilyViewName SnmpAdminString, 1208 vacmViewTreeFamilySubtree OBJECT IDENTIFIER, 1209 vacmViewTreeFamilyMask OCTET STRING, 1210 vacmViewTreeFamilyType INTEGER, 1211 vacmViewTreeFamilyStorageType StorageType, 1212 vacmViewTreeFamilyStatus RowStatus 1213 } 1215 vacmViewTreeFamilyViewName OBJECT-TYPE 1216 SYNTAX SnmpAdminString (SIZE(1..32)) 1217 MAX-ACCESS not-accessible 1218 STATUS current 1219 DESCRIPTION "The human readable name for a family of view subtrees. 1220 " 1221 ::= { vacmViewTreeFamilyEntry 1 } 1223 vacmViewTreeFamilySubtree OBJECT-TYPE 1224 SYNTAX OBJECT IDENTIFIER 1225 MAX-ACCESS not-accessible 1226 STATUS current 1227 DESCRIPTION "The MIB subtree which when combined with the 1228 corresponding instance of vacmViewTreeFamilyMask 1229 defines a family of view subtrees. 1230 " 1231 ::= { vacmViewTreeFamilyEntry 2 } 1233 vacmViewTreeFamilyMask OBJECT-TYPE 1234 SYNTAX OCTET STRING (SIZE (0..16)) 1235 MAX-ACCESS read-create 1236 STATUS current 1237 DESCRIPTION "The bit mask which, in combination with the 1238 corresponding instance of vacmViewTreeFamilySubtree, 1239 defines a family of view subtrees. 1241 Each bit of this bit mask corresponds to a 1242 sub-identifier of vacmViewTreeFamilySubtree, with the 1243 most significant bit of the i-th octet of this octet 1244 string value (extended if necessary, see below) 1245 corresponding to the (8*i - 7)-th sub-identifier, and 1246 the least significant bit of the i-th octet of this 1247 octet string corresponding to the (8*i)-th 1248 sub-identifier, where i is in the range 1 through 16. 1250 Each bit of this bit mask specifies whether or not 1251 the corresponding sub-identifiers must match when 1252 determining if an OBJECT IDENTIFIER is in this 1253 family of view subtrees; a '1' indicates that an 1254 exact match must occur; a '0' indicates 'wild card', 1255 i.e., any sub-identifier value matches. 1257 Thus, the OBJECT IDENTIFIER X of an object instance 1258 is contained in a family of view subtrees if, for 1259 each sub-identifier of the value of 1260 vacmViewTreeFamilySubtree, either: 1262 the i-th bit of vacmViewTreeFamilyMask is 0, or 1264 the i-th sub-identifier of X is equal to the i-th 1265 sub-identifier of the value of 1266 vacmViewTreeFamilySubtree. 1268 If the value of this bit mask is M bits long and 1269 there are more than M sub-identifiers in the 1270 corresponding instance of vacmViewTreeFamilySubtree, 1271 then the bit mask is extended with 1's to be the 1272 required length. 1274 Note that when the value of this object is the 1275 zero-length string, this extension rule results in 1276 a mask of all-1's being used (i.e., no 'wild card'), 1277 and the family of view subtrees is the one view 1278 subtree uniquely identified by the corresponding 1279 instance of vacmViewTreeFamilySubtree. 1281 Note that masks of length greater than zero length 1282 do not need to be supported. In this case this | 1283 object is made read-only. | 1284 " 1285 DEFVAL { ''H } 1286 ::= { vacmViewTreeFamilyEntry 3 } 1288 vacmViewTreeFamilyType OBJECT-TYPE 1289 SYNTAX INTEGER { included(1), excluded(2) } 1290 MAX-ACCESS read-create 1291 STATUS current 1292 DESCRIPTION "Indicates whether the corresponding instances of 1293 vacmViewTreeFamilySubtree and vacmViewTreeFamilyMask 1294 define a family of view subtrees which is included in 1295 or excluded from the MIB view. 1297 " 1298 DEFVAL { included } 1299 ::= { vacmViewTreeFamilyEntry 4 } 1301 vacmViewTreeFamilyStorageType OBJECT-TYPE 1302 SYNTAX StorageType 1303 MAX-ACCESS read-create 1304 STATUS current 1305 DESCRIPTION "The storage type for this conceptual row. 1307 Conceptual rows having the value 'permanent' need not 1308 allow write-access to any columnar objects in the row. 1309 " 1310 DEFVAL { nonVolatile } 1311 ::= { vacmViewTreeFamilyEntry 5 } 1313 vacmViewTreeFamilyStatus OBJECT-TYPE 1314 SYNTAX RowStatus 1315 MAX-ACCESS read-create 1316 STATUS current 1317 DESCRIPTION "The status of this conceptual row. 1319 The RowStatus TC [RFC1903] requires that this 1320 DESCRIPTION clause states under which circumstances 1321 other objects in this row can be modified: 1323 The value of this object has no effect on whether 1324 other objects in this conceptual row can be modified. 1325 " 1326 ::= { vacmViewTreeFamilyEntry 6 } 1328 -- Conformance information ******************************************* 1330 vacmMIBCompliances OBJECT IDENTIFIER ::= { vacmMIBConformance 1 } 1331 vacmMIBGroups OBJECT IDENTIFIER ::= { vacmMIBConformance 2 } 1333 -- Compliance statements ********************************************* 1335 vacmMIBCompliance MODULE-COMPLIANCE 1336 STATUS current 1337 DESCRIPTION "The compliance statement for SNMP engines which 1338 implement the SNMP View-based Access Control Model 1339 configuration MIB. 1340 " 1341 MODULE -- this module 1342 MANDATORY-GROUPS { vacmBasicGroup } 1344 OBJECT vacmAccessContextMatch 1345 MIN-ACCESS read-only 1346 DESCRIPTION "Write access is not required." 1347 OBJECT vacmAccessReadViewName 1348 MIN-ACCESS read-only 1349 DESCRIPTION "Write access is not required." 1351 OBJECT vacmAccessWriteViewName 1352 MIN-ACCESS read-only 1353 DESCRIPTION "Write access is not required." 1355 OBJECT vacmAccessNotifyViewName 1356 MIN-ACCESS read-only 1357 DESCRIPTION "Write access is not required." 1359 OBJECT vacmAccessStorageType 1360 MIN-ACCESS read-only 1361 DESCRIPTION "Write access is not required." 1363 OBJECT vacmAccessStatus 1364 MIN-ACCESS read-only 1365 DESCRIPTION "Create/delete/modify access to the | 1366 vacmAccessTable is not required. | 1367 " 1369 OBJECT vacmViewTreeFamilyMask 1370 WRITE-SYNTAX OCTET STRING (SIZE (0)) 1371 MIN-ACCESS read-only 1372 DESCRIPTION "Support for configuration via SNMP of subtree 1373 families using wild-cards is not required. 1374 " 1376 OBJECT vacmViewTreeFamilyType 1377 MIN-ACCESS read-only 1378 DESCRIPTION "Write access is not required." 1380 OBJECT vacmViewTreeFamilyStorageType 1381 MIN-ACCESS read-only 1382 DESCRIPTION "Write access is not required." 1384 OBJECT vacmViewTreeFamilyStatus 1385 MIN-ACCESS read-only 1386 DESCRIPTION "Create/delete/modify access to the | 1387 vacmViewTreeFamilyTable is not required. | 1388 " 1389 ::= { vacmMIBCompliances 1 } 1391 -- Units of conformance ********************************************** 1393 vacmBasicGroup OBJECT-GROUP 1394 OBJECTS { 1395 vacmContextName, 1396 vacmGroupName, 1397 vacmSecurityToGroupStorageType, 1398 vacmSecurityToGroupStatus, 1399 vacmAccessContextMatch, 1400 vacmAccessReadViewName, 1401 vacmAccessWriteViewName, 1402 vacmAccessNotifyViewName, 1403 vacmAccessStorageType, 1404 vacmAccessStatus, 1405 vacmViewSpinLock, 1406 vacmViewTreeFamilyMask, 1407 vacmViewTreeFamilyType, 1408 vacmViewTreeFamilyStorageType, 1409 vacmViewTreeFamilyStatus 1410 } 1411 STATUS current 1412 DESCRIPTION "A collection of objects providing for remote 1413 configuration of an SNMP engine which implements 1414 the SNMP View-based Access Control Model. 1415 " 1416 ::= { vacmMIBGroups 1 } 1418 END 1419 5. Intellectual Property 1421 The IETF takes no position regarding the validity or scope of any 3 1422 intellectual property or other rights that might be claimed to 3 1423 pertain to the implementation or use of the technology described in 3 1424 this document or the extent to which any license under such rights 3 1425 might or might not be available; neither does it represent that it 3 1426 has made any effort to identify any such rights. Information on the 3 1427 IETF's procedures with respect to rights in standards-track and 3 1428 standards-related documentation can be found in BCP-11. Copies of 3 1429 claims of rights made available for publication and any assurances of 3 1430 licenses to be made available, or the result of an attempt made to 3 1431 obtain a general license or permission for the use of such 3 1432 proprietary rights by implementors or users of this specification can 3 1433 be obtained from the IETF Secretariat. 3 1434 3 1435 The IETF invites any interested party to bring to its attention any 3 1436 copyrights, patents or patent applications, or other proprietary 3 1437 rights which may cover technology that may be required to practice 3 1438 this standard. Please address the information to the IETF Executive 3 1439 Director. 3 1441 6. Acknowledgements 3 1443 This document is the result of the efforts of the SNMPv3 Working Group. 1444 Some special thanks are in order to the following SNMPv3 WG members: 1446 Dave Battle (SNMP Research, Inc.) 1447 Uri Blumenthal (IBM T.J. Watson Research Center) 1448 Jeff Case (SNMP Research, Inc.) 1449 John Curran (BBN) 1450 T. Max Devlin (Hi-TECH Connections) 1451 John Flick (Hewlett Packard) 1452 David Harrington (Cabletron Systems Inc.) 1453 N.C. Hien (IBM T.J. Watson Research Center) 1454 Dave Levi (SNMP Research, Inc.) 1455 Louis A Mamakos (UUNET Technologies Inc.) 1456 Paul Meyer (Secure Computing Corporation) 1457 Keith McCloghrie (Cisco Systems) 1458 Russ Mundy (Trusted Information Systems, Inc.) 1459 Bob Natale (ACE*COMM Corporation) 1460 Mike O'Dell (UUNET Technologies Inc.) 1461 Dave Perkins (DeskTalk) 1462 Peter Polkinghorne (Brunel University) 1463 Randy Presuhn (BMC Software, Inc.) 1464 David Reid (SNMP Research, Inc.) 1465 Shawn Routhier (Epilogue) 1466 Juergen Schoenwaelder (TU Braunschweig) 1467 Bob Stewart (Cisco Systems) 1468 Bert Wijnen (IBM T.J. Watson Research Center) 1470 The document is based on recommendations of the IETF Security and 1471 Administrative Framework Evolution for SNMP Advisory Team. 1472 Members of that Advisory Team were: 1474 David Harrington (Cabletron Systems Inc.) 1475 Jeff Johnson (Cisco Systems) 1476 David Levi (SNMP Research Inc.) 1477 John Linn (Openvision) 1478 Russ Mundy (Trusted Information Systems) chair 1479 Shawn Routhier (Epilogue) 1480 Glenn Waters (Nortel) 1481 Bert Wijnen (IBM T. J. Watson Research Center) 1483 As recommended by the Advisory Team and the SNMPv3 Working Group 1484 Charter, the design incorporates as much as practical from previous 1485 RFCs and drafts. As a result, special thanks are due to the authors 1486 of previous designs known as SNMPv2u and SNMPv2*: 1488 Jeff Case (SNMP Research, Inc.) 1489 David Harrington (Cabletron Systems Inc.) 1490 David Levi (SNMP Research, Inc.) 1491 Keith McCloghrie (Cisco Systems) 1492 Brian O'Keefe (Hewlett Packard) 1493 Marshall T. Rose (Dover Beach Consulting) 1494 Jon Saperia (BGS Systems Inc.) 1495 Steve Waldbusser (International Network Services) 1496 Glenn W. Waters (Bell-Northern Research Ltd.) 1498 7. Security Considerations 3 1500 7.1. Recommended Practices 3 1502 This document is meant for use in the SNMP architecture. The 1503 View-based Access Control Model described in this document checks 1504 access rights to management information based on: 1506 - contextName, representing a set of management information at the 1507 managed system where the Access Control module is running. 1508 - groupName, representing a set of zero or more securityNames. 1509 The combination of a securityModel and a securityName is mapped 1510 into a group in the View-based Access Control Model. 1511 - securityModel under which access is requested. 1512 - securityLevel under which access is requested. 1513 - operation performed on the management information. 1514 - MIB views for read, write or notify access. 1516 When the User-based Access Control module is called for checking 1517 access rights, it is assumed that the calling module has ensured 1518 the authentication and privacy aspects as specified by the 1519 securityLevel that is being passed. 1521 When creating entries in or deleting entries from the | 1522 vacmViewFamiliyTreeTable it is important to do such in the sequence 2 1523 as recommended in the DESCRIPTION clause of the vacmViewFamilityTable 2 1524 definition. Otherwise unwanted access may be granted while changing | 1525 the entries in the table. | 1527 7.2. Defining Groups 3 1529 The groupNames are used to give access to a group of zero or more 1530 securityNames. Within the View-Based Access Control Model, a 1531 groupName is considered to exist if that groupName is listed in the 1532 vacmSecurityToGroupTable. 1534 By mapping the combination of a securityModel and securityName into 1535 a groupName, an SNMP Command Generator application can add/delete 1536 securityNames to/from a group, if proper access is allowed. 1537 | 1538 Further it is important to realize that the grouping of | 1539 tuples in the vacmSecurityToGroupTable 2 1540 does not take securityLevel into account. It is therefore important | 1541 that the security administrator uses the securityLevel index in the | 1542 vacmAccessTable to separate noAuthNoPriv from authPriv and/or 2 1543 authNoPriv access. 1545 7.3. Conformance 3 1547 For an implementation of the View-based Access Control Model to be 1548 conformant, it MUST implement the SNMP-VIEW-BASED-ACM-MIB. It also 1549 SHOULD implement the initial configuration, described in appendix A. | 1551 8. References 1552 3 1553 [RFC1902] The SNMPv2 Working Group, Case, J., McCloghrie, K., 1554 Rose, M., and S., Waldbusser, "Structure of Management 1555 Information for Version 2 of the Simple Network Management 1556 Protocol (SNMPv2)", RFC 1902, January 1996. 1558 [RFC1903] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., | 1559 and S. Waldbusser, "Textual Conventions for Version 2 of the Simple | 1560 Network Management Protocol (SNMPv2)", RFC 1903, January 1996. | 1561 | 1562 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2 1563 Requirement Levels", BCP 14, RFC 2119, March 1997. 3 1565 [SNMP-ARCH] The SNMPv3 Working Group, Harrington, D., Wijnen, B., 2 1566 Presuhn, R., "An Architecture for describing SNMP Management 2 1567 Frameworks", draft-ietf-snmpv3-next-gen-arch-06.txt, 3 1568 October 1997. 3 1570 [SNMP-MPD] The SNMPv3 Working Group, Case, J., Harrington, D., 2 1571 Wijnen, B., Presuhn, R., "Message Processing and Dispatching for 2 1572 the Simple Network Management Protocol (SNMP)", 2 1573 draft-ietf-snmpv3-v3mpc-model-06.txt, October 1997. 3 1575 [ISO-ASN.1] Information processing systems - Open Systems 1576 Interconnection - Specification of Abstract Syntax Notation One 1577 (ASN.1), International Organization for Standardization. 1578 International Standard 8824, (December, 1987). 1580 9. Editors' Addresses 3 1582 Co-editor: Bert Wijnen 1583 IBM T. J. Watson Research 1584 postal: Schagen 33 1585 3461 GL Linschoten 1586 Netherlands 1587 email: wijnen@vnet.ibm.com 1588 phone: +31-348-432-794 1590 Co-editor: Randy Presuhn 1591 BMC Software, Inc 1592 postal: 1190 Saratoga Avenue, Suite 130 1593 San Jose, CA 95129-3433 1594 USA 1595 email: rpresuhn@bmc.com 1596 phone: +1-408-556-0720 1598 Co-editor: Keith McCloghrie 1599 Cisco Systems, Inc. 1600 postal: 170 West Tasman Drive 1601 San Jose, CA 95134-1706 1602 USA 1603 email: kzm@cisco.com 1604 phone: +1-408-526-5260 1606 APPENDIX A - Installation 1608 A.1. Installation Parameters 1610 During installation, an authoritative SNMP engine which supports this | 1611 View-based Access Control Model SHOULD be configured with several | 1612 initial parameters. | 1613 These include for the View-based Access Control Model: 1615 1) A security configuration 1617 The choice of security configuration determines if initial 1618 configuration is implemented and if so how. 1619 One of three possible choices is selected: 1621 - initial-minimum-security-configuration 1622 - initial-semi-security-configuration 1623 - initial-no-access-configuration 1625 In the case of a initial-no-access-configuration, there is no 1626 initial configuration, and so the following steps are irrelevant. 1628 2) A default context 1630 One entry in the vacmContextTable with a contextName of "" (the 1631 empty string), representing the default context. Note that this 1632 table gets created automatically if a default context exists. 1634 no privacy support privacy support 1635 ------------------ --------------- 1636 vacmContextName "" "" 1638 3) An initial group 1640 One entry in the vacmSecurityToGroupTable to allow access to group 1641 "initial". 1643 no privacy support privacy support 1644 ------------------ --------------- 1645 vacmSecurityModel 3 (USM) 3 (USM) 1646 vacmSecurityName "initial" "initial" 1647 vacmGroupName "initial" "initial" 1648 vacmSecurityToGroupStorageType anyValidStorageType anyValidStorageType 1649 vacmSecurityToGroupStatus active active 1651 4) Initial access rights 1653 Three entries in the vacmAccessTable as follows: 1655 - read-notify access for securityModel USM, securityLevel 1656 "noAuthNoPriv" on behalf of securityNames that belong to the 1657 group "initial" to the MIB view in the default 1658 context with contextName "". 1660 - read-write-notify access for securityModel USM, securityLevel 1661 "authNoPriv" on behalf of securityNames that belong to the 1662 group "initial" to the MIB view in the default context 1663 with contextName "". 1665 - if privacy is supported, 1666 read-write-notify access for securityModel USM, securityLevel 1667 "authPriv" on behalf of securityNames that belong to the group 1668 "initial" to the MIB view in the default context with 1669 contextName "". 1671 That translates into the following entries in the vacmAccessTable. 1672 Those columns marked with (index) are index-only objects and are 1673 not really present in this table. 1675 - One entry to be used for unauthenticated access (noAuthNoPriv): 1677 no privacy support privacy support 1678 ------------------ --------------- 1679 vacmAccessContextPrefix "" "" 1680 vacmGroupName (index) "initial" "initial" 1681 vacmSecurityModel (index) 3 (USM) 3 (USM) 1682 vacmAccessSecurityLevel noAuthNoPriv noAuthNoPriv 1683 vacmAccessReadViewName "restricted" "restricted" 1684 vacmAccessWriteViewName "" "" 1685 vacmAccessNotifyViewName "restricted" "restricted" 1686 vacmAccessStorageType anyValidStorageType anyValidStorageType 1687 vacmAccessStatus active active 1689 - One entry to be used for authenticated access but without 1690 privacy (authNoPriv): 1691 no privacy support privacy support 1692 ------------------ --------------- 1693 vacmAccessContextPrefix "" "" 1694 vacmGroupName (index) "initial" "initial" 1695 vacmSecurityModel (index) 3 (USM) 3 (USM) 1696 vacmAccessSecurityLevel authNoPriv authNoPriv 1697 vacmAccessReadViewName "internet" "internet" 1698 vacmAccessWriteViewName "internet" "internet" 1699 vacmAccessNotifyViewName "internet" "internet" 1700 vacmAccessStorageType anyValidStorageType anyValidStorageType 1701 vacmAccessStatus active active 1703 - One entry to be used for authenticated access with privacy 1704 (authPriv): 1706 no privacy support privacy support 1707 ------------------ --------------- 1709 vacmAccessContextPrefix "" 1710 vacmGroupName (index) "initial" 1711 vacmSecurityModel (index) 3 (USM) 1712 vacmAccessSecurityLevel authPriv 1713 vacmAccessReadViewName "internet" 1714 vacmAccessWriteViewName "internet" 1715 vacmAccessNotifyViewName "internet" 1716 vacmAccessStorageType anyValidStorageType 1717 vacmAccessStatus active 1719 5) Two MIB views, of which the second one depends on the security 1720 configuration. 1722 - One view, the view, for authenticated access: 1724 - the MIB view is the following subtree: 1725 "internet" (subtree 1.3.6.1) 1727 - A second view, the view, for unauthenticated 1728 access. This view is configured according to the selected 1729 security configuration: 1731 - For the initial-no-access-configuration there is no default 1732 initial configuration, so no MIB views are pre-scribed. 1734 - For the initial-semi-secure-configuration: 1736 the MIB view is the union of these subtrees: 1737 (a) "system" (subtree 1.3.6.1.2.1.1) [RFC1907] 1738 (b) "snmp" (subtree 1.3.6.1.2.1.11) [RFC1907] 1739 (c) "snmpEngine" (subtree 1.3.6.1.6.3.7.2.1) [SNMP-ARCH] 1740 (d) "snmpMPDStats" (subtree 1.3.6.1.6.3.8.2.1) [SNMP-MPD] 1741 (e) "usmStats" (subtree 1.3.6.1.6.3.9.2.1) [SNMP-USM] 1743 - For the initial-minimum-secure-configuration: 1745 the MIB view is the following subtree. 1746 "internet" (subtree 1.3.6.1) 1748 This translates into the following "internet" entry in the 1749 vacmViewTreeFamilyTable: 1751 minimum-secure semi-secure 1752 ---------------- --------------- 1753 vacmViewTreeFamilyViewName "internet" "internet" 1754 vacmViewTreeFamilySubtree 1.3.6.1 1.3.6.1 1755 vacmViewTreeFamilyMask "" "" 1756 vacmViewTreeFamilyType 1 (included) 1 (included) 1757 vacmViewTreeFamilyStorageType anyValidStorageType anyValidStorageType 1758 vacmViewTreeFamilyStatus active active 1759 In addition it translates into the following "restricted" entries 1760 in the vacmViewTreeFamilyTable: 1762 minimum-secure semi-secure 1763 ---------------- --------------- 1764 vacmViewTreeFamilyViewName "restricted" "restricted" 1765 vacmViewTreeFamilySubtree 1.3.6.1 1.3.6.1.2.1.1 1766 vacmViewTreeFamilyMask "" "" 1767 vacmViewTreeFamilyType 1 (included) 1 (included) 1768 vacmViewTreeFamilyStorageType anyValidStorageType anyValidStorageType 1769 vacmViewTreeFamilyStatus active active 1771 vacmViewTreeFamilyViewName "restricted" 1772 vacmViewTreeFamilySubtree 1.3.6.1.2.1.11 1773 vacmViewTreeFamilyMask "" 1774 vacmViewTreeFamilyType 1 (included) 1775 vacmViewTreeFamilyStorageType anyValidStorageType 1776 vacmViewTreeFamilyStatus active 1778 vacmViewTreeFamilyViewName "restricted" 1779 vacmViewTreeFamilySubtree 1.3.6.1.6.3.7.2.1 1780 vacmViewTreeFamilyMask "" 1781 vacmViewTreeFamilyType 1 (included) 1782 vacmViewTreeFamilyStorageType anyValidStorageType 1783 vacmViewTreeFamilyStatus active 1785 vacmViewTreeFamilyViewName "restricted" 1786 vacmViewTreeFamilySubtree 1.3.6.1.6.3.8.2.1 1787 vacmViewTreeFamilyMask "" 1788 vacmViewTreeFamilyType 1 (included) 1789 vacmViewTreeFamilyStorageType anyValidStorageType 1790 vacmViewTreeFamilyStatus active 1792 vacmViewTreeFamilyViewName "restricted" 1793 vacmViewTreeFamilySubtree 1.3.6.1.6.3.9.2.1 1794 vacmViewTreeFamilyMask "" 1795 vacmViewTreeFamilyType 1 (included) 1796 vacmViewTreeFamilyStorageType anyValidStorageType 1797 vacmViewTreeFamilyStatus active 1799 B. Full Copyright Statement 3 1800 3 1801 Copyright (C) The Internet Society (1997). All Rights Reserved. 3 1802 3 1803 This document and translations of it may be copied and furnished to 3 1804 others, and derivative works that comment on or otherwise explain it 3 1805 or assist in its implementation may be prepared, copied, published 3 1806 and distributed, in whole or in part, without restriction of any 3 1807 kind, provided that the above copyright notice and this paragraph 3 1808 are included on all such copies and derivative works. However, this 3 1809 document itself may not be modified in any way, such as by removing 3 1810 the copyright notice or references to the Internet Society or other 3 1811 Internet organizations, except as needed for the purpose of 3 1812 developing Internet standards in which case the procedures for 3 1813 copyrights defined in the Internet Standards process must be 3 1814 followed, or as required to translate it into languages other than 3 1815 English. 3 1816 3 1817 The limited permissions granted above are perpetual and will not be 3 1818 revoked by the Internet Society or its successors or assigns. 3 1819 3 1820 This document and the information contained herein is provided on an 3 1821 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 3 1822 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 3 1823 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 3 1824 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 3 1825 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3