Managing Access and Usage Controls in SNMP

E. Barka, F. Sallabi, and A. Hosani

College ofInformation Technology UAE University, AI Ain, UAE

{ebarka, 200601259 }@uaeu.ac.ae

ABSTRACT

Simple Network Management Protocol "SNMP", which is a component of the Internet Protocol Suite, is the most widely-used protocol in network management systems today. It is used to monitor network-attached devices such as routers, switches, Servers, workstations, printers, etc., for conditions that warrant administrative attention. In its initial versions, SNMPvl and SNMPv2, SNMP was criticized for its lack of security, however, in its latest version, SNMPv3, it added important security features such as confidentiality, message integrity, authentication, and access control.

In this paper we analyze the current approach, used by SNMP for providing access control, and we present new architecture that implements a new type of access control, called Usage Control (UCON), to better-control the access to the SNMP-managed environment at: pre-connection, during connection, and post connection. We believe that our proposed solution will enable owners of the SNMP­managed network to control who can access the system objects "i.e. the MIBs", to control the activities of both the manager and the agent entities, and to help set some parameters to determine whether a communication between the agent and the manager can continue or should terminate. Keywords: SNMP; Access Control; VBAC; UCON

1. INTRODUCTION

Nowadays, communication networks are experiencing a tremendous growth in size and the services they offer. These networks rely on centralized management systems which control large number of network elements by manipulating local management agents. Most of these management systems implement an industry standard protocol known as Simple Network Management Protocol (SNMP). In typical SNMP use, one or more administrative computers called managers have the task of monitoring or managing a group of hosts or devices on a computer network. Each managed system executes, at all times, a software component called an agent, which reports information via SNMP messages to the manager [ I].

Essentially, SNMP agents expose management data on the managed systems as variables. These variables and other metadata (such as type and description of the variable), are described by Management Information Bases (MIBs) [ I, 2].

978-1-4577-1719-2112/$26.00 ©2012 IEEE 41

SNMP protocol also permits active management tasks, such as modifYing and applying a new configuration through remote modification of these variables.

In this paper we analyze the current approach that SNMPv3 applies to provide access control and we propose new architecture that implements a new type of access control, called Usage Control (UCON), to control the access to the SNMP-managed resources at: pre-connection, during connection, and post connection. We believe that our proposed solution will enable owners of the SNMP­managed network to have better control on who can access the MIBs, to control the activities of both the manager and the agent entities, and to help set some parameters to determine whether a communication between the agent and the manager can continue or should terminate.

1.1. Motivation

In this section we present few factors that support the usage control UCON model over the traditional "VBAC" access control, which is implemented in SNMPv3, in the case of network management applications.

The main security enhancement made in SNMPv3 is the addition of the two security subsystems: The User-Based Security Mode (USM) and the View-Based Access Control Model. These two subsystems enabled SNMP to provide better security services such as authentication, encryption, and privacy. However, USM was not meant to protect against traffic analysis, where an attacker can sniff and monitor the network. This is because SNMP traffic is predictable, so there is no point in protecting it. Moreover, denial of server attack (�OS) is still a problem with SNMPv3. This is simply because DOS attacks cannot be differentiated from network failures. Also, DOS is usually a network-wide problem, which can be caused by areas that SNMP cannot control [2].

SNMP relies on the View-based access control (VBAC) for

controlling the access to the MIBs objects. Even though

VBAC is considered as an adequate mean for protecting

system objects, it suffers from the following problems:

Safety: Since objects are shared between views, objects

in secret-labeled view may exist in a confidential­

labeled view. Therefore, these objects are exposed to

people who are not supposed to have access to them [3].

Assurance: since every view is based on a query

sentence, storing all queries and database management

system (DBMS) codes for all views may result in a

large Trusted Computer Base (TCB). A small TCB is

essential for granting certification for multi-level

security systems.

VBAC suffers from the lack of flexibility to specify

security policies in the case of ubiquitous environments.

This means that the VBAC cannot provide the same

level of control of access in the cases were the attribute

of the requester changes (i.e. memberships of the group

changes) or the context in which the policy was written

has also changed [3].

