In the Name of the Most High SNMPv

In the Name of the Most High SNMPv 3 by Behzad Akbari Fall 2011 These slides are based in parts upon slides of Prof. Dssouli (Concordia university) 1

Key Features of SNMPv 3 q Modularization of documentation and architecture q q SNMP engine defined q q Enables the use of SNMPv 1 and SNMPv 2 with the newly developed SNMPv 3. – A model for the processing of SNMP messages. New Security features q q – Secure information to prevent tampering of data – Access control to determine proper access to MIB. 2

Documentation 3

SNMP Architecture q q Distributed, interacting collection of SNMP entities SNMP entity implements a portion of the SNMP capability: q q It acts either as an agent or manager or both A collection of modules interacting with each other to provide services SNMP ENTITY SNMP APPLICATIONS COMMAND GENERATOR COMMAND RESPONDER NOTIFICATION ORIGINATOR NOTIFICATION RECEIVER PROXY FORWARDER OTHER SNMP ENGINE DISPATCHER MESSAGE PROCESSING SUBSYSTEM SECURITY SUBSYSTEM ACCESS CONTROL SUBSYSTEM

SNMP Architecture Advantages: q The role of SNMP entity is determined by the modules implemented in that entity o q Security subsystem provides services such as authentication and privacy of messages o q Certain set of modules are required for agent, while a different set is required for a manager Multiple security models can coexist Set of authorization services an application can use for checking access rights o Access Control

SNMP Architecture-Manager COMMAND GENERATOR PDU DISPATCHER NOTIFICATION RECEIVER MESSAGE PROCESSING SUBSYSTEM SNMPv 1 MESSAGE DISPATCHER SNMPv 2 C NOTIFICATION ORIGINATOR SECURITY SUBSYSTEM COMMUNITY BASED SECURITY MODEL USER BASED SECURITY MODEL SNMPv 3 TRANSPORT MAPPINGS OTHER SECURITY MODEL

SNMPv 3 Architecture-Manager q q Command Generator Application o Monitor and manipulate management data at remote agents o Make use of SNMPv 1, v 2 PDUs: Get, Get. Next, Get. Bulk, etc. Notification Originator Application q Initiates messages, such as Inform. Request PDU Notification Receiver Application o Receive messages from other managers or agents o Inform. Request, SNMPv 1 - and SNMPv 2 -Traps, etc… These applications make use of the services provided by the SNMP engine: o Get Outgoing PDUs, process them and generates SNMP messages for transmission over the transport layer o Accept incoming SNMP messages, process them, and extracts PDUs and passes them to appropriate SNMP application

SNMPv 3 Architecture-Manager SNMP Engine (identified by snmp. Engine. ID) Dispatcher q Security Subsystem One dispatcher in an SNMP engine o o o q Message Processing Subsystem Accepts PDUs from applications Handles multiple version messages (SNMPv 1, v 2, v 3) Interfaces with application modules, network, and message processing models Three components for three functions q Transport mapper delivers messages over the transport protocol q Routes messages between network and appropriate module of MPS q PDU dispatcher handles messages between application and MPS

SNMPv 3 Architecture-Manager SNMP Engine (identified by snmp. Engine. ID) Dispatcher Message Processing Subsystem Security Subsystem q Accepts outgoing PDUs from Dispatcher, attach appropriate header, and return message to Dispatcher q Accepts incoming messages, process each message header, and return the enclosed PDU to the Dispatcher q Contains one or more Message Processing Models, each for each SNMP version q SNMP version identified in the header

SNMPv 3 Architecture-Manager SNMP Engine (identified by snmp. Engine. ID) Dispatcher q q q Message Processing Subsystem Security subsystems perform authentication and encryption functions for each outgoing/incoming message Outgoing PDUs may be encrypted and authentication codes generated and appended to the message header o The message is then returned to the MPS Incoming messages are passed to the security subsystem o Message decryption o Messages authenticated

