SNMPv3 Network Management Spring 2014 Bahador Bakhshi CE & IT Department, Amirkabir University of...
-
Upload
lydia-whitehead -
Category
Documents
-
view
219 -
download
2
Transcript of SNMPv3 Network Management Spring 2014 Bahador Bakhshi CE & IT Department, Amirkabir University of...
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
2
Outline
Introduction
SNMPv3 Architecture
Abstract Service Interface
Security Background
User-based Security Model (USM)
View-based Access Control Model (VACM)
Message Format
3
The Basic Ingredients of Network Management
4
Previous Lectures: NM Protocols
Current Lecture: SNMPv3 agent1) Agent modules 2) Security & Access control
Previous Lectures: Functions & Integration
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
5
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
6
Outline
Introduction
SNMPv3 Architecture
Abstract Service Interface
Security Background
User-based Security Model (USM)
View-based Access Control Model (VACM)
Message Format
7
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
8
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
9
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
10
SNMPv3 Entity
11
OTHERNOTIFICATIONORIGINATOR
COMMANDRESPONDER
COMMANDGENERATOR
NOTIFICATIONRECEIVER
PROXYFORWARDER
SNMP APPLICATIONS
SNMP ENGINE
MESSAGE PROCESSING
SUBSYSTEMDISPATCHERSECURITY
SUBSYSTEMACCESS CONTROL
SUBSYSTEM
SNMP ENTITY
OTHER
SNMP Engine
An SNMP engine provides services for 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
12
Dispatcher
Interfaces with application modules, network, and message processing models
Handles multiple versions of messages For backward compatibility
13
OTHERNOTIFICATIONORIGINATOR
COMMANDRESPONDER
COMMANDGENERATOR
NOTIFICATIONRECEIVER
PROXYFORWARDER
SNMP APPLICATIONS
SNMP ENGINE
MESSAGE PROCESSINGSUBSYSTEMDISPATCHER SECURITY
SUBSYSTEMACCESS CONTROL
SUBSYSTEM
SNMP ENTITY
OTHER
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
14
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
15
OTHERNOTIFICATIONORIGINATOR
COMMANDRESPONDER
COMMANDGENERATOR
NOTIFICATIONRECEIVER
PROXYFORWARDER
SNMP APPLICATIONS
SNMP ENGINE
MESSAGE PROCESSINGSUBSYSTEMDISPATCHER SECURITY
SUBSYSTEMACCESS CONTROL
SUBSYSTEM
SNMP ENTITY
OTHER
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
16
OTHERNOTIFICATIONORIGINATOR
COMMANDRESPONDER
COMMANDGENERATOR
NOTIFICATIONRECEIVER
PROXYFORWARDER
SNMP APPLICATIONS
SNMP ENGINE
MESSAGE PROCESSINGSUBSYSTEMDISPATCHER SECURITY
SUBSYSTEMACCESS CONTROL
SUBSYSTEM
SNMP ENTITY
OTHER
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
17
SNMPv3 Entity
19
OTHERNOTIFICATIONORIGINATOR
COMMANDRESPONDER
COMMANDGENERATOR
NOTIFICATIONRECEIVER
PROXYFORWARDER
SNMP APPLICATIONS
SNMP ENGINE
MESSAGE PROCESSING
SUBSYSTEMDISPATCHERSECURITY
SUBSYSTEMACCESS CONTROL
SUBSYSTEM
SNMP ENTITY
OTHER
SNMPv3 Applications
Command Generator 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
20
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
21
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
22
SNMP Manager & Agent
SNMP Manager 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
23
SNMPv3 Manager Architecture
24
NOTIFICATIONRECEIVER
COMMANDGENERATOR
PDUDISPATCHER
USER BASEDSECURITY MODEL
OTHERSECURITY MODEL
SECURITY SUBSYSTEM
SNMPv1
SNMPv2C
SNMPv3
OTHER
MESSAGE PROCESSINGSUBSYSTEM
MESSAGEDISPATCHER
TRANSPORTMAPPINGS
NOTIFICATIONORIGINATOR
SECURITY MODELCOMMUNITY BASED
SNMPv3 Agent Architecture
25
PDUDISPATCHER
SNMPv1
SNMPv2C
SNMPv3
OTHER
MESSAGE PROCESSINGSUBSYSTEM
MESSAGEDISPATCHER
TRANSPORTMAPPINGS
MANAGEMENT INFORMATION BASE
VIEW BASEDACCESS CONTROL
ACCESS CONTROL SUBSYSTEM
NOTIFICATIONORIGINATOR
COMMANDRESPONDER
USER BASEDSECURITY MODEL
OTHERSECURITY MODEL
SECURITY SUBSYSTEM
Proxy ForwarderApplications
COMMUNITY BASEDSECURITY MODEL
SNMP Engine ID
26
O TH ER
SNMP ENGINE
SNMP ENTITY
snmpEngineID=4
O TH ER
SNMP ENGINE
SNMP ENTITY
snmpEngineID=2
O TH ER
SNMP ENGINE
SNMP ENTITY
snmpEngineID=3
OT HE R
SNMP ENGINE
SNMP ENTITY
snmpEngineID=1
Outline
Introduction
SNMPv3 Architecture
Abstract Service Interface
Security Background
User-based Security Model (USM)
View-based Access Control Model (VACM)
Message Format
27
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
28
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)
29
CommandGenerator
Dispatcher
Abstract ServiceInterface
sendPdu
Abstract ServiceInterface
MessageProcessing
ModelsendPduHandle/errorIndication
Primitives Examples
processPdu 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
30
CommandResponder
Dispatcher
Abstract ServiceInterface
ReturnResponsePdu
Abstract ServiceInterface
MessageProcessing
ModelProcessPdu
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
31
CommandGenerator
Dispatcher
Abstract ServiceInterface
Abstract ServiceInterfacepr
epar
eOut
goin
gMes
sage
MessageProcessing
Model
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
32
CommandResponder
Dispatcher
Abstract ServiceInterface
Abstract ServiceInterface
prep
areR
espo
nseM
essa
ge
MessageProcessing
Model
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
33
Abstract Service Interface in Action Example
34
Network
send get-request message
receive get-response message
CommandGenerator
Dispatcher Message ProcessingModel
SecurityModel
sendPdu
PduHandle
prepareOutgoingMessage
generateRequestMsg
processResponsePdu
prepareDataElemetsprocessIncomingMsg
CommandResponder
DispatcherMessage
ProcessingModel
SecurityModel
35
Network
receive get-request message
send get-response message
CommandGenerator
Dispatcher Message ProcessingModel
SecurityModel
processPdu
processIncomingMsg
prepareDataElements
returnResponsePdu
prepareResponseMsg
generateResponseMsg
Dispatcher Message ProcessingModel
SecurityModel
CommandResponder
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
36
TerminologySecurity goals & objectives
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
37
Common Security Goals Authenticity
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?
...
38
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
39
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
40
SNMP Security Goals & Threats
41
Management Entity A
Management Entity B
A) Modification of informationB) MasqueradeC) Message stream modification
D) Disclosure
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
42
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
43
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
44
SNMP Security Goal & Threats (cont’d)
Outline
Introduction
SNMPv3 Architecture
Abstract Service Interface
Security Background
User-based Security Model (USM)
View-based Access Control Model (VACM)
Message Format
46
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
47
Security Services in SNMPv3
48
Security Subsystem
MessageProcessing
Model
AuthenticationModule
PrivacyModule
TimelinessModule
Data Integrity
Data Origin Authentication
Data Confidentiality
Message Timeliness &Limited Replay Protection
Authentication Module
49
Security Subsystem
Message
Processing
Model
Authentication
Module
Privacy
Module
Timeliness
Module
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
50
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)
52
Security Subsystem
MessageProcessing
Model
AuthenticationModule
PrivacyModule
TimelinessModule
Data Integrity
Data Origin Authentication
Data Confidentiality
Message Timeliness &Limited Replay Protection
Timeliness Module
Prevent message redirection, delay and replay
Configure a receiver window for accepting message Three objects: snmpEngineID, snmpEngineBoots, snmpEngineTime
54
Security Subsystem
MessageProcessing
Model
AuthenticationModule
PrivacyModule
TimelinessModule
Data Integrity
Data Origin Authentication
Data Confidentiality
Message Timeliness &Limited Replay Protection
Replay Protection
55
Limited protection: If a messages is replied but falls in the window, it will be accepted; i.e., no protection against reordering
Securing Outgoing Message
57
Retrieve user information
Privacy Required?
msgPrivacyParamters NULL
Authent.Required?
msgAuthentParamters NULL
Encrypt scopedPDUset msgPrivacyParamters
YES
NO
Compute MACset msgAuthentParamters
YES
Message Transmission
NO
Securing Outgoing Message
58
Security Subsystem
PrivacyModule
scopedPDU
Encryption keyUser-based
SecurityModel
EncryptedscopedPDU
Privacyparameters
AuthenticationModule
Whole Message
Authentication key
AuthenticatedWhole Message
MessageProcessing
Model
MPM Information
Header data
Security data
scopedPDU
(Authenticated/encrypted)whole message
Whole message length
Security Parameters
Secure Incoming Message
59
Retrieve msgparameters
Authent.Required?
PrivacyRequired?
Encrypt scopedPDUset msgPrivacyParamters
YES
NO
YES
Message reception
Compute MAC & Check itmsgAuthentParamters
Determine if msg is within time window
Decrypt scopedPDU
NO
Security level Security modelSecurity name….
Timeliness check
Secure Incoming Message
60
Security Subsystem
User-basedSecurityModel
MessageProcessing
Model
MPM Information
Header data
Security parameters
whole message
(Decrypted) scopedPDU PrivacyModule
Decrypt key
DecryptedscopedPDU
Privacyparameters
AuthenticationModule
Whole Message(as received from network)
Authentication key
AuthenticatedWhole Message
Authenticationparameters
Encrypted PDU
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
61
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
62
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
63
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!
64
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
65
Key Management: Step 1
Password to key generation
1) 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
66
Key Management: Step 2
67
password Take Hashof expanded
password string
Take Hashof user key and
Remote Engine ID
Take Hashof user key and
Remote Engine ID
Take Hashof user key and
Remote Engine ID
User Key
(digest1)
Localized
Keydigest2
Localized
key
Localized
key
Localized keys are initially configured in a secure way (could be manual!)
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
68
User 1
User 2
(authKey1_1, privKey1_1)
(authKey1_2, privKey1_2)
Agent 1
User 3
User 4
(authKey2_1, privKey2_1)
(authKey2_4, privKey2_4)
Agent 2
If compromised, other keys are not!If this agent compromised, only its keys are compromised. Other agents are safe.
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
69
Outline
Introduction
SNMPv3 Architecture
Abstract Service Interface
Security Background
User-based Security Model (USM)
View-based Access Control Model (VACM)
Message Format
70
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
71
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>
72
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
73
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
74
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
75
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
76
VACM Process
77
Who are you?Group
Security-to-Group
Table
SecurityModel
SecurityName
(Principal)
Go Where?Context
ContextTable
ContextName
How securedare you?
Security Level
SecurityModel
SecurityLevel
Why do youwant access?
View Type
Read NotifyWrite
AccessAllowed?
AccessTable
Level
ModelContextName
Group Name
What & WhichObject?Variable
Select VariableNames
View TreeFamily Table
View Nameread/write/notify
Yes / No
noGroupName
noSuchContext
noAccessEntrynoSuchView
AccessAllowed
notInView
noSuchView
ObjectType
ObjectInstance
View Type
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.
78
Outline
Introduction
SNMPv3 Architecture
Abstract Service Interface
Security Background
User-based Security Model (USM)
View-based Access Control Model (VACM)
Message Format
79
SNMPv3 Message Format
80
VersionGlobal/Header
Data
SecurityParameters
Plaintext / EncryptedscopedPDU Data
MessageID
MessageMax. Size
MessageFlag
MessageSecurityModel
Header Data
ContextEngine ID
ContextName
Data
scopedPDU
AuthoritativeEngine ID
AuthoritativeEngine Boots
AuthoritativeEngine Time
User Name
AuthenticationParameters
PrivacyParameters
Security Parameters
Whole Message
1 SNMPv12 SNMPv23 SNMPv3
reportableFlagprivFlagauthFlag
Time synch. between entities to avoid message replay and achieve timeliness
SNMPv3 Message Format
81
Field Description Version SNMP version number of the message format Message ID Administrative ID associated with the message Message Max. Size Maximum size supported by the sender Message flags Bit fields identifying report, authentication, and privacy of
the message Message Security Model
Security model used for the message; concurrent multiple models allowed
Security Parameters Security parameters used for communication between sending and receiving security modules
Plaintext/Encrypted scopedPDU Data
Choice of plaintext or encrypted scopedPDU; scopedPDU uniquely identifies context and PDU
Context Engine ID Unique ID of a context (managed entity) with a context name realized by an SNMP entity
Context Name Name of the context (managed entity) PDU Contains unencrypted PDU
SNMPv3 Message Format: Applications
82
msgVersionmsgID
msgMaxSizemsgFlags
msgSecurityModel
msgSecurityParameters
contextEngineIDcontextName
PDU
USED BY MESSAGE PROCESSING SUBSYSTEM
USED BY SNMPv3 PROCESSING MODULE
USED BY SECURITY SUBSYSTEM
USED BY ACCESS CONTROL SUBSYSTEMAND APPLICATIONS
Outline
Introduction
SNMPv3 Architecture
Abstract Service Interface
Security Background
User-based Security Model (USM)
View-based Access Control Model (VACM)
Message Format
83
SNMPv3 SummaryThe 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
84
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/
85