For the above mentioned reasons, adopting the access control philosophy of UCON, which controls the usage before, during, and after connections, would substantially enhance the access control on the system objects. These UCON benefits are manifested through its ability to specify and enforce usage policies not only before access, but also during the access and after the task are completed.

The remainder of this paper is organized as follows. In section 2 provides some background on SNMPv3 and discusses how its security addition contributes to protection in the emerging pervasive environment. We do this by first providing an overview of SNMP applications and related security aspects. Section 3 introduces the usage control model (UCON). Section 4 presents our architecture and explains the integration of SNMP with UCON. Finally, section 5 discusses future work and concludes our paper.

2. SNMP OVERVIEW

2.1. SNMP Arcitecture

An SNMP-managed network consists of three key components [1, 2, and 4]: Agent - software which runs on managed devices and performs the tasks such as capturing information about its local environment, retrieving this information when the manager asks for it; and informing the manager when something up-normal happened, by sending "trap" messages.

• Network management system (NMS) - software which runs on the manager and executes applications that monitor and control managed devices.

A managed devices have SNMP agents running on them to allow exchange of node-specific information with the NMSs. Managed devices may including routers, access servers, switches, bridges, hubs, IP telephones, IP video

cameras, computer hosts, printers, and etc.

42

• In addition, Simple Network Management Protocol

(SNMP) defines the following entities:

Management Information Base (MlBs), which are two

types:

o Global MIB: contains information about the whole

network, and is kept by the manager.

o Local MIB: contains information about the local

environment of an agent, and kept by agent itself.

SNMP messages are of the following format:

Get messages: these messages are sent from a

manager to an agent to get a piece of information.

Set requests: sent from a manager to an agent to

modify or enter data into the MIB of an agent.

Trap: sent from an agent to alert a manager.

Inform: an alert sent from a manager to another

manager.

Figure 1 illustrates the basic components of SNMP.

A.C sub·

Traditional Sj\;MP Manal!cr

Fig 1: SNMP Communication

2.2. SNMP Security

SNMP Provides authentication and encryption services by using DES-CBC with 64-bit key and SHA 1-96 or MD5-96 The keys and initial values for encryption and authentication services are generated using a key localization mechanism, which derives the required keys and IVs from a password. It requires a principal to memorize only one password (or two passwords, one for encryption and the other for authentication).

2.3. Existing Access Control in SNMPv3

SNMP relies on the well-known View-based Access Control Model "V ACM" to control access to its MlBs. V ACM is invoked whenever a message is received or sent from an

agent to check the access rights of the receiver of the message. Access Policy is used in V ACM to determine the access rights for users or groups. Right are given as a read-view, write view, notifY-view. The following steps describe the process taken by V ACM to enforce an access policy:

V ACM takes two inputs, which are security name and

security model. Then, it searches within the

"VacmSecurityToGroupTable" to find a group

containing this combination. If it returns zero rows (this

combination does not exists in any group), then V ACM

returns an error indication (NoGroupName).

V ACM takes the second input, which is the context

name, and checks the VacmAccessTable to determine if

the group found in step 1 has the right to access this

context.

Then, it takes the securityModel and SecurityLevel to

determine whether the previous group has access to this

context by this level of security.

After that, it takes the "ViewType"as input to determine

whether this group can access this context by this level

of security to read, write or notifY.

The last step is checking if the previous group can

access this variable by using "variable name"

Access control decisions are taken only after the above steps are completed.

Access control in VCAM assumes that authentication was performed; and therefore, does not check the authenticity of the sender. This is because there are access control fields in the header that needs to be validated before running into taking Access Control decisions [ I, 3].

Therefore, the security challenge facing SNMP is to ensure Authentication and authorization not only at pre­connections, but also during connections.

Our approach introduces a new type of access control, named Usage Access Control (UCON) [6, 7, and 8]. UCON is used here to control the access to the SNMP-based communications at: pre-connection, during-the-connection, and even at post connection. This enables network owners to allow, and disallow, memberships to the SNMP community, to control who can access the MIBs and how, and to set some parameters to determine whether a certain access can continue or should terminate.

The following section provides an overview of the Usage Control Model (UCON).