SNMPv 3 Architecture-Agent MANAGEMENT INFORMATION BASE ACCESS CONTROL SUBSYSTEM COMMAND RESPONDER PDU DISPATCHER VIEW BASED ACCESS CONTROL MESSAGE PROCESSING SUBSYSTEM SNMPv 1 MESSAGE DISPATCHER SNMPv 2 C NOTIFICATION ORIGINATOR Proxy Forwarder Applications SECURITY SUBSYSTEM COMMUNITY BASED SECURITY MODEL USER BASED SECURITY MODEL SNMPv 3 TRANSPORT MAPPINGS OTHER SECURITY MODEL

SNMPv 3 Architecture-Agent q Command Responder Application o Provides access to management data o Responds to incoming requests by retrieving and/or setting managed objects and issuing Response PDU q Notification Originator Application o e. g. , SNMPv 1, v 2 Trap PDU q Proxy Forwarder Application o Forwards messages between entities q Access Control Subsystem o Provides authorization services to “control access” to the MIB for reading and setting management objects o Who can access o What can be accessed

Terminology SNMP Engine ID snmp. Engine. ID -- associated with each SNMP entity Principal principal Security Name Context Engine ID -- person or group or application requesting services security. Name -- human readable name context. Engine. ID -- each entity has a unique context ID (identical to snmp. Engine. ID) Context Name context. Name --a context associated with a managed object (for access control) An SNMP agent can monitor more than one network element (context) Example: n n SNMP Engine ID Principal Security Name IP address John Smith Administrator

snmp. Engine. ID

Abstract Service Interfaces q Abstract service interface is a conceptual interface between modules, independent of implementation q Defines a set of primitives o A primitive specifies the function to be performed (e. g. , procedural call) q Primitives associated with receiving entities o An interface defined using primitive and parameters is referred to as “abstract service interface” q e. g. , Dispatcher primitives: o Handle messages to and from applications o registering and un-registering of application modules o transmitting to and receiving messages from network q IN and OUT parameters q Status information / result

send. Pdu Command Generator send. Pdu q q q send. Pdu. Handle/ Error Indication Abstract Service Interface Dispatcher prepare. Outgoing. Message Dispatcher Primitives Message Processing Model Abstract Service Interface Used by a command generator to send SNMP request or notification PDU to another SNMP entity When successfully preparing the message by the Dispatcher: a send. Pdu. Handle (unique identifier) is returned (to track any response, if any is expected) The application also provides transport domain/address for the PDU as well as message processing model, security model, principal, level of security, the context for this PDU, and the PDU itself

send. Pdu Command Generator send. Pdu. Handle/ error. Indication process. Response. Pdu Dispatcher prepare. Outgoing. Message Dispatcher Primitives Message Processing Model Abstract Service Interface process. Response. Pdu q q Used by Dispatcher to pass an incoming response PDU to an application The application checks whether it is matched with a preceding request or notification PDU by checking the send. Pdu. Handle: q Success or failure

return. Response. Pdu Command Responder Dispatcher process. Pdu q q prepare. Response. Message Dispatcher Primitives Message Processing Model Abstract Service Interface Used by Dispatcher to pass an incoming request or notification PDU to an application (command responder) Security related information is required to generate a matching response message q The security subsystem (access control) will check whether access is allowed and a response will be generated accordingly return. Response. Pdu q Used by command responder to return an SNMP response in response to an incoming request or notification

send. Pdu Command Generator send. Pdu. Handle/ error. Indication Dispatcher prepare. Outgoing. Message Processing Subsystem Primitives Message Processing Model Abstract Service Interface prepare. Outgoing. Message q q q Prepare a message for an outgoing SNMP request or notification PDU The IN parameter is a PDU and OUT parameter is the message Success or failure is returned

return. Response. Pdu Command Responder Dispatcher process. Pdu prepare. Response. Message Processing Subsystem Primitives Message Processing Model Abstract Service Interface prepare. Response. Message q Request the preparation of a message containing an outgoing SNMP response PDU, in response to an incoming request or notification PDU

Security Subsystem Primitives generate. Request. Message q q 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 process. Incoming. Message q q q 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 generate. Response. Message q q 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

