chapter 7 snmp management: snmpv3 chapter 7 snmp management: snmpv3 1 network management: principles...

Chapter 7

SNMP Management:SNMPv3

Chapter 7 SNMP Management: SNMPv3

1Network Management: Principles and Practice

© Mani Subramanian 2011


Objectives• SNMPv3 features

• Formalized SNMP architecture

• Security

• SNMP engine ID and name for network entity

• SNMPv3 applications and primitives

• SNMP architecture

• Integrates the three SNMP versions

• Message processing module

• Dispatcher module

• Future enhancement capability

• User security model, USM

• Derived from user ID and password

• Authentication

• Privacy

• Message timeliness

• View-based access control model, VACM

• Configure set of MIB views for agent with contexts

• Family of subtrees in MIB views

• VACM process

2Network Management: Principles and Practice

© Mani Subramanian 2011

Notes

Key Features

• Modularization of document (see Table 7.1 & Figure 7.1)• Modularization of architecture• SNMP engine • Security feature

• Secure information• Access control

Network Management: Principles and Practice© Mani Subramanian 2011


3

Notes

ArchitectureSNMP entity

Application(s)

CommandGenerator

NotificationReceiver

ProxyForwarderSubsystem

CommandResponder

NotificationOriginator

Other

SNMP Engine (identified by snmpEngineID)

DispatcherMessage

ProcessingSubsystem

SecuritySubsystem

AccessControl

Subsystem

Figure 7.2 SNMPv3 Architecture


4


• SNMP entity is a node with an SNMP management element - either an agent or manager or both• Three names associated with an architecture:

• Entities: SNMP engine(Entity = implementation of architecture)

• Identities: Principal and security name• Management Information: Context engine

Notes

Architecture (Contd.)SNMP entity

Application(s)

CommandGenerator



CommandResponder


Other


DispatcherMessage

ProcessingSubsystem

SecuritySubsystem

AccessControl

Subsystem

Figure 7.2 SNMPv3 Architecture


5


• SNMP engine includes one or more Message Processing Models (MPMs) and may support more security models

• Security: message-level security (authentication, encryption, and timeliness checking)

• Access Control: Security (PDU level) applied to protocol operations (whether access to a MO is allowed)

• Proxy Forwarder (Optional) : forwards SNMP messages

SNMP Engine ID

SNMPv1SNMPv2

Enterprise ID(1-4 octets)

Enterprise method(5th octet)

Function of the method(6-12 octets)

SNMPv3Enterprise ID(1-4 octets)

Format indicator(5th octet)

Format(variable number of octets)1

0

1stbit

Figure 7.3 SNMP Engine ID


6


Notes• Each SNMP engine has a unique ID: snmpEngineID • SNMP engine is of type:

OCTET STRING (SIZE(5..32))• For SNMPv1 and SNMPv2 → length = 12 octets• For SNMPv3 → length varies [5-32] octets

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

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


6-127 Reserved, unused

128-255 As defined by the enterprises



7


Notes• For SNMPv1 and SNMPv2:

• Octet 5 is the method• Octet 6-12 is a function of the method (e.g., IP address)

• Examples: IBM host IP address 10.10.10.10 SNMPv1: 00 00 00 02 01 0A 0A 0A 0A 00 00 00 SNMPv3: 80 00 00 02 02 00 00 00 00 00 00 00 00 00 00 00

00 0A 0A 0A 0A

Notes

Dispatcher


DispatcherMessage

ProcessingSubsystem

SecuritySubsystem

AccessControl

Subsystem

• One dispatcher in an SNMP engine• Handles multiple version messages• Interfaces with application modules, network, and MPMs• Three components for three functions:

• Transport mapper delivers messages on the network over the transport protocol

• Message Dispatcher routes messages between network and appropriate module of MPS

• PDU dispatcher handles messages between application and MPM


8


Notes

Message Processing Subsystem


DispatcherMessage

ProcessingSubsystem

SecuritySubsystem

AccessControl

Subsystem

• Contains one or more MPMs•Responsible for preparing messages for sending and for extracting data from received messages

• One MPM for each SNMP version

• SNMP version identified in the header


9


Notes

Security and Access Control


DispatcherMessage

