SNMPv3 Access Control: VACM

• The VACM determines whether access to a managed object in a local MIB by a remote principal should be allowed.

• The VACM makes use of a MIB that defines the access control policy for this agent, and makes it possible for remote configuration to be used. In this section, we first look at the elements that make up the VACM model, and then summarize the motivations for this organization.

Elements of the VACM Model:

There are five elements that make up the VACM: • Groups • Security level • Contexts • MIB views • Access policy

1) VACM: groups

• Basically, a set of security model, security names

• A useful concept for categorizing managers with respect to access rights

• All member of a group have the same right

• SecurityName: human readable string representing a principal (i.e., the username of manager)

• SecurityModel: 1 - SNMPv1, 2 - SNMPv2, 3 - SNMPv3

2) VACM: security level

• There are three levels: i) No authentication, no privacy ii) Authentication, no privacy iii) Authentication, privacy

• Privacy means encryption using DES and authentication requires a password hashed with MD5 or SHA1.

• Access rights may differ depending on the security level of the message containing the request.

Examples: An agent may allow read-only access for a request communicated in an unauthenticated message but may require authentication fro write access. The agent may also require privacy service for some sensitive objects/information. The VACM requires that the securityLevel is passed as input when called to check for access rights

3) VACM: MIB views and view families

• To restrict the access rights of some groups to only a subset of the management information

• Specifying its rights in terms of the particular (subset) MIB view it can access

• MIB view is defined as the combination of a set of "view subtrees", where each view subtree is a subtree within the managed object naming tree

4) VACM: Context

• A collection of management information accessible by an SNMP entity

• A useful way for aggregating objects into collections with different access policies

• SNMP engine may maintain more than one context. An object or an instance may appear in more than one context

5) VACM: Access Policy

• Determines the access right to objects as read-view, write-view, notify-view

• Read-view: get, getNext, getBulk, Write-view: set, Notify-view: notification

• For a given groupName, contextName, SecurityModel, SecurityLevel access right is any combination of the views or not- accessible

For USM Refer (Explain user security model of SNMPV3) asked in May 2015.

• In contrast to SNMP version 1 (SNMPv1) and SNMP version 2 (SNMPv2), SNMP version 3 (SNMPv3) supports authentication and encryption. SNMPv3 uses the user-based security model (USM) for message security and the view-based access control model (VACM) for access control.

• USM specifies authentication and encryption. VACM specifies access-control rules.

• USM uses the concept of a user for which security parameters (levels of security, authentication, privacy protocols, and keys) are configured for both the agent and the manager.

• Messages sent using USM are better protected than messages sent with community strings, where passwords are sent in the clear.

• With USM, messages exchanged between the manager and the agent can have data integrity checking and data origin authentication. USM protects against message delays and message replays by using time indicators and request IDs. Encryption is also available.

• To complement the USM, SNMPv3 uses the VACM, a highly granular access-control model for SNMPv3 applications.

• Based on the concept of applying security policies to the name of the groups querying the agent, the agent decides whether the group is allowed to view or change specific MIB objects.

• VACM defines collections of data (called views), groups of data users, and access statements that define which views a particular group of users can use for reading, writing, or receiving traps.

• Trap entries in SNMPv3 are created by configuring the notify, notify filter, target address, and target parameters.

• The notify statement specifies the type of notification (trap) and contains a single tag. The tag defines a set of target addresses to receive a trap.

• The notify filter defines access to a collection of trap object identifiers (OIDs).

• The target address defines a management application's address and other attributes to be used in sending notifications.

• Target parameters define the message processing and security parameters to be used in sending notifications to a particular management target.

• SNMPv3 Access Control: VACM

1. The VACM determines whether access to a managed object in a local MIB by a remote principal should be allowed.

2. The VACM makes use of a MIB that defines the access control policy for this agent, and makes it possible for remote configuration to be used. In this section, we first look at the elements that make up the VACM model, and then summarize the motivations for this organization.

• Elements of the VACM Model:

There are five elements that make up the VACM: 1.Groups 2.Security level 3.Contexts 4. MIB views 5. Access policy

1) VACM: groups

• Basically, a set of security model, security names

• A useful concept for categorizing managers with respect to access rights

• All member of a group have the same right

• SecurityName: human readable string representing a principal (i.e., the username of manager)

• SecurityModel: 1 - SNMPv1, 2 - SNMPv2, 3 - SNMPv3

2) VACM: security level

• There are three levels: i) No authentication, no privacy ii) Authentication, no privacy iii) Authentication, privacy

• Privacy means encryption using DES and authentication requires a password hashed with MD5 or SHA1.

• Access rights may differ depending on the security level of the message containing the request.

• Examples: An agent may allow read-only access for a request communicated in an unauthenticated message but may require authentication fro write access. The agent may also require privacy service for some sensitive objects/information. The VACM requires that the securityLevel is passed as input when called to check for access rights

3) VACM: MIB views and view families

• To restrict the access rights of some groups to only a subset of the management information

• Specifying its rights in terms of the particular (subset) MIB view it can access

• MIB view is defined as the combination of a set of "view subtrees", where each view subtree is a subtree within the managed object naming tree

4) VACM: Context

• A collection of management information accessible by an SNMP entity

• A useful way for aggregating objects into collections with different access policies

• SNMP engine may maintain more than one context. An object or an instance may appear in more than one context

5) VACM: Access Policy

• Determines the access right to objects as read-view, write-view, notify-view

• Read-view: get, getNext, getBulk, Write-view: set, Notify-view: notification

• For a given groupName, contextName, SecurityModel, SecurityLevel access right is any combination of the views or not- accessible