Applications Application(s) Command Generator Notification Receiver Proxy Forwarder Subsystem Command Responder Notification Originator Other Application • Command generator • Command responder • Notification originator • Notification receiver • Proxy Forwarder (SNMP versions only) • Other Example get-request get-response trap generation trap processing get-bulk to get-next Special application 22

Command Generator: 1)-Examine parameters from the received PDU and match/compare them with a cached copy (security model/level/name, context. Name, etc. ). If no match, message is discarded 2)-Check the received PDU (check request-id, etc. ) 3)- if all OK, then take action

Command Responder: 1)-examines content of request PDU. Check whether object has already registered with the responder 2)- is. Access. Allowed primitive is invoked (to determine whether object can be accessed by the principal making the request) check the security level 3)- if access permitted, prepare a response.

Scenario Diagrams

Scenario Diagrams

Scenario Diagrams

Scenario Diagrams

Scenario Diagrams

Scenario Diagrams

Scenario Diagrams

Scenario Diagrams

Scenario Diagrams

Scenario Diagrams

Scenario Diagrams

Scenario Diagrams

Scenario Diagrams

Scenario Diagrams

Scenario Diagrams

Scenario Diagrams

Message Format reportable. Flag priv. Flag auth. Flag Header Data Message ID Message Max. Size Message Flag Version scoped. PDU Message Security Model Global/ Header Data 1 SNMPv 1 2 SNMPv 2 3 SNMPv 3 Security Parameters Context Engine ID Plaintext / Encrypted scoped. PDU Data Context Name Whole Message Security Parameters Authoritative Engine ID Authoritative Engine Boots Authoritative Engine Time synch. between entities to avoid message replay and achieve timeliness User Name Authentication Parameters Data Privacy Parameters

Message Format

See p. 304 43

Security Threats Modification of Information q an entity may alter in-transit SNMP messages generated on behalf of an authorized principal in such a way as to effect unauthorized management operations, including falsifying the value of an object Masquerade q management operations not authorized for some entity may be attempted by assuming the identity of another entity that has the appropriate authorizations Modification of information Masquerade Message stream modification Management Entity A Management Entity B Disclosure

Security Threats Message Stream Modification q SNMP is typically based upon a connectionless transport service. Messages may be maliciously reordered, delayed or replayed, in order to effect unauthorized management operations. o For example, a message to reboot a system could be copied and replayed later Disclosure q Eavesdropping or intercepting on the exchanges between SNMP engines Modification of information Masquerade Message stream modification Management Entity A Management Entity B Disclosure

Security Threats SNMPv 3 is not intended to secure against these two threats: Denial of Service: q An attacker may prevent exchanges between manager and agent q q DOS are indistinguishable from network element failures DOS may disrupt all services (not just those pertaining to NM) Modification of information Masquerade Message stream modification Management Entity A Management Entity B Disclosure Traffic Analysis: q An attacker may observe the general pattern of traffic between managers and agents

Security Model Goals o Data Integrity (Authentication) o Authentication o Message redirection/re-ordering/delay/replay o Data encryption/decryption

Security Model Security Subsystem Data Integrity Data Origin Authentication Message Processing Model Authentication Module Data Confidentiality Privacy Module Message Timeliness & Limited Replay Protection Timeliness Module q The Security model authenticates and forwards incoming and outgoing messages to the MPM q 3 different modules o Authentication module o Privacy module o Timeliness module

Authentication Module Security Subsystem Data Integrity Data Origin Authentication Message Processing Model q Data Confidentiality Privacy Module Message Timeliness & Limited Replay Protection Timeliness Module Data integrity o o o q Authentication Module message authentication at sender and validation at receiver Ensure that a message is not modified by an unauthorized intruder Authentication protocols: HMAC-MD 5 -96 / HMAC-SHA-96 Data origin authentication o o 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

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

Timeliness Module Security Subsystem Data Integrity Data Origin Authentication Message Processing Model Data Confidentiality Message Timeliness & Limited Replay Protection Authentication Module Privacy Module Timeliness Module q Prevent message redirection, delay and replay q Configure a receiver window for accepting message (e. g. , 150 s for SNMPv 3) q Three objects: snmp. Engine. IP, snmp. Engine. Boots, snmp. Engine. Time