ProcessingSubsystem

SecuritySubsystem

AccessControl

Subsystem


10


• May contain multiple security models

• Security at the message level• Authentication • Privacy of message via secure communication

• Flexible access control• Who can access• What can be accessed• Flexible MIB views

PDU Classes

Five classifications are based on the functional properties of a PDU:

• Read Class: The Read Class contains protocol operations that retrieve management information. For example, [RFC3416] defines the following protocol operations for the Read Class: GetRequest-PDU, GetNextRequest-PDU, and GetBulkRequest-PDU.

• Write Class: The Write Class contains protocol operations which attempt to modify management information. For example, [RFC3416] defines the following protocol operation for the Write Class: SetRequest-PDU.

• Response Class: The Response Class contains protocol operations which are sent in response to a previous request. For example, [RFC3416] defines the following for the Response Class: Response-PDU, Report-PDU.

• Notification Class: The Notification Class contains protocol operations which send a notification to a notification receiver application. For example, [RFC3416] defines the following operations for the Notification Class: Trapv2-PDU, InformRequest-PDU.

• Internal Class: The Internal Class contains protocol operations which are exchanged internally between SNMP engines. For example, [RFC3416] defines the following operation for the Internal Class: Report-PDU.



11

Two classifications are based on whether a response is expected:

• Confirmed Class: The Confirmed Class contains all protocol operations which cause the receiving SNMP engine to send back a response. For example, [RFC3416] defines the following operations for the Confirmed Class: GetRequest-PDU, GetNextRequest-PDU, GetBulkRequest-PDU, SetRequest-PDU, and InformRequest-PDU.

• Unconfirmed Class: The Unconfirmed Class contains all protocol operations which are not acknowledged. For example, [RFC3416] defines the following operations for the Unconfirmed Class: Report-PDU, Trapv2-PDU, and Response-PDU.



12

PDU Classes

Applications

• Command generator: initiates SNMP Read-Class and/or Write-Class requests, and processes responses to requests which it generated, e.g., get-request.

• Command responder: receives SNMP Read-Class and/or Write-Class requests, performs the appropriate protocol operation and generates a response message, e.g., get-response.

• Notification originator: monitors a system for particular events or conditions, and generates Notification-Class messages (either Confirmed-Class or Unconfirmed-Class PDU types) based on these events or conditions, e.g., trap generation.

• Notification receiver: listens for notification messages, and generates response messages when a message containing a Confirmed-Class PDU is received, e.g., trap processing.

• Proxy Forwarder (Optional): forwards SNMP messages, e.g., get-bulk to get-next or between different transport mappings (SNMP versions only)

• Other: special application

Application(s)

CommandGenerator



CommandResponder


Other



13

Notes

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

Examples:SNMP Engine ID IP address

Principal John SmithSecurity Name Administrator

Principal Li, David, Kristen, Rashmi, Security Name Operator

• An SNMP agent can monitor more than one network element (context)


14


Notes

Abstract Service Interface

Subsystem A Subsystem B

AbstractService

Interface

primitiveABIN = a1, a2 .

OUT = b1, b2

statusInformation/

result

Figure 7.4(a) Abstract Service Interface

primitiveBC

AbstractService

Interface

Subsystem C


15


• Abstract service interface is a conceptual interface between modules, independent of implementation• Defines a set of primitives • Primitives associated with receiving entities except for Dispatcher, e.g., Subsystem B for primitiveAB.• Dispatcher primitives associated with

• messages to and from applications• registering and un-registering of application modules (contextEngineID and pduType)• transmitting to and receiving messages from the network

• IN and OUT parameters• Status information / result

Notes

sendPDU Primitive

CommandGenerator

Dispatcher

AbstractService

Interface

sendPdu

Figure 7.4(b) Abstract Service Interface for sendPdu

AbstractService

Interface

prep

areO

utgo

ingM

essa

ge

MessageProcessing

Model

sendPduHandle/errorIndication


16


• sendPdu request sent by the application module, command generator, is associated with the receiving module, dispatcher• After the message is transmitted over the network, dispatcher sends a handle to the command generator for tracking the response• sendPdu is the primitive• statusInformation stores the returned parameter, which could be either sendPduHandle (if successful) or errorIndication (in case of failure)

