idnits 2.17.1 draft-ietf-isms-radius-vacm-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document date (January 29, 2010) is 5199 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Narayan 3 Internet-Draft Cisco Systems, Inc. 4 Intended status: Standards Track D. Nelson 5 Expires: August 2, 2010 Elbrys Networks, Inc. 6 R. Presuhn, Ed. 7 None 8 January 29, 2010 10 Extensions to View-based Access Control Model for use with RADIUS 11 draft-ietf-isms-radius-vacm-02.txt 13 Abstract 15 This memo defines a portion of the Management Information Base (MIB) 16 for use with network management protocols. In particular, it 17 describes a backward-compatible extension to the View-based Access 18 Control Model (VACM) for SNMPv3 for use with RADIUS and other AAA 19 services to provide authorization of MIB database access, and defines 20 objects for managing this extension. This extension is intended to 21 be used in conjunction with secure SNMP Transport Models that 22 facilitate RADIUS authentication, such as the Secure Shell Transport 23 Model. 25 Status of this Memo 27 This Internet-Draft is submitted to IETF in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF), its areas, and its working groups. Note that 32 other groups may also distribute working documents as Internet- 33 Drafts. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/ietf/1id-abstracts.txt. 43 The list of Internet-Draft Shadow Directories can be accessed at 44 http://www.ietf.org/shadow.html. 46 This Internet-Draft will expire on August 2, 2010. 48 Copyright Notice 49 Copyright (c) 2010 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. The Internet-Standard Management Framework . . . . . . . . . . 4 67 3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 4.1. System Block Diagram . . . . . . . . . . . . . . . . . . . 4 70 4.2. Using RADIUS with SNMP . . . . . . . . . . . . . . . . . . 5 71 5. Structure of the MIB Module . . . . . . . . . . . . . . . . . 6 72 5.1. Textual Conventions . . . . . . . . . . . . . . . . . . . 6 73 5.2. The extVacmCounters Subtree . . . . . . . . . . . . . . . 6 74 5.3. The Notifications Subtree . . . . . . . . . . . . . . . . 6 75 5.4. The Table Structures . . . . . . . . . . . . . . . . . . . 6 76 6. Relationship to Other MIB Modules . . . . . . . . . . . . . . 7 77 6.1. Relationship to the VACM MIB . . . . . . . . . . . . . . . 7 78 6.1.1. Extended VACM for RADIUS Authorization . . . . . . . . 7 79 6.1.2. VACM Extension for RADIUS Authorization . . . . . . . 7 80 6.1.2.1. Dynamic Update of VACM and Extended VACM MIB 81 Module Objects . . . . . . . . . . . . . . . . . . 7 82 6.1.2.2. Purging Volatile Entries in the Extended VACM 83 MIB Module . . . . . . . . . . . . . . . . . . . . 9 84 6.1.3. Elements of Procedure for Extended VACM . . . . . . . 9 85 6.2. MIB modules required for IMPORTS . . . . . . . . . . . . . 10 86 7. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 10 87 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 88 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 89 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 17 90 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 91 11.1. Normative References . . . . . . . . . . . . . . . . . . . 17 92 11.2. Informative References . . . . . . . . . . . . . . . . . . 18 93 Appendix A. Open Issues . . . . . . . . . . . . . . . . . . . . . 18 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 96 1. Introduction 98 1.1. General 100 This memo specifies the integration of several protocols to 101 operationally simplify the administration of the access rights 102 granted to users of network management data. In this environment: 104 o The View-Based Access Control Model (VACM) [RFC3415] provides a 105 means to manage users' access rights to management information 106 accessed using SNMP. 108 o The Simple Network Management Protocol version 3 (SNMPv3) provides 109 message security services through the Security Subsystem. 111 o The Transport Subsystem for the Simple Network Management Protocol 112 [RFC5590] defines a Transport Subsystem. 114 o The Transport Security Model for SNMP [RFC5591] defines a 115 Transport Security Model. 117 o The Secure Shell Transport Model for SNMP [RFC5592] defines a 118 Secure Shell Transport Model and Remote Authentication Dial-In 119 User Service (RADIUS). 121 o RADIUS Usage for Simple Network Management Protocol (SNMP) 122 Transport Models [RFC5608] defines a method for authenticating 123 SNMPv3 users via RADIUS. 125 It is possible to authenticate SNMPv3 messages via a RADIUS when 126 those messages are sent over the SSH transport. As originally 127 envisioned, VACM authorizes a given SNMP transaction using on-device, 128 pre-existing authorization configuration. In order to leverage a 129 centralized RADIUS service to its full extent, the access control 130 decision in the Access Control Subsystem needs to be able to make use 131 of authorization information received from RADIUS as well. This 132 document defines an extension to the View-based Access Control Model 133 to obtain authorization information for an authenticated principal, 134 from RADIUS. 136 Additional introductory material on the RADIUS operational model and 137 RADIUS usage with SNMP may be found in Sections 1.3 and 1.5 of 138 [RFC5608]. 140 It is important to understand the SNMP architecture and the 141 terminology of the architecture to understand where the Extended 142 View-based Access Control Model described in this memo fits into the 143 architecture and how it interacts with other subsystems and models 144 within the architecture. It is expected that reader will have also 145 read and understood RFC3411 [RFC3411], RFC3412 [RFC3412], RFC3413 146 [RFC3413], RFC3415 [RFC3415]and RFC3418 [RFC3418]. As this document 147 describes an extension to VACM, a thorough understanding of RFC3415 148 [RFC3415] is assumed. 150 2. The Internet-Standard Management Framework 152 For a detailed overview of the documents that describe the current 153 Internet-Standard Management Framework, please refer to section 7 of 154 RFC 3410 [RFC3410]. 156 Managed objects are accessed via a virtual information store, termed 157 the Management Information Base or MIB. MIB objects are generally 158 accessed through the Simple Network Management Protocol (SNMP). 159 Objects in the MIB are defined using the mechanisms defined in the 160 Structure of Management Information (SMI). This memo specifies a MIB 161 module that is compliant to the SMIv2, which is described in STD 58, 162 RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 163 [RFC2580]. 165 3. Conventions 167 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 168 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 169 document are to be interpreted as described in RFC 2119 [RFC2119]. 171 4. Overview 173 4.1. System Block Diagram 175 A block diagram of the major system components referenced in this 176 document may be useful to understanding the text that follows. 178 +--------+ 179 +......................... |RADIUS |....+ 180 . |Server | . 181 Shared +--------+ . 182 User | . 183 Credentials RADIUS | Shared 184 . | RADIUS 185 . | Secret 186 . | . 187 +-------------+ +-----------------+ 188 | Network | | RADIUS Client / | 189 | Management | SNMP | SNMP Engine / | 190 | Application |------------------| Network Device | 191 +-------------+ SSH +-----------------+ 193 Block Diagram 195 This diagram illustrates that a network management application 196 communicates with a network device, the managed entity, using SNMP 197 over SSH. The network devices uses RADIUS to communicate with a 198 RADIUS Server to authenticate the network management application (or 199 the user whose credentials that application provides) and to obtain 200 authorization information related to access via SNMP for purpose of 201 device management. Other secure transport protocols might be used 202 instead of SSH. 204 4.2. Using RADIUS with SNMP 206 There are two use cases for RADIUS support of management access via 207 SNMP. These are (a) service authorization and (b) access control 208 authorization. RADIUS almost always involves user authentication as 209 prerequisite to authorization, and there is a user authentication 210 phase for each of these two use cases. The first use case is 211 discussed in detail in [RFC5608]. The second use case is the subject 212 of this document. This document describes how RADIUS attributes and 213 messages are applied to the specific application area of SNMP Access 214 Control Models, and VACM in particular. 216 This document assumes that Extended VACM will be used in conjunction 217 with an SNMP secure Transport Model and the SNMP Transport Security 218 Model. The rationale for this assumption is as follows. The RFC 219 3411 SNMP architecture maintains strong modularity and separation of 220 concerns, extending to separating user identity (authentication) from 221 user database access rights (authorization). The former is the 222 business of the Security Subsystem and the latter is the business of 223 the Access Control Subsystem. RADIUS, on the other hand, allows for 224 no such separation of authorization from authentication. In order to 225 use RADIUS with SNMP, binding of user authentication to user 226 authorization must be achieved, without violating the modularity of 227 the RFC 3411 SNMP architecture. 229 RADIUS does support a limited form of Authorize-Only operations. The 230 RADIUS "Authorize Only" Service-Type Attribute can be specified in an 231 Access-Request message, but only when accompanied by a RADIUS State 232 Attribute, which contains an implementation specific "cookie" 233 representing the successful outcome of a previous authentication 234 transaction. For that reason, it is not possible to completely 235 separate the use of RADIUS by the Access Control Subsystem from the 236 use of RADIUS by other subsystems. This suggests that the most 237 straightforward approach is to leverage the existing RADIUS usage, as 238 documented in [RFC5608], and the tmStateReference cache, as 239 documented in Section 5.2 of [RFC5590]. 241 This document also assumes that the detailed access control rules are 242 pre-configued in the NAS. Dynamic user authorization for MIB 243 database access control, as defined herein, is limited to mapping the 244 authenticated user to a pre-existing group, which in turn is mapped 245 to the pre-existing rules. The operative use case assumption is that 246 roles within an organization (i.e. groups and rules) change 247 infrequently while the users assigned to those roles change much more 248 frequently. It is the user to role mapping that is outsourced to the 249 RADIUS server. 251 5. Structure of the MIB Module 253 5.1. Textual Conventions 255 This MIB module makes use of the RowStatus, StorageType, 256 SnmpAdminString, and SnmpSecurityModel textual conventions. 258 5.2. The extVacmCounters Subtree 260 The extVacmCounters subtree contains all of this module's counters. 262 5.3. The Notifications Subtree 264 No notifications are defined in this MIB module 266 5.4. The Table Structures 267 6. Relationship to Other MIB Modules 269 6.1. Relationship to the VACM MIB 271 6.1.1. Extended VACM for RADIUS Authorization 273 This document will rely on implementation specific integration of the 274 RADIUS client for user authentication and authorization. Further, it 275 will rely on implementation specific caching of MIB database access 276 policy information, in the form of the RADIUS Management-Policy-Id 277 Attribute, such that it will be available to Extended VACM. 279 A NAS that is compliant to this specification, MUST treat any RADIUS 280 Access-Accept message that provisions a specific policy for MIB 281 database access control that cannot be provided as if an Access- 282 Reject message had been received instead. 284 The RADIUS Management-Policy-Id Attribute MUST be used in an Access- 285 Accept message to provision a user-specific access control policy for 286 use in conjunction with Extended VACM. The syntax and semantics of 287 the Management-Policy-Id attribute are described in Section 6.3 of 288 [RFC5607]. 290 The intended use of the content of the Management-Policy-Id attribute 291 is to provision a mapping between the authenticated user, associated 292 with the secure transport session, and an access control group pre- 293 provisioned in the VACM MIB module. Details of this mapping are 294 described in following sections. 296 6.1.2. VACM Extension for RADIUS Authorization 298 The extension to VACM [RFC3415] described in this document is a 299 method for one or more of its MIB module objects to be dynamically 300 provisioned based on information received from RADIUS, or some 301 similar AAA service. This extension requires no changes to the 302 Abstract Service Interface (ASI) for the Access Control Subsystem, 303 nor any changes in the Elements of Procedure (EOP) for VACM. A new 304 MIB module that augments the vacmSecurityToGroupTable is defined in 305 this document, as well as supplemental EOP for Extended VACM to 306 follow. It does require that a module of code somewhere in the NAS 307 be able to write to the VACM MIB module and Extended VACM MIB Module, 308 and that it reliably and consistently do so in immediate response to 309 access control policy information received from RADIUS. 311 6.1.2.1. Dynamic Update of VACM and Extended VACM MIB Module Objects 313 The implementation-dependent interface between the RADIUS Client 314 function and the SNMP Engine is responsible for updating the 315 vacmSecurityToGroupTable table within the VACM MIB Module [RFC3415] 316 and the corresponding rows of the extVacmSecurityToGroupTable. 317 Specifically, the RADIUS User-Name Attribute is used as the 318 vacmSecurityName and the RADIUS Management-Policy-Id Attribute is 319 used as the vacmGroupName. The vacmSecurityModel is the encoding for 320 the Transport Security Model. The vacmSecurityToGroupStorageType 321 should be (2) volatile. 323 In creating a row entry in the vacmSecurityToGroupTable, there are 324 three cases to consider: 326 o No existing row has a matching vacmSecurityName. 328 o An existing row has a matching vacmSecurityName. 330 o No additional rows can be created, e.g. because of resource 331 constraints, etc. 333 The second and third cases require special consideration. The second 334 case may represent a conflict between dynamic access control 335 authorization from RADIUS and local access control configuration by a 336 security administrator, e.g. via remote or local SNMP MIB module 337 updates. If one assumes that the security administrator 338 intentionally configured a table entry for the "conflicting" 339 vacmSecurityName, with full knowledge that it might over-ride dynamic 340 authorization information from RADIUS, the right thing to do would be 341 nothing. That is to say, do not update the table based on RADIUS 342 authorization information. On the other hand, it is possible that 343 the "name collision" is the result of a mistake, or the result of 344 stale configuration information. 346 The behavior specified for Extended VACM is to make no update to the 347 vacmSecurityToGroupTable, and to increment the 348 extVacmSecurityNameConflict counter. 350 The third case is likely to be rare, and SHOULD result in a 351 notification of some sort being logged for action by the system 352 administrator. 354 It is expected that the value of the RADIUS Management-Policy-Id 355 Attribute match an existing vacmGroupName that can be sucessfully 356 used as an index to the vacmAccessTable. If no matching 357 vacmGroupName exists, then the access control defaults to this will 358 result in the default access rights of "no access", which is the 359 desired result. The NAS should increment the extVacmMissingGroupName 360 counter, for troubleshooting purposes, as this most likely indicates 361 an administrative misconfiguration. 363 In addition to creating a new row in the vacmSecurityToGroupTable, 364 the NAS creates a corresponding new row in the 365 extVacmSecurityToGroupTable, using the same values for index as were 366 used to create the row in the vacmSecurityToGroupTable. The value of 367 the extVacmRowCreatedBy object is set to RADIUS (1), and the value of 368 extVacmRowLifetime is set to the value of the RADIUS Session-Timeout 369 Attribute, if one was received by the RADIUS Client for this session, 370 or to zero (0) otherwise. 372 6.1.2.2. Purging Volatile Entries in the Extended VACM MIB Module 374 When the secure transport session is torn down, disconnected or times 375 out, any volatile table rows created in the vacmSecurityToGroup table 376 by the Extended VACM function MUST be removed. The mechanism to 377 accomplish this task is implementation specific. 379 6.1.3. Elements of Procedure for Extended VACM 381 This section describes the Elements of Procedure for Extended VACM. 382 The function of the VACM extension is to manage the creation and 383 deletion of rows in the vacmSecurityToGroupTable, based on the 384 outcome of RADIUS authorization. All access control decision 385 functions are taken by VACM, as defined in [RFC3415]. The EOP for 386 VACM remains as listed in Section 3 of that document. 388 When a RADIUS (or other AAA service) authorizes SNMP data access 389 control for a user-authenticated secure transport session, the NAS 390 causes the RADIUS provisioning information to be made available to 391 the Extended VACM facility, which populates the 392 vacmSecurityToGroupTable, as follows: 394 1. If the the RADIUS Management-Policy-Id Attribute is not 395 available, increment the extVacmNoPolicy counter. Do not create 396 a table row. 398 2. If the the RADIUS Management-Policy-Id Attribute is available, 399 and if no existing row has a vacmSecurityName matching the RADIUS 400 User-Name Attribute, create a new row with the columns populated 401 as follows: 403 A. vacmSecurityModel = (x) secureTransportSecurityModel 405 B. vacmSecurityName = RADIUS User-Name Attribute 407 C. vacmGroupName = RADIUS Management-Policy-Id Attribute 408 D. vacmSecurityToGroupStorageType = volatile(2) 410 E. vacmSecurityToGroupStatus = createAndGo ??? 412 F. extVacmRowCreatedBy = (1) 414 G. extVacmRowLifetime = RADIUS Session-Timeout Attribute | zero 415 (0) 417 H. extVacmTransportSessionID = ID provided by the Secure 418 Transport Model 420 3. If an existing table row has a matching vacmSecurityName, 421 increment the extVacmSecurityNameConflict counter. Do not create 422 a table row. If no additional table rows can be created, e.g. 423 because of resource constraints, increment the 424 extVacmResourceError counter. 426 When a RADIUS-authenticated secure transport session is disconnected 427 by the remote peer, the NAS causes the Extended VACM to remove the 428 corresponding table row from the vacmSecurityToGroupTable. The NAS 429 provides an implementation dependent identifier of the session in 430 question to Extended VACM. 432 1. Search for a row with a matching extVacmTransportSessionID. 434 2. If found, check to see that the extVacmRowCreateby value is (1) 435 radius. If not, ignore the request. 437 3. If a table row exists with a matching value of 438 extVACMTransportSessionID, that row is deleted. 440 6.2. MIB modules required for IMPORTS 442 The MIB module defined employs textual conventions from [RFC2579] and 443 [RFC3411]. 445 7. Definitions 447 SNMP-EXT-VACM-MIB DEFINITIONS ::= BEGIN 449 IMPORTS 450 MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF 451 MODULE-IDENTITY, OBJECT-TYPE, 452 mib-2, 453 Unsigned32, 454 Counter32 FROM SNMPv2-SMI 455 RowStatus, StorageType FROM SNMPv2-TC 456 SnmpAdminString, 457 SnmpSecurityModel FROM SNMP-FRAMEWORK-MIB; 459 snmpExtVacmMIB MODULE-IDENTITY 460 LAST-UPDATED "200912020000Z" -- 1 Dec. 2009, midnight 461 ORGANIZATION "ISMS Working Group" 462 CONTACT-INFO "WG-email: isms@ietf.org" 464 DESCRIPTION "The management and local datstore information 465 definitions for the Extended View-based Access 466 Control Model for SNMP. 468 Copyright (C) The Internet Society (2009)." 470 REVISION "200912020000Z" 471 DESCRIPTION "Initial version,published as RFCZZZZ." 472 ::= { mib-2 XXX } 474 extVacmMIBObjects OBJECT IDENTIFIER ::= { snmpExtVacmMIB 1 } 476 extVacmMIBConformance OBJECT IDENTIFIER ::= {snmpExtVacmMIB 2 } 478 extVacmCounters OBJECT IDENTIFIER ::= { extVacmMIBObjects 1 } 480 extVacmResourceError OBJECT-TYPE 481 SYNTAX Counter32 482 UNITS "lost rows" 483 MAX-ACCESS read-only 484 STATUS current 485 DESCRIPTION 486 "The number of VACM Security Name to Security 487 Group table rows that could not be created by 488 Extended VACM because of insufficient resources." 489 ::= { extVacmCounters 1 } 491 extVacmNoPolicy OBJECT-TYPE 492 SYNTAX Counter32 493 UNITS "lost rows" 494 MAX-ACCESS read-only 495 STATUS current 496 DESCRIPTION 497 "The number of VACM Security Name to Security 498 Group table rows that could not be created by 499 Extended VACM because the AAA-provisioned 500 group policy did not match an existing row in 501 the VACM access table." 502 ::= { extVacmCounters 2 } 504 extVacmSecurityNameConflict OBJECT-TYPE 505 SYNTAX Counter32 506 UNITS "lost rows" 507 MAX-ACCESS read-only 508 STATUS current 509 DESCRIPTION 510 "The number of VACM Security Name to Security 511 Group table rows that could not be created by 512 Extended VACM because the AAA-provisioned 513 security name (user name) conflicted with an 514 existing row in the table." 515 ::= { extVacmCounters 3 } 517 extVacmSecurityToGroupTable OBJECT-TYPE 518 SYNTAX SEQUENCE OF ExtVacmSecurityToGroupEntry 519 MAX-ACCESS not-accessible 520 STATUS current 521 DESCRIPTION "This table maps a combination of securityModel and 522 securityName into a groupName which is used to define 523 an access control policy for a group of principals." 524 ::= { extVacmMIBObjects 2 } 526 extVacmSecurityToGroupEntry OBJECT-TYPE 527 SYNTAX ExtVacmSecurityToGroupEntry 528 MAX-ACCESS not-accessible 529 STATUS current 530 DESCRIPTION "An entry in this table maps the combination of a 531 securityModel and securityName into a groupName." 532 INDEX { 533 extVacmSecurityModel, 534 extVacmSecurityName 535 } 536 ::= { extVacmSecurityToGroupTable 1 } 538 ExtVacmSecurityToGroupEntry ::= SEQUENCE 539 { 540 extVacmSecurityModel SnmpSecurityModel, 541 extVacmSecurityName SnmpAdminString, 542 extVacmGroupName SnmpAdminString, 543 extVacmSecurityToGroupStorageType StorageType, 544 extVacmSecurityToGroupStatus RowStatus, 545 extVacmRowCreatedBy INTEGER, 546 extVacmRowLifetime Unsigned32, 547 extVacmTransportSessionID Unsigned32 549 } 551 extVacmSecurityModel OBJECT-TYPE 552 SYNTAX SnmpSecurityModel(1..2147483647) 553 MAX-ACCESS not-accessible 554 STATUS current 555 DESCRIPTION "The Security Model, by which the vacmSecurityName 556 referenced by this entry is provided. 557 Note, this object may not take the 'any' (0) value." 558 ::= { extVacmSecurityToGroupEntry 1 } 560 extVacmSecurityName OBJECT-TYPE 561 SYNTAX SnmpAdminString (SIZE(1..32)) 562 MAX-ACCESS not-accessible 563 STATUS current 564 DESCRIPTION "The securityName for the principal, represented in a 565 Security Model independent format, which is mapped by 566 this entry to a groupName." 567 ::= { extVacmSecurityToGroupEntry 2 } 569 extVacmGroupName OBJECT-TYPE 570 SYNTAX SnmpAdminString (SIZE(1..32)) 571 MAX-ACCESS read-create 572 STATUS current 573 DESCRIPTION "The name of the group to which this entry (e.g., the 574 combination of securityModel and securityName) 575 belongs. 577 This groupName is used as index into the 578 vacmAccessTable to select an access control policy. 579 A value in this table does not imply that an instance 580 with the value exists in table vacmAccesTable." 581 ::= { extVacmSecurityToGroupEntry 3 } 583 extVacmSecurityToGroupStorageType OBJECT-TYPE 584 SYNTAX StorageType 585 MAX-ACCESS read-create 586 STATUS current 587 DESCRIPTION "The storage type for this conceptual row. 588 Conceptual rows having the value 'permanent' need not 589 allow write-access to any columnar objects in the row." 590 DEFVAL { nonVolatile } 591 ::= { extVacmSecurityToGroupEntry 4 } 593 extVacmSecurityToGroupStatus OBJECT-TYPE 594 SYNTAX RowStatus 595 MAX-ACCESS read-create 596 STATUS current 597 DESCRIPTION "The status of this conceptual row. 599 Until instances of all corresponding columns are 600 appropriately configured, the value of the 601 corresponding instance of the vacmSecurityToGroupStatus 602 column is 'notReady'. 604 In particular, a newly created row cannot be made 605 active until a value has been set for vacmGroupName. 607 The RowStatus TC [RFC2579] requires that this 608 DESCRIPTION clause states under which circumstances 609 other objects in this row can be modified: 611 The value of this object has no effect on whether 612 other objects in this conceptual row can be modified." 613 ::= { extVacmSecurityToGroupEntry 5 } 615 extVacmRowCreatedBy OBJECT-TYPE 616 SYNTAX INTEGER 617 { radius (1), -- Row created by Extended VACM 618 other (2) -- ??? 619 } 620 MAX-ACCESS read-create 621 STATUS current 622 DESCRIPTION "The source of the infromation in this row 623 is indicated by the value of this object. 624 In the case of VACM this column probably won't 625 exist." 626 ::= { extVacmSecurityToGroupEntry 6 } 628 extVacmRowLifetime OBJECT-TYPE 629 SYNTAX Unsigned32 630 UNITS "seconds" 631 MAX-ACCESS read-create 632 STATUS current 633 DESCRIPTION "The number of seconds remaining in this row's 634 lifetime. Extended VACM SHOULD delete this 635 row when this value reaches zero." 636 ::= { extVacmSecurityToGroupEntry 7 } 638 extVacmTransportSessionID OBJECT-TYPE 639 SYNTAX Unsigned32 640 MAX-ACCESS read-create 641 STATUS current 642 DESCRIPTION "An identifier of the secure transport 643 model's session associated with this 644 authenticated user. The identifier 645 MUST be unique within the scope of the NAS. 646 It's content is implementation dependant 647 and it SHOULD be used merely as an index." 648 ::= { extVacmSecurityToGroupEntry 8 } 650 -- Conformance information ****************************************** 652 extVacmMIBCompliances 653 OBJECT IDENTIFIER ::= {extVacmMIBConformance 1} 654 extVacmMIBGroups 655 OBJECT IDENTIFIER ::= {extVacmMIBConformance 2} 657 -- compliance statements 659 extVacmMIBBasicCompliance MODULE-COMPLIANCE 660 STATUS current 661 DESCRIPTION "The compliance statement for SNMP engines which 662 implement the Extensions to the View-based Access 663 Control Model for use with RADIUS. 664 " 665 MODULE -- this module 666 MANDATORY-GROUPS { extVacmGroup } 668 ::= { extVacmMIBCompliances 1 } 670 -- units of conformance 672 extVacmGroup OBJECT-GROUP 673 OBJECTS { 674 extVacmResourceError, 675 extVacmNoPolicy, 676 extVacmSecurityNameConflict, 677 extVacmGroupName, 678 extVacmSecurityToGroupStorageType, 679 extVacmSecurityToGroupStatus, 680 extVacmRowCreatedBy, 681 extVacmRowLifetime, 682 extVacmTransportSessionID 683 } 684 STATUS current 685 DESCRIPTION "A collection of objects for supporting the use 686 of RADIUS to provide user / group mappings for VACM. 687 " 688 ::= { extVacmMIBGroups 1 } 690 END 691 8. Security Considerations 693 TODO 695 Some of the readable objects in this MIB module (i.e., objects with a 696 MAX-ACCESS other than not-accessible) may be considered sensitive or 697 vulnerable in some network environments. It is thus important to 698 control even GET and/or NOTIFY access to these objects and possibly 699 to even encrypt the values of these objects when sending them over 700 the network via SNMP. These are the tables and objects and their 701 sensitivity/vulnerability: 703 o TBD 705 SNMP versions prior to SNMPv3 did not include adequate security. 706 Even if the network itself is secure (for example by using IPsec), 707 even then, there is no control as to who on the secure network is 708 allowed to access and GET/SET (read/change/create/delete) the objects 709 in this MIB module. 711 It is RECOMMENDED that implementers consider the security features as 712 provided by the SNMPv3 framework (see [RFC3410], section 8), 713 including full support for the SNMPv3 cryptographic mechanisms (for 714 authentication and privacy). 716 Further, deployment of SNMP versions prior to SNMPv3 is NOT 717 RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to 718 enable cryptographic security. It is then a customer/operator 719 responsibility to ensure that the SNMP entity giving access to an 720 instance of this MIB module is properly configured to give access to 721 the objects only to those principals (users) that have legitimate 722 rights to indeed GET or SET (change/create/delete) them. 724 9. IANA Considerations 726 The MIB module in this document uses the following IANA-assigned 727 OBJECT IDENTIFIER values recorded in the SMI Numbers registry: 729 Descriptor OBJECT IDENTIFIER value 730 ---------- ----------------------- 731 snmpExtVacmMIB { mib-2 XXX } 733 Editor's Note (to be removed prior to publication): the IANA is 734 requested to assign a value for "XXX" under the 'mib-2' subtree and 735 to record the assignment in the SMI Numbers registry. When the 736 assignment has been made, the RFC Editor is asked to replace "XXX" 737 (here and in the MIB module) with the assigned value and to remove 738 this note. 740 10. Contributors 742 The following participants from the isms working group contributed to 743 the devlopment of this document: 745 o David Harrington 747 o Juergen Schoenwaelder 749 11. References 751 11.1. Normative References 753 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 754 Requirement Levels", BCP 14, RFC 2119, March 1997. 756 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 757 Schoenwaelder, Ed., "Structure of Management Information 758 Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 760 [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. 761 Schoenwaelder, Ed., "Textual Conventions for SMIv2", 762 STD 58, RFC 2579, April 1999. 764 [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, 765 "Conformance Statements for SMIv2", STD 58, RFC 2580, 766 April 1999. 768 [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An 769 Architecture for Describing Simple Network Management 770 Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, 771 December 2002. 773 [RFC3415] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based 774 Access Control Model (VACM) for the Simple Network 775 Management Protocol (SNMP)", STD 62, RFC 3415, 776 December 2002. 778 [RFC5590] Harrington, D. and J. Schoenwaelder, "Transport Subsystem 779 for the Simple Network Management Protocol (SNMP)", 780 RFC 5590, June 2009. 782 [RFC5591] Harrington, D. and W. Hardaker, "Transport Security Model 783 for the Simple Network Management Protocol (SNMP)", 784 RFC 5591, June 2009. 786 [RFC5607] Nelson, D. and G. Weber, "Remote Authentication Dial-In 787 User Service (RADIUS) Authorization for Network Access 788 Server (NAS) Management", RFC 5607, July 2009. 790 [RFC5608] Narayan, K. and D. Nelson, "Remote Authentication Dial-In 791 User Service (RADIUS) Usage for Simple Network Management 792 Protocol (SNMP) Transport Models", RFC 5608, August 2009. 794 11.2. Informative References 796 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, 797 "Introduction and Applicability Statements for Internet- 798 Standard Management Framework", RFC 3410, December 2002. 800 [RFC3412] Case, J., Harrington, D., Presuhn, R., and B. Wijnen, 801 "Message Processing and Dispatching for the Simple Network 802 Management Protocol (SNMP)", STD 62, RFC 3412, 803 December 2002. 805 [RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple Network 806 Management Protocol (SNMP) Applications", STD 62, 807 RFC 3413, December 2002. 809 [RFC3418] Presuhn, R., "Management Information Base (MIB) for the 810 Simple Network Management Protocol (SNMP)", STD 62, 811 RFC 3418, December 2002. 813 [RFC5592] Harrington, D., Salowey, J., and W. Hardaker, "Secure 814 Shell Transport Model for the Simple Network Management 815 Protocol (SNMP)", RFC 5592, June 2009. 817 Appendix A. Open Issues 819 This section identifies questions and issues that have not been 820 addressed in this version of this document. This section will 821 probably be removed prior to publication, since there will be no 822 questions left to address. 824 1. Is this document an amendment or update to RFC 3514? Or is it 825 simply a standalone document that describes how to provision 826 certain MIB Objects defined in RFC 3514, along with an extended 827 set of augmenting table columns? 829 2. Does this document need to make any reference to the Elements of 830 Procedure in RFC 3514, or does is simply need its own Elements of 831 Procedure for updating the group mapping table? 833 3. Dave Harrington had issued a summary email after IETF75 834 containing apparently contradictory statements about whether the 835 additional columns should be in the *same* table that VACM uses 836 or in another, separate table that augments the VACM table. 837 Basically, we need some help in actually structuring the new MIB 838 Module. 840 4. The Groups and Conformance sections of the MIB Module need to be 841 checked and kept in alignment with the definitions. 843 5. Make sure that the new Elements of Procedure make sense and cover 844 all the corner cases correctly. 846 6. for session tracking use tlstmSessionID? 848 7. Make boilerplate in MIB module agree with the legal trust 849 incantation du jour. 851 8. Security considerations need to be filled in, specifically 852 concerning trust relationships to RADIUS and the interaction with 853 statically configured policy. 855 Authors' Addresses 857 Kaushik Narayan 858 Cisco Systems, Inc. 859 10 West Tasman Drive 860 San Jose, CA 95134 861 USA 863 Phone: +1.408.526.8168 864 Email: kaushik_narayan@yahoo.com 865 David Nelson 866 Elbrys Networks, Inc. 867 282 Corporate Drive, Unit #1, 868 Portsmouth, NH 03801 869 USA 871 Phone: +1.603.570.2636 872 Email: d.b.nelson@comcast.net 874 Randy Presuhn (editor) 875 None 877 Email: randy_presuhn@mindspring.com