Authoritative vs. non-authoritative engine q Responsibility of Authoritative engine o Unique SNMP engine ID o Time-stamp (a clock maintained by the authoritative engine) q Non-authoritative engine should keep a table of the time-stamp and authoritative engine ID o Synchronize its clock with regard to that of the authoritative engine Non-Authoritative Engine (NMS) Authoritative Engine (Agent)

User-based Security Model (USM) q USM primitives across abstract service interfaces o Authentication service primitives o o o authenticate. Outgoing. Msg authenticate. Incoming. Msg Privacy Services o o encrypt. Data // outgoing PDU decrypt. Data // incoming PDU

User-based Security Model (USM) Security Subsystem MPM Information Header data Security data scoped. PDU User-based Security Model Encryption key scoped. PDU Privacy parameters Privacy Module Encrypted scoped. PDU Message Processing Model (Authenticated/encrypted) whole message Whole message length Authentication key Whole Message Authenticated Whole Message Security Parameters Privacy and Authentication Service for Outgoing Message Authentication Module

User-based Security Model (USM) Security Subsystem MPM Information Header data Security data scoped. PDU User-based Security Model Encryption key scoped. PDU Privacy Module Privacy parameters Encrypted scoped. PDU Message Processing Model (Authenticated/encrypted) whole message Whole message length Authentication key Whole Message Authenticated Whole Message Authentication Module Security Parameters q USM invokes privacy module w/ encryption key and scoped. PDU q Privacy module returns privacy parameters and encrypted scoped. PDU q USM then invokes the authentication module w/authentication key and whole message and receives authenticated whole message

User-based Security Model (USM) Security Subsystem MPM Information Header data Security parameters whole message Authentication key User-based Security Model Whole Message (as received from network) Authentication parameters Authentication Module Authenticated Whole Message Processing Model Decrypt key Encrypted PDU (Decrypted) scoped. PDU Privacy parameters Privacy Module Decrypted scoped. PDU Processing secure incoming message reverse of secure outgoing message q Authentication validation done first by the authentication module q Decryption of the message done then by the privacy module q

User-based Security Model (USM) q q q msg. User. Name: user or a principal on whose behalf the message is being exchanged msg. Authentication. Parameters: defined by authentication protocol msg. Privacy. Parameters: type of privacy protocol used

SNMPv 3 -Next! q q q Background and security threats SNMPv 3 Architecture SNMPv 3 Applications Message Format User-based Security Model (USM) q q q USM Timeliness Mechanism Cryptographic Functions USM Message Processing Discovery Key Management

USM Timeliness Mechanism Management of authoritative clocks q All authoritative engines must maintain two objects: o o q q q snmp. Engine. Boots snmp. Engine. Time Initially, both are set to 0 snmp. Engine. Time is incremented once per second snmp. Engine. Boots is incremented if the system has rebooted or if snmp. Engine. Time reaches its maximum value (231 -1)

USM Timeliness Mechanism Synchronization q q A non-authoritative engine must remain loosely synchronized with each authoritative engine with which it communicates A non-authoritative engine keeps a local copy of 3 variables for each authoritative engine: snmp. Engine. Boots: o o o o Most recent value of snmp. Engine. Boots for the remote authoritative engine snmp. Engine. Time: Synchronized to the authoritative engine. Between synch events, it is incremented once per second to maintain loose synch latest. Received. Engine. Time: Highest value of msg. Authoritative. Engine. Time. o It protects against a replay message attack These values are stored in a cache indexed by snmp. Engine. ID

USM Timeliness Mechanism Synchronization (cont’d) authoritative non-authoritative msg. Authoritative. Engine. Boots, msg. Athoritative. Engine. Time, msg. Athoritative. Engine. ID If message is authentic non auth. updates its local variables according to this rule: (msg. Authoritative. Engine. Boots > snmp. Engine. Boots) OR [(msg. Authoritative. Engine. Boots = snmp. Engine. Boots) AND (msg. Authoritative. Engine. Time > latest. Received. Engine. Time)] If two messages arrive out of order or a replay attack is underway!