Notes

Dispatcher Primitives

Module Primitive Service Provided

Dispatcher sendPdu Request from application to send aPDU to a remote entity

Dispatcher processPdu Processing of incoming messagefrom remote entity

Dispatcher returnResponsePdu Request from application to send aresponse PDU

Dispatcher processResponsePdu Processing of incoming responsefrom a remote entity

Dispatcher registerContextEngineID Register request from a ContextEngine

Dispatcher unregisterContextEngineID Unregister request from a ContextEngine


17


• Received (by Dispatcher) from an application:• sendPdu,• returnResponsePdu• registerContextEngineID• unregisterContextEngineID

• Sent (by Dispatcher) to an application:• processPdu,• processResponsePdu

Command Generator(Typically in Manager)

Network

send get-request message

receive get-response message

CommandGenerator Dispatcher

MessageProcessing

ModelSecurityModel

sendPdu

PduHandle

prepareOutgoingMessage

generateRequestMsg

processResponsePdu

prepareDataElemetsprocessIncomingMsg

CommandGenerator

DispatcherMessage

ProcessingModel

SecurityModel


18


Command Responder(Typically in Agent)

Network

receive get-request message

send get-response message

CommandResponder

Dispatcher

MessageProcessingModel

SecurityModel

processPdu

processIncomingMsg

prepareDataElements

returnResponsePdu

prepareResponseMsg

generateResponseMsg

DispatcherMessageProcessingModel

SecurityModel

registerContextEngineID


19


Notification / Proxy


20


• Notification originator (typically in an Agent)• Generates trap and inform messages

• [Notification-Class messages (eitherConfirmed-Class or Unconfirmed-Class PDUs)]

• Determines target, SNMP version, and security• Uses the MIB

• Decides context information

• Notification receiver• Registers with SNMP engine

• To receive notifications• Receives notification messages

• Proxy forwarder• Proxy server• Handles only SNMP messages generated by

• Command generator• Command responder• Notification originator• Report indicator

• Uses the translation table in the proxy group MIB

SNMPv2 MIB

