Lecture 7:

SNMPv3

Chapter 7: SNMP Management: SNMPv3 Chapter 3: SNMPv3

Network Management: Principles and Practice O'Reilly, Essential SNMP
© Mani Subramanian 2000
1
 Outline
▪ 0. Why SNMPv3 ?
▪ I. SNMPv3 Key Features
▪ II. SNMPv3 Architecture
▪ III. SNMPv3 Application
▪ IV. SNMPv3 MIB
▪ V. SNMPv3 Security
▪ VI. SNMPv3 User-based Security Model
▪ VII. Access Control

2
 0. Why SNMPv3
SNMPv1 and SNMPv2c message format
SNMPv1/SNMPv2c Message {
version snmpv1=0 snmpv2c=1
community STRING
PDU (operation) {
request-id INTEGER
error-status INTEGER
error-index INTEGER
variable-bindings {
OID, VALUE
…
}
}
}
SNMP v2c (Community Network-Based Simple Protocol)
2 based on RFC 1901 - RFC 1908

3
 SNMP Agent
Community (public, private)
READ- READ-
SNMP Access Mode
ONLY WRITE

not-accessible read-only write-only read-write MIB Access

Object 1 Object 2 Object 3 Object 4

SNMP MIB View

Figure 5.2 SNMP Community Profile

https://woshub.com/install-configure-snmp-service-windows/

4
SNMPv1 and SNMPv2c problems

◼ Community strings for authentication

== Clear Text Passwords

◼ Community strings also used for “context”

❑ Accessing data in a certain “context” is difficult

◼ No Standardized Method for Access Control

❑ No consistent method to configure communities across a network
of many devices.
❑ Most were devices manually configured, or worse, left with their
default settings intact.
◼ kingdom keys:“public”, “private”

5
SNMPv1 example:
% snmpget -d -v 1 -c public localhost sysUpTime.0

Sending 43 bytes to 127.0.0.1

0000: 30 29 02 01 00 04 06 70 75 62 6C 69 63 A0 1C 02 0).....public ..
0016: 04 2C 78 27 BC 02 01 00 02 01 00 30 0E 30 0C 06 .,x'¼......0.0..
0032: 08 2B 06 01 02 01 01 03 00 05 00 .+.........

Received 45 bytes from 127.0.0.1

0000: 30 2B 02 01 00 04 06 70 75 62 6C 69 63 A2 1E 02 0+.....public¢..
0016: 04 2C 78 27 BC 02 01 00 02 01 00 30 10 30 0E 06 .,x'¼......0.0..
0032: 08 2B 06 01 02 01 01 03 00 43 02 11 0F .+.......C...

sysUpTimeInstance = Timeticks: (4367) 0:00:43.67

6
Goals behind SNMPv3
◼ Security
◼ Security
◼ Security
◼ Provide modularity in the architecture
❑ Replacing new elements in the future should be
easier.
❑ Modularity = many IETF RFCs
◼ Separate “context” of the request from the
authentication

7
 I. SNMPv3 Key Features (1)
▪ Provides security for SNMP
▪ Defines a database that determines what parts of each MIB each
user can access
▪ Database entries also determine what protocols are used to
encrypt data

▪ Modularization of architecture
▪ SNMP Entities
❑ Both managers and agents are called SNMP entities
❑ Each entity consists of an SNMP engine and one or more SNMP
applications
▪ Security feature
❑ Secure information
❑ Access control

8
 SNMPv3 Key Features (2)

▪ SNMP Version 3 (SNMPv3) adds security and remote

configuration capabilities to the previous versions.

▪ The SNMPv3 architecture introduces

❑ the User-based Security Model (USM) for message security and

❑ the View-based Access Control Model (VACM) for access control.

❑ The architecture supports the concurrent use of different security,

access control, and message processing models.

9
 SNMPv3 Key Features (3)
▪ More specifically:
❑ Security
✓ authentication and privacy
✓ authorization and access control
❑ Administrative Framework
✓ naming of entities
✓ people and policies
✓ usernames and key management
✓ notification destinations
✓ proxy relationships
❑ Remotely configurable via SNMP operations
▪ SNMPv3 also introduces the ability to dynamically configure
the SNMP agent using SNMP SET commands against the
MIB objects that represent the agent's configuration.
❑ This dynamic configuration support enables addition, deletion, and
modification of configuration entries either locally or remotely.

10
Database Structure
◼ Database consists of USM, VTF, S2G, and VACM
entries.
◼ User based Security Model (USM) entries contain
information about the user including
❑ Username
❑ Authentication key
❑ Encryption key

◼ Security to Group (S2G) entries associate a user with a

