This presentation is based on the slides listed in references. SNMPv3 Network Management Spring 2014 Bahador Bakhshi CE & IT Department, Amirkabir University of Technology This presentation is based on the slides listed in references.

Outline Introduction SNMPv3 Architecture Abstract Service Interface Security Background User-based Security Model (USM) View-based Access Control Model (VACM) Message Format

Outline Introduction SNMPv3 Architecture Abstract Service Interface Security Background User-based Security Model (USM) View-based Access Control Model (VACM) Message Format

The Basic Ingredients of Network Management Previous Lectures: Functions & Integration Previous Lectures: NM Protocols Current Lecture: SNMPv3 agent Agent modules Security & Access control

Introduction SNMPv1 has both security and performance problems SNMPv2 was aimed to resolved the issues Most performance problems were solved, but SNMPv2c uses community based security method SNMPv3 provides the security solution Moreover, Modularization of document and architecture SNMP engine

SNMPv3 Design Goals Address the need for security set support Define an architecture to allow longevity of SNMP Modular design to allow for future extensions Keep SNMP as simple as possible (!!) Allow for minimal implementation Support also more complex features which are required in large networks Reuse existing specifications whenever possible

Outline Introduction SNMPv3 Architecture Abstract Service Interface Security Background User-based Security Model (USM) View-based Access Control Model (VACM) Message Format

SNMPv3 Architecture Similar to SNMPv1 and SNMPv2, architecture is distributed Interacting collection of SNMPv3 entities A SNMP entity implements a portion of the SNMP capabilities Manager capabilities vs. Agent capabilities It acts either as an agent or manager or both A collection of modules interacting with each other to provide services/capabilities

SNMPv3 Architecture Advantages: The role of SNMP entity is determined by the modules implemented in that entity Certain set of modules are required for agent, while a different set is required for a manager Application specific entities can be implemented Security subsystem provides services such as authentication and privacy of messages Multiple security models can coexist New security algorithms can be integrated

Components of SNMP Entity Each SNMP entity has a set of applications and a single SNMP engine The SNMP engine implements the required SNMP functions E.g. sending and receiving messages, authenticating, encrypting and decrypting messages and controlling access to managed objects, … These functions are provided as services to one or more applications configured with the SNMP engine in the SNMP entity

SNMPv3 Entity SNMP ENTITY SNMP APPLICATIONS OTHER SNMP ENGINE NOTIFICATION ORIGINATOR COMMAND RESPONDER GENERATOR RECEIVER PROXY FORWARDER SNMP APPLICATIONS SNMP ENGINE MESSAGE PROCESSING SUBSYSTEM DISPATCHER SECURITY ACCESS CONTROL SNMP ENTITY

SNMP Engine An SNMP engine provides services for Components sending and receiving messages authenticating and encrypting messages controlling access to managed objects Components a Dispatcher a Message Processing Subsystem a Security Subsystem an Access Control Subsystem

Dispatcher Interfaces with application modules, network, and message processing models Handles multiple versions of messages For backward compatibility OTHER NOTIFICATION ORIGINATOR COMMAND RESPONDER GENERATOR RECEIVER PROXY FORWARDER SNMP APPLICATIONS SNMP ENGINE MESSAGE PROCESSING SUBSYSTEM DISPATCHER SECURITY ACCESS CONTROL SNMP ENTITY Applications Network

Dispatcher (cont’d) Three components for three functions Transport mapper delivers messages over the transport protocol Message dispatcher routes messages between network and appropriate module of message processing subsystem PDU dispatcher handles messages between application and message processing subsystem There is only one dispatcher in an SNMP engine

Message Processing Subsystem Contains one or more Message Processing Models One Message Processing Model for each SNMP version SNMP version identified in the header Messages routed to corresponding processor by the dispatcher Prepares outgoing message Extracts data from incoming messages OTHER NOTIFICATION ORIGINATOR COMMAND RESPONDER GENERATOR RECEIVER PROXY FORWARDER SNMP APPLICATIONS SNMP ENGINE MESSAGE PROCESSING SUBSYSTEM DISPATCHER SECURITY ACCESS CONTROL SNMP ENTITY