3. USAGE CONTROL MODEL (UCON) OVERVIEW

In this section we briefly review the general ideas of UCON and the core authorization models. The details of these models can be found in [7, 8].

The UCON model consists of six components, three of these components "subjects, objects, and rights" are considered as core components and the other three "authorization rules,

43

conditions, and obligations" are additional, and they are mainly involved in the authorization process (see figure 2).

In UCON system, rights-related authorization rules have to be included for authorization. Conditions and obligations can also be used in the authorization process. The following sub-sections describe UCON's core components.

3.1. Subjects and Objects

Subjects and Objects in UCON are "Active" and "Passive" entities in the system respectively.

3.2. Rights

Rights are privileges that a subject can hold on an object.

UCON rights can be divided into many functional categories. The two most fundamental rights categories might be a view and a modification. They are denoted as V and M respectively such that: R={V, M} Modification includes change to an existing digital object and creation of a new object that reuses an original digital object. The range of V and M is denoted as: C={O, I, a} where:

"0" means closed to everybody (no one can access),

" I " means open to everybody (everyone can access),

and "a" means access approval is selective or controlled.

The openness of the control or availability of object to

public is expressed as 0 < a < 1 which means that 1 is

most open to public and 0 is least open.

The following sub-sections describe the additional component of UCON [7, 8].

3.3. Authorization Rules

Authorization rules are a set of decision factors used to check whether a subject is qualified for the use of certain rights on an object; they are a set of requirements that should be satisfied before allowing subjects to access to, or use of objects. In UCON, there are mainly two kinds of authorization rules. The Rights-related Authorization Rules (RAR) , which are used to check if a subject has valid privilege to exercise certain rights on a digital object. Examples of such rules may include identities or roles verification, properties checking, proof of payments, etc.

And The Obligation-related Authorization Rules (OAR), which is mainly used to check if a subject has agreed on the fulfillment of an obligation which has to be done after obtaining or exercising rights on a digital object. Examples of such rules may include things like usage log report agreement, etc.

3.4. Conditions

Conditions are a set of decision factors that the system should verifY at authorization process along with authorization rules before allowing usage of rights on a digital object. Conditions are of two types: One is the

dynamic conditions, which are conditions that include information to be checked for updates at each time of usage. Examples of dynamic conditions are the number of usage times (e.g., can read 5 times, can print 2 times), and usage log (e.g., already read portion cannot be accessed again). The other is the static conditions, which include information that does not have to be checked for updates. Some examples of static conditions are accessible time periods (e.g., business hours), accessible locations (e.g., workplace), and allowed printer names.

3.5. Obligations

Obligations are mandatory requirements that a subject has to perform after obtaining or exercising rights on an object. In real world implementation, however, this may have to be done by agreeing on the fulfillment of obligations before obtaining the rights. For example, a subject may have to agree on providing usage log information to a provider subject before allowing the access.

The most important properties that distinguish UCON from traditional access control models are the continuity of usage decisions and the mutability of attributes. Continuity means that a control policy may be enforced not only before an access, but during the period of the access [8].

Sub'ects S Subject

Attributes (SA)

Fig 2: UCON Components

Ob'ects 0 Object

Attributes (OA)

Mutability refers to updates of the subject or the object's attribute that may occur as a result of the access. Along with the three phases there are three kinds of updates: pre­updates, ongoing-updates, and post-updates. All these updates are performed and monitored by the system. An update of subject or object attributes may result in a system action to permit or revoke an access. An update can affect not only the concurrent usage, but also other usages related to the same subject or object. An update on the current usage may generate

The control decision components are checked and enforced in the first two phases, named pre-decisions and ongoing­decisions respectively. In the after-usage phase, UCON doesn't enforce any policy since there is no access control after a subject finishes a usage on an object. But it utilized mutability.

4. SNMP/UCON INTEGRATION

Integrating the UCON technology into a SNMP-based

44

environment requires a careful mapping between the entities of UCON and those entities and components of the SNMP. Following is a list of integrated components which require such mapping:

Subjects: Are entities that can perform certain rights on objects.