group name.
◼ View Tree Family (VTF) entries define a view into a
MIB. A view is a piece (possibly all) of a MIB.
◼ View based Access Control Model (VACM) entries
associate a group with a view.

11
For User to Access MIB

◼ Create a USM entry for the user

◼ Create an S2G entry that associates the user
with a group
◼ Create a VACM entry that associates the group
with a view
◼ Create a VTF entry that defines a view into the
MIB

12
 II. SNMPv3 Architecture
Consists of a distributed collection of SNMP entities
SNMP ENTITY

SNMP APPLICATIONS

COMMAND COMMAND NOTIFICATION NOTIFICATION PROXY

GENERATOR RESPONDER ORIGINATOR RECEIVER FORWARDER
OTHER
OTHER

SNMP ENGINE

MESSAGE PROCESSING SECURITY ACCESS CONTROL

DISPATCHER
SUBSYSTEM SUBSYSTEM SUBSYSTEM

▪ SNMP entity is a node with an SNMP management element - either an agent or manager
or both
▪ Three names associated with an entity
❑ Entities: SNMP engine
❑ Identities: Principal and security name
❑ Management Information: Context engine

“The architecture is designed to be modular to allow the evolution of the Framework over time.”
-- RFC 2570 & RFC 2571 13
SNMPv3: Standards Breakdown
◼ RFC2570: SNMPv3 Overview
◼ RFC2571: Architecture
◼ RFC2572: Message Processing
◼ RFC2573: Applications
◼ RFC2574: User-based Security Model
◼ RFC2575: View-based Access Control Model
◼ RFC2576: v1/v2c/v3 Coexistence / Transition
◼ RFC2578-80: SMIv2 -- Language of the MIBs
◼ RFC1157: SNMPv1
◼ RFC1901,5: SNMPv2
◼ ...

14
SNMPv3: Framework Architecture
Application Access Control
or Agent
VACM
CG CR NG NR ...

Dispatcher Message Security

Processing

SNMPv3 MP User-based (USM)

SNMPv1 Kerberos
... ...

UDP TCP ...

Network

15
SNMPv3: Applications (RFC 2573)
◼ Application “types” have been formally defined:
❑ CG: Command Generator (was: Manager)
❑ CR: Command Responder (was: Agent)
❑ NG: Notification Generator
❑ NR: Notification Responder
❑ PF: Proxy Forwarder (not shown in diagram)

◼ An application can be of multiple types

❑ An agent is typically a CR and a NG
❑ A mid level manager is likely a CG, CR, NG, and NR
◼ (and maybe a PF)

16
SNMPv3 Protocol Packet Breakdown
SNMPv3Message {
Version INTEGER Dispatcher
(snmpv3 = 3)
HeaderData {
msgID INTEGER
MaxSize INTEGER MSG Processor
Flags STRING
SecurityModel INTEGER
(USM = 3)
}
UsmSecurityParameters STRING {
AuthoritativeEngineID STRING,
AuthoritativeEngineBoots INTEGER
AuthoritativeEngineTime INTEGER Security Model
UserName STRING
AuthenticationParameters STRING
PrivacyParameters STRING
}
ScopedPduData {
contextEngineID STRING,
contextName STRING,
PDU SNMPv2 PDUs
}
} Application

17
 Architecture Components
“The major portions of the architecture are an SNMP engine containing a
Message Processing Subsystem, a Security Subsystem and an Access
Control Subsystem, and possibly multiple SNMP applications which provide
specific functional processing of management data..”
-- RFC 2571

18
 SNMP Engine ID
1st
bit

SNMPv1 Enterprise ID Enterprise method Function of the method

0
SNMPv2 (1-4 octets) (5th octet) (6-12 octets)

Enterprise ID Format indicator Format

SNMPv3 1 (1-4 octets) (5th octet) (variable number of octets)

Figure 7.3 SNMP Engine ID

▪ Each SNMP engine has a unique ID: snmpEngineID

▪ Acme Networks {enterprises 696}
▪ SNMPv1 snmpEngineID ‘000002b8’H
▪ SNMPv3 snmpEngineID ‘800002b8’H
(the 1st octet is 1000 0000)

19
 SNMPv3 Engine ID Format 5th Octet
Table 7.2 SNMPv3 Engine ID Format (5th octet)

0 Reserved, unused
1 IPv4 address (4 octets)
2 IPv6 (16 octets)
Lowest non-special IP address
3 MAC address (6 octets)
Lowest IEEE MAC address, canonical order
4 Text, administratively assigned
Maximum remaining length 27
5 Octets, administratively assigned
Maximum remaining length 27
6-127 Reserved, unused
128-255 As defined by the enterprises
Maximum remaining length 27