Security & Access Control Subsystem Security at the message level Authentication Encryption: Privacy of message via secure communication Access control Who can access What can be accessed Flexible MIB views SNMP ENTITY SNMP APPLICATIONS COMMAND COMMAND NOTIFICATION NOTIFICATION PROXY OTHER GENERATOR RESPONDER ORIGINATOR RECEIVER FORWARDER OTHER SNMP ENGINE MESSAGE PROCESSING SECURITY ACCESS CONTROL DISPATCHER SUBSYSTEM SUBSYSTEM SUBSYSTEM

Incoming Message Flow in SNMP Engine Dispatcher receives a valid SNMPv3 message Dispatcher determines the version and forward the message to SNMPv3 Message Processing Model Message processor extract data from message and call Security subsystem Security subsystem decrypts and authenticates the message Dispatcher forward the PDU to the appropriate SNMP application

Out Going Message Flow in SNMP Engine ?

SNMPv3 Entity SNMP ENTITY SNMP APPLICATIONS OTHER SNMP ENGINE NOTIFICATION ORIGINATOR COMMAND RESPONDER GENERATOR RECEIVER PROXY FORWARDER SNMP APPLICATIONS SNMP ENGINE MESSAGE PROCESSING SUBSYSTEM DISPATCHER SECURITY ACCESS CONTROL SNMP ENTITY

SNMPv3 Applications Command Generator Command Responder Initiates SNMP GET, GETNEXT, GETBULK, SET requests Prepares the request message to be sent to the responder Command Responder Receives SNMP GET, GETNEXT, GETBULK, SET request messages Prepares a RESPONSE message to be sent to the request’s originator

SNMPv3 Applications (cont’d) Notification Originator Monitors the system for particular events or conditions and generates a trap and/or Inform Request message Notification Receiver Listens for Notification messages and generates response messages when a message containing an Inform PDU is received

SNMPv3 Applications (cont’d) Proxy Forwarder Acts as a proxy, forwards and translates requests, responses and notifications to other SNMP entities Other Special applications For example a vendor can implement vendor specific management features

SNMP Manager & Agent SNMP Manager SNMP Agent An SNMP entity containing one or more command generator and/or notification receiver applications (along with their associated SNMP engine) has traditionally been called an SNMP manager SNMP Agent An SNMP entity containing one or more command responder and/or notification originator applications (along with their associated SNMP engine) has traditionally been called an SNMP agent

SNMPv3 Manager Architecture NOTIFICATION RECEIVER COMMAND GENERATOR PDU DISPATCHER USER BASED SECURITY MODEL OTHER SECURITY SUBSYSTEM SNMPv1 SNMPv2C SNMPv3 MESSAGE PROCESSING SUBSYSTEM MESSAGE TRANSPORT MAPPINGS ORIGINATOR COMMUNITY BASED

SNMPv3 Agent Architecture MANAGEMENT INFORMATION BASE ACCESS CONTROL SUBSYSTEM COMMAND NOTIFICATION Proxy Forwarder VIEW BASED RESPONDER ORIGINATOR Applications ACCESS CONTROL PDU MESSAGE PROCESSING SECURITY SUBSYSTEM DISPATCHER SUBSYSTEM COMMUNITY BASED SNMPv1 SECURITY MODEL MESSAGE SNMPv2C USER BASED DISPATCHER SECURITY MODEL SNMPv3 OTHER TRANSPORT SECURITY MODEL OTHER MAPPINGS

SNMP Engine ID

Outline Introduction SNMPv3 Architecture Abstract Service Interface Security Background User-based Security Model (USM) View-based Access Control Model (VACM) Message Format

Abstract Service Interface Abstract service interface is a conceptual interface between modules Independent of implementation Defines a set of primitives used for interaction between two modules Primitives contain IN and OUT parameters and status information / result Primitives typically associated with receiving entities

Examples: Dispatcher Primitives Used by a command generator to send SNMP request or notification PDU to another SNMP entity The application also provides transport domain/address, message processing model, security model, level of security, and the PDU itself When successfully preparing the message by the Dispatcher: a sendPduHandle (unique identifier) is returned (to track any response, if any is expected)