mgmt(2

directory(1)

experimental(3)

private(4)

internet{1 3 6 1}

security(5)

snmpv2(6)

snmpDomains(1)

snmpProxys(2)

snmpModules(3)

Figure 6.31 SNMPv2 Internet Group

snmpMIB(1)

mib-2(1)

system(1)

snmp(11)

snmpMIBConformance(2)

snmpMIBObjects(1)

Notes• SNMPv3 MIB developed under snmpModules• Security placeholder not used


21


Notes

SNMPv3 MIB

snmpVacmMIB (16)

snmpUsmMIB (15)

snmpProxyMIB (14)

snmpFrameworkMIB (10)

snmpMPDMIB (11)

snmpTargetMIB (12)

snmpModules{1.3.6.1.6.3}

Figure 7.7 SNMPv3 MIB

snmpNotificationMIB (13)


22


• snmpFrameworkMIB describes SNMP management architecture (RFC 3411)• snmpMPDMIB identifies objects in the message processing and dispatch subsystems (RFC 3412)• snmpTargetMIB and snmpNotificationMIB used for notification generation (RFC 3413)• snmpProxyMIB defines translation table for proxy

forwarding (RFC 3413)• snmpUsmMIB defines user-based security model objects (RFC 3414)• snmpVacmMIB defines objects for view-based access control (RFC 3415)

SNMP Framework MIB (RFC 3411)

snmpFrameworkMIB(10)


snmpFrameworkMIBObjects(2)

snmpAuthProtocols(1)

snmpPrivProtocols(2)

snmpFrameworkAdmin(1)

snmpEngine(1)

snmpFrameworkMIBConformance(3)

snmpFrameworkMIBCompliances

(1)

snmpFrameworkMIBGroups

(2)

• snmpFrameworkAdminOBJECT IDENTIFIER ::= { snmpFrameworkMIB 1 }

• snmpFrameworkMIBObjectsOBJECT IDENTIFIER ::= { snmpFrameworkMIB 2 }

• snmpFrameworkMIBConformanceOBJECT IDENTIFIER ::= { snmpFrameworkMIB 3 }

• snmpFrameworkMIBCompliancesOBJECT IDENTIFIER ::= { snmpFrameworkMIBConformance 1}

• snmpFrameworkMIBGroups

OBJECT IDENTIFIER ::= {snmpFrameworkMIBConformance 2}



23

Message Processing and Dispatching(RFC 3412)

snmpMPDMIB(11)


snmpMPDMIBObjects(2)

snmpMPDAdmin(1)

snmpMPDStats(1)

snmpMPDMIBConformance(3)

snmpMPDMIBCompliances(1)

snmpMPDMIBGroups(2)

• snmpMPDAdmin

OBJECT IDENTIFIER ::= { snmpMPDMIB 1 }

• snmpMPDMIBObjects


• snmpMPDMIBConformance


• snmpMPDStats

OBJECT IDENTIFIER ::= { snmpMPDMIBObjects 1 }

• snmpMPDMIBCompliances

OBJECT IDENTIFIER ::= {snmpMPDMIBConformance 1}

• snmpMPDMIBGroups

OBJECT IDENTIFIER ::= {snmpMPDMIBConformance 2}



24

Notes

SNMPv3 Target MIB (RFC 3413)

• Target MIB contains two tables

• Target address table contains:• Addresses of the targets for notifications (see

notification group)• Information for establishing the transport

parameters• Reference to the second table, i.e., target

parameter table

•Target parameter table contains security parameters for authentication and privacy

snmpTargetMIB{snmpModules 12}

snmpTargetObjects(1)

snmpTargetAddrTable(2)

snmpTargetParamsTable(3)

snmpTargetSpinLock (1)

snmpUnavailableContexts (4)

snmpUnknownContexts (5)

snmpTargetConformance(3)



25

Notes

SNMPv3 Notification MIB(RFC 3413)

• Notification group contains three tables

• Notify table contains groups of management targets that should receive notifications and the type of notifications to be generated and sent

• 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

snmpNotifyFilterTable(3)

snmpNotificationMIB{snmpModules 13}

snmpNotifyObjects(1)

snmpNotifyFilterProfileTable(2)

snmpNotifyTable(1)



26

Principal Threats(RFC 3411 & RFC 3414)

• The principal threats against which any Security Model used within this architecture SHOULD provide protection are:

– Modification of Information - an entity may alter in-transit SNMP messages generated on behalf of an authorized principal in such a way as to effect unauthorized management operations, including falsifying the value of an object.

– Masquerade - management operations not authorized for some entity may be attempted by assuming the identity of another entity that has the appropriate authorizations.

• Secondary threats against which any Security Model used within this architecture SHOULD provide protection are:

– Disclosure - Eavesdropping on the exchanges between SNMP engines. (a matter of local policy)

– Message Stream Modification - SNMP is typically based upon a connectionless transport service. Messages may be maliciously re-ordered, delayed or replayed, in order to effect unauthorized management operations. For example, a message to reboot a system could be copied and replayed later.

• SNMPv3 is not intended to secure against these two threats:

– Denial of Service An attacker may prevent exchanges between manager and agent.

– Traffic Analysis An attacker may observe the general pattern of traffic between managers and agents.



27

Notes

Security Threats (RFC 3414)

ManagementEntity A

ManagementEntity B

Modification of informationMasquerade

Message stream modification

Disclosure

Figure 7.10 Security Threats to Management Information

• Modification of information: Contents modified by an unauthorized user, does not include address change• Masquerade: change of originating address by unauthorized user• Disclosure: is eavesdropping. Disclosure does not require interception of messages• Message Stream Modification: Fragments of message altered by an unauthorized user to modify the meaning of the message• Denial of service and traffic analysis are not considered as threats



28

SNMP Security Model Goals (RFC 3414)

• Based on the foregoing account of threats in the SNMP network management environment, the goals of this SNMP Security Model are as follows:

1) Provide for verification that each received SNMP message has not been modified during its transmission through the network.

2) Provide for verification of the identity of the user on whose behalf a received SNMP message claims to have been generated.

3) Provide for detection of received SNMP messages, which request or contain management information, whose time of generation was not recent.

4) Provide, when necessary, that the contents of each received SNMP message are protected from disclosure.



29

