As per Relevance of the word mechanism, we have this rfc below:
Network Working Group J.
Request for Comments: 1446 Trusted Information
K.
Hughes LAN
April 1993
Security
for version 2 of
Simple Network Management Protocol (SNMPv2)
Status of this
This RFC specifes an IAB standards track protocol for
Internet community, and requests discussion and
for improvements. Please refer to the current edition of
"IAB Official Protocol Standards" for the
state and status of this protocol. Distribution of this
is unlimited
Table of
1 Introduction .......................................... 2
1.1 A Note on Terminology ............................... 3
1.2 Threats ............................................. 4
1.3 Goals and Constraints ............................... 5
1.4 Security Services ................................... 6
1.5 Mechanisms .......................................... 7
1.5.1 Message Digest Algorithm .......................... 8
1.5.2 Symmetric Encryption Algorithm .................... 9
2 SNMPv2 Party .......................................... 11
3 Digest Authentication Protocol ........................ 14
3.1 Generating a Message ................................ 16
3.2 Receiving a Message ................................. 18
4 Symmetric Privacy Protocol ............................ 21
4.1 Generating a Message ................................ 21
4.2 Receiving a Message ................................. 22
5 Clock and Secret Distribution ......................... 24
5.1 Initial Configuration ............................... 25
5.2 Clock Distribution .................................. 28
5.3 Clock Synchronization ............................... 29
5.4 Secret Distribution ................................. 31
5.5 Crash Recovery ...................................... 34
6 Security Considerations ............................... 37
6.1 Recommended Practices ............................... 37
6.2 Conformance ......................................... 39
6.3 Protocol Correctness ................................ 42
Galvin & McCloghrie [Page i
RFC 1446 Security Protocols for SNMPv2 April 1993
6.3.1 Clock Monotonicity Mechanism ...................... 43
6.3.2 Data Integrity Mechanism .......................... 43
6.3.3 Data Origin Authentication Mechanism .............. 44
6.3.4 Restricted Administration Mechanism ............... 44
6.3.5 Message Timeliness Mechanism ...................... 45
6.3.6 Selective Clock Acceleration Mechanism ............ 46
6.3.7 Confidentiality Mechanism ......................... 47
7 Acknowledgements ...................................... 48
8 References ............................................ 49
9 Authors' Addresses .................................... 51
Galvin & McCloghrie [Page 1]
RFC 1446 Security Protocols for SNMPv2 April 1993
1.
A network management system contains: several (
many) nodes, each with a processing entity, termed an agent
which has access to management instrumentation; at least
management station; and, a management protocol, used to
management information between the agents and
stations. Operations of the protocol are carried out under
administrative framework which defines both authentication
authorization policies
Network management stations execute management
which monitor and control network elements. Network
are devices such as hosts, routers, terminal servers, etc.,
which are monitored and controlled through access to
management information
In the Administrative Model for SNMPv2 document [1],
SNMPv2 party is, by definition, associated with a
authentication protocol and a single privacy protocol. It
the purpose of this document, Security Protocols for SNMPv2,
to define one such authentication and one such
protocol
The authentication protocol provides a mechanism by
SNMPv2 management communications transmitted by the party
be reliably identified as having originated from that party
The authentication protocol defined in this memo also
determines that the message received is the message that
sent
The privacy protocol provides a mechanism by which SNMPv
management communications transmitted to said party
protected from disclosure. The privacy protocol in this
specifies that only authenticated messages may be
from disclosure
These protocols are secure alternatives to the so-
"trivial" protocol defined in [2].
USE OF THE TRIVIAL PROTOCOL ALONE DOES NOT
SECURE NETWORK MANAGEMENT. THEREFORE, A
MANAGEMENT SYSTEM THAT IMPLEMENTS ONLY THE
PROTOCOL IS NOT CONFORMANT TO THIS SPECIFICATION
Galvin & McCloghrie [Page 2]
RFC 1446 Security Protocols for SNMPv2 April 1993
The Digest Authentication Protocol is described in Section 3.
It provides a data integrity service by transmitting a
digest - computed by the originator and verified by
recipient - with each SNMPv2 message. The data
authentication service is provided by prefixing the
with a secret value known only to the originator
recipient, prior to computing the digest. Thus,
integrity is supported explicitly while data
authentication is supported implicitly in the verification
the digest
The Symmetric Privacy Protocol is described in Section 4.
protects messages from disclosure by encrypting their
according to a secret cryptographic key known only to
originator and recipient. The additional
afforded by this protocol is assumed to justify its
computational cost
The Digest Authentication Protocol depends on the existence
loosely synchronized clocks between the originator
recipient of a message. The protocol specification makes
assumptions about the strategy by which such clocks
synchronized. Section 5.3 presents one strategy that
particularly suited to the demands of SNMP network management
Both protocols described here require the sharing of
information between the originator of a message and
recipient. The protocol specifications assume the
of the necessary secrets. The selection of such secrets
their secure distribution to appropriate parties may
accomplished by a variety of strategies. Section 5.4
one such strategy that is particularly suited to the
of SNMP network management
1.1. A Note on
For the purpose of exposition, the original Internet-
Network Management Framework, as described in RFCs 1155, 1157,
and 1212, is termed the SNMP version 1 framework (SNMPv1).
The current framework is termed the SNMP version 2
(SNMPv2).
Galvin & McCloghrie [Page 3]
RFC 1446 Security Protocols for SNMPv2 April 1993
1.2.
Several of the classical threats to network protocols
applicable to the network management problem and
would be applicable to any SNMPv2 security protocol.
threats are not applicable to the network management problem
This section discusses principal threats, secondary threats
and threats which are of lesser importance
The principal threats against which any SNMPv2
protocol should provide protection are
Modification of
The SNMPv2 protocol provides the means for
stations to interrogate and to manipulate the value
objects in a managed agent. The modification threat
the danger that some party may alter in-transit
generated by an authorized party in such a way as
effect unauthorized management operations,
falsifying the value of an object
The SNMPv2 administrative model includes an
control model. Access control necessarily depends
knowledge of the origin of a message. The
threat is the danger that management operations
authorized for some party may be attempted by that
by assuming the identity of another party that has
appropriate authorizations
Two secondary threats are also identified. The
protocols defined in this memo do provide protection against
Message Stream
The SNMPv2 protocol is based upon a
transport service which may operate over any
service. The re-ordering, delay or replay of
can and does occur through the natural operation of
such subnetwork services. The message
modification threat is the danger that messages may
maliciously re-ordered, delayed or replayed to an
which is greater than can occur through the
operation of a subnetwork service, in order to
unauthorized management operations
Galvin & McCloghrie [Page 4]
RFC 1446 Security Protocols for SNMPv2 April 1993
The disclosure threat is the danger of eavesdropping
the exchanges between managed agents and a
station. Protecting against this threat is
when the SNMPv2 is used to create new SNMPv2 parties [1]
on which subsequent secure operation might be based
Protecting against the disclosure threat may also
required as a matter of local policy
There are at least two threats that a SNMPv2 security
need not protect against. The security protocols defined
this memo do not provide protection against
Denial of
A SNMPv2 security protocol need not attempt to
the broad range of attacks by which service to
parties is denied. Indeed, such denial-of-
attacks are in many cases indistinguishable from the
of network failures with which any viable
management protocol must cope as a matter of course
Traffic
In addition, a SNMPv2 security protocol need not
to address traffic analysis attacks. Indeed,
traffic patterns are predictable - agents may be
on a regular basis by a relatively small number
management stations - and therefore there is
significant advantage afforded by protecting
traffic analysis
1.3. Goals and
Based on the foregoing account of threats in the SNMP
management environment, the goals of a SNMPv2
protocol are enumerated below
(1) The protocol should provide for verification that
received SNMPv2 message has not been modified during
transmission through the network in such a way that
unauthorized management operation might result
(2) The protocol should provide for verification of
identity of the originator of each received SNMPv
message
Galvin & McCloghrie [Page 5]
RFC 1446 Security Protocols for SNMPv2 April 1993
(3) The protocol should provide that the apparent time
generation for each received SNMPv2 message is recent
(4) The protocol should provide, when necessary, that
contents of each received SNMPv2 message are
from disclosure
In addition to the principal goal of supporting secure
management, the design of any SNMPv2 security protocol is
influenced by the following constraints
(1) When the requirements of effective management in times
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 availability
other network services (e.g., Network Time Protocol (NTP
or secret/key management protocols).
(3) A security mechanism should entail no changes to
basic SNMP network management philosophy
1.4. Security
The security services necessary to support the goals of
SNMPv2 security protocol are as follows
Data
is the provision of the property that data has not
altered or destroyed in an unauthorized manner, nor
data sequences been altered to an extent greater than
occur non-maliciously
Data Origin
is the provision of the property that the claimed
of received data is corroborated
Data
is the provision of the property that information is
made available or disclosed to unauthorized individuals
entities, or processes
Galvin & McCloghrie [Page 6]
RFC 1446 Security Protocols for SNMPv2 April 1993
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
data integrity without data origin authentication, nor is
possible to realize data origin authentication without
integrity
Further, there is no provision for data
without both data integrity and data origin authentication
1.5.
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 SNMPv2 message and included as part of
message sent to the recipient
o In support of data origin authentication and
integrity, the portion of a SNMPv2 message that
digested is first prefixed with a secret value shared
the originator of that message and its
recipient
o To protect against the threat of message delay or replay
(to an extent greater than can occur through
operation), a timestamp value is included in each
generated. A recipient evaluates the timestamp
determine if the message is recent. This
against the threat of message delay or replay does
imply nor provide any protection against
deletion or suppression of messages. Other
defined independently of the security protocol can
be used to detect message replay (e.g., the request-
[2]), or for set operations, the re-ordering, replay
deletion, or suppression of messages (e.g., the
variable snmpSetSerialNo [14]).
o In support of data confidentiality, a
encryption algorithm is required. An appropriate
of the message is encrypted prior to being transmitted
Galvin & McCloghrie [Page 7]
RFC 1446 Security Protocols for SNMPv2 April 1993
its recipient
The security protocols in this memo are defined
of the particular choice of a message digest and
algorithm - owing principally to the lack of a suitable
by which to evaluate the security of particular
choices. However, in the interests of completeness and
order to guarantee interoperability, Sections 1.5.1 and 1.5.2
specify particular choices, which are considered
secure as of this writing. In the future, this memo may
updated by the publication of a memo specifying substitute
alternate choices of algorithms, i.e., a replacement for
addition to the sections below
1.5.1. Message Digest
In support of data integrity, the use of the MD5 [3]
digest algorithm is chosen. A 128-bit digest is
over the designated portion of a SNMPv2 message and
as part of the message sent to the recipient
An appendix of [3] contains a C Programming
implementation of the algorithm. This code was written
portability being the principal objective. Implementors
wish to optimize the implementation with respect to
characteristics of their hardware and software platforms
The use of this algorithm in conjunction with the
Authentication Protocol (see Section 3) is identified by
ASN.1 object identifier value v2md5AuthProtocol, defined
[4]. (Note that this protocol is a modified version of
md5AuthProtocol protocol defined in RFC 1352.)
For any SNMPv2 party for which the authentication protocol
v2md5AuthProtocol, the size of its private authentication
is 16 octets
Within an authenticated management communication generated
such a party, the size of the authDigest component of
communication (see Section 3) is 16 octets
Galvin & McCloghrie [Page 8]
RFC 1446 Security Protocols for SNMPv2 April 1993
1.5.2. Symmetric Encryption
In support of data confidentiality, the use of the
Encryption Standard (DES) in the Cipher Block Chaining mode
operation is chosen. The designated portion of a SNMPv
message is encrypted and included as part of the message
to the recipient
Two organizations have published specifications defining
DES: the National Institute of Standards and Technology (NIST
[5] and the American National Standards Institute [6].
is a companion Modes of Operation specification for
definition (see [7] and [8], respectively).
The NIST has published three additional documents
implementors may find useful
o There is a document with guidelines for implementing
using the DES, including functional specifications
the DES and its modes of operation [9].
o There is a specification of a validation test suite
the DES [10]. The suite is designed to test all
of the DES and is useful for pinpointing
problems
o There is a specification of a maintenance test for
DES [11]. The test utilizes a minimal amount of data
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
initialization step, e.g., when a computer reboots
The use of this algorithm in conjunction with the
Privacy Protocol (see Section 4) is identified by the ASN.1
object identifier value desPrivProtocol, defined in [4].
For any SNMPv2 party for which the privacy protocol
desPrivProtocol, the size of the private privacy key is 16
octets, of which the first 8 octets are a DES key and
second 8 octets are a DES Initialization Vector. The 64-
DES key in the first 8 octets of the private key is a 56
quantity used directly by the algorithm plus 8 parity bits -
arranged so that one parity bit is the least significant
of each octet. The setting of the parity bits is ignored
Galvin & McCloghrie [Page 9]
RFC 1446 Security Protocols for SNMPv2 April 1993
The length of the octet sequence to be encrypted by the
must be an integral multiple of 8. When encrypting, the
should be padded at the end as necessary; the actual pad
is insignificant
If the length of the octet sequence to be decrypted is not
integral multiple of 8 octets, the processing of the
sequence should be halted and an appropriate exception noted
Upon decrypting, the padding should be ignored
Galvin & McCloghrie [Page 10]
RFC 1446 Security Protocols for SNMPv2 April 1993
2. SNMPv2
Recall from [1] that a SNMPv2 party is a conceptual,
execution context whose operation is restricted (for
or other purposes) to an administratively defined subset
all possible operations of a particular SNMPv2 entity.
SNMPv2 entity is an actual process which performs
management operations by generating and/or responding
SNMPv2 protocol messages in the manner specified in [12].
Architecturally, every SNMPv2 entity maintains a
database that represents all SNMPv2 parties known to it
Galvin & McCloghrie [Page 11]
RFC 1446 Security Protocols for SNMPv2 April 1993
A SNMPv2 party may be represented by an ASN.1 value with
following syntax
SnmpParty ::= SEQUENCE {
OBJECT IDENTIFIER
OBJECT IDENTIFIER
OCTET STRING
INTEGER
OBJECT IDENTIFIER
INTEGER
OCTET STRING
OCTET STRING
INTEGER
OBJECT IDENTIFIER
OCTET STRING
OCTET
}
For each SnmpParty value that represents a SNMPv2 party,
generic significance of each of its components is defined
[1]. For each SNMPv2 party that supports the generation
messages using the Digest Authentication Protocol, additional
special significance is attributed to certain components
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 1.5.1).
This combined mechanism is used to authenticate
origin and integrity of all messages generated by
party
Galvin & McCloghrie [Page 12]
RFC 1446 Security Protocols for SNMPv2 April 1993
o Its partyAuthClock component is called the
clock and represents a notion of the current time that
specific to the party
o Its partyAuthPrivate component is called the
authentication key and represents any secret value
to support the Digest Authentication Protocol
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
This component is not significant except as suggested
Section 5.4.
o Its partyAuthLifetime component is called the
and represents an administrative upper bound
acceptable delivery delay for protocol messages
by the party
For each SNMPv2 party that supports the receipt of
via the Symmetric Privacy Protocol, additional,
significance is attributed to certain components of
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 1.5.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 5.4.
Galvin & McCloghrie [Page 13]
RFC 1446 Security Protocols for SNMPv2 April 1993
3. Digest Authentication
This section describes the Digest Authentication Protocol.
provides both for verifying the integrity of a
message (i.e., the message received is the message sent)
for verifying the origin of a message (i.e., the
identification of the originator). The integrity of
message is protected by computing a digest over an
portion of a message. The digest is computed by
originator of the message, transmitted with the message,
verified by the recipient of the message
A secret value known only to the originator and recipient
the message is prefixed to the message prior to the
computation. Thus, the origin of the message is
implicitly with the verification of the digest
A requirement on parties using this Digest
Protocol is that they shall not originate messages
transmission to any destination party which does not also
this Digest Authentication Protocol. This
excludes undesirable side effects of communication between
party which uses these security protocols and a party
does not
Recall from [1] that a SNMPv2 management communication
represented by an ASN.1 value with the following syntax
SnmpMgmtCom ::= [2] IMPLICIT SEQUENCE {
OBJECT IDENTIFIER
OBJECT IDENTIFIER
OBJECT IDENTIFIER
}
For each SnmpMgmtCom value that represents a SNMPv2
communication, the following statements are true
o Its dstParty component is called the destination
identifies the SNMPv2 party to which the communication
directed
Galvin & McCloghrie [Page 14]
RFC 1446 Security Protocols for SNMPv2 April 1993
o Its srcParty component is called the source
identifies the SNMPv2 party from which the
is originated
o Its context component identifies the SNMPv2
containing the management information referenced by
communication
o Its pdu component has the form and
attributed to it in [12].
Recall from [1] that a SNMPv2 authenticated
communication is represented by an ASN.1 value with
following syntax
SnmpAuthMsg ::= [1] IMPLICIT SEQUENCE {
ANY, - defined by authentication
}
For each SnmpAuthMsg value that represents a SNMPv
authenticated management communication, the
statements are true
o Its authInfo component is called the
information and represents information required
support of the authentication protocol used by both
SNMPv2 party originating the message, and the SNMPv
party receiving the message. The detailed
of the authentication information is specific to
authentication protocol in use; it has no effect on
application semantics of the communication other than
use by the authentication protocol in determining
the communication is authentic or not
o Its authData component is called the authentication
Galvin & McCloghrie [Page 15]
RFC 1446 Security Protocols for SNMPv2 April 1993
and represents a SNMPv2 management communication
In support of the Digest Authentication Protocol, an
component is of type AuthInformation
AuthInformation ::= [2] IMPLICIT SEQUENCE {
OCTET STRING
UInteger32,
UInteger32
}
For each AuthInformation value that represents
information, the following statements are true
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
o Its authSrcTimestamp component is called
authentication timestamp and represents the time of
generation of the message according to the
of the SNMPv2 party that originated it. Note that
granularity of the authentication timestamp is 1 second
o Its authDstTimestamp component is called
authentication timestamp and represents the time of
generation of the message according to the
of the SNMPv2 party that is to receive it. Note that
granularity of the authentication timestamp is 1 second
3.1. Generating a
This section describes the behavior of a SNMPv2 entity when
acts as a SNMPv2 party for which the authentication
is administratively specified as the Digest
Protocol. Insofar as the behavior of a SNMPv2 entity
transmitting protocol messages is defined generically in [1],
only those aspects of that behavior that are specific to
Digest Authentication Protocol are described below.
Galvin & McCloghrie [Page 16]
RFC 1446 Security Protocols for SNMPv2 April 1993
particular, this section describes the encapsulation of
SNMPv2 management communication into a SNMPv2
management communication
According to Section 3.1 of [1], a SnmpAuthMsg value
constructed during Step 3 of generic processing.
particular, it states the authInfo component is
according to the authentication protocol identified for
SNMPv2 party originating the message. When the
authentication protocol is the Digest Authentication Protocol
the procedure performed by a SNMPv2 entity whenever
management communication is to be transmitted by a SNMPv
party is as follows
(1) The local database is consulted to determine
authentication clock and private authentication
(extracted, for example, according to the
defined in Section 1.5.1) of the SNMPv2 party
the message. The local database is also consulted
determine the authentication clock of the
SNMPv2 party
(2) The authSrcTimestamp component is set to the
authentication clock value of the message's source.
authDstTimestamp component is set to the
authentication clock value of the message's
recipient
(3) The authentication digest is temporarily set to
private authentication key of the SNMPv2
originating the message. The SnmpAuthMsg value
serialized according to the conventions of [13] and [12].
A digest is computed over the octet sequence
that serialized value using, for example, the
specified in Section 1.5.1. The authDigest component
set to the computed digest value
As set forth in [1], the SnmpAuthMsg value is
encapsulated according to the appropriate privacy
into a SnmpPrivMsg value. This latter value is
serialized and transmitted to the receiving SNMPv2 party
Galvin & McCloghrie [Page 17]
RFC 1446 Security Protocols for SNMPv2 April 1993
3.2. Receiving a
This section describes the behavior of a SNMPv2 entity
receipt of a protocol message from a SNMPv2 party for
the authentication protocol is administratively specified
the Digest Authentication Protocol. Insofar as the
of a SNMPv2 entity when receiving protocol messages is
generically in [1], only those aspects of that behavior
are specific to the Digest Authentication Protocol
described below
According to Section 3.2 of [1], a SnmpAuthMsg value
evaluated during Step 9 of generic processing. In particular
it states the SnmpAuthMsg value is evaluated according to
authentication protocol identified for the SNMPv2 party
originated the message. When the relevant
protocol is the Digest Authentication Protocol, the
performed by a SNMPv2 entity whenever a
communication is received by a SNMPv2 party is as follows
(1) If the ASN.1 type of the authInfo component is
AuthInformation, the message is evaluated as unauthentic
and the snmpStatsBadAuths counter [14] is incremented
Otherwise, the authSrcTimestamp, authDstTimestamp,
authDigest components are extracted from the
value
(2) The local database is consulted to determine
authentication clock, private authentication
(extracted, for example, according to the
defined in Section 1.5.1), and lifetime of the SNMPv
party that originated the message
(3) If the authSrcTimestamp component plus the lifetime
less than the authentication clock, the message
evaluated as unauthentic, and the
counter [14] is incremented
(4) The authDigest component is extracted and
recorded
(5) A new SnmpAuthMsg value is constructed such that
authDigest component is set to the private
key and its other components are set to the value of
corresponding components in the received
Galvin & McCloghrie [Page 18]
RFC 1446 Security Protocols for SNMPv2 April 1993
value. This new SnmpAuthMsg value is
according to the conventions of [13] and [12]. A
is computed over the octet sequence representing
serialized value using, for example, the
specified in Section 1.5.1.
Because serialization rules are unambiguous but
not be unique, great care must be taken
reconstructing the serialized value prior
computing the digest. Implementations may find
useful to keep a copy of the original
value and then simply modify the octets
directly correspond to the placement of
authDigest component, rather than re-applying
serialization algorithm to the new
value
(6) If the computed digest value is not equal to the
value temporarily recorded in step 4 above, the
is evaluated as unauthentic, and
snmpStatsWrongDigestValues counter [14] is incremented
(7) The message is evaluated as authentic
(8) The local database is consulted for access
permitted by the local access policy to the
SNMPv2 party with respect to the receiving SNMPv2 party
If any level of access is permitted, then
the authentication clock value locally recorded for
originating SNMPv2 party is advanced to
authSrcTimestamp value if this latter exceeds
recorded value; and
the authentication clock value locally recorded for
receiving SNMPv2 party is advanced to
authDstTimestamp value if this latter exceeds
recorded value
(Note that this step is conceptually independent
Steps 15-17 of Section 3.2 in [1]).
If the SnmpAuthMsg value is evaluated as unauthentic,
authentication failure is noted and the received message
Galvin & McCloghrie [Page 19]
RFC 1446 Security Protocols for SNMPv2 April 1993
discarded without further processing. Otherwise,
of the received message continues as specified in [1].
Galvin & McCloghrie [Page 20]
RFC 1446 Security Protocols for SNMPv2 April 1993
4. Symmetric Privacy
This section describes the Symmetric Privacy Protocol.
provides for protection from disclosure of a received message
An appropriate portion of the message is encrypted
to a secret key known only to the originator and recipient
the message
This protocol assumes the underlying mechanism is a
encryption algorithm. In addition, the message to
encrypted must be protected according to the conventions
the Digest Authentication Protocol
Recall from [1] that a SNMPv2 private management
is represented by an ASN.1 value with the following syntax
SnmpPrivMsg ::= [1] IMPLICIT SEQUENCE {
OBJECT IDENTIFIER
[1] IMPLICIT OCTET
}
For each SnmpPrivMsg value that represents a SNMPv2
management communication, the following statements are true
o Its privDst component is called the privacy
and identifies the SNMPv2 party to which
communication is directed
o Its privData component is called the privacy data
represents the (possibly encrypted)
(according to the conventions of [13] and [12]) of
SNMPv2 authenticated management communication
4.1. Generating a
This section describes the behavior of a SNMPv2 entity when
communicates with a SNMPv2 party for which the
protocol is administratively specified as the
Privacy Protocol. Insofar as the behavior of a SNMPv2
when transmitting a protocol message is defined generically
[1], only those aspects of that behavior that are specific
the Symmetric Privacy Protocol are described below.
Galvin & McCloghrie [Page 21]
RFC 1446 Security Protocols for SNMPv2 April 1993
particular, this section describes the encapsulation of
SNMPv2 authenticated management communication into a SNMPv
private management communication
According to Section 3.1 of [1], a SnmpPrivMsg value
constructed during Step 5 of generic processing.
particular, it states the privData component is
according to the privacy protocol identified for the SNMPv
party receiving the message. When the relevant
protocol is the Symmetric Privacy Protocol, the
performed by a SNMPv2 entity whenever a
communication is to be transmitted by a SNMPv2 party is
follows
(1) If the SnmpAuthMsg value is not authenticated
to the conventions of the Digest Authentication Protocol
the generation of the private management
fails according to a local procedure, without
processing
(2) The local database is consulted to determine the
privacy key of the SNMPv2 party receiving the
(represented, for example, according to the
defined in Section 1.5.2).
(3) The SnmpAuthMsg value is serialized according to
conventions of [13] and [12].
(4) The octet sequence representing the
SnmpAuthMsg value is encrypted using, for example,
algorithm specified in Section 1.5.2 and the
private privacy key
(5) The privData component is set to the encrypted value
As set forth in [1], the SnmpPrivMsg value is then
and transmitted to the receiving SNMPv2 party
4.2. Receiving a
This section describes the behavior of a SNMPv2 entity when
acts as a SNMPv2 party for which the privacy protocol
administratively specified as the Symmetric Privacy Protocol
Insofar as the behavior of a SNMPv2 entity when receiving
Galvin & McCloghrie [Page 22]
RFC 1446 Security Protocols for SNMPv2 April 1993
protocol message is defined generically in [1], only
aspects of that behavior that are specific to the
Privacy Protocol are described below
According to Section 3.2 of [1], the privData component of
received SnmpPrivMsg value is evaluated during Step 4
generic processing. In particular, it states the
component is evaluated according to the privacy
identified for the SNMPv2 party receiving the message.
the relevant privacy protocol is the Symmetric
Protocol, the procedure performed by a SNMPv2 entity
a management communication is received by a SNMPv2 party is
follows
(1) The local database is consulted to determine the
privacy key of the SNMPv2 party receiving the
(represented, for example, according to the
defined in Section 1.5.2).
(2) The contents octets of the privData component
decrypted using, for example, the algorithm specified
Section 1.5.2 and the extracted private privacy key
Processing of the received message continues as specified
[1].
Galvin & McCloghrie [Page 23]
RFC 1446 Security Protocols for SNMPv2 April 1993
5. Clock and Secret
The protocols described in Sections 3 and 4 assume
existence of loosely synchronized clocks and shared
values. Three requirements constrain the strategy by
clock values and secrets are distributed
o If the value of an authentication clock is decreased,
private authentication key must be 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 its
value may be replayed. Changing the
authentication key obviates this threat
o The private authentication key and private privacy
must be known only to the parties requiring knowledge
them
Protecting the secrets from disclosure is critical to
security of the protocols. Knowledge of the secrets
be as restricted as possible within an implementation
In particular, although the secrets may be known to
or more persons during the initial configuration of
device, the secrets should be changed immediately
configuration such that their actual value is known
to the software. A management station has the
responsibility of recovering the state of all
whenever it boots, and it may address this
by recording the secrets on a long-term storage device
Access to information on this device must be
restricted as is practically possible
o There must exist at least one SNMPv2 entity that
the role of a responsible management station
This management station is responsible for ensuring
all authentication clocks are synchronized and
changing the secret values when necessary. Although
than one management station may share
responsibility, their coordination is essential to
secure management of the network. The mechanism by
multiple management stations ensure that no more than
of them attempts to synchronize the clocks or update
Galvin & McCloghrie [Page 24]
RFC 1446 Security Protocols for SNMPv2 April 1993
secrets at any one time is a local implementation issue
A responsible management station may either support
synchronization and secret distribution as
functions, or combine them into a single functional unit
The first section below specifies the procedures by which
SNMPv2 entity is initially configured. The next two
describe one strategy for distributing clock values and
for determining a synchronized clock value among SNMPv
parties supporting the Digest Authentication Protocol.
SNMPv2 parties supporting the Symmetric Privacy Protocol,
next section describes a strategy for distributing
values. The last section specifies the procedures by which
SNMPv2 entity recovers from a "crash."
5.1. Initial
This section describes the initial configuration of a SNMPv
entity that supports the Digest Authentication Protocol
both the Digest Authentication Protocol and the
Privacy Protocol
When a network device is first installed, its initial,
configuration must be done manually, i.e., a person
physically visit the device and enter the initial
values for at least its first secure SNMPv2 party.
requirement suggests that the person will have knowledge
the initial secret values
In general, the security of a system is enhanced as the
of entities that know a secret is reduced. Requiring a
to physically visit a device every time a SNMPv2 party
configured not only exposes the secrets unnecessarily but
administratively prohibitive. In particular, when MD5
used, the initial authentication secret is 128 bits long
when DES is used an additional 128 bits are needed - 64
each for the key and initialization vector. Clearly,
values will need to be recorded on a medium in order to
transported between a responsible management station and
managed agent. The recommended procedure is to configure
small set of initial SNMPv2 parties for each SNMPv2 entity
one pair of which may be used initially to configure all
SNMPv2 parties
Galvin & McCloghrie [Page 25]
RFC 1446 Security Protocols for SNMPv2 April 1993
In fact, there is a minimal, useful set of SNMPv2 parties
could be configured between each responsible
station and managed agent. This minimal set includes one
each of the following for both the responsible
station and the managed agent
o a SNMPv2 party for which the authentication protocol
privacy protocol are the values noAuth and noPriv
respectively
o a SNMPv2 party for which the authentication
identifies the mechanism defined in Section 1.5.1 and
privacy protocol is the value noPriv,
o a SNMPv2 party for which the authentication protocol
privacy protocol identify the mechanisms defined
Section 1.5.1 and Section 1.5.2, respectively
The last of these SNMPv2 parties in both the
management station and the managed agent could be used
create all other SNMPv2 parties
Configuring one pair of SNMPv2 parties to be used to
all other parties has the advantage of exposing only one
of secrets - the secrets used to configure the minimal,
set identified above. To limit this exposure, the
management station should change these values as its
operation upon completion of the initial configuration.
this way, secrets are known only to the peers
knowledge of them in order to communicate
The Management Information Base (MIB) document [4]
these security protocols specifies 6 initial party
and initial values, which, by convention, are assigned to
parties and their associated parameters
These 6 initial parties are required to exist as part of
configuration of implementations when first installed,
the exception that implementations not providing support for
privacy protocol only need the 4 initial parties for which
privacy protocol is noPriv. When installing a managed agent
these parties need to be configured with their
secrets, etc., both in the responsible management station
in the new agent
Galvin & McCloghrie [Page 26]
RFC 1446 Security Protocols for SNMPv2 April 1993
If the responsible management station is configured first,
can be used to generate the initial secrets and provide
to a person, on a suitable medium, for distribution to
managed agent. The following sequence of steps describes
initial configuration of a managed agent and its
management station
(1) Determine the initial values for each of the
of the SNMPv2 party to be configured. Some of
values may be computed by the responsible
station, some may be specified in the MIB document,
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 to
entered into the agent, an appropriate medium must
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 synchronize
authentication clock values for each party it shares
each managed agent. Section 5.3 specifies one
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 knowledge
them in order to communicate. To do this, the
station generates new secrets for each party to
reconfigured and distributes the updates using
strategy which protects the new values from disclosure
use of a SNMPv2 set operation acting on the
objects defined in [4] is such a strategy.
receiving positive acknowledgement that the new
have been distributed, the management station
update its local database with the new values
If the managed agent does not support a protocol that
messages from disclosure, e.g., the Symmetric Privacy
(see section 5.4), then the distribution of new secrets,
the compromise of existing secrets, is not possible. In
case, the new secrets can only be distributed by a
Galvin & McCloghrie [Page 27]
RFC 1446 Security Protocols for SNMPv2 April 1993
visit to the device
If there are other SNMPv2 protocol entities
knowledge of the secrets, the responsible management
must distribute the information upon completion of the
configuration. The considerations, mentioned above
concerning the protection of secrets from disclosure,
apply in this case
5.2. Clock
A responsible management station must ensure that
authentication clock value for each SNMPv2 party for which
is
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
lifetime value, in addition to the expected
delivery delay
A skewed authentication clock may be detected by a number
strategies, including knowledge of the accuracy of the
clock, unauthenticated queries of the party database,
recognition of authentication failures originated by
party
Whenever clock skew is detected, and whenever the SNMPv
entities at both the responsible management station and
relevant managed agent support an appropriate privacy
(e.g., the Symmetric Privacy Protocol), a
strategy for the correction of clock skew is
alteration of authentication clock and private key for
relevant SNMPv2 party. If the request to alter the key
clock for a particular party originates from that same party
then, prior to transmitting that request, the local notion
the authentication clock is artificially advanced to
acceptance of the request as authentic
Galvin & McCloghrie [Page 28]
RFC 1446 Security Protocols for SNMPv2 April 1993
More generally, however, since an authentication clock
need not be protected from disclosure, it is not
that a managed agent support a privacy protocol in order for
responsible management station to correct skewed clock values
The procedure for correcting clock skew in the general case
presented in Section 5.3.
In addition to correcting skewed notions of
clocks, every SNMPv2 entity must react correctly as
