INTERNET-DRAFT Expires in six months Security Encapsulation of SNMP -------- ------------- -- ---- 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