Session-based Security Model
for SNMPv3 (SNMPv3/SBSM)
David T. Perkins
Wes Hardaker
IETF
November 12, 2003
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
2
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
3
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
4
Managed Networks
A managed network consists of one (or
more) management domains (which
may overlap)
Domain “A”
Domain “B”
Domain “C”
manager
managed
system
Nov 12, 2003
IETF
5
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
6
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 the
security level, with values:
– noAuthNoPriv: no authentication and no encryption
– authNoPriv: authentication, but no encryption
– authPriv: authentication and encryption
Nov 12, 2003
IETF
7
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
8
SNMPv3 Message Format
msgVersion msgGlobalData msgSecurityParms msgData
msgID msgMaxSize msgFlags msgSecurityModel
(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
Nov 12, 2003
IETF
New format
for SBSM
New value
for SBSM
Nothing
changed
to
support
SBSM
(no new
PDUs)
9
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
10
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
11
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
12
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
13
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
14
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
15
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
16
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
17
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
18
Deployment of a
New 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
19
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
20
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
21
Deployment of a
New 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
22
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
23
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
24
End of Introduction
Questions
Nov 12, 2003
IETF
25