▪ For SNMPv1 and SNMPv2:

❑ Octet 5 is the method
❑ Octet 6-12 is IP address

▪ Examples: IBM host IP address 10.10.10.10

SNMPv1: 00 00 00 02 01 0A 0A 0A 0A 00 00 00 => 00 00 00 02 01 00 00 00 0A 0A 0A 0A
SNMPv3: 80 00 00 02 01 00 00 00 00 00 00 00 0A 0A 0A 0A => 80 00 00 02 01 0A 0A 0A 0A

20
Engine ID
◼ Used to create hash user keys and for encryption and
authentication
◼ Older versions of SNMPv3 based it on unit’s IP address.
Bad idea since IP address can change.
◼ This version uses Ethernet MAC address
◼ Should prevent problems with new customers
◼ May create minor problems with customers who already
had SNMPv3

21
https://support.huawei.com/enterprise/en/doc/EDOC1000142063/8213
6ea0/what-is-an-snmp-engine-id-and-how-do-i-configure-it 22
◼ 800007DB03360102101100
◼ 800007DB = enterprise of HUAWEI
◼ 03 = represent MAC address
◼ 360102101100 = MAC address

23
 Dispatcher
SNMP Engine (identified by snmpEngineID)

Message Access
Security
Dispatcher Processing Control
Subsystem
Subsystem Subsystem

▪ One dispatcher in an SNMP engine

▪ Handles multiple version messages
❑ Try to determine the versions of each received message (v1, v2, v3)
▪ Interfaces with application modules, network, and message
processing models
❑ To send and received messages
▪ Three components for three functions
❑ Transport mapper delivers messages over the transport protocol
❑ Message Dispatcher routes messages between network and
appropriate module of MPS
❑ PDU dispatcher handles messages between application and MPS

24
The Dispatcher
Application Access Control
or Agent
VACM
CG CR NG NR ...

Dispatcher Message Security

Processing

SNMPv3 MP User-based (USM)

SNMPv1 Kerberos
... ...

UDP TCP ...

Network

25
The Dispatcher (RFC 2572)
◼ The simplest component of the architecture
◼ Directs packets to and from the other elements:
❑ Application or agent
◼ CG, CR, NG, NR
❑ The Network (through the appropriate transport layer)
❑ The correct message processor
◼ Makes it’s decision based on:
❑ What component sent it
❑ What protocol version is being sent
❑ What type of PDU is being sent
◼ Knowledge of it not required by the typical user

26
 Message Processing Subsystem
SNMP Engine (identified by snmpEngineID)

Message Access
Security
Dispatcher Processing Control
Subsystem
Subsystem Subsystem

▪ Processes messages to be sent and extracts data

from the received messages
▪ Contains one or more Message Processing Models
▪ One MPM for each SNMP version
▪ SNMP version identified in the header

27
The Message Processor

Application Access Control

or Agent
VACM
CG CR NG NR ...

Dispatcher Message Security

Processor

SNMPv3 MP User-based (USM)

SNMPv1 Kerberos
... ...

UDP TCP ...

Network

28
The SNMPv3 Message Processor (RFC 2572)
◼ Encodes and decodes the majority of the packet
◼ Handles errors and exceptions
❑ Message too big to fit in a packet
❑ Parse errors are detected
❑ ...
◼ Passes to appropriate security model for authentication
and encryption support.
❑ (Currently, the only defined security model is the USM)

◼ Knowledge of it not required by the typical user

29
 Security and Access Control
SNMP Engine (identified by snmpEngineID)

Message Access
Security
Dispatcher Processing Control
Subsystem
Subsystem Subsystem

▪ Security at the message level

❑ Authentication
✓ Uses either community strings (v1, v2)
✓ Uses user-based authentication (v3) – MD5, SHA
❑ Privacy of message via secure communication
✓ Uses DES algorithm
▪ Flexible access control – for controlling access to MIB objects – for
example, you might want to limit a user’s read-write access to certain parts of the
mib-2 tree while allowing read-only access to the entire tree
❑ Who can access
❑ What can be accessed
❑ Flexible MIB views

30
Security Model (1)
Application Access Control
or Agent
VACM
CG CR NG NR ...

Dispatcher Message Security

Processing

SNMPv3 MP User-based (USM)

SNMPv1 Kerberos
... ...

UDP TCP ...

Network

