idnits 2.17.1 draft-li-isms-svacm-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 959. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 970. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 977. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 983. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == 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: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 isms C. Li 3 Internet-Draft Y. Li 4 Intended status: Informational Huawei Technologies 5 Expires: May 5, 2009 Nov. 2008 7 Simplified View-based Access Control Model (SVACM) for the Simple 8 Network Management Protocol (SNMP) 9 draft-li-isms-svacm-01.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on May 5, 2009. 36 Abstract 38 This document introduces a Simplified View-based Access Control Model 39 (SVACM) for the Simple Network Management Protocol (SNMP), which is 40 useful for the access control application of SNMP protocol. 42 This document describes the procedure of access control in SVACM with 43 Remote Authentication Dial In User Service (RADIUS) server for 44 authorization. 46 This document also includes a Management Information Base (MIB) for 47 remotely managing the configuration parameters for SVACM. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.2. General . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Simplified View-based Access Control Model (SVACM) . . . . . . 3 55 2.1. Elements of SVACM . . . . . . . . . . . . . . . . . . . . 4 56 2.1.1. Groups . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2.1.2. securityLevel . . . . . . . . . . . . . . . . . . . . 5 58 2.1.3. MIB Views . . . . . . . . . . . . . . . . . . . . . . 5 59 2.1.4. Access Policy . . . . . . . . . . . . . . . . . . . . 6 60 2.2. Elements of Procedure . . . . . . . . . . . . . . . . . . 6 61 2.2.1. Overview of isAccessAllowed Process . . . . . . . . . 7 62 2.2.2. Processing the isAccessAllowed Service Request . . . . 7 63 3. RADIUS authorization for SNMP . . . . . . . . . . . . . . . . 9 64 4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 10 65 5. Security Considerations . . . . . . . . . . . . . . . . . . . 18 66 5.1. Recommended Practices . . . . . . . . . . . . . . . . . . 18 67 5.2. Defining Groups . . . . . . . . . . . . . . . . . . . . . 18 68 5.3. Conformance . . . . . . . . . . . . . . . . . . . . . . . 19 69 5.4. Access to the SNMP-SIMPLIFIED-VIEW-BASED-ACM-MIB . . . . . 19 70 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 71 7. Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 72 8. Normative References . . . . . . . . . . . . . . . . . . . . . 20 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 74 Intellectual Property and Copyright Statements . . . . . . . . . . 22 76 1. Introduction 78 1.1. Motivation 80 View-based Access Control Model (VACM) of SNMP [RFC3415] is a 81 specific model of the Access Control Subsystem (ACS). VACM is 82 elaborate, comprehensive and agile, but it is difficult to understand 83 and configure, and it is not easy for administrators to deploy 84 correctly. The complexity of VACM and lack of support for RADIUS 85 impact its adoption. Simplified View-based Access Control Model 86 (SVACM) makes the Access Control Model more intuitive and operable. 88 1.2. General 90 This document defines another specific model of ACS, designated 91 SVACM, which simplifies VACM. SVACM inherits the basic thinking of 92 VACM, but simplifies some parameters, and confines the granularity of 93 a view to MIB module level. SVACM is less flexible than VACM, but is 94 simpler and easier to deploy. SVACM covers most common scenarios 95 which do not need fine granularity of MIB views. SVACM supports 96 RADIUS for the process of authorization. There is a parallel 97 relationship between VACM and SVACM. SVACM is not a replacement of 98 VACM. When administrators need the fine granularity of access 99 control, the VACM should be adopted. 101 This document also describes the procedure of access control in SVACM 102 with a RADIUS [RFC2865] server for authorization, using the attribute 103 of RADIUS protocol which is defined in [radman] to carry the access 104 policies. 106 It is important to understand the SNMP architecture and the 107 terminology of the architecture to understand where the Access 108 Control Model described in this memo fits into the architecture and 109 interacts with other subsystems and models within the architecture. 110 The reader is expected to have read and understood the description 111 and terminology of the SNMP architecture, as defined in [RFC3411]. 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in [RFC2119]. 117 2. Simplified View-based Access Control Model (SVACM) 119 VACM determines the access rights of a group, representing zero or 120 more securityNames which have the same access rights. For a 121 particular context, identified by contextName, to which a group, 122 identified by groupName, has access using a particular securityModel 123 and securityLevel, that group's access rights are given by a read- 124 view, a write-view and a notify-view. 126 VACM defines the vacmContextTable that lists the locally available 127 contexts by contextName. A SNMP context is a collection of 128 management information accessible by a SNMP engine, but in a majority 129 of use cases, there is not multiple contexts in a single agent. 130 Moreover, administrators do not understand well what the concept of 131 context represents, so the configuration of context is difficult. To 132 be more practical, SVACM does not consider the context parameter any 133 more in access control process. SVACM just considers most common 134 situations, if several contexts are required in one agent, VACM is 135 still needed. 137 SVACM does not use the securityModel parameter like VACM. 138 SecurityModel is an identifier that uniquely identifies a Security 139 Model of the Security Subsystem within this SNMP Management 140 Architecture. In VACM the parameter securityModel is checked in 141 vacmSecurityToGroupTable and vacmAccessTable. SVACM removes the 142 securityModel from these two steps, the reasons are described in the 143 following sections. 145 SVACM inherits the same basic mechanism of groups and views as VACM, 146 but changes some details in them, to be simpler and easier for the 147 deployment. 149 2.1. Elements of SVACM 151 2.1.1. Groups 153 In VACM a group is a set of zero or more (securityModel, 154 securityName) tuples on whose behalf SNMP management objects can be 155 accessed. SVACM also uses the group mechanism, but it uses the 156 securityName as an only index for the mapping of groupName. The 157 parameter securityModel is not a mapping parameter any more in the 158 group mechanism. 160 In VACM, a user using different securityModel could be mapped into 161 different groups, and different users using different securityModel 162 respectively could be mapped into the same group. Thus introducing 163 securityModel in group mapping method makes people confused about the 164 meaning of a group. In general, a group is a set of users. Removing 165 securityModel parameter from vacmSecurityToGroupTable would make the 166 concept of group clear. Furthermore, one index in 167 vacmSecurityToGroupTable is more straightforward than two indexes. 168 The securityModel and securityLevel should indeed be taken into 169 account by access control process. They may influence access rights 170 of a group via the mapping from group into views, thereby it 171 indirectly influence access rights of a user. So SVACM does not 172 consider securityModel parameter in the group mapping step. 174 In SVACM, a securityName will be mapped into only one group. Whether 175 this mapping occurs in local database of SNMP engine or in an outer 176 server depends on the deployment. In the latter case, the outer 177 server such as a RADIUS server will transport the mapped groupName 178 information to the SNMP engine. The procedure of access control in 179 SVACM with a RADIUS server is described in Section 3. 181 2.1.2. securityLevel 183 SVACM uses the same securityLevel parameter as VACM. SecurityLevel 184 identifies the level of security that will be assumed when checking 185 for access rights. Different access rights for members of a group 186 can be defined for different levels of security, i.e., noAuthNoPriv, 187 authNoPriv, and authPriv. 189 2.1.3. MIB Views 191 In VACM, a "MIB view" details a specific set of managed object types 192 (and optionally, the specific instances of object types). The 193 definition of MIB views in VACM is agile, but configuring the 194 vacmViewTreeFamilyTable is complicated. To configure each MIB view 195 in the whole MIB tree, a network administrator must know clearly 196 about the MIB tree structure and exactly where a certain managed 197 object locates. It is too difficult for network administrators to 198 know all these details and to calculate the subtree mask. 200 SVACM also uses the definition of a "MIB view" to detail the managed 201 object types, but SVACM simplifies MIB Views by eliminating include/ 202 exclude, subtree masks, and ViewTreeFamilies. 204 SVACM defines a "MIB view" in a coarse granularity. Each MIB module 205 is defined as a MIB view. These MIB views are built in the 206 svacmViewTable and do not need to be configured by network 207 administrators. For example, OSPF-MIB is a MIB module which has a 208 definite OID, SVACM defines OSPF-MIB as a MIB view whose viewname is 209 OSPF-MIB. This view definition method omits the steps of configuring 210 the subtree OID and subtree mask. Administrators who know only the 211 MIB-module name are able to distribute each view the types of access 212 (read, write or notify). It improves human readability. Moreover, 213 ignoring subtree mask and remove of excluding a subtree would result 214 in that the examination of whether a variableName is in specific MIB 215 views is much faster than before. 217 There SHOULD be a built-in MIB view in the svacmViewTable, which 218 represents the whole MIB tree. Its name could be ALL-MIB or others. 220 2.1.4. Access Policy 222 In SVACM, the svacmAccessTable makes use of only the groupname and 223 securityLevel as indexes, the securityModel is discarded. The 224 securityModel is just an identifier of a security model, which does 225 not indicate the completeness of a protection measure. For 226 instances, the User-based Security Model(USM) [RFC3414] could be with 227 securityLevel of authNoPriv or authPriv. The Transport Security 228 Model (TSM) [TSM for SNMP] could also be with securityLevel of 229 authNoPriv or authPriv. No one can assert that a securityModel is 230 more secure than another one. For a given group, assigning different 231 access control rights for different securityModels with the same 232 securityLevel is meaningless. So the securityLevel is the key factor 233 in the access control process, the securityModel is not significant. 235 In vacmAccessTable of VACM, the group's access rights are given by a 236 read-view, a write-view or a notify-view. In SVACM, each view 237 includes a MIB-module subtree. Several views are distributed with 238 one type of access (read, write or notify). So one group could 239 access more than one read-view, more than one write-view or more than 240 one notify-view, which are configured in svacmAccessTable. This 241 configuration method of svacmAccessTable reuses each built-in view. 242 So it is more convenient and easy to configure. 244 Most MIB module names end in -MIB, so it could be simpler for an 245 agent to just list "BGP4, OSPF, MPLS, ..." in svacmAccessTable and 246 svacmViewTable, and it is useful in the length limitation of 247 SnmpAdminString. 249 2.2. Elements of Procedure 251 This section describes the procedures followed by an Access Control 252 Module that deploys SVACM, when checking access rights as requested 253 by an application. The abstract service primitive is: 255 statusInformation = -- success or errorIndication 256 isAccessAllowed( 257 securityModel -- Security Model in use, 258 unused in SVACM. 259 securityName -- principal who wants access 260 securityLevel -- Level of Security 261 viewType -- read, write, or notify view 262 contextName -- context containing variableName, 263 unused in SVACM 264 variableName -- OID for the managed object 265 ) 267 The abstract data elements are: 269 statusInformation - one of the following: 270 accessAllowed - MIB views were found and access is granted. 271 notInAllViews - MIB views were found but access is denied. 272 The variableName is not in any MIB views 273 for the specified viewType (e.g.,in the 274 relevant entry of svacmAccessTable). 275 noSuchViews - no MIB view found because no view has been 276 configured for specified viewType (e.g., in 277 the relevant entry in svacmAccessTable). 278 noGroupName - no MIB view found because no entry has been 279 configured in svacmSecurityToGroupTable 280 for the specified securityName. 281 noAccessEntry - no MIB view found because no entry has been 282 configured in svacmAccessTable for the 283 specified groupName (from 284 svacmSecurityToGroupTable). 285 otherError - failure, an undefined error occurred. 287 2.2.1. Overview of isAccessAllowed Process 289 The following picture shows how the decision for access control is 290 made by SVACM. This process will not check the parameters 291 contextName and securityModel which are unused in SVACM. 293 +-----------------------------------------------------------+ 294 | | 295 | securityName ---> groupName --+ | 296 | | | 297 | securityLevel ----------------+-> viewNames -+-> yes/no | 298 | | | decision | 299 | viewType (read/write/notify)--+ | | 300 | | | 301 | variableName (OID) --------------------------+ | 302 | | 303 +-----------------------------------------------------------+ 305 2.2.2. Processing the isAccessAllowed Service Request 307 This section describes the procedure followed by an Access Control 308 module that deploys SVACM whenever it receives an isAccessAllowed 309 request. 311 1) The svacmSecurityToGroupTable is consulted for mapping the 312 securityName into a groupName. If the information about this 313 securityName is absent from the table, then an 314 errorIndication (noGroupName) is returned to the calling 315 module, and the processing of the request stops. 317 2) The svacmAccessTable is consulted for information about the 318 groupName and securityLevel. If information about this 319 combination is absent from the table, then an 320 errorIndication (noAccessEntry) is returned to the calling 321 module, and the processing of the request stops. 323 3) a) If the viewType is "read", then the read views are used for 324 checking access rights. 326 b) If the viewType is "write", then the write views are used 327 for checking access rights. 329 c) If the viewType is "notify", then the notify views are used 330 for checking access rights. 332 If the viewtype is a zero length string, then an 333 errorIndication (noSuchViews) is returned to the calling 334 module, and the processing of the request stops. 336 4) a) If one view in the read-view (write-view or notify-view) 337 list is not built in the svacmViewTable, ignore this result 338 and go on match other views in the list. If none view 339 configured for the specified viewType is found in 340 svacmViewTable, then an errorIndication (noSuchViews) is 341 returned to the calling module, and the processing of the 342 request stops. 344 b) If the specified variableName (object instance) is not in 345 the MIB views then an errorIndication (notInAllViews) is 346 returned to the calling module, and the processing of the 347 request stops. 349 Otherwise, 351 c) The specified variableName is in the MIB views. A 352 statusInformation of success (accessAllowed) is returned 353 to the calling module. 355 3. RADIUS authorization for SNMP 357 SVACM is easy to be integrated with RADIUS. When a SNMP engine using 358 a RADIUS server to complete the authorization of access control, the 359 SNMP engine takes the role of NAS according to the RADIUS server. 360 The mapping from securityName into groupName is done by the RADIUS 361 server, instead of svacmSecurityToGroupTable of SVACM in the SNMP 362 engine. 364 [radman] defines a RADIUS attribute Management-Policy-Id which is 365 transported in an Access-Accept message, and it indicates the name of 366 the management access policy for users. When SVACM is integrated 367 with RADIUS, the Management-Policy-Id attribute indicates the 368 groupName which a user belongs to. 370 [draft-ietf-isms-radius-usage] also provides hint attributes in the 371 Access-Request messages. When attempting to use RADIUS to provide 372 SNMP service, it is important to use the hint attributes to signal to 373 the RADIUS server the type of service being requested over the 374 transport session. It is also important for the NAS to know that the 375 RADIUS server is authorizing the use of SNMP service by the user. 377 So the process of RADIUS authorization for SNMP is detailed as 378 follows. RADIUS Clients, within the agent, initiate a transaction by 379 sending a RADIUS Access-Request message to the RADIUS server. RADIUS 380 server authenticates the client user according to the identity and 381 credentials of the user. Then the RADIUS server will indicate a 382 successful authentication by returning an Access-Accept message, or 383 indicate an unsuccessful authenticationan by returning an Access- 384 Reject message. The Access-Accept message and Access-Accept message 385 both utilize the Service-Type Attribute with a value of Framed- 386 Management, the RADIUS Framed-Management-Protocol Attribute with a 387 value of SNMP, and the Management-Transport-Protection Attribute with 388 a value of Integrity- Confidentiality-Protection. The Access-Accept 389 message will also include Management-Policy-Id attribute to indicate 390 which groupName should the user be related to. The mapping from user 391 to usergroup is done in the back-end authentication database of 392 RADIUS server, which contains credentials of many classes of users. 393 The methods of authenticating the user in RADIUS server are 394 implementation specific. 396 If the agent rceives a Management-Policy-Id attribute with an unknown 397 groupName, or the policy rules are incorrectly formatted, the agent 398 MUST treat the packet as if it had been an Access-Reject. 400 In SVACM, the information about access rights and policies is part of 401 the SNMP engine's Local Configuration Datastore (LCD) in agent. When 402 the agent get the Access-Accept message, during the general process 403 of the message, the data object access control authorization in SNMP 404 is handled by the Access Control Subsystem (ACS). If the Access 405 Control Model is SVACM, the next steps are to check the 406 vacmContextTable, the svacmAccessTable, the svacmViewTable and check 407 the variableName whether in the specific MIB views. 409 4. Definitions 411 SNMP-SIMPLIFIED-VIEW-BASED-ACM-MIB DEFINITIONS ::= BEGIN 413 IMPORTS 414 MODULE-COMPLIANCE FROM SNMPv2-CONF 415 MODULE-IDENTITY, OBJECT-TYPE, 416 snmpModules FROM SNMPv2-SMI 417 RowStatus, StorageType FROM SNMPv2-TC 418 SnmpAdminString FROM SNMP-FRAMEWORK-MIB; 420 snmpSvacmMIB MODULE-IDENTITY 421 LAST-UPDATED "" 422 ORGANIZATION "" 423 CONTACT-INFO " 424 " 425 DESCRIPTION "The management information definitions for the 426 Simplified View-based Access Control Model for 427 SNMP. 428 " 429 ::= { snmpModules x } 431 -- Administrative assignments ************************************* 433 svacmMIBObjects OBJECT IDENTIFIER ::= { snmpSvacmMIB 1 } 434 svacmMIBConformance OBJECT IDENTIFIER ::= { snmpSvacmMIB 2 } 436 -- Information about Groups *************************************** 438 svacmSecurityToGroupTable OBJECT-TYPE 439 SYNTAX SEQUENCE OF SvacmSecurityToGroupEntry 440 MAX-ACCESS not-accessible 441 STATUS current 442 DESCRIPTION "This table maps a securityName into a groupName 443 which is used to define an access control policy 444 for a group of principals. 445 " 446 ::= { svacmMIBObjects 1 } 448 svacmSecurityToGroupEntry OBJECT-TYPE 449 SYNTAX SvacmSecurityToGroupEntry 450 MAX-ACCESS not-accessible 451 STATUS current 452 DESCRIPTION "An entry in this table maps a securityName into a 453 groupName. 454 " 455 INDEX { 456 svacmSecurityName 457 } 458 ::= { svacmSecurityToGroupTable 1 } 460 SvacmSecurityToGroupEntry ::= SEQUENCE 461 { 462 svacmSecurityName SnmpAdminString, 463 svacmGroupName SnmpAdminString, 464 svacmSecurityToGroupStorageType StorageType, 465 svacmSecurityToGroupStatus RowStatus 466 } 468 svacmSecurityName OBJECT-TYPE 469 SYNTAX SnmpAdminString (SIZE(1..32)) 470 MAX-ACCESS not-accessible 471 STATUS current 472 DESCRIPTION "The securityName for the principal which is 473 mapped by this entry into a groupName. 474 " 475 ::= { svacmSecurityToGroupEntry 1 } 477 svacmGroupName OBJECT-TYPE 478 SYNTAX SnmpAdminString (SIZE(1..32)) 479 MAX-ACCESS read-create 480 STATUS current 481 DESCRIPTION "The name of the group which this entry (the 482 securityName) belongs to. 484 This groupName is used as an index in the 485 svacmAccessTable to select an access control 486 policy. However, a value in this table does not 487 imply that an instance with the value exists in 488 svacmAccesTable. 489 " 490 ::= { svacmSecurityToGroupEntry 2 } 492 svacmSecurityToGroupStorageType OBJECT-TYPE 493 SYNTAX StorageType 494 MAX-ACCESS read-create 495 STATUS current 496 DESCRIPTION "The storage type for this conceptual row. 497 Conceptual rows having the value 'permanent' need 498 not allow write-access to any columnar objects in 499 the row. 500 " 501 DEFVAL { nonVolatile } 502 ::= { svacmSecurityToGroupEntry 3 } 504 svacmSecurityToGroupStatus OBJECT-TYPE 505 SYNTAX RowStatus 506 MAX-ACCESS read-create 507 STATUS current 508 DESCRIPTION "The status of this conceptual row. 510 Until instances of all corresponding columns are 511 appropriately configured, the value of the 512 corresponding instance of the 513 svacmSecurityToGroupStatus column is 'notReady'. 515 In particular, a newly created row cannot be made 516 active until a value has been set for 517 svacmGroupName. 519 The RowStatus TC [RFC2579] requires that this 520 DESCRIPTION clause states under which circumstances 521 other objects in this row can be modified: 523 The value of this object has no effect on whether 524 other objects in this conceptual row can be 525 modified. 526 " 527 ::= { svacmSecurityToGroupEntry 4 } 529 -- Information about Access Rights ******************************** 531 svacmAccessTable OBJECT-TYPE 532 SYNTAX SEQUENCE OF SvacmAccessEntry 533 MAX-ACCESS not-accessible 534 STATUS current 535 DESCRIPTION "The table of access rights for groups. 537 Each entry is indexed by a groupName and a 538 svacmSecurityLevel. To determine whether access 539 is allowed, one entry from this table needs to 540 be selected and the proper viewNames from that 541 entry must be used for access control checking. 542 " 543 ::= { svacmMIBObjects 2 } 545 svacmAccessEntry OBJECT-TYPE 546 SYNTAX SvacmAccessEntry 547 MAX-ACCESS not-accessible 548 STATUS current 549 DESCRIPTION "An access right configured in Local Configuration 550 Datastore(LCD) authorizing access to an SNMP engine. 552 Entries in this table can use an instance value for 553 object svacmGroupName even if no entry in table 554 svacmAccessSecurityToGroupTable has a corresponding 555 value for object svacmGroupName. 556 " 557 INDEX { svacmGroupName, 558 svacmSecurityLevel 559 } 560 ::= { svacmAccessTable 1 } 562 SvacmAccessEntry ::= SEQUENCE 563 { 564 svacmSecurityLevel SnmpAdminString, 565 svacmAccessReadViewNames SnmpAdminString, 566 svacmAccessWriteViewNames SnmpAdminString, 567 svacmAccessNotifyViewNames SnmpAdminString, 568 svacmAccessStorageType StorageType, 569 svacmAccessStatus RowStatus 570 } 572 svacmSecurityLevel OBJECT-TYPE 573 SYNTAX SnmpAdminString (SIZE(0..32)) 574 MAX-ACCESS not-accessible 575 STATUS current 576 DESCRIPTION "The minimum level of security required in order to 577 gain the access rights allowed by this conceptual 578 row. A securityLevel of noAuthNoPriv is less than 579 authNoPriv which in turn is less than authPriv." 580 ::= { svacmAccessEntry 1 } 582 svacmAccessReadViewNames OBJECT-TYPE 583 SYNTAX SnmpAdminString 584 MAX-ACCESS read-create 585 STATUS current 586 DESCRIPTION "The value of an instance of this object identifies 587 the MIB views of the SNMP engine to which this 588 conceptual row authorizes read access. 590 One SnmpAdminString carries a list of Read view 591 names separated by comma. 593 The identified MIB views are that ones for which the 594 svacmViewName has the same value as the instance of 595 this object; if the value is the empty string or if 596 there is no active MIB view having this value of 597 svacmViewName, then no access is granted. 598 " 599 DEFVAL { ''H } -- the empty string 600 ::= { svacmAccessEntry 2 } 602 svacmAccessWriteViewNames OBJECT-TYPE 603 SYNTAX SnmpAdminString 604 MAX-ACCESS read-create 605 STATUS current 606 DESCRIPTION "The value of an instance of this object identifies 607 the MIB view of the SNMP engine to which this 608 conceptual row authorizes write access. 610 One SnmpAdminString carries a list of Write view 611 names separated by comma. 613 The identified MIB views are that ones for which the 614 svacmViewName has the same value as the instance of 615 this object; if the value is the empty string or if 616 there is no active MIB view having this value of 617 svacmViewName, then no access is granted. 618 " 619 DEFVAL { ''H } -- the empty string 620 ::= { svacmAccessEntry 3 } 622 svacmAccessNotifyViewNames OBJECT-TYPE 623 SYNTAX SnmpAdminString 624 MAX-ACCESS read-create 625 STATUS current 626 DESCRIPTION "The value of an instance of this object identifies 627 the MIB view of the SNMP engine to which this 628 conceptual row authorizes access for notifications. 630 One SnmpAdminString carries a list of Notify view 631 names separated by comma. 633 The identified MIB views are that ones for which the 634 svacmViewName has the same value as the instance of 635 this object; if the value is the empty string or if 636 there is no active MIB view having this value of 637 svacmViewName, then no access is granted. 638 " 639 DEFVAL { ''H } -- the empty string 640 ::= { svacmAccessEntry 4 } 642 svacmAccessStorageType OBJECT-TYPE 643 SYNTAX StorageType 644 MAX-ACCESS read-create 645 STATUS current 646 DESCRIPTION "The storage type for this conceptual row. 648 Conceptual rows having the value 'permanent' need 649 not allow write-access to any columnar objects in 650 the row. 651 " 652 DEFVAL { nonVolatile } 653 ::= { svacmAccessEntry 5 } 655 svacmAccessStatus OBJECT-TYPE 656 SYNTAX RowStatus 657 MAX-ACCESS read-create 658 STATUS current 659 DESCRIPTION "The status of this conceptual row. 661 The RowStatus TC [RFC2579] requires that this 662 DESCRIPTION clause states under which circumstances 663 other objects in this row can be modified: 665 The value of this object has no effect on whether 666 other objects in this conceptual row can be 667 modified. 668 " 669 ::= { svacmAccessEntry 6 } 671 -- Information about MIB views ************************************ 673 -- Support for MIB-module-granularity is compulsory. 675 svacmMIBViews OBJECT IDENTIFIER ::= { svacmMIBObjects 3 } 677 svacmViewTable OBJECT-TYPE 678 SYNTAX SEQUENCE OF SvacmViewEntry 679 MAX-ACCESS not-accessible 680 STATUS current 681 DESCRIPTION "Locally held information about MIB views. This table 682 is built in by the agent, and can not be altered or 683 deleted by any administrator. 685 Each MIB view is a included subtree in the unit of 686 MIB module with definite OID value. So the 687 definition of each view based on each MIB module 688 could be built in this table. 690 To determine whether a particular object instance is 691 in a particular MIB view, compare the object 692 instance's OBJECT IDENTIFIER with the MIB view's 693 active entry in this table. If none match, then the 694 object instance is not in the MIB view. If one 695 matches, then the object instance is included in. 697 If a administrator want to create/delete an entry in 698 the svacmViewTable, then an operation error must be 699 returned. 700 " 701 ::= { svacmMIBViews 1 } 703 svacmViewEntry OBJECT-TYPE 704 SYNTAX SvacmViewEntry 705 MAX-ACCESS not-accessible 706 STATUS current 707 DESCRIPTION "Information on a particular view subtree included 708 in a particular SNMP engine's MIB view. 710 If no conceptual rows exist in this table for a 711 given MIB view (viewName), then an errorIndication 712 (noSuchView) is returned. 713 " 714 INDEX { 715 svacmViewName 716 } 717 ::= { svacmViewTable 1 } 719 SvacmViewEntry ::= SEQUENCE 720 { 721 svacmViewName SnmpAdminString, 722 svacmViewSubtree OBJECT IDENTIFIER 723 } 725 svacmViewName OBJECT-TYPE 726 SYNTAX SnmpAdminString (SIZE(1..32)) 727 MAX-ACCESS read-only 728 STATUS current 729 DESCRIPTION "The human readable name for a MIB-module-granularity 730 view. 731 " 732 ::= { svacmViewEntry 1 } 734 svacmViewSubtree OBJECT-TYPE 735 SYNTAX OBJECT IDENTIFIER 736 MAX-ACCESS read-only 737 STATUS current 738 DESCRIPTION "The MIB subtree which defines a MIB-module- 739 granularity view. Corresponding to each 740 svacmViewName, its OID value is definite and built 741 in svacmViewTable. It does not need to be configured 742 by administrators. 743 " 744 ::= { svacmViewEntry 2 } 746 -- Conformance information **************************************** 748 svacmMIBCompliances OBJECT IDENTIFIER ::= { svacmMIBConformance 1 } 749 svacmMIBGroups OBJECT IDENTIFIER ::= { svacmMIBConformance 2 } 751 -- Compliance statements ****************************************** 753 svacmMIBCompliance MODULE-COMPLIANCE 754 STATUS current 755 DESCRIPTION "The compliance statement for SNMP engines which 756 deploy the SNMP simplified View-based Access 757 Control Model configuration MIB. 758 " 759 MODULE -- this module 760 MANDATORY-GROUPS { svacmBasicGroup } 762 OBJECT svacmAccessReadViewNames 763 MIN-ACCESS read-only 764 DESCRIPTION "Write access is not required." 766 OBJECT svacmAccessWriteViewNames 767 MIN-ACCESS read-only 768 DESCRIPTION "Write access is not required." 770 OBJECT svacmAccessNotifyViewNames 771 MIN-ACCESS read-only 772 DESCRIPTION "Write access is not required." 774 OBJECT svacmAccessStorageType 775 MIN-ACCESS read-only 776 DESCRIPTION "Write access is not required." 778 OBJECT svacmAccessStatus 779 MIN-ACCESS read-only 780 DESCRIPTION "Create/delete/modify access to the 781 svacmAccessTable is not required. 782 " 783 ::= { svacmMIBCompliances 1 } 785 -- Units of conformance *********************************** 786 svacmBasicGroup OBJECT-GROUP 787 OBJECTS { 788 svacmGroupName, 789 svacmSecurityLevel, 790 svacmSecurityToGroupStorageType, 791 svacmSecurityToGroupStatus, 792 svacmAccessReadViewNames, 793 svacmAccessWriteViewNames, 794 svacmAccessNotifyViewNames, 795 svacmAccessStorageType, 796 svacmAccessStatus 797 } 798 STATUS current 799 DESCRIPTION "A collection of objects providing for remote 800 configuration of an SNMP engine which deploys 801 the SNMP simplified View-based Access Control Model. 802 " 803 ::= { svacmMIBGroups 1 } 804 END 806 5. Security Considerations 808 5.1. Recommended Practices 810 This document is meant for use in the SNMP architecture. The 811 Simplified View-based Access Control Model described in this document 812 checks access rights to management information based on: 814 - groupName, representing a set of zero or more 815 securityNames. The securityName is mapped into a group in the 816 Simplified View-based Access Control Model. 818 - securityLevel under which access is requested. 820 - operation performed on the management information. 822 - MIB views for read, write or notify access. 824 When the User-based Security Module or transport security model is 825 called for checking access rights, it is assumed that the calling 826 module has ensured the authentication and privacy aspects as 827 specified by the securityLevel that is being passed. 829 5.2. Defining Groups 831 The groupNames are used to give access to a group of zero or more 832 securityNames. Within the Simplified View-Based Access Control 833 Model, a groupName is considered to exist if that groupName is listed 834 in the svacmSecurityToGroupTable. 836 By mapping the securityName into a groupName, an SNMP Command 837 Generator application can add/delete securityNames to/from a group, 838 if proper access is allowed. 840 Further it is important to realize that the grouping of securityName 841 in the svacmSecurityToGroupTable does not take securityLevel into 842 account. It is therefore important that the security administrator 843 uses the securityLevel index in the svacmAccessTable to separate 844 noAuthNoPriv from authPriv and/or authNoPriv access. 846 There is a parallel relationship between the View-based Access 847 Control Model and the Simplified View-based Access Control Model. An 848 application need to decide which ACM should be used (VACM or SVACM). 849 The Simplified View-based Access Control Model is used in scenarios 850 which do not consider the context parameter and with coarse 851 granularity of MIB views in MIB module level. When administrators 852 need the fine granularity of access control, or several contexts in 853 one agent, the View-based Access Control Model is still needed. 855 5.3. Conformance 857 For an implementation of the View-based Access Control Model to be 858 conformant, it MUST implement the SNMP-SIMPLIFIED-VIEW-BASED-ACM-MIB 859 according to the svacmMIBCompliance. 861 5.4. Access to the SNMP-SIMPLIFIED-VIEW-BASED-ACM-MIB 863 The objects in this MIB control the access to all MIB data that is 864 accessible via the SNMP engine and they may be considered sensitive 865 in many environments. It is important to closely control (both read 866 and write) access to these MIB objects by using appropriately 867 configured Access Control models (for example the Simplified View- 868 based Access Control Model as specified in this document). 870 6. IANA Considerations 872 None. 874 7. Notation 876 None. 878 8. Normative References 880 [RFC2119] Bradner, s., "Key words for use in RFCs to Indicate 881 Requirement Levels", BCP 14, RFC 2119, March 1997. 883 [RFC2579] McCloghrie, K., "Textual Conventions for SMIv2", 884 February 2008, 885 . 887 [RFC2865] Rigney, C., "Remote Authentication Dial In User Service 888 (RADIUS)", rfc 2865, June 2000, 889 . 891 [RFC3411] Harrington, D., "An Architecture for Describing Simple 892 Network Management Protocol (SNMP) Management Frameworks", 893 rfc 3411, std 62, December 2002, 894 . 896 [RFC3414] Blumenthal, U., "User-based Security Model (USM) for 897 version 3 of the Simple Network Management Protocol 898 (SNMPv3)", February 2008, 899 . 901 [RFC3415] Wijnen, B., "View-based Access Control Model (VACM) for 902 the Simple Network Management Protocol (SNMP)", rfc 3415, 903 December 2002, . 905 [TSM for SNMP] 906 Harrington, D., "Transport Security Model for SNMP 907 draft-ietf-isms-transport-security-model-07", 908 February 2008, . 911 [draft-ietf-isms-radius-usage] 912 Narayan, K., "Remote Authentication Dial-In User Service 913 (RADIUS) Usage for Simple Network Management Protocol 914 (SNMP) Transport Models", June 2008, . 917 [radman] Nelson, D., "Remote Authentication Dial-In User Service 918 (RADIUS) Authorization for Network Access Server (NAS) 919 Management", February 2008, . 923 Authors' Addresses 925 Chunxiu Li 926 Huawei Technologies 927 HuaWei Building, No.3 Xinxi Rd.,Shang-Di Information Industry Base 928 Beijing 100085 929 China 931 Phone: +86 010 82836081 932 Email: lichunxiu@huawei.com 933 URI: http://www.huawei.com 935 Yan Li 936 Huawei Technologies 937 HuaWei Building, No.3 Xinxi Rd.,Shang-Di Information Industry Base 938 Beijing 100085 939 China 941 Phone: +86 010 82836074 942 Email: liyan_77@huawei.com 943 URI: http://www.huawei.com 945 Full Copyright Statement 947 Copyright (C) The IETF Trust (2008). 949 This document is subject to the rights, licenses and restrictions 950 contained in BCP 78, and except as set forth therein, the authors 951 retain all their rights. 953 This document and the information contained herein are provided on an 954 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 955 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 956 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 957 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 958 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 959 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 961 Intellectual Property 963 The IETF takes no position regarding the validity or scope of any 964 Intellectual Property Rights or other rights that might be claimed to 965 pertain to the implementation or use of the technology described in 966 this document or the extent to which any license under such rights 967 might or might not be available; nor does it represent that it has 968 made any independent effort to identify any such rights. Information 969 on the procedures with respect to rights in RFC documents can be 970 found in BCP 78 and BCP 79. 972 Copies of IPR disclosures made to the IETF Secretariat and any 973 assurances of licenses to be made available, or the result of an 974 attempt made to obtain a general license or permission for the use of 975 such proprietary rights by implementers or users of this 976 specification can be obtained from the IETF on-line IPR repository at 977 http://www.ietf.org/ipr. 979 The IETF invites any interested party to bring to its attention any 980 copyrights, patents or patent applications, or other proprietary 981 rights that may cover technology that may be required to implement 982 this standard. Please address the information to the IETF at 983 ietf-ipr@ietf.org.