As per Relevance of the word password, we have this rfc below:
Network Working Group U.
Request for Comments: 2574 IBM T. J. Watson
Obsoletes: 2274 B.
Category: Standards Track IBM T. J. Watson
April 1999
User-based Security Model (USM) for version 3 of
Simple Network Management Protocol (SNMPv3)
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (1999). All Rights Reserved
This document describes the User-based Security Model (USM) for
version 3 for use in the SNMP architecture [RFC2571]. It defines
Elements of Procedure for providing SNMP message level security
This document also includes a MIB for remotely monitoring/
the configuration parameters for this Security Model
Table of
1. Introduction 3
1.1. Threats 4
1.2. Goals and Constraints 5
1.3. Security Services 6
1.4. Module Organization 7
1.4.1. Timeliness Module 7
1.4.2. Authentication Protocol 8
1.4.3. Privacy Protocol 8
1.5. Protection against Message Replay, Delay and Redirection 8
1.5.1. Authoritative SNMP engine 8
1.5.2. Mechanisms 9
1.6. Abstract Service Interfaces 10
1.6.1. User-based Security Model Primitives for Authentication 11
1.6.2. User-based Security Model Primitives for Privacy 11
2. Elements of the Model 12
2.1. User-based Security Model Users 12
Blumenthal & Wijnen Standards Track [Page 1]
RFC 2574 USM for SNMPv3 April 1999
2.2. Replay Protection 13
2.2.1. msgAuthoritativeEngineID 13
2.2.2. msgAuthoritativeEngineBoots and msgAuthoritativeEngineTime14
2.2.3. Time Window 15
2.3. Time Synchronization 15
2.4. SNMP Messages Using this Security Model 16
2.5. Services provided by the User-based Security Model 17
2.5.1. Services for Generating an Outgoing SNMP Message 17
2.5.2. Services for Processing an Incoming SNMP Message 19
2.6. Key Localization Algorithm. 21
3. Elements of Procedure 21
3.1. Generating an Outgoing SNMP Message 22
3.2. Processing an Incoming SNMP Message 25
4. Discovery 30
5. Definitions 31
6. HMAC-MD5-96 Authentication Protocol 50
6.1. Mechanisms 50
6.1.1. Digest Authentication Mechanism 50
6.2. Elements of the Digest Authentication Protocol 51
6.2.1. Users 51
6.2.2. msgAuthoritativeEngineID 51
6.2.3. SNMP Messages Using this Authentication Protocol 51
6.2.4. Services provided by the HMAC-MD5-96 Authentication Module52
6.2.4.1. Services for Generating an Outgoing SNMP Message 52
6.2.4.2. Services for Processing an Incoming SNMP Message 53
6.3. Elements of Procedure 53
6.3.1. Processing an Outgoing Message 54
6.3.2. Processing an Incoming Message 54
7. HMAC-SHA-96 Authentication Protocol 55
7.1. Mechanisms 55
7.1.1. Digest Authentication Mechanism 56
7.2. Elements of the HMAC-SHA-96 Authentication Protocol 56
7.2.1. Users 56
7.2.2. msgAuthoritativeEngineID 57
7.2.3. SNMP Messages Using this Authentication Protocol 57
7.2.4. Services provided by the HMAC-SHA-96 Authentication Module57
7.2.4.1. Services for Generating an Outgoing SNMP Message 57
7.2.4.2. Services for Processing an Incoming SNMP Message 58
7.3. Elements of Procedure 59
7.3.1. Processing an Outgoing Message 59
7.3.2. Processing an Incoming Message 60
8. CBC-DES Symmetric Encryption Protocol 61
8.1. Mechanisms 61
8.1.1. Symmetric Encryption Protocol 61
8.1.1.1. DES key and Initialization Vector. 62
8.1.1.2. Data Encryption. 63
8.1.1.3. Data Decryption 63
8.2. Elements of the DES Privacy Protocol 63
Blumenthal & Wijnen Standards Track [Page 2]
RFC 2574 USM for SNMPv3 April 1999
8.2.1. Users 63
8.2.2. msgAuthoritativeEngineID 64
8.2.3. SNMP Messages Using this Privacy Protocol 64
8.2.4. Services provided by the DES Privacy Module 64
8.2.4.1. Services for Encrypting Outgoing Data 64
8.2.4.2. Services for Decrypting Incoming Data 65
8.3. Elements of Procedure. 66
8.3.1. Processing an Outgoing Message 66
8.3.2. Processing an Incoming Message 66
9. Intellectual Property 67
10. Acknowledgements 67
11. Security Considerations 69
11.1. Recommended Practices 69
11.2. Defining Users 71
11.3. Conformance 72
11.4. Use of Reports 72
11.5. Access to the SNMP-USER-BASED-SM-MIB 72
12. References 73
13. Editors' Addresses 75
A.1. SNMP engine Installation Parameters 76
A.2. Password to Key Algorithm 78
A.2.1. Password to Key Sample Code for MD5 79
A.2.2. Password to Key Sample Code for SHA 80
A.3. Password to Key Sample Results 81
A.3.1. Password to Key Sample Results using MD5 81
A.3.2. Password to Key Sample Results using SHA 81
A.4. Sample encoding of msgSecurityParameters 82
A.5. Sample keyChange Results 83
A.5.1. Sample keyChange Results using MD5 83
A.5.2. Sample keyChange Results using SHA 84
B. Change Log 85
C. Full Copyright Statement 86
1.
The Architecture for describing Internet Management
[RFC2571] describes that an SNMP engine is composed of
1) a
2) a Message Processing Subsystem
3) a Security Subsystem,
4) an Access Control Subsystem
Applications make use of the services of these subsystems
It is important to understand the SNMP architecture and
terminology of the architecture to understand where the
Model described in this document fits into the architecture
Blumenthal & Wijnen Standards Track [Page 3]
RFC 2574 USM for SNMPv3 April 1999
interacts with other subsystems within the architecture. The
is expected to have read and understood the description of the
architecture, as defined in [RFC2571].
This memo [RFC2274] describes the User-based Security Model as it
used within the SNMP Architecture. The main idea is that we use
traditional concept of a user (identified by a userName) with
to associate security information
This memo describes the use of HMAC-MD5-96 and HMAC-SHA-96 as
authentication protocols and the use of CBC-DES as the
protocol. The User-based Security Model however allows for other
protocols to be used instead of or concurrent with these protocols
Therefore, the description of HMAC-MD5-96, HMAC-SHA-96 and CBC-
are in separate sections to reflect their self-contained nature
to indicate that they can be replaced or supplemented in the future
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
document are to be interpreted as described in [RFC2119].
1.1.
Several of the classical threats to network protocols are
to the network management problem and therefore would be
to any SNMP Security Model. Other threats are not applicable to
network management problem. This section discusses
threats, secondary threats, and threats which are of
importance
The principal threats against which this SNMP Security Model
provide protection are
- Modification of
The modification threat is the danger that some unauthorized
may alter in-transit SNMP messages generated on behalf of
authorized principal in such a way as to effect
management operations, including falsifying the value of an object
-
The masquerade threat is the danger that management operations
authorized for some user may be attempted by assuming the
of another user that has the appropriate authorizations
Two secondary threats are also identified. The Security
defined in this memo provides limited protection against
Blumenthal & Wijnen Standards Track [Page 4]
RFC 2574 USM for SNMPv3 April 1999
-
The disclosure threat is the danger of eavesdropping on
exchanges between managed agents and a management station
Protecting against this threat may be required as a matter of
policy
- Message Stream
The SNMP protocol is typically based upon a connection-
transport service which may operate over any sub-network service
The re-ordering, delay or replay of messages can and does
through the natural operation of many such sub-network services
The message stream modification threat is the danger that
may be maliciously re-ordered, delayed or replayed to an
which is greater than can occur through the natural operation of
sub-network service, in order to effect unauthorized
operations
There are at least two threats that an SNMP Security Model need
protect against. The security protocols defined in this memo do
provide protection against
- Denial of
This SNMP Security Model does not attempt to address the
range of attacks by which service on behalf of authorized users
denied. Indeed, such denial-of-service attacks are in many
indistinguishable from the type of network failures with which
viable network management protocol must cope as a matter of course
- Traffic
This SNMP Security Model does not attempt to address
analysis attacks. Indeed, many traffic patterns are predictable -
devices may be managed on a regular basis by a relatively
number of management applications - and therefore there is
significant advantage afforded by protecting against
analysis
1.2. Goals and
Based on the foregoing account of threats in the SNMP
management environment, the goals of this SNMP Security Model are
follows
1) Provide for verification that each received SNMP message
not been modified during its transmission through the network
2) Provide for verification of the identity of the user on
behalf a received SNMP message claims to have been generated
Blumenthal & Wijnen Standards Track [Page 5]
RFC 2574 USM for SNMPv3 April 1999
3) Provide for detection of received SNMP messages, which
or contain management information, whose time of generation
not recent
4) Provide, when necessary, that the contents of each
SNMP message are protected from disclosure
In addition to the principal goal of supporting secure
management, the design of this SNMP Security Model is also
by the following constraints
1) When the requirements of effective management in times
network stress are inconsistent with those of security, the
should prefer the former
2) Neither the security protocol nor its underlying
mechanisms should depend upon the ready availability of
network services (e.g., Network Time Protocol (NTP) or
management protocols).
3) A security mechanism should entail no changes to the
SNMP network management philosophy
1.3. Security
The security services necessary to support the goals of this
Security Model are as follows
- Data
is the provision of the property that data has not been altered
destroyed in an unauthorized manner, nor have data sequences
altered to an extent greater than can occur non-maliciously
- Data Origin
is the provision of the property that the claimed identity of
user on whose behalf received data was originated is corroborated
- Data
is the provision of the property that information is not
available or disclosed to unauthorized individuals, entities,
processes
- Message timeliness and limited replay
is the provision of the property that a message whose
time is outside of a specified time window is not accepted.
that message reordering is not dealt with and can occur in
conditions too
Blumenthal & Wijnen Standards Track [Page 6]
RFC 2574 USM for SNMPv3 April 1999
For the protocols specified in this memo, it is not possible
assure the specific originator of a received SNMP message; rather,
is the user on whose behalf the message was originated that
authenticated
For these protocols, it not possible to obtain data integrity
data origin authentication, nor is it possible to obtain data
authentication without data integrity. Further, there is
provision for data confidentiality without both data integrity
data origin authentication
The security protocols used in this memo are considered
secure at the time of writing. However, the procedures allow for
authentication and privacy methods to be specified at a future
if the need arises
1.4. Module
The security protocols defined in this memo are split in
different modules and each has its specific responsibilities
that together they realize the goals and security services
above
- The authentication module MUST provide for
- Data Integrity
- Data Origin
- The timeliness module MUST provide for
- Protection against message delay or replay (to an
greater than can occur through normal operation
- The privacy module MUST provide
- Protection against disclosure of the message payload
The timeliness module is fixed for the User-based Security
while there is provision for multiple authentication and/or
modules, each of which implements a specific authentication
privacy protocol respectively
1.4.1. Timeliness
Section 3 (Elements of Procedure) uses the timeliness values in
SNMP message to do timeliness checking. The timeliness check is
performed if authentication is applied to the message. Since
Blumenthal & Wijnen Standards Track [Page 7]
RFC 2574 USM for SNMPv3 April 1999
complete message is checked for integrity, we can assume that
timeliness values in a message that passes the authentication
are trustworthy
1.4.2. Authentication
Section 6 describes the HMAC-MD5-96 authentication protocol which
the first authentication protocol that MUST be supported with
User-based Security Model. Section 7 describes the HMAC-SHA-96
authentication protocol which is another authentication protocol
SHOULD be supported with the User-based Security Model. In
future additional or replacement authentication protocols may
defined as new needs arise
The User-based Security Model prescribes that, if authentication
used, then the complete message is checked for integrity in
authentication module
For a message to be authenticated, it needs to pass
check by the authentication module and the timeliness check which
a fixed part of this User-based Security model
1.4.3. Privacy
Section 8 describes the CBC-DES Symmetric Encryption Protocol
is the first privacy protocol to be used with the User-based
Model. In the future additional or replacement privacy protocols
be defined as new needs arise
The User-based Security Model prescribes that the scopedPDU
protected from disclosure when a message is sent with privacy
The User-based Security Model also prescribes that a message needs
be authenticated if privacy is in use
1.5. Protection against Message Replay, Delay and
1.5.1. Authoritative SNMP
In order to protect against message replay, delay and redirection
one of the SNMP engines involved in each communication is
to be the authoritative SNMP engine. When an SNMP message contains
payload which expects a response (those messages that contain
Confirmed Class PDU [RFC2571]), then the receiver of such messages
authoritative. When an SNMP message contains a payload which
not expect a response (those messages that contain an
Class PDU [RFC2571]), then the sender of such a message
authoritative
Blumenthal & Wijnen Standards Track [Page 8]
RFC 2574 USM for SNMPv3 April 1999
1.5.2.
The following mechanisms are used
1) To protect against the threat of message delay or replay (to
extent greater than can occur through normal operation), a set
timeliness indicators (for the authoritative SNMP engine)
included in each message generated. An SNMP engine evaluates
timeliness indicators to determine if a received message
recent. An SNMP engine may evaluate the timeliness indicators
ensure that a received message is at least as recent as the
message it received from the same source. A non-
SNMP engine uses received authentic messages to advance its
of the timeliness indicators at the remote authoritative source
An SNMP engine MUST also use a mechanism to match
Responses to outstanding Requests and it MUST drop any
that do not match an outstanding request. For example, a msgID
be inserted in every message to cater for this functionality
These mechanisms provide for the detection of
messages whose time of generation was not recent
This protection against the threat of message delay or replay
not imply nor provide any protection against unauthorized
or suppression of messages. Also, an SNMP engine may not be
to detect message reordering if all the messages involved are
within the Time Window interval. Other mechanisms
independently of the security protocol can also be used to
the re-ordering replay, deletion, or suppression of
containing Set operations (e.g., the MIB variable
[RFC1907]).
2) Verification that a message sent to/from one authoritative
engine cannot be replayed to/as-if-from another authoritative
engine
Included in each message is an identifier unique to
authoritative SNMP engine associated with the sender or
recipient of the message
A message containing an Unconfirmed Class PDU sent by
authoritative SNMP engine to one non-authoritative SNMP engine
potentially be replayed to another non-authoritative SNMP engine
The latter non-authoritative SNMP engine might (if it knows
the same userName with the same secrets at the authoritative
engine) as a result update its notion of timeliness indicators
the authoritative SNMP engine, but that is not considered
Blumenthal & Wijnen Standards Track [Page 9]
RFC 2574 USM for SNMPv3 April 1999
threat. In this case, A Report or Response message will
discarded by the Message Processing Model, because there
not be an outstanding Request message. A Trap will possibly
accepted. Again, that is not considered a threat, because
communication was authenticated and timely. It is as if
authoritative SNMP engine was configured to start sending Traps
the second SNMP engine, which theoretically can happen without
knowledge of the second SNMP engine anyway. Anyway, the
SNMP engine may not expect to receive this Trap, but is allowed
see the management information contained in it
3) Detection of messages which were not recently generated
A set of time indicators are included in the message,
the time of generation. Messages without recent time
are not considered authentic. In addition, an SNMP engine
drop any Responses that do not match an outstanding request.
however is the responsibility of the Message Processing Model
This memo allows the same user to be defined on multiple
engines. Each SNMP engine maintains a value, snmpEngineID,
uniquely identifies the SNMP engine. This value is included in
message sent to/from the SNMP engine that is authoritative (
section 1.5.1). On receipt of a message, an authoritative
engine checks the value to ensure that it is the intended recipient
and a non-authoritative SNMP engine uses the value to ensure that
message is processed using the correct state information
Each SNMP engine maintains two values, snmpEngineBoots
snmpEngineTime, which taken together provide an indication of time
that SNMP engine. Both of these values are included in
authenticated message sent to/received from that SNMP engine.
receipt, the values are checked to ensure that the
timeliness value is within a Time Window of the current time.
Time Window represents an administrative upper bound on
delivery delay for protocol messages
For an SNMP engine to generate a message which an authoritative
engine will accept as authentic, and to verify that a
received from that authoritative SNMP engine is authentic, such
SNMP engine must first achieve timeliness synchronization with
authoritative SNMP engine. See section 2.3.
1.6. Abstract Service
Abstract service interfaces have been defined to describe
conceptual interfaces between the various subsystems within an
entity. Similarly a set of abstract service interfaces have
Blumenthal & Wijnen Standards Track [Page 10]
RFC 2574 USM for SNMPv3 April 1999
defined within the User-based Security Model (USM) to describe
conceptual interfaces between the generic USM services and the self
contained authentication and privacy services
These abstract service interfaces are defined by a set of
that define the services provided and the abstract data elements
must be passed when the services are invoked. This section lists
primitives that have been defined for the User-based Security Model
1.6.1. User-based Security Model Primitives for
The User-based Security Model provides the following
primitives to pass data back and forth between the Security
itself and the authentication service
statusInformation =
authenticateOutgoingMsg
IN authKey -- secret key for
IN wholeMsg -- unauthenticated complete
OUT authenticatedWholeMsg -- complete authenticated
)
statusInformation =
authenticateIncomingMsg
IN authKey -- secret key for
IN authParameters -- as received on the
IN wholeMsg -- as received on the
OUT authenticatedWholeMsg -- complete authenticated
)
1.6.2. User-based Security Model Primitives for
The User-based Security Model provides the following
primitives to pass data back and forth between the Security
itself and the privacy service
statusInformation =
encryptData
IN encryptKey -- secret key for
IN dataToEncrypt -- data to encrypt (scopedPDU
OUT encryptedData -- encrypted data (encryptedPDU
OUT privParameters -- filled in by service
)
statusInformation =
decryptData
IN decryptKey -- secret key for
IN privParameters -- as received on the
Blumenthal & Wijnen Standards Track [Page 11]
RFC 2574 USM for SNMPv3 April 1999
IN encryptedData -- encrypted data (encryptedPDU
OUT decryptedData -- decrypted data (scopedPDU
)
2. Elements of the
This section contains definitions required to realize the
model defined by this memo
2.1. User-based Security Model
Management operations using this Security Model make use of a
set of user identities. For any user on whose behalf
operations are authorized at a particular SNMP engine, that
engine must have knowledge of that user. An SNMP engine that
to communicate with another SNMP engine must also have knowledge of
user known to that engine, including knowledge of the
attributes of that user
A user and its attributes are defined as follows
A string representing the name of the user
A human-readable string representing the user in a format that
Security Model independent
An indication of whether messages sent on behalf of this user
be authenticated, and if so, the type of authentication
which is used. Two such protocols are defined in this memo
- the HMAC-MD5-96 authentication protocol
- the HMAC-SHA-96 authentication protocol
If messages sent on behalf of this user can be authenticated
the (private) authentication key for use with the
protocol. Note that a user's authentication key will
be different at different authoritative SNMP engines. The
is not accessible via SNMP. The length requirements of the
are defined by the authProtocol in use
authKeyChange and
The only way to remotely update the authentication key.
that in a secure manner, so that the update can be
without the need to employ privacy protection
Blumenthal & Wijnen Standards Track [Page 12]
RFC 2574 USM for SNMPv3 April 1999
An indication of whether messages sent on behalf of this
can be protected from disclosure, and if so, the type of
protocol which is used. One such protocol is defined in
memo: the CBC-DES Symmetric Encryption Protocol
If messages sent on behalf of this user can be en/decrypted
the (private) privacy key for use with the privacy protocol
Note that a user's privacy key will normally be different
different authoritative SNMP engines. The privKey is
accessible via SNMP. The length requirements of the privKey
defined by the privProtocol in use
privKeyChange and
The only way to remotely update the encryption key. Does
in a secure manner, so that the update can be completed
the need to employ privacy protection
2.2. Replay
Each SNMP engine maintains three objects
- snmpEngineID, which (at least within an administrative domain
uniquely and unambiguously identifies an SNMP engine
- snmpEngineBoots, which is a count of the number of times
SNMP engine has re-booted/re-initialized since
was last configured; and
- snmpEngineTime, which is the number of seconds since
snmpEngineBoots counter was last incremented
Each SNMP engine is always authoritative with respect to
objects in its own SNMP entity. It is the responsibility of
non-authoritative SNMP engine to synchronize with
authoritative SNMP engine, as appropriate
An authoritative SNMP engine is required to maintain the values
its snmpEngineID and snmpEngineBoots in non-volatile storage
2.2.1.
The msgAuthoritativeEngineID value contained in an
message is used to defeat attacks in which messages from one
engine to another SNMP engine are replayed to a different
engine. It represents the snmpEngineID at the authoritative
engine involved in the exchange of the message
Blumenthal & Wijnen Standards Track [Page 13]
RFC 2574 USM for SNMPv3 April 1999
When an authoritative SNMP engine is first installed, it sets
local value of snmpEngineID according to a enterprise-
algorithm (see the definition of the Textual Convention
SnmpEngineID in the SNMP Architecture document [RFC2571]).
2.2.2. msgAuthoritativeEngineBoots and
The msgAuthoritativeEngineBoots and
values contained in an authenticated message are used to
attacks in which messages are replayed when they are no
valid. They represent the snmpEngineBoots and
values at the authoritative SNMP engine involved in the
of the message
Through use of snmpEngineBoots and snmpEngineTime, there is
requirement for an SNMP engine to have a non-volatile clock
ticks (i.e., increases with the passage of time) even when
SNMP engine is powered off. Rather, each time an SNMP
re-boots, it retrieves, increments, and then stores
in non-volatile storage, and resets snmpEngineTime to zero
When an SNMP engine is first installed, it sets its local
of snmpEngineBoots and snmpEngineTime to zero. If
ever reaches its maximum value (2147483647), then
is incremented as if the SNMP engine has re-booted
snmpEngineTime is reset to zero and starts incrementing again
Each time an authoritative SNMP engine re-boots, any SNMP
holding that authoritative SNMP engine's values of
and snmpEngineTime need to re-synchronize prior to
correctly authenticated messages to that authoritative SNMP
(see Section 2.3 for (re-)synchronization procedures). Note
however, that the procedures do provide for a notification to
accepted as authentic by a receiving SNMP engine, when sent by
authoritative SNMP engine which has re-booted since the
SNMP engine last (re-)synchronized
If an authoritative SNMP engine is ever unable to determine
latest snmpEngineBoots value, then it must set its
value to 2147483647.
Whenever the local value of snmpEngineBoots has the value 2147483647
it latches at that value and an authenticated message always
an notInTimeWindow authentication failure
In order to reset an SNMP engine whose snmpEngineBoots value
reached the value 2147483647, manual intervention is required
The engine must be physically visited and re-configured,
Blumenthal & Wijnen Standards Track [Page 14]
RFC 2574 USM for SNMPv3 April 1999
with a new snmpEngineID value, or with new secret values for
authentication and privacy protocols of all users known to
SNMP engine. Note that even if an SNMP engine re-boots once a
that it would still take approximately 68 years before the max
of 2147483647 would be reached
2.2.3. Time
The Time Window is a value that specifies the window of time
which a message generated on behalf of any user is valid.
memo specifies that the same value of the Time Window, 150 seconds
is used for all users
2.3. Time
Time synchronization, required by a non-authoritative SNMP
in order to proceed with authentic communications, has
when the non-authoritative SNMP engine has obtained a local
of the authoritative SNMP engine's values of snmpEngineBoots
snmpEngineTime from the authoritative SNMP engine. These
must be (and remain) within the authoritative SNMP engine's
Window. So the local notion of the authoritative SNMP engine'
values must be kept loosely synchronized with the values
at the authoritative SNMP engine. In addition to keeping a
copy of snmpEngineBoots and snmpEngineTime from the
SNMP engine, a non-authoritative SNMP engine must also keep
local variable, latestReceivedEngineTime. This value records
highest value of snmpEngineTime that was received by
non-authoritative SNMP engine from the authoritative SNMP
and is used to eliminate the possibility of replaying
that would prevent the non-authoritative SNMP engine's notion
the snmpEngineTime from advancing
A non-authoritative SNMP engine must keep local notions of
(snmpEngineBoots, snmpEngineTime and latestReceivedEngineTime
for each authoritative SNMP engine with which it wishes
communicate. Since each authoritative SNMP engine is
and unambiguously identified by its value of snmpEngineID,
non-authoritative SNMP engine may use this value as a key
order to cache its local notions of these values
Time synchronization occurs as part of the procedures of
an SNMP message (Section 3.2, step 7b). As such, no explicit
synchronization procedure is required by a non-authoritative
engine. Note, that whenever the local value of snmpEngineID
changed (e.g., through discovery) or when secure
are first established with an authoritative SNMP engine, the
Blumenthal & Wijnen Standards Track [Page 15]
RFC 2574 USM for SNMPv3 April 1999
values of snmpEngineBoots and latestReceivedEngineTime should
set to zero. This will cause the time synchronization to
when the next authentic message is received
2.4. SNMP Messages Using this Security
The syntax of an SNMP message using this Security Model
to the message format defined in the version-specific
Processing Model document (for example [RFC2572]).
The field msgSecurityParameters in SNMPv3 messages has a data
of OCTET STRING. Its value is the BER serialization of
following ASN.1 sequence
USMSecurityParametersSyntax DEFINITIONS IMPLICIT TAGS ::=
UsmSecurityParameters ::=
SEQUENCE {
-- global User-based security
msgAuthoritativeEngineID OCTET STRING
msgAuthoritativeEngineBoots INTEGER (0..2147483647),
msgAuthoritativeEngineTime INTEGER (0..2147483647),
msgUserName OCTET STRING (SIZE(0..32)),
-- authentication protocol specific
msgAuthenticationParameters OCTET STRING
-- privacy protocol specific
msgPrivacyParameters OCTET
}
The fields of this sequence are
- The msgAuthoritativeEngineID specifies the snmpEngineID of
authoritative SNMP engine involved in the exchange of the message
- The msgAuthoritativeEngineBoots specifies the snmpEngineBoots
at the authoritative SNMP engine involved in the exchange of
message
- The msgAuthoritativeEngineTime specifies the snmpEngineTime
at the authoritative SNMP engine involved in the exchange of
message
- The msgUserName specifies the user (principal) on whose behalf
message is being exchanged. Note that a zero-length userName
not match any user, but it can be used for snmpEngineID discovery
Blumenthal & Wijnen Standards Track [Page 16]
RFC 2574 USM for SNMPv3 April 1999
- The msgAuthenticationParameters are defined by the
protocol in use for the message, as defined by
usmUserAuthProtocol column in the user's entry in the usmUserTable
- The msgPrivacyParameters are defined by the privacy protocol in
for the message, as defined by the usmUserPrivProtocol column
the user's entry in the usmUserTable).
See appendix A.4 for an example of the BER encoding of
msgSecurityParameters
2.5. Services provided by the User-based Security
This section describes the services provided by the User-
Security Model with their inputs and outputs
The services are described as primitives of an abstract
interface and the inputs and outputs are described as abstract
elements as they are passed in these abstract service primitives
2.5.1. Services for Generating an Outgoing SNMP
When the Message Processing (MP) Subsystem invokes the User-
Security module to secure an outgoing SNMP message, it must use
appropriate service as provided by the Security module. These
services are provided
1) A service to generate a Request message. The abstract
primitive is
statusInformation = -- success or
generateRequestMsg
IN messageProcessingModel -- typically, SNMP
IN globalData -- message header, admin
IN maxMessageSize -- of the sending SNMP
IN securityModel -- for the outgoing
IN securityEngineID -- authoritative SNMP
IN securityName -- on behalf of this
IN securityLevel -- Level of Security
IN scopedPDU -- message (plaintext)
OUT securityParameters -- filled in by Security
OUT wholeMsg -- complete generated
OUT wholeMsgLength -- length of generated
)
2) A service to generate a Response message. The abstract
primitive is
Blumenthal & Wijnen Standards Track [Page 17]
RFC 2574 USM for SNMPv3 April 1999
statusInformation = -- success or
generateResponseMsg
IN messageProcessingModel -- typically, SNMP
IN globalData -- message header, admin
IN maxMessageSize -- of the sending SNMP
IN securityModel -- for the outgoing
IN securityEngineID -- authoritative SNMP
IN securityName -- on behalf of this
IN securityLevel -- Level of Security
IN scopedPDU -- message (plaintext)
IN securityStateReference -- reference to security
-- information from
--
OUT securityParameters -- filled in by Security
OUT wholeMsg -- complete generated
OUT wholeMsgLength -- length of generated
)
The abstract data elements passed as parameters in the
service primitives are as follows
An indication of whether the encoding and securing of the
was successful. If not it is an indication of the problem
The SNMP version number for the message to be generated.
data is not used by the User-based Security module
The message header (i.e., its administrative information).
data is not used by the User-based Security module
The maximum message size as included in the message. This data
not used by the User-based Security module
These are the security parameters. They will be filled in by
User-based Security module
The securityModel in use. Should be User-based Security Model
This data is not used by the User-based Security module
Together with the snmpEngineID it identifies a row in
usmUserTable that is to be used for securing the message.
securityName has a format that is independent of the
Model. In case of a response this parameter is ignored and
value from the cache is used
Blumenthal & Wijnen Standards Track [Page 18]
RFC 2574 USM for SNMPv3 April 1999
The Level of Security from which the User-based Security
determines if the message needs to be protected from
and if the message needs to be authenticated
The snmpEngineID of the authoritative SNMP engine to which
Request message is to be sent. In case of a response it is
to be the processing SNMP engine's snmpEngineID and so if it
specified, then it is ignored
The message payload. The data is opaque as far as the User-
Security Model is concerned
A handle/reference to cachedSecurityData to be used when
an outgoing Response message. This is the exact
handle/reference as it was generated by the User-based
module when processing the incoming Request message to which
is the Response message
The fully encoded and secured message ready for sending on
wire
The length of the encoded and secured message (wholeMsg).
Upon completion of the process, the User-based Security
returns statusInformation. If the process was successful,
completed message with privacy and authentication applied if such
requested by the specified securityLevel is returned. If the
was not successful, then an errorIndication is returned
2.5.2. Services for Processing an Incoming SNMP
When the Message Processing (MP) Subsystem invokes the User-
Security module to verify proper security of an incoming message,
must use the service provided for an incoming message. The
service primitive is
statusInformation = -- errorIndication or
-- error counter OID/value if
processIncomingMsg
IN messageProcessingModel -- typically, SNMP
IN maxMessageSize -- of the sending SNMP
IN securityParameters -- for the received
IN securityModel -- for the received
IN securityLevel -- Level of
IN wholeMsg -- as received on the
IN wholeMsgLength -- length as received on the
OUT securityEngineID -- authoritative SNMP
Blumenthal & Wijnen Standards Track [Page 19]
RFC 2574 USM for SNMPv3 April 1999
OUT securityName -- identification of the
OUT scopedPDU, -- message (plaintext)
OUT maxSizeResponseScopedPDU -- maximum size of the Response
OUT securityStateReference -- reference to security
) -- information, needed for
The abstract data elements passed as parameters in the
service primitives are as follows
An indication of whether the process was successful or not.
not, then the statusInformation includes the OID and the value
the error counter that was incremented
The SNMP version number as received in the message. This data
not used by the User-based Security module
The maximum message size as included in the message. The User
based Security module uses this value to calculate
maxSizeResponseScopedPDU
These are the security parameters as received in the message
The securityModel in use. Should be the User-based
Model. This data is not used by the User-based Security module
The Level of Security from which the User-based Security
determines if the message needs to be protected from
and if the message needs to be authenticated
The whole message as it was received
The length of the message as it was received (wholeMsg).
The snmpEngineID that was extracted from the
msgAuthoritativeEngineID and that was used to lookup the
in the usmUserTable
The security name representing the user on whose behalf
message was received. The securityName has a format that
independent of the Security Model
The message payload. The data is opaque as far as the User-
Security Model is concerned
Blumenthal & Wijnen Standards Track [Page 20]
RFC 2574 USM for SNMPv3 April 1999
The maximum size of a scopedPDU to be included in a
Response message. The User-based Security module calculates
size based on the msgMaxSize (as received in the message) and
space required for the message header (including
securityParameters) for such a Response message
A handle/reference to cachedSecurityData to be used when
an outgoing Response message. When the Message
Subsystem calls the User-based Security module to generate
response to this incoming message it must pass
handle/reference
Upon completion of the process, the User-based Security
returns statusInformation and, if the process was successful,
additional data elements for further processing of the message.
the process was not successful, then an errorIndication,
with a OID and value pair of an error counter that was incremented
2.6. Key Localization Algorithm
A localized key is a secret key shared between a user U and
authoritative SNMP engine E. Even though a user may have only
password and therefore one key for the whole network, the
secrets shared between the user and each authoritative SNMP
will be different. This is achieved by key localization [Localized
key].
First, if a user uses a password, then the user's password
converted into a key Ku using one of the two algorithms described
Appendices A.2.1 and A.2.2.
To convert key Ku into a localized key Kul of user U at
authoritative SNMP engine E, one appends the snmpEngineID of
authoritative SNMP engine to the key Ku and then appends the key
to the result, thus enveloping the snmpEngineID within the two
of user's key Ku. Then one runs a secure hash function (which
depends on the authentication protocol defined for this user U
authoritative SNMP engine E; this document defines two
protocols with their associated algorithms based on MD5 and SHA).
output of the hash-function is the localized key Kul for user U
the authoritative SNMP engine E
3. Elements of
This section describes the security related procedures followed by
SNMP engine when processing SNMP messages according to the User-
Security Model
Blumenthal & Wijnen Standards Track [Page 21]
RFC 2574 USM for SNMPv3 April 1999
3.1. Generating an Outgoing SNMP
This section describes the procedure followed by an SNMP
whenever it generates a message containing a management
(like a request, a response, a notification, or a report) on
of a user, with a particular securityLevel
1) a) If any securityStateReference is passed (Response or
message), then information concerning the user is
from the cachedSecurityData. The cachedSecurityData can
be discarded. The securityEngineID is set to the
snmpEngineID. The securityLevel is set to the value
by the calling module
Otherwise
b) based on the securityName, information concerning the user
the destination snmpEngineID, specified by
securityEngineID, is extracted from the Local
Datastore (LCD, usmUserTable). If information about the
is absent from the LCD, then an error
(unknownSecurityName) is returned to the calling module
2) If the securityLevel specifies that the message is to
protected from disclosure, but the user does not support both
authentication and a privacy protocol then the message cannot
sent. An error indication (unsupportedSecurityLevel) is
to the calling module
3) If the securityLevel specifies that the message is to
authenticated, but the user does not support an
protocol, then the message cannot be sent. An error
(unsupportedSecurityLevel) is returned to the calling module
4) a) If the securityLevel specifies that the message is to
protected from disclosure, then the octet
representing the serialized scopedPDU is encrypted
to the user's privacy protocol. To do so a call is made to
privacy module that implements the user's privacy
according to the abstract primitive
statusInformation = -- success or
encryptData
IN encryptKey -- user's localized
IN dataToEncrypt -- serialized
OUT encryptedData -- serialized
OUT privParameters -- serialized privacy
)
Blumenthal & Wijnen Standards Track [Page 22]
RFC 2574 USM for SNMPv3 April 1999
indicates if the encryption process was successful or not
the user's localized private privKey is the secret key
can be used by the encryption algorithm
the serialized scopedPDU is the data to be encrypted
the encryptedPDU represents the encrypted scopedPDU
encoded as an OCTET STRING
the privacy parameters, encoded as an OCTET STRING
If the privacy module returns failure, then the message
be sent and an error indication (encryptionError) is
to the calling module
If the privacy module returns success, then the
privParameters are put into the msgPrivacyParameters field
the securityParameters and the encryptedPDU serves as
payload of the message being prepared
Otherwise
b) If the securityLevel specifies that the message is not to
be protected from disclosure, then a zero-length OCTET
is encoded into the msgPrivacyParameters field of
securityParameters and the plaintext scopedPDU serves as
payload of the message being prepared
5) The securityEngineID is encoded as an OCTET STRING into
msgAuthoritativeEngineID field of the securityParameters.
that an empty (zero length) securityEngineID is OK for a
message, because that will cause the remote (authoritative)
engine to return a Report PDU with the proper
included in the msgAuthoritativeEngineID in
securityParameters of that returned Report PDU
6) a) If the securityLevel specifies that the message is to
authenticated, then the current values of snmpEngineBoots
snmpEngineTime corresponding to the securityEngineID from
LCD are used
Otherwise
b) If this is a Response or Report message, then the
value of snmpEngineBoots and snmpEngineTime corresponding
the local snmpEngineID from the LCD are used
Blumenthal & Wijnen Standards Track [Page 23]
RFC 2574 USM for SNMPv3 April 1999
Otherwise
c) If this is a Request message, then a zero value is used
both snmpEngineBoots and snmpEngineTime. This zero value
used if snmpEngineID is empty
The values are encoded as INTEGER respectively into
msgAuthoritativeEngineBoots and msgAuthoritativeEngineTime
of the securityParameters
7) The userName is encoded as an OCTET STRING into the
field of the securityParameters
8) a) If the securityLevel specifies that the message is to
authenticated, the message is authenticated according to
user's authentication protocol. To do so a call is made to
authentication module that implements the user'
authentication protocol according to the abstract
primitive
statusInformation =
authenticateOutgoingMsg
IN authKey -- the user's localized
IN wholeMsg -- unauthenticated
OUT authenticatedWholeMsg -- authenticated complete
)
indicates if authentication was successful or not
the user's localized private authKey is the secret key
can be used by the authentication algorithm
the complete serialized message to be authenticated
the same as the input given to the
service, but with msgAuthenticationParameters
filled in
If the authentication module returns failure, then the
cannot be sent and an error indication (authenticationFailure
is returned to the calling module
If the authentication module returns success, then
msgAuthenticationParameters field is put into
securityParameters and the authenticatedWholeMsg
the serialization of the authenticated message being prepared
Blumenthal & Wijnen Standards Track [Page 24]
RFC 2574 USM for SNMPv3 April 1999
Otherwise
b) If the securityLevel specifies that the message is not to
authenticated then a zero-length OCTET STRING is encoded
the msgAuthenticationParameters field of
securityParameters. The wholeMsg is now serialized and
represents the unauthenticated message being prepared
9) The completed message with its length is returned to the
module with the statusInformation set to success
3.2. Processing an Incoming SNMP
This section describes the procedure followed by an SNMP
whenever it receives a message containing a management operation
behalf of a user, with a particular securityLevel
To simplify the elements of procedure, the release of
information is not always explicitly specified. As a general rule,
state information is available when a message gets discarded,
state information should also be released. Also, an error
can return an OID and value for an incremented counter and
a value for securityLevel, and values for contextEngineID
contextName for the counter. In addition, the
data is returned if any such information is available at the
where the error is detected
1) If the received securityParameters is not the
(according to the conventions of [RFC1906]) of an OCTET
formatted according to the UsmSecurityParameters defined
section 2.4, then the snmpInASNParseErrs counter [RFC1907]
incremented, and an error indication (parseError) is returned
the calling module. Note that we return without the OID
value of the incremented counter, because in this case there
not enough information to generate a Report PDU
2) The values of the security parameter fields are extracted
the securityParameters. The securityEngineID to be returned
the caller is the value of the msgAuthoritativeEngineID field
The cachedSecurityData is prepared and a
is prepared to reference this data. Values to be cached are
3) If the value of the msgAuthoritativeEngineID field in
securityParameters is unknown then
Blumenthal & Wijnen Standards Track [Page 25]
RFC 2574 USM for SNMPv3 April 1999
a) a non-authoritative SNMP engine that performs discovery
optionally create a new entry in its Local
Datastore (LCD) and continue processing
b) the usmStatsUnknownEngineIDs counter is incremented,
an error indication (unknownEngineID) together with
OID and value of the incremented counter is returned
the calling module
Note in the event that a zero-length, or other
sized msgAuthoritativeEngineID is received, b) should
chosen to facilitate engineID discovery
Otherwise the choice between a) and b) is an
issue
4) Information about the value of the msgUserName
msgAuthoritativeEngineID fields is extracted from the
Configuration Datastore (LCD, usmUserTable). If no
is available for the user, then the
counter is incremented and an error
(unknownSecurityName) together with the OID and value of
incremented counter is returned to the calling module
5) If the information about the user indicates that it does
support the securityLevel requested by the caller, then
usmStatsUnsupportedSecLevels counter is incremented and
error indication (unsupportedSecurityLevel) together with
OID and value of the incremented counter is returned to
calling module
6) If the securityLevel specifies that the message is to
authenticated, then the message is authenticated according
the user's authentication protocol. To do so a call is
to the authentication module that implements the user'
authentication protocol according to the abstract
primitive
statusInformation = -- success or
authenticateIncomingMsg
IN authKey -- the user's localized
IN authParameters -- as received on the
IN wholeMsg -- as received on the
OUT authenticatedWholeMsg -- checked for
)
Blumenthal & Wijnen Standards Track [Page 26]
RFC 2574 USM for SNMPv3 April 1999
indicates if authentication was successful or not
the user's localized private authKey is the secret key
can be used by the authentication algorithm
the complete serialized message to be authenticated
the same as the input given to the
service, but after authentication has been checked
If the authentication module returns failure, then the
cannot be trusted, so the usmStatsWrongDigests counter
incremented and an error indication (authenticationFailure
together with the OID and value of the incremented counter
returned to the calling module
If the authentication module returns success, then the
is authentic and can be trusted so processing continues
7) If the securityLevel indicates an authenticated message,
the local values of snmpEngineBoots,
and
corresponding to the value of the
field are extracted from the Local Configuration Datastore
a) If the extracted value of msgAuthoritativeEngineID is
same as the value of snmpEngineID of the processing
engine (meaning this is the authoritative SNMP engine),
then if any of the following conditions is true, then
message is considered to be outside of the Time Window
- the local value of snmpEngineBoots is 2147483647;
- the value of the msgAuthoritativeEngineBoots field
from the local value of snmpEngineBoots; or
- the value of the msgAuthoritativeEngineTime field
from the local notion of snmpEngineTime by more
+/- 150 seconds
