Internet Draft User-Based Symmetric Security for SNMPv2 September 1995
User-Based Symmetric Security Protocols
for Version 2 of the
Simple Network Management Protocol (SNMPv2)
Fri Sep 08 1995
draft-various-snmpv2-sec-syn-01.txt
Tell U. Later
snmpv2@tis.com
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute working
documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference material
or to cite them other than as ``work in progress.''
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow
Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe),
ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
Expires February 1996 [Page 1]
Internet Draft User-Based Symmetric Security for SNMPv2 September 1995
running list of open issues
reference list
reference citations
acknowledgements
authors
author addresses
spell check
mib needs to be re-checked for rationality with the text
improve compliance/conformance statement for the protocols and mib
horizontal spacing / column alignment in the mib
Expires February 1996 [Page 2]
Internet Draft User-Based Symmetric Security for SNMPv2 September 1995
1. Introduction
A management system contains: several (potentially many) manageable
nodes, each with a processing entity, termed an agent, which has access
to management instrumentation; at least one management station; and, a
management protocol. The management protocol is used to convey
management information between the agents and management stations; and,
for manager-to-manager communications, between management stations.
Operations of the protocol are carried out under an administrative
framework which defines authentication, authorization, access control,
and privacy policies.
Management stations execute management applications which monitor and
control managed elements. Managed elements are devices such as hosts,
routers, terminal servers, etc., which are monitored and controlled via
access to their management information.
The Administrative Model for SNMPv2 document [@ref v2admin] defines a
framework and an administrative model which realizes effective
management in a variety of configurations and environments.
In the administrative model, there are provisions for multiple
authentication and privacy services (identified by the security protocol
identifier, sPI) to achieve various objectives. Each manager (including
a dual-role entity acting in a manager role) and each agent (including a
dual-role entity acting in an agent role) implements one or more of
these types of service.
Although many such types of authentication and privacy services might be
defined, it is the purpose of this document, User-Based Symmetric
Security Protocols for SNMPv2, to define three such services; one
service supporting neither authentication nor privacy (usecNoAuth(4)),
one service supporting authentication but not privacy (usecAuth(5)), and
another supporting both authentication and privacy (usecPriv(6)).
The model defined by the administrative framework also includes
provisions for access control. The enforcement of access rights
requires the means to identify the entity on whose behalf a request is
generated. That is, authentication is a functional prerequisite to
access control. The SNMPv2 security services described herein identify
an entity on whose behalf an SNMPv2 message is generated as a "user".
For the purpose of exposition, the original Internet-standard Network
Management Framework, as described in RFCs 1155, 1157, and 1212, is
termed the SNMP version 1 framework (SNMPv1). This document is a part
Expires February 1996 [Page 3]
Internet Draft User-Based Symmetric Security for SNMPv2 September 1995
of the current framework, termed the SNMP version 2 framework (SNMPv2).
Expires February 1996 [Page 4]
Internet Draft User-Based Symmetric Security for SNMPv2 September 1995
1.1. Threats
Several of the classical threats to network protocols are applicable to
the management problem and therefore would be applicable to any SNMPv2
security service. Other threats are not applicable to the management
problem. This section discusses principal threats, secondary threats,
and threats which are of lesser importance.
The principal threats against which the SNMPv2 security service
described herein should provide protection are:
Modification of Information
The modification threat is the danger that some unauthorized entity
may alter in-transit SNMPv2 messages generated on behalf of an
authorized user in such a way as to effect unauthorized management
operations, including falsifying the value of an object.
Masquerade
The masquerade threat is the danger that management operations not
authorized for some user may be attempted by assuming the identity
of another user that has the appropriate authorizations.
Two secondary threats are also identified. The security protocols
defined in this memo do provide protection against:
Message Stream Modification
The SNMPv2 protocol is typically based upon a connectionless
transport service which may operate over any subnetwork service.
The re-ordering, delay or replay of messages can and does occur
through the natural operation of many such subnetwork services.
The message stream modification threat is the danger that messages
may be maliciously re-ordered, delayed or replayed to an extent
which is greater than can occur through the natural operation of a
subnetwork service, in order to effect unauthorized management
operations.
Disclosure
The disclosure threat is the danger of eavesdropping on the SNMPv2
messages as they are transmitted through the network. Protecting
against this threat may be required as a matter of local policy.
There are at least two threats that an SNMPv2 security protocol need not
protect against. The security protocols defined in this memo do not
provide protection against:
Expires February 1996 [Page 5]
Internet Draft User-Based Symmetric Security for SNMPv2 September 1995
Denial of Service
An SNMPv2 security protocol need not attempt to address the broad
range of attacks by which service on behalf of authorized users is
denied. Indeed, such denial-of-service attacks are in many cases
indistinguishable from the type of network failures with which any
viable management protocol must cope as a matter of course.
Traffic Analysis
In addition, an SNMPv2 security protocol need not attempt to
address traffic analysis attacks. Indeed, many traffic patterns
are predictable - agents may be managed on a regular basis by a
relatively small number of management stations - and therefore
there is no significant advantage afforded by protecting against
traffic analysis.
1.2. Goals and Constraints
Based on the foregoing account of threats in the SNMP management
environment, the goals of the SNMPv2 security protocols described herein
are enumerated as follows.
(1) The protocol should provide for verification that each received
SNMPv2 message has not been modified during its transmission
through the network in such a way that an unauthorized management
operation might result.
(2) The protocol should provide for verification of the identity of the
user on whose behalf a received SNMPv2 message claims to have been
generated.
(3) The protocol should provide for detection of received SNMPv2
messages whose time of generation was not recent.
(4) The protocol should provide, when necessary, that the contents of
each received SNMPv2 message are protected from disclosure.
In addition to the principal goal of supporting secure management, the
design of any SNMPv2 security protocol is also influenced by the
following constraints:
(1) When the requirements of effective management in times of network
stress are inconsistent with those of security, the design should
prefer the former.
Expires February 1996 [Page 6]
Internet Draft User-Based Symmetric Security for SNMPv2 September 1995
(2) Neither the security protocol nor its underlying security
mechanisms should depend upon the ready availability of other
network services (e.g., Network Time Protocol (NTP) or the Domain
Name System (DNS).
(3) A security mechanism should entail no changes to the basic SNMP
management philosophy.
1.3. Security Services
The security services necessary to support the goals of an SNMPv2
security protocol are as follows.
Data Integrity
is the provision of the property that data have not been altered or
destroyed in an unauthorized manner, nor have data sequences been
altered to an extent greater than can occur non-maliciously.
Data Origin Authentication
is the provision of the property that the claimed identity of the
user on whose behalf received data was originated is corroborated.
Data Confidentiality
is the provision of the property that information is not made
available or disclosed to unauthorized individuals, entities, or
processes.
For the protocols specified in this memo, it is not possible to
ascertain the specific originator of a received SNMPv2 message; rather,
it is the user on whose behalf the message was originated that is
authenticated.
For these protocols, it is not possible to obtain data integrity without
data origin authentication, nor is it possible to obtain data origin
authentication without data integrity.
Further, there is no provision for data confidentiality without both
data integrity and data origin authentication.
The security protocols used in this memo are considered acceptably
secure at the time of writing. However, the design of the
administrative model allows the security protocols described in this
memo to be replaced or supplemented with additional security protocols
to be specified at a future time if the need arises.
Expires February 1996 [Page 7]
Internet Draft User-Based Symmetric Security for SNMPv2 September 1995
1.4. Mechanisms
The security protocols defined in this memo employ several types of
mechanisms in order to realize the goals and security services described
above:
- Data Integrity: A message digest algorithm is utilized in support
of data integrity. A digest is calculated over an appropriate
portion of an SNMPv2 message and included as part of the message
sent to the recipient.
- Data Origin Authentication: A secret value is inserted into the
SNMPv2 message prior to computing the digest and then overwritten
prior to transmission in support of data origin authentication and
data integrity. The secret value is shared by all SNMPv2 entities
authorized to originate messages on behalf of the appropriate user.
- Replay Protection: To protect against the threat of message delay
or replay, (to an extent greater than can occur through normal
operation), a set of time indicators is included in each message
generated. A recipient evaluates the time indicators to determine
if the message is recent. This protection against the threat of
message delay or replay does not imply nor provide any protection
against unauthorized deletion or suppression of messages. Other
mechanisms defined independently of the security protocol can also
be used to detect message replay (e.g., the request-id [@ref
protoops]), or for set operations, the re-ordering, replay,
deletion, or suppression of messages (e.g., the MIB variable
snmpSetSerialNo [@ref v2mib4v2]).
- Data Confidentiality: A symmetric encryption algorithm is utilized
in support of data confidentiality. An appropriate portion of the
message is encrypted prior to being transmitted.
Expires February 1996 [Page 8]
Internet Draft User-Based Symmetric Security for SNMPv2 September 1995
1.4.1. Digest Authentication Protocol
The Digest Authentication Protocol utilizes a message digest algorithm
in conjunction with loosely synchronized monotonically increasing time
indicators as mechanisms to address the goals of data origin
authentication, data integrity, and message delay or replay.
The Digest Authentication Protocol defined in this memo provides several
functions. These include:
- Verifying the integrity of a received message (i.e., the message
was not modified during transit).
The integrity of the message is protected by computing a digest
over an appropriate portion of a message. The digest is computed
by the originator of the message, transmitted with the message, and
verified by the recipient of the message.
The nature of the digest computation is such that undetected
alteration of a message is computationally infeasible without
knowledge of secret values.
- Verifying the user on whose behalf the message was generated.
A secret value known only to SNMPv2 entities authorized to generate
messages on behalf of this user is inserted into the message prior
to the digest computation. Thus, the verification of the user is
implicit with the verification of the digest.
- Verifying that a message sent to/from one agent or manager cannot
be replayed to/as-if-from another agent or manager.
Included in each message is an identifier which is unique to the
protocol engine of the SNMPv2 protocol entity which is the sender
or intended recipient of the message.
- Detecting messages which were not recently generated.
A set of time indicators are included in the message, indicating
the time of generation. Messages without recent time indicators
are not considered authentic.
This protocol uses the MD5 [@ref md5] message digest algorithm. A 128-
bit digest is calculated over the designated portion of an SNMPv2
message and included as part of the message sent to the recipient. The
Expires February 1996 [Page 9]
Internet Draft User-Based Symmetric Security for SNMPv2 September 1995
size of both the digest carried in a message and the private
authentication key is 16 octets.
This memo allows the same user to be defined on multiple SNMPv2 agents
and managers. Every SNMPv2 protocol entity maintains a value, snmpID,
which uniquely and unambiguously identifies the protocol engine. Each
SNMPv2 protocol entity which implements the usecNoAuth(4), usecAuth(5),
or usecPriv(6) authentication and privacy services maintains a value,
authSnmpID, which uniquely and unambiguously identifies the
usecNoAuth(4), usecAuth(5), and usecPriv(6) protocol engine of the
SNMPv2 protocol entity. The authSnmpID is equal to the snmpID of the
protocol entity. For example, each SNMPv2 protocol entity, whether it
acts in an agent role, a manager role, or some combined role, has a
snmpID, which is used as the authSnmpID for messages to or from that
entity that are based on its authoritative authentication information.
For traffic to or from an SNMPv2 agent, the value of snmpID for the
agent is assigned to authSnmpID in each authenticated message sent
to/from the agent. (See [@ref proxyops] for special rules for proxy
agents in this regard.) On receipt of a message, an agent checks the
value to ensure it is the intended recipient, and a manager uses the
value to ensure that the message is processed using the correct state
information for that agent. Similar mechanisms are used for traffic
between two entities with each acting in a manager role.
Each SNMPv2 protocol entity which implements the usecAuth(5)
authentication service or the usecPriv(6) authentication and privacy
service maintains two additional values, authSnmpBoots and authSnmpTime,
which together provide an indication of time at that entity. For
example, an SNMPv2 agent maintains both of these values which, when
taken together, provide an indication of time at that agent. Both of
these values are included in authenticated messages sent to/received
from that agent. (See [@ref proxyops] for special rules for proxy agents
in this regard.) On receipt, the values are checked to ensure that the
indicated time is within a time window of the current time. The time
window represents an administrative upper bound on acceptable delivery
delay for protocol messages. Similar mechanisms are used for traffic
between two entities with each acting in a manager role.
Every SNMP transaction is between two protocol entities. Because both
entities base their security algorithms on information known to them in
their local databases, conflict could arise if those databases are not
consistent. Therefore it is useful to resolve conflicts by explicitly
identifying one particular database that is correct by definition. An
SNMPv2 entity is considered the authoritative source of information, or
simply authoritative, for information that it maintains in its
Expires February 1996 [Page 10]
Internet Draft User-Based Symmetric Security for SNMPv2 September 1995
configuration store. Every SNMPv2 message is sent with either the
receiver or sender identified as the authoritative source of information
upon which that message is based. The non-authoritative participant in
any transaction will maintain a database containing the authoritative
information for each peer SNMPv2 entity it knows about. When processing
a communication, the non-authoritative entity finds that it doesn't have
required information about the authoritative entity or that its
information is incorrect, it is the responsibility of the non-
authoritative entity to acquire the correct information.
Every SNMPv2 protocol entity which implements the usecAuth(5) or
usecPriv(6) authentication and privacy services maintains values of
authSnmpID, authSnmpBoots, and authSnmpTime and is authoritative for
those values. Every SNMPv2 message which uses the usecNoAuth(4),
usecAuth(5), or usecPriv(6) services contains a authSnmpID value which
identifies the snmpID of the entity that is authoritative for that
message.
When using the authentication and privacy services specified in this
memo, time synchronization must be achieved in order for an exchange
between two SNMPv2 protocol entities (i.e., a transaction between a
manager and an agent, two managers, a manager and a proxy agent, two
proxy agents, or a proxy agent and a manager), to be determined to be
timely and authentic according to the usecAuth(5) or usecPriv(6)
services. [In the case of a multi-hop relationship, (e.g., manager,
proxy agent, agent or manager, proxy agent, manager, etc) then the time
synchronization is achieved between the endpoints on a hop-by-hop
basis.] In order to achieve this time synchronization, the non-
authoritative entity must update its notion of the authoritative
entity's time. For example, for an SNMPv2 manager to generate a message
which an agent will accept as authentic, and to verify that a message
received from an agent is authentic, that manager must first achieve
time synchronization with that agent.
This memo specifies that the usecAuth(5) and usecPriv(6) authentication
services use secret keys of length 16 octets in conjunction with that
algorithm.
Within an authenticated management communication generated by such these
services, the size of the authDigest value of that communication (see
Section 2.1) is 16 octets.
Expires February 1996 [Page 11]
Internet Draft User-Based Symmetric Security for SNMPv2 September 1995
1.4.2. Symmetric Encryption Protocol
In support of data confidentiality, the use of the Data Encryption
Standard (DES) in the Cipher Block Chaining mode of operation is chosen.
The designated portion of an SNMPv2 message is encrypted and included as
part of the message sent to the recipient.
Two organizations have published specifications defining the DES: the
National Institute of Standards and Technology (NIST) [@ref des] and the
American National Standards Institute [@ref dea]. There is a companion
Modes of Operation specification for each definition (see [@ref desmoo]
and [@ref deamoo], respectively).
The NIST has published three additional documents that implementors may
find useful.
- There is a document with guidelines for implementing and using the
DES, including functional specifications for the DES and its modes
of operation [@ref desguidelines].
- There is a specification of a validation test suite for the DES
[@ref desvalidating]. The suite is designed to test all aspects of
the DES and is useful for pinpointing specific problems.
- There is a specification of a maintenance test for the DES [@ref
desmaintest]. The test utilizes a minimal amount of data and
processing to test all components of the DES. It provides a simple
yes-or-no indication of correct operation and is useful to run as
part of an initialization step, e.g., when a computer reboots.
This memo specifies that the usecPriv(6) authentication and privacy
services use secret keys of length 16 octets, of which the first eight
octets are a DES key and the second eight octets are a DES
Initialization Vector. The 64-bit DES key in the first eight octets of
the private key is a 56 bit quantity used directly by the algorithm plus
eight parity bits - arranged so that one parity bit is the least
significant bit of each octet. The setting of the parity bits is
ignored.
The length of the octet sequence to be encrypted by the DES must be an
integral multiple of eight.
When encrypting, the data should be padded at the end as necessary; the
actual pad value is irrelevant. However, an implementation should take
care to avoid accidental disclosure of information through the inclusion
Expires February 1996 [Page 12]
Internet Draft User-Based Symmetric Security for SNMPv2 September 1995
of uninitialized pad values. Consequently, it is suggested that
implementations initialize the padded values to a constant value; zero
is recommended as an obvious choice.
As described in the Elements of Procedure, if the length of the octet
sequence to be decrypted is not an integral multiple of eight octets,
the processing of the octet sequence is halted and an appropriate
exception noted. Upon decrypting, the padding should be ignored.
Expires February 1996 [Page 13]
Internet Draft User-Based Symmetric Security for SNMPv2 September 1995
2. Elements of the Service
This section contains definitions required to realize the authentication
and privacy services defined by this memo.
2.1. SNMPv2 Users
Management operations using this security model make use of a defined
set of user identities. For any SNMPv2 user on whose behalf management
operations are authorized at a particular SNMPv2 agent, that agent must
have knowledge of that user. A SNMPv2 manager that wishes to
communicate with a particular agent must also have knowledge of a user
known to that agent, including knowledge of the applicable attributes of
that user.
A user and its attributes are defined as follows:
<userName>
An octet string representing the name of the user.
<groupName>
The name of the set of access rights assigned to this user.
<authPrivateKey>
The user's (private) authentication key if the usecAuth(5) or
usecPriv(6) services are provided and messages sent on behalf of
this user can be authenticated. Note that a user's authentication
key may be different at different SNMPv2 entities, e.g., managers
and agents.
<privPrivateKey>
The user's (private) privacy key if the usecPriv(6) service is
provided and messages sent on behalf of this user can be protected
from disclosure. Note that a user's privacy key may be different
at different agents.
All users are capable of having messages without authentication and
privacy generated on their behalf. Users having an authentication key
can have messages with authentication but not privacy generated on their
behalf. Users having an authentication key and a privacy key can have
messages with authentication and privacy generated on their behalf.
Authoritative SNMPv2 protocol entities must retain the attributes above
for all users in non-volatile storage.
Expires February 1996 [Page 14]
Internet Draft User-Based Symmetric Security for SNMPv2 September 1995
2.2. Values of sPI
This memo defines authentication and privacy services associated with
three values of sPI, as follows:
o 4 usecNoAuth
o 5 usecAuth
o 6 usecPriv
Other values of sPI are allocated as specified in [@ref v2admin].
An implementation may choose to implement the usecNoAuth(4) service,
both the usecNoAuth(4) and usecAuth(5) services, or all three services
(usecNoAuth(4), usecAuth(5), and usecPriv(6)). No other combinations
are valid, i.e., usecNoAuth(4) is a prerequisite for usecAuth(5), and
usecAuth(5) is a prerequisite for usecPriv(6).
2.3. Replay Protection
Each SNMPv2 protocol entity, i.e., each manager and each agent, which
implements the usecAuth(5) or usecPriv(6) services, maintains three
objects in support of replay protection:
- snmpID, which, among other uses, is used to identify an SNMP
protocol entity as authoritative for a transaction,
- authSnmpBoots, which is a count of the number of times the SNMPv2
protocol entity has rebooted/re-initialized since authSnmpID was
last configured; and,
- authSnmpTime, which is the number of seconds since authSnmpBoots
was last incremented.
SNMPv2 entities are always authoritative with respect to their own
values of these variables. They may also have non-authoritative notions
of these values for other SNMPv2 entities. Note that an entity will
have exactly one instance of the values it is authoritative for, but may
have many instances of these values for non-authoritative peers.
These non-authoritative notions must be synchronized with the
authoritative values from time-to-time as described in a later section.
Expires February 1996 [Page 15]
Internet Draft User-Based Symmetric Security for SNMPv2 September 1995
A SNMPv2 protocol entity is required to maintain the value of snmpID and
authSnmpBoots in non-volatile storage. These are critical components of
the overall security of the authentication protocol. The SNMPv2 entity
must be able to ensure that on each bootup, that authSnmpBoots is larger
than it ever was previously.
2.3.1. snmpID
The snmpID value contained in an authenticated message is used to defeat
attacks in which messages from one SNMPv2 protocol entity are replayed
as if from a different SNMPv2 protocol entity. Examples include attacks
in which messages from a manager are replayed to a different agent
and/or messages from one agent are replayed as if from a different
agent.
When a SNMPv2 protocol entity is first installed, it sets its local
value of snmpID according to a enterprise-specific algorithm (see the
definition of snmpID in Section 4.1).
2.3.2. authSnmpBoots and authSnmpTime
The authSnmpBoots and authSnmpTime values contained in an authenticated
message are used to defeat attacks in which messages from a manager are
replayed to the same destination at a time when they are no longer
valid. Through use of authSnmpBoots and authSnmpTime, there is no
requirement for an SNMPv2 protocol entity to have a non-volatile clock
which ticks (i.e., increases with the passage of time) even when the
SNMPv2 protocol entity is powered off. Rather, each time an SNMPv2
protocol entity reboots, it retrieves, increments, and then stores
authSnmpBoots in non-volatile storage, and resets authSnmpTime to zero.
When an SNMPv2 protocol entity is first installed, it sets its local
values of authSnmpBoots and authSnmpTime to zero. If authSnmpTime ever
reaches its maximum value (2147483647), then authSnmpBoots is
incremented as if the SNMPv2 protocol entity has rebooted and
authSnmpTime is reset to zero and starts incrementing again.
Each time an SNMPv2 protocol entity reboots, any SNMPv2 managers holding
that entity's values of authSnmpBoots and authSnmpTime need to re-
synchronize prior to sending correctly authenticated messages to that
entity.
If an SNMPv2 protocol entity is ever unable to determine its latest
authSnmpBoots value, then it must set its authSnmpBoots value to
0xffffffff.
Expires February 1996 [Page 16]
Internet Draft User-Based Symmetric Security for SNMPv2 September 1995
Whenever the local value of authSnmpBoots has the value 0xffffffff, it
latches at that value and an authenticated message always causes an |
usecStatsNotInTimeWindows |
authentication failure.
In order to reset an SNMPv2 protocol entity whose authSnmpBoots value
has reached the value 0xffffffff, manual intervention is required. The
SNMPv2 protocol entity must be physically visited and re-configured,
either with a new snmpID value, or with new secret values for the
authentication and privacy keys of all users known to that SNMPv2
protocol entity.
2.3.3. Time Window
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 specifies
that the same value of the Time Window, 150 seconds, is used for all
users.
2.3.4. Error Reporting
While processing a received communication, an SNMPv2 authentication and
privacy service may determine that the message is unacceptable. In this
case, the appropriate counter in the usecBasicGroup object group of the
MIB module contained in this memo is incremented and the requester is
advised that the message is unauthentic.
If an SNMPv2 protocol entity makes such a determination, and if the
reportableFlag is set, then after incrementing the appropriate counter,
it is sometimes specified in the elements of procedure that a report PDU
should be generated and sent to the transport address which originated
the received message.
A message containing a report PDU must always be sent with the
reportableFlag clear in the security flags. The report PDU sent from
the authentication and privacy services defined in this memo are always
sent using an sPI value of maint(3) except for the situation in which |
the incremented counter was usecStatsNotInTimeWindows, in which |
case the report PDU is always sent using usecAuth(5).
If the entity is able to determine the request-id field of the received
PDU, then it uses that value for the request-id field of the report PDU.
Otherwise, the value 2147483647 is used.
Expires February 1996 [Page 17]
Internet Draft User-Based Symmetric Security for SNMPv2 September 1995
The error-status and error-index fields of the report PDU are always set
to zero.
The variable-bindings field contains a single variable: the identity of
the statistics counter which was incremented and its new value.
A report PDU is never sent in response to a report PDU. A protocol
entity makes this determination by examining the reportableFlag of the
received message and only sending report PDUs when the reportableFlag is
set.
Several additional parameters must be provided to the protocol engine to
send the reports.
For reports which are sent with an sPI value of maint(3), the
identityName (and thereby the userName) is "report".
For reports which are sent from the authentication and privacy
services defined in this memo with an sPI value of usecAuth(5), the
userName is set to be the same as the userName in the received
message which invoked the report operation. The secret
authentication key associated with that user is used in the
generation of the authenticated message.
In either case, the authSnmpID and contextSnmpID are set to the
value of snmpID for the local (generating) SNMPv2 protocol entity.
The contextName is set to "default".
The message containing the report is then processed in accordance with
the procedures specified in the section entitled "Generating an
SnmpV2AuthMessage Component", serialized as an SnmpV2Message with the
reportableFlag portion of the security flags field set to false, and the
sent to the source of the original received message according to the
procedures specified in [@ref v2admin].
2.3.5. Time Synchronization
An SNMPv2 entity always has correct time synchronization for those
transactions for which it is authoritative.
When an SNMPv2 entity is non-authoritative for an authenticated
transaction, it must achieve time synchronization with its peer. First,
if it has no notion of the authSnmpBoots and authSnmpTime value for its
peer, it must initialize both of these values to zero. Then, in any
Expires February 1996 [Page 18]
Internet Draft User-Based Symmetric Security for SNMPv2 September 1995
case, it sends the transaction as it would normally. If the transaction
is authenticated (either usecAuth(5) or usecPriv(6)) and otherwise
correct but the time is not synchronized, the peer will reply with a
message containing a reportPDU which is authenticated with usecAuth(5)
using the userName of the request packet. The message conveying the
report PDU contains the correct values of authSnmpBoots and
authSnmpTime. The receiving protocol engine will update its values of
authSnmpBoots and authSnmpTime for that entity if and only if the report
PDU was authenticated and contained the correct digest value (but wasn't
necessarily within the lifetime).
Note that this mechanism can synchronize any SNMPv2 entity, independent
of the existence of an agent at either end of the transaction.
2.3.5.1. Time Synchronization for Traps
Because traps are not sent in a request-response fashion, another
mechanism is required. Traps are sent from an agent, which is
authoritative, to a manager. The recommended mechanism for the manager
to synchronize time with the agent is to initiate a usecAuth(5)
request-response transaction with the agent (a usecAuth(5) Get request
of any arbitrary variable is appropriate). This transaction can be
executed periodically to keep the timers up to date, or in response to a
received trap that was out of lifetime. In the latter case,
authentication processing of the trap can be deferred and repeated when
the time is resynchronized.
2.4. Local Configuration Datastore (LCD)
Each SNMPv2 protocol entity maintains a local conceptual database,
called the Local Configuration Datastore (LCD), which holds its known
set of information about SNMPv2 users and other associated (e.g., access
control) information.
It is a local implementation issue as to whether information in the LCD
is stored information or whether it is obtained dynamically (e.g., as a
part of an SNMPv2 manager's API) on an as-needed basis.
2.5. SnmpV2AuthMessage Format
Each authentication and privacy service must define the AuthInfo
sequence associated with the service. All three services defined in
this memo, e.g., usecNoAuth(4), usecAuth(5), and usecPriv(6), use the
same format, which is summarized in Figure 1.
Expires February 1996 [Page 19]
Internet Draft User-Based Symmetric Security for SNMPv2 September 1995
| <---------------------- SnmpV2AuthMessage ----------------------> | |
| authInfo | ContextInfo | PDU | |
+---------------------------------+-------------+-------------------+ |
| s | | u | S | S | | | | s p | | |
| e | s | s | n | n | D | c S | c | e d | | |
| q | a n | e | a m | a m | a i | o n | o n | q u | | |
| = | u m | r | u p | u p | u g | n m | n a | = | | P | |
| 0 | t p | N | t B | t T | t e | t p | t m | t | D | |
| a | h I | a | h o | h i | h s | e I | e e | y | U | |
| 9 | D | m | o | m | t | x D | x | p | | |
| h | | e | t | e | | t | t | e | | |
| | | | s | | | | | | | |
+---------------------------------+-------------+-------------------+ |
Figure 1: Usec-based SnmpV2AuthMessage Format
2.6. ASN.1 Definition of SnmpV2AuthMessage Members
The formal ASN.1 definition for the members of a Usec-based |
SnmpV2AuthMessage are as follows: |
SnmpV2AuthMessage ::= [9] IMPLICIT SEQUENCE { |
authInfo |
AuthInfo, |
contextSnmpID |
OCTET STRING (SIZE(12)), |
contextName |
OCTET STRING, |
pdu |
PlainOrEncryptedPDU |
} |
AuthInfo ::= [9] IMPLICIT SEQUENCE { +
authSnmpID
OCTET STRING (SIZE(12)),
userName -
OCTET STRING (SIZE(1..32)),
authSnmpBoots -
Integer32 (0..2147483647),
authSnmpTime -
Integer32 (0..2147483647),
authDigest -
OCTET STRING (SIZE(0|16))
Expires February 1996 [Page 20]
Internet Draft User-Based Symmetric Security for SNMPv2 September 1995
}
PlainOrEncryptedPDU ::= CHOICE { +
plaintext +
PDUs, +
encrypted +
OCTET STRING +
} +
This same format is used by all three authentication and privacy
services defined in this memo, e.g., usecNoAuth(4), usecAuth(5), and
usecPriv(6).
Expires February 1996 [Page 21]
Internet Draft User-Based Symmetric Security for SNMPv2 September 1995
3. Elements of Procedure
These procedures, which provide the usecNoAuth(4), usecAuth(5), and
usecPriv(6) authentication and privacy services, are invoked on behalf
of a user. There are two basic sets of procedures: generating an
SnmpV2AuthMessage component from parameters provided by a requester, and
processing a received SnmpV2AuthMessage component.
3.1. Generating an SnmpV2AuthMessage Component
This section describes the procedure followed by the authentication and
privacy service whenever it is requested by an application to generate
an SnmpV2AuthMessage component with a sPI value corresponding to
usecNoAuth(4), usecAuth(5), or usecPriv(6) on behalf of a user. The
requester must provide the following parameters:
- sPI, corresponding to any one of usecNoAuth(4), usecAuth(5), or
usecPriv(6), a definitive identification of the type of
authentication and privacy service requested;
- identityName;
- authSnmpID, unique identification of an instance of the
administrative model, i.e., an SNMPv2 protocol engine; and
- a contextSnmpID and a contextName, specifying the context in which |
the data contained in the PDU is contained; and |
- a PDU message component. |
Upon completion of the required processing, the service provides an
SnmpV2AuthMessage value.
The basic approach is that the SnmpV2AuthMessage value is generated by
first privatizing the PDU, then adding context and authentication
information to the result.
The detailed steps are as follows.
(1) Information concerning the user is extracted from the userNameTable
in the LCD. If there is no such information, then the message
cannot be sent and the requesting application is suitably advised.
Note that the information may have been entered into the LCD by the
application shortly before the application requested the generation
of this SnmpV2AuthMessage component.
Expires February 1996 [Page 22]
Internet Draft User-Based Symmetric Security for SNMPv2 September 1995
If the sPI indicates that the message is to be authenticated, i.e.,
the value of sPI corresponds to usecAuth(5) or usecPriv(6), but the
authentication key is not configured or is not 16 octets in length,
then the message cannot be sent and the requesting application is
suitably advised. If the sPI indicates that the message is to be
authenticated and protected from disclosure i.e., the value of sPI
corresponds to usecPriv(6), but the privacy key is not configured,
then the message cannot be sent and the requesting application is
suitably advised.
(2) A PlainOrEncryptedPDU value [@ref v2admin] is serialized according
to the conventions of [@ref tm]:
if the sPI specifies that the message is to be protected from
disclosure, i.e., the value of sPI corresponds to usecPriv(6), then
the octet sequence representing the serialized PDUs value is
encrypted using the user's privacy key, and the encrypted string is
used as the value of the data component; and
if the sPI specifies that the message is not to be protected from
disclosure, i.e., the value of sPI corresponds to usecNoAuth(4) or
usecAuth(5), then the serialized PDUs value is used directly as the
value of the data component.
(3) The contextSnmpID and contextName values are serialized and |
prepended to the PlainOrEncryptedPDU value. |
(4) An AuthInfo value is constructed as follows. The userName is set
to the value of identityName provided by the requesting
application. The authSnmpID is set to the value provided by the
requesting application. If authentication is requested, i.e., the
value of sPI corresponds to either usecAuth(5) or usecPriv(6), then
- The LCD is consulted to retrieve the current value for
authSnmpBoots associated with the provided value of authSnmpID
and the retrieved value is assigned to authSnmpBoots. If the LCD
has no such value, then the value zero is assigned to
authSnmpBoots.
- The LCD is consulted to retrieve the current value for
authSnmpTime associated with the provided value of authSnmpID and
the retrieved value is assigned to authSnmpTime. If the LCD has
no such value, then the value zero is assigned to authSnmpTime.
- The LCD is consulted to retrieve the value of the authentication
Expires February 1996 [Page 23]
Internet Draft User-Based Symmetric Security for SNMPv2 September 1995
key associated with the userName and authSnmpID. The retrieved
value is temporarily assigned to the authDigest.
Otherwise, i.e., the value of sPI corresponds to usecNoAuth(4), the
values of authSnmpBoots, authSnmpTime, and authDigest are assigned
the values 0, 0, and the zero length OCTET STRING, respectively.
The AuthInfo value is serialized according to the conventions of
[@ref tm].
(5) The constructed SnmpV2AuthMessage value is serialized (i.e.,
encoded) according to the conventions of [@ref tm].
(6) If and only if authentication is requested, i.e., the sPI
corresponds to either usecAuth(5) or usecPriv(6), then an MD5
digest value is computed over the octet sequence representing the
serialized SnmpV2AuthMessage value including the outermost tag and
length fields of the encoded sequence. The portion of the
serialized SnmpV2AuthMessage corresponding to the authDigest value
is set to the result of the digest computation.
The SnmpV2AuthMessage resulting from these operations is then returned
from the authentication and privacy service to the requester.
Expires February 1996 [Page 24]
Internet Draft User-Based Symmetric Security for SNMPv2 September 1995
3.2. Processing a Received Communication
This section describes the procedure followed by the authentication and
privacy service whenever a requester provides an SnmpV2AuthMessage
component with a sPI value which corresponds to usecNoAuth(4),
usecAuth(5), or usecPriv(6) to be processed on behalf of a user.
The requester must provide the following parameters:
- an SnmpV2AuthMessage value as defined by [@ref v2admin]; and
- sPI, corresponding to any one of usecNoAuth(4), usecAuth(5), or
usecPriv(6), a definitive identification of the type of
authentication and privacy service requested.
Upon completion of the required processing, the service provides:
- an authSnmpID; +
- +
an identityName;
- a groupName;
- a contextSnmpID; |
- a contextName; |
- a plaintext PDU. |
The basic approach is that the SnmpV2AuthMessage is parsed, checked for
authenticity, if appropriate, and decrypted, if appropriate.
The detailed steps are as follows:
(1) If the received message is not the serialization (according to the
conventions of [@ref v2admin]) of an SnmpV2AuthMessage value, then |
the snmpInASNParseErrs counter [@ref v2mib4v2] is incremented, |
a Report PDU is generated, and the message is discarded without
further processing.
(2) The values of the individual fields are extracted from the AuthInfo
portion of the SnmpV2AuthMessage value, i.e., authSnmpID, userName,
authSnmpBoots, authSnmpTime, and authDigest.
Expires February 1996 [Page 25]
Internet Draft User-Based Symmetric Security for SNMPv2 September 1995
(3) Information about the user identified by the userName and
authSnmpID values is extracted from the LCD. If no such
information is available, then the usecStatsUnknownUserNames
counter is incremented, a report PDU is generated, and the
requester is advised that the message is not authentic. Otherwise,
the identityName is set to the userName, and the groupName is set
to the value extracted from the LCD associated with the user. The
value of userTransportLabel is extracted, if present. In addition,
values are extracted for the user's private authentication and
private privacy keys, if any.
(4) If the sPI value indicates that the message is not authenticated,
i.e., the value of sPI corresponds to usecNoAuth(4), then the
values of authSnmpBoots, authSnmpTime, and authDigest are ignored.
(5) The source address is then validated.
If the extracted value of userTransportLabel is zero octets in
length, or not present, which indicate that source address
validation is not desired or not implemented, then the source
address is considered valid.
If the userTransportLabel is non-null, the transportTable [@ref
adminmib] is consulted. All entries in the transport table
corresponding to the userTransportLabel are examined which match
the received transport domain. If, for any one or more entries,
the entry's transportAddress logically anded with the entry's
transportReceiveMask is equal to the source address of the message |
anded with the entry's transportReceiveMask, then the value of |
transportMMS is extracted, and the source address |
is considered valid.
Otherwise, the usecStatsUnknownUserNames counter is incremented, a
report PDU is generated, and the requester is advised that the
message is not authentic.
(6) If the sPI value indicates that the message is authenticated, i.e.,
the value of sPI corresponds to usecAuth(5) or usecPriv(6), then
the message is checked for authenticity:
- The received authDigest value is temporarily saved. A new
serialized SnmpV2AuthMessage is constructed which differs from
that received in exactly one respect: that the authDigest
field within it has the value of the user's authentication key
extracted from the LCD, above. If the length of the extracted
Expires February 1996 [Page 26]
Internet Draft User-Based Symmetric Security for SNMPv2 September 1995
authentication key is not exactly 16 octets, then the
usecStatsWrongDigestValues counter is incremented, a report PDU
is generated, and the requester is advised that the message is
not authentic.
NOTE
Because serialization rules are unambiguous but may not be
unique, great care must be taken in reconstructing the
serialized value prior to computing the digest.
Implementations may find it useful to keep a copy of the
original serialized value and then simply modify the
octets which directly correspond to the placement of the
authDigest component, rather than re-applying the
serialization algorithm to the new SnmpV2AuthMessage
value.
An MD5 digest value is computed over the octet sequence
representing the new serialized SnmpV2AuthMessage value, |
including the outermost tag |
and length fields of the encoded sequence.
If the computed digest differs from the saved authDigest value,
then the usecStatsWrongDigestValues counter is incremented, a
report PDU is generated, and the requester is advised that the
message is not authentic.
- The LCD is examined to extract local values for authSnmpBoots
and authSnmpTime which correspond to the received value of
authSnmpID. If the received value of authSnmpBoots is less
than the extracted value, or the received value of
authSnmpBoots is equal to the extracted value but the received
value of authSnmpTime is less than the extracted value by more
than 150 seconds, then the usecStatsNotInTimeWindows counter is |
incremented, |
a report PDU is generated, and the requester is advised that
the message is not authentic.
Note that this step allows for the received value of
authSnmpBoots to be greater than the local value of
authSnmpBoots. This allows for notifications to be accepted as
authentic when received from an agent that has rebooted since
the manager last re-synchronized.
- The LCD entry corresponding to the value of authSnmpID is
updated by setting the local values of authSnmpBoots and
Expires February 1996 [Page 27]
Internet Draft User-Based Symmetric Security for SNMPv2 September 1995
authSnmpTime to the received values, if the received values in
combination are greater than the local non-authoritative
values.
(7) The values of the contextSnmpID and contextName fields are +
extracted from the SnmpV2AuthMessage. +
(8) +
If the sPI value indicates that the message is protected from
disclosure, i.e., the value of sPI corresponds to usecPriv(6), then
the appropriate portion of the message is decrypted:
- The extracted value of the user's private privacy key is
examined. If the length of the extracted privacy key is not
exactly 16 octets, then the usecStatsBadPrivacys counter is
incremented, a report PDU is generated, and the requester is
advised that the message is not authentic.
- The PDU value is decrypted using the the extracted privacy key |
and a plaintext PDU value is produced. |
However, if the length of the octet sequence is not an integral
multiple of eight octets, then the usecStatsBadPrivacys counter
is incremented, a report PDU is generated, and the requester is
advised that the message is not authentic.
(9) The resulting authSnmpID, identityName, groupName, contextSnmpID, |
contextName, and plaintext PDU are delivered to the requester |
and the requester is advised that the message is authentic.
3.3. Discussion of Distribution of Secrets and Time Information
Every SNMP protocol engine which implements this specification will have
authoritative values of the following:
o authSnmpBoots, and
o authSnmpTime.
o a [possibly null] list of users and associated secrets
These authoritative values will be used by that protocol engine whenever
the protocol engine receives any of the following operations:
o Get,
Expires February 1996 [Page 28]
Internet Draft User-Based Symmetric Security for SNMPv2 September 1995
o GetNext,
o Set,
o GetBulk, and
o Inform.
That is, the protocol engine that sends these PDUs must know (or somehow
discover), and use, the values that are authoritative in the destination
protocol engine. Similarly, the protocol engine that receives these
operations, sends responses, and optionally sends traps, must use its
authoritative values when validating incoming messages or generating
outgoing messages.
Note that this means that authoritative information is stored on
managers that receive informs as well as on agents.
It is instructive to note the symmetry with the Report PDU in that the
Report PDU is only sent by a protocol engine when it is reporting that
it received information that was inconsistent with its authoritative
datastore.
Because time information and secrets are authoritative on only one of
the two protocol engines involved in an SNMP transaction, it is clear
that if both engines do not agree on the information, that the non-
authoritative engine is "wrong", and must then seek to conform to the
information in the authoritative engine. There is thus no inconsistency
when multiple managers are talking to an agent - they must all use the
correct time information and secret information for that agent.
A protocol engine has at most one record of authoritative information
for that protocol engine (note that not all protocol engines need
authoritative information, for example a manager that won't receive
informs). A protocol engine will also have one or more records of non-
authoritative information for any other protocol engines it will
communicate with, where each record is identified by the snmpID [@ref
adminmib] of the peer protocol engine.
The following sections describe how this information is to be created
and maintained in a consistent manner.
Expires February 1996 [Page 29]
Internet Draft User-Based Symmetric Security for SNMPv2 September 1995
3.3.1. Initial Configuration
Before any communication can begin, it is necessary for the
authoritative information to be configured on the protocol engine for
which it is authoritative. This configuration can be accomplished
through a local mechanism or through a MIB provided for this purpose
[@ref adminmib].
Configuration of non-authoritative information can be deferred until the
time of use. This is important because managers may be transient and
may not even exist when an agent is first configured. There are many
ways to defer the act of configuring of non-authoritative information
into a manager. One way that is possible for an interactive management
application is for it to prompt the human operator for the information
when it is required.
3.3.2. Secret Distribution
In order to allow for operational maintenance of users and secrets,
especially to maintain a high level of security, users need to be added
and deleted, and secrets need to be changed. All of these operations
must be able to be performed remotely.
The USEC MIB defines objects which may be used to add, delete, and
change secret information in both authoritative and non-authoritative
protocol engines. Because of the need for privacy when sending secrets
over the network and the non-ubiquity of encryption technology, secrets
are changed using the userAuthChange and userPrivChange MIB objects,
which encrypt a new secret with the previous value of the secret.
Two modes of secret maintenance deserve special attention. First, it is
possible for a management application to remotely configure a new user
into one or more agents and inform receivers around the network, as well
as to remotely configure the corresponding information into one or more
non-authoritative management stations.
A second mode is where the agents and inform receivers are configured
remotely and the user simply remembers his secret in the form of a
password so that he can supply it to any management station when he
requests service of that management station.
Note that this second mode is made more simple for the management
station and the user if the user has the same userName on all
authoritative systems, and if the user's secret is the same on many or
all of those systems. Of course, this means that more systems will be
Expires February 1996 [Page 30]
Internet Draft User-Based Symmetric Security for SNMPv2 September 1995
compromised by the disclosure of a single secret, but evaluation of the
risks due to this tradeoff is left to each operational environment to
determine in light of their local security policies.
3.3.3. Cloning
The preceding discussion described a mechanism for changing secrets in
private by encrypting the new secret with the old secret. Of course,
for a new user, there is no old secret, so cloning from a template is
introduced to create an initial entry for a user by cloning an entry for
another user whose password is known. The secret is then changed to a
different, unrelated value using the userAuthChange and userPrivChange
objects.
One prime candidate for the data to be cloned is the administrator's
entry, because the administrator's secret keys are known to the
administrator who does the cloning. However, in some operational
environments, it may be worthwhile to clone from a template which has
never been used for authenticated traffic on the network because the
conventional wisdom is that so doing reduces one's vulnerability to
certain kinds of attacks.
3.3.4. Additional Details
For the sake of clarity and to prevent the above procedure from being
even longer, the following details were omitted from the above
procedure.
3.3.4.1. ASN.1 Parsing Errors
For ASN.1 parsing errors, the snmpInASNParseErrs counter [@ref v2mib4v2] |
is incremented and a |
report PDU is generated whenever such an ASN.1 parsing error is
discovered.
3.3.4.2. Generation of a Report PDU
Some steps specify that the received message is discarded without
further processing whenever a report PDU is generated. However, there
are some restrictions on the generation of report PDUs.
First, a report PDU is never sent in response to a message without the
reportableFlag set in the security flags field. This means that reports
will never be sent in response to a Report PDU, to a Response PDU, or to
Expires February 1996 [Page 31]
Internet Draft User-Based Symmetric Security for SNMPv2 September 1995
a Trap PDU.
Second, a generated report PDU must, whenever possible, contain the same
request-id value as in the PDU contained in the received message.
Meeting these constraints normally requires the message to be further
processed just enough so as to extract its security flags (to derive the
reportableFlag) and request-id. Even in the case where the
SnmpV2AuthMessage is deemed unauthentic, an attempt must be made to
extract the SNMPv2 operation type and request-id by assuming the message
is not encrypted. With this assumption, the only situation in which the
SNMPv2 operation type and request-id cannot be extracted is when an
ASN.1 parsing error occurs. Note also that since the ASN.1 tag for an
encrypted PDU is not one of the valid PDU types, an ASN.1 parsing error
will always occur if the PDU is encrypted.
3.3.5. Changing A User's Secrets
An SNMPv2 manager uses the following procedure to change the
authentication secret configured for a user at a particular agent.
(1) The management station determines the value for the new secret and
generates an unpredictable value:
determine desired value for keyNew
randomValue = unpredictable()
It then computes the appropriate delta value using the following
algorithm (where the || symbol represents the concatenation operation):
iterations = (lenOfkeyNew - 1) / 16; /* integer division */
temp = keyOld;
for (i = 0; i < iterations; i++) {
temp = MD5 (temp || randomValue);
deltaValue[i*16 .. (i*16)+15] = temp XOR
keyNew[i*16 .. (i*16)+15];
}
temp = MD5 (temp || randomValue);
deltaValue[i*16 .. lenOfkeyNew-1] = temp XOR
keyNew[i*16 .. lenOfkeyNew-1];
(2) The management station initializes its knowledge of the current
state of the agent using an authenticated get operation, retrying
as necessary until a response is received:
get (
Expires February 1996 [Page 32]
Internet Draft User-Based Symmetric Security for SNMPv2 September 1995
lastLock = userSpinLock.0,
lastNovel = userNovel.<user>
)
(3) The management station generates a unique novel value (which must
be different from all previous values of lastNovel used with these
new secret values). It then concatenates the unpredictable and
delta values and conveys them to the agent in a single varbindlist,
together with the most recently retrieved value of the advisory
lock and the most recently generated unique novel value, using an
authenticated set operation with a previously unused value of
request-id.
set (
userSpinLock.0 = lastLock,
userAuthChange.<user> = <randomValue || deltaValue>,
userNovel.<user> = uniqueNovelValue
)
If a successful response with the correct request-id value is
received, then goto step 4.
If no response or an error response (with the correct request-id)
is received, then the operation may or may not have been
successful, due to duplication and/or loss of the request and/or
the response(s). So,
- save the error-index and error-status values,
- re-issue the get operation in step 2;
- retry this get operation as necessary until a response is
received,
- if this response indicates that userNovel has the unique
novel value assigned in the last set operation, goto step 4.
Otherwise, the set operation failed, and the saved error values are
inspected to determine the cause of the failure.
- if no response was received or the error-index indicates a
problem with userSpinLock, goto step 2.
- if the error-index indicates a problem with
userAuthChange or userNovel, the secret cannot be
changed to the new value.
Expires February 1996 [Page 33]
Internet Draft User-Based Symmetric Security for SNMPv2 September 1995
(4) Record the new secret values in stable storage. The operation is
now successfully completed.
[Retry counts to prevent endlessly looping in the presence of certain
failures were omitted from the above procedure in the interest of
brevity.]
Note that during the period of time after the request has been sent and
before the success of the operation is determined, the management
station must keep track of both the old and new secret values. Since
the delay may be the result of a network failure, the management station
must be prepared to retain both values for an extended period of time,
including across reboots.
A user's secret privacy key is changed using the same procedure except
that userPrivChange is used instead of userAuthChange.
Expires February 1996 [Page 34]
Internet Draft User-Based Symmetric Security for SNMPv2 September 1995
4. Definitions
USEC-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, Integer32, Counter32, UInteger32
FROM SNMPv2-SMI
RowStatus, TestAndIncr, RowPointer |
FROM SNMPv2-TC
KeyChange, MemoryType, TransportLabel, AuthName, SnmpID
FROM V2ADMIN-MIB
MODULE-COMPLIANCE, OBJECT-GROUP
FROM SNMPv2-CONF;
usecMIB MODULE-IDENTITY
LAST-UPDATED "9508121700"
ORGANIZATION "IETF SNMPv2 Working Group"
CONTACT-INFO "snmpv2@tis.com
Complete contact information to be provided."
DESCRIPTION
"The MIB module for configuring the USEC security and privacy
services."
::= { snmpModules xx }
--
-- The usecScalars group. This group contains objects which provide
-- time synchronization for the USEC authentication service.
--
usecScalars OBJECT IDENTIFIER ::= { usecMIB 1 }
snmpBoots OBJECT-TYPE
SYNTAX Integer32 (-1..2147483647)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of times the management system on a device has
been re-initialized since its initial configuration."
::= { usecScalars 1 }
snmpTime OBJECT-TYPE
SYNTAX Integer32 (0..2147483647)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
Expires February 1996 [Page 35]
Internet Draft User-Based Symmetric Security for SNMPv2 September 1995
"The number of seconds since the SNMPv2 protocol entity
last incremented the snmpBoots object."
::= { usecScalars 2 }
Expires February 1996 [Page 36]
Internet Draft User-Based Symmetric Security for SNMPv2 September 1995
--
-- The usecStats group. This group contains objects which provide |
-- statistics for the USEC security and privacy services.
--
usecStats OBJECT IDENTIFIER ::= { usecMIB 2 } |
usecStatsNotInTimeWindows OBJECT-TYPE |
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A count of the number of packets that were deemed
unauthentic due to the authSnmpBoots or authSnmpTime values
being out of lifetime."
::= { usecStats 1 } |
usecStatsUnknownUserNames OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A count of the number of packets containing an SPI
associated with usecNoAuth(4), usecAuth(5), or usecPriv(6),
but whose userNames were not found in the
userNameTable."
::= { usecStats 2 } |
usecStatsWrongDigestValues OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A count of the number of packets that were deemed
unauthentic due to the digest value being incorrect."
::= { usecStats 3 } |
usecStatsBadPrivacys OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A count of the number of packets received which were
encrypted incorrectly."
::= { usecStats 4 } |
Expires February 1996 [Page 37]
Internet Draft User-Based Symmetric Security for SNMPv2 September 1995
--
-- The usecUser group
--
usecUser OBJECT IDENTIFIER ::= { usecMIB 3 }
userSpinLock OBJECT-TYPE
SYNTAX TestAndIncr
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"An advisory lock used to allow several cooperating SNMPv2
entities, all acting in a manager role, to coordinate their
use of SNMPv2 set operations to entries in the userNameTable.
A manager application should include the value of
userSpinLock in every set operation which accesses the
userNameTable. Since this is an advisory lock, entities
acting in an agent role do not enforce the use of
userSpinLock."
::= { usecUser 1 }
maxUserNameLength OBJECT-TYPE
SYNTAX Integer32 (0..255)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The maximum length of userName allowed by this implementation.
This value can be probed by a management application prior
to attempting a row creation operation in the userNameTable.
A value of 0 indicates that the userNameTable does not allow
row creation or deletion operations."
::= { usecUser 2 }
--
-- The userNameTable contains the database of users who are configured to
-- perform SNMP communications via the Usec authentication and privacy service.
-- These users are organized into 'groups'.
-- The group to which a user belongs is specified in the userGroupName
-- object.
--
-- Access privileges are assigned in the acTable [@ref adminmib] by group.
-- This allows groups of users to share the same privileges, or for individual
-- users to have their own unique privileges.
--
-- In order to ease the task of configuring SNMPv2 entities, many of the
Expires February 1996 [Page 38]
Internet Draft User-Based Symmetric Security for SNMPv2 September 1995
-- indices used in the following table are textual (human-readable) strings.
-- Experience has shown that it is often necessary for a network administrator
-- to manually edit the configuration datastore for an SNMPv2 entities.
-- Use of textual strings for indices makes the configuration datastore much
-- easier for an administrator to maintain.
-- An implementation may restrict the lengths of userName and userGroupName
-- entries to less than the maximum value.
-- The maxUserNameLength variable and maxGroupNameLength [@ref adminmib]
-- variables can be used to detect the maximum length of name strings
-- supported by a particular implementation.
userNameTable OBJECT-TYPE
SYNTAX SEQUENCE OF UserNameEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The SNMPv2 database for usecNoAuth(4), usecAuth(5), and
usecPriv(6) users."
::= { usecUser 3 }
userNameEntry OBJECT-TYPE
SYNTAX UserNameEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Information about a particular SNMPv2 user."
INDEX { userAuthSnmpID, IMPLIED userName }
::= { userNameTable 1 }
UserNameEntry ::= SEQUENCE {
userAuthSnmpID SnmpID,
userName AuthName,
userGroupName AuthName,
userAuthChange KeyChange,
userPrivChange KeyChange,
userNovel OCTET STRING,
userTransportLabel TransportLabel,
userCloneFrom RowPointer,
userMemoryType MemoryType,
userStatus RowStatus
}
userAuthSnmpID OBJECT-TYPE
SYNTAX SnmpID
MAX-ACCESS not-accessible
Expires February 1996 [Page 39]
Internet Draft User-Based Symmetric Security for SNMPv2 September 1995
STATUS current
DESCRIPTION
"The node's administratively-unique identifier.
In a simple agent, this value will always be equal to the
agent's snmpID object.
In a manager which does not send or receive inform requests,
this value will be equal to the snmpID object of the
agent with which this user can communicate.
In a manager which sends or receives inform requests, this
object will be equal to one of three things:
- The snmpID of the agent with which this user
can communicate.
- The snmpID of the manager's local protocol engine.
- The snmpID of a remote manager which this user
can send inform requests to or receive inform requests
from.
In a dual-role entity, this value will be some combination
of those specified for agents and managers above."
::= { userNameEntry 1 }
userName OBJECT-TYPE
SYNTAX AuthName (SIZE(1..32))
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This variable contains the textual name of a user."
::= { userNameEntry 2 }
userGroupName OBJECT-TYPE
SYNTAX AuthName (SIZE(0..32))
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This variable contains the textual name of the group to
which a user belongs."
::= { userNameEntry 3 }
userAuthChange OBJECT-TYPE
SYNTAX KeyChange
MAX-ACCESS read-create
STATUS current
Expires February 1996 [Page 40]
Internet Draft User-Based Symmetric Security for SNMPv2 September 1995
DESCRIPTION
"An object, which when modified, causes the user's secret
authentication key to be modified via a one-way function.
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 userCloneFrom."
DEFVAL { ''H } -- the empty string
::= { userNameEntry 4 }
userPrivChange OBJECT-TYPE
SYNTAX KeyChange
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"An object, which when modified, causes the user's secret
privacy key to be modified via a one-way function.
When creating a new user, it is a '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 userCloneFrom."
DEFVAL { ''H } -- the empty string
::= { userNameEntry 5 }
userNovel OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..20))
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object may be used by a manager as a part of its
procedure for altering secret information about a user.
By altering the value of an instance of this object in
the same SNMPv2 Set-Request used to update secret information,
a subsequent Get-Request can determine if the Set-Request
was successful in the event that no response to the
Set-Request is received.
When an instance of this object is created, its value is
initialized to a random value.
This object need not be stored in non-volatile storage and
should be initialized to an unpredictable value upon system
re-initialization."
Expires February 1996 [Page 41]
Internet Draft User-Based Symmetric Security for SNMPv2 September 1995
DEFVAL { ''H } -- the empty string
::= { userNameEntry 6 }
userTransportLabel OBJECT-TYPE
SYNTAX TransportLabel
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object specifies a set of transport endpoints from which
an agent will accept management requests. If a management
request generated by this user is received on a transport
endpoint other than the transport endpoints identified
by this object, the request is deemed unauthentic.
The transports identified by this object are specified in
the transportTable. Entries in the transportTable whose
transportLabel value are equal to this object are identified.
If the value of this object has zero-length, or if the
transportTable is not implemented, then transport endpoints
are not checked when authenticating messages generated
by this user."
DEFVAL { ''H } -- the empty string
::= { userNameEntry 7 }
userCloneFrom OBJECT-TYPE
SYNTAX RowPointer (SIZE(14..268)) |
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"An indication of the user to clone authentication and privacy
parameters from. When read, the value { 0 0 } is returned.
This object must be written exactly once, when the associated
instance of userStatus either does not exist or has the
value `notReady'. Subsequent set operations to this object
will succeed, but will not cause the agent to take any action.
When first written, the value identifies an instance of
a user, the cloning user, whose status column has the value
'active' or 'not in service'.
For implementations which support both authentication and
privacy, the authentication and privacy secrets of the cloning
user are copied to the corresponding authentication and
privacy secrets of the user being created.
Expires February 1996 [Page 42]
Internet Draft User-Based Symmetric Security for SNMPv2 September 1995
For implementations which support only authentication, the
authentication secret of the cloning user is copied to the
corresponding authentication secret of the user being created.
For implementations which support neither authentication nor
privacy, this object has no effect (and need not be
implemented)."
::= { userNameEntry 8 }
userMemoryType OBJECT-TYPE
SYNTAX MemoryType
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The storage type for this conceptual row in the userNameTable.
Conceptual rows having the value 'permanent' must allow
write-access at a minimum to:
userAuthChange and userNovel for users employing
authentication; and userPrivChange and userNovel
for users employing privacy.
Note that any user which employs authentication or privacy
must allow its secrets to be updated and thus
cannot be 'readOnly'."
::= { userNameEntry 9 }
userStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The status of this conceptual row in the userNameTable.
A user is not qualified for activation until instances of
all columns of its userNameEntry row have an appropriate
value. In particular, one or more management set operations
are required to configure the entry:
a value must be written to the user's userCloneFrom
object, and ... update of secrets
Until instances of all corresponding columns and secrets are
appropriately configured, the value of the corresponding
instance of the userStatus column is `notReady'."
Expires February 1996 [Page 43]
Internet Draft User-Based Symmetric Security for SNMPv2 September 1995
::= { userNameEntry 10 }
Expires February 1996 [Page 44]
Internet Draft User-Based Symmetric Security for SNMPv2 September 1995
-- conformance information
usecMIBConformance
OBJECT IDENTIFIER ::= { usecMIB 4 }
usecMIBCompliances
OBJECT IDENTIFIER ::= { usecMIBConformance 1 }
usecMIBGroups
OBJECT IDENTIFIER ::= { usecMIBConformance 2 }
-- compliance statements
usecMIBNoAuthCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for SNMPv2 entities which
implement the SNMPv2 USEC MIB with no authentication
or privacy protocols."
MODULE -- this module
MANDATORY-GROUPS { usecNoAuthGroup }
::= { usecMIBCompliances 1 }
usecMIBAuthCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for SNMPv2 entities which
implement the SNMPv2 USEC MIB with authentication and
no privacy protocols."
MODULE -- this module
MANDATORY-GROUPS { usecNoAuthGroup, usecAuthGroup }
OBJECT userAuthChange
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
::= { usecMIBCompliances 2 }
usecMIBPrivCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for SNMPv2 entities which
implement the SNMPv2 USEC MIB with both authentication
Expires February 1996 [Page 45]
Internet Draft User-Based Symmetric Security for SNMPv2 September 1995
and privacy protocols."
MODULE -- this module
MANDATORY-GROUPS { usecNoAuthGroup, usecAuthGroup, usecPrivGroup }
OBJECT userAuthChange
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT userPrivChange
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
::= { usecMIBCompliances 3 }
Expires February 1996 [Page 46]
Internet Draft User-Based Symmetric Security for SNMPv2 September 1995
-- units of conformance
usecNoAuthGroup OBJECT-GROUP
OBJECTS {
usecStatsNotInTimeWindows, |
usecStatsUnknownUserNames,
usecStatsWrongDigestValues,
usecStatsBadPrivacys,
userSpinLock,
userAuthSnmpID,
userName,
userGroupName,
userTransportLabel,
userCloneFrom,
userMemoryType,
userStatus
}
STATUS current
DESCRIPTION
"A collection of objects providing for configuration of an
SNMPv2 agent which implements the SNMPv2 User-based Security
Model."
::= { usecMIBGroups 1 }
usecAuthGroup OBJECT-GROUP
OBJECTS {
userAuthChange,
userNovel
}
STATUS current
DESCRIPTION
"A collection of objects providing for configuration of an
SNMPv2 agent which implements the SNMPv2 User-based Security
Model."
::= { usecMIBGroups 2 }
usecPrivGroup OBJECT-GROUP
OBJECTS {
userPrivChange
}
STATUS current
DESCRIPTION
"A collection of objects providing for configuration of an
SNMPv2 agent which implements the SNMPv2 User-based Security
Expires February 1996 [Page 47]
Internet Draft User-Based Symmetric Security for SNMPv2 September 1995
Model."
::= { usecMIBGroups 3 }
END
Expires February 1996 [Page 48]
Internet Draft User-Based Symmetric Security for SNMPv2 September 1995
5. Security Considerations
5.1. Recommended Practices
This section describes practices that contribute to the secure,
effective operation of the mechanisms defined in this memo.
- A management station must discard SNMPv2 responses for which
neither the request-id component nor the represented management
information corresponds to any currently outstanding request.
Although it would be typical for a management station to do this as
a matter of course, when using these security protocols it is
significant due to the possibility of message duplication
(malicious or otherwise).
- When sending state altering messages to a managed agent, a
management station can increase security by delaying sending
successive messages to the managed agent until a positive
acknowledgement is received for the previous message or until the
previous message expires.
No message ordering is imposed by the SNMPv2. Messages may be
received in any order relative to their time of generation and each
will be processed in the ordered received. Note that when an
authenticated message is sent to a managed agent, it will be valid
for a period of time of approximately 150 seconds under normal
circumstances, and is subject to replay during this period.
Indeed, a management station must cope with the loss and re-
ordering of messages resulting from anomalies in the network as a
matter of course.
However, a managed object, snmpSetSerialNo [@ref v2mib4v2], is
specifically defined for use with SNMPv2 set operations in order to
provide a mechanism to ensure the processing of SNMPv2 messages
occurs in a specific order.
- The frequency with which the secrets of an SNMPv2 user should be
changed is indirectly related to the frequency of their use.
Protecting the secrets from disclosure is critical to the overall
security of the protocols. Frequent use of a secret provides a
continued source of data that may be useful to a cryptanalyst in
exploiting known or perceived weaknesses in an algorithm. Frequent
Expires February 1996 [Page 49]
Internet Draft User-Based Symmetric Security for SNMPv2 September 1995
changes to the secret avoid this vulnerability.
Changing a secret after each use is generally regarded as the most
secure practice, but a significant amount of overhead may be
associated with that approach.
Note, too, in a local environment the threat of disclosure may be
less significant, and as such the changing of secrets may be less
frequent. However, when public data networks are the communication
paths, more caution is prudent.
5.2. Defining Users
The mechanisms defined in this document employ the notion of "users"
having access rights. How "users" are defined is subject to the
security policy of the network administration. For example, users could
be individuals (e.g., "joe" or "jane"), or a particular role (e.g.,
"operator" or "administrator"), or a combination (e.g., "joe-operator",
"jane-operator" or "joe-admin"). Furthermore, a "user" may be a logical
entity, such as a manager station application or set of manager station
applications, acting on behalf of a individual or role, or set of
individuals, or set of roles, including combinations.
Appendix A describes an algorithm for mapping a user "password" to a 16
octet value for use as either a user's authentication key or privacy key
(or both). Passwords are often generated, remembered, and input by a
human. Human-generated passwords may be less than the 16 octets
required by the authentication and privacy protocols, and brute force
attacks can be quite easy on a relatively short ASCII character set.
Therefore, the algorithm is Appendix A performs a transformation on the
password. If the Appendix A algorithm is used, agent implementations
(and agent configuration applications) must ensure that passwords are at
least 8 characters in length.
Because the Appendix A algorithm uses such passwords (nearly) directly,
it is very important that they not be easily guessed. It is suggested
that they be composed of mixed-case alphanumeric and punctuation
characters that don't form words or phrases that might be found in a
dictionary. Longer passwords improve the security of the system. Users
may wish to input multiword phrases to make their password string longer
while ensuring that it is memorable.
Note that there is security risk in configuring the same "user" on
multiple systems where the same password is used on each system, since
Expires February 1996 [Page 50]
Internet Draft User-Based Symmetric Security for SNMPv2 September 1995
the compromise of that user's secrets on one system results in the
compromise of that user on all other systems having the same password.
There is also greater security risk and less accountability in allowing
multiple humans to know the password for a given "user".
Expires February 1996 [Page 51]
Internet Draft User-Based Symmetric Security for SNMPv2 September 1995
5.3. Conformance
To claim conformance to this memo, an SNMPv2 implementation:
- must implement the Digest Authentication Protocol. Otherwise, it is
termed an "insecure SNMPv2 implementation" -- one which adheres to
the SNMPv2 Administrative Framework but does not support secure
operations.
- must, to the maximal extent possible, prohibit access to the
secret(s) of each user about which it maintains information in a LCD,
under all circumstances except as required to generate and/or
validate SNMPv2 messages with respect to that user.
- must implement the SNMPv2 USEC MIB.
Implementation of the Symmetric Encryption Protocol is optional.
6. Acknowledgements
To be provided.
7. References
To be provided.
APPENDIX A - Agent Installation Parameters
During installation, an agent is configured with several parameters.
These include:
(1) a security posture
The choice of security posture determines the extent of the view
configured for unauthenticated access. One of three possible
choices is selected:
minimum-secure,
semi-secure, or
very-secure.
(2) one or more transport service addresses
These parameters may be specified explicitly, or they may be
Expires February 1996 [Page 52]
Internet Draft User-Based Symmetric Security for SNMPv2 September 1995
specified implicitly as the same set of network-layer addresses
configured for other uses by the device together with the well-
known transport-layer "port" information for the appropriate
transport domain [@ref tm]. The agent listens on each of these
transport service addresses for messages sent on behalf of any user
it knows about.
(3) one or more secrets
These are the authentication/privacy secrets for the first user to
be configured.
One way to accomplish this is to have the installer enter a
"password" for each required secret. The password is then
algorithmically converted into the required secret by: forming a
string of length 1,048,576 octets by repeating the value of the
password as often as necessary, truncating accordingly, and using
the resulting string as the input to the MD5 algorithm. The
resulting digest is the required secret (see Appendix B).
With these configured parameters, the agent instantiates the following
user, context, views and access rights. This configuration information
should be persistent.
- One user:
privacy not supported privacy supported
--------------------- -----------------
<userName> "public" "public"
<authPrivateKey> authentication key authentication key
<privPrivateKey> -- privacy key
-
One local context with its <contextSelector> as the string
"default".
- One view for authenticated access:
- the <all> MIB view is the "internet" subtree.
Expires February 1996 [Page 53]
Internet Draft User-Based Symmetric Security for SNMPv2 September 1995
- A second view for unauthenticated access. This view is configured
according to the selected security posture. For the "very-secure"
posture:
- the <restricted> MIB view is the union of the "snmp", |
"v2AdminStats", and "usecStats" subtrees. |
For the "semi-secure" posture:
- the <restricted> MIB view is the union of the "snmp", |
"v2AdminStats", |
"usecStats" and "system" subtrees.
For the "minimum-secure" posture:
- the <restricted> MIB view is the "internet" subtree.
- Access rights to allow:
- read-only access for unauthenticated messages on behalf of the
user "public" to the <restricted> MIB view of contextSelector
"default".
- read-write access for authenticated but not private messages
on behalf of the user "public" to the <all> MIB view of
contextSelector "default".
- if privacy is supported, read-write access for authenticated
and private messages on behalf of the user "public" to the
<all> MIB view of contextSelector "default".
Expires February 1996 [Page 54]
Internet Draft User-Based Symmetric Security for SNMPv2 September 1995
APPENDIX B - Password to Key Algorithm
The following code fragment demonstrates the password to key algorithm
which can be used when mapping a password to an authentication or
privacy key. (The calls to MD5 are as documented in RFC 1321.)
void password_to_key(password, passwordlen, key)
u_char *password; /* IN */
u_int passwordlen; /* IN */
u_char *key; /* OUT - caller supplies pointer to 16
octet buffer */ {
MD5_CTX MD;
u_char *cp, password_buf[64];
u_long password_index = 0;
u_long count = 0, i;
MD5Init (&MD); /* initialize MD5 */
/* loop until we've done 1 Megabyte */
while (count < 1048576) {
cp = password_buf;
for(i = 0; i < 64; i++) {
*cp++ = password[ password_index++ % passwordlen ];
/*
* Take the next byte of the password, wrapping to the
* beginning of the password as necessary.
*/
}
MDupdate (&MD, password_buf, 64);
count += 64;
}
MD5Final (key, &MD); /* tell MD5 we're done */
return; }
Expires February 1996 [Page 55]
Internet Draft User-Based Symmetric Security for SNMPv2 September 1995
Authors' Addresses
Tell U. Later
snmpv2@tis.com
others
To be provided.
Expires February 1996 [Page 56]
Internet Draft User-Based Symmetric Security for SNMPv2 September 1995
Table of Contents
1 Introduction .................................................... 3
1.1 Threats ....................................................... 5
1.2 Goals and Constraints ......................................... 6
1.3 Security Services ............................................. 7
1.4 Mechanisms .................................................... 8
1.4.1 Digest Authentication Protocol .............................. 9
1.4.2 Symmetric Encryption Protocol ............................... 12
2 Elements of the Service ......................................... 14
2.1 SNMPv2 Users .................................................. 14
2.2 Values of sPI ................................................. 15
2.3 Replay Protection ............................................. 15
2.3.1 snmpID ...................................................... 16
2.3.2 authSnmpBoots and authSnmpTime .............................. 16
2.3.3 Time Window ................................................. 17
2.3.4 Error Reporting ............................................. 17
2.3.5 Time Synchronization ........................................ 18
2.3.5.1 Time Synchronization for Traps ............................ 19
2.4 Local Configuration Datastore (LCD) ........................... 19
2.5 SnmpV2AuthMessage Format ...................................... 19
2.6 ASN.1 Definition of SnmpV2AuthMessage Members ................. 20
3 Elements of Procedure ........................................... 22
3.1 Generating an SnmpV2AuthMessage Component ..................... 22
3.2 Processing a Received Communication ........................... 25
3.3 Discussion of Distribution of Secrets and Time Information
.............................................................. 28
3.3.1 Initial Configuration ....................................... 30
3.3.2 Secret Distribution ......................................... 30
3.3.3 Cloning ..................................................... 31
3.3.4 Additional Details .......................................... 31
3.3.4.1 ASN.1 Parsing Errors ...................................... 31
3.3.4.2 Generation of a Report PDU ................................ 31
3.3.5 Changing A User's Secrets ................................... 32
4 Definitions ..................................................... 35
5 Security Considerations ......................................... 49
5.1 Recommended Practices ......................................... 49
5.2 Defining Users ................................................ 50
5.3 Conformance ................................................... 52
6 Acknowledgements ................................................ 52
7 References ...................................................... 52
Appendix A Agent Installation Parameters .......................... 52
Appendix B Password to Key Algorithm .............................. 55
Authors' Addresses ................................................ 56
Expires February 1996 [Page 57]
Internet Draft User-Based Symmetric Security for SNMPv2 September 1995
Expires February 1996 [Page 58]