Primitives Examples processPdu returnResponsePdu Used by Dispatcher to pass an incoming request or notification PDU to an application (command responder or notification receiver) returnResponsePdu Used by command responder to return an SNMP response in response to an incoming request or notification

Primitives Examples (cont’d) prepareOutgoingMessage Prepare a message for an outgoing SNMP request or notification PDU The IN parameter is a PDU and OUT parameter is the message

Primitives Examples (cont’d) prepareResponseMessage Request the preparation of a message containing an outgoing SNMP response PDU, in response to an incoming request or notification PDU

Primitives Examples: Security Subsystem generateRequestMessage Generate a “message” containing an outgoing SNMP request or notification PDU Returns to the MPS a message (with possibly authentication and encryption) and associated security parameters generateResponseMessage Generate a message containing outgoing SNMP response PDU in response to incoming request or notification Returns to the MPS a message (with some authentication and encryption applied) and associated security parameters processIncomingMessage Provide security function for incoming messages Return success or failure indicating the result of the security check If successful, a PDU is returned to the MPS

Abstract Service Interface in Action Example

Abstract Service Interface in Action Example

Outline Introduction SNMPv3 Architecture Abstract Service Interface Security Background User-based Security Model (USM) View-based Access Control Model (VACM) Message Format

Terminology Security goals & objectives Security threats What do we want? Security threats Why the goals is not achievable by default? Security mechanisms How to achieve the goals Basic mechanisms Typically cryptography algorithms Security protocols How to build a security system using the basic mechanism

Common Security Goals Authenticity Integrity Confidentiality Is the message sent from a valid user? Integrity Has the message been modified? Confidentiality Has the message been intercepted? Availability Is the service available for the user? Authorization Has user the right to access the requested object? ...

Common Security Threats Information Disclosure Violates Confidentiality Modification of messages Violates Integrity Masquerade & Replay & Man-in-Middle Violates Authenticity Denial of Service (DoS) Violates Service Availability Bypassing Access Controls Violates Authorization Traffic Analysis Traffic Pattern

Common Security Mechanisms Encryption and Decryption To protect confidentiality of information Standards: DES, AES, etc… Message Authentication Code (MAC and HMAC) To protect message integrity and verify message authenticity Standards: HMAC-96, SHA-1, MD5, etc… Nonce, timestamp (timeliness) Protect against replay attacks

SNMP Security Goals & Threats

SNMP Security Goal & Threats (cont’d) Unauthorized modification of information Some unauthorized entity may alter in-transit SNMP messages in such a way as to effect unauthorized management operations Masquerade Management operations not authorized for some principal may be attempted by assuming the identity of another principal that has the appropriate authorizations

SNMP Security Goal & Threats (cont’d) Message stream modification Messages may be maliciously re-ordered, delayed or replayed in order to effect unauthorized management operations Disclosure Eavesdropping on the exchanges between SNMP engine

SNMP Security Goal & Threats (cont’d) Denial of service attack and traffic analysis threats are out-of-scope and not covered DOS: Indeed, denial-of-service attacks network-wide attack that detecting & prevention mechanisms are independent of the management protocol Many traffic patterns are predictable - entities may be managed on a regular basis by a relatively small number of management stations - and therefore there is no significant advantage afforded by protecting against traffic analysis

Security Threats & Mechanisms in SNMPv3

Outline Introduction SNMPv3 Architecture Abstract Service Interface Security Background User-based Security Model (USM) View-based Access Control Model (VACM) Message Format

User-Based Security Model Based on traditional username/pass concept USM primitives across abstract service interfaces between MPU & USM Authentication service primitives authenticateOutgoingMsg authenticateIncomingMsg Privacy Services encryptData decryptData Timeliness

Security Services in SNMPv3

Authentication Module Security Subsystem Message Processing Model Authentication Module Privacy Timeliness Data Integrity Data Origin Authentication Data Confidentiality Message Timeliness & Limited Replay Protection

Authentication Module Data integrity message authentication at sender and validation at receiver Ensure that a message is not modified by an unauthorized intruder Authentication protocols: HMAC-MD5-96 / HMAC-SHA-96 Data origin authentication Check the identity of a user on whose behalf a message is sent Append to the message a unique Identifier associated with authoritative SNMP engine

