idnits 2.17.1 draft-ietf-isms-radius-vacm-07.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 == Line 453 has weird spacing: '...sed for the c...' == 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 (July 6, 2010) is 5041 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 (~~), 3 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: January 7, 2011 Elbrys Networks, Inc. 6 R. Presuhn, Ed. 7 None 8 July 6, 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-07.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 Comments are solicited and should be addressed to the working group's 25 mailing list at isms@ietf.org. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on January 7, 2011. 44 Copyright Notice 46 Copyright (c) 2010 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. The Internet-Standard Management Framework . . . . . . . . . . 3 63 3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 4.1. Using AAA services with SNMP . . . . . . . . . . . . . . . 3 66 4.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 4 67 5. Structure of the MIB Module . . . . . . . . . . . . . . . . . 5 68 5.1. Textual Conventions . . . . . . . . . . . . . . . . . . . 5 69 5.2. The Table Structure . . . . . . . . . . . . . . . . . . . 5 70 6. Relationship to Other MIB Modules . . . . . . . . . . . . . . 6 71 6.1. Relationship to the VACM MIB . . . . . . . . . . . . . . . 6 72 6.2. MIB modules required for IMPORTS . . . . . . . . . . . . . 6 73 7. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 6 74 7.1. Sequencing Requirements . . . . . . . . . . . . . . . . . 6 75 7.2. Actions Upon Session Establishment Indication . . . . . . 7 76 7.2.1. Creation of Entries in vacmAaaSecurityToGroupTable . . 7 77 7.2.2. Creation of Entries in vacmSecurityToGroupTable . . . 8 78 7.2.3. Update of vacmGroupName . . . . . . . . . . . . . . . 8 79 7.3. Actions Upon Session Termination Indication . . . . . . . 8 80 7.3.1. Deletion of Entries from 81 vacmAaaSecurityToGroupTable . . . . . . . . . . . . . 9 82 7.3.2. Deletion of Entries from vacmSecurityToGroupTable . . 9 83 8. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 9 84 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 85 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 86 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 16 87 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 88 12.1. Normative References . . . . . . . . . . . . . . . . . . . 16 89 12.2. Informative References . . . . . . . . . . . . . . . . . . 17 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 92 1. Introduction 94 This memo specifies a way to simplify the administration of the 95 access rights granted to users of network management data. It 96 functions to dynamically provision selected View-Based Access Control 97 Model (VACM) [RFC3415] MIB objects, based on information received 98 from an Authentication, Authorization, and Accounting (AAA) service, 99 such as RADIUS [RFC2865]. 101 This memo requires no changes to the Abstract Service Interface for 102 the Access Control Subsystem, and requires no changes to the Elements 103 of Procedure for VACM. It provides a MIB module that reflects the 104 information provided by the AAA service, along with elements of 105 procedure for maintaining that information and performing 106 corresponding updates to VACM MIB data. 108 2. The Internet-Standard Management Framework 110 For a detailed overview of the documents that describe the current 111 Internet-Standard Management Framework, please refer to section 7 of 112 RFC 3410 [RFC3410]. 114 Managed objects are accessed via a virtual information store, termed 115 the Management Information Base or MIB. MIB objects are generally 116 accessed through the Simple Network Management Protocol (SNMP). 117 Objects in the MIB are defined using the mechanisms defined in the 118 Structure of Management Information (SMI). This memo specifies a MIB 119 module that is compliant to the SMIv2, which is described in STD 58, 120 RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 121 [RFC2580]. 123 3. Conventions 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 127 document are to be interpreted as described in RFC 2119 [RFC2119]. 129 4. Overview 131 4.1. Using AAA services with SNMP 133 There are two use cases for AAA support of management access via 134 SNMP. These are (a) service authorization and (b) access control 135 authorization. The former is discussed in detail in [RFC5608]. The 136 latter is the subject of this memo. 138 The use case assumption here is that roles within an organization, 139 which are reflected in VACM as groups and rules, change infrequently, 140 while the users assigned to those roles change much more frequently. 141 This memo describes how the user-to-role (group) mapping can be 142 delegated to the RADIUS server, avoiding the need to re-provision 143 managed devices as users are added, deleted, or assigned new roles in 144 an organization. 146 This memo assumes that the detailed access control policies are pre- 147 configured in VACM, and does not attempt to address the question of 148 how the policy associated with a given role is put in place. 150 The only additional information obtained from the AAA service is the 151 mapping of the authenticated user's identifier to a specific role (or 152 "group" in VACM terminology) in the access control policy. Dynamic 153 user authorization for MIB database access control, as defined 154 herein, is limited to mapping the authenticated user to a group, 155 which in turn is mapped to whatever rules are already in place in 156 VACM. 158 The SNMP architecture [RFC3411] maintains strong modularity and 159 separation of concerns, separating user identity (authentication) 160 from user database access rights (authorization). RADIUS, on the 161 other hand, allows for no such separation of authorization from 162 authentication. Consequently, the approach here is to leverage 163 existing RADIUS usage for identifying a principal, documented in 164 [RFC5608], along with the RADIUS Management-Policy-Id Attribute 165 [RFC5607]. 167 The tmSessionID (along with its transport model prefix) [RFC5590] is 168 a suitable identifier for a AAA-authorized "session". This is 169 because tmSessionID and tmSecurityName, assigned by a AAA-aware 170 transport model, identify a specific transport session authorized to 171 offer SNMP service, for which a principal has been AAA-authenticated. 172 When a RADIUS-Management-Policy-ID Attribute (or equivalent) is bound 173 to such a transport session and principal authentication, this 174 binding provides sufficient information to compute dynamic updates to 175 VACM. How this information is communicated within an implementation 176 is implementation-dependent; this memo is only concerned with 177 externally-observable behaviour. 179 4.2. Applicability 181 Though this memo was motivated to support the use of specific 182 Transport Models, such as the Secure Shell Transport Model [RFC5592], 183 it MAY be used with other implementation environments satisfying 184 these requirements: 186 o use an AAA service for sign-on service and data access 187 authorization; 189 o provide an indication of the start of a session for a particular 190 authenticated principal, identified using a SecurityName, and 191 provide the corresponding value of vacmGroupName to be used, based 192 on information provided by the AAA service in use; 194 o provide an indication of the end of the need for being able to 195 make access decisions for a particular authenticated principal, as 196 at the end of a session, whether due to disconnection, termination 197 due to timeout, or any other reason. 199 Likewise, although this memo specifically refers to RADIUS, it MAY be 200 used with other AAA services satisfying these requirements: 202 o the service provides information semantically equivalent to the 203 RADIUS Management-Policy-Id Attribute [RFC5607], which corresponds 204 to a GroupName; 206 o the service provides an authenticated principal identifier (e.g., 207 the RADIUS User-Name Attribute [RFC2865]) which can be transformed 208 to an equivalent principal identifier in the form of a 209 SecurityName. 211 5. Structure of the MIB Module 213 5.1. Textual Conventions 215 This MIB module makes use of the SnmpAdminString and 216 SnmpSecurityModel textual conventions. 218 5.2. The Table Structure 220 This MIB module defines a single table, the 221 vacmAaaSecurityToGroupTable. This table is indexed by the integer 222 assigned to each security model, the protocol-independent 223 SecurityName corresponding to a principal, and the unique identifier 224 of a session. This index structure was chosen to support use cases 225 in which a given user could potentially have multiple concurrent 226 sessions, and to support environments in which multiple security 227 models might find concurrent usage. 229 6. Relationship to Other MIB Modules 231 This MIB module has a close operational relationship with the SNMP- 232 VIEW-BASED-ACM-MIB (more commonly known as the "VACM MIB") from 233 [RFC3415]. It also relies on IMPORTS from several other modules. 235 6.1. Relationship to the VACM MIB 237 Although the MIB module defined here has a close relationship with 238 the VACM MIB's vacmSecurityToGroupTable, it in no way changes the 239 elements of procedure for VACM, nor does it affect any other tables 240 defined in VACM. See the elements of procedure (below) for details 241 of how the contents of the vacmSecurityToGroupTable are affected by 242 this MIB module. 244 6.2. MIB modules required for IMPORTS 246 This MIB module employs definitions from [RFC2578], [RFC2579] and 247 [RFC3411]. The module also relies on the IANA registry defined in 248 [RFC5590] for transport domain prefixes. 250 7. Elements of Procedure 252 The following elements of procedure are formulated in terms of two 253 types of events: an indication of the establishment of a session, and 254 an indication that one has ended. These can result in the creation 255 of entries in the vacmAaaSecurityToGroupTable, which can in turn 256 trigger creation, update, or deletion of entries in the 257 vacmSecurityToGroupTable. 259 There are various possible implementation-specific error cases not 260 spelled out here, such as running out of memory. By their nature, 261 recovery in such cases will be implementation-specific. Implementors 262 are advised to consider fail-safe strategies, e.g., prematurely 263 terminating access in preference to erroneously perpetuating access. 265 7.1. Sequencing Requirements 267 These procedures assume that a transport model, such as [RFC5592], 268 coordinates session establishment with AAA authentication and 269 authorization. They rely critically on the receipt by the AAA client 270 of the RADIUS Management-Policy-Id [RFC5607] Attribute (or its 271 equivalent) from the RADIUS Access-Accept message (or equivalent). 272 They also assume that the User-Name [RFC2865] from the RADIUS Access- 273 Request message (or equivalent) corresponds to an SNMP Security Name 274 [RFC3411]. 276 To ensure correct processing of SNMP PDUs, the handling of the 277 indication of the establishment of a session in accordance with the 278 elements of procedure below MUST be completed before the 279 IsAccessAllowed() abstract service interface is invoked for any SNMP 280 PDUs from that session. 282 If a session termination indication occurs before all invocations of 283 the IsAccessAllowed() abstract service interface have completed for 284 all SNMP PDUs from that session, those remaining invocations MAY 285 result in denial of access. 287 7.2. Actions Upon Session Establishment Indication 289 Four pieces of information are needed to process the session 290 establishment indication: 292 o the SnmpSecurityModel [RFC3411] needed as an index into the 293 vacmSecurityToGroupTable; 295 o the RADIUS User-Name Attribute or equivalent; 297 o a session identifier, such as tmSessionID [RFC5590] along with the 298 prefix for its transport domain, as a definitive identifier of the 299 transport session that the AAA authorization is tied to; 301 o the RADIUS Management-Policy-Id Attribute or equivalent 303 In particular, if either the User-Name or Management-Policy-Id is 304 absent, invalid, or a zero-length string, no further processing of 305 the session establishment indication is undertaken. 307 7.2.1. Creation of Entries in vacmAaaSecurityToGroupTable 309 Whenever an indication arrives that a new session has been 310 established, determine whether a corresponding entry exists in the 311 vacmAaaSecurityToGroupTable. If one does not, create a new row with 312 the columns populated as follows: 314 o vacmAaaSecurityModel = value of SnmpSecurityModel corresponding to 315 the security model in use 317 o vacmAaaSecurityName = RADIUS User-Name Attribute or equivalent, 318 the securityName that will be used in invocations of the 319 isAccessAllowed() abstract service interface; 321 o vacmAaaTransportModel = the one- to four-character registered 322 prefix of the transport domain [RFC5590] 324 o vacmAaaTransportSessionID = unique (at least within the the scope 325 of a transport model) session identifier 327 o vacmAaaGroupName = RADIUS Management-Policy-Id Attribute or 328 equivalent 330 Otherwise, if the row already exists, update the vacmAaaGroupName 331 with the value supplied. 333 7.2.2. Creation of Entries in vacmSecurityToGroupTable 335 Whenever an entry is created in the vacmAaaSecurityToGroupTable, the 336 vacmSecurityToGroupTable is examined to determine whether a 337 corresponding entry exists there, using the value of 338 vacmAaaSecurityModel for vacmSecurityModel, and the value of 339 vacmAaaSecurityName for vacmSecurityName. If no corresponding entry 340 exists, create one, using the vacmAaaGroupName of the newly created 341 entry to fill in vacmGroupName, using a value of "volatile" for 342 vacmSecurityToGroupStorageType, and a value of "active" for 343 vacmSecurityToGroupStatus. 345 If a corresponding entry already exists in the 346 vacmSecurityToGroupTable, and the row's StorageType is anything other 347 than "volatile", or the RowStatus is anything other than "active", 348 then a role (group) mapping for this user (principal) has already 349 been put in place on this system, and will not be overridden. 351 7.2.3. Update of vacmGroupName 353 Whenever the value of an instance of vacmAaaGroupName is updated, if 354 a corresponding entry exists in the vacmSecurityToGroupTable, and 355 vacmSecurityToGroupStorageType is "volatile" and 356 vacmSecurityToGroupStatus is "active", update the value of 357 vacmGroupName with the value from vacmAaaGroupName. 359 The operational assumption here is that if the row's StorageType is 360 "volatile", then this entry was probably dynamically created; an 361 entry created by a security administrator would not normally be given 362 a StorageType of "volatile". If value being provided by RADIUS (or 363 other AAA service) is the same as what is already there, this is a 364 no-op. If the value is different, the new information is understood 365 as a more recent role (group) assignment for the user, which should 366 supercede the one currently held there. 368 7.3. Actions Upon Session Termination Indication 370 Whenever a RADIUS (or other AAA) authenticated session ends for any 371 reason, an indication is provided. This indication MUST provide 372 means of determining the SnmpSecurityModel, transport domain prefix, 373 and an identifier for the transport session tied to the AAA 374 authorization. The manner in which this occurs is implementation 375 dependent. 377 7.3.1. Deletion of Entries from vacmAaaSecurityToGroupTable 379 Entries in the vacmAaaSecurityToGroupTable MUST NOT persist across 380 system reboots. 382 When a session has been terminated, the vacmAaaSecurityToGroupTable 383 is searched for a corresponding entry. A "matching" entry is any 384 entry for which the SnmpSecurityModel, transport domain prefix, and 385 session ID match the information associated with the session 386 termination indication. Any matching entries are deleted. It is 387 possible that no entries will match; this is not an error, and no 388 special processing is required in this case. 390 7.3.2. Deletion of Entries from vacmSecurityToGroupTable 392 Whenever the last remaining row bearing a particular 393 (vacmAaaSecurityModel, vacmAaaSecurityName) pair is deleted from the 394 vacmAaaSecurityToGroupTable, the vacmSecurityToGroupTable is examined 395 for a corresponding row. If one exists, and if its StorageType is 396 "volatile" and its RowStatus is "active", that row MUST be deleted as 397 well. The mechanism to accomplish this task is implementation 398 specific. 400 8. Definitions 402 SNMP-VACM-AAA-MIB DEFINITIONS ::= BEGIN 404 IMPORTS 405 MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF 406 MODULE-IDENTITY, OBJECT-TYPE, 407 mib-2, 408 Unsigned32 FROM SNMPv2-SMI 409 SnmpAdminString, 410 SnmpSecurityModel FROM SNMP-FRAMEWORK-MIB; 412 snmpVacmAaaMIB MODULE-IDENTITY 413 LAST-UPDATED "201007040000Z" -- 4 July, 2010 414 ORGANIZATION "ISMS Working Group" 415 CONTACT-INFO "WG-email: isms@ietf.org" 416 DESCRIPTION "The management and local datastore information 417 definitions for the AAA-Enabled View-based Access 418 Control Model for SNMP. 420 Copyright (c) 2010 IETF Trust and the persons 421 identified as the document authors. All rights 422 reserved. 424 Redistribution and use in source and binary forms, 425 with or without modification, is permitted pursuant 426 to, and subject to the license terms contained in, 427 the Simplified BSD License set forth in Section 428 4.c of the IETF Trust's Legal Provisions Relating 429 to IETF Documents 430 (http://trustee.ietf.org/license-info). 432 This version of this MIB module is part of RFC XXXX; 433 see the RFC itself for full legal notices." 435 REVISION "201007040000Z" 436 DESCRIPTION "Initial version, published as RFC XXXX." 437 ::= { mib-2 XXX } 439 vacmAaaMIBObjects OBJECT IDENTIFIER ::= { snmpVacmAaaMIB 1 } 441 vacmAAAMIBConformance OBJECT IDENTIFIER ::= {snmpVacmAaaMIB 2 } 443 vacmAaaSecurityToGroupTable OBJECT-TYPE 444 SYNTAX SEQUENCE OF VacmAaaSecurityToGroupEntry 445 MAX-ACCESS not-accessible 446 STATUS current 447 DESCRIPTION "This table provides a listing of all currently 448 active sessions for which a mapping 449 of the combination of SnmpSecurityModel and 450 SecurityName into a GroupName has been provided 451 by an AAA service. The GroupName (in VACM) 452 in turn identifies an access control policy 453 to be used for the corresponding principals." 454 ::= { vacmAaaMIBObjects 1 } 456 vacmAaaSecurityToGroupEntry OBJECT-TYPE 457 SYNTAX VacmAaaSecurityToGroupEntry 458 MAX-ACCESS not-accessible 459 STATUS current 460 DESCRIPTION "An entry in this table maps the combination of a 461 SnmpSecurityModel and SecurityName into a GroupName 462 for a particular session. 464 Each entry corresponds to a session. 466 Entries do not persist across reboots. 468 When a session is torn down, disconnected, 469 timed out (e.g. following the RADIUS 470 Session-Timeout Attribute), or otherwise 471 terminated for any reason, the corresponding 472 vacmAaaSecurityToGroupEntry is deleted." 473 INDEX { 474 vacmAaaSecurityModel, 475 vacmAaaSecurityName, 476 vacmAaaTransportModel, 477 vacmAaaTransportSessionID 478 } 479 ::= { vacmAaaSecurityToGroupTable 1 } 481 VacmAaaSecurityToGroupEntry ::= SEQUENCE 482 { 483 vacmAaaSecurityModel SnmpSecurityModel, 484 vacmAaaSecurityName SnmpAdminString, 485 vacmAaaTransportModel SnmpAdminString, 486 vacmAaaTransportSessionID Unsigned32, 487 vacmAaaGroupName SnmpAdminString 488 } 490 vacmAaaSecurityModel OBJECT-TYPE 491 SYNTAX SnmpSecurityModel(1..2147483647) 492 MAX-ACCESS not-accessible 493 STATUS current 494 DESCRIPTION "The Security Model associated with the AAA binding 495 represented by this entry. 496 This object cannot take the 'any' (0) value." 497 ::= { vacmAaaSecurityToGroupEntry 1 } 499 vacmAaaSecurityName OBJECT-TYPE 500 SYNTAX SnmpAdminString (SIZE(1..32)) 501 MAX-ACCESS not-accessible 502 STATUS current 503 DESCRIPTION "The Security Name of the principal associated with 504 the AAA binding represented by this entry. 505 In RADIUS environments, this corresponds to 506 the User-Name Attribute." 507 ::= { vacmAaaSecurityToGroupEntry 2 } 509 vacmAaaTransportModel OBJECT-TYPE 510 SYNTAX SnmpAdminString (SIZE(1..4)) 511 MAX-ACCESS not-accessible 512 STATUS current 513 DESCRIPTION "The prefix of this session's transport domain." 514 ::= { vacmAaaSecurityToGroupEntry 3 } 516 vacmAaaTransportSessionID OBJECT-TYPE 517 SYNTAX Unsigned32 518 MAX-ACCESS not-accessible 519 STATUS current 520 DESCRIPTION "A specific identifier of the session. 521 This value MUST be unique among all 522 currently open sessions within a transport model. 523 The value has no particular significance other 524 to distinguish sessions. An example of a suitable 525 value would be tmSessionID." 526 ::= { vacmAaaSecurityToGroupEntry 4 } 528 vacmAaaGroupName OBJECT-TYPE 529 SYNTAX SnmpAdminString (SIZE(1..32)) 530 MAX-ACCESS read-only 531 STATUS current 532 DESCRIPTION "The name of the group to which this entry 533 is to belong. In RADIUS environments this 534 comes from the RADIUS Management-Policy-Id 535 Attribute. 537 This group name is used to set the vacmGroupName 538 in the corresponding vacmSecurityToGroupEntry." 539 ::= { vacmAaaSecurityToGroupEntry 5 } 541 -- Conformance information ****************************************** 543 vacmAaaMIBCompliances 544 OBJECT IDENTIFIER ::= {vacmAAAMIBConformance 1} 545 vacmAaaMIBGroups 546 OBJECT IDENTIFIER ::= {vacmAAAMIBConformance 2} 548 -- compliance statements 550 vacmAaaMIBBasicCompliance MODULE-COMPLIANCE 551 STATUS current 552 DESCRIPTION "The compliance statement for SNMP engines which 553 implement the Extensions to the View-based Access 554 Control Model for use with RADIUS." 555 MODULE -- this module 556 MANDATORY-GROUPS { vacmAaaGroup } 558 ::= { vacmAaaMIBCompliances 1 } 560 -- units of conformance 562 vacmAaaGroup OBJECT-GROUP 563 OBJECTS { 564 vacmAaaGroupName 565 } 566 STATUS current 567 DESCRIPTION "A collection of objects for supporting the use 568 of AAA services to provide user / group 569 mappings for VACM." 570 ::= { vacmAaaMIBGroups 1 } 572 END 574 9. Security Considerations 576 The algorithms in this memo make heuristic use of the StorageType of 577 entries in the vacmSecurityToGroupTable to distinguish those 578 provisioned by a security administrator (which would presumably not 579 be configured as "volatile") from those dynamically generated. In 580 making this distinction, it assumes that those entries explicitly 581 provisioned by a security administrator and given a non-"volatile" 582 status are not to be dynamically over-ridden. Users of this memo 583 need to be aware of this operational assumption, which, while 584 reasonable, is not necessarily universally valid. For example, this 585 situation could also occur if the SNMP security administrator had 586 mistakenly created these non-volatile entries in error. 588 The design of VACM ensures that if an unknown policy (group name) is 589 used in the vacmSecurityToGroupTable, no access is granted. A 590 consequence of this is that no matter what information is provided by 591 the AAA server, no user can gain SNMP access rights not already 592 granted to some group through the VACM configuration. 594 In order to ensure that the access control policy ultimately applied 595 as a result of the mechanisms described here is indeed the intended 596 policy for a given principal using a particular security model, care 597 needs to be applied in the mapping of the authenticated user 598 (principal) identity to the securityName used to make the access 599 control decision. Broadly speaking, there are two approaches to 600 ensure consistency of identity: 602 o Entries for the vacmSecurityToGroupTable corresponding to a given 603 security model are created only through the operation of the 604 procedures described in this memo. A consequence of this would be 605 that all such entries would have been created using the RADIUS 606 User-Name (or other AAA-authenticated identity) and RADIUS 607 Management-Policy-Id Attribute (or equivalent). 609 o Administrative policy allows a matching pre-configured entry to 610 exist in the vacmSecurityToGroupTable, i.e., an entry with the 611 corresponding vacmSecurityModel and with a vacmSecurityName 612 matching the authenticated principal's RADIUS User-Name). In this 613 case, administrative policy also needs to ensure consistency of 614 identity between each authenticated principal's RADIUS User-Name 615 and the administratively configured vacmSecurityName in the 616 vacmSecurityToGroupTable row entries for that particular security 617 model. 619 In the later case, inconsistent re-use of the same name for different 620 entities or individuals (principals) can cause the incorrect access 621 control policy to be applied for the authenticated principal, 622 depending on whether the policy configured using SNMP, or the policy 623 applied using the procedures of this memo, is the intended policy. 624 This may result in greater or lesser access rights than the 625 administrative policy intended. Inadvertent mis-identification in 626 such cases may be undetectable by the SNMP engine or other software 627 elements of the managed entity. 629 There are no management objects defined in this MIB module that have 630 a MAX-ACCESS clause of read-write and/or read-create. So, if this 631 MIB module is implemented correctly, then there is no risk that an 632 intruder can alter or create any management objects of this MIB 633 module via direct SNMP SET operations. 635 Some of the readable objects in this MIB module (including some 636 objects with a MAX-ACCESS of not-accessible, whose values are exposed 637 as a result access to indexed objects) may be considered sensitive or 638 vulnerable in some network environments. It is thus important to 639 control even GET and/or NOTIFY access to these objects and possibly 640 to even encrypt the values of these objects when sending them over 641 the network via SNMP. These are the tables and objects and their 642 sensitivity/vulnerability: 644 o vacmAaaSecurityToGroupTable - the entire table is potentially 645 sensitive, since walking the table will reveal user names, 646 security models in use, session identifiers, and group names. 648 o vacmAaaSecurityModel - though not-accessible, this is exposed as 649 an index of vacmAaaGroupName 651 o vacmAaaSecurityName - though not-accessible, this is exposed as an 652 index of vacmAaaGroupName 654 o vacmAaaTransportSessionID - though not-accessible, this is exposed 655 as an index of vacmAaaGroupName 657 o vacmAaaGroupName - since this identifies a security policy and 658 associates it with a particular user, this is potentially 659 sensitive. 661 SNMP versions prior to SNMPv3 did not include adequate security. 662 Even if the network itself is secure (for example by using IPsec), 663 even then, there is no control as to who on the secure network is 664 allowed to access and GET/SET (read/change/create/delete) the objects 665 in this MIB module. 667 It is RECOMMENDED that implementers consider the security features as 668 provided by the SNMPv3 framework (see [RFC3410], section 8), 669 including full support for the SNMPv3 cryptographic mechanisms (for 670 authentication and privacy). 672 Further, deployment of SNMP versions prior to SNMPv3 is NOT 673 RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to 674 enable cryptographic security. It is then a customer/operator 675 responsibility to ensure that the SNMP entity giving access to an 676 instance of this MIB module is properly configured to give access to 677 the objects only to those principals (users) that have legitimate 678 rights to indeed GET or SET (change/create/delete) them. 680 10. IANA Considerations 682 The MIB module in this document uses the following IANA-assigned 683 OBJECT IDENTIFIER value recorded in the SMI Numbers registry: 685 Descriptor OBJECT IDENTIFIER value 686 ---------- ----------------------- 687 snmpVacmAaaMIB { mib-2 XXX } 689 Editor's Note (to be removed prior to publication): the IANA is 690 requested to assign a value for "XXX" under the 'mib-2' subtree and 691 to record the assignment in the SMI Numbers registry. When the 692 assignment has been made, the RFC Editor is asked to replace "XXX" 693 (here and in the MIB module) with the assigned value and to remove 694 this note. 696 11. Contributors 698 The following participants from the isms working group contributed to 699 the development of this document: 701 o Andrew Donati 703 o David Harrington 705 o Jeffrey Hutzelman 707 o Juergen Schoenwaelder 709 o Tom Petch 711 o Wes Hardaker 713 12. References 715 12.1. Normative References 717 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 718 Requirement Levels", BCP 14, RFC 2119, March 1997. 720 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 721 Schoenwaelder, Ed., "Structure of Management Information 722 Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 724 [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. 725 Schoenwaelder, Ed., "Textual Conventions for SMIv2", 726 STD 58, RFC 2579, April 1999. 728 [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, 729 "Conformance Statements for SMIv2", STD 58, RFC 2580, 730 April 1999. 732 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 733 "Remote Authentication Dial In User Service (RADIUS)", 734 RFC 2865, June 2000. 736 [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An 737 Architecture for Describing Simple Network Management 738 Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, 739 December 2002. 741 [RFC3415] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based 742 Access Control Model (VACM) for the Simple Network 743 Management Protocol (SNMP)", STD 62, RFC 3415, 744 December 2002. 746 [RFC5590] Harrington, D. and J. Schoenwaelder, "Transport Subsystem 747 for the Simple Network Management Protocol (SNMP)", 748 RFC 5590, June 2009. 750 [RFC5607] Nelson, D. and G. Weber, "Remote Authentication Dial-In 751 User Service (RADIUS) Authorization for Network Access 752 Server (NAS) Management", RFC 5607, July 2009. 754 [RFC5608] Narayan, K. and D. Nelson, "Remote Authentication Dial-In 755 User Service (RADIUS) Usage for Simple Network Management 756 Protocol (SNMP) Transport Models", RFC 5608, August 2009. 758 12.2. Informative References 760 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, 761 "Introduction and Applicability Statements for Internet- 762 Standard Management Framework", RFC 3410, December 2002. 764 [RFC5592] Harrington, D., Salowey, J., and W. Hardaker, "Secure 765 Shell Transport Model for the Simple Network Management 766 Protocol (SNMP)", RFC 5592, June 2009. 768 Authors' Addresses 770 Kaushik Narayan 771 Cisco Systems, Inc. 772 10 West Tasman Drive 773 San Jose, CA 95134 774 USA 776 Phone: +1 408-526-8168 777 Email: kaushik_narayan@yahoo.com 779 David Nelson 780 Elbrys Networks, Inc. 781 282 Corporate Drive, Unit #1, 782 Portsmouth, NH 03801 783 USA 785 Phone: +1 603-570-2636 786 Email: d.b.nelson@comcast.net 787 Randy Presuhn (editor) 788 None 789 San Jose, CA 95120 790 USA 792 Email: randy_presuhn@mindspring.com