31
Security Model (2)
◼ Authenticates packets to ensure/verify origin
❑ Current authentication methods
◼ Provides message encryption/decryption support
❑ The ScopedPDU can be protected by encryption
◼ Makes it’s decisions based on packet data:
❑ EngineID, Engine Boots, Engine Time
❑ User Name
❑ Authentication field
❑ Privacy field
◼ Currently only one standard security model exists
❑ The “User Based Security Model”, or USM

32
 III. SNMPv3 Applications
Application(s)

Proxy
Command Notification
Forwarder
Generator Receiver
Subsystem

Command Notification Other

Responder Originator

Application Example
▪ Command generator get-request
▪ Command responder get-response
▪ Notification originator trap generation
▪ Notification receiver trap processing
▪ Proxy Forwarder get-bulk to get-next
(SNMP versions only)
▪ Other Special application

33
 Names
SNMP Engine ID snmpEngineID
Principal principal
Who: person or group or application
Security Name securityName
human readable name
Context Engine ID contextEngineID
Context Name contextName

▪ An SNMP agent can monitor more than one network element (context)
Examples:
SNMP Engine ID IP address

Principal John Smith

Security Name Administrator

Principal Li, David, Kristen, Rashmi,

Security Name Operator

snmpEngineID = Specified or a combination of enterprise ID + IP (or MAC address)

34
 Dispatcher Primitives

Module Primitive Service Provided

Dispatcher sendPdu Request from application to send a
PDU to a remote entity
Dispatcher processPdu Processing of incoming message
from remote entity
Dispatcher returnResponsePdu Request from application to send a
response PDU
Dispatcher processResponsePdu Processing of incoming response
from a remote entity
Dispatcher registerContextEngineID Register request from a Context
Engine
Dispatcher unregisterContextEngineID Unregister request from a Context
Engine

35
SNMP Overview
◼ Network monitoring and Information Collection

GET: What is in your routing table?

RESPONSE: It’s …

36
SNMP Manager
COMMAND NOTIFICATION
GENERATOR RECEIVER

PDU MESSAGE PROCESSING SECURITY SUBSYSTEM

DISPATCHER SUBSYSTEM

SNMPv1 COMMUNITY BASED

SECURITY MODEL
MESSAGE
DISPATCHER SNMPv2C
USER BASED
SECURITY MODEL
SNMPv3
OTHER
TRANSPORT SECURITY MODEL
MAPPINGS OTHER

37
SNMP Agent
MANAGEMENT INFORMATION BASE

ACCESS CONTROL SUBSYSTEM

COMMAND VIEW BASED
NOTIFICATION
RESPONDER ACCESS CONTROL
ORIGINATOR

PDU MESSAGE PROCESSING SECURITY SUBSYSTEM

DISPATCHER SUBSYSTEM

SNMPv1 COMMUNITY BASED

SECURITY MODEL
MESSAGE
DISPATCHER SNMPv2C
USER BASED
SECURITY MODEL
SNMPv3
OTHER
TRANSPORT SECURITY MODEL
MAPPINGS OTHER

38
SNMPv3 Flow

39
SNMPv3 Example: Generating a Request
Application Access Control
or Agent
VACM
CG CR NG NR ...

Dispatcher Message Security

Processing

SNMPv3 MP User-based (USM)

SNMPv1 Kerberos
... ...

UDP TCP ...

40
SNMPv3 Example: Receiving a Request
Application Access Control
or Agent
VACM
CG CR NG NR ...

Dispatcher Message Security

Processing

SNMPv3 MP User-based (USM)

SNMPv1 Kerberos
... ...

UDP TCP ...

Network

41
SNMPv3 Example: Generating a Response
Application Access Control
or Agent
VACM
CG CR NG NR ...

Dispatcher Message Security

Processing

SNMPv3 MP User-based (USM)

SNMPv1 Kerberos
... ...

UDP TCP ...

Network

42
SNMPv3 Example: Receiving a Response
Application Access Control
or Agent
VACM
CG CR NG NR ...

Dispatcher Message Security

Processing

SNMPv3 MP User-based (USM)

SNMPv1 Kerberos
... ...

UDP TCP ...

Network

43
 Notification / Proxy
▪ Notification originator
❑ Generates trap and inform messages
❑ Determine target, SNMP version, and security
❑ Decides context information
▪ Notification receiver
❑ Registers with SNMP engine
❑ Receives notification messages
▪ Proxy forwarder
❑ Proxy server
❑ Handles only SNMP messages by
✓ Command generator
✓ Command responder
✓ Notification generator
✓ Report indicator
❑ Uses the translation table in the proxy group MIB

44
 IV. SNMPv3 MIB
snmpModules
{1.3.6.1.6.3}

snmpFrameworkMIB (10) snmpVacmMIB (16)