Objects: Are entities where rights are exercised upon them by subjects.

The concept of a Manger in SNMP is represented as a subject component in the UCON.

The concept of an Agent in SNMP is represented as a subject component in the UCON, in the cases when the agent is operating on system objects (I.e., when operating on MIB objects).

The concept of an Agent in SNMP can also be represented by an object in UCON, in the case when the agent is operated upon by the manager (I.e., when it is configured by the manager).

Permissions/Rights: The concept of Permissions in UCON will reflect all the privileges that an SNMP entity needs to complete a task.

Authorization Rules: Authorization rules in UCON are the set of requirements that should be satisfied before any SNMP active entity is permitted to operate on any MIB objects, or to be permitted to communicate with other entities within the SNMP community.

M.n.g.,.

Fig 3: SNMP-UCON Integration

Obligations: The concept of Obligation in UCON can be represented in SNMP as the set of actions that SNMP entity is required to perform before and after the connection has been established.

Conditions: Conditions in UCON are represented in SNMP by the set of environmental and system decision factors that must be continuously evaluated to make sure that their changes do not lead to changes in the access status.

4.1. Architecture ofthe UCON/SNMP

One of the most critical issues in using UCON for enforcing access into SNMP environment is to use the concept of a reference monitor. The reference monitor (RM), which has been extensively used by the access control community for years, was introduced and published by the ISO as a standard for access control framework [10], and has been considered as the core control mechanism for access and usage of digital information. In classical access control,

subjects can access digital objects only through the reference monitor (RM), which is a process inside the trusted computer base (TCB) that is always running and is a tamper proof. The following section discusses our conceptual structure of UCON/SNNMP access control domains, based on the reference monitor.

4.2. SNMP/uCON Mode of operation

The area of control in our architecture refers to the area of coverage where the rights to access the SNMP MIB objects is under the control of the reference monitor. According to the standard [10], the reference monitor

consists of two facilities: Access Control Enforcement Facility (AEF) and Access Decision Facility (ADF). These two facilities interact in such a way that every request to access an object is intercepted by AEF, who asks the ADF for a decision on the request approval. The ADF returns either 'yes' or 'no' as appropriate. The enforcement of this decision takes place at the AEF.

Our UCON/SNMP reference monitor is similar but differs in the details from that of ISO model. Figure 4 shows the conceptual structure of the UCON/SNMP reference monitor.

Access Enforcement Facility (AEF)

Fig 4: Conceptual Structure for UCON/SNMP Reference Monitor

As the figure shows, both the AEF and ADF include several functional modules. The AEF contains:

Monitoring module which is used to keep track of the

changes of the attributes of the subjects and objects.

Updating module which is used primarily to update the

attributes of the subjects and objects.

The ADF is where all of the access granting decisions, and the access maintenance and the access termination take place. This facility includes three core modules that are utilized collectively in rendering access decisions as response to the (AEF) requests:

• Authorization

• Condition

• Obligation

The Authorization module uses subjects and objects attributes, and the access rules to check if a request is allowed or not. The condition module uses the access rules and the contextual information to decide whether the

45

conditional requirements, both system and environmental, for the authorized request are satisfied or not. Finally, the obligation module is responsible for handling decisions that are tied to actions, which are required to be performed by the requestor before, during or after the access is granted. All existing obligations are monitored by the monitoring module and the outcome must be resolved by the update module in the AEF.

4.3. Areas of control Architecture

There are two possible areas by which to control the access to the SNMP-based environment, based on the location of the reference monitor. The Manager-side control domain (MCD) is the area where the reference monitor is located at the manager environment and directly enforces the access policy to the system resources. The Agent-side control domain (ACD), on the other hand, is the area of control where the reference monitor is located at the agent-side environment and enforces the access policy on behalf of the manager. Our architecture considers the later, due to the fact that the most critical elements to protect are the agent and the MIB objects, which are both located at the agent­side environment. Figures 5 depict this architecture.

snmp manager

Server

Reference monitor

