Internet DRAFT - draft-alten-snmpv2-sec-encap
draft-alten-snmpv2-sec-encap
HTTP/1.1 200 OK
Date: Mon, 08 Apr 2002 22:29:36 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Tue, 07 Nov 1995 23:00:00 GMT
ETag: "2e7cd5-13b05-309fe4f0"
Accept-Ranges: bytes
Content-Length: 80645
Connection: close
Content-Type: text/plain
INTERNET-DRAFT
Expires in six months
Security Encapsulation of SNMP
-------- ------------- -- ----
<draft-alten-snmpv2-sec-encap-01.txt>
Alexander. I. Alten
November 6, 1995
Abstract
This document proposes a practical solution for the security
of SNMP packets. It allows any SNMP packet to be transmitted
with strong authentication information. Packets can be optionally
encrypted for full security. This encapsulation protocol is
designed to allow implementations to meet USA export requirements.
It supports SNMPv1 [2], SNMPv2 [11], and will support any future
SNMP protocol enhancements. It can be added transparently so that
investment in existing SNMP protocol stacks can be preserved.
Administration is kept simple, in particular public key management
and time synchronization. This encapsulation scales well to large
numbers of managers and agents. It is designed to facilitate
implementation and to minimize troubleshooting with extensive
error reporting mechanisms.
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 ftp.is.co.za (Africa),
nic.nordu.net (Europe), munnari.oz.au (Pacific Rim),
ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast).
1. Introduction
When devices, containing sensitive or critical data, are attached to
a computer network the possibility arises in which an unauthorized
person may tamper, alter, review or destroy that data. Using SNMP to
configure and manage the device is a powerful and useful mechanism.
It is a real convenience and advantage to be able administer any
device across a computer network. However this same technology can
also allow a stranger to damage or manipulate the device without the
owner's permission. This person could be malicious, or simply
ignorant of the damage he is causing.
In the electronic world of computer networks, encryption technology
provides the only real solution of preventing unauthorized access
to the device, while at the same time allowing authorized people to
access it from their desks anywhere in the world.
Most commercial software applications are using the SNMP version 1
(SNMPv1) [1, 2, 3] network management protocol to allow remote
administration of a device. SNMPv1 is usually chosen because the
technology is proven and there are many available and robust
commercial implementations. SNMPv1 is a transaction protocol with
a pair of read requests, called Get and Get Next, and a write request,
called a Set. In general the most critical transaction request is
the Set since it can do serious damage to the data inside a device.
A later version of the protocol, SNMP version 2 (SNMPv2) [9, 10, 11],
adds some new read requests; Get Bulk and Inform. To prevent an
unauthorized SNMP transaction we must use encryption technology.
This document describes an encapsulation protocol for SNMP which
provides authentication and data privacy capabilities. Existing
implementations of SNMP can be easily supported, along with any
future enhancements to SNMP. This encapsulation is orthogonal to
any new SNMP PDU types or mechanisms to control MIB access. It is
designed to be easy to implement with a modest administrative
overhead.
2. Technical Overview of the Protocol
This protocol encapsulates any SNMP protocol. Using a hybrid
encryption approach, it provides either authentication-only or
secure SNMP transactions. It acts like a preprocessor to a SNMP
protocol, providing its own mechanisms for reporting errors, such
as an authentication failure. This document specifies the
encapsulation header format which contains a version identifier, an
opaque value, an error value, a time stamp, and an encrypted hash.
The SNMP packet is appended, either as plain data or as encrypted
data.
The signed and encrypted hash provides the most critical part of the
authentication of the SNMP packet. It binds the entire encapsulation
and SNMP packet together and ensures that it cannot be tampered with
on its journey from the sender to the receiver. It is signed and
encrypted using asymmetric (public key) encryption technology, such
as the RSA algorithm [15]. First the sender signs the hash with
his private key, then he encrypts it with the receiver's public key.
This ensures that only the correct receiver can recover the hash
from the encapsulation, by decrypting first with his private key and
then verifying it with the sender's public key, authenticating the
sender. This model of authentication is simple and robust.
The SNMP packet itself can be kept in its original ASN.1 encoding
or it can be encrypted with a symmetric encryption algorithm, such
as DES [13, 16, 17, 19] or RC4 [27]. This type of algorithm is
chosen because it is much faster than an asymmetric one. For
example DES is roughly 1000 times faster than RSA. Asymmetric
algorithms are chosen because the public portion of the keys can be
easily distributed over a network without compromising data
encrypted by the private portion. Since these algorithms are very
slow, only small pieces of data are encrypted with them, like
one-way hashes, timestamps and symmetric keys. A fully secure SNMP
packet would be authenticated and encrypted.
The agent MIB extensions are primarily to facilitate the exchange
of public keys. A table is specified where managers can deposit
their public keys. Also managers can retrieve the agent's public
key. The agent's timer value can be retrieved. Public key
distribution and time synchronization issues are more fully
discussed below.
This protocol has been designed with export licensing in mind. For
example an implementor may choose to do only authentication, the
SNMP packet is never encrypted. This would be the easiest
implementation to license. If encryption of the SNMP packet is
required, then the implementor may choose to use RC2 or RC4 with
40 bit keys. This would qualify for an export license.
This protocol has been designed to facilitate implementation
and in-the-field troubleshooting. Encryption technology can make
SNMP protocol transactions very difficult to analyze by obscuring
encodings and other critical data. As much data as possible is
unencrypted, such as the time stamp and the error status, to assist
the implementor or the administrator when they are trying to fix a
problem. By providing an encapsulation to existing SNMP protocol
machinery, which has been in use and field proven, problems can be
isolated and solved more easily.
3. Comparison With SNMPv2 Security
Both SNMPv2 and this proposal use encapsulation to provide
authentication and privacy of SNMP packets. However this proposal
diverges from SNMPv2 in how authentication is performed. SNMPv2,
after stripping away the details, uses a symmetric key algorithm,
DES, to provide authentication. This proposal uses an asymmetric
(public key) algorithm, such as RSA. This choice significantly
simplifies the exchange and maintenance of authentication
information. SNMPv2 relies on a mechanism of preconfiguring parties
on each agent and manager which wish to communicate, e.g. setting up
the DES key for each pair. DES keys cannot be freely sent across
the network, they must be given out either by hand or by some other
secure mechanism. In contrast, this proposal only requires that the
agent collect, possibly remotely across the network, public keys of
any managers that it will allow to communicate with it. Managers
simply get the agent's public key when they wish to communicate with
it. SNMPv2 becomes difficult to administer as the numbers of agents
and managers wishing to communicate increases, an exponential
explosion of DES keys must be created and distributed. For this
proposal the number of public keys remains equal to the total number
of agents and managers. In addition, distribution might only occur
when a manager and agent actually need to communicate.
For software which encrypts user data it is difficult to obtain
a US export license and many countries, notably France, will not
allow it to be used by their citizens without severe restrictions.
SNMPv2 uses DES to provide privacy for SNMP PDUs. This proposal
recommends RC2 or RC4 with 40 bit keys to provide privacy for SNMP
packets, DES is an optional implementation. It very difficult, if
not impossible, to get a US export license for DES. RC2 or RC4 with
40 bit keys (or less) can be exported from the USA.
Unlike SNMPv2 this proposal encapsulates an entire SNMP packet.
This means that it can provide authentication and privacy to
existing SNMPv1 packets as well as SNMPv2 packets. This is
important since there is a large installed base of SNMPv1 managers
and agents. The impact on SNMPv1 protocol stack machinery should be
negligible allowing easy upgrades. It should be able to support any
future versions of SNMP.
In summary this proposal provides three advantages over SNMPv2.
1. Authentication (key distribution) is simpler and scales better.
2. Export licenses can be obtained when encrypting data (privacy).
3. Also provides security for SNMPv1.
4. What This Document Does Not Discuss
This document does not discuss the following.
1. Patent licenses or royalties.
2. Encryption theory or background.
3. Operating system security policy.
4. Legal policy.
5. Generating random numbers.
6. Generating encryption keys.
7. Encrypting and storing private asymmetric encryption keys.
8. Encryption key escrow.
5. What This Document Does Discuss
This document discusses SNMP authentication and privacy.
1. USA export rules governing the export of encryption software.
2. Network security policy (limited).
3. Computing, signing and encrypting hashes.
4. Synchronizing time.
5. Encryption key identification.
6. Distributing encryption keys.
7. Certifying encryption keys (simple).
8. Encrypting SNMP packets.
6. Encryption Nomenclature
There are two types of encryption algorithms; asymmetric and
symmetric. Asymmetric algorithms use two keys, a public and a
private key. If one of the keys is used to encrypt data, then
only the other key may decrypt the data. If one of the keys is
used to sign the data, then only the other key may verify the
signature of the data. For some algorithms, like RSA [15],
these pair of operations use the exact same mathematical formula.
I.e. signing and encrypting with the same key are identical
operations, creating the same multiprecision integer result. For
other algorithms, like ElGamal [25], these are not the same
mathematical formula. I.e. signing and encrypting with the same key
will create different multiprecision integer results. The only
asymmetric algorithms specified are RSA and ElGamal.
Symmetric algorithms use only one key for both encryption and
decryption of bulk data, such as an SNMP packet. The only
symmetric algorithms specified are; RC2, RC4 [27], DES [13, 16, 17,
18], Triple DES [25], and IDEA [14].
In summary, for authentication, an encrypted signature, we use the
public and private keys. While for privacy, an encrypted SNMP
packet, we use a symmetric key. Note that full SNMP security
requires both authentication and privacy.
7. Security Nomenclature
Security is usually defined as all of the following.
1. Authentication, integrity
2. Privacy, secrecy, confidential
3. Availability, denial of service
4. Access control, authorization
5. Non-repudiation
In the context of this document they are defined as follows.
1. Authentication or integrity means that sender and the receiver
are known to each other, via asymmetric encryption, such as RSA,
and are associated with this encapsulated packet.
2. Privacy, secrecy or confidential means that the data payload of
this encapsulation packet, e.g. the SNMP packet, is encrypted
with a symmetric encryption algorithm, such as DES.
3. Availability means that the agent can ensure that it is still
functioning properly after an illegal attempt to modify its
MIB content. Denial of service means a valid manager could be
denied access to an agent. Unfortunately this document cannot
propose any solution for this attack.
4. Access control or authorization means that a manager may only
have access to portions of an agent's MIB or may only be able to
perform limited SNMP operations. This document does not describe
this. The underlying SNMP protocol inside the encapsulation
supports this.
5. Non-repudiation means that a manager cannot deny they performed
an operation on the agent. This document provides the foundation
mechanism for this (authentication), but does not describe how
to do it.
8. Requirements for Authenticated SNMP Packets
1. To prevent an unauthorized manager from initiating a destructive
operation on an agent e.g. a malicious Set request.
2. To allow an agent to accurately distinguish between management
stations or individuals. This will allow an agent to tailor
access rights to portions of a MIB.
3. To meet USA export requirements for software containing
encryption which is used only for authentication purposes.
9. Requirements for Private SNMP Packets
1. To prevent sensitive information from being read by unauthorized
recipients.
2. To allow the implementer to meet USA export requirements for
software containing encryption which is used for data
encryption purposes.
10. Secure Encapsulation Header
The secure encapsulation header for an SNMP packet contains
information to support the protocol operations and to provide
authentication of the sender. The SNMP packet is appended to it
either in plain or encrypted form.
The version field indicates the protocol described in this
document. The specified value is two.
The opaqueValue field allows the manager to match requests
with agent responses. This is needed in particular when the
SNMP packet is encrypted, shrouding the request identifer.
It can be any value, except zero. A simple count is recommended.
Traps set this to zero.
The errorStatus field is used by the agent to report any
encapsulation processing errors.
Error Name Description
----------------------- ---------------------------------------
noError Request encapsulation was correct.
Traps always use this code.
generalError An unspecified error occured.
badSignature The manager's public key is not
registered with the agent. Or the
signature is malformed; the one-way
hash is invalid or the decryption
failed to produce the correct
signature. This means that the
signature verification failed.
unsupportedPublicKey This type of public key is not
supported. RSA is required for all
implementations. This means that the
signature verification failed.
unsupportedHash This one-way hash algorithm is not
supported.
badTimeStamp The agent has an accurate clock and
requires a valid time. The manager's
time stamp is too old or incorrect.
badSymmetricKey The symmetric key is malformed. This
means the SNMP packet could not be
recovered from the encrypted data.
tooLargeSymmetricKey The agent does not allow too large a
symmetric key. This is to allow
encryption of the SNMP packet
conforming to export restrictions.
unsupportedSymmetricKey This symmetric key is not supported.
If encryption of the SNMP packet is
supported then RC2 and RC4, up to 40
bit key sizes, must be implemented.
unsupportedSymmetricMode This symmetric mode is not supported.
If encryption of the SNMP packet is
supported then ECB mode must be
supported. Other modes are optional.
noEncryptedDataAllowed The agent does not allow encrypted
SNMP packets.
badEncryptedData After decryption the data could not
be interpreted as a valid SNMP packet.
The timeStamp field is to reduce the probability of an authentic
packet being replayed. It represents the number of seconds since
midnight January 1, 1900 GMT. The manager fills this out with
a time value. The agent checks to see if this time is what it
expects i.e. the timestamp falls within a certain delay period.
This interval is not specified by this document. It is recommended
that it be configurable value on the agent. Some agents may not
have a reliable timer available. In this case the field can be
ignored by the agent. The return value should be an accurate copy
of the agent's timer when the response encapsulation is created.
If no reliable timer is available, then this field should be set to
zero by the agent.
The encryptedSignature is the computed one-way hash of the entire
encapsulation, not including this field, and the appended SNMP
packet (plain or encrypted). It is signed first by the sender's
private key and then encrypted by the receiver's public key. This
is called an encrypted signature. If the SNMP packet is encrypted
then the symmetric key is included with the hash before the
signature is created.
The final field is the SNMP packet, either plain or symmetric
algorithm encrypted.
-- Authenticated or secure encapsulation of SNMP message.
Encapsulation-Message ::=
SEQUENCE {
version -- Version 3 for this RFC.
INTEGER {
version-3(2)
},
opaqueValue -- Manager sets this, agent must
INTEGER, -- echo it back. Traps use 0.
errorStatus -- Response from agent, 0 otherwise.
INTEGER {
noError(0),
generalError(1),
badSignature(2),
unsupportedPublicKey(3),
unsupportedHash(4),
badTimeStamp(5),
badSymmetricKey(6),
tooLargeSymmetricKey(7),
unsupportedSymmetricKey(8),
unsupportedSymmetricMode(9),
noEncryptedDataAllowed(10),
badEncryptedData(11)
},
timeStamp -- Synchronized time value.
INTEGER, -- Agent returns current value.
encryptedSignature -- May contain symmetric key.
EncryptedSignature,
CHOICE {
data -- SNMPv1, SNMPv2, etc., packet
ANY,
encryptedData -- The encrypted SNMP packet.
EncryptedData
}
}
11. Authentication-only SNMP
Initially the sender, either a manager or agent, generates a public
and private key pair. The manager then registers its public key
with the agent. This registration can be done using SNMP or by
another mechanism. The manager can retrieve the agent's public key
using SNMP or by another mechanism. Once this exchange has taken
place then authenticated SNMP packets can be emitted and received.
Authenticated Requests
----------------------
When the manager wishes to send an authenticated SNMP request packet
the following steps need to be followed.
1. Retrieve a current time from the agent or use an internal timer
if the manager is confident that it is synchronized with the
agent.
2. Construct the encapsulation header and append the SNMP packet.
Set the encrypted signature and error values to zero. The opaque
value is set to some useful value, typically a unique count.
3. Compute a hash of the encapsulation header (see below) and
the SNMP packet. Everything must already be in its ASN.1
encoded form, including the current time stamp.
4. Sign the hash value with the manager's private key, then encrypt
the resulting signature with the agent's public key. This not
only authenticates the manager to the agent, but prevents a replay
attack against another agent which has also registered this
manager's public key.
When the agent receives this authenticated SNMP request packet, the
following steps are followed.
1. Decrypt the encrypted signature using the agent's private key,
then verify the signature with the manager's public key. If the
manager's public key is not registered then issue an authenticated
response indicating that a bad public key was encountered. If
the decryption or verification fails then send an appropriate
error response back to the sender.
2. Compute a hash of the encapsulation header (see below) and the
appended SNMP packet. The encrypted signature field is zeroed
during the calculation.
3. Compare the computed hash and the received hash. If they are
equal then proceed. Otherwise send an authenticated response
indicating a bad signature was encountered.
4. Check the time stamp. The agent should allow for network delays
time skews. If the time stamp is within an acceptable delay
period (this can be a configurable value on the agent) then
proceed. Otherwise send an authenticated response indicating
a bad time stamp was encountered.
Note: If any errors occur, such as a bad public key, then the
agent constructs a new encapsulation header and sends it and the
data (the SNMP packet) back to the manager.
Authenticated Responses
-----------------------
When the agent issues an authenticated SNMP response packet, the
following steps are followed.
1. Use an internal timer (secureSystemTime) to set the time stamp.
This can be used to synchronize the manager's timer.
2. Construct the encapsulation header and append the SNMP packet.
The encrypted signature and error values are set to zero. The
opaque value is set to some useful value, typically a unique
count. Copy the opaque value from the original request
encapsulation header to this one.
3. Compute a hash of the encapsulation header (see below) and
the SNMP packet. Everything must already be in its ASN.1
encoded form, including the current time stamp.
4. Sign the hash value with the agent's private key, then encrypt it
with the manager's public key. This not only authenticates
the agent to the manager, but prevents a replay attack against
another manager.
When the manager receives this authenticated SNMP response packet, the
following steps are followed.
1. Decrypt the encrypted signature using the manager's private key,
then verify it with the agent's public key. If the decryption or
verification fails then ignore the packet and optionally report
the error back up the protocol stack.
2. Compute a hash of the encapsulation header (see below) and the
SNMP packet. The encrypted signature field is zeroed during
the calculation.
3. Compare the computed hash and the received hash. If they are
equal then proceed. If not then ignore the packet and optionally
report the error back up the protocol stack.
4. The time stamp can be used to resynchronize the manager's timer.
5. Use the opaque value to demultiplex the response, e.g. to match
it with a pending request in the protocol machinery.
Authenticated Traps
-------------------
When the agent issues an authenticated SNMP trap packet, the
following steps are followed.
1. Use an internal timer (authSystemTime) to set the time stamp.
This can be used to synchronize the manager's timer.
2. Construct the encapsulation header and appended SNMP trap packet.
The encrypted signature, error and opaque values are set to zero.
3. Compute a hash of the encapsulation header (see below) and
the SNMP packet. Everything must already be in its ASN.1
encoded form, including the current time stamp.
4. Sign the hash value with the agent's private key, then encrypt it
with the manager's public key. This not only authenticates the
agent to the manager, but prevents a replay attack against
another manager.
When the manager receives this authenticated SNMP trap packet, the
following steps are followed.
1. Decrypt the encrypted signature using the manager's private key,
then verify it with the agents's public key. If the decryption
or verification fails then ignore the packet and optionally
report the error back up the protocol stack.
2. Compute a hash of the encapsulation header (see below) and the
SNMP packet. The encrypted signature field is zeroed during
the calculation.
3. Compare the computed hash and the received hash. If they are
equal then proceed. If not then ignore the packet and optionally
report the error back up the protocol stack.
4. The time stamp can be used to resynchronize the manager's timer.
Authenticated SNMP Transaction or Trap
+--------------------------+
| |
| Encapsulation |
| Header |
| using an |
| Encrypted Signature |
| |
+-------------+ | +----------------------+ | +------------+
| | | | | | | |
| Sender | | | | | | Receiver |
| |---->| | SNMP Packet | |---->| |
|(Private Key)| | | | | |(Public Key)|
| | | | | | | |
+-------------+ | +----------------------+ | +------------+
+--------------------------+
12. Secure SNMP
For full SNMP security, authentication information and the
encryption of the encapsulated SNMP packet is required. The
preparation of the encapsulation header is identical to the
authentication steps outlined above, except that the encrypted
symmetric key field is now used and that the data, an SNMP packet,
is encrypted using this symmetric key. It is recommended that each
pair of manager and agent use a different symmetric key during
their secure communications. For maximum security, each packet
sent should use a different symmetric key for encrypting the
SNMP packet. If the software is to be exported outside the USA
then it is recommended to use either the RC2 or RC4 algorithms
with a maximum of 40 bit keys.
Secure Requests
---------------
When the manager wishes to send a secure SNMP request packet the
following steps need to be followed.
1. Retrieve a current time from the agent or use an internal timer
if the manager is confident that it is synchronized with the
agent.
2. Using the symmetric key encrypt the SNMP packet. ASN.1 encode
the results as an OCTET STRING. The symmetric key is generated,
then signed by the manager's private key and then it is encrypted
by the agent's public key, and finally ASN.1 encoded. These two
ASN.1 variables are then appended to the encapsulation header as
a SEQUENCE.
3. Construct the encapsulation header and append the SNMP packet.
The encrypted signature and error values are set to zero, and
ASN.1 encoded. The opaque value is set to some useful value,
typically a unique count.
4. Compute a hash of the encapsulation header (see below) and
the encrypted SNMP packet. Everything must already be in its
ASN.1 encoded form, including the time stamp. The only exception
is the asymmetric key encrypted signature field which is zeroed
during the calculation.
5. Sign the hash value with the manager's private key, then encrypt
it with the agent's public key. This not only authenticates
the manager to the agent, but prevents a replay attack against
another agent which has also registered this agent's public key.
When the agent receives this secured SNMP request packet, the
following steps are followed.
1. Decrypt the encrypted signature using the agent's private key,
then verify it with the manager's public key. If the manager's
public key is not registered then issue a secure response
indicating that a bad public key was encountered. This operation
will also recover the symmetric key.
2. Compute a hash of the encapsulation header (see below) and the
SNMP packet. The encrypted signature field is zeroed during
the calculation.
3. Compare the computed hash and the received hash. If they are
equal then proceed. Otherwise send a secure response indicating
a bad signature was encountered.
4. Check the time stamp. The agent should allow for network delays
time skews. If the time stamp is within an acceptable delay
period (this can be a configurable value on the agent) then
proceed. Otherwise send a secure response indicating a bad time
stamp was encountered.
5. Using the symmetric key from step one ASN.1 decode and decrypt
the SNMP packet.
Note: If any errors occur, such as a bad signature, then the agent
constructs a new encapsulation header and sends it and the
encrypted data (the SNMP packet) back to the manager.
Secure Responses
----------------
When the agent issues a secure SNMP response packet, the following
steps are followed.
1. Use an internal timer (authSystemTime) to set the time stamp.
This can be used to synchronize the manager's timer.
2. Using the symmetric key encrypt the SNMP packet. ASN.1 encode
the results as an OCTET STRING. The symmetric key is generated,
then encrypted by the manager's private key and then the agent's
public key, and finally ASN.1 encoded. These two ASN.1 variables
are then appended to the encapsulation header as a SEQUENCE.
3. Construct the encapsulation header and append the SNMP packet.
The encrypted signature value is set to zero. Set the error
status value. Copy the opaque value from the original request
encapsulation header to this one.
4. Compute a hash of the encapsulation header (see below) and
the encrypted SNMP packet. Everything must already be in its
ASN.1 encoded form, including the time stamp.
5. Sign the hash value with the agent's private key, then encrypt it
with the manager's public key. This not only authenticates the
agent to the manager, but prevents a replay attack against
another manager.
When the manager receives this secure SNMP response packet, the
following steps are followed.
1. Decrypt the encrypted signature using the manager's private key,
then verify it with the agents's public key. If the decryption
fails then ignore the packet and optionally report the error back
up the protocol stack.
2. Compute a hash of the encapsulation header (see below) and the
SNMP packet. The encrypted signature field is zeroed during
the calculation.
3. Compare the computed hash and the received hash. If they are
equal then proceed. If not then ignore the packet and optionally
report the error back up the protocol stack.
4. The time stamp can be used to resynchronize the manager's timer.
5. Using the symmetric key from step one ASN.1 decode and decrypt
the SNMP packet.
6. Use the opaque value to demultiplex the response, e.g. to match
it with a pending request in the protocol machinery.
Secure Traps
------------
When the agent issues a secure SNMP trap packet, the following steps
are followed.
1. Use an internal timer (authSystemTime) to set the time stamp.
This can be used to synchronize the manager's timer.
2. Construct the encapsulation header. The encrypted signature,
error, and opaque values are set to zero. Since this is for
authentication only the encrypted symmetric key is set to an
ASN.1 NULL value.
3. Compute a hash of the encapsulation header (see below) and
the SNMP packet. Everything must already be in its ASN.1
encoded form, including the time stamp. The only exception is
the encrypted signature field which is zeroed during the
calculation.
4. Sign the hash value with the agent's private key, then encrypt it
with the manager's public key. This not only authenticates
the agent to the manager, but prevents a replay attack against
another manager.
When the manager receives this authenticated SNMP trap packet, the
following steps are followed.
1. Decrypt the doubly encrypted hash, first using the manager's
private key, then the agents's public key. If the decryption
fails then ignore the packet and optionally report the error back
up the protocol stack.
2. Compute a hash of the encapsulation header (see below) and the
SNMP packet. The encrypted signature field is zeroed during
the calculation.
3. Compare the computed hash and the received hash. If they are
equal then proceed. If not then ignore the packet and optionally
report the error back up the protocol stack.
4. The time stamp can be used to resynchronize the manager's timer.
5. Using the symmetric key from step one ASN.1 decode and decrypt
the SNMP packet.
Secure SNMP Transaction or Trap
+--------------------------+
| |
| Encapsulation |
| Header |
| using an |
| Encrypted Signature |
| |
+-------------+ | +----------------------+ | +------------+
| | | | | | | |
| | | | Encrypted | | | |
| Sender | | | Symmetric Key | | | Receiver |
| | | | and | | | |
|(Private Key)|---->| | Encrypted | |---->|(Public Key)|
| | | | SNMP Packet | | | |
| | | | | | | |
+-------------+ | +----------------------+ | +------------+
+--------------------------+
13. Time Stamp Format
The timer (secureSystemTime) is maintained by the agent. When a
manager wishes to synchronize it's own copy of this timer then
it can retrieve the time from the agent. Whenever the manager
sends a SNMP request it includes a copy of it's syncronized timer
value. Likewise the manager uses it's own timer when sending a
response or trap.
secureSystemTime OBJECT-TYPE
SYNTAX Time
ACCESS read-only
STATUS optional
DESCRIPTION
"This is the Agent's system date and time
expressed as the number of seconds since
midnight January 1, 1900 GMT. The manager
can retrieve this to synchronize its time
stamps. A practical implementation will
allow a certain amount of clock skew when
comparing incoming timestamps with this
value.
"
::= { secure 2 }
14. Hash Format
This is the ASN.1 format of a hash. Implicit values 0 to 3 are
reserved for one-way hashes.
HashMd5 ::= [0] IMPLICIT OCTET STRING (SIZE (16))
HashSha ::= [1] IMPLICIT OCTET STRING (SIZE (20))
Hash ::=
CHOICE {
hashMd5
HashMd5,
hashSha
HashSha
}
The MD5 [6] and SHA [21] one-way hashes are the only ones defined.
15. Public Key Format
This is the ASN.1 format of a public key [28]. When a public and
private key are generated by a manager or agent, two additional
pieces of information must be associated with this key pair. A
validity period and an identification number. The validity period
is used to age the key. If a key is older than the validity period
date then it is considered to be invalid. Implicit values 4 to 7
are reserved for public keys.
PublicKeyRsa ::= [4] IMPLICIT SEQUENCE {
validityPeriod
INTEGER,
modulus -- n
INTEGER,
encryption -- e
INTEGER
}
The validityPeriod is in number of seconds since midnight January 1,
1900 GMT (0 means forever).
The modulus and exponent are multiprecision integers which together
represent the public key.
For RSA it is recommended that the modulus is at least 768 bits in
length.
PublicKeyElGamal ::= [5] IMPLICIT SEQUENCE {
validityPeriod
INTEGER,
modulus -- p
INTEGER,
constant -- g
INTEGER,
resultant -- y
INTEGER
}
The validityPeriod is in number of seconds since midnight January 1,
1900 GMT (0 means forever).
The modulus, constant, and resultant, are multiprecision integers
which together represent the public key.
For ElGamal in DSS it is recommended that the modulus is 512 to 1024
bits in length.
PublicKey ::=
CHOICE {
publicKeyRsa
PublicKeyRsa
}
The RSA [15] and ElGamal [25] algorithms are the only ones defined.
16. Private Key Signature Format
This is the format of the private key signature format [14].
For this document the signature data will consist of a calculated
hash and possibly a symmetric key. When data is encrypted, a
unique identifier (keyIdentifier) is prepended to it. This is a
unique value associated with this public and private key pair. This
identifier is computed by taking a hash of a phase phrase or text,
and using only the lower 8 octets. While this increases the chance
of a duplicate value, it should be sufficient for manager and agent
communications. Implicit values 8 to 11 are reserved for private
key encrypted data.
PrivateKeySignatureRsa ::= [8] IMPLICIT SEQUENCE {
keyIdentifier
OCTET STRING (SIZE(8)),
encryptedData,
OCTET STRING
}
PrivateKeySignatureElGamal ::= [9] IMPLICIT SEQUENCE {
keyIdentifier
OCTET STRING (SIZE(8)),
encryptedData,
OCTET STRING
}
PrivateKeySignatureData ::=
CHOICE {
privateKeySignatureRsa
PrivateKeySignatureRsa,
privateKeySignatureElGamal
PrivateKeySignatureElGamal
}
The RSA [15] and ElGamal [25] algorithms are the only ones defined.
17. Public Key Encrypted Data Format
This is the format of the public key encrypted data format [28].
For this document the encrypted data will consist only of a private
key signature. When data is encrypted, a unique identifier
(keyIdentifier) is prepended to it. This is a unique value
associated with this public and private key pair. This identifier
is computed by taking a hash of the RSA modulus and using only the
lower 8 octets. While this increases the chance of a duplicate
value, it should be sufficient for manager and agent communications.
Implicit values 12 to 15 are reserved for public key encrypted data.
PublicKeyEncryptedDataRsa ::= [12] IMPLICIT SEQUENCE {
keyIdentifier
OCTET STRING (SIZE(8)),
encryptedData,
OCTET STRING
}
PublicKeyEncryptedDataElGamal ::= [13] IMPLICIT SEQUENCE {
keyIdentifier
OCTET STRING (SIZE(8)),
encryptedData,
OCTET STRING
}
PublicKeyEncryptedData ::=
CHOICE {
privateKeyEncryptedDataRsa
PrivateKeyEncryptedDataRsa,
privateKeyEncryptedDataElGamal
PrivateKeyEncryptedDataElGamal
}
The RSA [15] and ElGamal [25] algorithms are the only ones defined.
18. Symmetric Key Format
This is the ASN.1 format of a symmetric key. Implicit values 16 to
30 are reserved for symmetric keys.
SymmetricKeyRc2 ::= [16] IMPLICIT SEQUENCE {
numberOfBits -- recommend 40 bits for export software
INTEGER,
key
OCTET STRING
}
SymmetricKeyRc4 ::= [17] IMPLICIT SEQUENCE {
numberOfBits -- recommend 40 bits for export software
INTEGER,
key
OCTET STRING
}
SymmetricKeyDes ::= [18] IMPLICIT SEQUENCE {
modes -- ECB, CBC, etc...
INTEGER { ecb(0), cbc(1), cfb(2), ofb(3) },
vector -- Used by CBC, CFB and OFB modes
OCTET STRING OPTIONAL (SIZE (8)),
numBytes -- Used by CFB and OFB modes
INTEGER OPTIONAL { 1..7 },
key
OCTET STRING (SIZE (8))
}
SymmetricKeyTripleDes ::= [19] IMPLICIT SEQUENCE {
modes, -- normal or encrypt-decrypt-encrypt modes
INTEGER { normal(0), ede2(1), ede3(2) },
pad1, -- random bits of half a block
OCTET STRING (SIZE (4)) OPTIONAL,
pad2, -- random bits of half a block
OCTET STRING (SIZE (4)) OPTIONAL,
key1
SymmetricKeyDes,
key2
SymmetricKeyDes,
key3
SymmetricKeyDes
}
SymmetricKeyIdea ::= [20] IMPLICIT SEQUENCE {
modes -- ECB, CBC, etc...
INTEGER { ecb(0), cbc(1), cfb(2), ofb(3) },
vector -- Used by CBC, CFB and OFB modes
OCTET STRING (SIZE(8)) OPTIONAL,
numBytes -- Used by CFB and OFB modes
INTEGER OPTIONAL { 1..7 },
key
OCTET STRING (SIZE(16))
}
SymmetricKey ::=
CHOICE {
symmetricKeyRc2
SymmetricKeyRc2,
symmetricKeyRc4
SymmetricKeyRc4,
symmetricKeyDes
SymmetricKeyDes,
symmetricKeyTripleDes
SymmetricKeyTripleDes,
symmetricKeyIdea
SymmetricKeyIdea
}
19. Hash Only Encrypted Signature
The one-way hash (message digest) [6, 21] computation is done after
the assembly of an SNMP packet and the encapsulation header. The
encrypted signature field data octets are set to zero during the
calculation.
Step 1: One-way hash computation.
H = Hash ( Encapsulation-Message including zeroed encrypted
signature field )
Step 2: Sign the computed hash value with the sender's
private key.
S = Sign( H, Sender's Private Key )
Step 3: Encrypt the signature with the receiver's public key.
E = Encrypt( S, Receiver's PublicKey )
20. Hash And Symmetric Key Encrypted Signature
The one-way hash (message digest) [6, 21] computation is done after
the assembly of an SNMP packet and the encapsulation header. The
encrypted signature field data octets are set to zero during the
calculation.
Step 1: One-way hash computation.
H = Hash ( Encapsulation-Message including zeroed encrypted
signature field )
Step 2: Randomly generate a symmetric key.
Step 3: Sign the computed hash value and the symmetric key with
the sender's private key.
S = Sign( H, Symmetric Key, Sender's Private Key )
Step 4: Encrypt the signature with the receiver's public key.
E = Encrypt( S, Receiver's PublicKey )
21. Encrypted Signature Format
This is the format of the above encrypted signatures.
EncryptedSignatureHash ::= {
{
hash
Hash
}
PrivateKeySignature
}
PublicKeyEncryptedData
EncryptedSignatureHashSymmetricKey ::= {
{
SEQUENCE {
hash
Hash,
symmetricKey
SymmetricKey
}
}
PrivateKeySignature
}
PublicKeyEncryptedData
EncryptedSignature ::= {
CHOICE {
encryptedSignatureHash
EncryptedSignatureHash,
encryptedSignatureHashSymmetricKey
EncryptedSignatureHashSymmetricKey
}
}
22. Encrypted Data Format
This is the encrypted SNMP packet. It is encrypted using the
key to a selected symmetric algorithm. The symmetric key
encoding will indicate which algorithm, mode, etc., to use.
EncryptedData ::= [31] IMPLICIT {
encryptedData,
OCTET STRING
}
Note: Some algorithms require the data to be encrypted to be padded.
For example, DES requires data to be in discrete eight (8)
byte blocks. The data may need to be padded out to the
nearest eight byte boundary.
Note: A DES key is 8 octets of data. This consists of 56 bits of
key, and 8 parity bits (one per octet). The key is encoded
as a series of 8 octets written in MSB-first order. The bits
within the key are also encoded in MSB order. For example,
if the encryption key is: (B1,B2,...,B7,P1,B8,...,B14,P2,B15,
...,B49,P7,B50,...,B56,P8) where B1,B2,...,B56 are the key
bits in MSB order, and P1,P2,...,P8 are the parity bits, the
first octet of the key would be B1,B2,...,B7,P1 (with B1 as
the MSbit). [17] (This text was derived from section 6.3.4
in RFC 1510).
23. Distributing and Certifying Encryption Keys
Only the public keys can be distributed by any means. Private keys
can never be distributed. Symmetric keys can only be distributed
when they are first encrypted by the sender's private key and then
by the receiver's public key. Symmetric keys typically have a
restricted lifetime, only for one or a limited series of requests.
An agent can receive and certify a manager's key in one of two ways,
either by the administrator or across the network from a trusted
manager. A manager's public key can be deposited in a secure
location on the agent by an administrator. This should be done
during the agent's initial installation. These keys are then
certified by the person installing them. Each key has a privilege
level associated with it. Note asymmetric key pairs are generated
by each manager, only the public key is registered and certified on
the agent, the private key is never distributed. Once a manager's
public key is registered, certified, and given a privilege level,
then it in turn can use an authenticated SNMP Set to deposit other
public keys. These keys are implicitly certified by this manager
an cannot have privilege levels better than his privilege level.
The highest privilege level is zero, and declines with higher
values.
During the installation of the agent, the installer should generate
its asymmetric key pair using proper key generation techniques
[12, 24, 28]. The public key is then made available to managers via
a MIB variable (securePublicKey). The agent's public key is always
available as a read-only variable (securePublicKey). It is
recommended that managers use an authenticated SNMP Get to retrieve
the agent's public key.
This document specifies an optional MIB table (securePublicKeyTable)
which allows managers to write a public key. Only manager's which
have been previously registered can place a public key in this
table, in essence they are certifying the new key. The very first
public key would have to be set up by a non-SNMP mechanism. This
could be done during the initial set up and configuration of the
agent.
The Agent Public Key
--------------------
securePublicKey OBJECT-TYPE
SYNTAX PublicKey
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The agent's public key.
"
::= { secure 1 }
Table of Certified Manager Public Keys
--------------------------------------
securePublicKeyTable OBJECT-TYPE
SYNTAX SEQUENCE OF securePublicKeyEntry
ACCESS not-accessible
STATUS optional
::= { secure 3 }
securePublicKeyEntry OBJECT-TYPE
SYNTAX SecurePublicKeyEntry
ACCESS not-accessible
STATUS mandatory
INDEX { publicKeyIndex }
::= { securePublicKeyTable 1 }
AuthPublicKeyEntry ::= SEQUENCE {
securePublicKeyIndex
INTEGER,
securePublicKeyPrivilegeLevel
INTEGER,
securePublicKeyIdentifier,
OCTET STRING,
securePublicKey
PublicKey
}
securePublicKeyIndex OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This is an index value."
::= { securePublicKeyEntry 1 }
securePublicKeyPrivilegeLevel OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-write
STATUS mandatory
DESCRIPTION
"This indicates what privileges are
allowed for the manager associated with
this public key. This entry can only be
written using an authenticated Set request
which is accepted by the agent. The highest
privilege level is zero, and the lower the
level the greater the integer value."
::= { securePublicKeyEntry 2 }
securePublicKeyIdentifier OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(8))
ACCESS read-write
STATUS mandatory
DESCRIPTION
"A unique identifier associated with the
public key. It is generated by the
manager. This helps associate the
incoming encrypted variables with the
correct public key to decrypt them. This
entry can only be written using an
authenticated Set request which is
accepted by the agent."
::= { securePublicKeyEntry 3 }
securePublicKeyValue OBJECT-TYPE
SYNTAX PublicKey
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The manager's public key. This is
used by the agent to authenticate the
manager. This entry can only be written
using an authenticated Set request which
is accepted by the agent."
::= { securePublicKeyEntry 4 }
24. Levels of Security
Different implementations of managers and agents need varying grades
of security. An agent controlling a RAID device may need a higher
level of security than one which tells you the configuration of a
user's personal computer. This document divides security into four
levels.
Level A = Authentication and strong privacy.
Level B = Authentication and medium privacy.
Level C = Authentication and weak privacy.
Level D = Authentication only.
A timestamp is an optional part of the authentication information.
If it is included then it has enhanced the level and the letter has
a plus sign appended as follows.
Level A+ = Authentication (w/timestamp) and strong privacy.
Level B+ = Authentication (w/timestamp) and medium privacy.
Level C+ = Authentication (w/timestamp) and weak privacy.
Level D+ = Authentication (w/timestamp) only.
Note: Traps do not support enhanced levels.
There are two possible authentication types, each has a one-way hash
and uses asymmetric encryption. They are numbered as follows.
0 = MD5 and RSA (768 bit modulus or greater) algorithms
1 = SHA and ElGamal algorithms
There are two possible strong privacy types, each uses symmetric
encryption. They are numbered as follows.
0 = Triple DES algorithm
2 = IDEA algorithm
There is one possible medium privacy type, which uses symmetric
encryption. It is numbered as follows.
0 = DES algorithm
There are two possible weak privacy types, each uses symmetric
encryption. They are numbered as follows.
0 = RC2 algorithm (40 bit key or less)
2 = RC4 algorithm (40 bit key or less)
By adding the numbers for authentication and privacy a unique
value will exactly indicate which algorithms are used for each
level.
A0 = MD5, RSA and Triple DES
A1 = SHA, ElGamal and Triple DES
A2 = MD5, RSA and IDEA
A3 = SHA, ElGamal and IDEA
B0 = MD5, RSA and DES
B1 = SHA, ElGamal and DES
C0 = MD5, RSA and RC2
C1 = SHA, ElGamal and RC2
C2 = MD5, RSA and RC4
C3 = SHA, ElGamal and RC4
D0 = MD5 and RSA
D1 = SHA and ElGamal
If the authentication uses a valid timestamp then the security
levels are considered enhanced. Traps do not support enhanced
levels.
A0+ = MD5, RSA, timestamp and Triple DES
A1+ = SHA, ElGamal, timestamp and Triple DES
A2+ = MD5, RSA, timestamp and IDEA
A3+ = SHA, ElGamal, timestamp and IDEA
B0+ = MD5, RSA, timestamp and DES
B1+ = SHA, ElGamal, timestamp and DES
C0+ = MD5, RSA, timestamp and RC2
C1+ = SHA, ElGamal, timestamp and RC2
C2+ = MD5, RSA, timestamp and RC4
C3+ = SHA, ElGamal, timestamp and RC4
D0+ = MD5, RSA and timestamp
D1+ = SHA, ElGamal and timestamp
25. Implementation Requirements of Security Levels
General
-------
The maximum level of security is always determined by the agent.
A manager must send a series of encapsulated SNMP requests at
different levels to determine which level will be accepted by the
agent. The agent will indicate with the error codes what levels it
will accept. If the manager cannot support the level required by
the agent then it cannot communicate with the agent. If an agent
supports multiple levels then the manager may select which level it
wishes to communicate on. Some agents may require a higher level
for some MIB variables and a lower level for others. A manager
should try to seek the highest level it and the agent mutually
support together.
All managers are required to support D0 and D0+. If a manager can
support a higher level then it must also be able to support enhanced
version of that level. For example if it can support B1 then it
must also be prepared to support B1+.
All agents must at least support one of the following levels; A0,
A0+, A2, A2+, B0, B0+, C0, C0+, C2, C2+, D0, D0+. They must support
the securePublicKey variable. They can optionally support the
secureSystemTime variable and the securePublicKeyTable table.
Authentication-only SNMP
------------------------
The easiest USA export license is for authentication-only software.
For this license it is required to implement the agent or manager
with one of the following combinations.
Manager: D0, or D0+, or D0 and D1, or D0+ and D1+.
Agent: D0, or D0+, or D0 and D1, or D0+ and D1+.
Exportable Secure SNMP
----------------------
USA export licenses are usually granted for (weak) encryption
software using RC2 or RC4 with 40 bit keys. For this license it is
required to implement the agent or manager with one of the following
combinations.
Manager: D0, or D0+, or D0 and D1, or D0+ and D1+. Plus C0, or C0+,
or C1, or C1+, or C2, or C2+, or C3, or C3+.
Agent: D0, or D0+, or D0 and D1, or D0+ and D1+. Plus C0, or C0+,
or C1, or C1+, or C2, or C2+, or C3, or C3+.
26. Agent Requirements
An agent must use the same level of security for its response as the
manager used for its request. If the agent cannot or will not
support an algorithm (or key size) then it should return an
appropriate error. It is up to the manager to choose another
security level.
Only for traps can an agent select any level, besides enhanced,
however it is recommended to use the lowest available level. If
possible, D0 is the best since all managers guarentee to support
this level.
For the opaqueValue field it must respond with the exact same value
it received during the request. For traps this field is set to zero.
The timeStamp field should be set to a copy of its internal clock when
creating the response encapsulation header. If no clock is available
then this should be set to zero.
27. Explanation of Certain Design Details
Time Synchronization
--------------------
Time synchronization is quite simple. Each agent is considered
to keep an accurate timer. Any manager which wishes to communicate
with an agent, gets this timer to synchronize with their internal
timer. Once the flow of encapsulated packets has begun, then
the manager can automatically synchronize from the timeStamp
field when receiving a packet from the agent. Each agent
maintains what it considers to be an acceptable amount of delay
from its current time for any incoming packets. Packets
which fall outside this delay range must be returned to the
sender with an error (badTimeStamp) and a current copy of its
internal time in the timeStamp field. This gives the manager
a chance to correct its timestamp and to resubmit its request.
This also makes analyzing errors simpler. Managers do not test time
stamps, they only examine them to resynchronize their internal
timers for each agent they are communicating with. This does expose
managers to a replay attack. There are no real benefits to be
gained by this type of attack, in fact a good SNMP manager protocol
stack implementation should ignore duplicate SNMP responses.
Some agents may not be able to support an accurate timer. In
this case time synchronization is not possible. Any timeStamp
field value sent by the manager can be ignored by the agent.
When the agent responds it sets this field to zero, indicating
that there is no time stamp support. This degrades the
authentication robustness by increasing the possibility of replay
attacks against the agent.
Encrypted Signature
-------------------
The encrypted signature, where the signature contains the one-way
hash and potentially the symmetric key, ensures that only the
authorized sender and receiver can communicate.
Asymmetric Key Identification
-----------------------------
When the receiving an encapsulated SNMP packet with data that
has been signed by a private key, e.g. the hash and possibly the
symmetric key, there is a problem of looking up the correct public
key. All asymmetric algorithm signed or encrypted data, with either
the public or private key respectively, has a unique identifier
prepended to it. This allows the receiver to find the corresponding
key, usually a public key, to verify or decrypt the data. This
unique identifier is generated by whomever created the public and
private key pair. This document recommends that a hash be run over
a pass phrase or text, and then the lower 8 octets are used as the
unique identifier of the keys.
28. Exporting Encryption Software
According to the USA government, cryptography is a munition. You
must obtain the proper export license to sell any software with
cryptography [27]. There are two USA government agencies that
control export of encryption software.
One is the Bureau of Export Administration (BXA) in the Department
of Commerce, authorized by the Export Administration Regulations.
The other is the Office of Defense Trade Controls (DTC) in the State
Department, authorized by the Defense Trade Regulations. The
National Security Agency (NSA) controls the DTC.
The BXA has less stringent requirements. The DTC usually inspects
an application first and can refuse to transfer jurisdiction to BXA.
The Defense Trade Regulations regulates the export sales of
munitions. An encryption product may need approval for every
product revision or even every sale.
The State Department does not approve the export of products with the
DES algorithm. The Software Publishers Association (SPA) has recently
been negotiating with the government to ease the export license
restrictions. A 1992 agreement eased the export license rules for two
ciphers, RC2 and RC4, as long as the key size is 40 bits or less.
Products that implement one of these two algorithms have a much
simpler export approval process, provided that the keys are no more
than 40 bits in size.
Please note that these export rules do not apply to sales within the
USA, or to foreign subsidiaries of USA corporations in friendly
countries, or for financial uses in friendly countries, or to
Canada [22]. There are no restrictions in these cases. However,
they do apply to sales to foreign nationals residing within the USA.
Some foreign countries, most notably France, restrict the import of
encryption software.
29. Exporting Authentication-only Software
It is the stated policy of the NSA not to restrict the export of
authentication products, only encryption products. To export an
authentication-only product approval is subject to showing that the
device cannot easily be converted to an encryption device. The
bureaucratic procedures are much simpler for authentication products
than encryption products. An authentication product needs NSA and
State Department export approval only once.
30. Definitions
SECURE-SNMP DEFINITIONS ::= BEGIN
-- Authenticated or secure encapsulation of SNMP message.
Encapsulation-Message ::=
SEQUENCE {
version -- Version 3 for this RFC.
INTEGER {
version-3(2)
},
opaqueValue -- Manager sets this, agent must
INTEGER, -- echo it back. Traps use 0.
errorStatus -- Response from agent, 0 otherwise.
INTEGER {
noError(0),
generalError(1),
badSignature(2),
unsupportedPublicKey(3),
unsupportedHash(4),
badTimeStamp(5),
badSymmetricKey(6),
tooLargeSymmetricKey(7),
unsupportedSymmetricKey(8),
unsupportedSymmetricMode(9),
noEncryptedDataAllowed(10),
badEncryptedData(11)
},
timeStamp -- Synchronized time value.
INTEGER, -- Agent returns current value.
encryptedSignature -- May contain symmetric key.
EncryptedSignature,
CHOICE {
data -- SNMPv1, SNMPv2, etc., packet
ANY,
encryptedData -- The data encrypted w/symm. key.
EncryptedData
}
}
END
AUTHENTICATION-MIB DEFINITIONS ::= BEGIN
IMPORTS
mgmt
FROM RFC1155-SMI
OBJECT-TYPE
FROM RFC-1212;
-- MIB I and MIB II have the same object identifier.
mib-2 OBJECT IDENTIFIER ::= { mgmt 1 }
secure OBJECT IDENTIFIER ::= { mib-2 111 }
-- Textual conventions
Time ::= INTEGER
-- The date and time expressed as the number of seconds
-- since midnight January 1, 1900 GMT
-- ====================================================================
--
-- Support Variables
--
securePublicKey OBJECT-TYPE
SYNTAX PublicKey
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The agent's public key.
"
::= { secure 1 }
secureSystemTime OBJECT-TYPE
SYNTAX Time
ACCESS read-only
STATUS optional
DESCRIPTION
"This is the Agent's system date and time
expressed as the number of seconds since
midnight January 1, 1900 GMT. The manager
can retrieve this to synchronize its time
stamps. A practical implementation will
allow a certain amount of clock skew when
comparing incoming timestamps with this
value.
"
::= { secure 2 }
-- ====================================================================
--
-- The Public Key Table
--
-- It is optional to implement this table.
--
-- This table is for managers to deposit their public keys with an agent.
-- They must use their private keys to encrypt the hash and time stamps
-- but the agent uses the public keys to decrypt them and thus certify
-- the incoming SNMP request.
--
-- For a public key to be allowed into this table from across the
-- network it will have to be authenticated by a trusted person. This
-- person's public key must already be registered in this table before
-- they can add another person's public key i.e. certifing the new key.
-- This table controls which SNMP requests will be accepted by the
-- agent, and what privilege level will be associated with it. The
-- actual details of how the privilege levels will work and an acceptable
-- certification alogrithm is left up to the agent designer.
securePublicKeyTable OBJECT-TYPE
SYNTAX SEQUENCE OF securePublicKeyEntry
ACCESS not-accessible
STATUS optional
::= { secure 3 }
securePublicKeyEntry OBJECT-TYPE
SYNTAX SecurePublicKeyEntry
ACCESS not-accessible
STATUS mandatory
INDEX { publicKeyIndex }
::= { securePublicKeyTable 1 }
AuthPublicKeyEntry ::= SEQUENCE {
securePublicKeyIndex
INTEGER,
securePublicKeyPrivilegeLevel
INTEGER,
securePublicKeyIdentifier,
OCTET STRING,
securePublicKey
PublicKey
}
securePublicKeyIndex OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This is an index value."
::= { securePublicKeyEntry 1 }
securePublicKeyPrivilegeLevel OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-write
STATUS mandatory
DESCRIPTION
"This indicates what privileges are
allowed for the manager associated with
this public key. This entry can only be
written using an authenticated Set request
which is accepted by the agent. The highest
privilege level is zero, and the lower the
level the greater the integer value."
::= { securePublicKeyEntry 2 }
securePublicKeyIdentifier OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(8))
ACCESS read-write
STATUS mandatory
DESCRIPTION
"A unique identifier associated with the
public key. It is generated by the
manager. This helps associate the
incoming encrypted variables with the
correct public key to decrypt them. This
entry can only be written using an
authenticated Set request which is
accepted by the agent."
::= { securePublicKeyEntry 3 }
securePublicKeyValue OBJECT-TYPE
SYNTAX PublicKey
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The manager's public key. This is
used by the agent to authenticate the
manager. This entry can only be written
using an authenticated Set request which
is accepted by the agent."
::= { securePublicKeyEntry 4 }
END
31. An Example Encoding
We wish to set the following value on an agent.
Object Identifier = 1.3.6.1.4.1.123.5.0
Data Type = Integer
Data = 65
A standard SNMP Set request packet.
30 27 02 01 00 04 06 70 75 62 6C 69 63 A4 1A 02
01 01 02 01 00 02 01 00 30 0F 30 0D 06 08 2B 06
01 04 01 7B 05 00 02 01 41
The authenticated SNMP Set request packet. Using MD5 and
and RSA with a 512 bit modulus.
30 81 C8 02 01 02 02 01 00 02 01 00 02 04 30 9D
96 E5 AC 81 8D 04 08 02 00 00 00 00 00 00 00 04
81 80 80 58 D0 EB 7A C2 71 7B A8 9E 66 28 CD 2D
41 74 4F 6F 3D BE AC 22 6C 25 57 23 3D BF EF CE
21 9B AA 44 02 EA 32 B7 9D 92 BB 88 72 FC 86 32
66 B7 E0 75 3A 0D D6 87 0E 77 37 91 F1 EF B0 D7
F2 75 24 69 8D F2 C8 76 50 62 15 31 6E 7E 8D 9C
16 CD 72 AA 05 8E 1F 18 80 DA 99 54 77 78 DE 8E
2F 2F EA BF 39 A0 92 40 BB F3 E6 79 59 76 2E 49
B5 47 6A 32 0F 50 51 4E 13 A9 88 54 5C 69 1B F8
36 24 30 27 02 01 00 04 06 70 75 62 6C 69 63 A4
1A 02 01 01 02 01 00 02 01 00 30 0F 30 0D 06 08
2B 06 01 04 01 7B 05 00 02 01 41
A secure SNMP Set request packet (it is encrypted). Note the hash
was calculated over both the encapsulation (using a zeroed encrypted
signature field) header and the encrypted packet (ASN.1 encoded).
Using MD5 and RSA with a 512 bit modulus. The symmetric key is RC4
using 40 bits.
30 81 CA 02 01 02 02 01 00 02 01 00 02 04 30 9D
96 E9 AC 81 8D 04 08 02 00 00 00 00 00 00 00 04
81 80 2A 07 77 61 BE E4 9B 16 E6 D0 1A BE 66 B3
B7 F1 71 22 20 7D D2 9F D0 65 12 8C 0B 42 56 52
02 B6 66 C9 3E 82 C5 F7 19 95 C3 D8 8A FB BD 6E
B9 F8 F1 08 47 30 5E 4E 89 9C 9A 0A 3E 47 A2 F9
83 67 9C 03 66 BE D0 16 C2 2C B9 BD 0D 89 BA 84
66 87 2D 33 81 65 CA 4B 2E 7D DA D8 C7 00 4C B3
58 05 43 1F 5A 7D 3B 22 F8 87 94 E8 79 05 76 94
A8 E4 E4 03 CB BF 79 DE DA FE E1 6A 8A 0E 08 C6
BA 8F B1 29 9E 84 36 54 A3 C1 A4 35 3A 34 46 E3
37 01 B2 CB 63 8F DF 21 8C 89 ED 58 81 AB C6 DD
FB 51 A7 F5 A9 A9 E1 39 B3 99 CB 48 85
Note: This example uses a smaller RSA modulus than this document
recommends.
32. Acknowledgements
I would like to thank the following people for their excellent
suggestions and comments.
Don Provan Novell, Inc., USA
Denis Pinkas Bull SA, France
33. References
Request For Comments
--------------------
[1] RFC 1155, Case, J.D., et. al., Structure and Identification of
Management Information for TCP/IP-based Internets.
(SNMPv1), May 1990
[2] RFC 1157, Case, J.D., et. al., Simple Network Management Protocol
(SNMPv1), May 1990
[3] RFC 1158, Rose, M.T., Management Information Base for Network
Management of TCP/IP-based Internets: MIB-II
May 1990
[4] Fougner, R., RFC 1170, Public Key Standards and Licenses, Jan.
1991. Public Key Partners, Inc.
[5] RFC 1212, Rose, M., et al., Concise MIB Definitions, March 1991
[6] RFC 1321, Rivest, R., The MD5 Message-Digest Algorithm.
April 1992.
[7] RFC 1351, Davin, J., et. al., SNMP Administrative Model,
July 1992
[8] RFC 1352, Galvin, J., et. al., SNMP Security Protocols,
July 1992
[9] RFC 1445, Galvin, J., et. al., Administrative Model for version
2 of the Simple Network Management Protocol (SNMPv2).
April 1993.
[10] RFC 1446, Galvin, J., et. al., Security Protocols for version 2
of the Simple Network Management Protocol (SNMPv2).
April 1993.
[11] RFC 1448, Case, J.D., et. al., Protocol Operations for version
2 of the Simple Network Management Protocol (SNMPv2), April
1993.
[12] RFC 1750, Eastlake, D. E., et al., Randomness Recommendations
for Security
Patents
-------
[13] Meyer, C.H. et. al., USA Patent 3,962,539, Product Block Cipher
for Data Security. Held by IBM. Expired.
[14] Lai, X., et. al., European Patent PCT/CH91/00117. Patent
pending in USA. International Data Encryption Algorithm (IDEA).
Held by ETH and Ascom-Tech Ab, Switzerland.
[15] Rivest, R., et al., USA Patent 4,405,829. Cryptographic
Communications System and Method. Held by Public Key Partners.
This is also known as the RSA public key algorithm.
Standards
---------
[16] NBS FIPS PUB 46, "Data Encryption Standard", National Bureau of
Standards, U.S. Deparment of Commerce, Jan. 1977
[17] NBS FIPS PUB 81, "DES Modes of Operation", National Bureau of
Standards, U.S. Deparment of Commerce, Dec. 1980
[18] NBS FIPS PUB 74, "Guidelines for Implementing and Using the
NBS Data Encryption Standard", National Bureau of Standards,
U.S. Deparment of Commerce, Apr. 1981
[19] ANSI X9.17 (Revised), "American National Standard for Financial
Institution Key Management (Wholesale)", American Bankers
Association, 1985
[20] ISO DIS 8732, "Banking Key Management (Wholesale)", Association
for Payment Clearing Services, London, Dec. 1987
[21] NIST FIPS PUB 180, "Secure Hash Standard", National Institute
of Standards and Technology, Federal Information Processing
Standards Publication, U.S. Department of Commerce,
May 11, 1993.
Publications
------------
[22] Hoffman, L., ed., "Building In Big Brother, The Cryptographic
Policy Debate", Springer-Verlag, 1995
[23] Robshaw, M., "Security Estimates for 512-bit RSA", RSA
Laboratories, June 1995.
[24] Schneier, B., "Untangling Public-Key Cryptography", pp. 16-28,
Dr. Dobbs Journal, April 1992.
[25] Schneier, B., "Applied Cryptography", 2nd ed., John Wiley &
Sons, Inc., 1996.
[26] Imported and Exported Defense Articles and Services (ITAR),
Vol. 57, No. 89, Part II, 56 FR 19666, May 7, 1992.
U.S. Department of State, Bureau of Politico-Military Affairs
Code
----
[27] Rivest, R. Ron's Code 2 (RC2) and 4 (RC4). Variable key size
encryption algorithms owned by RSA Data Security, Inc.
Unpublished. (RC4 was stolen and distributed on the Internet.)
[28] Zimmerman, P., Pretty Good Privacy, 2.3a source code, 1994.
34. Glossary of Terms
ASN.1, Abstract Syntax Notation version 1
BXA, Bureau of Export Administration in the Department of Commerce,
authorized by the Export Administration Regulations.
DES, Digital Encryption Standard, a USA symmetric key standard
[13, 16, 17, 18].
DSA, Digital Signature Algorithm, part of DSS, a public key algorithm
DSS, Digital Signature Standard, a USA public key standard
DTC, Office of Defense Trade Controls in the State Department,
authorized by the Defense Trade Regulations.
LUC, Public key algorithm using Lucas functions, invented by Peter
Smith.
IDEA, International Digital Encryption Algorithm, a symmetric key
algorithm [14].
MD, Message Digest, a one-way hash
MIB, Management Information Base, used with SNMP
MIT, Massachusetts Institute of Technology.
NSA, National Security Agency
PDU, Packet Data Unit
PKP, Public Key Partners of Sunnyvale, California, a consortium of
RSADSI, Cylink, Inc., Stanford University and MIT.
RC, Ron's Code
RFC, Request For Comment, Internet standards
RSA, Rivest-Shamir-Adleman, public key algorithm [15]
RSADSI, RSA Data Security Inc.
SHA, Secure Hash Algorithm, a one-way hash
SNMP, Simple Network Management Protocol, see also MIB
SNMPv1, SNMP version 1 (RFCs 1155 1157, 1212)
SNMPv2, SNMP version 2 (RFCs 1441 to 1452)
SNMPSec,SNMP Security (RFCs 1351, 1352)
Security Considerations
Security issues for SNMP authentication and privacy are discussed
in this document.
Author Address
Alexander I. Alten
Alten@Novell.Com
(408) 577-8224
Novell, Inc.
Mail Stop F1-42-D2
2180 Fortune Drive
San Jose, CA 95131
USA
