As per Relevance of the word mechanism, we have this rfc below:
Network Working Group J.
Request for Comments: 1352 Trusted Information Systems, Inc
K.
Hughes LAN Systems, Inc
J.
MIT Laboratory for Computer
July 1992
SNMP Security
Status of this
This document specifies an IAB standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" for the standardization state and
of this protocol. Distribution of this memo is unlimited
Table of
1. Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2.1 Threats . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2 Goals and Constraints . . . . . . . . . . . . . . . . . . . 5
2.3 Security Services . . . . . . . . . . . . . . . . . . . . . 6
2.4 Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.4.1 Message Digest Algorithm . . . . . . . . . . . . . . . . . 7
2.4.2 Symmetric Encryption Algorithm . . . . . . . . . . . . . . 8
3. SNMP Party . . . . . . . . . . . . . . . . . . . . . . . . 9
4. Digest Authentication Protocol . . . . . . . . . . . . . . . 11
4.1 Generating a Message . . . . . . . . . . . . . . . . . . . 14
4.2 Receiving a Message . . . . . . . . . . . . . . . . . . . . 15
5. Symmetric Privacy Protocol . . . . . . . . . . . . . . . . . 16
5.1 Generating a Message . . . . . . . . . . . . . . . . . . . 17
5.2 Receiving a Message . . . . . . . . . . . . . . . . . . . . 18
6. Clock and Secret Distribution . . . . . . . . . . . . . . . 19
6.1 Initial Configuration . . . . . . . . . . . . . . . . . . 20
6.2 Clock Distribution . . . . . . . . . . . . . . . . . . . . 22
6.3 Clock Synchronization . . . . . . . . . . . . . . . . . . . 24
6.4 Secret Distribution . . . . . . . . . . . . . . . . . . . . 26
6.5 Crash Recovery . . . . . . . . . . . . . . . . . . . . . . 28
7. Security Considerations . . . . . . . . . . . . . . . . . . 30
7.1 Recommended Practices . . . . . . . . . . . . . . . . . . . 30
7.2 Conformance . . . . . . . . . . . . . . . . . . . . . . . 33
7.3 Protocol Correctness . . . . . . . . . . . . . . . . . . . . 34
7.3.1 Clock Monotonicity Mechanism . . . . . . . . . . . . . . . 35
7.3.2 Data Integrity Mechanism . . . . . . . . . . . . . . . . . 36
Galvin, McCloghrie, & Davin [Page 1]
RFC 1352 SNMP Security Protocols July 1992
7.3.3 Data Origin Authentication Mechanism . . . . . . . . . . . 36
7.3.4 Restricted Administration Mechanism . . . . . . . . . . . 36
7.3.5 Ordered Delivery Mechanism . . . . . . . . . . . . . . . 37
7.3.6 Message Timeliness Mechanism . . . . . . . . . . . . . . . 38
7.3.7 Selective Clock Acceleration Mechanism . . . . . . . . . . 38
7.3.8 Confidentiality Mechanism . . . . . . . . . . . . . . . . 39
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 40
10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 41
1.
The Simple Network Management Protocol (SNMP) specification [1]
allows for the protection of network management operations by
variety of security protocols. The SNMP administrative
described in [2] provides a framework for securing SNMP
management. In the context of that framework, this memo
protocols to support the following three security services
o data integrity
o data origin authentication,
o data confidentiality
Please send comments to the SNMP Security Developers mailing
(snmp-sec-dev@tis.com).
2.
In the model described in [2], each SNMP party is, by definition
associated with a single authentication protocol. The
protocol provides a mechanism by which SNMP management
transmitted by the party may be reliably identified as
originated from that party. The authentication protocol defined
this memo also reliably determines that the message received is
message that was sent
Similarly, each SNMP party is, by definition, associated with
single privacy protocol. The privacy protocol provides a mechanism
which SNMP management communications transmitted to said party
protected from disclosure. The privacy protocol in this
specifies that only authenticated messages may be protected
disclosure
These protocols are secure alternatives to the so-called "trivial
protocol defined in [1].
Galvin, McCloghrie, & Davin [Page 2]
RFC 1352 SNMP Security Protocols July 1992
USE OF THE TRIVIAL PROTOCOL ALONE DOES NOT CONSTITUTE
NETWORK MANAGEMENT. THEREFORE, A NETWORK MANAGEMENT SYSTEM
IMPLEMENTS ONLY THE TRIVIAL PROTOCOL IS NOT CONFORMANT TO
SPECIFICATION
The Digest Authentication Protocol is described in Section 4.
provides a data integrity service by transmitting a message digest --
computed by the originator and verified by the recipient -- with
SNMP message. The data origin authentication service is provided
prefixing the message with a secret value known only to
originator and recipient, prior to computing the digest. Thus,
integrity is supported explicitly while data origin authentication
supported implicitly in the verification of the digest
The Symmetric Privacy Protocol is described in Section 5. It
messages from disclosure by encrypting their contents according to
secret cryptographic key known only to the originator and recipient
The additional functionality afforded by this protocol is assumed
justify its additional computational cost
The Digest Authentication Protocol depends on the existence
loosely synchronized clocks between the originator and recipient of
message. The protocol specification makes no assumptions about
strategy by which such clocks are synchronized. Section 6.3
one strategy that is particularly suited to the demands of
network management
Both protocols described here require the sharing of
information between the originator of a message and its recipient
The protocol specifications assume the existence of the
secrets. The selection of such secrets and their secure
to appropriate parties may be accomplished by a variety
strategies. Section 6.4 presents one such strategy that
particularly suited to the demands of SNMP network management
2.1
Several of the classical threats to network protocols are
to the network management problem and therefore would be
to any SNMP security protocol. Other threats are not applicable
the network management problem. This section discusses
threats, secondary threats, and threats which are of
importance
The principal threats against which any SNMP security protocol
provide protection are
Galvin, McCloghrie, & Davin [Page 3]
RFC 1352 SNMP Security Protocols July 1992
Modification of Information
The SNMP protocol provides the means for management stations
interrogate and to manipulate the value of objects in a
agent. The modification threat is the danger that some party
alter in-transit messages generated by an authorized party in
a way as to effect unauthorized management operations,
falsifying the value of an object
Masquerade
The SNMP administrative model includes an access control model
Access control necessarily depends on knowledge of the origin of
message. The masquerade threat is the danger that
operations not authorized for some party may be attempted by
party by assuming the identity of another party that has
appropriate authorizations
Two secondary threats are also identified. The security
defined in this memo do provide protection against
Message Stream Modification
The SNMP protocol is based upon connectionless transport services
The message stream modification threat is the danger that
may be arbitrarily re-ordered, delayed or replayed to
unauthorized management operations. This threat may arise
by the work of a malicious attacker or by the natural operation
a subnetwork service
Disclosure
The disclosure threat is the danger of eavesdropping on
exchanges between managed agents and a management station
Protecting against this threat is mandatory when the SNMP is
to administer private parameters on which its security is based
Protecting against the disclosure threat may also be required as
matter of local policy
There are at least two threats that a SNMP security protocol need
protect against. The security protocols defined in this memo do
provide protection against
Denial of Service
A SNMP security protocol need not attempt to address the
range of attacks by which service to authorized parties is 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
course
Galvin, McCloghrie, & Davin [Page 4]
RFC 1352 SNMP Security Protocols July 1992
Traffic Analysis
In addition, a SNMP security protocol need not attempt to
traffic analysis attacks. Indeed, many traffic patterns
predictable -- agents may be managed on a regular basis by
relatively small number of management stations -- and
there is no significant advantage afforded by protecting
traffic analysis
2.2 Goals and
Based on the foregoing account of threats in the SNMP
management environment, the goals of a SNMP security protocol
enumerated below
1. The protocol should provide for verification that
received SNMP message has not been modified
its transmission through the network in such a way
an unauthorized management operation might result
2. The protocol should provide for verification of
identity of the originator of each received
message
3. The protocol should provide that the apparent time
generation for each received SNMP message is recent
4. The protocol should provide that the apparent time
generation for each received SNMP message
subsequent to that for all previously delivered
of similar origin
5. The protocol should provide, when necessary, that
contents of each received SNMP message are
from disclosure
In addition to the principal goal of supporting secure
management, the design of any SNMP security protocol is
influenced by the following constraints
1. When the requirements of effective management in
of network stress are inconsistent with those of security
the former are preferred
2. Neither the security protocol nor its underlying
mechanisms should depend upon the ready
of other network services (e.g., Network Time
(NTP) or secret/key management protocols).
Galvin, McCloghrie, & Davin [Page 5]
RFC 1352 SNMP Security Protocols July 1992
3. A security mechanism should entail no changes to
basic SNMP network management philosophy
2.3 Security
The security services necessary to support the goals of a
security protocol are as follows
Data Integrity is the provision of the property that
and data sequences have not been altered or
in an unauthorized manner
Data Origin Authentication is the provision of
property that the claimed origin of received data
corroborated
Data Confidentiality is the provision of the property
information is not made available or disclosed
unauthorized individuals, entities, or processes
The protocols specified in this memo require both
integrity and data origin authentication to be used at
times. For these protocols, it is not possible to realize
integrity without data origin authentication, nor is it
to realize data origin authentication without data integrity
Further, there is no provision for data confidentiality
both data integrity and data origin authentication
2.4
The security protocols defined in this memo employ
types of mechanisms in order to realize the goals and
services described above
o In support of data integrity, a message digest
is required. A digest is calculated over an
portion of a SNMP message and included as part of
message sent to the recipient
o In support of data origin authentication and
integrity, the portion of a SNMP message that
digested is first prefixed with a secret value shared
the originator of that message and its intended recipient
o To protect against the threat of message reordering,
timestamp value is included in each message generated
A recipient evaluates the timestamp to determine if
Galvin, McCloghrie, & Davin [Page 6]
RFC 1352 SNMP Security Protocols July 1992
message is recent and it uses the timestamp to
if the message is ordered relative to other messages
has received. In conjunction with other readily
information (e.g., the request-id), the timestamp
indicates whether or not the message is a replay of
previous message. This protection against the threat
message reordering implies no protection
unauthorized deletion or suppression of messages
o In support of data confidentiality, a
encryption algorithm is required. An
portion of the message is encrypted prior to
transmitted to its recipient
The security protocols in this memo are defined independently of
particular choice of a message digest and encryption algorithm --
owing principally to the lack of a suitable metric by which
evaluate the security of particular algorithm choices. However,
the interests of completeness and in order to
interoperability, Sections 2.4.1 and 2.4.2 specify
choices, which are considered acceptably secure as of this writing
In the future, this memo may be updated by the publication of a
specifying substitute or alternate choices of algorithms, i.e.,
replacement for or addition to the sections below
2.4.1 Message Digest
In support of data integrity, the use of the MD5 [3] message
algorithm is chosen. A 128-bit digest is calculated over
designated portion of a SNMP message and included as part of
message sent to the recipient
An appendix of [3] contains a C Programming Language
of the algorithm. This code was written with portability being
principal objective. Implementors may wish to optimize
implementation with respect to the characteristics of their
and software platforms
The use of this algorithm in conjunction with the
Authentication Protocol (see Section 4) is identified by the ASN.1
object identifier value md5AuthProtocol, defined in [4].
For any SNMP party for which the authentication protocol
md5AuthProtocol, the size of its private authentication key is 16
octets
Within an authenticated management communication generated by such
party, the size of the authDigest component of that
Galvin, McCloghrie, & Davin [Page 7]
RFC 1352 SNMP Security Protocols July 1992
(see Section 4) is 16 octets
2.4.2 Symmetric Encryption
In support of data confidentiality, the use of the Data
Standard (DES) in the Cipher Block Chaining mode of operation
chosen. The designated portion of a SNMP message is encrypted
included as part of the message sent to the recipient
Two organizations have published specifications defining the DES:
National Institute of Standards and Technology (NIST) [5] and
American National Standards Institute [6]. There is a
Modes of Operation specification for each definition (see [7]
[8], respectively).
The NIST has published three additional documents that
may find useful
o There is a document with guidelines for
and using the DES, including functional
for the DES and its modes of operation [9].
o There is a specification of a validation test suite for
DES [10]. The suite is designed to test all aspects of
DES and is useful for pinpointing specific problems
o There is a specification of a maintenance test for
DES [11]. The test utilizes a minimal amount of
and processing to test all components of the DES.
provides a simple yes-or-no indication of
operation and is useful to run as part of an
step, e.g., when a computer reboots
The use of this algorithm in conjunction with the Symmetric
Protocol (see Section 5) is identified by the ASN.1 object
value desPrivProtocol, defined in [4].
For any SNMP party for which the privacy protocol is desPrivProtocol
the size of the private privacy key is 16 octets, of which the
8 octets are a DES key and the second 8 octets are a
Initialization Vector. The 64-bit DES key in the first 8 octets
the private key is a 56 bit quantity used directly by the
plus 8 parity bits -- arranged so that one parity bit is the
significant bit of each octet. The setting of the parity bits
ignored
The length of the octet sequence to be encrypted by the DES must
Galvin, McCloghrie, & Davin [Page 8]
RFC 1352 SNMP Security Protocols July 1992
an integral multiple of 8. When encrypting, the data should be
at the end as necessary; the actual pad value is insignificant
If the length of the octet sequence to be decrypted is not
integral multiple of 8 octets, the processing of the octet
should be halted and an appropriate exception noted. Upon decrypting
the padding should be ignored
3. SNMP
Recall from [2] that a SNMP party is a conceptual, virtual
context whose operation is restricted (for security or
purposes) to an administratively defined subset of all
operations of a particular SNMP protocol entity. A SNMP
entity is an actual process which performs network
operations by generating and/or responding to SNMP protocol
in the manner specified in [1]. Architecturally, every SNMP
entity maintains a local database that represents all SNMP
known to it
A SNMP party may be represented by an ASN.1 value with the
syntax
SnmpParty ::= SEQUENCE {
OBJECT IDENTIFIER
OBJECT IDENTIFIER
OCTET STRING
OBJECT IDENTIFIER
INTEGER
OBJECT IDENTIFIER
INTEGER
INTEGER
INTEGER
OCTET STRING
OCTET STRING
Galvin, McCloghrie, & Davin [Page 9]
RFC 1352 SNMP Security Protocols July 1992
INTEGER
OBJECT IDENTIFIER
OCTET STRING
OCTET
}
For each SnmpParty value that represents a SNMP party, the
significance of each of its components is defined in [2]. For
SNMP party that supports the generation of messages using the
Authentication Protocol, additional, special significance
attributed to certain components of that party's representation
o Its partyAuthProtocol component is called
authentication protocol and identifies a combination
the Digest Authentication Protocol with a
digest algorithm (such as that defined in Section 2.4.1).
This combined mechanism is used to authenticate
origin and integrity of all messages generated by
party
o Its partyAuthClock component is called
authentication clock and represents a notion of
current time that is specific to the party
o Its partyAuthLastMsg component is called
last-timestamp and represents a notion of
associated with the most recent, authentic
message generated by the party
o Its partyAuthNonce component is called the
and represents a monotonically increasing
associated with the most recent, authentic
message generated by the party. The nonce
with a particular message distinguishes it among
others transmitted in the same unit time interval
o Its partyAuthPrivate component is called the
authentication key and represents any secret
needed to support the Digest Authentication
and associated digest algorithm
o Its partyAuthPublic component is called the
authentication key and represents any public value
may be needed to support the authentication protocol
Galvin, McCloghrie, & Davin [Page 10]
RFC 1352 SNMP Security Protocols July 1992
This component is not significant except as suggested
Section 6.4.
o Its partyAuthLifetime component is called
lifetime and represents an administrative upper
on acceptable delivery delay for protocol
generated by the party
For each SNMP party that supports the receipt of messages via
Symmetric Privacy Protocol, additional, special significance
attributed to certain components of that party's representation
o Its partyPrivProtocol component is called the
protocol and identifies a combination of the
Privacy Protocol with a particular encryption
(such as that defined in Section 2.4.2). This
mechanism is used to protect from disclosure all
messages received by the party
o Its partyPrivPrivate component is called the
privacy key and represents any secret value needed
support the Symmetric Privacy Protocol and
encryption algorithm
o Its partyPrivPublic component is called the
privacy key and represents any public value that may
needed to support the privacy protocol. This
is not significant except as suggested in Section 6.4.
4. Digest Authentication
This section describes the Digest Authentication Protocol.
provides both for verifying the integrity of a received
(i.e., the message received is the message sent) and for
the origin of a message (i.e., the reliable identification of
originator). The integrity of the message is protected by computing
digest over an appropriate portion of a message. The digest
computed by the originator of the message, transmitted with
message, and verified by the recipient of the message
A secret value known only to the originator and recipient of
message is prefixed to the message prior to the digest computation
Thus, the origin of the message is known implicitly with
verification of the digest
Recall from [2] that a SNMP management communication is
by an ASN.1 value with the following syntax
Galvin, McCloghrie, & Davin [Page 11]
RFC 1352 SNMP Security Protocols July 1992
SnmpMgmtCom ::= [1] IMPLICIT SEQUENCE {
OBJECT IDENTIFIER
OBJECT IDENTIFIER
pdu
}
For each SnmpMgmtCom value that represents a SNMP
communication, the following statements are true
o Its dstParty component is called the destination
identifies the SNMP party to which the
is directed
o Its srcParty component is called the source
identifies the SNMP party from which
communication is originated
o Its pdu component has the form and
attributed to it in [1].
Recall from [2] that a SNMP authenticated management communication
represented by an ASN.1 value with the following syntax
SnmpAuthMsg ::= [1] IMPLICIT SEQUENCE {
ANY, - defined by authentication
}
For each SnmpAuthMsg value that represents a SNMP
management communication, the following statements are true
o Its authInfo component is called the
information and represents information required
support of the authentication protocol used by
SNMP party originating the message. The
significance of the authentication information is
to the authentication protocol in use; it has no effect
the application semantics of the communication
than its use by the authentication protocol
determining whether the communication is authentic
not
Galvin, McCloghrie, & Davin [Page 12]
RFC 1352 SNMP Security Protocols July 1992
o Its authData component is called the
data and represents a SNMP
communication
In support of the Digest Authentication Protocol, an
component is of type AuthInformation
AuthInformation ::= [1] IMPLICIT SEQUENCE {
INTEGER (0..2147483647),
INTEGER (0..2147483647),
OCTET
}
For each AuthInformation value that represents
information, the following statements are true
o Its authTimestamp component is called
authentication timestamp and represents the time of
generation of the message according to
partyAuthClock of the SNMP party that
it. Note that the granularity of the
timestamp is 1 second
o Its authNonce component is called the
nonce and represents a non-negative integer
evaluated according to the authTimestamp value.
order not to limit transmission frequency of
communications to the granularity of the
timestamp, the authentication nonce is provided
differentiate between multiple messages sent with
same value of authTimestamp. The
nonce is a monotonically increasing sequence number
that is reset for each new authentication
value
o Its authDigest component is called the
digest and represents the digest computed over
appropriate portion of the message, where the message
temporarily prefixed with a secret value for the
of computing the digest
Galvin, McCloghrie, & Davin [Page 13]
RFC 1352 SNMP Security Protocols July 1992
4.1 Generating a
This section describes the behavior of a SNMP protocol entity when
acts as a SNMP party for which the authentication protocol
administratively specified as the Digest Authentication Protocol
Insofar as the behavior of a SNMP protocol entity when
protocol messages is defined generically in [2], only those
of that behavior that are specific to the Digest
Protocol are described below. In particular, this section
the encapsulation of a SNMP management communication into a
authenticated management communication
According to [2], a SnmpAuthMsg value is constructed during Step 3
generic processing. In particular, it states the authInfo
is constructed according to the authentication protocol
for the SNMP party originating the message. When the
authentication protocol is the Digest Authentication Protocol,
procedure performed by a SNMP protocol entity whenever a
communication is to be transmitted by a SNMP party is as follows
1. The local database is consulted to determine
authentication clock, last-timestamp, nonce, and
authentication key (extracted, for example, according
the conventions defined in Section 2.4.1) of the
party originating the message
2. The authTimestamp component is set to the
authentication clock value
3. If the last-timestamp is equal to the
clock, the nonce is incremented. Otherwise the nonce
set to zero. The authNonce component is set to
nonce value. In the local database, the
SNMP party's nonce and last-timestamp are set to
nonce value and the authentication clock, respectively
4. The authentication digest is temporarily set to
private authentication key. The SnmpAuthMsg
is serialized according to the conventions of [12] and [1].
A digest is computed over the octet
representing that serialized value using, for example,
algorithm specified in Section 2.4.1. The
component is set to the computed digest value
As set forth in [2], the SnmpAuthMsg value is then
according to the appropriate privacy protocol into a
value. This latter value is then serialized and transmitted to
receiving SNMP party
Galvin, McCloghrie, & Davin [Page 14]
RFC 1352 SNMP Security Protocols July 1992
4.2 Receiving a
This section describes the behavior of a SNMP protocol entity
receipt of a protocol message from a SNMP party for which
authentication protocol is administratively specified as the
Authentication Protocol. Insofar as the behavior of a SNMP
entity when receiving protocol messages is defined generically
[2], only those aspects of that behavior that are specific to
Digest Authentication Protocol are described below
According to [2], a SnmpAuthMsg value is evaluated during Step 9
generic processing. In particular, it states the SnmpAuthMsg value
evaluated according to the authentication protocol identified for
SNMP party that originated the message. When the
authentication protocol is the Digest Authentication Protocol,
procedure performed by a SNMP protocol entity whenever a
communication is received by a SNMP party is as follows
1. If the ASN.1 type of the authInfo component is
AuthInformation, the message is evaluated
unauthentic. Otherwise, the authTimestamp
authNonce, and authDigest components
extracted from the SnmpAuthMsg value
2. The local database is consulted to determine
authentication clock, last-timestamp, nonce,
authentication key (extracted, for example, according
the conventions defined in Section 2.4.1), and lifetime
the SNMP party that originated the message
3. If the authTimestamp component plus the lifetime
less than the authentication clock, the message
evaluated as unauthentic
4. If the authTimestamp component is less than
last-timestamp recorded for the originating party in
local database, the message is evaluated as unauthentic
5. If the authTimestamp component is equal to
last-timestamp and if the authNonce component is
than or equal to the nonce, the message is evaluated
unauthentic
6. The authDigest component is extracted
temporarily recorded
7. A new SnmpAuthMsg value is constructed such
its authDigest component is set to the
Galvin, McCloghrie, & Davin [Page 15]
RFC 1352 SNMP Security Protocols July 1992
authentication key and its other components are set
the value of the corresponding components in
received SnmpAuthMsg value. This
SnmpAuthMsg value is serialized according to
conventions of [12] and [1]. A digest is computed
the octet sequence representing that serialized
using, for example, the algorithm specified
Section 2.4.1.
8. If the computed digest value is not equal to
previously recorded digest value, the message
evaluated as unauthentic
9. The message is evaluated as authentic
10. The last-timestamp and nonce values locally
for the originating SNMP party are set to
authTimestamp value and the authNonce value
respectively
11. The authentication clock value locally recorded for
originating SNMP party is advanced to
authTimestamp value if this latter exceeds
recorded value
If the SnmpAuthMsg value is evaluated as unauthentic,
authentication failure is noted and the received message is
without further processing. Otherwise, processing of the
message continues as specified in [2].
5. Symmetric Privacy
This section describes the Symmetric Privacy Protocol. It
for protection from disclosure of a received message. An
portion of the message is encrypted according to a secret key
only to the originator and recipient of the message
This protocol assumes the underlying mechanism is a
encryption algorithm. In addition, the message to be encrypted
be protected according to the conventions of the
Authentication Protocol
Recall from [2] that a SNMP private management communication
represented by an ASN.1 value with the following syntax
Galvin, McCloghrie, & Davin [Page 16]
RFC 1352 SNMP Security Protocols July 1992
SnmpPrivMsg ::= [1] IMPLICIT SEQUENCE {
OBJECT IDENTIFIER
[1] IMPLICIT OCTET
}
For each SnmpPrivMsg value that represents a SNMP private
communication, the following statements are true
o Its privDst component is called the privacy
and identifies the SNMP party to which
communication is directed
o Its privData component is called the privacy data
represents the (possibly encrypted)
(according to the conventions of [12] and [1]) of a
authenticated management communication
5.1 Generating a
This section describes the behavior of a SNMP protocol entity when
communicates with a SNMP party for which the privacy protocol
administratively specified as the Symmetric Privacy Protocol.
as the behavior of a SNMP protocol entity when transmitting
protocol message is defined generically in [2], only those aspects
that behavior that are specific to the Symmetric Privacy Protocol
described below. In particular, this section describes
encapsulation of a SNMP authenticated management communication into
SNMP private management communication
According to [2], a SnmpPrivMsg value is constructed during Step 5
generic processing. In particular, it states the privData
is constructed according to the privacy protocol identified for
SNMP party receiving the message. When the relevant privacy
is the Symmetric Privacy Protocol, the procedure performed by a
protocol entity whenever a management communication is to
transmitted by a SNMP party is as follows
1. If the SnmpAuthMsg value is not
according to the conventions of the
Authentication Protocol, the generation of the
management communication fails according to a
procedure, without further processing
2. The local database is consulted to determine the
privacy key of the SNMP party receiving the
Galvin, McCloghrie, & Davin [Page 17]
RFC 1352 SNMP Security Protocols July 1992
(represented, for example, according to the
defined in Section 2.4.2).
3. The SnmpAuthMsg value is serialized according to
conventions of [12] and [1].
4. The octet sequence representing the
SnmpAuthMsg value is encrypted using, for example
the algorithm specified in Section 2.4.2 and
extracted private privacy key
5. The privData component is set to the encrypted value
As set forth in [2], the SnmpPrivMsg value is then
and transmitted to the receiving SNMP party
5.2 Receiving a
This section describes the behavior of a SNMP protocol entity when
acts as a SNMP party for which the privacy protocol
administratively specified as the Symmetric Privacy Protocol.
as the behavior of a SNMP protocol entity when receiving a
message is defined generically in [2], only those aspects of
behavior that are specific to the Symmetric Privacy Protocol
described below
According to [2], the privData component of a received
value is evaluated during Step 4 of generic processing.
particular, it states the privData component is evaluated
to the privacy protocol identified for the SNMP party receiving
message. When the relevant privacy protocol is the Symmetric
Protocol, the procedure performed by a SNMP protocol entity
a management communication is received by a SNMP party is as follows
1. The local database is consulted to determine the
privacy key of the SNMP party receiving the
(represented, for example, according to the
defined in Section 2.4.2).
2. The contents octets of the privData component
decrypted using, for example, the algorithm specified
Section 2.4.2 and the extracted private privacy key
Processing of the received message continues as specified in [2].
Galvin, McCloghrie, & Davin [Page 18]
RFC 1352 SNMP Security Protocols July 1992
6. Clock and Secret
The protocols described in Sections 4 and 5 assume the existence
loosely synchronized clocks and shared secret values.
requirements constrain the strategy by which clock values and
are distributed
o If the value of an authentication clock is decreased,
last-timestamp and private authentication key must
changed concurrently
When the value of an authentication clock is decreased
messages that have been sent with a timestamp
between the value of the authentication clock and
new value may be replayed. Changing the
authentication key obviates this threat. However
changing the authentication clock and the
authentication key is not sufficient to ensure
operation. If the last-timestamp is not reduced
to the authentication clock, no message will
considered authentic until the value of the
clock exceeds the value of the last-timestamp
o The private authentication key and private privacy
must be known only to the parties requiring
of them
Protecting the secrets from disclosure is critical to
security of the protocols. In particular, if the secrets
distributed via a network, the secrets must be
with a protocol that supports confidentiality, e.g.,
Symmetric Privacy Protocol. Further, knowledge of
secrets must be as restricted as possible within
implementation. In particular, although the secrets
be known to one or more persons during the
configuration of a device, the secrets should be
immediately after configuration such that their
value is known only to the software. A
station has the additional responsibility of recovering
state of all parties whenever it boots, and it may
this responsibility by recording the secrets on
long-term storage device. Access to information on
device must be as restricted as is practically possible
o There must exist at least one SNMP protocol entity
assumes the role of a responsible management station
This management station is responsible for ensuring
Galvin, McCloghrie, & Davin [Page 19]
RFC 1352 SNMP Security Protocols July 1992
all authentication clocks are synchronized and
changing the secret values when necessary.
more than one management station may share
responsibility, their coordination is essential to
secure management of the network. The mechanism
which multiple management stations ensure that
more than one of them attempts to synchronize
clocks or update the secrets at any one time is a
implementation issue
A responsible management station may either
clock synchronization and secret distribution as
functions, or combine them into a single functional unit
The first section below specifies the procedures by which a
protocol entity is initially configured. The next two
describe one strategy for distributing clock values and one
determining a synchronized clock value among SNMP parties
the Digest Authentication Protocol. For SNMP parties supporting
Symmetric Privacy Protocol, the next section describes a strategy
distributing secret values. The last section specifies the
by which a SNMP protocol entity recovers from a "crash."
6.1 Initial
This section describes the initial configuration of a SNMP
entity that supports the Digest Authentication Protocol or both
Digest Authentication Protocol and the Symmetric Privacy Protocol
When a network device is first installed, its initial,
configuration must be done manually, i.e., a person must
visit the device and enter the initial secret values for at least
first secure SNMP party. This requirement suggests that the
will have knowledge of the initial secret values
In general, the security of a system is enhanced as the number
entities that know a secret is reduced. Requiring a person
physically visit a device every time a SNMP party is configured
only exposes the secrets unnecessarily but is
prohibitive. In particular, when MD5 is used, the
authentication secret is 128 bits long and when DES is used
additional 128 bits are needed -- 64 bits each for the key
initialization vector. Clearly, these values will need to be
on a medium in order to be transported between a
management station and a managed agent. The recommended procedure
to configure a small set of initial SNMP parties for each
protocol entity, one pair of which may be used initially to
all other SNMP parties
Galvin, McCloghrie, & Davin [Page 20]
RFC 1352 SNMP Security Protocols July 1992
In fact, there is a minimal, useful set of SNMP parties that could
configured between each responsible management station and
agent. This minimal set includes one of each of the following
both the responsible management station and the managed agent
o a SNMP party for which the authentication protocol
privacy protocol are the values noAuth and noPriv
respectively
o a SNMP party for which the authentication
identifies the mechanism defined in Section 2.4.1 and
privacy protocol is the value noPriv,
o a SNMP party for which the authentication protocol
privacy protocol identify the mechanisms defined
Section 2.4.1 and Section 2.4.2, respectively
The last of these SNMP parties in both the responsible
station and the managed agent could be used to configure all
SNMP parties. It is the only suitable party for this purpose
it is the only party that supports data confidentiality, which
necessary in order to protect the distributed secrets from
to unauthorized entities
Configuring one pair of SNMP parties to be used to configure
other parties has the advantage of exposing only one pair of
-- the secrets used to configure the minimal, useful set
above. To limit this exposure, the responsible management
should change these values as its first operation upon completion
the initial configuration. In this way, secrets are known only to
peers requiring knowledge of them in order to communicate
The Management Information Base (MIB) document [4] supporting
security protocols specifies 6 initial party identities and
values, which, by convention, are assigned to the parties and
associated parameters
All 6 parties should be configured in each new managed agent and
responsible management station. The responsible management
should be configured first, since the management station can be
to generate the initial secrets and provide them to a person, on
suitable medium, for distribution to the managed agent. The
sequence of steps describes the initial configuration of a
agent and its responsible management station
1. Determine the initial values for each of the attributes
the SNMP party to be configured. Some of these
may be computed by the responsible
Galvin, McCloghrie, & Davin [Page 21]
RFC 1352 SNMP Security Protocols July 1992
station, some may be specified in the MIB document
and some may be administratively determined
2. Configure the parties in the responsible
station, according to the set of initial values. If
management station is computing some initial values
be entered into the agent, an appropriate medium
be present to record the values
3. Configure the parties in the managed agent, according
the set of initial values
4. The responsible management station must
the authentication clock values for each party it
with each managed agent. Section 6.3 specifies
strategy by which this could be accomplished
5. The responsible management station should change
secret values manually configured to ensure the
values are known only to the peers requiring
of them in order to communicate. To do this,
management station generates new secrets for each
to be reconfigured and distributes those secrets with
strategy that uses a protocol that protects them
disclosure, e.g., Symmetric Privacy Protocol (
Section 6.4). Upon receiving positive
that the new values have been distributed,
management station should update its local
with the new values
If the managed agent does not support a protocol that
messages from disclosure, then automatic maintenance
configuration of parties is not possible, i.e., the last step
is not possible. The secrets can only be changed by a physical
to the device
If there are other SNMP protocol entities requiring knowledge of
secrets, the responsible management station must distribute
information upon completion of the initial configuration.
mechanism used must protect the secrets from disclosure
unauthorized entities. The Symmetric Privacy Protocol, for example
is an acceptable mechanism
6.2 Clock
A responsible management station must ensure that the
clock value for each SNMP party for which it is
Galvin, McCloghrie, & Davin [Page 22]
RFC 1352 SNMP Security Protocols July 1992
o is loosely synchronized among all the local databases
which it appears
o is reset, as indicated below, upon reaching its
value,
o is non-decreasing, except as indicated below
The skew among the clock values must be accounted for in the
value, in addition to the expected communication delivery delay
A skewed authentication clock may be detected by a number
strategies, including knowledge of the accuracy of the system clock
unauthenticated queries of the party database, and recognition
authentication failures originated by the party
Whenever clock skew is detected, and whenever the SNMP entities
both the responsible management station and the relevant
agent support an appropriate privacy protocol (e.g., the
Privacy Protocol), a straightforward strategy for the correction
clock skew is simultaneous alteration of authentication clock
private key for the relevant SNMP party. If the request to alter
key and clock for a particular party originates from that same party
then, prior to transmitting that request, the local notion of
authentication clock is artificially advanced to assure acceptance
the request as authentic
More generally, however, since an authentication clock value need
be protected from disclosure, it is not necessary that a
agent support a privacy protocol in order for a
management station to correct skewed clock values. The procedure
correcting clock skew in the general case is presented in
6.3.
In addition to correcting skewed notions of authentication clocks
every SNMP entity must react correctly as an authentication
approaches its maximal value. If the authentication clock for
particular SNMP party ever reaches the maximal time value, the
must halt at that value. (The value of interest may be the
less lifetime. When authenticating a message, its
timestamp is added to lifetime and compared to the
clock. A SNMP protocol entity must guarantee that the sum is
greater than the maximal time value.) In this state, the
authenticated request a management station should generate for
party is one that alters the value of at least its
clock and private authentication key. In order to reset these values
the responsible management station may set the
timestamp in the message to the maximal time value. In this case,
Galvin, McCloghrie, & Davin [Page 23]
RFC 1352 SNMP Security Protocols July 1992
nonce value may be used to distinguish multiple messages
The value of the authentication clock for a particular SNMP
must never be altered such that its new value is less than its
value, unless its last-timestamp and private authentication key
also altered at the same time
6.3 Clock
Unless the secrets are changed at the same time, the correct way
synchronize clocks is to advance the slower clock to be equal to
faster clock. Suppose that party agentParty is realized by the
entity in a managed agent; suppose that party mgrParty is realized
the SNMP entity in the corresponding responsible management station
For any pair of parties, there are four possible conditions of
authentication clocks that could require correction
1. The management station's notion of the value of
authentication clock for agentParty exceeds the agent'
notion
2. The management station's notion of the value of
authentication clock for mgrParty exceeds the agent'
notion
3. The agent's notion of the value of the
clock for agentParty exceeds the management station'
notion
4. The agent's notion of the value of the
clock for mgrParty exceeds the management station'
notion
The selective clock acceleration mechanism intrinsic to the
corrects conditions 2 and 3 as part of the normal processing of
authentic message. Therefore, the clock adjustment procedure
does not provide for any adjustments in those cases. Rather,
following sequence of steps specifies how the clocks may
synchronized when condition 1, condition 4, or both of
conditions are manifest
1. The responsible management station saves its
notions of the authentication clocks for the two
agentParty and mgrParty
2. The responsible management station retrieves
authentication clock values for both agentParty
mgrParty from the agent. This retrieval must be
Galvin, McCloghrie, & Davin [Page 24]
RFC 1352 SNMP Security Protocols July 1992
unauthenticated request, since the management
does not know if the clocks are synchronized. If
request fails, the clocks cannot be synchronized, and
clock adjustment procedure is aborted without
processing
3. If the management station's notion of the
clock for agentParty exceeds the notion just
from the agent by more than the amount of
communications delay between the two protocol entities
then condition 1 is manifest. The recommended
of communication delay in this context is one half of
lifetime value recorded for agentParty
4. If the notion of the authentication clock for
just retrieved from the agent exceeds the
station's notion, then condition 4 is manifest, and
responsible management station advances its notion
the authentication clock for mgrParty to match
agent's notion
5. If condition 1 is manifest, then the
management station sends an
management operation to the agent that advances
agent's notion of the authentication clock
agentParty to be equal to the management station'
notion. If this management operation fails, then
management station restores its previously saved
of the clock values, and the clock adjustment
is aborted without further processing
6. The responsible management station retrieves
authentication clock values for both agentParty
mgrParty from the agent. This 