value of latestReceivedAgentTime,
then the LCD entry corresponding to the value of the <agentID>
field is updated, by setting the local value of agentBoots
from the <agentBoots> field, the local value
latestReceivedAgentTime from the <agentTime> field, and the
local value of agentTime from the <agentTime> field.
(10) If the <qoS> field indicates use of a privacy protocol, then the
octet sequence representing the data component is decrypted
according to the user's privacy protocol to obtain a serialized
PDUs value. Otherwise the data component is assumed to directly
contain the PDUs value.
(11) The SNMPv2 operation type is determined from the ASN.1 tag value
associated with the PDUs component.
(12) If the SNMPv2 operation type is a Report, then the request-id in
the PDU is correlated to an outstanding request, and if the
correlation is successful, the appropriate action is taken (e.g.,
time synchronization, proxy error propagation, etc.); in
particular, if the report PDU indicates a usecStatsNotInWindows
condition, then the outstanding request may be retransmitted (since
the procedure in Step 9d above should have resulted in time
synchronization).
(13) If the SNMPv2 operation type is either a Get, GetNext, GetBulk, or
Set operation, then:
a) if the LCD information indicates that the SNMPv2 context is of
type remote or remote-proxy, then the
usecStatsUnauthorizedOperations counter is incremented, a report
PDU is generated, and the received message is discarded without
further processing.
b) the LCD is consulted for access rights authorized for
communications using the indicated qoS, on behalf of the
indicated user, and concerning management information in the
indicated SNMPv2 context for the particular SNMPv2 operation
type.
c) if the SNMPv2 operation type is not among the authorized access
rights, then the usecStatsUnauthorizedOperations counter is
incremented, a report PDU is generated, and the received message
is discarded without further processing.
d) The information extracted from the LCD concerning the user and
the SNMPv2 context, together with the sending transport address
of the received message is cached for later use in generating a
response message.
e) if the LCD information indicates the SNMPv2 context is of type
local, then the management operation represented by the PDUs
value is performed by the receiving SNMPv2 entity with respect
to the relevant MIB view within the SNMPv2 context according to
the procedures set forth in [12], where the relevant MIB view is
determined according to the user, the agentID, the
contextSelector, the qoS values and the type of operation
requested.
f) if the LCD information indicates the SNMPv2 context is of type
local-proxy, then:
i. the user, qoS, agentID, contextSelector and transport address
to be used to forward the request are extracted from the LCD.
If insufficient information concerning the user is currently
available, then snmpProxyDrops counter [15] is incremented, a
report PDU is generated, and the received message is
discarded.
ii. if an administrative flag in the LCD indicates that the
message is to be forwarded using the SNMPv1 administrative
framework, then the procedures described in [4] are invoked.
Otherwise, a new SNMPv2 message is constructed: its PDUs
component is copied from that in the received message except
that the contained request-id is replaced by a unique value
(this value will enable a subsequent response message to be
correlated with this request); the <userName>, <qoS>,
<agentID> and <contextSelector> fields are set to the values
extracted from the LCD; the <maxSize> field is set to the
minimum of the value in the received message and the local
system's maximum message size for the transport domain which
will be used to forward the message; and finally, the message
is authenticated and/or protected from disclosure according
to the qoS value.
iii. the information cached in Step 13d above is augmented with
the request-id of the received message as well as the
request-id, agentID and contextSelector of the constructed
message.
iv. the constructed message is forwarded to the extracted
transport address.
(14) If the SNMPv2 operation type is an Inform, then:
a) if the LCD information indicates the SNMPv2 context is of type
local or local-proxy then the usecStatsUnauthorizedOperations
counter is incremented, a report PDU is generated, and the
received message is discarded without further processing.
b) if the LCD information indicates the SNMPv2 context is of type
remote, then the Inform operation represented by the PDUs value
is performed by the receiving SNMPv2 entity according to the
procedures set forth in [12].
c) if the LCD information indicates the SNMPv2 context is of type
remote-proxy, then:
i. a single unique request-id is selected for use by all
forwarded copies of this request. This value will enable the
first response message to be correlated with this request;
other responses are not required and should be discarded when
received, since the agent that originated the Inform only
requires one response to its Inform.
ii. information is extracted from the LCD concerning all
combinations of userName, qoS, agentID, contextSelector and
transport address with which the received message is to be
forwarded.
iii. for each such combination whose access rights permit Inform
operations to be forwarded, a new SNMPv2 message is
constructed, as follows: its PDUs component is copied from
that in the received message except that the contained
request-id is replaced by the value selected in Step i above;
its <userName>, <qoS>, <agentID> and <contextSelector> fields
are set to the values extracted in Step ii above; and its
<maxSize> field is set to the minimum of the value in the
received message and the local system's maximum message size
for the transport domain which will be used to forward this
message.
iv. for each constructed SNMPv2 message, information concerning
the <userName>, <qoS>, <agentID>, <contextSelector>,
request-id and sending transport address of the received
message, as well as the request- id, agentID and
contextSelector of the constructed message, is cached for
later use in generating a response message.
v. each constructed message is forwarded to the appropriate
transport address extracted from the LCD in step ii above.
(15) If the SNMPv2 operation type is a Response, then:
a) if the LCD information indicates the SNMPv2 context is of type
local, then the usecStatsUnauthorizedOperations counter is
incremented, a report PDU is generated, and the received message
is discarded without further processing.
b) if the LCD information indicates the SNMPv2 context is of type
remote, then the Response operation represented by the PDUs
value is performed by the receiving SNMPv2 entity according to
the procedures set forth in [12].
c) if the LCD information indicates the SNMPv2 context is of type
local-proxy or remote-proxy, then:
i. the request-id is extracted from the PDUs component of the
received message. The context's agentID and contextSelector
values together with the extracted request-id are used to
correlate this response message to the corresponding values
for a previously forwarded request by inspecting the cache of
information as augmented in Substep iii of Step 13f above or
in Substep iv of 14c above. If no such correlated
information is found, then the received message is discarded
without further processing.
ii. a new SNMPv2 message is constructed: its PDUs component is
copied from that in the received message except that the
contained request-id is replaced by the value saved in the
correlated information from the original request; its
<userName>, <qoS>, <agentID> and <contextSelector> fields are
set to the values saved from the received message. The
<maxSize> field is set to the minimum of the value in the
received message and the local system's maximum message size
for the transport domain which will be used to forward the
message. The message is authenticated and/or protected from
disclosure according to the saved qoS value.
iii. the constructed message is forwarded to the transport
address saved in the correlated information as the sending
transport address of the original request.
iv. the correlated information is deleted from the cache of
information.
(16) If the SNMPv2 operation type is a SNMPv2-Trap, then:
a) if the LCD information indicates the SNMPv2 context is of type
local or local-proxy, then the usecStatsUnauthorizedOperations
counter is incremented, a report PDU is generated, and the
received message is discarded without further processing.
b) if the LCD information indicates the SNMPv2 context is of type
remote, then the SNMPv2-Trap operation represented by the PDUs
value is performed by the receiving SNMPv2 entity according to
the procedures set forth in [12].
c) if the LCD information indicates the SNMPv2 context is of type
remote-proxy, then:
i. a unique request-id is selected for use in forwarding the
message.
ii. information is extracted from the LCD concerning all
combinations of userName, qoS, agentID, contextSelector and
transport address with which the received message is to be
forwarded.
iii. for each such combination whose access rights permit
SNMPv2-Trap operations to be forwarded, a new SNMPv2 message
is constructed, as follows: its PDUs component is copied from
that in the received message except that the contained
request-id is replaced by the value selected in Step i above;
its <userName>, <qoS>, <agentID> and <contextSelector> fields
are set to the values extracted in Step ii above.
iv. each constructed message is forwarded to the appropriate
transport address extracted from the LCD in step ii above.
3.2.1. 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.2.1.1. ASN.1 Parsing Errors
For ASN.1 parsing errors, the snmpInASNParseErrs counter [15] is
incremented and a report PDU is generated whenever such an ASN.1
parsing error is discovered. However, if the parsing error causes
the information able to be extracted from the message to be
insufficient for generating a report PDU, then the report PDU is not
sent.
3.2.1.2. Incorrectly Encoded Parameters
For an incorrectly encoded parameters component of the Message value
(e.g., incorrect or inconsistent value of the <userLen> or <authLen>
fields), the usecStatsBadParameters counter is incremented. Since the
encoded parameters are in error, the report flag in the qoS cannot be
reliably determined. Thus, no report PDU is generated for the
incorrectly encoded parameters error condition.
3.2.1.3. Generation of a Report PDU
Some steps specify that the received message is discarded without
further processing whenever a report PDU is generated. However:
- An SNMPv2 manager never generates a report PDU.
- If the operation type can reliably be determined and it is
determined to be a Report, SNMPv2-Trap, Inform, or a Response then
a report PDU is not generated.
- A report PDU is only generated when the report flag in the qoS is
set to the value 1.
A generated report PDU must always use the current values of agentID,
agentBoots, and agentTime from the LCD. In addition, a generated
report PDU must whenever possible contain the same request-id value
as in the PDU contained in the received message. Meeting this
constraint normally requires the message to be further processed just
enough so as to extract its request-id. There are two situations in
which the SNMPv2 request-id cannot be determined. The first situation
occurs when the userName is unknown and the qoS indicates that the
message is encrypted. The other situation is when there is an ASN.1
parsing error. In cases where the the request-id cannot be
determined, the default request-id value 2147483647 is used.
3.2.1.4. Cache Timeout
Some steps specify that information is cached so that a Response
operation may be correlated to the appropriate Request operation.
However, a number of situations could cause the cache to grow without
bound. One such situation is when the Response operation does not
arrive or arrives "late" at the entity. In order to ensure that the
cache does not grow without bound, it is recommended that cache
entries be deleted when they are determined to be no longer valid. It
is an implementation dependent decision as to how long cache entries
remain valid, however, caching entries more than 150 seconds is not
useful since any use of the cache entry after that time would
generate a usecStatsNotInWindows error condition.
3.3. Generating a Response
The procedure for generating a response to an SNMPv2 management
request is identical to the procedure for transmitting a request (see
Section 3.1), with these exceptions:
- The response is sent on behalf of the same user and with the same
value of the agentID and contextSelector as the request.
- The PDUs value of the responding Message value is the response
which results from performing the operation specified in the
original PDUs value.
- The authentication protocol and other relevant information for the
user is obtained, not from the LCD, but rather from information
cached (in Step 13d) when processing the original message.
- The serialized Message value is transmitted using any transport
address belonging to the agent for the transport domain from which
the corresponding request originated - even if that is different
from any transport information obtained from the LCD.
- If the qoS specifies that the message is to be authenticated or the
response is being generated by a SNMPv2 entity acting in an agent
role, then the current values of agentBoots and agentTime from the
LCD are used. Otherwise, the <agentBoots> and <agentTime> fields
are set to zero-filled octets.
- The report flag in the qoS is set to the value 0.
4. Discovery
This security model requires that a discovery process obtain
sufficient information about an SNMPv2 entity's agent in order to
communicate with it. Discovery requires the SNMPv2 manager to learn
the agent's agentID value before communication may proceed. This may
be accomplished by formulating a get-request communication with the
qoS set to noAuth/noPriv, the userName set to "public", the agentID
set to all zeros (binary), the contextSelector set to "", and the
VarBindList left empty. The response to this message will be an
reportPDU that contains the agentID within the <parameters> field
(and containing the usecStatsUnknownContexts counter in the
VarBindList). If authenticated communication is required then the
discovery process may invoke the procedure described in Section 2.7
to synchronize the clocks.
5. Definitions
SNMPv2-USEC-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, Counter32, Unsigned32,
snmpModules
FROM SNMPv2-SMI
TEXTUAL-CONVENTION
FROM SNMPv2-TC
MODULE-COMPLIANCE, OBJECT-GROUP
FROM SNMPv2-CONF;
usecMIB MODULE-IDENTITY
LAST-UPDATED "9601120000Z"
ORGANIZATION "IETF SNMPv2 Working Group"
CONTACT-INFO
" Glenn W. Waters
Postal: Bell-Northern Research, Ltd.
P.O. Box 3511, Station C
Ottawa, ON, K1Y 4H7
Canada
Tel: +1 613 763 3933
E-mail: gwaters@bnr.ca"
DESCRIPTION
"The MIB module for SNMPv2 entities implementing the user-
based security model."
::= { snmpModules 6 }
usecMIBObjects OBJECT IDENTIFIER ::= { usecMIB 1 }
-- Textual Conventions
AgentID ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"An agent's administratively-unique identifier.
The value for this object may not be all zeros or all 'ff'H.
The initial value for this object may be configured via an
operator console entry or via an algorithmic function. In
the later case, the following guidelines are recommended:
1) The first four octets are set to the binary equivalent
of the agent's SNMP network management private
enterprise number as assigned by the Internet Assigned
Numbers Authority (IANA). For example, if Acme
Networks has been assigned { enterprises 696 }, the
first four octets would be assigned '000002b8'H.
2) The remaining eight octets are the cookie whose
contents are determined via one or more enterprise-
specific methods. Such methods must be designed so as
to maximize the possibility that the value of this
object will be unique in the agent's administrative
domain. For example, the cookie may be the IP address
of the agent, or the MAC address of one of the
interfaces, with each address suitably padded with
random octets. If multiple methods are defined, then
it is recommended that the cookie be further divided
into one octet that indicates the method being used and
seven octets which are a function of the method."
SYNTAX OCTET STRING (SIZE (12))
-- the USEC Basic group
--
-- a collection of objects providing basic instrumentation of
-- the SNMPv2 entity implementing the user-based security model
usecAgent OBJECT IDENTIFIER ::= { usecMIBObjects 1 }
agentID OBJECT-TYPE
SYNTAX AgentID
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The agent's administratively-unique identifier."
::= { usecAgent 1 }
agentBoots OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of times that the agent has re-initialized
itself since its initial configuration."
::= { usecAgent 2 }
agentTime OBJECT-TYPE
SYNTAX Unsigned32 (0..2147483647)
UNITS "seconds"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of seconds since the agent last incremented the
agentBoots object."
::= { usecAgent 3 }
agentSize OBJECT-TYPE
SYNTAX INTEGER (484..65507)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The maximum length in octets of an SNMPv2 message which
this agent will accept using any transport mapping."
::= { usecAgent 4 }
-- USEC statistics
--
-- a collection of objects providing basic instrumentation of
-- the SNMPv2 entity implementing the user-based security model
usecStats OBJECT IDENTIFIER ::= { usecMIBObjects 2 }
usecStatsUnsupportedQoS OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of packets received by the SNMPv2 entity
which were dropped because they requested a quality-of-
service that was unknown to the agent or otherwise
unavailable."
::= { usecStats 1 }
usecStatsNotInWindows OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of packets received by the SNMPv2 entity
which were dropped because they appeared outside of the
agent's window."
::= { usecStats 2 }
usecStatsUnknownUserNames OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of packets received by the SNMPv2 entity
which were dropped because they referenced a user that was
not known to the agent."
::= { usecStats 3 }
usecStatsWrongDigestValues OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of packets received by the SNMPv2 entity
which were dropped because they didn't contain the expected
digest value."
::= { usecStats 4 }
usecStatsUnknownContexts OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of packets received by the SNMPv2 entity
which were dropped because they referenced a context that
was not known to the agent."
::= { usecStats 5 }
usecStatsBadParameters OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of packets received by the SNMPv2 entity
which were dropped because the <parameters> field was
improperly encoded or had invalid syntax."
::= { usecStats 6 }
usecStatsUnauthorizedOperations OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of packets received by the SNMPv2 entity
which were dropped because the PDU type referred to an
operation that is invalid or not authorized."
::= { usecStats 7 }
-- conformance information
usecMIBConformance
OBJECT IDENTIFIER ::= { usecMIB 2 }
usecMIBCompliances
OBJECT IDENTIFIER ::= { usecMIBConformance 1 }
usecMIBGroups OBJECT IDENTIFIER ::= { usecMIBConformance 2 }
-- compliance statements
usecMIBCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for SNMPv2 entities which
implement the SNMPv2 USEC model."
MODULE -- this module
MANDATORY-GROUPS { usecBasicGroup,
usecStatsGroup }
::= { usecMIBCompliances 1 }
-- units of conformance
usecBasicGroup OBJECT-GROUP
OBJECTS { agentID,
agentBoots,
agentTime,
agentSize }
STATUS current
DESCRIPTION
"A collection of objects providing identification, clocks,
and capabilities of an SNMPv2 entity which implements the
SNMPv2 USEC model."
::= { usecMIBGroups 1 }
usecStatsGroup OBJECT-GROUP
OBJECTS { usecStatsUnsupportedQoS,
usecStatsNotInWindows,
usecStatsUnknownUserNames,
usecStatsWrongDigestValues,
usecStatsUnknownContexts,
usecStatsBadParameters,
usecStatsUnauthorizedOperations }
STATUS current
DESCRIPTION
"A collection of objects providing basic error statistics of
an SNMPv2 entity which implements the SNMPv2 USEC model."
::= { usecMIBGroups 2 }
END
6. Security Considerations
6.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).
- A management station must generate unpredictable request-ids in
authenticated messages in order to protect against the possibility
of message duplication (malicious or otherwise).
- A management station should perform time synchronization using
authenticated messages in order to protect against the possibility
of message duplication (malicious or otherwise).
- When sending state altering messages to a managed agent, a
management station should delay 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 [15], 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
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.
6.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 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.
The algorithm in Appendix A avoids this problem by including the
agent's agentID value as well as the user's password in the
calculation of a user's secrets; this results in the user's secrets
being different at different agents; however, if the password is
compromised the algorithm in Appendix A is not effective.
6.3. Conformance
To be termed a "Secure SNMPv2 implementation", an SNMPv2
implementation:
- must implement the Digest Authentication Protocol.
- 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.
In addition, an SNMPv2 agent must provide initial configuration in
accordance with Appendix A.1.
Implementation of the Symmetric Encryption Protocol is optional.
7. Editor's Address
Glenn W. Waters
Bell-Northern Research Ltd.
P.O. Box 3511, Station C
Ottawa, Ontario K1Y 4H7
CA
Phone: +1 613 763 3933
EMail: gwaters@bnr.ca
8. Acknowledgements
This document is the result of significant work by three major
contributors:
Keith McCloghrie (Cisco Systems, kzm@cisco.com)
Marshall T. Rose (Dover Beach Consulting, mrose@dbc.mtview.ca.us)
Glenn W. Waters (Bell-Northern Research Ltd., gwaters@bnr.ca)
The authors wish to acknowledge James M. Galvin of Trusted
Information Systems who contributed significantly to earlier work on
which this memo is based, and the general contributions of members of
the SNMPv2 Working Group, and, in particular, Aleksey Y. Romanov and
Steven L. Waldbusser.
A special thanks is extended for the contributions of:
Uri Blumenthal (IBM)
Shawn Routhier (Epilogue)
Barry Sheehan (IBM)
Bert Wijnen (IBM)
9. References
[1] McCloghrie, K., Editor, "An Administrative Infrastructure for
SNMPv2", RFC1909, Cisco Systems, January 1996.
[2] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple
Network Management Protocol", STD 15, RFC1157, SNMP Research,
Performance Systems International, MIT Laboratory for Computer
Science, May 1990.
[3] Rivest, R., "The MD5 Message-Digest Algorithm", RFC1321, MIT
Laboratory for Computer Science, April 1992.
[4] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
S. Waldbusser, "Coexistence between Version 1 and Version 2 of
the Internet-standard Network Management Framework", RFC1908,
January 1996.
[5] Data Encryption Standard, National Institute of Standards and
Technology. Federal Information Processing Standard (FIPS)
Publication 46-1. Supersedes FIPS Publication 46, (January, 1977;
reaffirmed January, 1988).
[6] Data Encryption Algorithm, American National Standards Institute.
ANSI X3.92-1981, (December, 1980).
[7] DES Modes of Operation, National Institute of Standards and
Technology. Federal Information Processing Standard (FIPS)
Publication 81, (December, 1980).
[8] Data Encryption Algorithm - Modes of Operation, American National
Standards Institute. ANSI X3.106-1983, (May 1983).
[9] Guidelines for Implementing and Using the NBS Data Encryption
Standard, National Institute of Standards and Technology. Federal
Information Processing Standard (FIPS) Publication 74, (April,
1981).
[10] Validating the Correctness of Hardware Implementations of the NBS
Data Encryption Standard, National Institute of Standards and
Technology. Special Publication 500-20.
[11] Maintenance Testing for the Data Encryption Standard, National
Institute of Standards and Technology. Special Publication 500-61,
(August, 1980).
[12] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
S., Waldbusser, "Protocol Operations for Version 2 of the Simple
Network Management Protocol (SNMPv2)", RFC1905, January 1996.
[13] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
S. Waldbusser, "Transport Mappings for Version 2 of the Simple
Network Management Protocol (SNMPv2)", RFC1906, January 1996.
[14] Krawczyk, H., "Keyed-MD5 for Message Authentication", Work in
Progress, IBM, June 1995.
[15] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
S. Waldbusser, "Management Information Base for Version 2 of the
Simple Network Management Protocol (SNMPv2)", RFC1907
January 1996.
APPENDIX A - Installation
A.1. 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
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 [13]. 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, termed "digest1", is used in
the next step.
- a second string of length 44 octets is formed by concatenating
digest1, the agent's agentID value, and digest1. This string is
used as input to the MD5 algorithm. The resulting digest is the
required secret (see Appendix A.2).
With these configured parameters, the agent instantiates the
following user, context, views and access rights. This configuration
information should be readOnly (persistent).
- One user:
privacy not supported privacy supported
--------------------- -----------------
<userName> "public" "public"
<authProtocol> Digest Auth. Protocol Digest Auth. Protocol
<authPrivateKey> authentication key authentication key
<privProtocol> none Symmetric Privacy Protocol
<privPrivateKey> -- privacy key
- One local context with its <contextSelector> as the empty-string.
- One view for authenticated access:
- the <all> MIB view is the "internet" subtree.
- 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" [15],
"usecAgent" and "usecStats" subtrees.
For the "semi-secure" posture:
- the <restricted> MIB view is the union of the "snmp" [15],
"usecAgent", "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
"".
- read-write access for authenticated but not private messages
on behalf of the user "public" to the <all> MIB view of
contextSelector "".
- 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 "".
A.2. 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
RFC1321.)
void password_to_key(password, passwordlen, agentID, key)
u_char *password; /* IN */
u_int passwordlen; /* IN */
u_char *agentID; /* IN - pointer to 12 octet long agentID */
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 */
/* localize the key with the agentID and pass through MD5
to produce final key */
memcpy (password_buf, key, 16);
memcpy (password_buf+16, agentID, 12);
memcpy (password_buf+28, key, 16);
MD5Init (&MD);
MDupdate (&MD, password_buf, 44);
MD5Final (key, &MD);
return; }
A.3. Password to Key Sample
The following shows a sample output of the password to key algorithm.
With a password of "maplesyrup" the output of the password to key
algorithm before the key is localized with the agent's agentID is:
'9f af 32 83 88 4e 92 83 4e bc 98 47 d8 ed d9 63'H
After the intermediate key (shown above) is localized with the
agentID value of:
'00 00 00 00 00 00 00 00 00 00 00 02'H
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