draft-ietf-snmpv3-usec-00.txt   draft-ietf-snmpv3-usec-01.txt 
skipping to change at page 10, line ? skipping to change at page 10, line ?
User-based Security Model for version 3 of the User-based Security Model for version 3 of the
Simple Network Management Protocol (SNMPv3) Simple Network Management Protocol (SNMPv3)
U. Blumenthal U. Blumenthal
IBM T. J. Watson Research IBM T. J. Watson Research
uri@watson.ibm.com uri@watson.ibm.com
B. Wijnen B. Wijnen
IBM T. J. Watson Research IBM T. J. Watson Research
wijnen@vnet.ibm.com wijnen@vnet.ibm.com
<draft-ietf-snmpv3-usec-00.txt> <draft-ietf-snmpv3-usec-01.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
skipping to change at page 10, line ? skipping to change at page 10, line ?
material or to cite them other than as ``work in progress.'' material or to cite them other than as ``work in progress.''
To learn the current status of any Internet-Draft, please check the To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow
Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe),
ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
Abstract Abstract
This document describes the User-based Security Model (USEC) for SNMP This document describes the User-based Security Model (USEC) for SNMP
version 3 for use in the SNMPng architecture [SNMPng-ARCH]. This version 3 for use in the SNMP architecture [SNMP-ARCH]. This
document defines the Elements of Procedure for providing SNMP message document defines the Elements of Procedure for providing SNMP message
level security. This document also includes a MIB for remotely level security. This document also includes a MIB for remotely
monitoring/managing the configuration parameters for this Security monitoring/managing the configuration parameters for this Security
model. model.
Blumenthal/Wijnen Expires November 1997 [Page 1] 0.1 Issues
- Do we indeed want to move all STATS counters to MPC, we
have assumed so for now.
- Do we need to do group mapping here and pass it back to MPC
we have assumed so for now... but other documents do not pass
groupName around.
0. Change Log Blumenthal/Wijnen Expires December 1997 [Page 1]
- Do we want to check reportableFlag to determine if caching
of securityData is needed or not.
0.2 Change Log
[version 1.2]
- changed (simplified) time sync in section 3 item 7.
- added usecUserMiId
- cleaned up text
- defined IV "salt" generation
- removed Statistics counters (now in MPC) and reportPDU
generation (now in MPC)
- Removed auth and des MIBs which are now merged into USEC MIB
- specified where cachedSecurityData needs to be discarded
- added abtract service interface definitions
- removed section on error reporting (is MPC responsibility)
- removed auth/priv protocol definitions, they are in ARCH now
- removed MIB definitions for snmpEngineID,Time,Boots. They
are in ARCH now.
[version 1.1]
- removed <securityCookie>.
- added <securityIdentity>, <securityCachedData>.
- added abstract function interface description of
inter-module communications.
- modified IV generation process to accomodate messages produced
faster than one-per-second (still open).
- always update the clock regardless of whether incoming message
was Report or not (if the message was properly authenticated
and its timestamp is ahead of our notion of their clock).
[version 1.0] [version 1.0]
- first version posted to the v3editors mailing list. - first version posted to the v3editors mailing list.
- based on v2adv slides, v2adv items and issues list and on - based on v2adv slides, v2adv items and issues list and on
RFC1910 and SNMPv2u and SNMPv2* documents. RFC1910 and SNMPv2u and SNMPv2* documents.
- various iterations were done by the authors via private email. - various iterations were done by the authors via private email.
Blumenthal/Wijnen Expires November 1997 [Page 2] Blumenthal/Wijnen Expires December 1997 [Page 2]
1. Introduction 1. Introduction
Please refer to the introduction of the SNMP Architectural model The Architecture for describing Internet Management Frameworks
[SNMPng-ARCH] for an overall introduction to the SNMP components. is composed of multiple subsystems:
That same document explains the terminology in the various SNMP 1) a message processing and control subsystem,
components and documents. 2) a security subsystem,
3) an access control subsystem, and
4) orangelets.
It is important to understand the SNMP architecture and the
terminology of the architecture to understand where the model
described in this document fits into the architecture and interacts
with other subsystems within the architecture. The reader is
expected to have read and understood the description of the SNMP
architecture, as defined in [SNMP-ARCH].
This memo [SNMPv3-USEC] describes the User-Based Security model This memo [SNMPv3-USEC] describes the User-Based Security model
as it is used within the SNMPng Architectural model. The main idea as it is used within the SNMP Architecture. The main idea is that
is that we use the traditional concept of a user (identified by a we use the traditional concept of a user (identified by a userName)
userName) to associate security information with. to associate security information with.
This memo describes the use of Keyed-MD5 as the authentication This memo describes the use of Keyed-MD5 as the authentication
protocol and the use of CBC-DES as the privacy protocol. protocol and the use of CBC-DES as the privacy protocol.
The User-based Security model however allows for other such The User-based Security model however allows for other such
protocols to be used instead of or concurrent with these protocols. protocols to be used instead of or concurrent with these protocols.
So the description of Keyed-MD5 and CBC-DES are in separate sections. So the description of Keyed-MD5 and CBC-DES are in separate sections.
That way it shows that they are supposed to be self-contained That way it shows that they are supposed to be self-contained
pieces that can be replaced or supplemented in the future. pieces that can be replaced or supplemented in the future.
1.1. Threats 1.1. Threats
Several of the classical threats to network protocols are applicable Several of the classical threats to network protocols are applicable
to the network management problem and therefore would be applicable to the network management problem and therefore would be applicable
to any SNMPv3 security model. Other threats are not applicable to to any SNMP security model. Other threats are not applicable to
the network management problem. This section discusses principal the network management problem. This section discusses principal
threats, secondary threats, and threats which are of lesser threats, secondary threats, and threats which are of lesser
importance. importance.
The principal threats against which this SNMPv3 security model The principal threats against which this SNMPv3 security model
should provide protection are: should provide protection are:
- Modification of Information - Modification of Information
The modification threat is the danger that some unauthorized entity The modification threat is the danger that some unauthorized entity
may alter in-transit SNMPv3 messages generated on behalf of an may alter in-transit SNMPv3 messages generated on behalf of an
authorized user in such a way as to effect unauthorized management authorized user in such a way as to effect unauthorized management
operations, including falsifying the value of an object. operations, including falsifying the value of an object.
- Masquerade - Masquerade
The masquerade threat is the danger that management operations not The masquerade threat is the danger that management operations not
authorized for some user may be attempted by assuming the identity authorized for some user may be attempted by assuming the identity
of another user that has the appropriate authorizations. of another user that has the appropriate authorizations.
Blumenthal/Wijnen Expires December 1997 [Page 3]
Two secondary threats are also identified. The security protocols Two secondary threats are also identified. The security protocols
defined in this memo provide limited protection against: defined in this memo provide limited protection against:
- Disclosure - Disclosure
The disclosure threat is the danger of eavesdropping on the The disclosure threat is the danger of eavesdropping on the
exchanges between managed agents and a management station. exchanges between managed agents and a management station.
Protecting against this threat may be required as a matter of local Protecting against this threat may be required as a matter of
policy. local policy.
Blumenthal/Wijnen Expires November 1997 [Page 3]
- Message Stream Modification - Message Stream Modification
The SNMPv3 protocol is typically based upon a connection-less The SNMPv3 protocol is typically based upon a connection-less
transport service which may operate over any sub-network service. transport service which may operate over any sub-network service.
The re-ordering, delay or replay of messages can and does occur The re-ordering, delay or replay of messages can and does occur
through the natural operation of many such sub-network services. through the natural operation of many such sub-network services.
The message stream modification threat is the danger that messages The message stream modification threat is the danger that messages
may be maliciously re-ordered, delayed or replayed to an extent may be maliciously re-ordered, delayed or replayed to an extent
which is greater than can occur through the natural operation of a which is greater than can occur through the natural operation of a
sub-network service, in order to effect unauthorized management sub-network service, in order to effect unauthorized management
operations. operations.
skipping to change at page 10, line ? skipping to change at page 10, line ?
Based on the foregoing account of threats in the SNMP network Based on the foregoing account of threats in the SNMP network
management environment, the goals of this SNMPv3 security model are management environment, the goals of this SNMPv3 security model are
as follows. as follows.
1) The protocol should provide for verification that each received 1) The protocol should provide for verification that each received
SNMPv3 message has not been modified during its transmission SNMPv3 message has not been modified during its transmission
through the network in such a way that an unauthorized management through the network in such a way that an unauthorized management
operation might result. operation might result.
2) The protocol should provide for verification of the identity of 2) The protocol should provide for verification of the identity of
Blumenthal/Wijnen Expires December 1997 [Page 4]
the user on whose behalf a received SNMPv3 message claims to have the user on whose behalf a received SNMPv3 message claims to have
been generated. been generated.
3) The protocol should provide for detection of received SNMPv3 3) The protocol should provide for detection of received SNMPv3
messages, which request or contain management information, whose messages, which request or contain management information, whose
time of generation was not recent. time of generation was not recent.
4) The protocol should provide, when necessary, that the contents of 4) The protocol should provide, when necessary, that the contents of
each received SNMPv3 message are protected from disclosure. each received SNMPv3 message are protected from disclosure.
Blumenthal/Wijnen Expires November 1997 [Page 4]
In addition to the principal goal of supporting secure network In addition to the principal goal of supporting secure network
management, the design of this SNMPv3 security model is also management, the design of this SNMPv3 security model is also
influenced by the following constraints: influenced by the following constraints:
1) When the requirements of effective management in times of network 1) When the requirements of effective management in times of network
stress are inconsistent with those of security, the design should stress are inconsistent with those of security, the design should
prefer the former. prefer the former.
2) Neither the security protocol nor its underlying security 2) Neither the security protocol nor its underlying security
mechanisms should depend upon the ready availability of other mechanisms should depend upon the ready availability of other
skipping to change at page 10, line ? skipping to change at page 10, line ?
is the provision of the property that information is not made is the provision of the property that information is not made
available or disclosed to unauthorized individuals, entities, or available or disclosed to unauthorized individuals, entities, or
processes. processes.
For the protocols specified in this memo, it is not possible to For the protocols specified in this memo, it is not possible to
assure the specific originator of a received SNMPv3 message; rather, assure the specific originator of a received SNMPv3 message; rather,
it is the user on whose behalf the message was originated that is it is the user on whose behalf the message was originated that is
authenticated. authenticated.
For these protocols, it not possible to obtain data integrity without For these protocols, it not possible to obtain data integrity without
Blumenthal/Wijnen Expires December 1997 [Page 5]
data origin authentication, nor is it possible to obtain data origin data origin authentication, nor is it possible to obtain data origin
authentication without data integrity. Further, there is no authentication without data integrity. Further, there is no
provision for data confidentiality without both data integrity and provision for data confidentiality without both data integrity and
data origin authentication. data origin authentication.
The security protocols used in this memo are considered acceptably The security protocols used in this memo are considered acceptably
secure at the time of writing. However, the procedures allow for new secure at the time of writing. However, the procedures allow for new
authentication and privacy methods to be specified at a future time authentication and privacy methods to be specified at a future time
if the need arises. if the need arises.
Blumenthal/Wijnen Expires November 1997 [Page 5]
1.4. Implementation Organization 1.4. Implementation Organization
The security protocols defined in this memo are implemented in three The security protocols defined in this memo are implemented in three
different modules and each have their specific responsibilities such different modules and each have their specific responsibilities such
that together they realize the goals and security services described that together they realize the goals and security services described
above: above:
- The timeliness module must provide for: - The timeliness module must provide for:
- Protection against message delay or replay (to an extent greater - Protection against message delay or replay (to an extent greater
skipping to change at page 10, line ? skipping to change at page 10, line ?
performed if authentication is applied to the message. Since the performed if authentication is applied to the message. Since the
complete message is checked for integrity, we can assume that the complete message is checked for integrity, we can assume that the
time values in a message that passes the authentication module are time values in a message that passes the authentication module are
trustworthy. trustworthy.
1.4.2. Authentication Protocol 1.4.2. Authentication Protocol
Section 6 describes the Keyed-MD5 authentication protocol which is Section 6 describes the Keyed-MD5 authentication protocol which is
the first authentication protocol to be used with the User-based the first authentication protocol to be used with the User-based
Security model. In the future additional or replacement Security model. In the future additional or replacement
Blumenthal/Wijnen Expires December 1997 [Page 6]
authentication protocols may be defined as new needs arise. authentication protocols may be defined as new needs arise.
This User-based Security model prescribes that the complete message This User-based Security model prescribes that the complete message
is checked for integrity in the authentication module. is checked for integrity in the authentication module.
For a message to be authenticated, it needs to pass authentication For a message to be authenticated, it needs to pass authentication
check by the authentication module and the timeliness check which check by the authentication module and the timeliness check which
is a fixed part of this User-based Security model. is a fixed part of this User-based Security model.
Blumenthal/Wijnen Expires November 1997 [Page 6]
1.4.3. Privacy Protocol 1.4.3. Privacy Protocol
Section 7 describes the CBC-DES Symmetric Encryption Protocol which Section 7 describes the CBC-DES Symmetric Encryption Protocol which
the first privacy protocol to be used with the User-based Security the first privacy protocol to be used with the User-based Security
model. In the future additional or replacement privacy protocols model. In the future additional or replacement privacy protocols
may be defined as new needs arise. may be defined as new needs arise.
This User-based Security model prescribes that the scopedPDU This User-based Security model prescribes that the scopedPDU
is protected from disclosure when a message is sent with privacy. is protected from disclosure when a message is sent with privacy.
This User-based Security model also prescribes that a message needs This User-based Security model also prescribes that a message needs
to be authenticated if privacy is in use. to be authenticated if privacy is in use.
1.5 Mechanisms to protect against Message Replay, Delay and Redirection 1.5 Protection against Message Replay, Delay and Redirection
1.5.1 Authoritative SNMP Engine 1.5.1 Authoritative SNMP Engine
In order to protect against message replay, delay and redirection, In order to protect against message replay, delay and redirection,
one of the SNMP engines involved in each communication is designated one of the SNMP engines involved in each communication is designated
to be the authoritative engine. For messages with a GET, GETNEXT, to be the authoritative engine. For messages with a GET, GETNEXT,
GETBULK, SET or INFORM request as the payload, the receiver of such GETBULK, SET or INFORM request as the payload, the receiver of such
messages is authoritative. For messages with a SNMPv2-TRAP, messages is authoritative. For messages with a SNMPv2-TRAP,
RESPONSE or REPORT as the payload, the sender is authoritative. RESPONSE or REPORT as the payload, the sender is authoritative.
1.5.2 The following mechanisms are used: 1.5.2 The following mechanisms are used:
skipping to change at page 10, line ? skipping to change at page 10, line ?
a received message is at least as recent as the last message it a received message is at least as recent as the last message it
received from the same source. A non-authoritative SNMPv3 engine received from the same source. A non-authoritative SNMPv3 engine
uses received authentic messages to advance its notion of time at uses received authentic messages to advance its notion of time at
the remote authoritative source. An SNMPv3 engine also evaluates the remote authoritative source. An SNMPv3 engine also evaluates
the request-id in received Response messages and discards messages the request-id in received Response messages and discards messages
which do not correspond to outstanding requests. which do not correspond to outstanding requests.
These mechanisms provide for the detection of messages whose time These mechanisms provide for the detection of messages whose time
of generation was not recent in all but one circumstance; this of generation was not recent in all but one circumstance; this
circumstance is the delay or replay of a Report message (sent to a circumstance is the delay or replay of a Report message (sent to a
Blumenthal/Wijnen Expires December 1997 [Page 7]
receiver) when the receiver has has not recently communicated with receiver) when the receiver has has not recently communicated with
the source of the Report message. In this circumstance, the the source of the Report message. In this circumstance, the
detection guarantees only that the Report message is more recent detection guarantees only that the Report message is more recent
than the last communication between source and destination of the than the last communication between source and destination of the
Report message. However, Report messages do not request or contain Report message. However, Report messages do not request or contain
management information, and thus, goal #3 in Section 1.2 above is management information, and thus, goal #3 in Section 1.2 above is
met; further, Report messages can at most cause the receiver to met; further, Report messages can at most cause the receiver to
advance its notion of time (at the source) by less than the proper advance its notion of time (at the source) by less than the proper
amount. amount.
Blumenthal/Wijnen Expires November 1997 [Page 7]
This protection against the threat of message delay or replay does This protection against the threat of message delay or replay does
not imply nor provide any protection against unauthorized deletion not imply nor provide any protection against unauthorized deletion
or suppression of messages. Also, an SNMPv3 engine may not be able or suppression of messages. Also, an SNMPv3 engine may not be able
to detect message reordering if all the messages involved are sent to detect message reordering if all the messages involved are sent
within the Time Window interval. Other mechanisms defined within the Time Window interval. Other mechanisms defined
independently of the security protocol can also be used to detect independently of the security protocol can also be used to detect
the re-ordering replay, deletion, or suppression of messages the re-ordering replay, deletion, or suppression of messages
containing set operations (e.g., the MIB variable snmpSetSerialNo containing set operations (e.g., the MIB variable snmpSetSerialNo
[RFC1907]). [RFC1907]).
skipping to change at page 10, line ? skipping to change at page 10, line ?
Report PDUs) without recent time indicators are not considered Report PDUs) without recent time indicators are not considered
authentic. In addition, messages containing Response PDUs have a authentic. In addition, messages containing Response PDUs have a
request-id; if the request-id does not match that of a recently request-id; if the request-id does not match that of a recently
generated request, then the message is not considered to be generated request, then the message is not considered to be
authentic. authentic.
A Report message sent by an SNMPv3 engine can potentially be A Report message sent by an SNMPv3 engine can potentially be
replayed at a later time to an SNMPv3 engine which has not replayed at a later time to an SNMPv3 engine which has not
recently communicated with that source engine. However, Report recently communicated with that source engine. However, Report
messages do not request or contain management information, and messages do not request or contain management information, and
Blumenthal/Wijnen Expires December 1997 [Page 8]
thus, goal #3 in Section 1.2 above is met; further, Report thus, goal #3 in Section 1.2 above is met; further, Report
messages can at most cause the receiver to advance its notion of messages can at most cause the receiver to advance its notion of
time (at the authoritative source) by less than the correct amount. time (at the authoritative source) by less than the correct
amount.
This memo allows the same user to be defined on multiple SNMPv3 This memo allows the same user to be defined on multiple SNMPv3
engines. Each SNMPv3 engine maintains a value, snmpEngineID, engines. Each SNMPv3 engine maintains a value, snmpEngineID,
which uniquely identifies the engine. This value is included in each which uniquely identifies the engine. This value is included in
message sent to/from the engine that is authoritative (see section each message sent to/from the engine that is authoritative (see
1.5.1). On receipt of a message, an authoritative engine checks the section 1.5.1). On receipt of a message, an authoritative engine
value to ensure it is the intended recipient, and a non-authoritative checks the value to ensure it is the intended recipient, and a
engine uses the value to ensure that the message is processed non-authoritative engine uses the value to ensure that the message
is processed using the correct state information.
Blumenthal/Wijnen Expires November 1997 [Page 8]
using the correct state information.
Each SNMPv3 engine maintains two values, engineBoots and engineTime, Each SNMPv3 engine maintains two values, engineBoots and engineTime,
which taken together provide an indication of time at that engine. which taken together provide an indication of time at that engine.
Both of these values are included in an authenticated message sent Both of these values are included in an authenticated message sent
to/received from that engine. On receipt, the values are checked to to/received from that engine. On receipt, the values are checked to
ensure that the indicated time is within a time window of the ensure that the indicated time is within a time window of the
current time. The time window represents an administrative upper current time. The time window represents an administrative upper
bound on acceptable delivery delay for protocol messages. bound on acceptable delivery delay for protocol messages.
For an SNMPv3 engine to generate a message which an authoritative For an SNMPv3 engine to generate a message which an authoritative
engine will accept as authentic, and to verify that a message engine will accept as authentic, and to verify that a message
received from that authoritative engine is authentic, such an engine received from that authoritative engine is authentic, such an engine
must first achieve time synchronization with the authoritative must first achieve time synchronization with the authoritative
engine. engine.
Blumenthal/Wijnen Expires November 1997 [Page 9] Blumenthal/Wijnen Expires December 1997 [Page 9]
2. Elements of the Model 2. Elements of the Model
This section contains definitions required to realize the security This section contains definitions required to realize the security
model defined by this memo. model defined by this memo.
2.1. SNMPv3 Users 2.1. SNMPv3 Users
Management operations using this security model make use of a defined Management operations using this security model make use of a defined
set of user identities. For any SNMPv3 user on whose behalf set of user identities. For any SNMPv3 user on whose behalf
management operations are authorized at a particular SNMPv3 engine, management operations are authorized at a particular SNMPv3 engine,
that engine must have knowledge of that user. An SNMPv3 engine that that engine must have knowledge of that user. An SNMPv3 engine that
wishes to communicate with another SNMPv3 engine must also have wishes to communicate with another SNMPv3 engine must also have
knowledge of a user known to that engine, including knowledge of the knowledge of a user known to that engine, including knowledge of the
applicable attributes of that user. applicable attributes of that user.
A user and its attributes are defined as follows: A user and its attributes are defined as follows:
<userName> <userName>
An octet string representing the name of the user. A string representing the name of the user.
<miId>
A human-readable string representing a (security) model
independent identity for this user.
<groupName> <groupName>
An octet string representing the group that the user belongs to. A string representing the group that the user belongs to.
<authProtocol> <authProtocol>
An indication of whether messages sent on behalf of this user can An indication of whether messages sent on behalf of this user can
be authenticated, and if so, the type of authentication protocol be authenticated, and if so, the type of authentication protocol
which is used. One such protocol is defined in this memo: the which is used. One such protocol is defined in this memo: the
Digest Authentication Protocol. Digest Authentication Protocol.
<authKey>
If messages sent on behalf of this user can be authenticated, the
(private) authentication key for use with the authentication
protocol. Note that a user's authentication key will normally be
different at different authoritative engines. Not visible via
remote access.
<authKeyChange>
The only way to remotely update the authentication key. Does that
in a secure manner, so that the update can be completed without
the need to employ privacy protection.
<privProtocol> <privProtocol>
An indication of whether messages sent on behalf of this user can An indication of whether messages sent on behalf of this user can
be protected from disclosure, and if so, the type of privacy be protected from disclosure, and if so, the type of privacy
protocol which is used. One such protocol is defined in this memo: protocol which is used. One such protocol is defined in this memo:
the Symmetric Encryption Protocol. the DES-based Encryption Protocol.
<privKey>
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 at different
authoritative engines. Not visible via remote access.
<privKeyChange>
The only way to remotely update the encryption key. Does that
in a secure manner, so that the update can be completed without
the need to employ privacy protection.
2.2. Replay Protection 2.2. Replay Protection
Each SNMPv3 engine maintains three objects: Each SNMPv3 engine maintains three objects:
- snmpEngineID, which is an identifier unique among all SNMPv3 - snmpEngineID, which is an identifier unique among all SNMPv3
engines in (at least) an administrative domain; engines in (at least) an administrative domain;
- engineBoots, which is a count of the number of times the engine has - engineBoots, which is a count of the number of times the engine has
re-booted/re-initialized since snmpEngineID was last configured; re-booted/re-initialized since snmpEngineID was last configured;
skipping to change at page 11, line 18 skipping to change at page 11, line 46
its snmpEngineID and engineBoots in non-volatile storage. its snmpEngineID and engineBoots in non-volatile storage.
2.2.1. snmpEngineID 2.2.1. snmpEngineID
The engineID value contained in an authenticated message is used to The engineID value contained in an authenticated message is used to
defeat attacks in which messages from one engine to another engine defeat attacks in which messages from one engine to another engine
are replayed to a different engine. are replayed to a different engine.
When an authoritative engine is first installed, it sets its local When an authoritative engine is first installed, it sets its local
value of snmpEngineID according to a enterprise-specific algorithm value of snmpEngineID according to a enterprise-specific algorithm
(see the definition of engineID in the SNMPng Architectural model (see the definition of engineID in the SNMP Architecture document
document [SNMPng-ARCH]). [SNMP-ARCH]).
2.2.2. engineBoots and engineTime 2.2.2. engineBoots and engineTime
The engineBoots and engineTime values contained in an authenticated The engineBoots and engineTime values contained in an authenticated
message are used to defeat attacks in which messages are replayed message are used to defeat attacks in which messages are replayed
when they are no longer valid. Through use of engineBoots and when they are no longer valid. Through use of engineBoots and
engineTime, there is no requirement for an SNMPv3 engine to have a engineTime, there is no requirement for an SNMPv3 engine to have a
non-volatile clock which ticks (i.e., increases with the passage of non-volatile clock which ticks (i.e., increases with the passage of
time) even when the engine is powered off. Rather, each time an time) even when the engine is powered off. Rather, each time an
SNMPv3 engine re-boots, it retrieves, increments, and then stores SNMPv3 engine re-boots, it retrieves, increments, and then stores
skipping to change at page 11, line 42 skipping to change at page 12, line 19
When an SNMPv3 engine is first installed, it sets its local values When an SNMPv3 engine is first installed, it sets its local values
of engineBoots and engineTime to zero. If engineTime ever of engineBoots and engineTime to zero. If engineTime ever
reaches its maximum value (2147483647), then engineBoots is reaches its maximum value (2147483647), then engineBoots is
incremented as if the engine has re-booted and engineTime is reset to incremented as if the engine has re-booted and engineTime is reset to
zero and starts incrementing again. zero and starts incrementing again.
Each time an authoritative SNMPv3 engine re-boots, any SNMPv3 engines Each time an authoritative SNMPv3 engine re-boots, any SNMPv3 engines
holding that authoritative engine's values of engineBoots and holding that authoritative engine's values of engineBoots and
engineTime need to re-synchronize prior to sending correctly engineTime need to re-synchronize prior to sending correctly
authenticated messages to that authoritative engine (see Section authenticated messages to that authoritative engine (see Section
2.4 for (re-)synchronization procedures). Note, however, that the 2.3 for (re-)synchronization procedures). Note, however, that the
procedures do provide for a notification to be accepted as authentic procedures do provide for a notification to be accepted as authentic
by a receiving engine, when sent by an authoritative engine which has by a receiving engine, when sent by an authoritative engine which has
re-booted since the receiving engine last (re-)synchronized. re-booted since the receiving engine last (re-)synchronized.
If an authoritative SNMPv3 engine is ever unable to determine its If an authoritative SNMPv3 engine is ever unable to determine its
latest engineBoots value, then it must set its engineBoots value to latest engineBoots value, then it must set its engineBoots value to
0xffffffff. 0xffffffff.
Whenever the local value of engineBoots has the value 0xffffffff, it Whenever the local value of engineBoots has the value 0xffffffff, it
latches at that value and an authenticated message always causes an latches at that value and an authenticated message always causes an
usecStatsNotInTimeWindows authentication failure. notInTimeWindow authentication failure.
In order to reset an engine whose engineBoots value has reached the In order to reset an engine whose engineBoots value has reached the
value 0xffffffff, manual intervention is required. The engine must value 0xffffffff, manual intervention is required. The engine must
be physically visited and re-configured, either with a new be physically visited and re-configured, either with a new
snmpEngineID value, or with new secret values for the authentication snmpEngineID value, or with new secret values for the authentication
and privacy protocols of all users known to that engine. and privacy protocols of all users known to that engine.
2.2.3. Time Window 2.2.3. Time Window
The Time Window is a value that specifies the window of time in which The Time Window is a value that specifies the window of time in which
a message generated on behalf of any user is valid. This memo a message generated on behalf of any user is valid. This memo
specifies that the same value of the Time Window, 150 seconds, is specifies that the same value of the Time Window, 150 seconds, is
used for all users. used for all users.
2.3. Error Reporting 2.3. Time Synchronization
While processing a received communication, an SNMPv3 engine may
determine that the message is unacceptable (see Section 3). In
this case, the appropriate counter from the snmpGroup [RFC1907] or
usecStatsGroup object groups is incremented and an error indication
is returned to the calling module.
If an SNMPv3 engine acting in the authoritative role makes such a
determination and the reportableFlag indicates that a report may be
generated, then after incrementing the appropriate counter, it is
required to generate a message containing a report PDU, with the
same userName as in the received message, and to send it to the
transport address which originated the received message. For all
report PDUs, except those generated due to incrementing the
usecStatsNotInTimeWindows counter, the report PDU is unauthenticated.
For those generated due to incrementing usecStatsNotInTimeWindows,
the report PDU is authenticated only if the received message was
authenticated.
The reportableFlag in a message may only be set if the message
contains a Get, GetNext, GetBulk, Set, Inform operation. The
reportableFlag should never be set for a message that contains a
Response, SNMPv2-Trap or Report operation.
2.4. Time Synchronization
Time synchronization, required by a non-authoritative engine (see Time synchronization, required by a non-authoritative engine (see
section 5.1.1) in order to proceed with authentic communications, section 5.1.1) in order to proceed with authentic communications,
has occurred when the non-authoritative engine has obtained local has occurred when the non-authoritative engine has obtained local
values of engineBoots and engineTime from the authoritative engine values of engineBoots and engineTime from the authoritative engine
that are within the authoritative engine's time window. To remain that are within the authoritative engine's time window. To remain
synchronized, the local values must remain within the authoritative synchronized, the local values must remain within the authoritative
engine's time window and thus must be kept loosely synchronized engine's time window and thus must be kept loosely synchronized
with the values stored at the authoritative engine. with the values stored at the authoritative engine.
In addition to keeping a local version of engineBoots and engineTime, In addition to keeping a local version of engineBoots and engineTime,
a non-authoritative engine must also keep one other local variable, a non-authoritative engine must also keep one other local variable,
latestReceivedEngineTime. This value records the highest value of latestReceivedEngineTime. This value records the highest value of
engineTime that was received by the non-authoritative engine from engineTime that was received by the non-authoritative engine from
the authoritative engine and is used to eliminate the possibility the authoritative engine and is used to eliminate the possibility
of replaying messages that would prevent the non-authoritative of replaying messages that would prevent the non-authoritative
engine's notion of the engineTime from advancing. engine's notion of the engineTime from advancing.
Time synchronization occurs as part of the procedures of receiving a Time synchronization occurs as part of the procedures of receiving
message (Section 3.2, step 7b). As such, no explicit time a message (Section 3.2, step 7b). As such, no explicit time
synchronization procedure is required by a non-authoritative engine. synchronization procedure is required by a non-authoritative engine.
Note, that whenever the local value of snmpEngineID is changed (e.g., Note, that whenever the local value of snmpEngineID is changed
through discovery) or when a new secret is configured, the local (e.g., through discovery) or when secure communications are first
values of engineBoots and latestReceivedEngineTime should be set to established with this engine, the local values of engineBoots and
zero. This will cause the time synchronization to occur when the latestReceivedEngineTime should be set to zero. This will cause
next authentic message is received. the time synchronization to occur when the next authentic message
is received.
2.5. SNMPv3 Messages Using this Model 2.4. SNMPv3 Messages Using this Model
The syntax of an SNMPv3 message using this security model adheres The syntax of an SNMPv3 message using this security model adheres
to the message format defined in the SNMPng Architectural model to the message format defined in the SNMP Architecture document
document [SNMPng-ARCH]. The securityParameters in the message are [SNMP-ARCH]. The securityParameters in the message are
defined as an OCTET STRING. The format of that OCTET STRING for defined as an OCTET STRING. The format of that OCTET STRING for
the User-based Security model is as follows: the User-based Security model is as follows:
securityParameters ::= securityParameters ::=
SEQUENCE { SEQUENCE {
-- global parameters -- global parameters
engineID engineID
OCTET STRING (SIZE(12)), OCTET STRING (SIZE(12)),
engineBoots engineBoots
Unsigned32 (0..4294967295), Unsigned32 (0..4294967295),
skipping to change at page 13, line 52 skipping to change at page 14, line 5
END END
The authParameters are defined by the authentication protocol in The authParameters are defined by the authentication protocol in
use for the message (as defined by the authProtocol column in use for the message (as defined by the authProtocol column in
the user's entry in the usecUserTable). the user's entry in the usecUserTable).
The privParameters are defined by the privacy protocol in The privParameters are defined by the privacy protocol in
use for the message (as defined by the privProtocol column in use for the message (as defined by the privProtocol column in
the user's entry in the usecUserTable). the user's entry in the usecUserTable).
2.6 Input and Output of the User-based Security Module 2.5 Input and Output of the User-based Security Module
This section describes the inputs and outputs that the User-based This section describes the inputs and outputs that the User-based
Security module expects and produces when the Message Processing Security module expects and produces when the Message Processing
and Control module (MPC) invokes the User-base Security module for and Control module (MPC) invokes the User-base Security module for
services. services.
2.6.1 Input and Output when generating an SNMPv3 Message 2.5.1 Input and Output when generating an SNMPv3 Message
When the Message Processing and Control module (MPC) invokes the When the Message Processing and Control module (MPC) invokes the
User-based Security module to secure an outgoing SNMPv3 message, User-based Security module to secure an outgoing SNMPv3 message,
it must pass as arguments: there are two possibilities:
<globalData> a) A new request is generated. The abstract service interface is:
this is the global data in the message. The important piece of
information is the Level of Security (LoS) from which the
User-based Security module determines if the message needs to be
protected from disclosure and if the message needs to be
authenticated.
<scopedPDU> generateRequestMsg(version, msgID, mms, msgFlags,
securityModel, securityParameters,
LoS, miId, engineID, scopedPDU)
b) A response is generated. The abtract service interface is:
generateResponseMsg(version, msgID, mms, msgFlags,
securityModel, securityParameters,
scopedPDU, cachedSecurityDataReference)
Where:
version
This is the version number for the SNMP message.
This data is not used by the USEC module.
It is part of the globalData of the message.
msgID
This is the msgID to be generated.
This data is not used by the USEC module.
It is part of the globalData of the message.
mms
This is the maximum message size.
This data is not used by the USEC module.
It is part of the globalData of the message.
msgFlags
This is the field containing the msgFlags.
This data is not used by the USEC module.
It is part of the globalData of the message.
It should be consistent with the LoS that is passed.
securityModel
This is the securityModel in use. Should be the USEC model.
This data is not used by the USEC module.
It is part of the globalData of the message.
securityParameters
These are the security parameters. They will be filled in
by the User-based Security module.
LoS
The Level of Security (LoS) from which the User-based Security
module determines if the message needs to be protected from
disclosure and if the message needs to be authenticated.
scopedPDU
this is the message payload. The data is opaque as far as the this is the message payload. The data is opaque as far as the
User-based Security module is concerned. User-based Security module is concerned.
miId
this is the (security) model independent Identifier.
Together with the engineID it identifies a row in the
usecUserTable that is to be used for securing the message.
engineID
the engineID of the authoritative SNMP engine to which the
request is to be sent.
cachedSecurityDataReference
A handle/reference to cached security data to be used when
securing an outgoing response. This is the handle/reference
that was generated by the USEC module when the incoming
request was processed.
<securityCookie> Upon completion of the process, the User-based Security module
this is an implementation specific handle that identifies an returns either and error indication or the completed message
entry in the usecUserTable. with privacy and authentication applied if such was requested
by the Level of Security (LoS) flags passed.
<cachedSecurityData> The abstract service interface is:
cached security data to be used when securing an outgoing
response. If no cachedSecurityData exists, then the
securityCookie is used.
It is important that a response uses the same auth and priv returnGeneratedMsg(wholeMsg, wholeMsgLen, statusCode)
protocols and secrets as the incoming request. The security
module is not supposed to look at the PDU-type.
So it seems we need to cache the protocols and secrets either as
part of the securityCookie or it needs to be cached as info that
is attached to the msgID. We think we prefer the latter, because
the MPC also needs to cache certain info (like msgID, origin
addressing info) about a message that may result in a response.
So it seems we need one more in/output to the MPC. We will use
this cached data in the remainder of the text, assuming that
for now this is the best way to do it.
Upon completion of the process, the User-based Security module will Where:
return either and error indication or the completed message with wholeMsg
privacy and authentication applied if such was requested by the this is fully encoded and secured message ready to be sent on
Level of Security (LoS) flags passed as part of the <globalData>. the wire.
wholeMsgLen
this is the length of the encoded and secured message wholeMsg.
statusCode
this is the indicator of whether the encoding and securing of
the message was successful, and if not it is an indication of
the problem.
2.6.1 Input and Output when receiving an SNMPv3 Message 2.5.2 Input and Output when receiving an SNMPv3 Message
When the Message Processing and Control module (MPC) invokes the
User-based Security module to verify proper security of an incoming
SNMPv3 message, it must pass as arguments:
<globalData> The Message Processing and Control module (MPC) invokes the
this is the global data in the message. The important piece of User-based Security module to verify proper security of an incoming
information is the Level of Security (LoS) from which the SNMPv3 message. The abstract service interface is:
User-based Security module determines if the message has been
protected from disclosure and if the message has to be checked
for authentication. Another piece of information used by the
User-based Security module is the Maximum Message Size (MMS) in
order to calculate the MMS that a scopedPDU can use in a
potential response.
<securityParameters> processMsg(version, msgID, mms, msgFlags,
this is the octet string that contains the User-based Security securityModel, securityParameters,
model specific security parameters. See section 2.5 for details. LoS, wholeMsg, wholeMsgLen)
Where:
<wholeMessage> version
This is the version number for the SNMP message.
This data is not used by the USEC module.
It is part of the globalData of the message.
msgID
This is the msgID to be generated.
This data is not used by the USEC module.
It is part of the globalData of the message.
mms
This is the maximum message size.
This data is not used by the USEC module.
It is part of the globalData of the message.
msgFlags
This is the field containing the msgFlags.
This data is not used by the USEC module.
It is part of the globalData of the message.
It should be consistent with the LoS that is passed.
securityModel
This is the securityModel in use. Should be the USEC model.
This data is not used by the USEC module.
It is part of the globalData of the message.
securityParameters
These are the security parameters. They will be filled in
by the User-based Security module.
LoS
The Level of Security (LoS) from which the User-based Security
module determines if the message needs to be protected from
disclosure and if the message needs to be authenticated.
wholeMsg
this is the complete message as it was received by the Message this is the complete message as it was received by the Message
Processing and Control module (MPC). In the case of Processing and Control module (MPC).
authentication, a digest needs to be calculated over the complete wholeMsgLen
message. this is the length of the wholeMsg as received on the wire.
Upon completion of the process, the User-based Security module will Upon completion of the process, the User-based Security module
return either and error indication or these pieces of returns a statusCode and in case of success authenticated and
information/data: decrypted data. The abstract service interface is:
<scopedPDU-MMS> returnMsg(miId, groupName, cachedSecurityDataReference,
scopedPDUmms, scopedPDU, statusCode)
Where:
miId
this is an Security Model-independent Identifier that identifies
an entry in the usecUserTable. It is to be used later when a
response message must be secured.
groupName
this is the group to which the user belongs. The User-based
Security module retrieves this information from the usecUserTable.
cachedSecurityDataReference
cached security data to be used when securing a possible outgoing
response to this request. Will have to be released explicitly
by the MPC or the application.
scopedPDUmms
this is the maximum message size that a possible response PDU this is the maximum message size that a possible response PDU
may use. The User-based Security module calculates this size such may use. The User-based Security module calculates this size such
that there is always space available for any security parameters that there is always space available for any security parameters
that need to be added to the response message. that need to be added to the response message.
scopedPDU
<groupName>
this is the group to which the user belongs. The User-base
Security module retrieves this information from the usecUserTable.
<securityCookie>
this is an implementation specific handle that identifies an
entry in the usecUserTable. It is to be used later when a response
message must be secured.
<cachedSecurityData>
cached security data to be used when securing a possible outgoing
response to this request.
<scopedPDU>
this is the message payload. The data is opaque as far as the this is the message payload. The data is opaque as far as the
User-based Security module is concerned. But if the data was User-based Security module is concerned. But if the data was
encrypted because privacy protection was in effect, then upon encrypted because privacy protection was in effect, then upon
return from the User-based Security module the data will have return from the User-based Security module the data will have
been decrypted. been decrypted.
statusCode
this is an indicator of whether the message was parsed,
authenticated and possibly decrypted successfully. If
it was not - it indicates what the problem was.
3. Elements of Procedure 3. Elements of Procedure
This section describes the security related procedures followed by This section describes the security related procedures followed by
an SNMPv3 engine when processing SNMPv3 messages according to the an SNMPv3 engine when processing SNMPv3 messages according to the
User-based Security model. User-based Security model.
3.1. Processing an Outgoing Message 3.1. Processing an Outgoing Message
This section describes the procedure followed by an SNMPv3 engine This section describes the procedure followed by an SNMPv3 engine
whenever it generates a message containing a management operation whenever it generates a message containing a management operation
(either a request, a response, a notification, or a report) on (either a request, a response, a notification, or a report) on
behalf of a user, with a particular Level of Security (LoS). behalf of a user, with a particular Level of Security (LoS).
1) - If any cachedSecurityData exists for this message, then 1) - If any cachedSecurityDataReference is passed, then
information concerning the user is extracted from the information concerning the user is extracted from the
cachedSecurityData. cachedSecurityData. The cachedSecurityData can now be
- Otherwise, based on the information in the securityCookie, discarded.
information concerning the user at the destination engineID - Otherwise, based on the miId, information concerning the user
is extracted from the Security Configuration Datastore at the destination engineID is extracted from the Local
(SCD, usecUserTable). (security) Configuration Datastore (LCD, usecUserTable).
If information about the user is absent from the LCD,
then an error indication (unknownSecurityIdentity) is
returned to the calling module.
2) If the Level of Security (LoS) specifies that the message is to 2) If the Level of Security (LoS) specifies that the message is to
be protected from disclosure, but the user does not support both be protected from disclosure, but the user does not support both
an authentication and a privacy protocol then the message cannot an authentication and a privacy protocol then the message cannot
be sent. An error indication is returned to the calling module. be sent. An error indication (unsupportedLoS) is returned to
the calling module.
3) If the Level of Security (LoS) specifies that the message is to 3) If the Level of Security (LoS) specifies that the message is to
be authenticated, but the user does not support an authentication be authenticated, but the user does not support an authentication
protocol, then the message cannot be sent. An error indication protocol, then the message cannot be sent. An error indication
is returned to the calling module. (unsupportedLoS) is returned to the calling module.
4) If the Level of Security (LoS) specifies that the message is to 4) If the Level of Security (LoS) specifies that the message is to
be protected from disclosure, then the octet sequence be protected from disclosure, then the octet sequence
representing the serialized scopedPDU is encrypted according to representing the serialized scopedPDU is encrypted according to
the user's privacy protocol. To do so a call is made to the the user's privacy protocol. To do so a call is made to the
privacy module that implements the user's privacy protocol. privacy module that implements the user's privacy protocol.
Input passed to the privacy module is: The abstract service interface is:
<engineID> encryptMsg(cryptKey, scopedPDU)
the engineID of the authoritative SNMPv3 engine as it will be
included in the message.
<userName>
the user on whose behalf the message is to be encrypted.
<engineTime>
the engineTime value as it will be included in the message.
This has been added as an additional input so that the
privacy protocol can use it if it so wishes/needs. Turns
out that this value is a good value for the IV for DES.
<cachedSecurityData>
the possible cached security data if this is a response to an
earlier request message.
<scopedPDU>
the data to be encrypted.
Upon completion the privacy module must return either an error Where:
indication or:
<encryptedPDU> cryptKey
the encrypted scopedPDU (encoded as an octet string). The user's usecUserPrivKey. This is the secret key
<privParameters> that can be used by the encryption algorithm.
The privacy parameters (encoded as an octet string) that need scopedPDU
to be sent in the outgoing message. The data to be encrypted.
If an error indication is returned by the privacy module then the Upon completion the privacy module returns:
message cannot be sent and an error indication is returned to the
calling module. returnEncryptedMsg(encryptedPDU, privParameters, statusCode)
If the privacy module returns success, then the <privParameters>
field is put into the securityParameters and the <encryptedPDU> encryptedPDU
The encrypted scopedPDU (encoded as an octet string).
privParameters
The privacy parameters (encoded as an octet string) that
need to be sent in the outgoing message.
statusCode
The indicator of whether the PDU was encrypted successfully
and if not, it indicates what went wrong.
If an error indication is returned by the privacy module then
the message cannot be sent and the error indication is returned
to the calling module.
If the privacy module returns success, then the privParameters
field is put into the securityParameters and the encryptedPDU
serves as the payload of the message being prepared. serves as the payload of the message being prepared.
5) If the Level of Security (LoS) specifies that the message is not 5) If the Level of Security (LoS) specifies that the message is not
to be protected from disclosure, then the NULL string is encoded to be protected from disclosure, then the NULL string is encoded
as an octet string into the <privParameters> field of the as an octet string into the privParameters field of the
securityParameters and the scopedPDU serves as the payload of securityParameters and the scopedPDU serves as the payload of
the message being prepared. the message being prepared.
6) The engineID is encoded as an octet string into the <engineID> 6) The engineID is encoded as an octet string into the <engineID>
field of the securityParameters. field of the securityParameters.
7) If the Level of Security (LoS) specifies that the message is to 7) If the Level of Security (LoS) specifies that the message is to
be authenticated, then the current values of engineBoots, and be authenticated, then the current values of engineBoots, and
engineTime corresponding to engineID from the SCD are used. engineTime corresponding to engineID from the LCD are used.
Otherwise, a zero value is used for engineBoots and engineTime. Otherwise, a zero value is used for engineBoots and engineTime.
The values are encoded as Unsigned32 into the <engineBoots> and The values are encoded as Unsigned32 into the engineBoots and
<engineTime> fields of the securityParameters. engineTime fields of the securityParameters.
8) The userName is encoded as an octet string into the <userName> 8) The userName is encoded as an octet string into the userName
field of the securityParameters. field of the securityParameters.
9) If the Level of Security (LoS) specifies that the message is to 9) If the Level of Security (LoS) specifies that the message is to
be authenticated, the message is authenticated according to the be authenticated, the message is authenticated according to the
user's authentication protocol. To do so, a call is made to the user's authentication protocol. To do so, a call is made to the
authentication module that implements the user's authentication authentication module that implements the user's authentication
protocol. Input passed to the authentication module is: protocol. The abstract service interface is:
<engineID> authMsg(authKey, wholeMsg)
the engineID of the authoritative SNMPv3 engine as it will be
included in the message.
<userName>
the user on whose behalf the message is to be authenticated.
<cachedSecurityData> authKey
the possible cached security data if this is a response to an The user's usecUserAuthKey. This is the secret key
earlier request message. that can be used by the authentication algorithm.
<authParameters> wholeMsg
the authParameters, to be filled by the authentication module.
<wholeMessage>
the message to be authenticated. the message to be authenticated.
Output expected from the authentication module is an error Upon completion the authentication module returns:
indication or the completed message.
returnAuthMsg(wholeMsg, statusCode)
wholeMsg
Same as in input, but with authParameters properly filled.
statusCode
The indicator of whether the message was successfully
processed by the authentication module.
If an error indication is returned by the authentication module, If an error indication is returned by the authentication module,
then the message cannot be sent and an error indication is then the message cannot be sent and the error indication is
returned to the calling module. returned to the calling module.
10) If the Level of Security (LoS) specifies that the message is not 10) If the Level of Security (LoS) specifies that the message is not
to be authenticated then the NULL string is encoded as an octet to be authenticated then the NULL string is encoded as an octet
string into the <authParameters> field of the securityParameters. string into the authParameters field of the securityParameters.
11) The completed message is returned to the calling module. 11) The completed message is returned to the calling module with
the statusCode set to success.
3.2. Processing an Incoming Message 3.2. Processing an Incoming Message
This section describes the procedure followed by an SNMPv3 engine This section describes the procedure followed by an SNMPv3 engine
whenever it receives a message containing a management operation whenever it receives a message containing a management operation
on behalf of a user, with a particular Level of Security (LoS). on behalf of a user, with a particular Level of Security (LoS).
1) If the received securityParameters is not the serialization 1) If the received securityParameters is not the serialization
(according to the conventions of [RFC1906]) of an OCTET STRING (according to the conventions of [RFC1906]) of an OCTET STRING
formatted according to the securityParameters defined in section formated according to the securityParameters defined in section
2.5, then the snmpInASNParseErrs counter [RFC1907] is 2.4, then the snmpInASNParseErrs counter [RFC1907] is
incremented, and an error indication is returned to the calling incremented, and an error indication (ASNParseError) is returned
module. to the calling module.
2) The values of the security parameter fields are extracted from 2) The values of the security parameter fields are extracted from
the securityParameters. the securityParameters.
3) If the <engineID> field contained in the securityParameters is 3) If the engineID field contained in the securityParameters is
unknown then: unknown then:
- a manager that performs discovery may optionally create a new - a manager that performs discovery may optionally create a
entry in its Security Configuration Database (SCD) and continue new entry in its Local (security) Configuration Database (LCD)
processing; or and continue processing; or
- the usecStatsUnknownEngineIDs counter is incremented, a report - an error indication (unknownEngineID) is returned to the
PDU is generated, and an error indication is returned to the
calling module. calling module.
4) Information about the value of the <userName> and <engineID> 4) Information about the value of the userName and engineID
fields is extracted from the local Security Configuration fields is extracted from the Local (security) Configuration
Database (SCD, usecUserTable). If no information is available Database (LCD, usecUserTable). If no information is
for this user, then the usecStatsUnknownUserNames counter is available for this user, then an error indication
incremented, a report PDU is generated, and an error indication (unknownSecurityIdentity) is returned to the calling module.
is returned to the calling module.
5) If the information about the user indicates that it does not 5) If the information about the user indicates that it does not
support the Level of Security indicated by the <LoS> field in support the Level of Security indicated by the LoS parameter,
the globalData, then the usecStatsUnsupportedLoS counter is then and an error indication (unsupportedLoS) is returned to
incremented, a report PDU is generated, and an error indication the calling module.
is returned to the calling module.
6) If the Lever of Security (LoS) specifies that the message is to 6) If the Level of Security (LoS) specifies that the message is to
be authenticated, then the message is authenticated according to be authenticated, then the message is authenticated according to
the user's authentication protocol. To do so, a call is made to the user's authentication protocol. To do so, a call is made to
the authentication module that implements the user's the authentication module that implements the user's
authentication protocol. Input passed to the authentication authentication protocol. The abstract service interface is:
module is:
<engineID> authIncomingMsg(authKey, authParameters, wholeMsg)
the engineID of the authoritative SNMPv3 engine as it was
included in the message. authKey
<userName> The user's (secret) usecUserAuthKey
the user on whose behalf the message is to be authenticated. authParameters
<authParameters> the authParameters from the incoming message.
the authParameters. wholeMsg
<wholeMessage>
the message to be authenticated. the message to be authenticated.
The authentication module returns:
returnAuthIncomingMsg(wholeMsg, statusCode)
If the message is not authentic according to the authentication If the message is not authentic according to the authentication
protocol module (i.e. it returns an error indication), then an protocol module (i.e. it returns an error indication), then the
error indication is returned to the calling module. error indication is returned to the calling module.
Otherwise the authentication module must return these pieces of Otherwise, the authenticated wholeMsg is used for further
information/data: processing.
<cachedSecurityData>
the cached security data so that it can be used later when
a response to a request message must be secured.
If we are not supposed to look at the PDU type, then it
seems we must always cache the security data. But that then
makes it problematic as to who gets rid of the cache and
when..... or do we consider that an implementation issue?
7) If the <LoS> field indicates an authenticated message, then 7) If the LoS field indicates an authenticated message, then
the local values of engineBoots and engineTime corresponding to the local values of engineBoots and engineTime corresponding to
the value of the <engineID> field are extracted from the the value of the engineID field are extracted from the
Security Configuration Database (SCD). Local (security) Configuration Database (LCD).
a) If the <engineID> value is the same as the engineID of a) If the engineID value is the same as the snmpEngineID of
the processing SNMPv3 engine (meaning that this is the the processing SNMPv3 engine (meaning that this is the
authoritative engine), then if any of the following authoritative engine), then if any of the following
conditions is true, then the message is considered to be conditions is true, then the message is considered to be
outside of the Time Window: outside of the Time Window:
- the local value of engineBoots is 0xffffffff; - the local value of engineBoots is 0xffffffff;
- the <engineBoots> field differs from the local value of - the engineBoots field differs from the local value of
engineBoots; or, engineBoots; or,
- the value of the <engineTime> field differs from the local - the value of the engineTime field differs from the local
notion of engineTime by more than +/- 150 seconds. notion of engineTime by more than +/- 150 seconds.
If the message is considered to be outside of the Time Window If the message is considered to be outside of the Time Window
then the usecStatsNotInTimeWindows counter is incremented, an then an error indication (notInTimeWindow) is returned to
authenticated report PDU is generated (see section 2.3), and the calling module.
an error indication is returned to the calling module.
b) If the <engineID> value is not the same as the engineID of b) If the engineID value is not the same as the snmpEngineID of
the processing SNMPv3 engine (meaning that this engine is not the processing SNMPv3 engine (meaning that this engine is not
the authoritative engine), then: the authoritative engine), then:
- if all of the following conditions are true: - if at least one of the following conditions is true:
- if the <LoS> field indicates that privacy is not in use;
- the SNMPv2 operation type determined from the ASN.1 tag
value associated with the PDU's component is a Report;
So it turns out we do need to look at the PDU data
Mmmm... this is against our own rules of cohesion and encapsulation
- the Report was generated due to a - the engineBoots field is greater than the local value
usecStatsNotInTimeWindows error condition; and, of engineBoots; or,
- the <engineBoots> field is greater than the local value of - the engineBoots field is equal to the local value of
engineBoots, or the <engineBoots> field is equal to the engineBoots and the engineTime field is greater than
local value of engineBoots and the <engineTime> field is the value of latestReceivedEngineTime,
greater than the value of latestReceivedEngineTime,
then the SCD entry corresponding to the value of the then the LCD entry corresponding to the value of the
<engineID> field is updated, by setting the local value of engineID field is updated, by setting the local value of
engineBoots from the <engineBoots> field, the value engineBoots from the engineBoots field, the local value
latestReceivedEngineTime from the <engineTime> field, and latestReceivedEngineTime from the engineTime field, and
the local value of engineTime from the <engineTime> field. the local value of engineTime from the engineTime field.
- if any of the following conditions is true, then the message - if any of the following conditions is true, then the message
is considered to be outside of the Time Window: is considered to be outside of the Time Window:
- the local value of engineBoots is 0xffffffff; - the local value of engineBoots is 0xffffffff;
- the <engineBoots> field is less than the local value of
- the engineBoots field is less than the local value of
engineBoots; or, engineBoots; or,
- the <engineBoots> field is equal to the local value of - the engineBoots field is equal to the local value of
engineBoots and the <engineTime> field is more than 150 engineBoots and the engineTime field is more than 150
seconds less than the local notion of engineTime. seconds less than the local notion of engineTime.
If the message is considered to be outside of the Time If the message is considered to be outside of the Time
Window then the usecStatsNotInTimeWindows counter is Window then an error indication (notInTimeWindow) is
incremented, and an error indication is returned to the returned to the calling module;
calling module; however, time synchronization procedures however, time synchronization procedures may be invoked.
may be invoked. Note that this procedure allows for engineBoots in the
Note that this procedure allows for <engineBoots> to be message to be greater than the local value of engineBoots
greater than the local value of engineBoots to allow for to allow for received messages to be accepted as authentic
received messages to be accepted as authentic when received when received from an authoritative SNMPv3 engine that
from an authoritative SNMPv3 engine that has re-booted since has re-booted since the receiving SNMPv3 engine last
the receiving SNMPv3 engine last re-synchronized. (re-)synchronized.
- if at least one of the following conditions is true:
- the <engineBoots> field is greater than the local value of
engineBoots; or,
- the <engineBoots> field is equal to the local value of
engineBoots and the <engineTime> field is greater than the
value of latestReceivedEngineTime,
then the SCD entry corresponding to the value of the
<engineID> field is updated, by setting the local value of
engineBoots from the <engineBoots> field, the local value
latestReceivedEngineTime from the <engineTime> field, and
the local value of engineTime from the <engineTime> field.
8) If the <LoS> field indicates that the message was protected from 8) If the LoS field indicates that the message was protected from
disclosure, then the octet sequence representing the <scopedPDU> disclosure, then the octet sequence representing the scopedPDU
is decrypted according to the user's privacy protocol to obtain is decrypted according to the user's privacy protocol to obtain
a serialized scopedPDUs value. Otherwise the data component is a serialized scopedPDUs value. Otherwise the data component is
assumed to directly contain the scopedPDUs value. To do the assumed to directly contain the scopedPDUs value. To do the
decryption, a call is made to the privacy module that implements decryption, a call is made to the privacy module that implements
the user's privacy protocol. Input passed to the privacy module the user's privacy protocol. The abstract service interface is:
is:
<snmpEngineID> decryptMsg(cryptKey, privParameters, encryptedPDU)
the engineID of the authoritative SNMPv3 engine as it was
included in the message. cryptKey
<userName> The user's secret usecUserPrivKey
the user on whose behalf the message is to be decrypted. privParameters
<engineTime> The privParameters field from the securityParameters from
the engineTime value as it was included in the message. the incoming message.
<encryptedPDU> encryptedPDU
the data to be decrypted the data to be decrypted
Output expected from the privacy module is an error code or:
<cachedSecurityData> The privacy module returns:
the cached security data so that it can be used later when
<scopedPDU>
the decrypted scopedPDU.
If an error code is returned by the privacy module, then an error returnDecryptedMsg(scopedPDU, statusCode)
indication is returned to the calling module.
9) The scopedPDU-MMS is calculated. scopedPDU
The decrypted scopedPDU.
statusCode
The indicator whether the message was successfully decrypted.
10) The groupName is retrieved from the usecUserTable. If an error indication is returned by the privacy module, then
the error indication is returned to the calling module.
11) The <securityCookie> is retrieved from the usecUserTable 9) The scopedPDU-MMS is calculated.
12) A return is made to the calling module, passing these values: 10) The groupName is retrieved from the usecUserTable
<scopedPDU-MMS> 11) The miId is retrieved from the usecUserTable
the maximum message size that a possible response may use.
<groupName> 12) The securityData is cached, so that a possible response to
the name of the group that the user, on whose behalf the this message can use the same authentication and privacy
message was sent, belongs to. secrets. Information to be saved/cached is as follows:
<securityCookie> usecUserName,
this is an implementation specific handle that identifies an usecUserAuthProto, usecUserAuthKey,
entry in the usecUserTable. It is to be used later when a usecUserPrivProto, usecUserPrivKey
response message must be secured.
<cachedSecurityData> -- Editor's note:
the cached security data so that it can be used later when If we assume SNMPv3, then we could check the reportableFlag and if
it is not set, then we do not need to cache any security data
because then there is no response possible. Do we want to do that?
-- End Editor's note.
<scopedPDU> 13) The statusCode is set to success and a return is made to the
the scopedPDU (message payload) calling module according to this abstract service interface:
returnMsg(miId, groupName, cachedSecurityDataReference,
scopedPDUmms, scopedPDU, statusCode)
4. Discovery 4. Discovery
This security model requires that a discovery process obtain This security model requires that a discovery process obtains
sufficient information about other SNMPv3 entities in order to sufficient information about other SNMP engines in order to
communicate with them. Discovery requires the SNMPv3 manager to communicate with them. Discovery requires the SNMP manager to
learn the engine's snmpEngineID value before communication may learn the engine's snmpEngineID value before communication may
proceed. This may be accomplished by formulating a get-request proceed. This may be accomplished by formulating a get-request
communication with the LoS set to noAuth/noPriv, the userName set communication with the LoS set to noAuth/noPriv, the userName set
to "public", the snmpEngineID set to all zeros (binary), and the to "public", the snmpEngineID set to all zeros (binary), and the
varBindList left empty. The response to this message will be a varBindList left empty. The response to this message will be a
report PDU that contains the snmpEngineID within the report PDU that contains the snmpEngineID within the
<securityParameters> field (and containing the securityParameters field (and containing the snmpUnknownEngineIDs
usecStatsUnknownEngineIDs counter in the varBindList). counter in the varBindList).
If authenticated communication is required then the If authenticated communication is required then the discovery
discovery process may invoke the procedure described in Section 2.4 process may invoke the procedure described in Section 2.3 to
to synchronize the clocks. synchronize the timers.
5. Definitions 5. Definitions
SNMPv3-USEC-MIB DEFINITIONS ::= BEGIN SNMP-USEC-MIB DEFINITIONS ::= BEGIN
IMPORTS IMPORTS
Counter32, Unsigned32,
MODULE-IDENTITY, OBJECT-TYPE, snmpModules FROM SNMPv2-SMI MODULE-IDENTITY, OBJECT-TYPE, snmpModules FROM SNMPv2-SMI
TEXTUAL-CONVENTION, TestAndIncr, TEXTUAL-CONVENTION, TestAndIncr,
RowStatus, AutonomousType, StorageType, RowStatus, StorageType FROM SNMPv2-TC
TDomain, TAddress FROM SNMPv2-TC
MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF, MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF,
SnmpV3GroupName, SnmpV3ContextName, SnmpAdminString, SnmpLoS, SnmpEngineID,
SnmpV3LoS, SnmpV3EngineID, SnmpSecurityModel,
SnmpV3SecurityModel, SnmpV3SecurityCookie FROM SNMPv3-MIB; imfAuthMD5Protocol, imfNoPrivProtocol FROM IMF-MIB;
Not sure if the above are all in SNMPv3-MIB, need to see
how the complete MPC document will look like.
snmpV3UsecMIB MODULE-IDENTITY snmpUsecMIB MODULE-IDENTITY
LAST-UPDATED "9705090000Z" -- 09 May 1997, midnight LAST-UPDATED "9706180000Z" -- 18 June 1997, midnight
ORGANIZATION "SNMPv3 Working Group" ORGANIZATION "SNMPv3 Working Group"
CONTACT-INFO "WG-email: snmpv3@tis.com CONTACT-INFO "WG-email: snmpv3@tis.com
Subscribe: majordomo@tis.com Subscribe: majordomo@tis.com
In msg body: subscribe snmpv3 In msg body: subscribe snmpv3
Chair: Russ Mundy Chair: Russ Mundy
Trutsed Information Systems Trusted Information Systems
postal: 3060 Washington Rd postal: 3060 Washington Rd
Glenwood MD 21738 Glenwood MD 21738
email: mundy@tis.com email: mundy@tis.com
phone: 301-854-6889 phone: 301-854-6889
Co-editor Uri Blumenthal Co-editor Uri Blumenthal
IBM T. J. Watson Research IBM T. J. Watson Research
postal: 30 Saw Mill River Pkwy, postal: 30 Saw Mill River Pkwy,
Hawthorne, NY 10532 Hawthorne, NY 10532
USA USA
email: uri@watson.ibm.com email: uri@watson.ibm.com
phone: +1.914.784.7964 phone: +1.914.784.7964
Co-editor: Bert Wijnen Co-editor: Bert Wijnen
IBM T. J. Watson Research IBM T. J. Watson Research
postal: Schagen 33 postal: Schagen 33
3461 GL Linschoten 3461 GL Linschoten
Netherlands Netherlands
email: wijnen@vnet.ibm.com email: wijnen@vnet.ibm.com
phone: +31-348-412-498 phone: +31-348-432-794
" "
DESCRIPTION "The management information definitions for the DESCRIPTION "The management information definitions for the
SNMPv3 User-based Security model. SNMPv3 User-based Security model.
" "
::= { snmpModules xx } ::= { snmpModules 99 } -- to be assigned
-- Administrative assignments **************************************** -- Administrative assignments ****************************************
snmpV3UsecAdmin OBJECT IDENTIFIER ::= { snmpV3UsecMIB 1 } snmpUsecAdmin OBJECT IDENTIFIER ::= { snmpUsecMIB 1 }
snmpV3UsecMIBObjects OBJECT IDENTIFIER ::= { snmpV3UsecMIB 2 } snmpUsecMIBObjects OBJECT IDENTIFIER ::= { snmpUsecMIB 2 }
snmpV3UsecMIBConformance OBJECT IDENTIFIER ::= { snmpV3UsecMIB 3 } snmpUsecMIBConformance OBJECT IDENTIFIER ::= { snmpUsecMIB 3 }
usecAuthProtocols OBJECT IDENTIFIER ::= { snmpV3UsecAdmin 1 }
usecNoAuthProtocol OBJECT IDENTIFIER ::= { usecAuthProtocols 1 }
usecMD5AuthProtocol OBJECT IDENTIFIER ::= { usecAuthProtocols 2 }
usecPrivProtocols OBJECT IDENTIFIER ::= { usecAdmin 2 }
usecNoPrivProtocol OBJECT IDENTIFIER ::= { usecPrivProtocols 1 } -- Textual Conventions ***********************************************
usecDESPrivProtocol OBJECT IDENTIFIER ::= { usecPrivProtocols 2 } UserName ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION "A string representing the name of a user for use in
accordance with the SNMP User-based Security model.
"
SYNTAX SnmpAdminString (SIZE(1..16))
-- Editor's note: -- Editor's note:
We picked these up from earlier MIBs. -- A real issue is whether the fact that MD5 is used in the following
It all seems a bit overdone though. If a user has no auth -- TC is OK. It might be better to use 3DES for 3DES and IDEA for IDEA.
or priv protocol, we could just put the NULL OID { 0 0 }
in the usecUserPrivProtocol or usecUserAuthProtocol column.
There also seems no need to split between auth and priv
protocols. How about the following (simpler) scheme:
usecProtocols OBJECT IDENTIFIER ::= { snmpV3UsecAdmin 1 }
-- the Digest Authentication Protocol
usecMD5AuthProtocol OBJECT IDENTIFIER ::= { usecProtocols 1 }
-- the Symmetric Encryption Protocol
usecDESPrivProtocol OBJECT IDENTIFIER ::= { usecProtocols 2 }
-- End Editor's note -- End Editor's note
- <span class="insert">TC is OK. It might be better to use 3DES for 3DES and IDEA for IDEA.</span>
KeyChange ::= TEXTUAL-CONVENTION
snmpEngine OBJECT IDENTIFIER ::= { snmpV3UsecMIBObjects 1 }
snmpEngineID OBJECT-TYPE
SYNTAX SnmpEngineID
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The SNMP engine's administratively-unique identifier."
::= { snmpEngine 1 }
snmpEngineBoots OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The number of times that the engine has re-initialized
itself since its initial configuration.
"
::= { snmpEngine 2 }
snmpEngineTime OBJECT-TYPE
SYNTAX Unsigned32 (0..2147483647)
UNITS "seconds"
MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION "The number of seconds since the engine last DESCRIPTION
incremented the snmpEngineBoots object. "Every definition of an object with this syntax must identify
" a protocol, P, and a secret key, K. The object's value is a
::= { snmpEngine 3 } manager-generated, partially-random value which, when
modified, causes the value of the secret key, K, to be
modified via a one-way function.
usecStats OBJECT IDENTIFIER ::= { snmpV3UsecMIBObjects 2 } The value of an instance of this object is the concatenation
of two components: a 'random' component and a 'delta'
component. The lengths of the random and delta components are
given by the corresponding value of the protocol, P; if P
requires K to be a fixed length, the length of both the random
and delta components is that fixed length; if P allows the
length of K to be variable up to a particular maximum length,
the length of the random component is that maximum length and
the length of the delta component is any length less than or
equal to that maximum length. For example,
imfAuthMD5Protocol requires K to be a fixed length of 16
octets. Other protocols may define other sizes, as deemed
appropriate.
usecStatsUnsupportedLoS OBJECT-TYPE When an instance of this object is modified to have a new
SYNTAX Counter32 value by the management protocol, the agent generates a new
MAX-ACCESS read-only value of K as follows:
STATUS current
DESCRIPTION "The total number of packets received by the SNMPv3
engine which were dropped because they requested a
Level of Security that was unknown to the engine or
otherwise unavailable.
"
::= { usecStats 1 }
usecStatsNotInTimeWindows OBJECT-TYPE - a temporary variable is initialized to the existing value
SYNTAX Counter32 of K;
MAX-ACCESS read-only - if the length of the delta component is greater than 16
STATUS current bytes, then:
DESCRIPTION "The total number of packets received by the SNMPv3 - the random component is appended to the value of the
engine which were dropped because they appeared temporary variable, and the result is input to the MD5
outside of the engine's window. hash algorithm to produce a digest value, and the
" temporary variable is set to this digest value;
::= { usecStats 2 } - the value of the temporary variable is XOR-ed with the
first (next) 16-bytes of the delta component to produce
the first (next) 16-bytes of the new value of K.
- the above two steps are repeated until the unused
portion of the delta component is 16 bytes or less,
- the random component is appended to the value of the
temporary variable, and the result is input to the MD5
hash algorithm to produce a digest value;
- this digest value, truncated if necessary to be the same
length as the unused portion of the delta component, is
XOR-ed with the unused portion of the delta component to
produce the (final portion of the) new value of K.
usecStatsUnknownUserNames OBJECT-TYPE i.e.,
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The total number of packets received by the SNMPv3
engine which were dropped because they referenced a
user that was not known to the engine.
"
::= { usecStats 3 }
usecStatsUnknownEngineIDs OBJECT-TYPE iterations = (lenOfDelta - 1)/16; /* integer division */
SYNTAX Counter32 temp = keyOld;
MAX-ACCESS read-only for (i = 0; i < iterations; i++) {
STATUS current temp = MD5 (temp || random);
DESCRIPTION "The total number of packets received by the SNMPv3 keyNew[i*16 .. (i*16)+15] =
engine which were dropped because they referenced an temp XOR delta[i*16 .. (i*16)+15];
engineID that was not known to the engine. }
" temp = MD5 (temp || random);
::= { usecStats 4 } keyNew[i*16 .. lenOfDelta-1] =
temp XOR delta[i*16 .. lenOfDelta-1];
The value of an object with this syntax, whenever it is
retrieved by the management protocol, is always the zero-
length string."
SYNTAX OCTET STRING
UserName ::= TEXTUAL-CONVENTION -- *******************************************************************
STATUS current
DESCRIPTION "An octet string representing the name of a user for
use in accordance with the SNMPv3 User-based Security
model.
"
SYNTAX OCTET STRING (SIZE(1..16))
-- The valid users for the User-based Security model ****************** -- The valid users for the User-based Security model ******************
usecUser OBJECT IDENTIFIER ::= { snmpV3UsecMIBObjects 3 } usecUser OBJECT IDENTIFIER ::= { snmpUsecMIBObjects 1 }
usecUserTable OBJECT-TYPE usecUserTable OBJECT-TYPE
SYNTAX SEQUENCE OF UsecUserEntry SYNTAX SEQUENCE OF UsecUserEntry
MAX-ACCESS not-accessible MAX-ACCESS not-accessible
STATUS current STATUS current
DESCRIPTION "The table of users configured in the SNMPv3 entity's DESCRIPTION "The table of users configured in the SNMP engine's
security configuration datastore (SCD)." Local (security) Configuration Datastore (LCD)."
::= { usecUser 1 } ::= { usecUser 1 }
usecUserEntry OBJECT-TYPE usecUserEntry OBJECT-TYPE
SYNTAX UsecUserEntry SYNTAX UsecUserEntry
MAX-ACCESS not-accessible MAX-ACCESS not-accessible
STATUS current STATUS current
DESCRIPTION "A user configured in the SNMPv3 entity's security DESCRIPTION "A user configured in the SNMP engine's Local
configuration datastore (SCD) for the User-based (security) Configuration Datastore (LCD) for
Security model. the User-based Security model.
" "
INDEX { usecUserEngineID, INDEX { usecUserEngineID,
IMPLIED usecUserName IMPLIED usecUserName
} }
::= { usecUserTable 1 } ::= { usecUserTable 1 }
UsecUserEntry ::= SEQUENCE { UsecUserEntry ::= SEQUENCE {
usecUserEngineID SnmpEngineID, usecUserEngineID SnmpEngineID,
usecUserName UserName, usecUserName UserName,
usecUserGroupName SnmpV3GroupName, usecUserMiId SnmpAdminString,
usecUserGroupName SnmpAdminString,
usecUserCloneFrom RowPointer,
usecUserAuthProtocol OBJECT IDENTIFIER, usecUserAuthProtocol OBJECT IDENTIFIER,
usecUserAuthKeyChange KeyChange,
-- usecUserAuthKey OCTET STRING, not visible
usecUserAuthPublic OCTET STRING,
usecUserPrivProtocol OBJECT IDENTIFIER, usecUserPrivProtocol OBJECT IDENTIFIER,
usecUserPrivKeyChange KeyChange,
-- usecUserPrivKey OCTET STRING, not visible
usecUserPrivPublic OCTET STRING,
usecUserStorageType StorageType, usecUserStorageType StorageType,
usecUserSecurityCookie SnmpV3SecurityCookie,
usecUserStatus RowStatus usecUserStatus RowStatus
} }
usecUserEngineID OBJECT-TYPE usecUserEngineID OBJECT-TYPE
SYNTAX SnmpEngineID SYNTAX SnmpEngineID
MAX-ACCESS not-accessible MAX-ACCESS not-accessible
STATUS current STATUS current
DESCRIPTION "An SNMPv3 engine's administratively-unique identifier. DESCRIPTION "An SNMP engine's administratively-unique identifier.
In a simple agent, this value is always that agent's In a simple agent, this value is always that agent's
own snmpEngineID value. own snmpEngineID value.
This value can also take the value of the snmpEngineID This value can also take the value of the snmpEngineID
of a remote SNMP engine with which this user can of a remote SNMP engine with which this user can
communicate. communicate.
" "
::= { usecUserEntry 1 } ::= { usecUserEntry 1 }
usecUserName OBJECT-TYPE usecUserName OBJECT-TYPE
SYNTAX UserName SYNTAX UserName
MAX-ACCESS not-accessible MAX-ACCESS not-accessible
STATUS current STATUS current
DESCRIPTION "An octet string representing the name of the user." DESCRIPTION "A string representing the name of the user. This is
the (User-based security) model dependent identity.
"
::= { usecUserEntry 2 } ::= { usecUserEntry 2 }
usecUserMiId OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-only
STATUS current
DESCRIPTION "A string representing the (security) model independent
identity for this user.
The default mapping for the User-based Security model
is that the miId is the same as the userName.
"
::= { usecUserEntry 3 }
usecUserGroupName OBJECT-TYPE usecUserGroupName OBJECT-TYPE
SYNTAX SnmpV3GroupName SYNTAX SnmpAdminString
MAX-ACCESS read-write MAX-ACCESS read-write
STATUS current STATUS current
DESCRIPTION "An octet string representing the group to which the DESCRIPTION "A string representing the group to which the user
user belongs. A group name of zero length indicates belongs. A group name of zero length indicates
that the user is not [perhaps yet] a member of any that the user is not [perhaps yet] a member of any
group, possibly because the entry has not yet been group, possibly because the entry has not yet been
completely configured. Users which are not a part completely configured. Users which are not a part
of any group are effectively disabled to perform any of any group are effectively disabled to perform any
SNMP operations. SNMP operations.
" "
DEFVAL { ''H } -- the empty string DEFVAL { ''H } -- the empty string
::= { usecUserEntry 3 } ::= { usecUserEntry 4 }
usecUserCloneFrom OBJECT-TYPE
SYNTAX RowPointer
MAX-ACCESS read-create
STATUS current
DESCRIPTION "A pointer to another conceptual row in this
usecUserTable. The user in this other conceptual row
is called the clone-from user.
When a new user is created (i.e., a new conceptual row
is instantiated in this table), the authentication
parameters of the new user are cloned from its
clone-from user.
The first time an instance of this object is set by a
management operation (either at or after its
instantiation), the cloning process is invoked.
Subsequent writes are successful but invoke no action
to be taken by the agent.
The cloning process fails with an 'inconsistentName'
error if the conceptual row representing the
clone-from user is not in an active state when the
cloning process is invoked.
Cloning also causes the initial values of the secret
authentication key and the secret encryption key of
the new user to be set to the same value as the
corresponding secret of the clone-from user.
When this object is read, the zero length string is
returned.
"
::= { usecUserEntry 5 }
usecUserAuthProtocol OBJECT-TYPE usecUserAuthProtocol OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER SYNTAX OBJECT IDENTIFIER
MAX-ACCESS read-create MAX-ACCESS read-create
STATUS current STATUS current
DESCRIPTION "An indication of whether messages sent on behalf of DESCRIPTION "An indication of whether messages sent on behalf of
this user to/from the engine identified by this user to/from the SNMP engine identified by
usecUserEngineID, can be authenticated, and if so, usecUserEngineID, can be authenticated, and if so,
the type of authentication protocol which is used. the type of authentication protocol which is used.
An instance of this object is created concurrently An instance of this object is created concurrently
with the creation of any other object instance for with the creation of any other object instance for
the same user (i.e., as part of the processing of the same user (i.e., as part of the processing of
the set operation which creates the first object the set operation which creates the first object
instance in the same conceptual row). Once created, instance in the same conceptual row). Once created,
the value of an instance of this object can not be the value of an instance of this object can not be
changed. changed.
" "
DEFVAL { usecMD5AuthProtocol } DEFVAL { imfAuthMD5Protocol }
::= { usecUserEntry 4 } ::= { usecUserEntry 6 }
usecUserAuthKeyChange OBJECT-TYPE
SYNTAX KeyChange -- typically (SIZE (0..32))
MAX-ACCESS read-create
STATUS current
DESCRIPTION "An object, which when modified, causes the secret
authentication key used for messages sent on behalf
of this user to/from the SNMP engine identified by
usecUserEngineID, to be modified via a one-way
function.
The associated protocol is the usecUserAuthProtocol.
The associated secret key is the user's secret
authentication key (usecUserAuthKey).
When creating a new user, it is an 'inconsistentName'
error for a set operation to refer to this object
unless it is previously or concurrently initialized
through a set operation on the corresponding value
of usecUserCloneFrom.
"
DEFVAL { ''H } -- the empty string
::= { usecUserEntry 7 }
usecUserAuthPublic OBJECT-TYPE
SYNTAX OCTET STRING -- for MD5 (SIZE(0..32))
MAX-ACCESS read-create
STATUS current
DESCRIPTION "A publicly-readable value which is written as part
of the procedure for changing a user's secret key,
and later read to determine whether the change of
the secrets was effected.
"
DEFVAL { ''H } -- the empty string
::= { usecUserEntry 8 }
usecUserPrivProtocol OBJECT-TYPE usecUserPrivProtocol OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER SYNTAX OBJECT IDENTIFIER
MAX-ACCESS read-create MAX-ACCESS read-create
STATUS current STATUS current
DESCRIPTION "An indication of whether messages sent on behalf of DESCRIPTION "An indication of whether messages sent on behalf of
this user to/from the engine identified by this user to/from the SNMP engine identified by
usecUserEngineID, can be protected from disclosure, usecUserEngineID, can be protected from disclosure,
and if so, the type of privacy protocol which is used. and if so, the type of privacy protocol which is used.
An instance of this object is created concurrently An instance of this object is created concurrently
with the creation of any other object instance for with the creation of any other object instance for
the same user (i.e., as part of the processing of the same user (i.e., as part of the processing of
the set operation which creates the first object the set operation which creates the first object
instance in the same conceptual row). Once created, instance in the same conceptual row). Once created,
the value of an instance of this object can not be the value of an instance of this object can not be
changed. changed.
" "
DEFVAL { usecNoPrivProtocol } DEFVAL { imfNoPrivProtocol }
::= { usecUserEntry 5 } ::= { usecUserEntry 9 }
usecUserStorageType OBJECT-TYPE usecUserPrivKeyChange OBJECT-TYPE
SYNTAX StorageType SYNTAX KeyChange -- typically (SIZE (0..32))
MAX-ACCESS read-create MAX-ACCESS read-create
STATUS current STATUS current
DESCRIPTION "The storage type for this conceptual row." DESCRIPTION "An object, which when modified, causes the secret
DEFVAL { nonVolatile } encryption key used for messages sent on behalf
::= { usecUserEntry 7 } of this user to/from the SNMP engine identified by
usecUserEngineID, to be modified via a one-way
function.
usecUserSecurityCookie OBJECT-TYPE The associated protocol is the usecUserPrivProtocol.
SYNTAX SnmpV3SecurityCookie The associated secret key is the user's secret
MAX-ACCESS read-only encryption key (usecUserPrivKey).
When creating a new user, it is an 'inconsistentName'
error for a set operation to refer to this object
unless it is previously or concurrently initialized
through a set operation on the corresponding value
of usecUserCloneFrom.
"
DEFVAL { ''H } -- the empty string
::= { usecUserEntry 10 }
usecUserPrivPublic OBJECT-TYPE
SYNTAX OCTET STRING -- for DES (SIZE(0..16))
MAX-ACCESS read-create
STATUS current STATUS current
DESCRIPTION "An implementation specific handle that identifies DESCRIPTION "A publicly-readable value which is written as part
the User-based Security model and this entry in the of the procedure for changing a user's secret key,
usecUserTable. and later read to determine whether the change of
the secrets was effected.
" "
DEFVAL { ''H } -- the empty string
::= { usecUserEntry 11 }
usecUserStorageType OBJECT-TYPE
SYNTAX StorageType
MAX-ACCESS read-create
STATUS current
DESCRIPTION "The storage type for this conceptual row."
DEFVAL { nonVolatile } DEFVAL { nonVolatile }
::= { usecUserEntry 7 } ::= { usecUserEntry 12 }
usecUserStatus OBJECT-TYPE usecUserStatus OBJECT-TYPE
SYNTAX RowStatus SYNTAX RowStatus
MAX-ACCESS read-create MAX-ACCESS read-create
STATUS current STATUS current
DESCRIPTION "The status of this conceptual row. Until instances DESCRIPTION "The status of this conceptual row. Until instances
of all corresponding columns are appropriately of all corresponding columns are appropriately
configured, the value of the corresponding instance configured, the value of the corresponding instance
of the usecUserStatus column is 'notReady'. of the usecUserStatus column is 'notReady'.
For those columnar objects which permit write-access, For those columnar objects which permit write-access,
their value in an existing conceptual row can be their value in an existing conceptual row can be
changed irrespective of the value of usecUserStatus changed irrespective of the value of usecUserStatus
for that row. for that row.
" "
::= { usecUserEntry 8 } ::= { usecUserEntry 13 }
usecUserSecretSpinLock OBJECT-TYPE
SYNTAX TestAndIncr
MAX-ACCESS read-write
STATUS current
DESCRIPTION "An advisory lock used to allow several cooperating
SNMPv3 engines, all acting in a manager role, to
coordinate their use of facilities to alter secrets
in the usecUserTable.
"
::= { usecUser 2 }
--Editor's note
Is it enough to have just one spin-lock for such a table where
several secrets can be modified? Can the protocol ensure the
consistency? Should it?
--End editor's note
-- Conformance Information ******************************************* -- Conformance Information *******************************************
snmpV3UsecMIBCompliances snmpUsecMIBCompliances
OBJECT IDENTIFIER ::= { snmpV3UsecMIBConformance 1 } OBJECT IDENTIFIER ::= { snmpUsecMIBConformance 1 }
snmpV3UsecMIBGroups snmpUsecMIBGroups
OBJECT IDENTIFIER ::= { snmpV3UsecMIBConformance 2 } OBJECT IDENTIFIER ::= { snmpUsecMIBConformance 2 }
-- Compliance statements -- Compliance statements
snmpV3UsecMIBCompliance MODULE-COMPLIANCE snmpUsecMIBCompliance MODULE-COMPLIANCE
STATUS current STATUS current
DESCRIPTION "The compliance statement for SNMPv3 engines which DESCRIPTION "The compliance statement for SNMP engines which
implement the SNMPv3 USEC MIB. implement the SNMP USEC MIB.
" "
MODULE -- this module MODULE -- this module
MANDATORY-GROUPS { snmpV3UsecMIBBasicGroup } MANDATORY-GROUPS { snmpUsecMIBBasicGroup }
OBJECT usecUserGroupName OBJECT usecUserGroupName
MIN-ACCESS read-only MIN-ACCESS read-only
DESCRIPTION "Write access is not required." DESCRIPTION "Write access is not required."
OBJECT usecUserAuthProtocol OBJECT usecUserAuthProtocol
MIN-ACCESS read-only MIN-ACCESS read-only
DESCRIPTION "Write access is not required." DESCRIPTION "Write access is not required."
OBJECT usecUserPrivProtocol OBJECT usecUserPrivProtocol
MIN-ACCESS read-only MIN-ACCESS read-only
DESCRIPTION "Write access is not required." DESCRIPTION "Write access is not required."
::= { snmpV3UsecMIBCompliances 1 }
::= { snmpUsecMIBCompliances 1 }
-- Units of compliance -- Units of compliance
snmpV3UsecMIBBasicGroup OBJECT-GROUP snmpUsecMIBBasicGroup OBJECT-GROUP
OBJECTS { snmpEngineID, OBJECTS {
snmpEngineBoots, usecUserMiId,
snmpEngineTime,
usecStatsUnsupportedLoS,
usecStatsNotInTimeWindows,
usecStatsUnknownUserNames,
usecStatsUnknownEngineIDs,
usecUserGroupName, usecUserGroupName,
usecUserCloneFrom,
usecUserAuthProtocol, usecUserAuthProtocol,
usecUserAuthKeyChange,
usecUserAuthPublic,
usecUserPrivProtocol, usecUserPrivProtocol,
usecUserSecurityCookie, usecUserPrivKeyChange,
usecUserPrivPublic,
usecUserStorageType, usecUserStorageType,
usecUserStatus usecUserStatus
} }
STATUS current STATUS current
DESCRIPTION "A collection of objects providing for configuration DESCRIPTION "A collection of objects providing for configuration
of an SNMPv3 entity which implements the SNMPv3 of an SNMP engine which implements the SNMP
User-based Security model. User-based Security model.
" "
::= { snmpV3UsecMIBGroups 1 } ::= { snmpUsecMIBGroups 1 }
END END
6. MD5 Authentication Protocol 6. MD5 Authentication Protocol
This section describes the Keyed-MD5 authentication protocol. This section describes the Keyed-MD5 authentication protocol.
This protocol is the first authentication protocol defined for This protocol is the first authentication protocol defined for
the User-based Security model. the User-based Security model.
Over time, other authentication protocols may be defined either Over time, other authentication protocols may be defined either
as a replacement of this protocol or in addition to this protocol. as a replacement of this protocol or in addition to this protocol.
skipping to change at page 34, line 26 skipping to change at page 37, line 26
of a defined set of user identities. For any SNMPv3 user on whose of a defined set of user identities. For any SNMPv3 user on whose
behalf a message must be authenticated at a particular SNMPv3 engine, behalf a message must be authenticated at a particular SNMPv3 engine,
that engine must have knowledge of that user. An SNMPv3 engine that that engine must have knowledge of that user. An SNMPv3 engine that
wishes to communicate with another SNMPv3 engine must also have wishes to communicate with another SNMPv3 engine must also have
knowledge of a user known to that engine, including knowledge of the knowledge of a user known to that engine, including knowledge of the
applicable attributes of that user. applicable attributes of that user.
A user and its attributes are defined as follows: A user and its attributes are defined as follows:
<userName> <userName>
An octet string representing the name of the user. A string representing the name of the user.
<authKey>
<authMD5PrivateKey> A user's secret key to be used when calculating a digest.
If messages sent on behalf of this user can be authenticated, the
(private) authentication key for use with the authentication
protocol. Note that a user's authentication key will normally be
different at different authoritative engines.
6.2.2. EngineID 6.2.2. EngineID
The engineID value contained in an authenticated message specifies The engineID value contained in an authenticated message specifies
the authoritative SNMPv3 engine for that particular message. the authoritative SNMPv3 engine for that particular message.
(see the definition of engineID in the SNMPng Architectural model (see the definition of engineID in the SNMP Architecture document
document [SNMPng-ARCH]). [SNMP-ARCH]).
The user's (private) authentication key is normally different at The user's (private) authentication key is normally different at
each authoritative SNMPv3 engine and so the snmpEngineID is used each authoritative SNMPv3 engine and so the snmpEngineID is used
to select the proper key for the authentication process. to select the proper key for the authentication process.
6.2.3. SNMPv3 Messages Using this Authentication Protocol 6.2.3. SNMPv3 Messages Using this Authentication Protocol
Messages using this authentication protocol carry an authParameters Messages using this authentication protocol carry an authParameters
field as part of the securityParameters. For this protocol, the field as part of the securityParameters. For this protocol, the
authParameters field is the serialized octet string representing authParameters field is the serialized octet string representing
the MD5 digest of the wholeMessage. the MD5 digest of the wholeMsg.
The digest is calculated over the wholeMessage so if a message is The digest is calculated over the wholeMsg so if a message is
authenticated, that also means that all the fields in the message authenticated, that also means that all the fields in the message
are intact and have not been tampered with. are intact and have not been tampered with.
6.2.4 Input and Output of the MD5 Authentication Module 6.2.4 Input and Output of the MD5 Authentication Module
This section describes the inputs and outputs that the MD5 This section describes the inputs and outputs that the MD5
Authentication module expects and produces when the User-based Authentication module expects and produces when the User-based
Security module invokes the MD5 Authentication module for Security module invokes the MD5 Authentication module for
services. services.
6.2.4.1 Input and Output when generating an SNMPv3 Message 6.2.4.1 Input and Output when generating an SNMPv3 Message
When the User-based Security module invokes the MD5 Authentication This MD5 authentication protocol assumes that the selection of the
module to authenticate an outgoing message, it must pass as authKey is done by the caller and that the caller passes
arguments: the secret key to be used. The abstract service interface is:
<engineID> authMsg(authKey, wholeMsg)
the engineID of the authoritative SNMPv3 engine as it will be
included in the message. Where:
<userName>
the user on whose behalf the message is to be authenticated. authKey
<cachedSecurityData> The secret key to be used by the authentication algorithm.
the possible cached security data if this is a response to an wholeMsg
earlier request message.
<authParameters>
the authParameters, to be filled by the authentication module.
<wholeMessage>
the message to be authenticated. the message to be authenticated.
Output from the MD5 Authentication module is an error indication or Upon completion the authentication module returns information.
the completed wholeMessage (that is with the digest inserted into The abstract service interface is:
the authParameters field). If an error indication is returned by
the MD5 Authentication module, then the message cannot be sent. returnAuthMsg(wholeMsg, statusCode)
Where:
wholeMsg
Same as in input, but with authParameters properly filled.
statusCode
The indicator of whether the message was successfully
processed or not.
Note, that <authParameters> is filled by the authentication module
and this field should be already present in the <wholeMsg> before
the MAC is generated.
6.2.4.2 Input and Output when receiving an SNMPv3 Message 6.2.4.2 Input and Output when receiving an SNMPv3 Message
When the User-based Security module invokes the MD5 Authentication This MD5 authentication protocol assumes that the selection of the
module to authenticate an incoming message, it must pass as authKey is done by the caller and that the caller passes
arguments: the secret key to be used. The abstract service interface is:
<engineID> authIncomingMsg(authKey, authParameters, wholeMsg)
the engineID of the authoritative SNMPv3 engine as it was
included in the message. Where:
<userName>
the user on whose behalf the message is to be authenticated. authKey
<authParameters> The secret key to be used by the authentication algorithm.
the authParameters. authParameters
<wholeMessage> the authParameters from the incoming message.
wholeMsg
the message to be authenticated. the message to be authenticated.
Output from the MD5 Authentication module is an error indication or Upon completion the authentication module returns information.
the authentic wholeMessage plus any cachedSecurityData that may be The abstract service interface is:
needed when authenticating a possible outgoing response to this
(request) message.
If an error indication is returned by the MD5 Authentication module, returnAuthIncomingMsg(wholeMsg, statusCode)
then the message cannot be trusted. In the case that there was not
enough information in the Security Configuration Database (SCD) to wholeMsg
actually perform the authentication process, then a report PDU may Same as in input, data has been authenticated.
have been generated to inform the sender about the error condition. statusCode
The indicator of whether the message was successfully
processed or not.
6.3 Elements of Procedure 6.3 Elements of Procedure
This section describes the procedures for the Keyed-MD5 This section describes the procedures for the Keyed-MD5
authentication protocol. authentication protocol.
6.3.1 Processing an Outgoing Message 6.3.1 Processing an Outgoing Message
This section describes the procedure followed by an SNMPv3 engine This section describes the procedure followed by an SNMPv3 engine
whenever it must authenticate an outgoing message using the whenever it must authenticate an outgoing message using the
usecMD5AuthProtocol. imfAuthMD5Protocol.
1) - If any cachedSecurityData exists for this message, then
information concerning the user is extracted from the
cachedSecurityData.
- Otherwise, the engineID and the userName are used to extract
the information concerning the user from the Security
Configuration Datastore (SCD, authMD5Table).
2) If the engineID is not known by this authentication module,
then the message cannot be sent. An error indication is
returned to the calling module.
3) If the userName is not known by this authentication module,
then the message cannot be sent. An error indication is
returned to the calling module.
4) The authParameters field is set to the serialization according 1) The authParameters field is set to the serialization according
to the rules in [RFC1907] of an octet string representing the to the rules in [RFC1906] of an octet string representing the
secret (localized) key of the user. secret (localized) authKey.
5) The secret (localized) key of the user is then appended to the 2) The secret (localized) authKey is then appended to the end of
end of the wholeMessage. the wholeMsg.
6) The MD5-Digest is calculated according to [MD5]. Then the 3) The MD5-Digest is calculated according to [MD5]. Then the
authParameters field is replaced with the calculated digest. authParameters field is replaced with the calculated digest.
7) The wholeMessage (excluding the appended secret key) is then 4) The wholeMsg (excluding the appended secret key) is then
returned to the caller. returned to the caller together with a statusCode of success.
6.3.2 Processing an Incoming Message 6.3.2 Processing an Incoming Message
This section describes the procedure followed by an SNMPv3 engine This section describes the procedure followed by an SNMPv3 engine
whenever it must authenticate an incoming message using the whenever it must authenticate an incoming message using the
usecMD5AuthProtocol. imfAuthMD5Protocol.
1) If the engineID is not known by this authentication module,
then the authMD5StatsUnknownEngineIDs counter is incremented,
a report PDU is generated and an error indication is returned
to the calling module.
2) If the userName is not known by this authentication module,
then the authMD5StatsUnknownUserNames counter is incremented,
a report PDU is generated and an error indication is returned
to the calling module.
3) If the digest received in the authParameters field is not 1) If the digest received in the authParameters field is not
16 octets long, then the authMD5StatsWrongDigests counter is 16 octets long, then an error indication (authenticationError)
incremented, a report PDU is generated and an error indication
is returned to the calling module. is returned to the calling module.
4) The digest received in the authParameters field is saved. 2) The digest received in the authParameters field is saved.
5) The engineID and the userName are used to extract information
concerning the user from the Security Configuration Datastore
(SCD, authMD5Table).
6) The digest in the authParameters field is replaced by the user's 3) The digest in the authParameters field is replaced by the
secret (localized) key. secret (localized) authKey.
7) The secret (localized) key of the user is then appended to the 4) The secret (localized) authKey is then appended to the end of
end of the wholeMessage. the wholeMsg.
8) The MD5-Digest is calculated according to [MD5]. 5) The MD5-Digest is calculated according to [MD5].
The authParameters field is replaced with the digest value The authParameters field is replaced with the digest value
that was saved in step 4). that was saved in step 2).
9) Then the newly calculated digest is compared with the digest
saved in step 4). If the digests do not match, then the
authMD5StatsUnknownUserNames counter is incremented, a report
PDU is generated and an error indication is returned to the
calling module.
10) The secret key (used for calculating the digest) is cached
as part of the cachedSecurityData.
11) The wholeMessage (excluding the appended secret key) and the
cachedSecurityData is then returned to the caller.
6.4 Definitions
SNMPv3-AUTH-MD5-MIB DEFINITIONS ::= BEGIN
IMPORTS
Counter32, Unsigned32,
MODULE-IDENTITY, OBJECT-TYPE, snmpModules FROM SNMPv2-SMI
TEXTUAL-CONVENTION, TestAndIncr,
RowStatus, AutonomousType, StorageType,
TDomain, TAddress, RowPointer FROM SNMPv2-TC
MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF,
SnmpV3GroupName, SnmpV3ContextName,
SnmpV3LoS, SnmpV3EngineID,
SnmpV3SecurityModel FROM SNMPv3-MIB,
UserName, usecMD5AuthProtocol FROM SNMPv3-USEC-MIB;
authMD5MIB MODULE-IDENTITY
LAST-UPDATED "9705090000Z" -- 09 May 1997, midnight
ORGANIZATION "SNMPv3 Working Group"
CONTACT-INFO "WG-email: snmpv3@tis.com
Subscribe: majordomo@tis.com
In msg body: subscribe snmpv3
Chair: Russ Mundy
Trutsed Information Systems
postal: 3060 Washington Rd
Glenwood MD 21738
email: mundy@tis.com
phone: 301-854-6889
Co-editor Uri Blumenthal
IBM T. J. Watson Research
postal: 30 Saw Mill River Pkwy,
Hawthorne, NY 10532
USA
email: uri@watson.ibm.com
phone: +1.914.784.7964
Co-editor: Bert Wijnen
IBM T. J. Watson Research
postal: Schagen 33
3461 GL Linschoten
Netherlands
email: wijnen@vnet.ibm.com
phone: +31-348-412-498
"
DESCRIPTION "The management information definitions for the
Keyed-MD5 authentication protocol for use with the
SNMPv3 User-based Security model.
"
::= { snmpModules xx }
authMD5Admin OBJECT IDENTIFIER ::= { authMD5MIB 1 }
authMD5MIBObjects OBJECT IDENTIFIER ::= { authMD5MIB 2 }
authMD5MIBConformance OBJECT IDENTIFIER ::= { authMD5MIB 3 }
KeyChange ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Every definition of an object with this syntax must identify
a protocol, P, and a secret key, K. The object's value is a
manager-generated, partially-random value which, when
modified, causes the value of the secret key, K, to be
modified via a one-way function.
The value of an instance of this object is the concatenation
of two components: a 'random' component and a 'delta'
component. The lengths of the random and delta components are
given by the corresponding value of the protocol, P; if P
requires K to be a fixed length, the length of both the random
and delta components is that fixed length; if P allows the
length of K to be variable up to a particular maximum length,
the length of the random component is that maximum length and
the length of the delta component is any length less than or
equal to that maximum length. For example,
usecMD5AuthProtocol requires K to be a fixed length of 16
octets. Other protocols may define other sizes, as deemed
appropriate.
When an instance of this object is modified to have a new
value by the management protocol, the agent generates a new
value of K as follows:
- a temporary variable is initialized to the existing value
of K;
- if the length of the delta component is greater than 16
bytes, then:
- the random component is appended to the value of the
temporary variable, and the result is input to the MD5
hash algorithm to produce a digest value, and the
temporary variable is set to this digest value;
- the value of the temporary variable is XOR-ed with the
first (next) 16-bytes of the delta component to produce
the first (next) 16-bytes of the new value of K.
- the above two steps are repeated until the unused
portion of the delta component is 16 bytes or less,
- the random component is appended to the value of the
temporary variable, and the result is input to the MD5
hash algorithm to produce a digest value;
- this digest value, truncated if necessary to be the same
length as the unused portion of the delta component, is
XOR-ed with the unused portion of the delta component to
produce the (final portion of the) new value of K.
i.e.,
iterations = (lenOfDelta - 1)/16; /* integer division */
temp = keyOld;
for (i = 0; i < iterations; i++) {
temp = MD5 (temp || random);
keyNew[i*16 .. (i*16)+15] =
temp XOR delta[i*16 .. (i*16)+15];
}
temp = MD5 (temp || random);
keyNew[i*16 .. lenOfDelta-1] =
temp XOR delta[i*16 .. lenOfDelta-1];
The value of an object with this syntax, whenever it is
retrieved by the management protocol, is always the zero-
length string."
SYNTAX OCTET STRING
authMD5Stats OBJECT IDENTIFIER ::= { authMD5MIBObjects 1 }
authMD5StatsUnknownUserNames OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The total number of packets received by the SNMPv3
engine which were dropped because they referenced a
user that was not known to the MD5 authentication
module in the engine.
"
::= { authMD5Stats 1 }
authMD5StatsUnknownEngineIDs OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The total number of packets received by the SNMPv3
engine which were dropped because they referenced an
engineID that was not known to the MD5 authentication
module in the engine.
"
::= { authMD5Stats 2 }
authMD5StatsWrongDigests OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The total number of packets received by the SNMPv3
engine which were dropped because they didn't
contain the expected digest value.
"
::= { authMD5Stats 3 }
authMD5Table OBJECT-TYPE
SYNTAX SEQUENCE OF AuthMD5TableEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "The SNMPv3 security configuration database (SCD) for
authentication information for users who use the
usecAuthMD5Protocol as the authentication protocol.
"
::= { authMD5MIBObjects 2 }
authMD5TableEntry OBJECT-TYPE
SYNTAX AuthMD5TableEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "An entry for a particular SNMPv3 user and engineID."
INDEX { authMD5EngineID,
IMPLIED authMD5UserName
}
::= { authMD5Table 1 }
AuthMD5TableEntry ::= SEQUENCE {
authMD5EngineID SnmpV3EngineID,
authMD5UserName UserName,
authMD5KeyChange KeyChange,
authMD5CloneFrom RowPointer,
authMD5Public OCTET STRING,
authMD5StorageType StorageType,
authMD5Status RowStatus
}
authMD5EngineID OBJECT-TYPE
SYNTAX SnmpEngineID
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "An SNMPv3 engine's administratively-unique identifier.
In a simple agent, this value is always that agent's
own snmpEngineID value.
This value can also take the value of the snmpEngineID
of a remote SNMP engine with which this user can
communicate.
"
::= { authMD5TableEntry 1 }
authMD5UserName OBJECT-TYPE
SYNTAX UserName
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "An octet string representing the name of the user."
::= { authMD5TableEntry 2 }
authMD5KeyChange OBJECT-TYPE
SYNTAX KeyChange -- typically (SIZE (0..32))
MAX-ACCESS read-create
STATUS current
DESCRIPTION "An object, which when modified, causes the secret
authentication key used for messages sent on behalf
of this user to/from the engine identified by
authMD5EngineID, to be modified via a one-way function.
The associated protocol is the usecAuthMD5Protocol.
The associated secret key is the user's secret
authentication key.
When creating a new user, it is an 'inconsistentName'
error for a set operation to refer to this object
unless it is previously or concurrently initialized
through a set operation on the corresponding value
of authMD5CloneFrom.
"
DEFVAL { ''H } -- the empty string
::= { authMD5TableEntry 3 }
authMD5CloneFrom OBJECT-TYPE
SYNTAX RowPointer
MAX-ACCESS read-create
STATUS current
DESCRIPTION "A pointer to another conceptual row in this
authMD5Table. The user in this other conceptual row
is called the clone-from user.
When a new user is created (i.e., a new conceptual row
is instantiated in this table), the authentication
parameters of the new user are cloned from its
clone-from user.
The first time an instance of this object is set by a
management operation (either at or after its
instantiation), the cloning process is invoked.
Subsequent writes are successful but invoke no action
to be taken by the agent.
The cloning process fails with an 'inconsistentName'
error if the conceptual row representing the
clone-from user is not in an active state when the
cloning process is invoked.
Cloning also causes the initial values of the secret
authentication key of the new user to be set to the
same value as the corresponding secret of the
clone-from user.
When this object is read, the zero length string is
returned.
"
::= { authMD5TableEntry 4 }
authMD5Public OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..32))
MAX-ACCESS read-create
STATUS current
DESCRIPTION "A publicly-readable value which is written as part
of the procedure for changing a user's secret key,
and later read to determine whether the change of
the secrets was effected.
"
DEFVAL { ''H } -- the empty string
::= { authMD5TableEntry 5 }
authMD5StorageType OBJECT-TYPE
SYNTAX StorageType
MAX-ACCESS read-create
STATUS current
DESCRIPTION "The storage type for this conceptual row.
Conceptual rows having the value 'permanent' must allow
write-access at a minimum to authMD5KeyChange and
authMD5Public.
Note that any user which employs authentication must
allow its secret to be updated and thus an entry in
this table cannot be 'readOnly'.
"
DEFVAL { nonVolatile }
::= { authMD5TableEntry 6 }
authMD5Status OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION "The status of this conceptual row. Until instances of
all corresponding columns are appropriately configured,
the value of the corresponding instance of the
authMD5Status column is 'notReady'. In particular,
a value must have been written to the authMD5CloneFrom
column.
For those columnar objects which permit write-access,
their value in an existing conceptual row can be
changed irrespective of the value of authMD5Status for
that row.
"
::= { authMD5TableEntry 7 }
authMD5SecretSpinLock OBJECT-TYPE
SYNTAX TestAndIncr
MAX-ACCESS read-write
STATUS current
DESCRIPTION "An advisory lock used to allow several cooperating
SNMPv3 engines, all acting in a manager role, to
coordinate their use of facilities to alter secrets
in the authMD5Table.
"
::= { authMD5MIBObjects 3 }
authMD5MIBCompliances
OBJECT IDENTIFIER ::= { authMD5MIBConformance 1 }
authMD5MIBGroups
OBJECT IDENTIFIER ::= { authMD5MIBConformance 2 }
authMD5MIBCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION "The compliance statement for SNMPv3 engines which
implement the SNMPv3 authMD5 MIB.
"
MODULE -- this module
MANDATORY-GROUPS { authMD5MIBBasicGroup }
::= { authMD5MIBCompliances 1 }
authMD5MIBBasicGroup OBJECT-GROUP 6) Then the newly calculated digest is compared with the digest
OBJECTS { authMD5StatsUnknownUserNames, saved in step 2). If the digests do not match, then an error
authMD5StatsUnknownEngineIDs, indication (authenticationError) is returned to the calling
authMD5StatsWrongDigests, module.
authMD5KeyChange,
authMD5CloneFrom,
authMD5Public,
authMD5StorageType,
authMD5Status,
authMD5SecretSpinLock
}
STATUS current
DESCRIPTION "A collection of objects providing for configuration
of an SNMPv3 entity which implements the SNMPv3
MD5 Authentication Protocol.
"
::= { authMD5MIBGroups 1 }
END 7) The wholeMsg (excluding the appended secret key) and a
statusCode of success are then returned to the caller.
7. DES Privacy Protocol 7. DES Privacy Protocol
This section describes the DES privacy protocol. This section describes the DES privacy protocol.
This protocol is the first privacy protocol defined for the This protocol is the first privacy protocol defined for the
User-based Security model. User-based Security model.
Over time, other privacy protocols may be defined either Over time, other privacy protocols may be defined either
as a replacement of this protocol or in addition to this protocol. as a replacement of this protocol or in addition to this protocol.
7.1 Mechanisms 7.1 Mechanisms
skipping to change at page 46, line 49 skipping to change at page 41, line 49
an SNMPv3 engine, this engine must implement at least the Data an SNMPv3 engine, this engine must implement at least the Data
Encryption Standard (DES) in the Cipher Block Chaining mode of Encryption Standard (DES) in the Cipher Block Chaining mode of
operation. operation.
Two organizations have published specifications defining the DES: the Two organizations have published specifications defining the DES: the
National Institute of Standards and Technology (NIST) [DES-NIST] and National Institute of Standards and Technology (NIST) [DES-NIST] and
the American National Standards Institute [DES-ANSI]. There is a the American National Standards Institute [DES-ANSI]. There is a
companion Modes of Operation specification for each definition companion Modes of Operation specification for each definition
(see [DESO-NIST] and [DESO-ANSI], respectively). (see [DESO-NIST] and [DESO-ANSI], respectively).
The NIST has published three additional documents that implementers The NIST has published three additional documents that implementors
may find useful. may find useful.
- There is a document with guidelines for implementing and using the - There is a document with guidelines for implementing and using the
DES, including functional specifications for the DES and its modes DES, including functional specifications for the DES and its modes
of operation [DESG-NIST]. of operation [DESG-NIST].
- There is a specification of a validation test suite for the DES - There is a specification of a validation test suite for the DES
[DEST-NIST]. The suite is designed to test all aspects of the DES [DEST-NIST]. The suite is designed to test all aspects of the DES
and is useful for pinpointing specific problems. and is useful for pinpointing specific problems.
skipping to change at page 47, line 25 skipping to change at page 42, line 25
7.1.1.1 DES key and Initialization Vector. 7.1.1.1 DES key and Initialization Vector.
The first 8 bytes of the 16-byte secret (private privacy key) are The first 8 bytes of the 16-byte secret (private privacy key) are
used as a DES key. used as a DES key.
Since DES uses only 56 bits, the Least Significant Bit in each Since DES uses only 56 bits, the Least Significant Bit in each
byte is disregarded. byte is disregarded.
The Initialization Vector for encryption is obtained using the The Initialization Vector for encryption is obtained using the
following procedure. following procedure.
The last 8 bytes of the 16-byte secret (private privacy key) are
used as pre-IV. The 32-bit engineTime is converted to a 4-byte
octet string, Most Significant Byte first. This octet string is
XOR-ed with the first four bytes of the pre-IV. The result is the
Initialization Vector to be used in the subsequent encryption.
The engine must ensure that the same value of engineTime is encoded
in the securityParameters structure.
Possibly, if we want to keep things clean and properly separated, The last 8 bytes of the 16-byte secret (private privacy key)
then the engineTime should be duplicated in the privParameters. are used as pre-IV.
The engineTime in the header of the securityParameters is used for
the timeliness checks, and so is used/handled in a different module. In order to ensure that IV for two different packets encrypted
Do we want those extra bytes on the wire? by the same key, are not the same (i.e. IV does not repeat) we
need to "salt" the pre-IV with something unique per packet.
An 8-byte octet string is used as the "salt". The concatenation
of the generating engine's 32-bit snmpEngineBoots and a local
32-bit integer that the encryption engine maintains is input to
the "salt". The 32-bit integer is initialized to a random value
at boot time. The 32-bit snmpEngineBoots is converted to the first
4 bytes (Most Significant Byte first) of our "salt". The 32-bit
integer is then converted to the last 4 bytes (Most Significant
Byte first) of our "salt". The resulting "salt" is then XOR-ed
with the pre-IV. The 8-byte salt is then put into the privParameters
field as an octet-string. The "salt" integer is incremented by one
and wraps when it reaches the maximum value.
The "salt" must be placed in the privParameters field to enable the
receiving entity to compute the correct IV and to decrypt the
message.
How exactly the value of the "salt" (and thus of the IV) varies,
is an implementation issue, as long as the measures are taken to
avoid producing a duplicate IV.
7.1.1.2 Data Encryption. 7.1.1.2 Data Encryption.
The data to be encrypted is treated as sequence of octets. Its The data to be encrypted is treated as sequence of octets. Its
length should be an integral multiple of 8 - and if not, the length should be an integral multiple of 8 - and if not, the
data is padded at the end as necessary. The actual pad value data is padded at the end as necessary. The actual pad value
is irrelevant. is irrelevant.
The data is encrypted in Cipher Block Chaining mode. The data is encrypted in Cipher Block Chaining mode.
The plaintext is divided into 64-bit blocks. The plaintext is divided into 64-bit blocks.
skipping to change at page 48, line 44 skipping to change at page 44, line 5
that engine must have knowledge of that user. An SNMPv3 engine that that engine must have knowledge of that user. An SNMPv3 engine that
wishes to communicate with another SNMPv3 engine must also have wishes to communicate with another SNMPv3 engine must also have
knowledge of a user known to that engine, including knowledge of the knowledge of a user known to that engine, including knowledge of the
applicable attributes of that user. applicable attributes of that user.
A user and its attributes are defined as follows: A user and its attributes are defined as follows:
<userName> <userName>
An octet string representing the name of the user. An octet string representing the name of the user.
<privDESPrivateKey> <privKey>
If messages sent on behalf of this user can be en/decrypted, the A user's secret key to be used as input for the DES key and IV.
(private) privacy key for use with the privacy protocol. Note that
a user's privacy key will normally be different at different
authoritative engines.
7.2.2. EngineID 7.2.2. EngineID
The engineID value contained in an authenticated message specifies The engineID value contained in an authenticated message specifies
the authoritative SNMPv3 engine for that particular message. the authoritative SNMPv3 engine for that particular message.
(see the definition of engineID in the SNMPng Architectural model (see the definition of engineID in the SNMP Architecture document
document [SNMPng-ARCH]). [SNMP-ARCH]).
The user's (private) authentication key is normally different at The user's (private) privacy key is normally different at
each authoritative SNMPv3 engine and so the snmpEngineID is used each authoritative SNMPv3 engine and so the snmpEngineID is used
to select the proper key for the authentication process. to select the proper key for the authentication process.
7.2.3. SNMPv3 Messages Using this Privacy Protocol 7.2.3. SNMPv3 Messages Using this Privacy Protocol
Messages using this privacy protocol carry a privParameters Messages using this privacy protocol carry a privParameters
field as part of the securityParameters. For this protocol, the field as part of the securityParameters. For this protocol, the
privParameters field is the serialized octet string representing privParameters field is the serialized octet string representing
a NULL (zero length) string. the "salt" that was used to create the IV.
7.2.4 Input and Output of the DES Privacy Module 7.2.4 Input and Output of the DES Privacy Module
This section describes the inputs and outputs that the DES Privacy This section describes the inputs and outputs that the DES Privacy
module expects and produces when the User-based Security module module expects and produces when the User-based Security module
invokes the DES Privacy module for services. invokes the DES Privacy module for services.
7.2.4.1 Input and Output when generating an SNMPv3 Message 7.2.4.1 Input and Output when generating an SNMPv3 Message
When the User-based Security module invokes the DES Privacy module This DES privacy protocol assumes that the selection of the
to encrypt part of an outgoing message, it must pass as arguments: privKey is done by the caller and that the caller passes
the secret key to be used. The abstract service interface is:
<engineID> encryptMsg(cryptKey, scopedPDU)
the engineID of the authoritative SNMPv3 engine as it will be
included in the message.
<userName>
the user on whose behalf the message is to be encrypted.
<engineTime>
the engineTime value as it will be included in the message.
<cachedSecurityData>
the possible cached security data if this is a response to an
earlier request message.
<scopedPDU>
the data to be encrypted.
Upon completion the privacy module must return either an error Where:
indication or:
<encryptedPDU> cryptKey
the encrypted scopedPDU (encoded as an octet string). The secret key to be used by the encryption algorithm.
<privParameters> scopedPDU
The privacy parameters (encoded as an octet string) that need The data to be encrypted.
to be sent in the outgoing message.
Upon completion the privacy module returns information.
The abstract service interface is:
returnEncryptedMsg(encryptedPDU, privParameters, statusCode)
Where:
encryptedPDU
The encrypted scopedPDU (encoded as an octet string).
privParameters
The privacy parameters (encoded as an octet string) that
need to be sent in the outgoing message.
statusCode
The indicator of whether the PDU was encrypted successfully
and if not, it indicates what went wrong.
7.2.4.2 Input and Output when receiving an SNMPv3 Message 7.2.4.2 Input and Output when receiving an SNMPv3 Message
When the User-based Security module invokes the DES Privacy module This DES privacy protocol assumes that the selection of the
to decrypt part of an incoming message, it must pass as arguments: privKey is done by the caller and that the caller passes
the secret key to be used. The abstract service interface is:
<snmpEngineID> decryptMsg(cryptKey, privParameters, encryptedPDU)
the engineID of the authoritative SNMPv3 engine as it was
included in the message. Where:
<userName>
the user on whose behalf the message is to be decrypted. cryptKey
<engineTime> The secret key to be used by the decryption algorithm.
the engineTime value as it was included in the message. privParameters
<encryptedPDU> The "salt" to be used to calculate the IV.
encryptedPDU
the data to be decrypted the data to be decrypted
Output expected from the privacy module is an error code or: Upon completion the privacy module returns information.
The abstract service interface is:
<cachedSecurityData> returnDecryptedMsg(scopedPDU, statusCode)
the cached security data so that it can be used later when
<scopedPDU>
the decrypted scopedPDU.
If an error indication is returned by the DES Privacy module, then Where:
the message cannot be decrypted and so the data is unusable and
cannot be trusted. In the case that there was not enough scopedPDU
information in the Security Configuration Database (SCD) to The decrypted scopedPDU.
actually perform the privacy process, then a report PDU may statusCode
have been generated to inform the sender about the error condition. The indicator whether the message was successfully decrypted.
7.3 Elements of Procedure. 7.3 Elements of Procedure.
This section describes the procedures for the DES privacy protocol. This section describes the procedures for the DES privacy protocol.
7.3.1 Processing an Outgoing Message 7.3.1 Processing an Outgoing Message
This section describes the procedure followed by an SNMPv3 engine This section describes the procedure followed by an SNMPv3 engine
whenever it must encrypt part of an outgoing message using the whenever it must encrypt part of an outgoing message using the
usecDESPrivProtocol. imfPrivDESProtocol.
1) - If any cachedSecurityData exists for this message, then
information concerning the user is extracted from the
cachedSecurityData.
- Otherwise, the engineID and the userName are used to extract
the information concerning the user from the Security
Configuration Datastore (SCD, privDESTable).
2) If the engineID is not known by this privacy module,
then the message cannot be sent. An error indication is
returned to the calling module.
3) If the userName is not known by this privacy module,
then the message cannot be sent. An error indication is
returned to the calling module.
4) The authParameters field is set to the serialization according 1) The secret (localized) cryptKey are used to construct the DES
to the rules in [RFC1907] of an octet string representing the encryption key, the "salt" and the DES pre-IV (as described in
the NULL (zero length) string. 7.1.1.1).
5) The secret (localized) key of the user and the engineTime are 2) The authParameters field is set to the serialization according
then used to construct the DES encryption key and pre-IV (as to the rules in [RFC1906] of an octet string representing the
described in 7.1.1.1). the "salt" string.
6) The scopedPDU is encrypted (as described in 7.1.1.2) and the 2) The scopedPDU is encrypted (as described in 7.1.1.2) and the
encrypted data is serialized according to the rules in [RFC1907] encrypted data is serialized according to the rules in [RFC1906]
as an octet string. as an octet string.
7) The the serialized octet string representing the encrypted 3) The the serialized octet string representing the encrypted
scopedPDU and the cachedSecurityData together with the scopedPDU together with the privParameters and a statusCode of
privParameters is returned to the caller. success is returned to the caller.
7.3.2 Processing an Incoming Message 7.3.2 Processing an Incoming Message
This section describes the procedure followed by an SNMPv3 engine This section describes the procedure followed by an SNMPv3 engine
whenever it must decrypt part of an incoming message using the whenever it must decrypt part of an incoming message using the
usecDESPrivProtocol. imfPrivDESProtocol.
1) If the engineID is not known by this privacy module, then the
privDESStatsUnknownEngineIDs counter is incremented, a report
PDU is generated and an error indication is returned to the
calling module.
2) If the userName is not known by this privacy module, then the
privDESStatsUnknownUserNames counter is incremented, a report
PDU is generated and an error indication is returned to the
calling module.
3) If the privParameters field is not the NULL (zero length) string,
then the privDESStatsDecryptionErrors counter is incremented,
a report PDU is generated and an error indication is returned
to the calling module.
4) The engineID and the userName are used to extract information
concerning the user from the Security Configuration Datastore
(SCD, privDESTable).
5) The secret (localized) key of the user and the engineTime are
then used to construct the DES decryption key and pre-IV (as
described in 7.1.1.1).
6) The encryptedPDU is decrypted (as described in 7.1.1.3).
7) If the encryptedPDU cannot be decrypted, then the 1) If the privParameters field is not an 8-byte octet string,
privDESStatsDecryptionErrors counter is incremented, a report then an error indication (privacyError) is returned to the
PDU is generated and an error indication is returned to the
calling module. calling module.
8) The secret (localized) key (used for constructing the DES 2) The "salt" is extracted from the privParameters field.
decryption key and the pre-IV) is cached as part of the
cachedSecurityData.
9) The decrypted data is returned to the calling module as the
scopedPDU together with the cachedSecurityData.
7.4 Definitions
SNMPv3-PRIV-DES-MIB DEFINITIONS ::= BEGIN
IMPORTS
Counter32, Unsigned32,
MODULE-IDENTITY, OBJECT-TYPE, snmpModules FROM SNMPv2-SMI
TEXTUAL-CONVENTION, TestAndIncr,
RowStatus, AutonomousType, StorageType,
TDomain, TAddress, RowPointer FROM SNMPv2-TC
MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF,
SnmpV3GroupName, SnmpV3ContextName,
SnmpV3LoS, SnmpV3EngineID,
SnmpV3SecurityModel FROM SNMPv3-MIB,
UserName, usecDESPrivProtocol FROM SNMPv3-USEC-MIB,
KeyChange FROM SNMPv3-AUTH-MD5-MIB;
privDESMIB MODULE-IDENTITY
LAST-UPDATED "9705090000Z" -- 09 May 1997, midnight
ORGANIZATION "SNMPv3 Working Group"
CONTACT-INFO "WG-email: snmpv3@tis.com
Subscribe: majordomo@tis.com
In msg body: subscribe snmpv3
Chair: Russ Mundy
Trutsed Information Systems
postal: 3060 Washington Rd
Glenwood MD 21738
email: mundy@tis.com
phone: 301-854-6889
Co-editor Uri Blumenthal
IBM T. J. Watson Research
postal: 30 Saw Mill River Pkwy,
Hawthorne, NY 10532
USA
email: uri@watson.ibm.com
phone: +1.914.784.7964
Co-editor: Bert Wijnen
IBM T. J. Watson Research
postal: Schagen 33
3461 GL Linschoten
Netherlands
email: wijnen@vnet.ibm.com
phone: +31-348-412-498
"
DESCRIPTION "The management information definitions for the
Keyed-MD5 authentication protocol for use with the
SNMPv3 User-based Security model.
"
::= { snmpModules xx }
privDESAdmin OBJECT IDENTIFIER ::= { privDESMIB 1 }
privDESMIBObjects OBJECT IDENTIFIER ::= { privDESMIB 2 }
privDESMIBConformance OBJECT IDENTIFIER ::= { privDESMIB 3 }
privDESStats OBJECT IDENTIFIER ::= { privDESMIBObjects 1 }
privDESStatsUnknownUserNames OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The total number of packets received by the SNMPv3
engine which were dropped because they referenced a
user that was not known to the DES privacy module
in the engine.
"
::= { privDESStats 1 }
privDESStatsUnknownEngineIDs OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The total number of packets received by the SNMPv3
engine which were dropped because they referenced an
engineID that was not known to the DES privacy module
in the engine.
"
::= { privDESStats 2 }
privDESStatsDecryptionErrors OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The total number of packets received by the SNMPv3
engine which were dropped because they could not be
decrypted.
"
::= { privDESStats 3 }
privDESTable OBJECT-TYPE
SYNTAX SEQUENCE OF PrivDESTableEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "The SNMPv3 security configuration database (SCD) for
privacy information for users who use the
usecDESPrivProtocol as the privacy protocol.
"
::= { privDESMIBObjects 2 }
privDESTableEntry OBJECT-TYPE
SYNTAX PrivDESTableEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "An entry for a particular SNMPv3 user and engineID."
INDEX { privDESEngineID,
IMPLIED privDESUserName
}
::= { privDESTable 1 }
PrivDESTableEntry ::= SEQUENCE {
privDESEngineID SnmpV3EngineID,
privDESUserName UserName,
privDESKeyChange KeyChange,
privDESCloneFrom RowPointer,
privDESPublic OCTET STRING,
privDESStorageType StorageType,
privDESStatus RowStatus
}
privDESEngineID OBJECT-TYPE
SYNTAX SnmpEngineID
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "An SNMPv3 engine's administratively-unique identifier.
In a simple agent, this value is always that agent's
own snmpEngineID value.
This value can also take the value of the snmpEngineID
of a remote SNMP engine with which this user can
communicate.
"
::= { privDESTableEntry 1 }
privDESUserName OBJECT-TYPE
SYNTAX UserName
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "An octet string representing the name of the user."
::= { privDESTableEntry 2 }
privDESKeyChange OBJECT-TYPE
SYNTAX KeyChange -- typically (SIZE (0..32))
MAX-ACCESS read-create
STATUS current
DESCRIPTION "An object, which when modified, causes the secret
privacy key used for messages sent on behalf of this
user to/from the engine identified by privDESEngineID,
to be modified via a one-way function.
The associated protocol is the usecDESPrivProtocol.
The associated secret key is the user's secret
privacy key.
When creating a new user, it is an 'inconsistentName'
error for a set operation to refer to this object
unless it is previously or concurrently initialized
through a set operation on the corresponding value
of privDESCloneFrom.
"
DEFVAL { ''H } -- the empty string
::= { privDESTableEntry 3 }
privDESCloneFrom OBJECT-TYPE
SYNTAX RowPointer
MAX-ACCESS read-create
STATUS current
DESCRIPTION "A pointer to another conceptual row in this
privDESTable. The user in this other conceptual row
is called the clone-from user.
When a new user is created (i.e., a new conceptual row
is instantiated in this table), the privacy parameters
of the new user are cloned from its clone-from user.
The first time an instance of this object is set by a
management operation (either at or after its
instantiation), the cloning process is invoked.
Subsequent writes are successful but invoke no action
to be taken by the agent.
The cloning process fails with an 'inconsistentName'
error if the conceptual row representing the
clone-from user is not in an active state when the
cloning process is invoked.
Cloning also causes the initial values of the secret
privacy key of the new user to be set to the same
value as the corresponding secret of the clone-from
user.
When this object is read, the zero length string is
returned.
"
::= { privDESTableEntry 4 }
privDESPublic OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(1..32))
MAX-ACCESS read-create
STATUS current
DESCRIPTION "A publicly-readable value which is written as part
of the procedure for changing a user's secret key,
and later read to determine whether the change of
the secrets was effected.
"
DEFVAL { ''H } -- the empty string
::= { privDESTableEntry 5 }
privDESStorageType OBJECT-TYPE
SYNTAX StorageType
MAX-ACCESS read-create
STATUS current
DESCRIPTION "The storage type for this conceptual row.
Conceptual rows having the value 'permanent' must allow
write-access at a minimum to privDESKeyChange and
privDESPublic.
Note that any user which employs privacy must allow
its secret to be updated and thus an entry in this
table cannot be 'readOnly'.
"
DEFVAL { nonVolatile }
::= { privDESTableEntry 6 }
privDESStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION "The status of this conceptual row. Until instances of
all corresponding columns are appropriately configured,
the value of the corresponding instance of the
privDESStatus column is 'notReady'. In particular,
a value must have been written to the privDESCloneFrom
column.
For those columnar objects which permit write-access,
their value in an existing conceptual row can be
changed irrespective of the value of privDESStatus
for that row.
"
::= { privDESTableEntry 7 }
privDESSecretSpinLock OBJECT-TYPE
SYNTAX TestAndIncr
MAX-ACCESS read-write
STATUS current
DESCRIPTION "An advisory lock used to allow several cooperating
SNMPv3 engines, all acting in a manager role, to
coordinate their use of facilities to alter secrets
in the privDESTable.
"
::= { privDESMIBObjects 3 }
privDESMIBCompliances
OBJECT IDENTIFIER ::= { privDESMIBConformance 1 }
privDESMIBGroups
OBJECT IDENTIFIER ::= { privDESMIBConformance 2 }
privDESMIBCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION "The compliance statement for SNMPv3 engines which
implement the SNMPv3 privDES MIB.
"
MODULE -- this module
MANDATORY-GROUPS { privDESMIBBasicGroup }
::= { privDESMIBCompliances 1 } 3) The secret (localized) cryptKey and the "salt" are then used
to construct the DES decryption key and pre-IV
(as described in 7.1.1.1).
4) The encryptedPDU is decrypted (as described in 7.1.1.3).
privDESMIBBasicGroup OBJECT-GROUP 5) If the encryptedPDU cannot be decrypted, then an error
OBJECTS { privDESStatsUnknownUserNames, indication (privacyError) is returned to the calling module.
privDESStatsUnknownEngineIDs,
privDESStatsDecryptionErrors,
privDESKeyChange,
privDESCloneFrom,
privDESPublic,
privDESStorageType,
privDESStatus,
privDESSecretSpinLock
}
STATUS current
DESCRIPTION "A collection of objects providing for configuration
of an SNMPv3 entity which implements the SNMPv3
DES Privacy Protocol.
"
::= { privDESMIBGroups 1 }
END 6) The decrypted scopedPDU and a statusCode of success are returned
to the calling module.
8. Editor's Addresses 8. Editor's Addresses
Co-editor Uri Blumenthal Co-editor Uri Blumenthal
IBM T. J. Watson Research IBM T. J. Watson Research
postal: 30 Saw Mill River Pkwy, postal: 30 Saw Mill River Pkwy,
Hawthorne, NY 10532 Hawthorne, NY 10532
USA USA
email: uri@watson.ibm.com email: uri@watson.ibm.com
phone: +1-914-784-7064 phone: +1-914-784-7064
skipping to change at page 60, line 25 skipping to change at page 48, line 25
request. request.
Although it would be typical for a management station to do this Although it would be typical for a management station to do this
as a matter of course, when using these security protocols it is as a matter of course, when using these security protocols it is
significant due to the possibility of message duplication significant due to the possibility of message duplication
(malicious or otherwise). (malicious or otherwise).
- A management station must generate unpredictable msgIDs and - A management station must generate unpredictable msgIDs and
request-ids in authenticated messages in order to protect against request-ids in authenticated messages in order to protect against
the possibility of message duplication (malicious or otherwise). the possibility of message duplication (malicious or otherwise).
For example, start operations with msgID and/or request-id 0 is
not a good idea. Initializing them with a pseudorandom number
and then incrementing by one would be acceptable.
- A management station should perform time synchronization using - A management station should perform time synchronization using
authenticated messages in order to protect against the possibility authenticated messages in order to protect against the possibility
of message duplication (malicious or otherwise). of message duplication (malicious or otherwise).
- When sending state altering messages to a managed agent, a - When sending state altering messages to a managed agent, a
management station should delay sending successive messages to the management station should delay sending successive messages to the
managed agent until a positive acknowledgement is received for the managed agent until a positive acknowledgement is received for the
previous message or until the previous message expires. previous message or until the previous message expires.
skipping to change at page 62, line 21 skipping to change at page 50, line 25
will not help and network security may be compromised in this case. will not help and network security may be compromised in this case.
10.3. Conformance 10.3. Conformance
To be termed a "Secure SNMPv3 implementation" based on the User-base To be termed a "Secure SNMPv3 implementation" based on the User-base
Security model, an SNMPv3 implementation: Security model, an SNMPv3 implementation:
- must implement one or more Authentication Protocol(s). The MD5 - must implement one or more Authentication Protocol(s). The MD5
Authentication Protocol defined in this memo is one such protocol. Authentication Protocol defined in this memo is one such protocol.
- must, to the maximal extent possible, prohibit access to the - must, to the maximum extent possible, prohibit access to the
secret(s) of each user about which it maintains information in a secret(s) of each user about which it maintains information in a
Security Configuration Database (SCD) under all circumstances Local (security) Configuration Database (LCD) under all
except as required to generate and/or validate SNMPv3 messages circumstances except as required to generate and/or validate
with respect to that user. SNMPv3 messages with respect to that user.
- must implement these MIBs: - must implement the SNMP USEC MIB.
- SNMPv3 USEC MIB.
- the authentication MIB for the authentication protocol(s) in
use. The SNMPv3 AUTH-MD5 MIB defined in this memo is one such
MIB.
In addition, an SNMPv3 agent must provide initial configuration in In addition, an authoritative SNMPv3 engine must provide initial
accordance with Appendix A.1. configuration in accordance with Appendix A.1.
Implementation of a Privacy Protocol (the Symmetric Encryption Implementation of a Privacy Protocol (the Symmetric Encryption
Protocol defined in this memo is one such protocol) and its related Protocol defined in this memo is one such protocol) is optional.
MIB (the SNMPv3 PRIV-DES MIB defined in this memo is one such MIB)
is optional.
11. References 11. References
[RFC1902] The SNMPv2 Working Group, Case, J., McCloghrie, K., [RFC1902] The SNMPv2 Working Group, Case, J., McCloghrie, K.,
Rose, M., and S., Waldbusser, "Structure of Management Rose, M., and S., Waldbusser, "Structure of Management
Information for Version 2 of the Simple Network Management Information for Version 2 of the Simple Network Management
Protocol (SNMPv2)", RFC 1905, January 1996. Protocol (SNMPv2)", RFC 1905, January 1996.
[RFC1905] The SNMPv2 Working Group, Case, J., McCloghrie, K., [RFC1905] The SNMPv2 Working Group, Case, J., McCloghrie, K.,
Rose, M., and S., Waldbusser, "Protocol Operations for Rose, M., and S., Waldbusser, "Protocol Operations for
skipping to change at page 63, line 32 skipping to change at page 51, line 32
[RFC1907] The SNMPv2 Working Group, Case, J., McCloghrie, K., [RFC1907] The SNMPv2 Working Group, Case, J., McCloghrie, K.,
Rose, M., and S. Waldbusser, "Management Information Base for Rose, M., and S. Waldbusser, "Management Information Base for
Version 2 of the Simple Network Management Protocol (SNMPv2)", Version 2 of the Simple Network Management Protocol (SNMPv2)",
RFC 1907 January 1996. RFC 1907 January 1996.
[RFC1908] The SNMPv2 Working Group, Case, J., McCloghrie, K., [RFC1908] The SNMPv2 Working Group, Case, J., McCloghrie, K.,
Rose, M., and S. Waldbusser, "Coexistence between Version 1 Rose, M., and S. Waldbusser, "Coexistence between Version 1
and Version 2 of the Internet-standard Network Management and Version 2 of the Internet-standard Network Management
Framework", RFC 1908, January 1996. Framework", RFC 1908, January 1996.
[SNMPng-ARCH] The SNMPv3 Working Group, Harrington, D., Wijnen, B., [SNMP-ARCH] The SNMPv3 Working Group, Harrington, D., Wijnen, B.,
"Architectural Model for the Next Generation Simple Network "An Architecture for describing Internet Management Frameworks",
Managememt Protocol (SNMPng)", draft-ietf-snmpv3-next-gen-arch-02.txt, June 1997.
draft-ietf-snmpv3-next-gen-arch-00.txt,
March 1997.
[SNMPv3-MPC] The SNMPv3 Working Group, Wijnen, B., Harrington, D., [SNMPv3-MPC] The SNMPv3 Working Group, Wijnen, B., Harrington, D.,
"Message Processing and Control Model for version 3 of the Simple "Message Processing and Control Model for version 3 of the Simple
Network Management Protocol (SNMPv3)", Network Management Protocol (SNMPv3)",
draft-ietf-snmpv3-mpc-00.txt, draft-ietf-snmpv3-mpc-01.txt, June 1997.
March 1997.
[SNMPv3-LPM] The SNMPv3 Working Group, Wijnen, B., Harrington, D., [SNMPv3-ACM] The SNMPv3 Working Group, Wijnen, B., Harrington, D.,
"Local Processing Model for version 3 of the Simple Network "Access Control Model for Version 3 of the Simple Network
Management Protocol (SNMPv3)", Management Protocol (SNMPv3)", draft-ietf-snmpv3-acm-00.txt,
draft-ietf-snmpv3-lpm-00.txt, June 1997.
March 1997.
[SNMPv3-USEC] The SNMPv3 Working Group, Blumenthal, U., Wijnen, B. [SNMPv3-USEC] The SNMPv3 Working Group, Blumenthal, U., Wijnen, B.
"User-Based Security Model for version 3 of the Simple Network "User-Based Security Model for version 3 of the Simple Network
Managememt Protocol (SNMPv3)", Management Protocol (SNMPv3)",
draft-ietf-snmpv3-usec-00.txt, April 1997. draft-ietf-snmpv3-usec-01.txt, June 1997.
[Localized-Key] U. Blumenthal, N. C. Hien, B. Wijnen [Localized-Key] U. Blumenthal, N. C. Hien, B. Wijnen
"Key Derivation for Network Management Applications" "Key Derivation for Network Management Applications"
IEEE Network Magazine, April/May issue, 1997. IEEE Network Magazine, April/May issue, 1997.
[KEYED-MD5] Krawczyk, H., [KEYED-MD5] Krawczyk, H.,
"Keyed-MD5 for Message Authentication", "Keyed-MD5 for Message Authentication",
Work in Progress, IBM, June 1995. Work in Progress, IBM, June 1995.
[MD5] Rivest, R. [MD5] Rivest, R.
skipping to change at page 65, line 40 skipping to change at page 53, line 40
The resulting digest is the required secret (see Appendix A.2). The resulting digest is the required secret (see Appendix A.2).
With these configured parameters, the SNMPv3 engine instantiates With these configured parameters, the SNMPv3 engine instantiates
the following usecUserEntry in the usecUserTable: the following usecUserEntry in the usecUserTable:
no privacy support privacy support no privacy support privacy support
------------------ --------------- ------------------ ---------------
usecUserEngineID localEngineID localEngineID usecUserEngineID localEngineID localEngineID
usecUserName "public" "public" usecUserName "public" "public"
usecUserMiId "public" "public"
usecUserGroupName "public" "public" usecUserGroupName "public" "public"
usecUserAuthProtocol usecMD5AuthProtocol usecMD5AuthProtocol usecUserCloseFrom ZeroDotZero ZeroDotZero
usecUserPrivProtocol none usecDESPrivProtocol usecUserAuthProtocol imfAuthMD5Protocol imfAuthMD5Protocol
usecUserAuthKeyChange "" ""
usecUserAuthPublic "" ""
usecUserPrivProtocol none imfPrivDESProtocol
usecUserPrivKeyChange "" ""
usecUserrivhPublic "" ""
usecUserStorageType permanent permanent usecUserStorageType permanent permanent
usecUserSecurityCookie <upToImplemeter> <upToImplementer>
usecUserStatus active active usecUserStatus active active
With these configured parameters, the SNMPv3 engine instantiates
the following authMD5TableEntry in the authMD5Table:
no privacy support privacy support
------------------ ---------------
authMD5EngineID localEngineID localEngineID
authMD5UserName "public" "public"
authMD5KeyChange "" ""
authMD5CloneFrom ZeroDotZero ZeroDotZero
authMD5Public "" ""
authMD5StorageType permanent permanent
authMD5Status active active
With these configured parameters, the SNMPv3 engine instantiates
the following authMD5TableEntry in the authMD5Table:
no privacy support privacy support
------------------ ---------------
authMD5EngineID localEngineID
authMD5UserName "public"
authMD5KeyChange ""
authMD5CloneFrom ZeroDotZero
authMD5Public ""
authMD5StorageType permanent
authMD5Status active
A.2. Password to Key Algorithm A.2. Password to Key Algorithm
The following code fragment demonstrates the password to key The following code fragment demonstrates the password to key
algorithm which can be used when mapping a password to an algorithm which can be used when mapping a password to an
authentication or privacy key. The calls to MD5 are as authentication or privacy key. The calls to MD5 are as
documented in RFC1321 [RFC1321] documented in RFC1321 [RFC1321]
void password_to_key( void password_to_key(
u_char *password, /* IN */ u_char *password, /* IN */
u_int passwordlen, /* IN */ u_int passwordlen, /* IN */
u_char *agentID, /* IN - ptr to 12 octet long snmpEngineID */ u_char *engineID, /* IN - ptr to 12 octet long snmpEngineID */
u_char *key) /* OUT - caller's pointer to 16-byte buffer */ u_char *key) /* OUT - caller's pointer to 16-byte buffer */
{ {
MD5_CTX MD; MD5_CTX MD;
u_char *cp, password_buf[64]; u_char *cp, password_buf[64];
u_long password_index = 0; u_long password_index = 0;
u_long count = 0, i; u_long count = 0, i;
MD5Init (&MD); /* initialize MD5 */ MD5Init (&MD); /* initialize MD5 */
/**********************************************/ /**********************************************/
skipping to change at page 67, line 43 skipping to change at page 54, line 43
/* to the beginning of the password as necessary.*/ /* to the beginning of the password as necessary.*/
/*************************************************/ /*************************************************/
*cp++ = password[password_index++ % passwordlen]; *cp++ = password[password_index++ % passwordlen];
} }
MDupdate (&MD, password_buf, 64); MDupdate (&MD, password_buf, 64);
count += 64; count += 64;
} }
MD5Final (key, &MD); /* tell MD5 we're done */ MD5Final (key, &MD); /* tell MD5 we're done */
/*****************************************************/ /*****************************************************/
/* Now localize the key with the agentID and pass */ /* Now localize the key with the engineID and pass */
/* through MD5 to produce final key */ /* through MD5 to produce final key */
/*****************************************************/ /*****************************************************/
memcpy(password_buf, key, 16); memcpy(password_buf, key, 16);
memcpy(password_buf+16, agentID, 12); memcpy(password_buf+16, engineID, 12);
memcpy(password_buf+28, key, 16); memcpy(password_buf+28, key, 16);
MD5Init(&MD); MD5Init(&MD);
MDupdate(&MD, password_buf, 44); MDupdate(&MD, password_buf, 44);
MD5Final(key, &MD); MD5Final(key, &MD);
return; return;
} }
A.3. Password to Key Sample A.3. Password to Key Sample
skipping to change at page 69, line 7 skipping to change at page 56, line 7
snmpEngineID value of: snmpEngineID value of:
'00 00 00 00 00 00 00 00 00 00 00 02'H '00 00 00 00 00 00 00 00 00 00 00 02'H
the final output of the password to key algorithm is: the final output of the password to key algorithm is:
'52 6f 5e ed 9f cc e2 6f 89 64 c2 93 07 87 d8 2b'H '52 6f 5e ed 9f cc e2 6f 89 64 c2 93 07 87 d8 2b'H
Table of Contents Table of Contents
0. Change Log 2 0.1 Issues 1
0.2 Change Log 2
1. Introduction 3 1. Introduction 3
1.1. Threats 3 1.1. Threats 3
1.2. Goals and Constraints 4 1.2. Goals and Constraints 4
1.3. Security Services 5 1.3. Security Services 5
1.4. Implementation Organization 6 1.4. Implementation Organization 6
1.4.1. Timeliness Module 6 1.4.1. Timeliness Module 6
1.4.2. Authentication Protocol 6 1.4.2. Authentication Protocol 6
1.4.3. Privacy Protocol 7 1.4.3. Privacy Protocol 7
1.5 Mechanisms to protect against Message Replay, Delay and Redirection 7 1.5 Protection against Message Replay, Delay and Redirection 7
1.5.1 Authoritative SNMP Engine 7 1.5.1 Authoritative SNMP Engine 7
1.5.2 The following mechanisms are used: 7 1.5.2 The following mechanisms are used: 7
1.5.1). On receipt of a message, an authoritative engine checks the 8
2. Elements of the Model 10 2. Elements of the Model 10
2.1. SNMPv3 Users 10 2.1. SNMPv3 Users 10
2.2. Replay Protection 10 2.2. Replay Protection 11
2.2.1. snmpEngineID 11 2.2.1. snmpEngineID 11
2.2.2. engineBoots and engineTime 11 2.2.2. engineBoots and engineTime 11
2.4 for (re-)synchronization procedures). Note, however, that the 11 2.3 for (re-)synchronization procedures). Note, however, that the 12
2.2.3. Time Window 12 2.2.3. Time Window 12
2.3. Error Reporting 12 2.3. Time Synchronization 12
2.4. Time Synchronization 12 2.4. SNMPv3 Messages Using this Model 13
2.5. SNMPv3 Messages Using this Model 13 2.5 Input and Output of the User-based Security Module 14
2.6 Input and Output of the User-based Security Module 13 2.5.1 Input and Output when generating an SNMPv3 Message 14
2.6.1 Input and Output when generating an SNMPv3 Message 14 2.5.2 Input and Output when receiving an SNMPv3 Message 15
2.6.1 Input and Output when receiving an SNMPv3 Message 14 3. Elements of Procedure 18
3. Elements of Procedure 17 3.1. Processing an Outgoing Message 18
3.1. Processing an Outgoing Message 17 3.2. Processing an Incoming Message 20
3.2. Processing an Incoming Message 19 2.4, then the snmpInASNParseErrs counter [RFC1907] is 20
2.5, then the snmpInASNParseErrs counter [RFC1907] is 19 4. Discovery 25
4. Discovery 24 5. Definitions 26
5. Definitions 25 6. MD5 Authentication Protocol 36
6. MD5 Authentication Protocol 33 6.1 Mechanisms 36
6.1 Mechanisms 33 6.1.1. Digest Authentication Protocol 36
6.1.1. Digest Authentication Protocol 33 6.2 Elements of the Digest Authentication Protocol 37
6.2 Elements of the Digest Authentication Protocol 34 6.2.1. SNMPv3 Users 37
6.2.1. SNMPv3 Users 34 6.2.2. EngineID 37
6.2.2. EngineID 34 6.2.3. SNMPv3 Messages Using this Authentication Protocol 37
6.2.3. SNMPv3 Messages Using this Authentication Protocol 34 6.2.4 Input and Output of the MD5 Authentication Module 37
6.2.4 Input and Output of the MD5 Authentication Module 35 6.2.4.1 Input and Output when generating an SNMPv3 Message 38
6.2.4.1 Input and Output when generating an SNMPv3 Message 35 6.2.4.2 Input and Output when receiving an SNMPv3 Message 38
6.2.4.2 Input and Output when receiving an SNMPv3 Message 35 6.3 Elements of Procedure 39
6.3 Elements of Procedure 36 6.3.1 Processing an Outgoing Message 39
6.3.1 Processing an Outgoing Message 36 6.3.2 Processing an Incoming Message 39
6.3.2 Processing an Incoming Message 36 7. DES Privacy Protocol 41
6.4 Definitions 38 7.1 Mechanisms 41
7. DES Privacy Protocol 46 7.1.1. Symmetric Encryption Protocol 41
7.1 Mechanisms 46 7.1.1.1 DES key and Initialization Vector. 42
7.1.1. Symmetric Encryption Protocol 46 7.1.1.2 Data Encryption. 42
7.1.1.1 DES key and Initialization Vector. 47 7.1.1.3 Data Decryption 43
7.1.1.2 Data Encryption. 47 7.2 Elements of the DES Privacy Protocol 43
7.1.1.3 Data Decryption 48 7.2.1. SNMPv3 Users 43
7.2 Elements of the DES Privacy Protocol 48 7.2.2. EngineID 44
7.2.1. SNMPv3 Users 48 7.2.3. SNMPv3 Messages Using this Privacy Protocol 44
7.2.2. EngineID 48 7.2.4 Input and Output of the DES Privacy Module 44
7.2.3. SNMPv3 Messages Using this Privacy Protocol 49 7.2.4.1 Input and Output when generating an SNMPv3 Message 44
7.2.4 Input and Output of the DES Privacy Module 49 7.2.4.2 Input and Output when receiving an SNMPv3 Message 45
7.2.4.1 Input and Output when generating an SNMPv3 Message 49 7.3 Elements of Procedure. 45
7.2.4.2 Input and Output when receiving an SNMPv3 Message 49 7.3.1 Processing an Outgoing Message 45
7.3 Elements of Procedure. 50 7.1.1.1). 45
7.3.1 Processing an Outgoing Message 50 7.3.2 Processing an Incoming Message 46
7.3.2 Processing an Incoming Message 51 8. Editor's Addresses 47
7.4 Definitions 53 9. Acknowledgements 47
8. Editor's Addresses 59 A.1. Engine Installation Parameters 53
9. Acknowledgements 59 A.2. Password to Key Algorithm 54
A.1. Engine Installation Parameters 65 A.3. Password to Key Sample 55
A.2. Password to Key Algorithm 67
A.3. Password to Key Sample 68
 End of changes. 254 change blocks. 
1474 lines changed or deleted 926 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/