USM Timeliness Mechanism Synchronization (cont’d) q If an update is called for, then snmp. Engine. Boots : = msg. Authoritative. Engine. Boots snmp. Engine. Time : = msg. Authoritative. Engine. Time latest. Received. Engine. Time : = msg. Authoritative. Engine. Time q If (msg. Authoritative. Engine. Boots < snmp. Engine. Boots) then no update occurs [Message not authentic to be discarded] q If [(msg. Authoritative. Engine. Boots = snmp. Engine. Boots) AND (msg. Authoritative. Engine. Time < latest. Received. Engine. Time)] then no update occurs [Message may be authentic but may be misordered Update of snmp. Engine. Time is not warranted]

USM Timeliness Mechanism Timeliness checking by authoritative receiver q Ensure that messages are received within a reasonable time window (avoid delays and replays) q q q Too small time window authentic messages may be considered as unauthentic Too large increase vulnerability for attacks Incoming message is considered outside the time window if the following is true : snmp. Engine. Boots = (231 -1) OR msg. Authoritative. Engine. Boots snmp. Engine. Boots OR The value of msg. Authoritative. Engine. Time differs from that of snmp. Engine. Time by more than ± 150 seconds. message is considered not authentic (discarded and error message returned)

USM Timeliness Mechanism Timeliness checking by non-authoritative receiver q Incoming message is considered outside the time window if the following is true: snmp. Engine. Boots = (231 -1) OR msg. Authoritative. Engine. Boots < snmp. Engine. Boots OR [(msg. Authoritative. Engine. Boots = snmp. Engine. Boots) AND msg. Authoritative. Engine. Time < snmp. Engine. Time – 150] NOTE: msg. Authoritative. Engine. Boots > snmp. Engine. Boots is allowed

Cryptographic Functions-Authentication 2 functions defined by USM q q q authentication: auth. Key encryption: priv. Key auth. Key and priv. Key are derived from the password and are not accessible via SNMP 1 - Authentication q Two authentication protocols o o q HMAC: message authentication code generation from auth. Key q q HMAC-MD 5 -96 (Message Digest) HMAC-SHA 1 -96 (Secure Hash Algorithm) A 96 -bit MAC code generated and inserted in msg. Authentication. Parameters field of the message MD-5 (16 -octet) and SHA 1 (20 -octet) are the underlying hash functions

Cryptographic Functions-Authentication n Procedure: n n 1. Derive extended. Auth. Key: Supplement auth. Key with 0 s to get 64 -byte string n n n 2. Define ipad, opad, K 1, and K 2: ipad = 0 x 36 (00110110) repeated 64 times opad = 0 x 5 c (01011100) repeated 64 times K 1 = extended. Auth. Key XOR ipad K 2 = extended. Auth. Key XOR opad n n 3. Derive HMAC by hashing algorithm used HMAC = H (K 2, H (K 1, whole. Msg)) n Depending on whether MD-5 or SHA-1 is used, the algorithm produces a 16 (MD-5) or 20 (SHA-1)-octet length output which is truncated to produce a 12 -octet MAC

HMAC Structure 67

Cryptographic Functions-Authentication

To authenticate KEY DATA KEY HASH FUNCTION DATA HASH FUNCTION MAC =? USER MAC sender DATA USER MAC receiver DATA

Cryptographic Functions-Encryption 2 - Encryption and decryption of scoped PDU (context engine ID, context name, and PDU) q CBC - DES (Cipher Block Chaining - Data Encryption Standard) symmetric protocol o o 16 octet priv. Key (derived from password, similar to auth. Key ) is used as input to encryption protocol First 8 octets of priv. Key are used as DES key (only 56 bits LSB of each octet is ignored)

Cryptographic Functions-Encryption q CBC Mode o o Last 8 -octet of priv. Key used as preinitialization vector (pre-IV) Generate salt value (8 octets): <snmp. Egine. Boots || local value> Initialization vector: IV = salt XOR pre-IV o Local value: 4 -octet integer, implementation dependent, modified after each use. Transmit salt in msg. Privacy. Parameters so that receiver can recover the IV

