idnits 2.17.1 draft-ietf-isms-radius-vacm-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 date (September 14, 2010) is 4973 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: 0 errors (**), 0 flaws (~~), 1 warning (==), 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: March 18, 2011 Elbrys Networks, Inc. 6 R. Presuhn, Ed. 7 None 8 September 14, 2010 10 Using Authentication, Authorization, and Accounting services to 11 Dynamically Provision View-based Access Control Model User-to-Group 12 Mappings 13 draft-ietf-isms-radius-vacm-11.txt 15 Abstract 17 This memo defines a portion of the Management Information Base (MIB) 18 for use with network management protocols. It describes the use of 19 information provided by Authentication, Authorization, and Accounting 20 (AAA) services, such as the Remote Authentication Dial-In User 21 Service (RADIUS), to dynamically update user-to-group mappings in the 22 View-Based Access Control Model (VACM). 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on March 18, 2011. 41 Copyright Notice 43 Copyright (c) 2010 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. The Internet-Standard Management Framework . . . . . . . . . . 3 60 3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 4.1. Using AAA services with SNMP . . . . . . . . . . . . . . . 4 63 4.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 5 64 5. Structure of the MIB Module . . . . . . . . . . . . . . . . . 6 65 5.1. Textual Conventions . . . . . . . . . . . . . . . . . . . 6 66 5.2. The Table Structure . . . . . . . . . . . . . . . . . . . 6 67 6. Relationship to Other MIB Modules . . . . . . . . . . . . . . 6 68 6.1. Relationship to the VACM MIB . . . . . . . . . . . . . . . 6 69 6.2. MIB modules required for IMPORTS . . . . . . . . . . . . . 6 70 6.3. Documents required for REFERENCE clauses . . . . . . . . . 6 71 7. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 7 72 7.1. Sequencing Requirements . . . . . . . . . . . . . . . . . 7 73 7.2. Actions Upon Session Establishment Indication . . . . . . 7 74 7.2.1. Required Information . . . . . . . . . . . . . . . . . 7 75 7.2.2. Creation of Entries in vacmAaaSecurityToGroupTable . . 8 76 7.2.3. Creation of Entries in vacmSecurityToGroupTable . . . 8 77 7.2.4. Update of vacmGroupName . . . . . . . . . . . . . . . 9 78 7.3. Actions Upon Session Termination Indication . . . . . . . 9 79 7.3.1. Deletion of Entries from 80 vacmAaaSecurityToGroupTable . . . . . . . . . . . . . 9 81 7.3.2. Deletion of Entries from vacmSecurityToGroupTable . . 10 82 8. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 10 83 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 84 9.1. Principal Identity Naming . . . . . . . . . . . . . . . . 14 85 9.2. Management Information Considerations . . . . . . . . . . 15 86 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 87 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 17 88 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 89 12.1. Normative References . . . . . . . . . . . . . . . . . . . 18 90 12.2. Informative References . . . . . . . . . . . . . . . . . . 19 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 93 1. Introduction 95 This memo specifies a way to dynamically provision selected View- 96 Based Access Control Model (VACM) [RFC3415] Management Information 97 Base (MIB) objects, based on information received from an 98 Authentication, Authorization, and Accounting (AAA) service, such as 99 RADIUS [RFC2865] and [RFC5607]. It reduces the need for security 100 administrators to manually update VACM configurations due to user 101 churn, allowing a centralized AAA service to provide the information 102 associating a given user with the access control policy (known as a 103 "group" in VACM) governing that user's access to management 104 information. 106 This memo requires no changes to the Abstract Service Interface for 107 the Access Control Subsystem, and requires no changes to the Elements 108 of Procedure for VACM. It provides a MIB module that reflects the 109 information provided by the AAA service, along with elements of 110 procedure for maintaining that information and performing 111 corresponding updates to VACM MIB data. 113 The reader is expected to be familiar with [RFC3415], [RFC5607], 114 [RFC5608], and their supporting specifications. 116 2. The Internet-Standard Management Framework 118 For a detailed overview of the documents that describe the current 119 Internet-Standard Management Framework, please refer to section 7 of 120 RFC 3410 [RFC3410]. 122 Managed objects are accessed via a virtual information store, termed 123 the Management Information Base or MIB. MIB objects are generally 124 accessed through the Simple Network Management Protocol (SNMP). 125 Objects in the MIB are defined using the mechanisms defined in the 126 Structure of Management Information (SMI). This memo specifies a MIB 127 module that is compliant to the SMIv2, which is described in STD 58, 128 RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 129 [RFC2580]. 131 3. Conventions 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 135 "OPTIONAL" in this document are to be interpreted as described in RFC 136 2119 [RFC2119]. 138 4. Overview 140 4.1. Using AAA services with SNMP 142 There are two use cases for AAA support of management access via 143 SNMP. These are (a) service authorization and (b) access control 144 authorization. The former is discussed in detail in [RFC5608]. The 145 latter is the subject of this memo. 147 The use case assumption here is that roles within an organization, 148 which are reflected in VACM as groups, naming access control 149 policies, change infrequently, while the users assigned to those 150 roles change much more frequently. This memo describes how the user- 151 to-role (group) mapping can be delegated to the RADIUS server, 152 avoiding the need to re-provision managed devices as users are added, 153 deleted, or assigned new roles in an organization. 155 This memo assumes that the detailed access control policies are pre- 156 configured in VACM, and does not attempt to address the question of 157 how the policy associated with a given role is put in place. 159 The only additional information obtained from the AAA service is the 160 mapping of the authenticated user's identifier to a specific role (or 161 "group" in VACM terminology) in the access control policy. Dynamic 162 user authorization for MIB database access control, as defined 163 herein, is limited to mapping the authenticated user to a group, 164 which in turn is mapped to whatever access control policies are 165 already in place in VACM. 167 The SNMP architecture [RFC3411] maintains strong modularity and 168 separation of concerns, separating user identity (authentication) 169 from user database access rights (authorization). RADIUS, on the 170 other hand, allows for no such separation of authorization from 171 authentication. Consequently, the approach here is to leverage 172 existing RADIUS usage for identifying a principal, documented in 173 [RFC5608], along with the RADIUS Management-Policy-Id Attribute 174 [RFC5607]. 176 A unique identifier is needed for each AAA-authorized "session", 177 corresponding to a communication channel, such as a transport 178 session, for which a principal has been AAA-authenticated and which 179 is authorized to offer SNMP service. How these identifiers are 180 assigned is implementation-dependent. When a RADIUS Management- 181 Policy-Id Attribute (or equivalent) is bound to such a session and 182 principal authentication, this binding provides sufficient 183 information to compute dynamic updates to VACM. How this information 184 is communicated within an implementation is implementation dependent; 185 this memo is only concerned with externally observable behavior. 187 The key concept here is that what we will informally call a "AAA 188 binding" binds: 190 1. a communications channel 192 2. an authenticated principal 194 3. service authorization 196 4. an access control policy name 198 Some of the binding is done via other specifications. A transport 199 model, such as the Secure Shell Transport Model [RFC5592], provides a 200 binding between 1) and 2) and 3), providing a securityName. In turn, 201 [RFC5607] provides a binding between (1+2+3) and 4). This document 202 extends that further, to create a binding between (1+2+3+4) and the 203 local (VACM MIB) definition of the named policy, called a group in 204 VACM. 206 4.2. Applicability 208 Though this memo was motivated to support the use of specific 209 Transport Models, such as the Secure Shell Transport Model [RFC5592], 210 it MAY be used with other implementation environments satisfying 211 these requirements: 213 o use an AAA service for sign-on service and data access 214 authorization; 216 o provide an indication of the start of a session for a particular 217 authenticated principal, identified using an SNMP securityName 218 [RFC3411], and provide the corresponding value to be used to 219 identify a VACM group to be used, based on information provided by 220 the AAA service in use; 222 o provide an indication of the end of the need for being able to 223 make access decisions for a particular authenticated principal, as 224 at the end of a session, whether due to disconnection, termination 225 due to timeout, or any other reason. 227 Likewise, although this memo specifically refers to RADIUS, it MAY be 228 used with other AAA services satisfying these requirements: 230 o the service provides information semantically equivalent to the 231 RADIUS Management-Policy-Id Attribute [RFC5607], which corresponds 232 to the name of a VACM group; 234 o the service provides an authenticated principal identifier (e.g., 235 the RADIUS User-Name Attribute [RFC2865]) which can be transformed 236 to an equivalent principal identifier in the form of a 237 securityName [RFC3411]. 239 5. Structure of the MIB Module 241 5.1. Textual Conventions 243 This MIB module makes use of the SnmpAdminString [RFC3411] and 244 SnmpSecurityModel [RFC3411] textual conventions. 246 5.2. The Table Structure 248 This MIB module defines a single table, the 249 vacmAaaSecurityToGroupTable. This table is indexed by the integer 250 assigned to each security model, the protocol-independent 251 securityName corresponding to a principal, and the unique identifier 252 of a session. 254 6. Relationship to Other MIB Modules 256 This MIB module has a close operational relationship with the SNMP- 257 VIEW-BASED-ACM-MIB (more commonly known as the "VACM MIB") from 258 [RFC3415]. It also relies on IMPORTS from several other modules. 260 6.1. Relationship to the VACM MIB 262 Although the MIB module defined here has a close relationship with 263 the VACM MIB's vacmSecurityToGroupTable, it in no way changes the 264 elements of procedure for VACM, nor does it affect any other tables 265 defined in VACM. See the elements of procedure (below) for details 266 of how the contents of the vacmSecurityToGroupTable are affected by 267 this MIB module. 269 6.2. MIB modules required for IMPORTS 271 This MIB module employs definitions from [RFC2578], [RFC2579] and 272 [RFC3411]. 274 6.3. Documents required for REFERENCE clauses 276 This MIB module contains REFERENCE clauses making reference to 277 [RFC2865], [RFC3411], and [RFC5590]. 279 7. Elements of Procedure 281 The following elements of procedure are formulated in terms of two 282 types of events: an indication of the establishment of a session, and 283 an indication that one has ended. These can result in the creation 284 of entries in the vacmAaaSecurityToGroupTable, which can in turn 285 trigger creation, update, or deletion of entries in the 286 vacmSecurityToGroupTable. 288 There are various possible implementation-dependent error cases not 289 spelled out here, such as running out of memory. By their nature, 290 recovery in such cases will be implementation-dependent. 291 Implementors are advised to consider fail-safe strategies, e.g., 292 prematurely terminating access in preference to erroneously 293 perpetuating access. 295 7.1. Sequencing Requirements 297 These procedures assume that a transport model, such as [RFC5592], 298 coordinates session establishment with AAA authentication and 299 authorization. They rely on the receipt by the AAA client of the 300 RADIUS Management-Policy-Id [RFC5607] Attribute (or its equivalent) 301 from the RADIUS Access-Accept message (or equivalent). They also 302 assume that the User-Name [RFC2865] from the RADIUS Access-Request 303 message (or equivalent) corresponds to a securityName [RFC3411]. 305 To ensure correct processing of SNMP PDUs, the handling of the 306 indication of the establishment of a session in accordance with the 307 elements of procedure below MUST be completed before the 308 isAccessAllowed() abstract service interface [RFC3415] is invoked for 309 any SNMP PDUs from that session. 311 If a session termination indication occurs before all invocations of 312 the isAccessAllowed() abstract service interface [RFC3415] have 313 completed for all SNMP PDUs from that session, those remaining 314 invocations MAY result in denial of access. 316 7.2. Actions Upon Session Establishment Indication 318 7.2.1. Required Information 320 Four pieces of information are needed to process the session 321 establishment indication: 323 o the SnmpSecurityModel [RFC3411] needed as an index into the 324 vacmSecurityToGroupTable; 326 o the RADIUS User-Name Attribute; 328 o a session identifier, as a unique, definitive identifier of the 329 session that the AAA authorization is tied to; 331 o the RADIUS Management-Policy-Id Attribute. 333 All four of these pieces of information are REQUIRED. In particular, 334 if either the User-Name or Management-Policy-Id is absent, invalid, 335 or a zero-length string, no further processing of the session 336 establishment indication is undertaken. 338 As noted in Section 4.2, the above text refers specifically to RADIUS 339 attributes. Other AAA services can be substituted, but the 340 requirements imposed on the User-Name and the Management-Policy-Id- 341 Attribute MUST be satisfied using the equivalent fields for those 342 services. 344 7.2.2. Creation of Entries in vacmAaaSecurityToGroupTable 346 Whenever an indication arrives that a new session has been 347 established, determine whether a corresponding entry exists in the 348 vacmAaaSecurityToGroupTable. If one does not, create a new row with 349 the columns populated as follows: 351 o vacmAaaSecurityModel = value of SnmpSecurityModel corresponding to 352 the security model in use; 354 o vacmAaaSecurityName = RADIUS User-Name Attribute or equivalent, 355 the securityName that will be used in invocations of the 356 isAccessAllowed() abstract service interface [RFC3415]; 358 o vacmAaaSessionID = session identifier, unique across all open 359 sessions of all of this SNMP engine's transport models; 361 o vacmAaaGroupName = RADIUS Management-Policy-Id Attribute or 362 equivalent. 364 Otherwise, if the row already exists, update the vacmAaaGroupName 365 with the the RADIUS Management-Policy-Id Attribute or equivalent 366 supplied. 368 7.2.3. Creation of Entries in vacmSecurityToGroupTable 370 Whenever an entry is created in the vacmAaaSecurityToGroupTable, the 371 vacmSecurityToGroupTable is examined to determine whether a 372 corresponding entry exists there, using the value of 373 vacmAaaSecurityModel for vacmSecurityModel, and the value of 374 vacmAaaSecurityName for vacmSecurityName. If no corresponding entry 375 exists, create one, using the vacmAaaGroupName of the newly created 376 entry to fill in vacmGroupName, using a value of "volatile" for the 377 row's StorageType, and a value of "active" for its RowStatus. 379 7.2.4. Update of vacmGroupName 381 Whenever the value of an instance of vacmAaaGroupName is updated, if 382 a corresponding entry exists in the vacmSecurityToGroupTable, and 383 that entry's StorageType is "volatile" and its RowStatus is "active", 384 update the value of vacmGroupName with the value from 385 vacmAaaGroupName. 387 If a corresponding entry already exists in the 388 vacmSecurityToGroupTable, and that row's StorageType is anything 389 other than "volatile", or its RowStatus is anything other than 390 "active", then that instance of vacmGroupName MUST NOT be modified. 392 The operational assumption here is that if the row's StorageType is 393 "volatile", then this entry was probably dynamically created; an 394 entry created by a security administrator would not normally be given 395 a StorageType of "volatile". If value being provided by RADIUS (or 396 other AAA service) is the same as what is already there, this is a 397 no-op. If the value is different, the new information is understood 398 as a more recent role (group) assignment for the user, which should 399 supersede the one currently held there. The structure of the 400 vacmSecurityToGroupTable makes it impossible for a 401 (vacmSecurityModel, vacmSecurityName) tuple to map to more than one 402 group. 404 7.3. Actions Upon Session Termination Indication 406 Whenever a RADIUS (or other AAA) authenticated session ends for any 407 reason, an indication is provided. This indication MUST provide 408 means of determining the SnmpSecurityModel, and an identifier for the 409 transport session tied to the AAA authorization. The manner in which 410 this occurs is implementation dependent. 412 7.3.1. Deletion of Entries from vacmAaaSecurityToGroupTable 414 Entries in the vacmAaaSecurityToGroupTable MUST NOT persist across 415 system reboots. 417 When a session has been terminated, the vacmAaaSecurityToGroupTable 418 is searched for a corresponding entry. A "matching" entry is any 419 entry for which the SnmpSecurityModel and session ID match the 420 information associated with the session termination indication. Any 421 matching entries are deleted. It is possible that no entries will 422 match; this is not an error, and no special processing is required in 423 this case. 425 7.3.2. Deletion of Entries from vacmSecurityToGroupTable 427 Whenever the last remaining row bearing a particular 428 (vacmAaaSecurityModel, vacmAaaSecurityName) pair is deleted from the 429 vacmAaaSecurityToGroupTable, the vacmSecurityToGroupTable is examined 430 for a corresponding row. If one exists, and if its StorageType is 431 "volatile" and its RowStatus is "active", that row MUST be deleted as 432 well. The mechanism to accomplish this task is implementation- 433 dependent. 435 8. Definitions 437 SNMP-VACM-AAA-MIB DEFINITIONS ::= BEGIN 439 IMPORTS 440 MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF 441 MODULE-IDENTITY, OBJECT-TYPE, 442 mib-2, 443 Unsigned32 FROM SNMPv2-SMI 444 SnmpAdminString, 445 SnmpSecurityModel FROM SNMP-FRAMEWORK-MIB; 447 vacmAaaMIB MODULE-IDENTITY 448 LAST-UPDATED "201009010000Z" -- 1 September, 2010 449 ORGANIZATION "ISMS Working Group" 450 CONTACT-INFO "WG-email: isms@ietf.org" 452 DESCRIPTION "The management and local datastore information 453 definitions for the AAA-Enabled View-based Access 454 Control Model for SNMP. 456 Copyright (c) 2010 IETF Trust and the persons 457 identified as the document authors. All rights 458 reserved. 460 Redistribution and use in source and binary forms, 461 with or without modification, is permitted pursuant 462 to, and subject to the license terms contained in, 463 the Simplified BSD License set forth in Section 464 4.c of the IETF Trust's Legal Provisions Relating 465 to IETF Documents 466 (http://trustee.ietf.org/license-info). 467 This version of this MIB module is part of RFC XXXX; 468 see the RFC itself for full legal notices." 470 REVISION "201009010000Z" 471 DESCRIPTION "Initial version, published as RFC XXXX." 472 ::= { mib-2 XXX } 473 -- RFC Ed.: replace XXX with IANA-assigned number & remove this note 474 -- RFC Ed.: replace XXXX with the RFC number & remove this note 476 vacmAaaMIBObjects OBJECT IDENTIFIER ::= { vacmAaaMIB 1 } 478 vacmAaaMIBConformance OBJECT IDENTIFIER ::= { vacmAaaMIB 2 } 480 vacmAaaSecurityToGroupTable OBJECT-TYPE 481 SYNTAX SEQUENCE OF VacmAaaSecurityToGroupEntry 482 MAX-ACCESS not-accessible 483 STATUS current 484 DESCRIPTION "This table provides a listing of all currently active 485 sessions for which a mapping of the combination of 486 SnmpSecurityModel and securityName into the name of 487 a VACM group which has been provided by an AAA service. 488 The group name (in VACM) in turn identifies an access 489 control policy to be used for the corresponding 490 principals." 491 REFERENCE "RFC 3411 section 3.2.2 defines securityName" 492 ::= { vacmAaaMIBObjects 1 } 494 vacmAaaSecurityToGroupEntry OBJECT-TYPE 495 SYNTAX VacmAaaSecurityToGroupEntry 496 MAX-ACCESS not-accessible 497 STATUS current 498 DESCRIPTION "An entry in this table maps the combination of a 499 SnmpSecurityModel and securityName into the name 500 of a VACM group defining the access control policy 501 which is to govern a particular session. 503 Each entry corresponds to a session. 505 Entries do not persist across reboots. 507 An entry is created whenever an indication occurs 508 that a new session has been established that would 509 not have the same index values as an existing entry. 511 When a session is torn down, disconnected, timed out 512 (e.g., following the RADIUS Session-Timeout Attribute), 513 or otherwise terminated for any reason, the 514 corresponding vacmAaaSecurityToGroupEntry is deleted." 516 REFERENCE "RFC 3411 section 3.2.2 defines securityName" 517 INDEX { 518 vacmAaaSecurityModel, 519 vacmAaaSecurityName, 520 vacmAaaSessionID 521 } 522 ::= { vacmAaaSecurityToGroupTable 1 } 524 VacmAaaSecurityToGroupEntry ::= SEQUENCE 525 { 526 vacmAaaSecurityModel SnmpSecurityModel, 527 vacmAaaSecurityName SnmpAdminString, 528 vacmAaaSessionID Unsigned32, 529 vacmAaaGroupName SnmpAdminString 530 } 532 vacmAaaSecurityModel OBJECT-TYPE 533 SYNTAX SnmpSecurityModel(1..2147483647) 534 MAX-ACCESS not-accessible 535 STATUS current 536 DESCRIPTION "The security model associated with the AAA binding 537 represented by this entry. 539 This object cannot take the 'any' (0) value." 540 ::= { vacmAaaSecurityToGroupEntry 1 } 542 vacmAaaSecurityName OBJECT-TYPE 543 SYNTAX SnmpAdminString (SIZE(1..32)) 544 MAX-ACCESS not-accessible 545 STATUS current 546 DESCRIPTION "The securityName of the principal associated with the 547 AAA binding represented by this entry. In RADIUS 548 environments, this corresponds to the User-Name 549 Attribute." 550 REFERENCE "RFC 3411 section 3.2.2 defines securityName, and 551 RFC 2865 section 5.1 defines User-Name." 552 ::= { vacmAaaSecurityToGroupEntry 2 } 554 vacmAaaSessionID OBJECT-TYPE 555 SYNTAX Unsigned32 556 MAX-ACCESS not-accessible 557 STATUS current 558 DESCRIPTION "An implementation-dependent identifier of the session. 560 This value MUST be unique among all currently open 561 sessions of all of this SNMP engine's transport models. 562 The value has no particular significance other than to 563 distinguish sessions. 565 Implementations in which tmSessionID has a compatible 566 syntax and is unique across all transport models MAY 567 use that value." 568 REFERENCE "The abstract service interface parameter tmSessionID 569 is defined in RFC 5590 section 5.2.4." 570 ::= { vacmAaaSecurityToGroupEntry 3 } 572 vacmAaaGroupName OBJECT-TYPE 573 SYNTAX SnmpAdminString (SIZE(1..32)) 574 MAX-ACCESS read-only 575 STATUS current 576 DESCRIPTION "The name of the group to which this entry is to belong. 577 In RADIUS environments this comes from the RADIUS 578 Management-Policy-Id Attribute. 580 When the appropriate conditions are met, 581 the value of this object is applied the vacmGroupName 582 in the corresponding vacmSecurityToGroupEntry." 583 REFERENCE "RFC 3415" 584 ::= { vacmAaaSecurityToGroupEntry 4 } 586 -- Conformance information ****************************************** 588 vacmAaaMIBCompliances 589 OBJECT IDENTIFIER ::= {vacmAaaMIBConformance 1} 590 vacmAaaMIBGroups 591 OBJECT IDENTIFIER ::= {vacmAaaMIBConformance 2} 593 -- compliance statements 595 vacmAaaMIBBasicCompliance MODULE-COMPLIANCE 596 STATUS current 597 DESCRIPTION "The compliance statement for SNMP engines implementing 598 the AAA-Enabled View-based Access Control Model for 599 SNMP." 600 MODULE -- this module 601 MANDATORY-GROUPS { vacmAaaGroup } 603 ::= { vacmAaaMIBCompliances 1 } 605 -- units of conformance 607 vacmAaaGroup OBJECT-GROUP 608 OBJECTS { 609 vacmAaaGroupName 610 } 611 STATUS current 612 DESCRIPTION "A collection of objects for supporting the use of AAA 613 services to provide user / group mappings for VACM." 614 ::= { vacmAaaMIBGroups 1 } 616 END 618 9. Security Considerations 620 The algorithms in this memo make heuristic use of the StorageType of 621 entries in the vacmSecurityToGroupTable to distinguish those 622 provisioned by a security administrator (which would presumably not 623 be configured as "volatile") from those dynamically generated. In 624 making this distinction, it assumes that those entries explicitly 625 provisioned by a security administrator and given a non-"volatile" 626 status are not to be dynamically overridden. Furthermore, it assumes 627 that any active entries with "volatile" status can be treated as 628 dynamic, and deleted or updated as needed. Users of this memo need 629 to be aware of this operational assumption, which, while reasonable, 630 is not necessarily universally valid. For example, this situation 631 could also occur if the SNMP security administrator had mistakenly 632 created these non-volatile entries in error. 634 The design of VACM ensures that if an unknown policy (group name) is 635 used in the vacmSecurityToGroupTable, no access is granted. A 636 consequence of this is that no matter what information is provided by 637 the AAA server, no user can gain SNMP access rights not already 638 granted to some group through the VACM configuration. 640 9.1. Principal Identity Naming 642 In order to ensure that the access control policy ultimately applied 643 as a result of the mechanisms described here is indeed the intended 644 policy for a given principal using a particular security model, care 645 needs to be applied in the mapping of the authenticated user 646 (principal) identity to the securityName used to make the access 647 control decision. Broadly speaking, there are two approaches to 648 ensure consistency of identity: 650 o Entries for the vacmSecurityToGroupTable corresponding to a given 651 security model are created only through the operation of the 652 procedures described in this memo. A consequence of this would be 653 that all such entries would have been created using the RADIUS 654 User-Name (or other AAA-authenticated identity) and RADIUS 655 Management-Policy-Id Attribute (or equivalent). 657 o Administrative policy allows a matching pre-configured entry to 658 exist in the vacmSecurityToGroupTable, i.e., an entry with the 659 corresponding vacmSecurityModel and with a vacmSecurityName 660 matching the authenticated principal's RADIUS User-Name. In this 661 case, administrative policy also needs to ensure consistency of 662 identity between each authenticated principal's RADIUS User-Name 663 and the administratively configured vacmSecurityName in the 664 vacmSecurityToGroupTable row entries for that particular security 665 model. 667 In the later case, inconsistent re-use of the same name for different 668 entities or individuals (principals) can cause the incorrect access 669 control policy to be applied for the authenticated principal, 670 depending on whether the policy configured using SNMP, or the policy 671 applied using the procedures of this memo, is the intended policy. 672 This may result in greater or lesser access rights than the 673 administrative policy intended. Inadvertent mis-identification in 674 such cases may be undetectable by the SNMP engine or other software 675 elements of the managed entity. 677 9.2. Management Information Considerations 679 There are no management objects defined in this MIB module that have 680 a MAX-ACCESS clause of read-write and/or read-create. So, if this 681 MIB module is implemented correctly, then there is no risk that an 682 intruder can alter or create any management objects of this MIB 683 module via direct SNMP SET operations. 685 Some of the readable objects in this MIB module (including some 686 objects with a MAX-ACCESS of not-accessible, whose values are exposed 687 as a result access to indexed objects) may be considered sensitive or 688 vulnerable in some network environments. It is thus important to 689 control even GET and/or NOTIFY access to these objects and possibly 690 to even encrypt the values of these objects when sending them over 691 the network via SNMP. These are the tables and objects and their 692 sensitivity/vulnerability: 694 o vacmAaaSecurityToGroupTable - the entire table is potentially 695 sensitive, since walking the table will reveal user names, 696 security models in use, session identifiers, and group names; 698 o vacmAaaSecurityModel - though not-accessible, this is exposed as 699 an index of vacmAaaGroupName; 701 o vacmAaaSecurityName - though not-accessible, this is exposed as an 702 index of vacmAaaGroupName; 704 o vacmAaaSessionID - though not-accessible, this is exposed as an 705 index of vacmAaaGroupName; 707 o vacmAaaGroupName - since this identifies a security policy and 708 associates it with a particular user, this is potentially 709 sensitive. 711 SNMP versions prior to SNMPv3 did not include adequate security. 712 Even if the network itself is secure (for example by using IPsec), 713 even then, there is no control as to who on the secure network is 714 allowed to access and GET/SET (read/change/create/delete) the objects 715 in this MIB module. 717 It is RECOMMENDED that implementers consider the security features as 718 provided by the SNMPv3 framework (see [RFC3410], section 8), 719 including full support for the SNMPv3 cryptographic mechanisms (for 720 authentication and privacy). 722 Further, deployment of SNMP versions prior to SNMPv3 is NOT 723 RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to 724 enable cryptographic security. It is then a customer/operator 725 responsibility to ensure that the SNMP entity giving access to an 726 instance of this MIB module is properly configured to give access to 727 the objects only to those principals (users) that have legitimate 728 rights to indeed GET or SET (change/create/delete) them. 730 10. IANA Considerations 732 The MIB module in this document uses the following IANA-assigned 733 OBJECT IDENTIFIER value recorded in the SMI Numbers registry: 735 Descriptor OBJECT IDENTIFIER value 736 ---------- ----------------------- 737 vacmAaaMIB { mib-2 XXX } 739 Editor's Note (to be removed prior to publication): the IANA is 740 requested to assign a value for "XXX" under the 'mib-2' subtree and 741 to record the assignment in the SMI Numbers registry. When the 742 assignment has been made, the RFC Editor is asked to replace "XXX" 743 (here and in the MIB module) with the assigned value and to remove 744 this note. 746 11. Contributors 748 The following participants from the isms working group contributed to 749 the development of this document: 751 o Andrew Donati 753 o David Harrington 755 o Jeffrey Hutzelman 757 o Juergen Schoenwaelder 759 o Tom Petch 761 o Wes Hardaker 763 During the IESG review additional comments were received from: 765 o Adrian Farrel 767 o Amanda Baber 769 o Dan Romescanu 771 o David Kessens 773 o Francis Dupont 775 o Glenn Keeni 777 o Jari Arkko 779 o Joel Jaeggli 781 o Magnus Nystroem 783 o Mike Heard 785 o Robert Story 787 o Russ Housley 789 o Sean Turner 791 o Tim Polk 793 12. References 795 12.1. Normative References 797 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 798 Requirement Levels", BCP 14, RFC 2119, March 1997. 800 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 801 Schoenwaelder, Ed., "Structure of Management Information 802 Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 804 [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. 805 Schoenwaelder, Ed., "Textual Conventions for SMIv2", 806 STD 58, RFC 2579, April 1999. 808 [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, 809 "Conformance Statements for SMIv2", STD 58, RFC 2580, 810 April 1999. 812 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 813 "Remote Authentication Dial In User Service (RADIUS)", 814 RFC 2865, June 2000. 816 [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An 817 Architecture for Describing Simple Network Management 818 Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, 819 December 2002. 821 [RFC3415] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based 822 Access Control Model (VACM) for the Simple Network 823 Management Protocol (SNMP)", STD 62, RFC 3415, 824 December 2002. 826 [RFC5590] Harrington, D. and J. Schoenwaelder, "Transport Subsystem 827 for the Simple Network Management Protocol (SNMP)", 828 RFC 5590, June 2009. 830 [RFC5607] Nelson, D. and G. Weber, "Remote Authentication Dial-In 831 User Service (RADIUS) Authorization for Network Access 832 Server (NAS) Management", RFC 5607, July 2009. 834 [RFC5608] Narayan, K. and D. Nelson, "Remote Authentication Dial-In 835 User Service (RADIUS) Usage for Simple Network Management 836 Protocol (SNMP) Transport Models", RFC 5608, August 2009. 838 12.2. Informative References 840 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, 841 "Introduction and Applicability Statements for Internet- 842 Standard Management Framework", RFC 3410, December 2002. 844 [RFC5592] Harrington, D., Salowey, J., and W. Hardaker, "Secure 845 Shell Transport Model for the Simple Network Management 846 Protocol (SNMP)", RFC 5592, June 2009. 848 Authors' Addresses 850 Kaushik Narayan 851 Cisco Systems, Inc. 852 10 West Tasman Drive 853 San Jose, CA 95134 854 USA 856 Phone: +1 408-526-8168 857 Email: kaushik_narayan@yahoo.com 859 David Nelson 860 Elbrys Networks, Inc. 861 282 Corporate Drive, Unit #1, 862 Portsmouth, NH 03801 863 USA 865 Phone: +1 603-570-2636 866 Email: d.b.nelson@comcast.net 868 Randy Presuhn (editor) 869 None 870 San Jose, CA 95120 871 USA 873 Email: randy_presuhn@mindspring.com