Notes

Security ServicesSecurity Subsystem

MessageProcessing

Model

AuthenticationModule

PrivacyModule

TimelinessModule

Data Integrity

Data Origin Authentication

Data Confidentiality

Message Timeliness &Limited Replay Protection

Figure 7.11 Security Services

• Authentication module:• Data integrity: is the provision of the property that data hasnot been altered or destroyed in an unauthorized manner, norhave data sequences been altered to an extent greater thancan occur non-maliciously.

• Authentication protocols: HMAC-MD5-96 / HMAC-SHA-96

• Data origin authentication: is the provision of the propertythat the claimed identity of the user on whose behalf receiveddata was originated is corroborated.

• Append to the message a unique Identifier associated with authoritative SNMP engine



30

Notes

Security Services (Cont.)Security Subsystem

MessageProcessing

Model


PrivacyModule

TimelinessModule

Data Integrity

Data Origin Authentication

Data Confidentiality

Message Timeliness &Limited Replay Protection

Figure 7.11 Security Services

• Privacy module (confidentiality): is the provision of theproperty that information is not made available or disclosed to

unauthorized individuals, entities, or processes. • Encryption: CBC-DES Symmetric Encryption Protocol

• Timeliness module: Message timeliness and limited replayprotection is the provision of the property that a message whosegeneration time is outside of a specified time window is not accepted.(Note that message reordering is not dealt with and can occur innormal conditions too.)

• Authoritative Engine ID, No. of engine boots and time in seconds



31

Notes

Role of SNMP Engines (RFC 3414)

Non-Authoritative Engine(NMS)

Authoritative Engine(Agent)

• To protect against message replay, delay and redirection,one of the SNMP engines involved in each communicationis designated to be the authoritative SNMP engine.

• When an SNMP message contains a payload which expects aresponse (i.e., messages that contain a Confirmed Class PDU[RFC3411]), then the receiver of such messages is authoritative.

• When an SNMP message contains a payload which does notexpect a response (those messages that contain anUnconfirmed Class PDU [RFC3411]), then the sender of sucha message is authoritative.



32

Notes

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 of every SNMP engine it communicates with

Role of SNMP Engines (RFC 3414)



33

USM Timeliness Mechanisms

• Management of authoritative clocks– All authoritative engines must maintain two objects:

• snmpEngineBoots• snmpEngineTime

– Initially, both are set to 0– snmpEngineTime is incremented once per second– snmpEngineBoots is incremented if the system has

rebooted or if snmpEngineTime reaches its maximum value (231 -1)

• Synchronization (required by a non-authoritative engine)– A non-authoritative engine must remain loosely

synchronized with each authoritative engine with which it communicates.

– A non-authoritative engine keeps a local copy of 3 variables for each authoritative engine:

• snmpEngineBoots: most recent value from authoritative engine.

• snmpEngineTime: synchronized to the authoritative engine. Between synch events, it is incremented once per second to maintain loose synch.

• latestReceivedEngineTime: Highest value of msgAuthoritativeEngineTime. It protects against a replay message attack.



34

• Synchronization (by a non-authoritative engine) (Cont.)– An update (of timeliness variables) occurs if:

(msgAuthoritativeEngineBoots > snmpEngineBoots) OR[(msgAuthoritativeEngineBoots = snmpEngineBoots) AND(msgAuthoritativeEngineTime > latestReceivedEngineTime)]

– If an update is called for, then the following changes are made:

• snmpEngineBoots := msgAuthoritativeEngineBoots • snmpEngineTime := msgAuthoritativeEngineTime • latestReceivedEngineTime := msgAuthoritativeEngineTime

– If (msgAuthoritativeEngineBoots < snmpEngineBoots) then no update occurs. [Message not authentic → to be discarded]

– If [(msgAuthoritativeEngineBoots = snmpEngineBoots) AND(msgAuthoritativeEngineTime < latestReceivedEngineTime)] then no update occurs. [Message may be authentic but may be misordered → Update of snmpEngineTime is not warranted.]

USM Timeliness Mechanisms(Cont.)



35

• Timeliness checking by authoritative receiver– Incoming message is considered outside the time window if