�-.f----M( Subject �H-+--lt+;"' snmp agent

Client/server Client

Fig 5: Client side reference monitor

Figure 5 shows that the reference monitor does not reside within the area of the server, but rather at the client side. This set up provides for better usage control over system objects. In this case, because of the existence of the SRM, the system objects can be stored centrally or locally. In either case, the objects are under the control of the client instead of the server.

Figure 5 also represents the scenario where the manager is the server that operates on the agent through the CRM. In this case the reference monitor is active at the client (agent) side only, and it controls the operations of the manager (subject) on the agent (object). Further, the agent becomes a subject when operating on the MIB through the CRM, the CRM, again, resides on the agent's side to control the access of the agent to the MIB.

authentication

Fig 6: Authorization (Before)

Figure 6 illustrates the scenario of a successful authorization process. In this figure, an SNMP manager is trying to retrieve data from the MIB behind the agent. The manager communicates with the agent who authenticates and authorizes the sender to retrieve such information. Upon valid authorization, the agent communicates with the MIB on behalf of the manager to retrieve the data. The data is then encapsulated, goes through the access control module again to re-check that the destination of this data is eligible, authorized to view it, then the appropriate security fields are added. Finally, the message is fetched to its destination.

d.eaypt iiUld check the digest: lJ the user

authentic?

e.l to the UCON

Y authorization rules

Does the user have prM1eses to operate

OOr:elobJectl

to the UCON Conditions

Does the request meets the specUied

conditions?

�j WID the

to theUcon Obligations

user agree on the specified obl1gations�

Fig 7: SNMP with UCON authorization process flow

Figure 7 shows the steps of the authorization process in SNMP with UCON implementation.

Authorization is granted to the manager after the following steps: (I) The manger's received request must be authenticated by

decrypting it and calculating the message digest by the USM module. I f either of them does not match, the connection is terminated immediately. Otherwise, the request will been authenticated and forwarded to the Access control (UCON) module.

(2) The UCON's rights/permissions is checked to ensure

that the manager has enough privileges to view/modify

46

the requested data in the requested way (read, write,

modify).

(3) The manager is then authorized by the UCON's authorization rules.

(4) Next, UCON checks the environmental and system changes that might affect the UCON's condition. Thus, affecting session establishment and maintenance. If the conditions are met, the message is forwarded to the UCON obligations process.

(5) Once conditions are met, both the manger and the agent must agree on some obligations in order to establish the session successfully. If the agent, or the manger, fails to fulfill or agree to these obligations, the sesston terminates. Figure 8 depicts this exchange.

SNMP manaaer SNMPAgent

(J -I-H"-"I 81 • iJlnglutKYOM'" IG§]�--I MIB

session established

UCON Oblioation Check

Valid reply

UCON Obligalion Check -

No/Invalid reply v

� session terminated

Fig 8: Authorization (During)

Obligations are checked not only during the session establishment, but it is also checked while the session is running .. As shown in figure 8, an agent, who is responsible for session maintenance, will have to ask the manager to perform the obligations periodically. If the manager fails to fulfill one or more of the obligations, the agent will terminate the session.

4.4. Security Analysis

In this section, we use three scenarios to analyze how better security is achieved when UCON is used with SNMP:

Scenario I: System abuse. UCON allows SNMP clients, or management station to control who can access them and when. This is done through the use of authorization before process (described in figure 6). This process relies on the UDF and UEF to decide on whether: (I) an SNMP manager is permitted to contact an SNMP agent at any given time, (2) SNMP agent can respond to an SNMP manager at any given time, and (3) an SNMP agent is permitted to access the MIPs. To accomplish this task, access rules can be dynamically updated on the policy server to allow the ADF to lookup these rules any time a request is made and makes a decision on whether an SNMP entity is authorized to access another SNMP entity (or object), or not, and sends a local notification to the AEF for the enforcement of such decision. In this case, the decision to allow session establishment depends upon the valid reply from the UCON to the SNMP entity that is requesting the service. This is done according to the information follow described in Figure 7.

Scenari02: protection against impersonation. We assume that an adversary gains "illegitimate" access to the system

and takes control over a host that's running an SNMP agent. Without the presence of UeON, the adversary could make the SNMP agent behave improperly, e.g., giving the agent the ability to manipulate the MIBs at well, or even allowing that agent to send sensitive information to the wrong place. However, this is not the case when using UeON, because UeON implements the reference monitor between the SNMP agent and the MIB. Thus, monitoring the traffic and mediating the agent's access to the MIB's objects. Therefore, when a compromised agent tries to reset the MIB's counters, the reference monitor can intercept the request sent by the compromised agent, and ask the ADF for a decision regarding that request. This process can deny the "unauthorized" host's access to the MIB and minimize the damage that can be caused by the adversary. This is done through the use of authorization during process (described in figure 8).

Scenari03: UeON allows SNMP to set some obligations that users agree to perform prior to establishing a connection. For example, a host "through it user" may agree to log certain types of information pertaining to a request "commands" that it receives. Through the obligation module, within the ADF, the SNMP can terminate the connection if that obligation was not fulfilled. This ensures that even if access was not authorized, it would be revoked immediately after not fulfilling the obligations. This is also accomplished through the use of authorization during process (described in figure 8).

Moreover, UeON has conditions module which can help in stopping a lot of attacks against the system. For example, it can stop a denial of service attacks "DOS attack" directed from a manager to an agent, and vice versa. If a manager was sending 2000 packet per second (assuming that the network threshold is 1000 pps), and using the monitoring module, the AEF would intercept the sending process and consult the ADF which will compare the sending rate to the present conditions. Once a condition is violated, the communication between the attacking manager and the agent will be terminated to protect the MIB.

5. CONCLUSION

In this paper we introduced a new concept of access control for controlling the access in the SNMP- managed environment. This concept is based on controlling usage of the various SNMP components. We have integrated this new concept with the SNMP protocol to produce new architecture that helps in controlling the access to the SNMP-based environment before, during, and after session establishments. In this work we have presented an extended architecture which integrates UeON with SNMP components in a manner that enables SNMP to support applications in ubiquitous environment more securely. We have presented few scenarios where we showed the necessary mapping between UeON components and that of SNMP. This work provided mainly architecture for applying UeON features to SNMP-based environment in the context of usage and access control. It also provided a set of security mechanisms for authorization and authentication algorithms.

47

For the future, we intend to extend this work e by providing an implementation of this architecture and assess its performance with regards to its benefits.

6. REFERENCES

[I] William Stallings. SNMPv3: A security enhancement for SNMP, Communications Surveys & Tutorials, IEEE Explorer. Volume: I, Issue: 1,1998.

121 A Corrente, L Tura. Security Performance Analysis of SNMPv3 With Respect to SNMPv2c, Network Operations and Management Symposium, 2004. NOMS 2004. IEEEIIFIP. Seoul, South Korea, August 2004

[3] Xiaolei Qian, "View-Based Access Control with High Assurance", Proceedings of the 1996 IEEE conference on Security and privacy, 6-8 May 1996, Oakland, CA , USA

[4] Network Security Essentials, Applications and Standards, by William Stallings, Prentice Hall. 2003.

[5] D. Mitton, M. StJohns, S. Barkley, D. Nelson, B. Patil, M. Stevens and B. Wolff, "Authentication, Authorization, and Accounting : Protocol Evaluation," RFC 3127, June 2001

[6] Jaehong Park and Ravi Sandhu. The UCONABc Usage Control Model. ACM Transaction on Information and System Security, Vol 7, No.1, February 2004, pages 128-174

[7] Jaehong Park and Ravi Sandhu. Towards Usage Control Models: Beyond Traditional Access Control. SACMAT02, June 3-4, 2002 Monterey, California, USA.

[8] Xinwen Zhang, Francesco Parisi-Presicce, Jaehong Park and Ravi Sandhu. Logical Model and Specification of Usage Control. ACM Transaction on Information and System Security, Vol 00, No. 00 2000,

[9] Roshan Thomas and Ravi Sandhu. Task-based authorization Control (TBAC): Models for Active and Enterprise-Oriented Authorization Management Database Security XI: Status and Prospects, North­Holland, Amsterdam, 1997.

[lO]ISO/IEC 10181-3, Information Technology-Open System Interconnection-Security framework for open systems: Access control, http://www.iso.org/