Authentication and Integrity Protection

Privacy Module Data confidentiality ensures that data is not made available to unauthorized users or entities Encryption is applied at the sender and decryption at receiver (CBC-DES) Security Subsystem Message Processing Model Authentication Module Privacy Timeliness Data Integrity Data Origin Authentication Data Confidentiality Message Timeliness & Limited Replay Protection

Encryption (DES)

Timeliness Module Prevent message redirection, delay and replay Configure a receiver window for accepting message Three objects: snmpEngineID, snmpEngineBoots, snmpEngineTime Security Subsystem Message Processing Model Authentication Module Privacy Timeliness Data Integrity Data Origin Authentication Data Confidentiality Message Timeliness & Limited Replay Protection

Replay Protection Limited protection: If a messages is replied but falls in the window, it will be accepted; i.e., no protection against reordering

Security Parameters

Securing Outgoing Message Retrieve user information YES Privacy Required? Encrypt scopedPDU set msgPrivacyParamters NO msgPrivacyParamters  NULL YES Compute MAC set msgAuthentParamters Authent. Required? NO msgAuthentParamters  NULL Message Transmission

Securing Outgoing Message

Secure Incoming Message Security level Security model Security name…. Retrieve msg parameters YES Authent. Required? Compute MAC & Check it msgAuthentParamters NO Determine if msg is within time window Timeliness check YES Privacy Required? Encrypt scopedPDU set msgPrivacyParamters Decrypt scopedPDU NO Message reception

Secure Incoming Message

Key Management Authentication and Encryption need keys Key management is an important issue in all security protocols How to generate keys? How two entities exchange keys securely Where to store keys (if needed?) Issues affecting key management in SNMP Agents should be simple! A manager typically manages many agents It is possible to have multiple managers in a network A NMS is used by multiple administrators

SNMP Key Management Approaches App. 1) Similar to other common security protocols (e.g., SSL, IPsec, …), Keys are generated per session using the public key encryption algorithm (e.g., RSA) of Key-Exchange algorithm (e.g., Diffie-Hellman) Each entity has a (public, private) key pair Session key is encrypted by other side’s public key Which is decrypted only by the associative private key Is not used in SNMP because the algorithms are computationally heavy Agents cannot (i.e., device vendors do not want to) implement the algorithms

SNMP Key Management Approaches App. 2) Keys per agent are generated during agent initial configuration & are stored in both agents and NMS Advantage: No computation & network overhead for key exchange per session Disadvantage: If NMS is compromised  The attacker knows all keys of all agent  Whole network is compromised! So, do NOT store keys in NMS/agent

SNMP Key Management Approaches App. 3) Keys per user are generated during agent initial configuration. User (operator/administrator) has to remember the keys Advantage: keys are not stored in NMS If NMS is compromised  All agents are safe Disadvantage: How can user remember keys of 100 agents? (S)He cannot  Use the same keys  If an agent is compromised  whole network is compromise!!! So, user can/should NOT remember keys! do NOT use the same keys!

Key Management in SNMPv3 Users need to remember only one (username, password) pair for themselves (why?) Keys should be agent dependent (why?) Keys should be user dependent (why?) Agents should generate keys only one time (why?) Keys are stored in agents Keys should not be stored in NMS (why?) NMS should generate keys per session  Key are generated using Password & Engine ID

Key Management: Step 1 Password to key generation 1) 2) Repeat the password to generate 2^20 bytes  digest0 2) digest1 = Hash (digest0) digest1 is 16-octet (MD-5) or 20-octet (SHA-1)  authKey is digest1 NOTE: A single password can be used (authKey and privKey are the same) or 2 passwords for 2 different keys

Key Management: Step 2 password Localized keys are initially Take Hash of user key and Remote Engine ID Localized Key digest2 Take Hash of user key and Remote Engine ID Localized key password Take Hash of expanded password string User Key (digest1) Take Hash of user key and Remote Engine ID Localized keys are initially configured in a secure way (could be manual!) Localized key