the following is true:• snmpEngineBoots = (231 -1) OR• msgAuthoritativeEngineBoots snmpEngineBoots OR• The value of msgAuthoritativeEngineTime differs from that of

snmpEngineTime by more than ± 150 seconds.

– In this case, an error indication (notInTimeWindow) is returned.

• Timeliness checking by non-authoritative receiver– Incoming message is considered outside the time window if

the following is true:• snmpEngineBoots = (231 -1) OR• msgAuthoritativeEngineBoots < snmpEngineBoots OR• [(msgAuthoritativeEngineBoots = snmpEngineBoots) AND

msgAuthoritativeEngineTime < snmpEngineTime – 150]

USM Timeliness Mechanisms(Cont.)

Notes• 231 -1 seconds ≈ 68 years.



36

Discovery• Discovery requires a non-authoritative SNMP engine to

learn the authoritative SNMP engine's snmpEngineID value before communication may proceed.

• The non-authoritative engine sends a Request message to the authoritative engine it wishes to discover with:

– securityLevel = noAuthnoPriv– msgUserName = “initial”– msgAuthoritativeEngineID = null– varBindList = null

• The authoritative engine respond with a Report message with:

– msgAuthoritativeEngineID = ‘its own’ snmpEngineID

• If authenticated communication is required:– The non-authoritative engine establishes time

synchronization with the authoritative engine• Non-authoritative engine sends an authenticated

Request message with:– msgAuthoritativeEngineID = newly learned remote

snmpEngineID– msgAuthoritativeEngineBoots = 0– msgAuthoritativeEngineTime = 0

• Authoritative engine sends a Report message with its current values:

– msgAuthoritativeEngineBoots = snmpEngineBoots – msgAuthoritativeEngineTime = snmpEngineTime



37

SNMPv3 Message Format(RFC 3412)

VersionGlobal/Header

Data

SecurityParameters

Plaintext / EncryptedscopedPDU Data

MessageID

MessageMax. Size

MessageFlag

MessageSecurityModel

AuthoritativeEngine ID

AuthoritativeEngine Boots

AuthoritativeEngine Time

User Name

AuthenticationParameters

PrivacyParameters

ContextEngine ID

ContextName

Data

Figure 7.12 SNMPv3 Message Format

Header Data scopedPDU

Security Parameters

Whole Message



38

SNMPv3 Message Format

Field Object name Description

Version msgVersion SNMP version number of themessage format

Message ID msgID Administrative ID associated with themessage

Message Max. Size msgMaxSize Maximum size supported by thesender

Message flags msgFlags Bit fields identifying report,authentication, and privacy of themessage

Message SecurityModel

msgSecurityModel Security model used for the message;concurrent multiple models allowed

Security Parameters(See Table 7.8)

msgSecurityParameters Security parameters used forcommunication between sending andreceiving security modules

Plaintext/EncryptedscopedPDU Data

scopedPduData Choice of plaintext or encryptedscopedPDU; scopedPDU uniquelyidentifies context and PDU

Context Engine ID contextEngineID Unique ID of a context (managedentity) with a context name realized byan SNMP entity

Context Name contextName Name of the context (managed entity)

PDU data Contains unencrypted PDU



39

Notes

Security Parameters(RFC 3414)

snmpUsmMIB(15)


SNMPv3 MIB Objects for Security Parameters

UsmMIBObjects(1)

UsmUser(2)

UsmUserTable(2)

UsmUserSpinLock(1)

Table 7.8 Security Parameters and Corresponding MIB Objects

Security Parameters USM User Group Objects msgAuthoritativeEngineID snmpEngineID (under snmpEngine Group) msgAuthoritativeEngineBoots

snmpEngineBoots (under snmpEngine Group)

msgAuthoritativeEngineTime

snmpEngineTime (under snmpEngine Group)

msgUserName usmUserName (in usmUserTable) msgAuthenticationParameters

usmUserAuthProtocol (in usmUserTable) (usmNoAuthProtocol (default), usmHMACMD5AuthProtocol, usmHMACSHAAuthProtocol)

msgPrivacyParameters usmUserPrivProtocol (in usmUserTable) (usmNoPrivProtocol (default), usmDESPrivProtocol)



40

Notes

User-Based Security Model(RFC 3414)

