Internet DRAFT - draft-ietf-snmpv2-features
draft-ietf-snmpv2-features
HTTP/1.1 200 OK
Date: Tue, 09 Apr 2002 08:19:05 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Tue, 08 Aug 1995 22:00:00 GMT
ETag: "323a95-6254-3027de60"
Accept-Ranges: bytes
Content-Length: 25172
Connection: close
Content-Type: text/plain
Internet Draft SNMPV2d Aug 1995
A Decoupled Approach to SNMPv2 and Its Features (SNMPv2d)
1 Aug 1995
draft-ietf-snmpv2-features-00.txt
Daniel O. Mahoney II
Cabletron Systems, Inc.
(dmahoney@ctron.com)
Dave Harrington
Cabletron Systems, Inc.
(dbh@ctron.com)
Dave Arneson
Cabletron Systems, Inc.
(arneson@ctron.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 January 1996 [Page 1]
Internet Draft SNMPv2d Aug 1995
Abstract
One of the problems with the original SNMPv2 drafts and the USEC version
of the drafts is the tight coupling of all the features. To implement
any feature requires all the features. This document proposes a
solution to the tight coupling of the SNMPv2 features. It allows the
developer and the user to choose which features are desired and which
features are not for a given implementation or network.
1. Introduction
A management system contains: several (potentially many) nodes, each
with a processing entity, termed an agent, which has access to
management instrumentation; at least one management station; and, a
management protocol, used to convey management information between the
agents and 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.
Management information is viewed as a collection of managed objects,
residing in a virtual information store, termed the Management
Information Base (MIB). Collections of related objects are defined in
MIB modules. These modules are written using a subset of OSI's Abstract
Syntax Notation One (ASN.1) [1], termed the Structure of Management
Information (SMI) [2].
The model described here is largely derived from the work of the SNMPv2
Working Group, as published in RFC1445 and RFC1447, and subsequent
internet drafts. With the tight coupling of features in the original
SNMPv2 Drafts and the USEC drafts, it seems that the all or nothing
approach dictated by these documents may well be one of the root causes
of many of the problems we have had to date with deploying SNMPv2. If
the features are decoupled such that various subsets can be designed,
implemented and used independently, then SNMPv2 can be more easily
deployed. It also gives control back to the customers, allowing them to
determine what features are needed.
It is the purpose of this document to define feature sets and define how
these feature sets can be used to implement subsets of the original
SNMPv2 functionality, which can be used with a variety of security
frameworks, commonly referred to as admin models. Each set consists of a
set of SNMPv2 features, a PDU format, and any configuration MIBs needed
(defined in [3] and [4]). The feature sets are:
Mahoney [Page 2]
Internet Draft SNMPv2d Aug 1995
1) SNMPv2 Message
Defines message format used throughout this document
Support of data filters, which allow two things: multiple
entities to be addressed via a single agent and views to
filter the data
Multiple PDU formats
2) SnmpMinSecure-PDU
contains SNMPv2 PDUs defined in [5]
3) SnmpPrivate-PDU
encrypted data
4) Authenticated and Secure PDU
similar to [6]
Administrative Model
Authentication
Encryption
The message format consist of a header with the multiple choices in the
data portion of the message. This gives the flexibility to implement or
use only the features desired.
2. Acknowledgments
The authors want to thank Michael Kornegay and Alex Alten for their
proposals, which started us off on this tangent.
The authors also wish to acknowledge the contributions of the SNMPv2
Working Group.
Credit for the name, "SNMPv2d", goes to Bob Natale.
3. Administrative Model Expectations
It is expected that any administrative model used with the message and
PDUs defined in this document will contain the following features:
a MIB defining the communicating entities in the system (i.e the
Party Table or a user MIB). This MIB should also allow for
definition of authentication and privacy protocols and the keys
associated with those protocols;
A MIB mapping any communicating entities that receive requests to
the appropriate data filter entry.
4. Feature Set Definitions
Mahoney [Page 3]
Internet Draft SNMPv2d Aug 1995
4.1 SNMPv2 Message
This feature set defines the message format used in this proposal. A
SNMPv2 message contains a single PDU; it is transmitted from one SNMPv2
entity to another SNMPv2 entity and contains management information for
the destination SNMPv2 entity. Each of the following sections define the
PDUs, which can be contained in the data portion of the message. It
includes a local entity field, which refers to the contextLocalEntity in
the ContextMIB [3]. The fields are defined as:
<version> = 2
<dataFilterIdentity> = defines which dataFilterEntry to use
<data> = one of SnmpMinSecure-PDU, SnmpAuthSecure-PDU
---------------------------------------
| | | |
| version | dataFilterIdentity | data |
| | | |
---------------------------------------
4.2 SnmpMinSecure-PDU
This PDU contains SNMPv2 PDUs as defined in Protocol Operations
for SNMPv2 [5].
4.3 SnmpPrivate-PDU
This PDU contains an encrypted form of a SnmpMinSecure-PDU.
4.4 SnmpAuthSecure-PDU
This feature set adds several additional features including the concept
of an administrative model, authentication and security. For more
information about the rationale behind the authentication and privacy
schemes used, read [6].
A Noauth/Nopriv mode is available for access control without
authentication and privacy. To achieve this, model is set to 0, which
means that the identity is read, but the AgentBoots, AgentTime and
doubleEncryptedHash is ignored.
The fields are defined as:
<model> = defines which admin model
is being used;
<identity> = is a field whose contents are defined by
the admin model to uniquely identify which
key information is to be used for
authentication or decryption
<error_state> = contains any errors related to the security
<AgentBoots> = as defined in [7]
<AgentTime> = as defined in [7]
<doubleEncryptedHash> = the authentication hash as defined in
Mahoney [Page 4]
Internet Draft SNMPv2d Aug 1995
section 15 in [6]
<PDU> = contains a SnmpMinSecure or SnmpPrivate PDU
-----------------------------------------------
| | | | | |
| version | model | identity | AuthInfo | PDU |
| | | | | |
-----------------------------------------------
/ \
--------------------------- ---------------
/ \
---------------------------------------------------------
| error- | AgentBoots | AgentTime | doubleEncryptedHash |
| status | | | |
| | | | |
---------------------------------------------------------
5. Message Definitions
SNMPv2-Message ::= SEQUENCE {
version INTEGER { SNMPv2 (1) },
dataFilterIdentity OCTET STRING, -- defined in [3]
errorCode INTEGER { normal(0),
encodingError(1),
notSupported(2), -- specified conformance level
-- is not supported
modelError(3) } -- The model is not supported
CHOICE {
SnmpMinSecure-PDU,
SnmpAuthSecure-PDU
}
}
SnmpMinSecure-PDU ::= [1] IMPLICIT SEQUENCE {
pdu PDUs
}
SnmpPrivate-PDU ::= [2] IMPLICIT SEQUENCE {
SymmetricKeyEncryptedData IMPLICIT OCTET STRING -- encryption of an
-- SnmpMinSecure-PDU
-- defined in [6]
Mahoney [Page 5]
Internet Draft SNMPv2d Aug 1995
SnmpAuthSecure ::= [3] IMPLICIT SEQUENCE {
model INTEGER,
identity OCTET STRING,
errorStatus INTEGER {noError(0)
badIdentity(1),
badPublicKey(2),
badHash(3),
badTimeStamp(4),
badSymmetricKey(5),
tooLargeSymmetricKey(6),
noEncryptedDataAllowed(7),
badEncryptedData(8),
generalError(9)}
agentBoots UINT32,
agentTime UINT32,
doubleAsymmetricEncryptedHash -- Encrypted one-way hash value.
DoubleAsymmetricEncryptedHash, -- as defined in [6]
CHOICE {
SnmpMinSecure-PDU,
SnmpPrivate-PDU
}
AgentBoots OBJECT-TYPE
SYNTAX INTEGER
MAX-ACCESS read
STATUS current
DESCRIPTION
"a count of the number of times the agent has
rebooted/re-initialized since agentID was last configured."
::= { agentMIB 1 }
AgentTime OBJECT-TYPE
SYNTAX INTEGER
MAX-ACCESS read
STATUS current
DESCRIPTION
"the number of seconds since agentBoots was last
incremented."
::= { agentMIB 2 }
AgentMaxMessageSize OBJECT-TYPE
SYNTAX INTEGER
MAX-ACCESS read
STATUS current
DESCRIPTION
"the maximum size of a message which can be processed by
this agent."
::= { agentMIB 3 }
Mahoney [Page 6]
Internet Draft SNMPv2d Aug 1995
AgentLifetime OBJECT-TYPE
SYNTAX INTEGER
MAX-ACCESS read
STATUS current
DESCRIPTION
"the maximum lifetime of messages recevied by this agent".
::- { agent 4 }
6. Message Processing
6.1 Sending a message
This section describes the procedure followed by an SNMPv2 entity
whenever an SNMPv2 message or notification needs to transmitted.
1) Starting from the PDU, an SNMPv2 message is constructed by creating two
successive ASN.1 SEQUENCES, where:
- the PDU is a component of the first SEQUENCE, which could be an
SnmpMinSecure-PDU, an SnmpPrivate-PDU, or an Snmpauthsecure-PDU,
- the first SEQUENCE is a component of the second SEQUENCE, which
corresponds exactly to an SNMPv2 message.
In the SNMPv2 message, the dataFilterIdentity identifies the
dataFilterEntry to use at the destination.
2) The constructed SNMPv2 message is encoded according to the conventions
of [8]
3) The serialized SNMPv2 message is transmitted using the transport
address and transport domain as specified by the administrative model
currently in use.
6.2 Receiving a message
This section describes the procedure followed by an SNMPv2 entity
whenever a SNMPv2 message is received. This procedure is independent of
the transport service address at which the message was received.
(1) Increment the snmpStatsPackets [9]. If the message is not encoded
correctly (according to Transport Mappings for SNMPv2 [8]),
then snmpStatsEncodingErrors [8] is incremented and the message is
dropped.
(2) If the version number is not 1, then this message is processed in
some other manner, or the message is dropped and
snmpStatsEncodingErrors [9] is incremented.
(3) An ASN.1 OCTET STRING value is constructed from the SNMPv2 message.
Mahoney [Page 7]
Internet Draft SNMPv2d Aug 1995
(4) The dataFilterIdentity is extracted from the message. If the
dataFilterEntry corresponding to that dataFilterIdentity is not
found, then a Report-PDU is sent. Generation of report PDUs is
suppressed if disabled by the managed object, SNMPv2dnableReports
[9].
(5) If the PDU Type is not supported by the recipient, then build an
SNMPv2 messages, set the errorCode to notSupported, encode the message
and send it to the original sender.
(6) The PDU is now processing according to the rules defined in section
7.
7. PDU Processing
It is mandatory that all SNMPv2 entities acting in an agent role be able
to generate the following PDU types: Response-PDU, SNMPv2-Trap-PDU and
Report-PDU; further, all such implementations must be able to receive
the following PDU types: GetRequest-PDU, GetNextRequest-PDU,
GetBulkRequest-PDU, and SetRequest-PDU.
It is mandatory that all SNMPv2 entities acting in a manager role be
able to generate the following PDU types: GetRequest-PDU,
GetNextRequest-PDU, GetBulkRequest-PDU, SetRequest-PDU, InformRequest-
PDU, and Response-PDU; further, all such implementations must be able to
receive the following PDU types: Response-PDU, SNMPv2-Trap-PDU,
InformRequest-PDU and Report-PDU.
In the elements of procedure below, any field of a PDU which is not
referenced by the relevant procedure is ignored by the receiving SNMPv2
entity. However, all components of a PDU, including those whose values
are ignored by the receiving SNMPv2 entity, must have valid ASN.1 syntax
and encoding. For example, some PDUs (e.g., the GetRequest-PDU) are
concerned only with the name of a variable and not its value. In this
case, the value portion of the variable binding is ignored by the
receiving SNMPv2 entity. The unSpecified value is defined for use as
the value portion of such bindings.
For all generated PDUs, the message "wrapper" to encapsulate the PDU is
generated and transmitted as specified in section 6.
On receiving a management communication, the procedures defined in
section 6 are followed. If these procedures indicate that the
PDU contained within the message "wrapper" is to be processed, then the
SNMPv2 context associated with the PDU defines the object resources
which are visible to the operation.
7.1 SnmpMinSecure-PDU
A SnmpMinSecure-PDU is generated and transmitted at the request of a
SNMPv2 application as described in [10].
Mahoney [Page 8]
Internet Draft SNMPv2d Aug 1995
Upon receipt of a SnmpMinSecure-PDU. the receiving SNMPv2 entity
processes the PDU using the following steps:
(1) Processes the PDU as described in [10].
(2) If the PDU was decoded correctly, then build an SNMPv2 message,
set the errorCode to <normal>, encode the message and return it to the
sender.
(3) If the PDU cannot be decoded, then build an SNMPv2 message, set the
errorCode to encodingError, encode the message and return it to the
sender.
7.2 SnmpAuthSecure-PDU
The PDU processing proposes the usage of a public key authentication
protocol and symmetric key privacy protocol. However, at the discretion
of the implementor, these usages may be changed to other protocols. For
more discussion of the implications of using other protocols, see [6].
A SnmpAuthSecure-PDU is generated and transmitted at the request of a
SNMPv2 application using the following steps:
(1) Get the desired identity and put in the identity field of the PDU.
(2) If the PDU is to be Noauth/Nopriv, then set model = 0 and skip to
step 7; otherwise Set model to the value defined for use by the
current admin model.
(3) Get the current values of AgentBoots and AgentTime either from the
agent or some stored value of them that the manager is sure is in sync
with the agent's values.
(4) Construct the PDU header setting the encrypted hash and error-status
to zero.
(5) Encode the PDU and compute the hash (see section 18 of [6]).
(6) Double encrypt the hash value, first with the sender's private
authentication key using the sender's authentication protocol and then
with the recipient's public authentication key using the recipient's
authentication protocol, which should be the same as the sender's.
(7) Process the PDU contained in the data portion of this PDU.
Upon receipt of a SnmpAuthSecure-PDU. the receiving SNMPv2 entity
processes the PDU using the following steps:
(1) Extract the model from the PDU header. If the model is not supported
by this recipient, then build an SNMPv2 message with this PDU in the
data portion of the message, set the errorCode to modelError, encode
the message and return it to the sender.
Mahoney [Page 9]
Internet Draft SNMPv2d Aug 1995
(2) Extract the identity from the PDU header.
(3) If the identity doesn't exist in the recipient's LCD, create an
SnmpAuthSecure-PDU, set error-status to badIdentity, generate an
SNMPv2-message and send the message to the original sender.
(4) Retrieve the recipient's private key from the LCD and the sender's
public key from the LCD using the identity from step 1.
(5) Decrypt the doubly encrypted hash, using first the recipient's
private key and then the sender's public key.
(6) Compute a hash of the PDU (see section 18 of [6]).
(7) Compare the computed hash and the decrypted hash. If they are not
equal, create an SnmpAuthSecure-PDU, set error-status to
badHash, generate an SNMPv2-message and send the message to the
original sender.
(8) Compare agentTime in header + lifetime to current agentTime in
recipient's agentMIB. If the lifetime is exceeded, then create an
SnmpAuthSecure-PDU, set error-status to badTimeStamp, generate
an SNMPv2-message, set errorCode to normal and send the message to
the original sender.
(9) If the PDU contained in the data portion of the PDU processes
without further error, then set the errorStatus to noErrors, build
an SNMPv2 Message with errorCode set to normal, encode the message
and return it to the sender
(10) Process PDU in data portion of this PDU in accordance to rules
defined in this section of the document for that type of PDU.
7.3 SnmpPrivate-PDU
A SnmpPrivate-PDU is always contained in an SnmpAuthSecure-PDU.
A SnmpPrivate-PDU is generated and transmitted at the request of a
SNMPv2 application using the following steps:
(1) Get privacy key and protocol to use from the LCD.
(2) Encrypt the PDU to be sent using the privacy key.
(3) Encode the results as an OCTET STRING.
(4) Encrypt the privacy key using first the sender's private
authentication key and then the recipient's public authentication
key and encode as an OCTET STRING
(5) These two values as a SEQUENCE are the PDU.
Mahoney [Page 10]
Internet Draft SNMPv2d Aug 1995
(6) These values then placed in the data portion of an
SnmpAuthSecure-PDU and process according to the rules in section 7.2
of this document.
Upon receipt of a SnmpPrivate-PDU. the receiving SNMPv2 entity
processes the PDU using the following steps:
(1) Decrypt the symmetric key, first using the recipient's private
authentication key and then the sender's public authentication key.
(2) Decode the data and decrypt it using the symmetric key.
(3) Process the resulting SnmpMinSecure-PDU according to the rules
defined in this section.
8. Security Considerations
This document discusses Authentication and Encrpytion of SNMP and SNMPv2
messages.
9. References
[1] Information processing systems - Open Systems Interconnection
Specification of Abstract Syntax Notation One (ASN.1),
International Organization for Standardization. International
Standard 8824, (December, 1987).
[2] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Structure
of Management Information for Version 2 of the Simple Network
Management Protocol (SNMPv2)", Internet Draft, SNMP Research, Inc.,
Cisco Systems, Dover Beach Consulting, Inc., Carnegie Mellon
University, May 1995.
[3] Dave Harrington, Sandeep Asija, Daniel O. Mahoney II, Data Filter
MIB for Version 2 of the Simple Network Management Protocol
(SNMPv2), draft-dbh-SNMPv2-dfilter-00.txt, July 1995.
[4] Dave Harrington, Sandeep Asija, Daniel O. Mahoney II, Access
Control MIB for Version 2 of the Simple Network Management
Protocol (SNMPv2), draft-dbh-SNMPv2-access-00.txt, July 1995.
[5] Jeffrey D. Case, Keith McCloghrie, Marshall T. Rose, Steven
Waldbusser, Protocol Operations for SNMPv2 of the Simple
Network Management Protocol (SNMPv2), August 1995,
draft-mahoney-SNMPv2-proto-03.txt .
[6] Alexander I. Alten, Security Encapsulation of Snmp, July 25,
1995
[7] Keith McCloghrie, Marshall T. Rose, Glenn Waters, James Galvin,
User-based Security Model for SNMPv2 of the Simple Network
Management Protocol (SNMPv2), draft-kzm-sec-alt-00.txt, June 1990
Mahoney [Page 11]
Internet Draft SNMPv2d Aug 1995
[8] Jeffrey D. Case, Keith McCloghrie, Marshall T. Rose and Steven
Waldbusser, Transport Mappings for version 2 of the Simple
Network Management Protocol (SNMPv2),
draft-kzm-SNMPv2-tm-alt-00.txt, June 1995.
[9] Jeffrey D. Case, Keith McCloghrie, Marshall T. Rose and Steven
Waldbusser, Management Information Base for version 2 of the
Simple Network Management Protocol (SNMPv2),
draft-kzm-SNMPv2-mib-alt-00.txt, June 1995.
[10] Jeffrey D. Case, Keith McCloghrie, Marshall T. Rose and Steven
Waldbusser, Protocol Operations for version 2 of the Simple
Network Management Protocol (SNMPv2),
draft-kzm-SNMPv2-proto-alt-00.txt, June 1995.
10. Authors
Daniel O. Mahoney II
Cabletron Systems, Inc.
ATTN: Daniel O. Mahoney II
Engineering - Durham
PO Box 5005
35 Industrial Way
Rochester, NH 03866-5005
USA
Phone: +1 603 337 7355
Email: dmahoney@ctron.com
David Harrington
Cabletron Systems, Inc.
ATTN: David Harrington
Engineering - Durham
P.O. Box 5005
Rochester NH 03866-5005
US
Phone: +1 603 337 7357
Email: dbh@ctron.com
David Arneson
Cabletron Systems, Inc.
ATTN: David Arneson
Engineering - Merrimack
P.O. Box 5005
Rochester NH 03866-5005
US
Phone: +1 603 337 5238
Email: arneson@ctron.com
Mahoney [Page 12]
Internet Draft SNMPv2d Aug 1995
Table of Contents
1. Introduction ............................................. 1
2. Acknowledgments .......................................... 3
3. Administrative Model Expectations ........................ 3
4. Feature Set Definitions .................................. 3
4.1 SNMPv2 Message .......................................... 4
4.2 SnmpMinSecure-PDU ....................................... 4
4.3 SnmpPrivate-PDU ......................................... 4
4.4 SnmpAuthSecure-PDU ...................................... 4
5. Message Definitions ...................................... 5
6. Message Processing ....................................... 6
6.1 Sending a message ....................................... 7
6.2 Receiving a message ..................................... 7
7. PDU Processing ........................................... 8
7.1 SnmpMinSecure-PDU ....................................... 8
7.2 SnmpAuthSecure-PDU ...................................... 8
7.3 SnmpPrivate-PDU ......................................... 9
8. Security Considerations .................................. 11
9. References ............................................... 11
10. Authors ................................................. 12
Expires January 1996 [Page 13]