snmpMPDMIB (11) snmpUsmMIB (15)
snmpTargetMIB (12) snmpProxyMIB (14)
snmpNotificationMIB (13)

Figure 7.7 SNMPv3 MIB

▪ snmpFrameworkMIB describes SNMP management architecture

▪ snmpMPDMIB identifies objects in the message processing and dispatch
subsystems
▪ snmpTargetMIB and snmpNotificationMIB used for notification generation
▪ snmpProxyMIB defines translation table for proxy forwarding
▪ snmpUsmMIB defines user-based security model objects
▪ snmpVacmMIB defines objects for view-based access control

45
 SNMPv2 MIB
Internet
{1 3 6 1}

directory mgmt experimental private security snmpv2

(1) (2 (3) (4) (5) (6)

snmpdomains snmpProxys snmpModules

(1) (2) (3)

mib-2 snmpMIB
(1) (1)

system snmp snmpMIBObjects snmpMIBConformance

(1) (11) (1) (2)

Figure 6.31 SNMPv2 Internet Group

▪ SNMPv3 MIB developed under snmpModules

▪ Security placeholder not used
46
 SNMPv3 Target MIB
snmpTargetMIB
{snmpModules 12}

snmpTargetObjects
(1)

snmpTargetAddrTable snmpTargetParamsTable
(2) (3)

Figure 7.8 Target Address and Target Parameter Tables

▪ Target MIB contains two tables

▪ Target address table contains addresses of the targets for notifications
(see notification group)
❑ Target address table also contains information for establishing the transport
parameters
❑ Target address table contains reference to the second table, target parameter table
▪ Target parameter table contains security parameters for authentication
and privacy

47
 SNMPv3 Notification MIB
snmpNotificationMIB
{snmpModules 13}

snmpNotifyObjects
(1)

snmpNotifyTable (1) snmpNotifyFilterTable (1)

snmpNotifyFilterProfileTable
(2)

Figure 7.9 SNMP Notification Tables

▪ Notification group contains three tables

▪ Notify table contains groups of management targets to receive notifications and
the type of notifications
❑ The target addresses to receive notifications that are listed in target address table
(see target group) are tagged here
▪ Notification profile table defines filter profiles associated with target
parameters
▪ Notification filter table contains table profiles of the targets
48
 V. Security
Security Threats
Modification of information
Masquerade
Message stream modification

Management Management
Entity A Entity B

Disclosure

Figure 7.10 Security Threats to Management Information

▪ Modification of information: Contents modified by unauthorized user, does not include

address change
▪ Masquerade: change of originating address by unauthorized user
▪ Fragments of message altered by an unauthorized user to modify the meaning of the
message
▪ Disclosure is eavesdropping
❑ Disclosure does not require interception of message
▪ Denial of service and traffic analysis are not considered as threats

49
 Security Services
Security Subsystem

Data Integrity
Authentication
Module
Data Origin Authentication

Message
Privacy
Processing Data Confidentiality
Module
Model

Message Timeliness & Timeliness

Limited Replay Protection Module

Figure 7.11 Security Services

▪ Authentication
❑ Data integrity:
✓ HMAC-MD5-96 / HMAC-SHA-96
❑ Data origin authentication
✓ Append to the message a unique Identifier associated with authoritative SNMP engine
▪ Privacy / confidentiality:
❑ Encryption
▪ Timeliness:
❑ Authoritative Engine ID, No. of engine boots and time in seconds

50
 Role of SNMP Engines

Non-Authoritative Engine
(NMS)

Authoritative Engine
(Agent)

▪ Responsibility of Authoritative engine:

❑ Unique SNMP engine ID
❑ Time-stamp
▪ Non-authoritative engine should keep a table of the time-stamp and
authoritative engine ID

51
 SNMPv3 Message Format
Header Data scopedPDU
Message
Message Message Message Context Context
Security Data
ID Max. Size Flag Engine ID Name
Model

Global/
Security Plaintext / Encrypted
Version Header Whole Message
Parameters scopedPDU Data
Data

Security Parameters

Authoritative Authoritative Authoritative User Authentication Privacy

Engine ID Engine Boots Engine Time Name Parameters Parameters

Figure 7.12 SNMPv3 Message Format

52
Protocol Structure - SNMPv3 Simple Network
Management Protocol version 3
SNMPv3 message format:

53
Version --For SNMPv3 it is 3.
ID --A unique identifier used between two SNMP entities to coordinate request and response
messages
Msg Size -- Maximum size of a message in octets supported by the sender of the message
Msg Flags --An octet string containing three flags in the least significant three bits:
reportableFlag, privFlag, authFlag.
Security Model --An identifier to indicate which security model was used by the sender and
therefore which security model must be used by the receiver to process this message.
AuthoritativeEngineID -- The snmpEngineID of the authoritative SNMP engine involved in
the exchange of this message. Thus, this value refers to the source for a Trap, Response, or
Report, and to the destination for a Get, GetNext, GetBulk, Set, or Inform.
AuthoritativeEngineBoots --The snmpEngineBoots value of the authoritative SNMP engine
involved in the exchange of this message.
AuthoritativeEngineTime -- The snmpEngineTime value of the authoritative SNMP engine
involved in the exchange of this message.
User Name --The user (principal) on whose behalf the message is being exchanged.
AuthenticationParameters -- Null if authentication is not being used for this exchange.
Otherwise, this is an authentication parameter.
PrivacyParameters -- Null if privacy is not being used for this exchange. Otherwise, this is a
privacy parameter.
PDU (Protocol Data Unit)-- The PDU types for SNMPv3 are the same as the SNMPv2. 54
 SNMPv3 Message Format
Field Object name Description
Version msgVersion SNMP version number of the
message format
Message ID msgID Administrative ID associated with the
message
Message Max. Size msgMaxSize Maximum size supported by the
sender
Message flags msgFlags Bit fields identifying report,
authentication, and privacy of the
message
Message Security msgSecurityModel Security model used for the message;
Model concurrent multiple models allowed
Security Parameters msgSecurityParameters Security parameters used for
(See Table 7.8) communication between sending and
receiving security modules
Plaintext/Encrypted scopedPduData Choice of plaintext or encrypted
scopedPDU Data scopedPDU; scopedPDU uniquely
identifies context and PDU
Context Engine ID contextEngineID Unique ID of a context (managed
entity) with a context name realized by
an SNMP entity
Context Name contextName Name of the context (managed entity)
PDU data Contains unencrypted PDU

55
VI. SNMPv3 User-Based Security
Model (USM)
▪ Designed to secure against: ▪ Based on traditional user name concept
❑ Modification of information ▪ USM primitives across abstract service
❑ Masquerade interfaces
❑ Message stream modification ❑ Authentication service primitives
❑ Disclosure ✓ authenticateOutgoingMsg
▪ Not intended to secure against: ✓ authenticateIncomingMsg
❑ Denial of Service (DoS attack) ❑ Privacy Services
❑ Traffic analysis ✓ encryptData
✓ decryptData

56
User Based Security: USM (RFC 2574)
◼ The User Based Security model provides:
❑ Authentication via MD5 or SHA1 hash
◼ The hash verifies the authenticity of the entire v3 message.
◼ Modified or forged packets will be rejected
❑ Encryption via DES encryption
◼ The ScopedPDU is encrypted (basically, the payload)
❑ 3 levels of security: noAuthNoPriv, authNoPriv, authPriv

◼ It does not provide protection against:

❑ Denial of Service
❑ Traffic Analysis

57
USM: About EngineIDs, etc...

◼ EngineIDs are:
❑ A unique “string” of data
❑ Generally defined from one of:
◼ IPv4 address
◼ IPv6 address
◼ MAC address
◼ Administratively defined strings
◼ Implementation dependent
◼ EngineBoots: number of reboots
◼ EngineTime: Time since last initialized
◼ Information is automatically probed by protocol.

58
USM: A User is...

◼ A USM User is defined by:

❑ The EngineID of the authoritative engine
❑ The SecurityName of the user (i.e., user name)
❑ The authentication type (MD5 or SHA1) and key
❑ The privacy type (DES) and key

◼ A user is modifiable via SNMP SET operations:

❑ Authentication and privacy keys can be changed.
❑ Encryption types and authentication types can not be changed
without deleting and recreating the user

59
USM: The Authoritative Engine
◼ Only one side of a transaction is “authoritative”
❑ Authoritative side == where the master user key exists
❑ Typically this means: the SNMP agents are authoritative
❑ The authoritative side is defined by whether the packet being
sent is expecting a response or not.
◼ An odd effect of this is:
❑ The engine receiving SNMPv3 INFORMs, which expect a “I got it”
response, are authoritative.
❑ The engine sending SNMPv3 TRAPs, which don’t require a response, are
authoritative.
❑ Ick.

60
USM: Keys
◼ USM Keys used to authenticate and encrypt
messages are generated:
❑ A password hashed using the authentication algorithm
(maybe)
❑ The resulting hash is then re-hashed after mixing it with the
authoritative engineID.

◼ This means:
❑ All user keys are different on each host
❑ Pro: A cracked system’s keys can’t be used to gain access to
other systems.
❑ Con: Distributing keys to many systems is difficult

61
USM: Keys

Management
Password
Application

Ku: Master Key

Kul1: Local Key 1 Kul2: Local Key 2 Kul3: Local Key 3

62
Message Authentication Code

63
USM: The math behind the keys
PassLong = repeat(password) till 1Mb long
Ku = hash(PassLong)
Kul = hash(Ku | authEngineID | Ku)

◼ Notes:
❑ Passwords must be at least 8 characters long
❑ Ku need not be generated from a password, but can be generated
randomly instead.
◼ Protects against brute-forcing low entropy passwords
❑ Hash is currently one of: MD5, SHA1

64
 Secure Outgoing Message
Security Subsystem

MPM Information Encryption key

User-based
Header data Security scopedPDU
Privacy
Security data Model Privacy Module
scopedPDU parameters

Message Encrypted
Processing scopedPDU
Model

Authentication key
(Authenticated/encrypted)
whole message Whole Message Authentication
Authenticated Module
Whole message length
Whole Message
Security Parameters

Figure 7.13 Privacy and Authentication Service for Outgoing Message

▪ USM invokes privacy module w/ encryption key and scopedPDU
▪ Privacy module returns privacy parameters and encrypted scopedPDU
▪ USM then invokes the authentication module w/authentication key and whole
message and receives authenticated whole message
65
 Secure Incoming Message
Security Subsystem
Authentication key
MPM Information
User-based Whole Message
Header data Security (as received from network) Authentication
Security parameters Model Authentication Module
whole message parameters
Authenticated
Message
Whole Message
Processing
Model

Decrypt key
Encrypted PDU
(Decrypted) scopedPDU Privacy Privacy
parameters Module
Decrypted
scopedPDU

Figure 7.14 Privacy and Authentication Service for Incoming Message

▪ Processing secure incoming message reverse of secure outgoing message

▪ Authentication validation done first by the authentication module
▪ Decryption of the message done then by the privacy module

66
 Security Parameters
snmpModules
{1.3.6.1.6.3}

snmpFrameworkMIB snmpUsmMIB
(10) (15)

snmpFrameworkMIBObjects snmpFrameworkAdmin UsmMIBObjects

(1) (1) (1)

snmpEngine snmpAuthProtocols snmpPrivProtocols UsmUser

(1) (1) (2) (2)

UsmUserSpinLock UsmUserTable
(1) (2)

Figure 7.15 SNMPv3 MIB Objects for Security Parameters

Table 7.8 Security Parameters and Corresponding MIB Objects

Security Parameters USM User Group Objects
msgAuthoritativeEngineID snmpEngineID (under snmpEngine Group)
msgAuthoritativeEngineBo snmpEngineBoots (under snmpEngine Group)
ots
msgAuthoritativeEngineTi snmpEngineTime (under snmpEngine Group)
me
msgUserName usmUserName (in usmUserTable)
msgAuthenticationParame usmUserAuthProtocol (in usmUserTable)
ters
67
msgPrivacyParameters usmUserPrivProtocol (in usmUserTable)
 Privacy Module

▪ Encryption and decryption of scoped PDU (context

engine ID, context name, and PDU)
▪ CBC - DES (Cipher Block Chaining - Data Encryption
Standard) symmetric protocol
▪ Encryption key (and initialization vector) made up of
secret key (user password), and timeliness value
▪ Privacy parameter is salt value (unique for each
packet) in CBC-DES

68
 Authentication Key
▪ User-based authentication
▪ Secret key for authentication
▪ Derived from user (NMS) password
▪ MD5 or SHA-1 algorithm used
▪ Authentication key is digest2
Procedure:
1. Derive digest0:
Password repeated until it forms 220 octets.
2. Derive digest1:
Hash digest0 using MD5 or SHA-1.
3. Derive digest2:
Concatenate authoritative SNMP engine ID and digest1 and hash
with the same algorithm
69
 Encryption Protocol
▪ Cipher Block Chaining mode of Data Encryption Standard (CBC-
DES) protocol
▪ 16-octet privKey is secret key
▪ First 8-octet of privKey used as 56-bit DES key; (Only 7 high-order
bits of each octet used)
▪ Last 8-octet of privKey used as pre-initialization vector
Transmission
Channel
Plaintext Encryption Ciphertext Decryption Plaintext
Secret Key

Secret Key
Figure 13.33 Basic Cryptographic Communication

▪ CBC Mode
❑ Plaintext divided into 64-bit blocks
❑ Each block is XOR-d with cipher text of the previous block and then
encrypted
❑ Use pre-IV (initialization vector) for prefixing the first message block

70
Key Localization Process

71
 VII. Access Control (1)
▪ For controlling access to MIB objects
▪ View-based Access Control Model (VACM)
❑ Groups: Name of the group comprising
security model and security name: In ▪ VACM has two
SNMPv1, is community name characteristics:
❑ Security Level ❑ Determines whether access
✓ no authentication - no privacy to a managed object should
✓ authentication - no privacy
be allowed.
✓ authentication - privacy
❑ Make use of an MIB that:
❑ Contexts: Names of the context
✓ Defines the access control
❑ MIB Views and View Families policy for this agent.
✓ MIB view is a combination of view subtrees ✓ Makes it possible for
❑ Access Policy remote configuration to be
✓ read-view used.
✓ write-view
✓ notify-view
✓ not-accessible

72
Access Control (2)
Application Access Control
or Agent
VACM
CG CR NG NR ...

Dispatcher Message Security

Processing

SNMPv3 MP User-based (USM)

SNMPv1 Kerberos
... ...

UDP TCP ...

Network

73
Access Control (3)

◼ Decides if a particular “object instance” may be

accessed or not.
◼ Consulted by the CR and NG application types
◼ Currently, only one access control model exists:
❑ The View-Based Access Control Module (VACM)

74
View Based Access Control (RFC 2575)
◼ Bases access control decisions on:
❑ Operation type (read, write, notify)
❑ Security model
❑ User performing the action
◼ Users are placed into a “group” and the groups are assigned the
rights, not the user.
❑ Security level of the transaction (authenticated? encrypted?)
❑ Object OID being accessed (and the context information)
❑ OID ranges are “included” or “excluded” from view
◼ I wish:
❑ Value of the object being accessed
❑ Users could be assigned to multiple groups (unix-like)

75
VACM: Access based on OID tree
1

Include .1.2
2 Exclude .1.2.2
Include .1.2.2.3

1 2 3 4
Objects “excluded” are
simply “not visible”

1 2 3 1 2 3
Simple Wild-carding
not shown, but possible

76
 VACM Process (1)
Answers 6 questions:
1. Who are you (group)?
2. Where do you want to go (context)?
3. How secured are you to access the information
(security model and security level)?
4. Why do you want to access the information
(read, write, or send notification)?
5. What object (object type) do you want to access?
6. Which object (object instance) do you want to
access?

77
 VACM Process (2)
Security
Security Security
Security Name Context
Model Level
Model (Principal) Name

Security-
How secured
Who are you? Context Go Where?
to-Group are you?
Group Table Context
Table Security Level

Context
noSuchContext Model
Name
Group Name Level
noGroupName
Read Write Notify

Why do you
Access Access
want access?
Table Allowed?
View Type

View Name
View Type Object Object
read/write/notify
noAccessEntry Type Instance
noSuchView
View Tree What & Which
Select Variable
Family Object?
Names
Table Variable

noSuchView

notInView Yes / No

Access
Allowed

78
Figure 7.16 VACM Process
 VACM Process (3)
Access control decision

79
 VACM MIB
snmpVacmMIB
(snmpModules 16)

vacmMIBObjects
(1)

vacmContextTable vacmSecurityToGroupTable vacmAccessTable vacmMIBViews

(1) (2) (4) (5)

vacmViewSpinLock vacmViewTreeFamilyAccessTable
(1) (2)

Figure 7.17 VACM MIB

▪ Four tables used to achieve access control

❑ Group defined by security-to-group table
❑ Context defined by context table
❑ Access determines access allowed and the view name
❑ View tree family table determines the MIB view, which is very flexible

80
 MIB Views

Simple view:
system 1.3.6.1.2.1.1
Complex view:
All information relevant to a particular interface - system and
interfaces groups

Family view subtrees

View with all columnar objects in a row appear as separate subtree.
OBJECT IDENTIFIER (family name)
paired with
bit-string value (family mask)
to select or suppress columnar objects

81
 VACM MIB View
vacmMIBViews
(vacmMIBObjects 5)

vacmViewSpinLock vacmViewTreeFamilyTable
(1) (2)

vacmViewTreeFamilyEntry
(1)

vacmViewTreeFamilyViewName (1) vacmViewTreeFamilyStatus (6)

vacmViewTreeFamilySubtree (2) vacmViewTreeFamilyStorageType (5)

vacmViewTreeFamilyMask (3) vacmViewTreeFamilyType(4)

Example: Figure 7.19 VACM MIB Views

Family view name = “system”

Family subtree = 1.3.6.1.2.1.1
Family mask = “” (implies all 1s by convention)
Family type = 1 (implies value to be included)

82