Cryptographic Functions-Encryption P 1 P 2 Pn IV Cn-1 k DES Encrypt C 2 Encryption Data is divided into blocks of 64 bits each. K is shared between sender and receiver k DES Encrypt Cn

Cryptographic Functions-Encryption C 1 k DES Decrypt C 2 k DES Decrypt Cn k DES Decrypt IV Cn-1 P 2 Decryption IV at the receiver is generated from the salt that is transmitted in the message Pn

USM Message Processing Retrieve user information Privacy Required? Security name of principal Auth. snmp. Engine. ID Determine security level … YES Encrypt scoped. PDU set msg. Privacy. Paramters NO msg. Privacy. Paramters NULL Authent. Required? YES NO msg. Authent. Paramters NULL Message Transmission Compute MAC set msg. Authent. Paramters

USM Message Processing security level Security model Security name…. Retrieve msg parameters Authent. Required? YES NO Privacy Required? Compute MAC msg. Authent. Paramters Determine if msg is within time window YES NO Message reception Encrypt Decrypt scoped. PDU set msg. Privacy. Paramters Time synch. Timeliness check

Discovery q The non-authoritative engine sends a Request message: security. Level = no. Authno. Priv msg. User. Name = “initial” msg. Authoritative. Engine. ID = null var. Bind. List = null q The authoritative engine responds with: msg. Authoritative. Engine. ID = snmp. Engine. ID (its own) q If authenticated communication is required o o The non-authoritative engine establishes time synchronization with the authoritative engine Authoritative engine sends an Report message with its current values: msg. Authoritative. Engine. Boots = snmp. Engine. Boots msg. Authoritative. Engine. Time = snmp. Engine. Time

Key Management q q q Authentication and privacy keys are required A principal (i. e. , NMS) should deploy or use only one auth. key and one priv. key. Keys are stored for the user’s password q q Password: human readable, not easy guessed Keys are not accessible via SNMP and are not stored in the MIB Password to key generation 1)- Repeat the psswd to generate 220 bytes digest 0 2)digest 1 = Hash (digest 0) digest 1 is 16 -octet (MD-5) or 20 octet (SHA-1) auth. Key is digest 1 NOTE : : A single password can be used (auth. Key and priv. Key are the same) or 2 passwords for 2 different keys

Key Localization q A localized key is a secret key shared between a user and one authoritative SNMP Engine q Hence, a user can communicate with many agents but maintains only one key (i. e. , only one password) Agent 1 Agent 2 User 1 (auth. Key 1_1, priv. Key 1_1) User 1 (auth. Key 2_1, priv. Key 2_1) User 2 (auth. Key 1_2, priv. Key 1_2) User 4 (auth. Key 2_4, priv. Key 2_4) If compromised, other keys are not! If this agent compromised, only its keys are compromised. Other agents are safe.

Generating localized Keys Take Hash of user key and Remote Engine ID password Take Hash of expanded password string Take Hash of user key and Remote Engine ID Localized Key digest 2 Localized key User Key (digest 1) Localized keys are initially configured in a secure way ( could be manual!) Take Hash of user key and Remote Engine ID Localized key

Key Update To enhance security, Keys are to be updated from time to time: key. Old key. New Requestor: 1)- Generate random 2)- Compute: digest = Hash ( key. Old || random ) 3)- delta = digest XOR key. New 4)- protocol. Key. Change = ( random || delta) Send a message set. Request ( protocol. Key. Change ) Receiver: 1)- compute digest = Hash( key. Old || random) 2)- compute key. New = digest XOR delta NOTE: digest XOR delta = digest XOR (digest XOR key. New) = key. New Since an attacker does not know key. Old, the update of the key is safe

Access Control q q q Agent can validate sending sources and their access privilege for command requests. Step following Authentication Maintain a local database contains access rights and policies MIB VIEW Allowed Operations Allowed managers Required Level of Security Interface Table SET John Authentication, Encryption Interface Table GET/GETNEXT John, Paul Authentication Systems Group GET/GETNEXT Georges None

Access Control (read, write, or send notification)