Internet DRAFT - draft-alten-snmp-sec-encap
draft-alten-snmp-sec-encap
HTTP/1.1 200 OK
Date: Mon, 08 Apr 2002 22:29:33 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Wed, 02 Aug 1995 22:00:00 GMT
ETag: "2e7cd4-13604-301ff560"
Accept-Ranges: bytes
Content-Length: 79364
Connection: close
Content-Type: text/plain
INTERNET DRAFT
Expires in six months
<draft-alten-snmp-sec-encap-00.txt>
Security Encapsulation of SNMP
-------- ------------- -- ----
Alexander. I. Alten
July 30, 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.
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 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 doubly
encrypted using asymmetric (public key) encryption technology, such
as the RSA algorithm [15]. First the sender encrypts 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 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, a combinatorial
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. Distribution might only occur when a manager
and agent 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 imported 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 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. The only asymmetric
algorithms specified are RSA [15] and ElGamal [25]. Symmetric
algorithms use only one key for both encryption and decryption.
The only symmetric algorithms specified are; RC2, RC4 [27], DES [13,
16, 17, 18], Triple DES [20, 21], and IDEA [14].
In summary, for authentication data encryption we use the public
and private keys, while for SNMP packet privacy encryption we use a
symmetric key. Note that full SNMP security requires both encrypted
authentication and SNMP packet 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 prevent an improper manager
from modifying the MIB. Denial of service means a valid manager
could be denied access to an agent.
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 this.
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.
badPublicKey The public key is not registered with
the agent or is malformed or is too
small.
unsupportedPublicKey This type of public key is not
supported. RSA is required for all
implementations.
badHash The one-way hash is invalid, it did not
match the computed hash.
unsupportedHash This one-way hash algorithm is not
supported.
badTimeStamp The agent has an accurate clock and
requires a valid time. The time stamp
is too old or incorrect.
badSymmetricKey The symmetric key is malformed.
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.
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 doubleAsymmetricEncryptedHash is the computed one-way hash
of the entire encapsulation, not including this field, and the
appended SNMP packet (plain or encrypted). It encrypted first
by the sender's private key and then by the receiver's public
key. This is called a double asymmetric encryption.
The final field is the SNMP packet, either plain or encrypted.
If it is encrypted it actually is composed of two fields, the
first being the symmetric key, a double asymmetric encryption,
and the second being the symmetric algorithm encrypted packet.
-- 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),
badPublicKey(2),
unsupportedPublicKey(3),
badHash(4),
unsupportedHash(5),
badTimeStamp(6),
badSymmetricKey(7),
tooLargeSymmetricKey(8),
unsupportedSymmetricKey(9),
noEncryptedDataAllowed(10),
badEncryptedData(11)
},
timeStamp -- Synchronized time value.
INTEGER, -- Agent returns current value.
doubleAsymmetricEncryptedHash -- Encrypted one-way hash value.
DoubleAssymetricEncryptedHash,
CHOICE {
data -- SNMPv1, SNMPv2, etc., packet
ANY,
encryptedData -- The data encrypted w/symm. key.
SymmetricKeyEncryptedData
}
}
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 receive 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. The encrypted hash and error
values are set 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 time stamp. The only exception is
the double encrypted hash field which is ignored during the
calculation.
4. Double encrypt the hash value, first with the manager's private
key, then 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 doubly encrypted hash, first using the agent's
private key, then 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.
2. Compute a hash of the encapsulation header (see below) and the
SNMP packet. The double encrypted hash field is ignored during
the calculation.
3. Compare the computed hash and the decrypted hash. If they are
equal then proceed. Otherwise send an authenticated response
indicating a bad hash 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. The encrypted hash value
is set to zero. Set the error status value. 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 time stamp. The only exception is
the double encrypted hash field which is ignored during the
calculation.
4. Double encrypt the hash value, first with the agent's private
key, then 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 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 double encrypted hash field is ignored during
the calculation.
3. Compare the computed hash and the decrypted 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. The 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 time stamp. The only exception is
the double encrypted hash field which is ignored during the
calculation.
4. Double encrypt the hash value, first with the agent's private
key, then 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 double encrypted hash field is ignored during
the calculation.
3. Compare the computed hash and the decrypted 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 One-Way Hash |
| |
+-------------+ | +----------------------+ | +------------+
| | | | | | | |
| 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 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. The encrypted hash 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 double asymmetric key encrypted hash field which is
ignored during the calculation.
5. Double encrypt the hash value, first with the manager's private
key, then 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 double asymmetric key encrypted hash, first using the
agent's private key, then 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.
2. Compute a hash of the encapsulation header (see below) and the
SNMP packet. The double encrypted hash field is ignored during
the calculation.
3. Compare the computed hash and the decrypted hash. If they are
equal then proceed. Otherwise send a secure response indicating
a bad hash 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. Decrypt the symmetric key, first using the agent's private key
and then the manager's public key. Then ASN.1 decode and decrypt,
using the symmetric key, the SNMP packet.
Note: If any errors occur, such as a bad public key, 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. The encrypted hash 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. The only exception
is the double asymmetric key encrypted hash field which is
ignored during the calculation.
5. Double encrypt the hash value, first with the agent's private
key, then 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 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 double encrypted hash field is ignored during
the calculation.
3. Compare the computed hash and the decrypted 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. ASN.1 decode and decrypt, using the symmetric key, 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 hash, 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 double encrypted hash field which is ignored during the
calculation.
4. Double encrypt the hash value, first with the agent's private
key, then 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 double encrypted hash field is ignored during
the calculation.
3. Compare the computed hash and the decrypted 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. ASN.1 decode and decrypt, using the symmetric key, the SNMP
packet.
Secure SNMP Transaction or Trap
+--------------------------+
| |
| Encapsulation |
| Header |
| using an |
| Encrypted One-Way Hash |
| |
+-------------+ | +----------------------+ | +------------+
| | | | | | | |
| | | | 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,
exponent -- 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 Encrypted Data Format
This is the format of the private key encrypted data format [14].
For this document the encrypted data will consist only of a
calculated hash or 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.
PrivateKeyEncryptedDataRsa ::= [8] IMPLICIT SEQUENCE {
keyIdentifier
Hash (SIZE(8)),
encryptedData,
OCTET STRING
}
PrivateKeyEncryptedDataElGamal ::= [9] IMPLICIT SEQUENCE {
keyIdentifier
Hash (SIZE(8)),
encryptedData,
OCTET STRING
}
PrivateKeyEncryptedData ::=
CHOICE {
privateKeyEncryptedDataRsa
PrivateKeyEncryptedDataRsa,
privateKeyEncryptedDataElGamal
PrivateKeyEncryptedDataElGamal
}
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
public key encrypted hash or symmetric key. This is called double
encryption. 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
Hash (SIZE(8)),
encryptedData,
OCTET STRING
}
PublicKeyEncryptedDataElGamal ::= [13] IMPLICIT SEQUENCE {
keyIdentifier
Hash (SIZE(8)),
encryptedData,
OCTET STRING
}
PublicKeyEncryptedData ::=
CHOICE {
privateKeyEncryptedDataRsa
PrivateKeyEncryptedDataRsa,
privateKeyEncryptedDataElGamal
PrivateKeyEncryptedDataElGamal
}
The RSA [15] and ElGamal [25] algorithms are the only ones defined.
18. Encrypted Hash Format
The one-way hash (message digest) [6, 21] computation is done
during after the assembling of an SNMP packet and the encapsulation
header. The encrypted hash field octets are set to zero during
the calculation.
Step 1: One-way hash computation:
M = Hash ( Encapsulation-Message, not including
doubleEncryptedHash field )
Step 2: Encrypting the computed hash value with the sender's
private key.
C1 = Encrypt( M, Sender's Private Key )
Step 3: Encrypting the private key encrypted hash value with the
receiver's public key.
C2 = Encrypt( C1, Receiver's PublicKey )
DoubleAsymmetricEncryptedHash ::= {
{
{
hash,
Hash
},
PrivateKeyEncryptedData
},
PublicKeyEncryptedData
}
19. 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), ofb(2), cfb(3) },
vector -- Used by CBC
INTEGER OPTIONAL,
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 {
key
OCTET STRING (SIZE(16))
}
SymmetricKey ::=
CHOICE {
symmetricKeyRc2
SymmetricKeyRc2,
symmetricKeyRc4
SymmetricKeyRc4,
symmetricKeyDes
SymmetricKeyDes,
symmetricKeyTripleDes
SymmetricKeyTripleDes,
symmetricKeyIdea
SymmetricKeyIdea
}
20. Symmetric Key Encrypted Data Format
This is the format of the symmetric key encrypted data format.
For this document the encrypted data will consist only of a
SNMP packet.
DoubleAsymmetricEncryptedSymmetricKey ::= {
{
{
symmetricKey,
SymmetricKey
},
PrivateKeyEncryptedData
},
PublicKeyEncryptedData
}
SymmetricKeyEncryptedData ::= [31] IMPLICIT SEQUENCE {
doubleAsymmetricEncryptedSymmetricKey,
DoubleAsymmetricEncryptedSymmetricKey,
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).
21. 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 }
22. 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
23. 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+.
24. 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.
25. 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.
Double Asymmetric Encryption
----------------------------
The double asymmetric encryption of the hash and 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 encrypted by a private key, the hash and the symmetric
key, there is a problem of looking up the correct public key.
All asymmetic encrypted data, encrypted with either the public or
private key, has a unique identifier prepended to it. This allows
the receiver to find the corresponding key, usually a public key,
to 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.
26. 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.
27. 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.
28. 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),
badPublicKey(2),
unsupportedPublicKey(3),
badHash(4),
unsupportedHash(5),
badTimeStamp(6),
badSymmetricKey(7),
tooLargeSymmetricKey(8),
unsupportedSymmetricKey(9),
noEncryptedDataAllowed(10),
badEncryptedData(11)
},
timeStamp -- Synchronized time value.
INTEGER, -- Agent always returns current value.
doubleAsymmetricEncryptedHash -- Encrypted one-way hash value.
DoubleAssymetricEncryptedHash,
CHOICE {
data -- SNMPv1, SNMPv2, etc., packet
ANY,
encryptedData -- The data encrypted w/symm. key.
SymmetricKeyEncryptedData
}
}
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
29. 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
The variable binding ASN.1 encoding.
30 0D 06 08 2B 06 01 04 01 7B 05 00 02 01 41
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
Using RSA, lets say that our manager's private key is <d=79,
n=3337> and it's public key is <e=1019, n=3337>. The agent has our
public key. The largest power of two less than 3337 is 2048 (2^11),
which means any data to be encrypted should be broken into blocks of
11 bits each.
To add authentication we need to build the encapsulation header and
then calculate the hash.
The version value is 2, the opaque value is 0, and the error status
is 0. For this example the data is not encrypted so the encrypted
symmetric key is null.
Say the time stamp is 2998021248 seconds (roughly Jan. 1995).
In hexadecimal it is B2B22C80.
The variable binding ASN.1 encoding of the time stamp.
02 04 B2 B2 2C 80
The MD5 hash calculation is over the following octets, without the
doubly encrypted hash field.
30 38 02 01 02 02 01 00 02 01 00 02 04 B2 B2 2C
80 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 128 bit MD5 hash result (message digest).
54 E8 BE 7B 9A 03 F3 6C B7 14 21 58 3D A7 92 F5
The ASN.1 encoding of it.
A0 10 54 E8 BE 7B 9A 03 F3 6C B7 14 21 58 3D A7
92 F5
Break it into thirteen 11-bit data chunks.
M13 M12 M11 M10 M9 M8 M7 M6 M5 M4 M3 M2 M1
2A 3A2 7CF 39A 1F 4DB 16E 142 AC F6 4F2 2F5 (hex)
42 930 1999 922 31 1243 366 322 172 246 1266 757 (dec)
C1 = 757^79 (mod 3337) = 599 (257 hex)
C2 = 1266^79 (mod 3337) = 1299 (513 hex)
C3 = 246^79 (mod 3337) = 3248 (CB0 hex)
C4 = 172^79 (mod 3337) = 1468 (5BC hex)
C5 = 322^79 (mod 3337) = 2929 (B71 hex)
C6 = 366^79 (mod 3337) = 1055 (41F hex)
C7 = 1243^79 (mod 3337) = 1155 (483 hex)
C8 = 31^79 (mod 3337) = 3301 (CE5 hex)
C9 = 922^79 (mod 3337) = 70 (046 hex)
C10 = 1999^79 (mod 3337) = 1836 (72C hex)
C11 = 930^79 (mod 3337) = 3029 (BD5 hex)
C12 = 42^79 (mod 3337) = 2973 (B9D hex)
C13 = 888^79 (mod 3337) = 1655 (677 hex)
Recombining the thirteen 12-bit encrypted data chunks gives the
manager's private key encrypted MD5 hash.
06 77 B9 DB D5 72 CD 4F CE 54 83 41 FB 71 5B CC
B0 51 32 57
The the ASN.1 encoding of it (with key identifier).
A8 20 A0 08 7B 9A 03 F3 6C B7 14 21 04 12 06 77
B9 DB D5 72 C0 46 CE 54 83 41 FB 71 5B CC B0 51
32 57
In turn, this is encrypted by the agent's public key,
2A 3A 27 CF 39 A1 F4 02 04 B2 DB 16 E1 42 AC F6
4F 22 F5 B2 2C 80 2B A3 6F BD 72 61 FC 5F 14 B5
3A AC FA
And then ASN.1 encoded.
AC 2F A0 08 9B BD 5D DC F4 EC 45 38 04 23 2A 3A
27 CF 39 A1 F4 02 04 B2 DB 16 E1 42 AC F6 4F 22
F5 B2 2C 80 2B A3 6F BD 72 61 FC 5F 14 B5 3A AC
FA
The authenticated SNMP Set request packet.
30 69 02 01 02 02 01 00 02 01 00 02 04 B2 B2 2C
80 AC 2F A0 08 9B BD 5D DC F4 EC 45 38 04 23 2A
3A 27 CF 39 A1 F4 02 04 B2 DB 16 E1 42 AC F6 4F
22 F5 B2 2C 80 2B A3 6F BD 72 61 FC 5F 14 B5 3A
AC FA 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 (minus hash field) header
and the encrypted packet (ASN.1 encoded). The symmetric key is RC4
using 40 bits (5 octets, 6 when encrypted by an asymmetric key).
30 84 02 01 02 02 01 00 02 01 00 02 04 B2 B2 2C
80 AC 2F A0 08 9B BD 5D DC F4 EC 45 38 04 23 F9
B2 7F 58 6B 12 BA F2 F6 2F 51 0F 24 B2 3A CA 7B
AD F2 0F 31 24 35 CC 2A 44 2A 6F CB 60 4E 21 5C
B1 1D BF 01 41 AC 14 A2 12 A0 08 83 54 CE 4F CD
D5 DB B9 04 06 3A 7C 91 42 2D 6E B1 27 5A B4 6F
16 A2 A4 22 C9 01 B4 32 6B BD 21 4E 22 53 20 CA
C8 12 CA FF 1D 57 FF 72 0F BB 32 AF F6 4F 9C E4
75 4B 6F 02 23 C9
Note: This example uses smaller RSA keys than this document
recommends.
30. Acknowledgements
31. 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] ??, 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", John Wiley & Sons, 1994.
[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.
32. 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.
Advanced Access Applications Division
Member of Technical Staff
Mail Stop F1-42-D2
2180 Fortune Drive
San Jose, CA 95131
USA
