Session-based Security Model for SNMPv3 (SNMPv3/SBSM)

David T. Perkins

Wes Hardaker

IETF

November 12, 2003

Nov 12, 2003 IETF 2

Goals

• Lower the cost of deployment and ongoing operation of SNMPv3 by using existing security infrastructure(s) for identification authentication

• Provide additional security features not currently found in SNMPv3 with USM

• Conform to the security model guidelines of the SNMPv3 architecture. (That is, NO changes to ANY SNMPv3 RFC!)

Nov 12, 2003 IETF 3

SNMPv3 Background

• SNMPv3 is an application layer protocol for management, which provides:– Configuration creation, deletion, and modification– Monitoring– Performing actions– Event reporting

• SNMPv3 was designed to allow pluggable security models (that is, SBSM is a new security model conforming with SNMPv3’s architecture)

Nov 12, 2003 IETF 4

SNMP Management Model

• The SNMP management model contains:– Several (typically many) managed systems

with an entity (an agent) that provides access to management information

– At least one SNMP entity (a manager) that runs management applications

– A management protocol– Management information

Nov 12, 2003 IETF 5

Managed Networks

A managed network consists of one (or more) management domains (which may overlap)

Domain “A” Domain “B” Domain “C”manager

managedsystem

Nov 12, 2003 IETF 6

Security In SNMPv3

Security is viewed as being applied at two different stages:

• Transmission/receipt of messages, which is called by SNMP a “security model”

• Processing the content of messages, which is called by SNMP an “access control model”

Presently, only one security model is defined, which is called User Security Model (USM)

SBSM is a new SNMP security model

Nov 12, 2003 IETF 7

SNMP Security at Message Level

• Services provided:– Identity authentication of the message sender– Message authentication (data integrity; replay,

re-order, and delay protection)– Disclosure protection (encryption)

• Set of services provided is called thesecurity level, with values:– noAuthNoPriv: no authentication and no encryption– authNoPriv: authentication, but no encryption– authPriv: authentication and encryption

Nov 12, 2003 IETF 8

SNMP Access Control• Authorization rules for access to management

information based on:– Operation type: “Get”, “Set”, and “Notification”– Management info: object type and optionally instance– Security level: noAuthNoPriv, authNoPriv, authPriv– Identity (called security name) and security model type

• Presently, only one access control model is defined, which is called VACM (view-based access control model)

SBSM result must work with VACM

Nov 12, 2003 IETF 9

SNMPv3 Message Format

msgVersion msgGlobalData msgSecurityParms msgData

msgID msgMaxSize msgFlags msgSecurityModel

New value for SBSM

New format for SBSM

(No change for SBSM), present legal values are:'100'b - a noAuthNoPriv request'000'b - a noAuthNoPriv response or unacknowledged notification'101'b - an authNoPriv request '001'b - an authNoPriv response or unacknowledged notification '111'b - an authPriv request '011'b - an authPriv response or unacknowledged notification

Nothing changed

to support SBSM (no

new PDUs)

Nov 12, 2003 IETF 10

USM Characteristics

• Combines sender identity authentication with message authentication

• Sender identity shared between manager and agent (that is, single identity authentication)

• By convention, a single pass phrase per user in a management domain is used to create a unique identity (and message) authentication key (and encryption key) per managed system

Nov 12, 2003 IETF 11

USM Characteristics(cont.)

• Message authentication and privacy keys are “reused” and long lived, since it is expensive to change user passwords

• User identity authentication entirely unique to SNMPv3/USM

Nov 12, 2003 IETF 12

SBSM Requirements

Related to Using Existing Security Infrastructures

• Must use existing security infrastructures for identity authentication (should support many)

• Must have a low incremental cost to add a new identity authentication mechanism

Nov 12, 2003 IETF 13

SBSM Requirements (cont)

Related to Additional Security Features• Must support authentication of both ends of the

message exchange, and allow use of a different mechanism by each end (including “anonymous” identity)

• When session establishment is initiated by a manager, the agent must reveal its identity and authenticate before the manager (note that identities must be encrypted)

Nov 12, 2003 IETF 14

SBSM Requirements (cont)• Must separate security mechanism used for

identity authentication from that used for message authentication and encryption

• Must support limited life time keys for message authentication and encryption

• Must support at session establishment negotiation of the algorithms used for session message authentication and encryption

• Must have a low incremental cost to add a new session message authentication or encryption algorithm

Nov 12, 2003 IETF 15

SBSM Requirements (cont)

• Must support no reprocessing of messages that are duplicated or replayed (reduces cost of packet loss – processing and latency)

• Must operate over connection oriented and connectionless transports

• Must work with unmodified VACM• Must have a low incremental cost to add new

security features such as capability-based authorization

Nov 12, 2003 IETF 16

Consequences of Requirements

• Very low cost to create new identities, change their authentication credentials, or delete, since provided by existing security infrastructure

• Saved encrypted messages can not be decrypted after identity credentials are compromised

Nov 12, 2003 IETF 17

Deployment and Initialization

• Putting a new device into operation, may require:– Creating X.509 certs– Creating SSH server keys– Setup for Radius (shared key, device identity,

Radius server address) (Similar for TACACS+) – Creating an “administrative user” and password– Specifying authorization rules (access control

policies)

Nov 12, 2003 IETF 18

Ongoing Operation

• Adding a new user– Create an Identity, specify credentials for identity

authentication– Assignment of authorized activities

• Changing a user’s authentication credentials• Changing authorization policies• Deleting a user• Suspending a user’s account• Auditing and billing

Nov 12, 2003 IETF 19

Deployment of aNew System with USM

• Activities to support other access(es) (depends on what is supported)

• SNMP engineID assignment

• Addition of all existing users to the USM MIB tables for the SNMP agent (requires access to each user’s password)

• Configuration of VACM MIB tables

Nov 12, 2003 IETF 20

Ongoing Operation with USM

• New user requires adding the user to the USM MIB tables for each agent in the domain, and the value of the user’s password to add the user keys. Also, must add the user to VACM’s “toGroup” table in each agent.

• Change of a user’s password requires access to the password and an update of the auth and priv keys on every agent in a management domain

Nov 12, 2003 IETF 21

Ongoing Ops with USM (cont)

• Changing authorization rules requires update of VACM MIB for all agents in a management domain

• Deleting a user requires modification of the USM MIB tables for all agents in a management domain, and an update of VACM’s “toGroup” table

• Suspending a user requires update of VACM’s “toGroup” table for all agents in a management domain

Nov 12, 2003 IETF 22

Deployment of aNew System with SBSM

• Activities to support other access(es) (depends on what is supported)

• SNMP engineID assignment• Configuration of VACM MIB tables

Note: no need to know every user and their “SNMP password”

Nov 12, 2003 IETF 23

Ongoing Operation with SBSM

• New user requires adding the user to VACM’s “toGroup” table in each agent

Note: no need for user password or additions to USM MIB tables

• Change of a user’s password requires no SNMP related modifications

Note: password update done via mechanisms in existing security infrastructure

Nov 12, 2003 IETF 24

Ongoing Ops with SBSM (cont)

• Changing authorization rules requires update of VACM MIB for all agents in a management domain

• Deleting a user requires update of VACM’s “toGroup” table for all agents in a management domain

• Suspending a user requires update of VACM’s “toGroup” table for all agents in a management domain

Nov 12, 2003 IETF 25

End of Introduction

Questions