SNMPv3 Network Management Spring 2014 Bahador Bakhshi CE & IT Department, Amirkabir University of...

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

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

Out Going Message Flow in SNMP Engine

?

18

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)

Security Threats & Mechanisms in SNMPv3

45

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

Authentication and Integrity Protection

51

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

Encryption (DES)

53

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

Security Parameters

56

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