• Based on traditional user name concept

• USM primitives across abstract service interfaces• Authentication service primitives

• authenticateOutgoingMsg• authenticateIncomingMsg

• Privacy Services• encryptData• decryptData



41

Secure Outgoing Message

Security Subsystem

PrivacyModule

scopedPDU

Encryption keyUser-based

SecurityModel

EncryptedscopedPDU

Privacyparameters


Whole Message

Authentication key

AuthenticatedWhole Message

Figure 7.13 Privacy and Authentication Service for Outgoing Message

MessageProcessing

Model

MPM Information

Header data

Security data

scopedPDU

(Authenticated/encrypted)whole message

Whole message length

Security Parameters

Notes• USM invokes privacy module w/ encryption keyand scopedPDU

• Privacy module returns privacy parameters andencrypted scopedPDU

• USM then invokes the authentication modulew/authentication key and whole message and receivesauthenticated whole message



42

Secure Outgoing Message

Two services are provided:

1) A service to generate a Request message. The abstract service primitive is:

statusInformation = -- success or errorIndication generateRequestMsg( IN messageProcessingModel -- typically, SNMP version IN globalData -- message header, admin data IN maxMessageSize -- of the sending SNMP entity IN securityModel -- for the outgoing message (e.g., USM) IN securityEngineID -- authoritative SNMP entity IN securityName -- on behalf of this principal IN securityLevel -- Level of Security requested (none, auth, auth+priv) IN scopedPDU -- message (plaintext) payload OUT securityParameters -- filled in by Security Module OUT wholeMsg -- complete generated message OUT wholeMsgLength -- length of generated message )

2) A service to generate a Response message. The abstract service primitive is:

statusInformation = -- success or errorIndication generateResponseMsg( IN messageProcessingModel -- typically, SNMP version IN globalData -- message header, admin data IN maxMessageSize -- of the sending SNMP entity IN securityModel -- for the outgoing message IN securityEngineID -- authoritative SNMP entity IN securityName -- on behalf of this principal IN securityLevel -- Level of Security requested IN scopedPDU -- message (plaintext) payload IN securityStateReference -- reference to security state information from original request OUT securityParameters -- filled in by Security Module OUT wholeMsg -- complete generated message OUT wholeMsgLength -- length of generated message )



43

Secure Incoming Message

Security Subsystem

User-basedSecurityModel

Figure 7.14 Privacy and Authentication Service for Incoming Message

MessageProcessing

Model

MPM Information

Header data

Security parameters

whole message

(Decrypted) scopedPDU PrivacyModule

Decrypt key

DecryptedscopedPDU

Privacyparameters


Whole Message(as received from network)

Authentication key

AuthenticatedWhole Message

Authenticationparameters

Encrypted PDU

Notes• Processing secure incoming message reverse ofsecure outgoing message

• Authentication validation done first by theauthentication module

• Decryption of the message done then by theprivacy module



44

Secure Incoming Message

The abstract service primitive is:

statusInformation = -- errorIndication or success -- error counter OID/value if error processIncomingMsg( IN messageProcessingModel -- typically, SNMP version IN maxMessageSize -- of the sending SNMP entity IN securityParameters -- for the received message IN securityModel -- for the received message IN securityLevel -- Level of Security IN wholeMsg -- as received on the wire IN wholeMsgLength -- length as received on the wire OUT securityEngineID -- authoritative SNMP entity OUT securityName -- identification of the principal OUT scopedPDU -- message (plaintext) payload OUT maxSizeResponseScopedPDU -- maximum size of the Response PDU OUT securityStateReference -- reference to security state information, needed

-- for response)



45

Notes

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



46

Notes

Encryption Protocol

TransmissionChannel

EncryptionPlaintext

Secr

et K

ey

Decryption PlaintextCiphertext

Figure 13.33 Basic Cryptographic CommunicationSe

cret

Key

• Cipher Block Chaining mode of Data Encryption Standard (CBC-DES) protocol• 16-octet privKey is a secret key (using MD5)• 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

• CBC Mode – Encryption process• Plaintext divided into 64-bit blocks• Each block is XOR-d with ciphertext of the previous block and then encrypted• The first message block is XOR-d withthe IV (initialization vector):

