RFC 6065
Using Authentication, Authorization, and Accounting Services to Dynamically Provision View-Based Access Control Model User-to-Group Mappings
RFC 6065 🎀 Using AAA to Dynamically Provision VACM User-to-Group Mappings
Okay bestie, this is RFC 6065, and it's a Standards Track document, so it's the real deal 👑 It was published in December 2010 by the IETF (Internet Engineering Task Force) and carries ISSN 2070-1721. The authors are K. Narayan from Cisco Systems, Inc., D. Nelson from Elbrys Networks, Inc., and R. Presuhn, who is the editor (Ed.) 💅 The title is long but iconic: Using Authentication, Authorization, and Accounting Services to Dynamically Provision View-Based Access Control Model User-to-Group Mappings ✨ The header doesn't list any RFCs that it obsoletes or updates, so it's standing on its own 🦋
Abstract
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. It describes the use of information provided by Authentication, Authorization, and Accounting (AAA) services, such as the Remote Authentication Dial-In User Service (RADIUS), to dynamically update user-to-group mappings in the View-based Access Control Model (VACM). 🌸
Status of This Memo
Okay, this part is the paperwork, but it matters 📜 This is an Internet Standards Track document. It's a product of the IETF, it represents the consensus of the IETF community, it got public review, and the IESG (Internet Engineering Steering Group) approved it for publication. If you want more on Internet Standards, check out Section 2 of RFC 5741. For the current status, errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc6065. 🔥
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. 🌈
This document is subject to BCP 78 and to the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date. Please read these carefully, because they spell out your rights and restrictions for this document 🫶 Code Components pulled out of this document must include the Simplified BSD License text described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Simplified BSD License describes.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. The Internet-Standard Management Framework . . . . . . . . . . 3
3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Using AAA services with SNMP . . . . . . . . . . . . . . . 4
4.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 5
5. Structure of the MIB Module . . . . . . . . . . . . . . . . . 6
5.1. Textual Conventions . . . . . . . . . . . . . . . . . . . 6
5.2. The Table Structure . . . . . . . . . . . . . . . . . . . 6
6. Relationship to Other MIB Modules . . . . . . . . . . . . . . 6
6.1. Relationship to the VACM MIB . . . . . . . . . . . . . . . 6
6.2. MIB modules Required for IMPORTS . . . . . . . . . . . . . 6
6.3. Documents Required for REFERENCE Clauses . . . . . . . . . 6
7. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 7
7.1. Sequencing Requirements . . . . . . . . . . . . . . . . . 7
7.2. Actions upon Session Establishment Indication . . . . . . 7
7.2.1. Required Information . . . . . . . . . . . . . . . . . 7
7.2.2. Creation of Entries in vacmAaaSecurityToGroupTable . . 8
7.2.3. Creation of Entries in vacmSecurityToGroupTable . . . 8
7.2.4. Update of vacmGroupName . . . . . . . . . . . . . . . 9
7.3. Actions upon Session Termination Indication . . . . . . . 9
7.3.1. Deletion of Entries from
vacmAaaSecurityToGroupTable . . . . . . . . . . . . . 9
7.3.2. Deletion of Entries from vacmSecurityToGroupTable . . 10
8. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 10
9. Security Considerations . . . . . . . . . . . . . . . . . . . 14
9.1. Principal Identity Naming . . . . . . . . . . . . . . . . 14
9.2. Management Information Considerations . . . . . . . . . . 15
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 16
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
12.1. Normative References . . . . . . . . . . . . . . . . . . . 17
12.2. Informative References . . . . . . . . . . . . . . . . . . 181. Introduction ✨
Okay so this memo sets out a way to dynamically provision selected View-based Access Control Model (VACM) [RFC3415] Management Information Base (MIB) objects. The information comes from an Authentication, Authorization, and Accounting (AAA) service, like RADIUS [RFC2865] and [RFC5607]. The big win is that security admins don't have to keep manually updating VACM configs every time users come and go 🙌 A centralized AAA service can supply the link between a given user and the access control policy (called a "group" in VACM) that governs what that user can access in management information.
This memo requires no changes to the Abstract Service Interface for the Access Control Subsystem, and it requires no changes to the Elements of Procedure for VACM. What it does do is provide a MIB module that reflects the information from the AAA service, plus elements of procedure for maintaining that information and making matching updates to VACM MIB data 💖
You're expected to already know [RFC3415], [RFC5607], [RFC5608], and their supporting specs, so get those ready first 🧚
2. The Internet-Standard Management Framework 🌸
If you want a detailed overview of the documents that make up the current Internet-Standard Management Framework, look at section 7 of RFC 3410 [RFC3410].
Managed objects are accessed through a virtual information store called the Management Information Base, or MIB. MIB objects are usually accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant with SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580] 🦋
3. Conventions 📏
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 💅
4. Overview 🔥
4.1. Using AAA services with SNMP
Okay, so there are two use cases for AAA support of management access via SNMP: (a) service authorization and (b) access control authorization. The first one is covered in detail in [RFC5608]. The second one is what this memo is about 👑
The idea here is that roles in an organization (which VACM represents as groups, and groups point to access control policies) change pretty rarely, but the users assigned to those roles change all the time 😭 This memo shows how the user-to-role (group) mapping can be handed off to the RADIUS server. That means no more re-provisioning managed devices every time people are added, removed, or given new roles in an organization.
This memo assumes the detailed access control policies are already set up in VACM. It doesn't try to explain how the policy for a given role gets put in place 🌈
The only extra info pulled from the AAA service is the mapping of the authenticated user's identifier to a specific role (or "group" in VACM terms) within the access control policy. Dynamic user authorization for MIB database access control, as defined here, is limited to mapping the authenticated user to a group. That group then maps to whatever access control policies VACM already has in place 💜
The SNMP architecture [RFC3411] keeps strong modularity and separation of concerns. It separates user identity (authentication) from user database access rights (authorization). RADIUS doesn't do that, though. It doesn't separate authorization from authentication at all 🙈 So the approach here is to reuse existing RADIUS usage for identifying a principal, which is documented in [RFC5608], along with the RADIUS Management-Policy-Id Attribute [RFC5607].
Each AAA-authorized "session" needs a unique identifier. A session is a communication channel, like a transport session, for which a principal has been AAA-authenticated and is allowed to offer SNMP service. How these identifiers get assigned is implementation dependent. When a RADIUS Management-Policy-Id Attribute (or equivalent) is bound to such a session and principal authentication, that binding has enough information to compute dynamic updates to VACM. How the information gets passed around inside an implementation is also implementation dependent. This memo only cares about externally observable behavior 🦋
The key concept is what we'll informally call an "AAA binding." It binds:
- a communications channel
- an authenticated principal
- service authorization
- an access control policy name
Some of the binding happens through other specs. A transport model, like the Secure Shell Transport Model [RFC5592], gives a binding between 1, 2, and 3, and provides a securityName. Then [RFC5607] gives a binding between (1+2+3) and 4. This document takes it one step further, creating a binding between (1+2+3+4) and the local (VACM MIB) definition of the named policy, which is called a group in VACM ✨
4.2. Applicability
Even though this memo was motivated by supporting specific Transport Models, like the Secure Shell Transport Model [RFC5592], it MAY be used with other implementation environments that satisfy these requirements:
- use an AAA service for sign-on service and data access authorization;
- provide an indication of the start of a session for a particular authenticated principal in a particular role, based on information provided by the AAA service. The principal will be identified using an SNMP securityName [RFC3411]. The role will be identified by the name of the corresponding VACM group.
- provide an indication of the end of the need to make access decisions for a particular authenticated principal, such as at the end of a session, whether that's due to disconnection, termination due to timeout, or any other reason.
Likewise, although this memo specifically talks about RADIUS, it MAY be used with other AAA services that satisfy these requirements:
- the service provides information semantically equivalent to the RADIUS Management-Policy-Id Attribute [RFC5607], which corresponds to the name of a VACM group;
- the service provides an authenticated principal identifier (e.g., the RADIUS User-Name Attribute [RFC2865]) that can be transformed into an equivalent principal identifier in the form of a securityName [RFC3411] 🌸
5. Structure of the MIB Module 🧩
5.1. Textual Conventions
This MIB module uses the SnmpAdminString [RFC3411] and SnmpSecurityModel [RFC3411] textual conventions 💖
5.2. The Table Structure ✨
okay so this MIB module only has ONE table, the vacmAaaSecurityToGroupTable 💖 and it's indexed by three things: the integer assigned to each security model, the protocol-independent securityName for a principal, and the unique identifier of a session. bestie, that's a whole lineup 💅
6. Relationship to Other MIB Modules 🦋
this MIB module is super close operationally with the SNMP-VIEW-BASED-ACM-MIB, aka the "VACM MIB" from [RFC3415] 🫶 it also relies on IMPORTS from a bunch of other modules, so it's not doing this alone ✨
6.1. Relationship to the VACM MIB 🌸
so even though this MIB is tight with the VACM MIB's vacmSecurityToGroupTable, it does NOT change the elements of procedure for VACM 🙅♀️ and it doesn't touch any other tables in VACM either. the elements of procedure (down below) spell out how the contents of the vacmSecurityToGroupTable get affected by this MIB module 🎀
6.2. MIB modules Required for IMPORTS 🧚
this MIB module uses definitions from [RFC2578], [RFC2579], and [RFC3411] 💜
6.3. Documents Required for REFERENCE Clauses 📚
this MIB module has REFERENCE clauses that point to [RFC2865], [RFC3411], and [RFC5590] ⭐
7. Elements of Procedure 💅
the elements of procedure are built around two kinds of events: an indication that a session has been established, and an indication that one has ended 🦋 these can create entries in the vacmAaaSecurityToGroupTable, which can then trigger creation, update, or deletion of entries in the vacmSecurityToGroupTable ✨
there are also a bunch of implementation-dependent error cases that aren't spelled out here, like running out of memory 💀 since they're so situational, recovery in those cases is implementation dependent too. implementors are advised to think about fail-safe strategies, e.g., prematurely terminating access rather than erroneously perpetuating access. safety first, periodt 🔥
7.1. Sequencing Requirements 🎀
these procedures assume a transport model, like the one in [RFC5592], is coordinating session establishment with AAA authentication and authorization 🫶 they rely on the AAA client receiving the RADIUS Management-Policy-Id [RFC5607] Attribute (or its equivalent) from the RADIUS Access-Accept message (or equivalent). they also assume the User-Name [RFC2865] from the RADIUS Access-Request message (or equivalent) lines up with a securityName [RFC3411] 🌈
to make sure SNMP PDUs get processed correctly, handling the session establishment indication (following the elements of procedure below) MUST be finished before the isAccessAllowed() Abstract Service Interface [RFC3415] gets invoked for ANY SNMP PDUs from that session 🚨
and if a session termination indication happens before all the isAccessAllowed() Abstract Service Interface [RFC3415] invocations have finished for all SNMP PDUs from that session, those leftover invocations MAY result in denial of access 🙈
7.2. Actions upon Session Establishment Indication 🦋
7.2.1. Required Information 💖
four pieces of info are needed to process the session establishment indication:
- the SnmpSecurityModel [RFC3411] needed as an index into the
vacmSecurityToGroupTable; - the RADIUS User-Name Attribute;
- a session identifier, as a unique, definitive identifier of the session that the AAA authorization is tied to;
- the RADIUS Management-Policy-Id Attribute.
all four of these are REQUIRED, no exceptions 🫶 specifically, if either the User-Name or the Management-Policy-Id is absent, invalid, or a zero-length string, then no further processing of the session establishment indication happens 🙅♀️
as noted in Section 4.2, the text above is specifically about RADIUS attributes. other AAA services can be swapped in, but the requirements on the User-Name and the Management-Policy-Id Attribute MUST be satisfied using the equivalent fields for those services 🧚
7.2.2. Creation of Entries in vacmAaaSecurityToGroupTable ✨
whenever an indication shows up that a new session has been established, check whether a corresponding entry exists in the vacmAaaSecurityToGroupTable. if one doesn't exist, create a new row with the columns filled in like this:
vacmAaaSecurityModel= value of SnmpSecurityModel corresponding to the security model in use;vacmAaaSecurityName= RADIUS User-Name Attribute or equivalent, the securityName that will be used in invocations of the isAccessAllowed() Abstract Service Interface [RFC3415];vacmAaaSessionID= session identifier, unique across all open sessions of all of this SNMP engine's transport models;vacmAaaGroupName= RADIUS Management-Policy-Id Attribute or equivalent.
otherwise, if the row already exists, update the vacmAaaGroupName with the RADIUS Management-Policy-Id Attribute or equivalent that was supplied 🌸
7.2.3. Creation of Entries in vacmSecurityToGroupTable 🦋
whenever an entry gets created in the vacmAaaSecurityToGroupTable, check the vacmSecurityToGroupTable to see if a corresponding entry is already there. use vacmAaaSecurityModel for vacmSecurityModel and vacmAaaSecurityName for vacmSecurityName when you look it up 🔍 if there's no corresponding entry, create one: use the vacmAaaGroupName of the newly created entry to fill in vacmGroupName, set the row's StorageType to "volatile", and set its RowStatus to "active" 💜
7.2.4. Update of vacmGroupName 🌈
whenever the value of an instance of vacmAaaGroupName gets updated, if a corresponding entry exists in the vacmSecurityToGroupTable, and that entry's StorageType is "volatile" and its RowStatus is "active", update the value of vacmGroupName with the value from vacmAaaGroupName ✨
if a corresponding entry already exists in the vacmSecurityToGroupTable, and that row's StorageType is anything other than "volatile", or its RowStatus is anything other than "active", then that instance of vacmGroupName MUST NOT be modified. 🙅♀️
the operational assumption here is that if the row's StorageType is "volatile", the entry was probably created dynamically, because a security administrator wouldn't normally give an entry a StorageType of "volatile" 🧚 if the value coming from RADIUS (or another AAA service) is the same as what's already there, it's a no-op 😌 if it's different, the new info counts as a more recent role (group) assignment for the user, and it should supersede the one currently there 💅 and the structure of the vacmSecurityToGroupTable makes it impossible for a (vacmSecurityModel, vacmSecurityName) tuple to map to more than one group 🫶
7.3. Actions upon Session Termination Indication 💀
whenever a RADIUS (or other AAA) authenticated session ends for ANY reason, an indication is provided. this indication MUST provide a way of determining the SnmpSecurityModel, plus an identifier for the transport session tied to the AAA authorization. how this happens is implementation dependent 🌸
7.3.1. Deletion of Entries from vacmAaaSecurityToGroupTable 🎀
entries in the vacmAaaSecurityToGroupTable MUST NOT persist across system reboots. 🔄
when a session has been terminated, the vacmAaaSecurityToGroupTable gets searched for a corresponding entry. a "matching" entry is any entry where the SnmpSecurityModel and session ID match the info tied to the session termination indication. any matching entries get deleted 🗑️ it's possible that nothing matches, and that's not an error, so no special processing is needed in that case 🫶
7.3.2. Deletion of Entries from vacmSecurityToGroupTable 💜
whenever the last remaining row with a particular (vacmAaaSecurityModel, vacmAaaSecurityName) pair gets deleted from the vacmAaaSecurityToGroupTable, the vacmSecurityToGroupTable gets checked for a corresponding row. if one exists, and its StorageType is "volatile" and its RowStatus is "active", that row MUST be deleted as well. the mechanism for doing this is implementation dependent 🧚
8. Definitions 📜
SNMP-VACM-AAA-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF
MODULE-IDENTITY, OBJECT-TYPE,
mib-2,
Unsigned32 FROM SNMPv2-SMI
SnmpAdminString,
SnmpSecurityModel FROM SNMP-FRAMEWORK-MIB;
vacmAaaMIB MODULE-IDENTITY
LAST-UPDATED "201012090000Z" -- 9 December 2010
ORGANIZATION "ISMS Working Group"
CONTACT-INFO "WG-email: isms@ietf.org"
DESCRIPTION "The management and local datastore information
definitions for the AAA-Enabled View-based Access
Control Model for SNMP.
Copyright (c) 2010 IETF Trust and the persons
identified as the document authors. All rights
reserved.
Redistribution and use in source and binary forms,
with or without modification, is permitted pursuant
to, and subject to the license terms contained in,
the Simplified BSD License set forth in Section
4.c of the IETF Trust's Legal Provisions Relating
to IETF Documents
(http://trustee.ietf.org/license-info).
This version of this MIB module is part of RFC 6065;
see the RFC itself for full legal notices."
REVISION "201012090000Z"
DESCRIPTION "Initial version, published as RFC 6065."
::= { mib-2 199 }
vacmAaaMIBObjects OBJECT IDENTIFIER ::= { vacmAaaMIB 1 }
vacmAaaMIBConformance OBJECT IDENTIFIER ::= { vacmAaaMIB 2 }
vacmAaaSecurityToGroupTable OBJECT-TYPE
SYNTAX SEQUENCE OF VacmAaaSecurityToGroupEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "This table provides a listing of all currently active
sessions for which a mapping of the combination of
SnmpSecurityModel and securityName into the name of
a VACM group has been provided by an AAA service.
The group name (in VACM) in turn identifies an access
control policy to be used for the corresponding
principals."
REFERENCE "RFC 3411, Section 3.2.2, defines securityName."
::= { vacmAaaMIBObjects 1 }
vacmAaaSecurityToGroupEntry OBJECT-TYPE
SYNTAX VacmAaaSecurityToGroupEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "An entry in this table maps the combination of a
SnmpSecurityModel and securityName into the name
of a VACM group defining the access control policy
that is to govern a particular session.
Each entry corresponds to a session.
Entries do not persist across reboots.
An entry is created whenever an indication occurs
that a new session has been established that would
not have the same index values as an existing entry.
When a session is torn down, disconnected, timed out
(e.g., following the RADIUS Session-Timeout Attribute),
or otherwise terminated for any reason, the
corresponding vacmAaaSecurityToGroupEntry is deleted."
REFERENCE "RFC 3411, Section 3.2.2, defines securityName."
INDEX {
vacmAaaSecurityModel,
vacmAaaSecurityName,
vacmAaaSessionID
}
::= { vacmAaaSecurityToGroupTable 1 }okay so this is where the MIB module actually lives, and the entry table is giving main character energy 💅🎀
VacmAaaSecurityToGroupEntry ::= SEQUENCE
{
vacmAaaSecurityModel SnmpSecurityModel,
vacmAaaSecurityName SnmpAdminString,
vacmAaaSessionID Unsigned32,
vacmAaaGroupName SnmpAdminString
}
vacmAaaSecurityModel OBJECT-TYPE
SYNTAX SnmpSecurityModel(1..2147483647)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "The security model associated with the AAA binding
represented by this entry.
This object cannot take the 'any' (0) value."
::= { vacmAaaSecurityToGroupEntry 1 }
vacmAaaSecurityName OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE(1..32))
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "The securityName of the principal associated with the
AAA binding represented by this entry. In RADIUS
environments, this corresponds to the User-Name
Attribute."
REFERENCE "RFC 3411, Section 3.2.2, defines securityName, and
RFC 2865, Section 5.1, defines User-Name."
::= { vacmAaaSecurityToGroupEntry 2 }
vacmAaaSessionID OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "An implementation-dependent identifier of the session.
This value MUST be unique among all currently open
sessions of all of this SNMP engine's transport models.
The value has no particular significance other than to
distinguish sessions.
Implementations in which tmSessionID has a compatible
syntax and is unique across all transport models MAY
use that value."
REFERENCE "The Abstract Service Interface parameter tmSessionID
is defined in RFC 5590, Section 5.2.4."
::= { vacmAaaSecurityToGroupEntry 3 }
vacmAaaGroupName OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE(1..32))
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The name of the group to which this entry is to belong.
In RADIUS environments, this comes from the RADIUS
Management-Policy-Id Attribute.
When the appropriate conditions are met,
the value of this object is applied the vacmGroupName
in the corresponding vacmSecurityToGroupEntry."
REFERENCE "RFC 3415"
::= { vacmAaaSecurityToGroupEntry 4 }ngl the vacmAaaSessionID one is the most important bit here 🔥 the value has to be unique across all the open sessions of the engine's transport models, but it doesn't mean anything beyond telling sessions apart 🦋 and if tmSessionID already fits the bill, you MAY just reuse it 🫶
Conformance information 🎀
-- Conformance information ******************************************
vacmAaaMIBCompliances
OBJECT IDENTIFIER ::= {vacmAaaMIBConformance 1}
vacmAaaMIBGroups
OBJECT IDENTIFIER ::= {vacmAaaMIBConformance 2}
-- compliance statements
vacmAaaMIBBasicCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION "The compliance statement for SNMP engines implementing
the AAA-Enabled View-based Access Control Model for
SNMP."
MODULE -- this module
MANDATORY-GROUPS { vacmAaaGroup }
::= { vacmAaaMIBCompliances 1 }
-- units of conformance
vacmAaaGroup OBJECT-GROUP
OBJECTS {
vacmAaaGroupName
}
STATUS current
DESCRIPTION "A collection of objects for supporting the use of AAA
services to provide user-to-group mappings for VACM."
::= { vacmAaaMIBGroups 1 }
END9. Security Considerations 🔐💀
okay this section is serious, so listen up bestie 🫶 the algorithms in this memo kinda guess which entries in the vacmSecurityToGroupTable were set up by a security admin and which ones were generated automatically, and they do it by looking at the StorageType. the assumption is that a row a human provisioned with a non-"volatile" status is not supposed to get overridden dynamically, and that any active row marked "volatile" can be treated as dynamic and deleted or updated when needed. that's reasonable, but it's NOT universally true 😭 like, if the admin accidentally made those non-volatile rows by mistake, you'd get the same situation anyway. users of this memo have to know about this.
also, if an unknown policy (group name) shows up in the vacmSecurityToGroupTable, VACM grants no access at all 🙅♀️ so no matter what the AAA server sends back, a user can't get SNMP access rights that aren't already granted to some group through the VACM configuration. that's the main protection, and it's a good one ✨
9.1. Principal Identity Naming 🪪
okay so the mapping from the authenticated user (principal) identity to the securityName used for the access control decision has to be handled with care, or the wrong policy could end up applied. there are basically two ways to keep identities consistent:
- entries in the
vacmSecurityToGroupTablefor a given security model only get created through the procedures in this memo. so every such entry was made using the RADIUS User-Name (or another AAA-authenticated identity) and the RADIUS Management-Policy-Id Attribute (or the equivalent). - administrative policy lets a matching pre-configured entry exist in the
vacmSecurityToGroupTable, meaning an entry with the matchingvacmSecurityModeland avacmSecurityNamethat matches the authenticated principal's RADIUS User-Name. in that case, admin policy also has to make sure each principal's RADIUS User-Name is consistent with the administratively configuredvacmSecurityNamein the rows for that security model.
in the second case, if the same name gets reused inconsistently for different entities or people (principals), the wrong access control policy can be applied to the authenticated principal 😬 depending on whether the SNMP-configured policy or the policy applied through this memo's procedures is the one that was actually intended. that could mean more or fewer access rights than the admin meant to give. and honestly, a misidentification like that might be completely undetectable by the SNMP engine or other software on the managed entity 👀
9.2. Management Information Considerations 🧚
there are no management objects in this MIB module with a MAX-ACCESS of read-write and/or read-create. so if this MIB module is implemented correctly, an intruder has no way to change or create any of its management objects with direct SNMP SET operations 🙌
some of the readable objects in this module can be sensitive or vulnerable in certain network environments, including some not-accessible objects whose values get exposed when you access indexed objects. so it matters a lot to control even GET and/or NOTIFY access to these objects, and it might even be worth encrypting their values when they're sent over the network via SNMP 🔒 here's the table and object breakdown and why each one is sensitive:
vacmAaaSecurityToGroupTable: the entire table is potentially sensitive, because walking it reveals user names, the security models in use, session identifiers, and group names.vacmAaaSecurityModel: even though it'snot-accessible, it's exposed as an index ofvacmAaaGroupName.vacmAaaSecurityName: even though it'snot-accessible, it's exposed as an index ofvacmAaaGroupName.vacmAaaSessionID: even though it'snot-accessible, it's exposed as an index ofvacmAaaGroupName.vacmAaaGroupName: since it identifies a security policy and links it to a particular user, it's potentially sensitive.
SNMP versions before SNMPv3 didn't include adequate security 😩 and even if the network itself is secure (for example, by using IPsec), there's still no control over who on that secure network can access and GET/SET (read/change/create/delete) the objects in this MIB module.
it is RECOMMENDED that implementers look at the security features that the SNMPv3 framework provides (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms for authentication and privacy 🔐
and deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. instead, it is RECOMMENDED to deploy SNMPv3 and turn on cryptographic security. after that, it's the customer/operator's responsibility to make sure the SNMP entity giving access to an instance of this MIB module is configured so that only the principals (users) with legitimate rights can GET or SET (change/create/delete) those objects 🫶
10. IANA Considerations 📋
the MIB module in this document uses the following IANA-assigned OBJECT IDENTIFIER value, which is recorded in the SMI Numbers registry:
Descriptor OBJECT IDENTIFIER value
---------- -----------------------
vacmAaaMIB { mib-2 199 }11. Contributors 🌸
the following participants from the ISMS working group helped develop this document:
- Andrew Donati
- David Harrington
- Jeffrey Hutzelman
- Juergen Schoenwaelder
- Tom Petch
- Wes Hardaker
during the IESG review, additional comments came in from:
- Adrian Farrel
- Amanda Baber
- Dan Romescanu
- David Kessens
- Francis Dupont
- Glenn Keeni
- Jari Arkko
- Joel Jaeggli
- Magnus Nystrom
- Mike Heard
- Robert Story
- Russ Housley
- Sean Turner
- Tim Polk
12. References 📚
12.1. Normative References ✨
okay bestie, this is the reading list the whole spec is built on 📚 nine docs, each one listed with its full details so you can go find them 🦋
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J.
Schoenwaelder, Ed., "Structure of Management Information
Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
[RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J.
Schoenwaelder, Ed., "Textual Conventions for SMIv2",
STD 58, RFC 2579, April 1999.
[RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder,
"Conformance Statements for SMIv2", STD 58, RFC 2580,
April 1999.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, June 2000.
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An
Architecture for Describing Simple Network Management
Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,
December 2002.
[RFC3415] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based
Access Control Model (VACM) for the Simple Network
Management Protocol (SNMP)", STD 62, RFC 3415,
December 2002.
[RFC5590] Harrington, D. and J. Schoenwaelder, "Transport Subsystem
for the Simple Network Management Protocol (SNMP)",
RFC 5590, June 2009.
[RFC5607] Nelson, D. and G. Weber, "Remote Authentication Dial-In
User Service (RADIUS) Authorization for Network Access
Server (NAS) Management", RFC 5607, July 2009.
[RFC5608] Narayan, K. and D. Nelson, "Remote Authentication Dial-In
User Service (RADIUS) Usage for Simple Network Management
Protocol (SNMP) Transport Models", RFC 5608, August 2009.12.2. Informative References 🌸
and these two are the extra-credit reading 🧚 handy to have, not the core ones 💜
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart,
"Introduction and Applicability Statements for Internet-
Standard Management Framework", RFC 3410, December 2002.
[RFC5592] Harrington, D., Salowey, J., and W. Hardaker, "Secure
Shell Transport Model for the Simple Network Management
Protocol (SNMP)", RFC 5592, June 2009.Authors' Addresses 🎀
and finally, who wrote this thing 🫶 here's where you can find the authors, with their contact details exactly as published
Kaushik Narayan
Cisco Systems, Inc.
10 West Tasman Drive
San Jose, CA 95134
USA
Phone: +1 408-526-8168
EMail: kaushik_narayan@yahoo.com
David Nelson
Elbrys Networks, Inc.
282 Corporate Drive, Unit #1,
Portsmouth, NH 03801
USA
Phone: +1 603-570-2636
EMail: d.b.nelson@comcast.net
Randy Presuhn (editor)
San Jose, CA 95120
USA
EMail: randy_presuhn@mindspring.comthat's the whole spec, bestie!! 🌈✨ 💅
📦 where this page comes from
- ietf: rfc6065 2010-12
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms