1. 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.

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

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

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

5. 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

6. 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

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

8. 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

9. 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

10. 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

11. 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

12. 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

13. 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

14. 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

15. 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

16. 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

17. 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

18. Out Going Message Flow in SNMP Engine?

19. 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

20. 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

21. 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

22. 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

23. 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

24. 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

25. 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

26. SNMP Engine ID

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

28. 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

29. 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)

30. 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

31. 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

32. 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

33. 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

34. Abstract Service Interface in Action Example

35. Abstract Service Interface in Action Example

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

37. 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

38. 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?
...

39. 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

40. 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

41. SNMP Security Goals & Threats

42. 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

43. 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

44. 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

45. Security Threats & Mechanisms in SNMPv3

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

47. 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

48. Security Services in SNMPv3

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

50. 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

51. Authentication and Integrity Protection

52. 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

53. Encryption (DES)

54. 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

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

56. Security Parameters

57. 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

58. Securing Outgoing Message

59. 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

60. Secure Incoming Message

61. 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

62. 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

63. 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

64. 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!

65. 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

66. 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

67. 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

68. 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!

69. 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

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

71. 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

72. 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>

73. 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

74. 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

75. 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

76. 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

77. VACM Process

78. 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.

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

80. 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

81. SNMPv3 Message Format

82. SNMPv3 Message Format: Applications

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

84. 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

85. 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, html
Nhut Nguyen, “Telecommunications Network Management,” University of Texas at Dallas,
J. Won-Ki Hong, “Network Management System,” PosTech University, dpnm.postech.ac.kr/cs607/