• IV = pre-IV XOR salt• salt = 4-octet snmpEngineBoots concatenatedwith a locally generated integer (4-octet)• salt value is placed in the msgPrivacyParameters field



47

Notes

Authentication Key• Secret key for authentication

• Derived from user (non authoritative engine - NMS)password

• MD5 (16 octets) or SHA-1 (20 octets) algorithm used

• Authentication key is digest2

Procedure:1. Derive digest0: Password repeated until it forms 220 octets, and truncating the last repetition, if necessary.

2. Derive digest1 (i.e., user key): Hash digest0 using MD5 or SHA-1.

3. Derive digest2 (i.e., authKey): Concatenate authoritative SNMP engine ID and digest1 and hash with the same algorithm: • authKey = H(concatenate (digest1, authoritativeSnmpEngineID, digest1))

• authKey is the user’s localized key.



48

Authentication KeyLocalization and Update

• Localized key: secret key shared between a user and one authoritative engine

• Key localization: process by which a single user key is converted into multiple unique keys, one for each remote SNMP engine.

• A single user key is mapped by means of nonreversible one-way function (a secure hash function) into different localized keys for different authenticated engines (agents).

• The localized key is stored in the authoritative engine

• SNMPv3 permits the operation of changes and modification in keys, but not creation of keys, to ensure that the secret key does not become stale.



49

Notes

Authentication Parameters• Authentication parameter is Hashed Message Access Code (HMAC)

• HMAC is 96-bit long (12 octets)

• Derived from authentication key (authKey)

HMAC Procedure:1. Derive extendedAuthKey: Supplement authKey with 0s to get 64-byte string

2. Define ipad, opad, K1, and K2: ipad = 0x36 (00110110) repeated 64 times opad = 0x5c (01011100) repeated 64 times K1 = extendedAuthKey XOR ipad K2 = extendedAuthKey XOR opad

3. Derive HMAC by hashing algorithm used HMAC = H (K2, H (K1, wholeMsg))



50

Access Control(RFC 3415)

• View-based Access Control Model has 5 elements:

• Groups: A group is a set of zero or more <securityModel, securityName> tuples. E.g., In SNMPv1 model, the security name is the community name.

• Security Level• no authentication - no privacy• authentication - no privacy• authentication - privacy

• Contexts: Names of the context

• MIB Views and View Families• MIB view is a combination of view subtrees

• Access Policy• read-view• write-view• notify-view• not-accessible



51

Notes

VACM Process

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?



52

VCAM Process

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 TreeFamilyTable

View Nameread/write/notify

Yes / No

noGroupName

noSuchContext

noAccessEntrynoSuchView

AccessAllowed

notInView

noSuchView

ObjectType

ObjectInstance

View Type

Figure 7.16 VACM Process



53

Notes

VACM MIB

• Four tables used to achieve access control

• Group defined by security-to-group table

• Context defined by context table

• Access table determines access allowed and the view name

• View tree family table determines the MIB view, which is very flexible

vacmContextTable(1)

vacmViewSpinLock(1)

Figure 7.17 VACM MIB

vacmSecurityToGroupTable(2)

vacmMIBObjects(1)

vacmAccessTable(4)

vacmMIBViews(5)

vacmViewTreeFamilyAccessTable(2)

snmpVacmMIB(snmpModules 16)



54

Notes

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



55

Notes

VACM MIB View

vacmViewTreeFamilyTable(2)

vacmViewTreeFamilyEntry(1)

Figure 7.19 VACM MIB Views

vacmViewTreeFamilyViewName (1)

vacmViewTreeFamilySubtree (2)

vacmViewTreeFamilyMask (3)

vacmViewTreeFamilyStatus (6)

vacmViewTreeFamilyStorageType (5)

vacmViewTreeFamilyType(4)

vacmMIBViews(vacmMIBObjects 5)

vacmViewSpinLock(1)

Example:

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)



56

chapter 7 snmp management: snmpv3 chapter 7 snmp management: snmpv3 1 network management: principles...

Documents

snmp management element

snmpengineid snmp engine

management information

snmp engineentity

octetnetwork management

snmpv3 snmp entity

practice mani subramanian

snmpv3 length