Key Localization A localized key is a secret key shared between a user and a SNMP engine Hence, a user can communicate with many agents but maintains only one password Agent 1 Agent 2 User 1 (authKey1_1, privKey1_1) User 3 (authKey2_1, privKey2_1) User 2 (authKey1_2, privKey1_2) User 4 (authKey2_4, privKey2_4) If this agent compromised, only its keys are compromised. Other agents are safe. If compromised, other keys are not!

SNMPv3 Key Management Advantages Greatly slow down a brute-force dictionary attack Clear text  A dictionary attack to find hash collision SNMPv3 key  Two times to compute hash (password  key  Message) Keys are not stored in NMS Key is regenerated every time that is needed If NMS is compromised  No key  Safe agents One password for an operator in a network Easy to handle/manage password Agent (EngineID) dependent If an agent is compromised  Other agents are safe

Outline Introduction SNMPv3 Architecture Abstract Service Interface Security Background User-based Security Model (USM) View-based Access Control Model (VACM) Message Format

SNMPv3 VACM Checking whether a specific type of access (read, write, notify) from a user using a given security mechanism to a particular object is allowed Information about access rights and policies is in engine's Local Configuration Datastore (LCD) The elements of the VACM model are: Groups: set of <security model , security name> Security level: (no) authentication – (no) privacy Contexts: Collection of accessible mgmt. info. MIB views: Sub-tree in MIT Access policy: read/write permissions

SNMPv3 VACM: Groups Groups: A set <securityModel, securityName> tuples 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 The combination <securityModel, securityName> belongs only to one group; e.g. ConfigGroup: <SNMPv3, A> & <SNMPv3, B> MonitorGroup: <SNMPv1, A> & <SNMPv2c, C>

SNMPv3 VACM: Security Level The level of security of current request 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

SNMPv3 VACM: MIB Views 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

SNMPv3 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 E.g., MPLS context contains the MIB views related to managing MPLS VPNs The VACM defines a vacmContextTable that lists the locally available contexts by contextName

SNMPv3 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

VACM Process

VACM in Action Who calls the Access Control Subsystem? 1) When an SNMP Get, Get-Next, Get-Bulk, or Set PDU is being processed, the Access Control Subsystem needs to be called to make sure the MIB objects specified within the variable bindings are allowed to be accessed 2) When a Notification is being generated, the Access Control Subsystem needs to be called to make sure the MIB objects specified for the variable bindings are allowed to be accessed.

Outline Introduction SNMPv3 Architecture Abstract Service Interface Security Background User-based Security Model (USM) View-based Access Control Model (VACM) Message Format

SNMPv3 Message Format Time synch. between entities to avoid reportableFlag privFlag authFlag Message ID Max. Size Flag Security Model Header Data Context Engine ID Name Data scopedPDU 1 SNMPv1 2 SNMPv2 3 SNMPv3 Global/ Security Plaintext / Encrypted Version Header Whole Message Parameters scopedPDU Data Data Authoritative Engine ID Engine Boots Engine Time User Name Authentication Parameters Privacy Security Parameters Time synch. between entities to avoid message replay and achieve timeliness

SNMPv3 Message Format

SNMPv3 Message Format: Applications

Outline Introduction SNMPv3 Architecture Abstract Service Interface Security Background User-based Security Model (USM) View-based Access Control Model (VACM) Message Format

SNMPv3 Summary The most complex version of SNMP Not so simple anymore! Concern: complexity may impede deployment! Address major security issues Confidentiality, Integrity, Authenticity, Timeliness Well defined modular architecture with the use of abstract service interface Coexistence with previous versions is assured with proxy forwarder application

References Reading Assignment: Chapter 7 of “Mani Subramanian,  ‘Network Management: Principles and Practice’, Pearson Education, 2012” R. Dssouli, “Advanced Network Management,” Concordia Institute for Information Systems Engineering, http://users.encs.concordia.ca/~dssouli/INSE 7120.html Nhut Nguyen, “Telecommunications Network Management,” University of Texas at Dallas, www.utdallas.edu/~nhutnn/cs6368/ J. Won-Ki Hong, “Network Management System,” PosTech University, dpnm.postech.ac.kr/cs607/