idnits 2.17.1 draft-alten-snmpv2-sec-encap-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 2028 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 10 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** There are 2 instances of lines with control characters in the document. ** The abstract seems to contain references ([2], [11]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 995: '... OCTET STRING OPTIONAL (SIZE (8)),...' RFC 2119 keyword, line 997: '... INTEGER OPTIONAL { 1..7 },...' RFC 2119 keyword, line 1006: '... OCTET STRING (SIZE (4)) OPTIONAL,...' RFC 2119 keyword, line 1008: '... OCTET STRING (SIZE (4)) OPTIONAL,...' RFC 2119 keyword, line 1021: '... OCTET STRING (SIZE(8)) OPTIONAL,...' (1 more instance...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Line 125 has weird spacing: '...ibution and t...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 6, 1995) is 10398 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: '0' is mentioned on line 829, but not defined == Missing Reference: '31' is mentioned on line 1127, but not defined == Unused Reference: '7' is defined on line 1807, but no explicit reference was found in the text == Unused Reference: '23' is defined on line 1873, but no explicit reference was found in the text == Unused Reference: '26' is defined on line 1882, but no explicit reference was found in the text ** Downref: Normative reference to an Historic RFC: RFC 1157 (ref. '2') ** Obsolete normative reference: RFC 1158 (ref. '3') (Obsoleted by RFC 1213) ** Downref: Normative reference to an Informational RFC: RFC 1170 (ref. '4') ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. '6') ** Downref: Normative reference to an Historic RFC: RFC 1351 (ref. '7') ** Downref: Normative reference to an Historic RFC: RFC 1352 (ref. '8') ** Downref: Normative reference to an Historic RFC: RFC 1445 (ref. '9') ** Downref: Normative reference to an Historic RFC: RFC 1446 (ref. '10') ** Obsolete normative reference: RFC 1448 (ref. '11') (Obsoleted by RFC 1905) ** Obsolete normative reference: RFC 1750 (ref. '12') (Obsoleted by RFC 4086) -- Possible downref: Non-RFC (?) normative reference: ref. '13' -- Possible downref: Non-RFC (?) normative reference: ref. '14' -- Possible downref: Non-RFC (?) normative reference: ref. '15' -- Possible downref: Non-RFC (?) normative reference: ref. '16' -- Possible downref: Non-RFC (?) normative reference: ref. '17' -- Possible downref: Non-RFC (?) normative reference: ref. '18' -- Possible downref: Non-RFC (?) normative reference: ref. '19' -- Possible downref: Non-RFC (?) normative reference: ref. '20' -- Possible downref: Non-RFC (?) normative reference: ref. '21' -- Possible downref: Non-RFC (?) normative reference: ref. '22' -- Possible downref: Non-RFC (?) normative reference: ref. '23' -- Possible downref: Non-RFC (?) normative reference: ref. '24' -- Possible downref: Non-RFC (?) normative reference: ref. '25' -- Possible downref: Non-RFC (?) normative reference: ref. '26' -- Possible downref: Non-RFC (?) normative reference: ref. '27' -- Possible downref: Non-RFC (?) normative reference: ref. '28' Summary: 23 errors (**), 0 flaws (~~), 9 warnings (==), 18 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT 2 Expires in six months 4 Security Encapsulation of SNMP 5 -------- ------------- -- ---- 6 8 Alexander. I. Alten 10 November 6, 1995 12 Abstract 14 This document proposes a practical solution for the security 15 of SNMP packets. It allows any SNMP packet to be transmitted 16 with strong authentication information. Packets can be optionally 17 encrypted for full security. This encapsulation protocol is 18 designed to allow implementations to meet USA export requirements. 19 It supports SNMPv1 [2], SNMPv2 [11], and will support any future 20 SNMP protocol enhancements. It can be added transparently so that 21 investment in existing SNMP protocol stacks can be preserved. 23 Administration is kept simple, in particular public key management 24 and time synchronization. This encapsulation scales well to large 25 numbers of managers and agents. It is designed to facilitate 26 implementation and to minimize troubleshooting with extensive 27 error reporting mechanisms. 29 Status of this Memo 31 This document is an Internet-Draft. Internet-Drafts are working 32 documents of the Internet Engineering Task Force (IETF), its 33 areas, and its working groups. Note that other groups may also 34 distribute working documents as Internet-Drafts. 36 Internet-Drafts are draft documents valid for a maximum of six 37 months and may be updated, replaced, or obsoleted by other 38 documents at any time. It is inappropriate to use Internet- 39 Drafts as reference material or to cite them other than as 40 ``work in progress.'' 42 To learn the current status of any Internet-Draft, please check 43 the ``1id-abstracts.txt'' listing contained in the Internet- 44 Drafts Shadow Directories on ftp.is.co.za (Africa), 45 nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), 46 ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 48 1. Introduction 50 When devices, containing sensitive or critical data, are attached to 51 a computer network the possibility arises in which an unauthorized 52 person may tamper, alter, review or destroy that data. Using SNMP to 53 configure and manage the device is a powerful and useful mechanism. 54 It is a real convenience and advantage to be able administer any 55 device across a computer network. However this same technology can 56 also allow a stranger to damage or manipulate the device without the 57 owner's permission. This person could be malicious, or simply 58 ignorant of the damage he is causing. 60 In the electronic world of computer networks, encryption technology 61 provides the only real solution of preventing unauthorized access 62 to the device, while at the same time allowing authorized people to 63 access it from their desks anywhere in the world. 65 Most commercial software applications are using the SNMP version 1 66 (SNMPv1) [1, 2, 3] network management protocol to allow remote 67 administration of a device. SNMPv1 is usually chosen because the 68 technology is proven and there are many available and robust 69 commercial implementations. SNMPv1 is a transaction protocol with 70 a pair of read requests, called Get and Get Next, and a write request, 71 called a Set. In general the most critical transaction request is 72 the Set since it can do serious damage to the data inside a device. 73 A later version of the protocol, SNMP version 2 (SNMPv2) [9, 10, 11], 74 adds some new read requests; Get Bulk and Inform. To prevent an 75 unauthorized SNMP transaction we must use encryption technology. 77 This document describes an encapsulation protocol for SNMP which 78 provides authentication and data privacy capabilities. Existing 79 implementations of SNMP can be easily supported, along with any 80 future enhancements to SNMP. This encapsulation is orthogonal to 81 any new SNMP PDU types or mechanisms to control MIB access. It is 82 designed to be easy to implement with a modest administrative 83 overhead. 85 2. Technical Overview of the Protocol 87 This protocol encapsulates any SNMP protocol. Using a hybrid 88 encryption approach, it provides either authentication-only or 89 secure SNMP transactions. It acts like a preprocessor to a SNMP 90 protocol, providing its own mechanisms for reporting errors, such 91 as an authentication failure. This document specifies the 92 encapsulation header format which contains a version identifier, an 93 opaque value, an error value, a time stamp, and an encrypted hash. 94 The SNMP packet is appended, either as plain data or as encrypted 95 data. 97 The signed and encrypted hash provides the most critical part of the 98 authentication of the SNMP packet. It binds the entire encapsulation 99 and SNMP packet together and ensures that it cannot be tampered with 100 on its journey from the sender to the receiver. It is signed and 101 encrypted using asymmetric (public key) encryption technology, such 102 as the RSA algorithm [15]. First the sender signs the hash with 103 his private key, then he encrypts it with the receiver's public key. 104 This ensures that only the correct receiver can recover the hash 105 from the encapsulation, by decrypting first with his private key and 106 then verifying it with the sender's public key, authenticating the 107 sender. This model of authentication is simple and robust. 109 The SNMP packet itself can be kept in its original ASN.1 encoding 110 or it can be encrypted with a symmetric encryption algorithm, such 111 as DES [13, 16, 17, 19] or RC4 [27]. This type of algorithm is 112 chosen because it is much faster than an asymmetric one. For 113 example DES is roughly 1000 times faster than RSA. Asymmetric 114 algorithms are chosen because the public portion of the keys can be 115 easily distributed over a network without compromising data 116 encrypted by the private portion. Since these algorithms are very 117 slow, only small pieces of data are encrypted with them, like 118 one-way hashes, timestamps and symmetric keys. A fully secure SNMP 119 packet would be authenticated and encrypted. 121 The agent MIB extensions are primarily to facilitate the exchange 122 of public keys. A table is specified where managers can deposit 123 their public keys. Also managers can retrieve the agent's public 124 key. The agent's timer value can be retrieved. Public key 125 distribution and time synchronization issues are more fully 126 discussed below. 128 This protocol has been designed with export licensing in mind. For 129 example an implementor may choose to do only authentication, the 130 SNMP packet is never encrypted. This would be the easiest 131 implementation to license. If encryption of the SNMP packet is 132 required, then the implementor may choose to use RC2 or RC4 with 133 40 bit keys. This would qualify for an export license. 135 This protocol has been designed to facilitate implementation 136 and in-the-field troubleshooting. Encryption technology can make 137 SNMP protocol transactions very difficult to analyze by obscuring 138 encodings and other critical data. As much data as possible is 139 unencrypted, such as the time stamp and the error status, to assist 140 the implementor or the administrator when they are trying to fix a 141 problem. By providing an encapsulation to existing SNMP protocol 142 machinery, which has been in use and field proven, problems can be 143 isolated and solved more easily. 145 3. Comparison With SNMPv2 Security 147 Both SNMPv2 and this proposal use encapsulation to provide 148 authentication and privacy of SNMP packets. However this proposal 149 diverges from SNMPv2 in how authentication is performed. SNMPv2, 150 after stripping away the details, uses a symmetric key algorithm, 151 DES, to provide authentication. This proposal uses an asymmetric 152 (public key) algorithm, such as RSA. This choice significantly 153 simplifies the exchange and maintenance of authentication 154 information. SNMPv2 relies on a mechanism of preconfiguring parties 155 on each agent and manager which wish to communicate, e.g. setting up 156 the DES key for each pair. DES keys cannot be freely sent across 157 the network, they must be given out either by hand or by some other 158 secure mechanism. In contrast, this proposal only requires that the 159 agent collect, possibly remotely across the network, public keys of 160 any managers that it will allow to communicate with it. Managers 161 simply get the agent's public key when they wish to communicate with 162 it. SNMPv2 becomes difficult to administer as the numbers of agents 163 and managers wishing to communicate increases, an exponential 164 explosion of DES keys must be created and distributed. For this 165 proposal the number of public keys remains equal to the total number 166 of agents and managers. In addition, distribution might only occur 167 when a manager and agent actually need to communicate. 169 For software which encrypts user data it is difficult to obtain 170 a US export license and many countries, notably France, will not 171 allow it to be used by their citizens without severe restrictions. 172 SNMPv2 uses DES to provide privacy for SNMP PDUs. This proposal 173 recommends RC2 or RC4 with 40 bit keys to provide privacy for SNMP 174 packets, DES is an optional implementation. It very difficult, if 175 not impossible, to get a US export license for DES. RC2 or RC4 with 176 40 bit keys (or less) can be exported from the USA. 178 Unlike SNMPv2 this proposal encapsulates an entire SNMP packet. 179 This means that it can provide authentication and privacy to 180 existing SNMPv1 packets as well as SNMPv2 packets. This is 181 important since there is a large installed base of SNMPv1 managers 182 and agents. The impact on SNMPv1 protocol stack machinery should be 183 negligible allowing easy upgrades. It should be able to support any 184 future versions of SNMP. 186 In summary this proposal provides three advantages over SNMPv2. 187 1. Authentication (key distribution) is simpler and scales better. 188 2. Export licenses can be obtained when encrypting data (privacy). 189 3. Also provides security for SNMPv1. 191 4. What This Document Does Not Discuss 193 This document does not discuss the following. 195 1. Patent licenses or royalties. 196 2. Encryption theory or background. 197 3. Operating system security policy. 198 4. Legal policy. 199 5. Generating random numbers. 200 6. Generating encryption keys. 201 7. Encrypting and storing private asymmetric encryption keys. 202 8. Encryption key escrow. 204 5. What This Document Does Discuss 206 This document discusses SNMP authentication and privacy. 208 1. USA export rules governing the export of encryption software. 209 2. Network security policy (limited). 210 3. Computing, signing and encrypting hashes. 211 4. Synchronizing time. 212 5. Encryption key identification. 213 6. Distributing encryption keys. 214 7. Certifying encryption keys (simple). 215 8. Encrypting SNMP packets. 217 6. Encryption Nomenclature 219 There are two types of encryption algorithms; asymmetric and 220 symmetric. Asymmetric algorithms use two keys, a public and a 221 private key. If one of the keys is used to encrypt data, then 222 only the other key may decrypt the data. If one of the keys is 223 used to sign the data, then only the other key may verify the 224 signature of the data. For some algorithms, like RSA [15], 225 these pair of operations use the exact same mathematical formula. 226 I.e. signing and encrypting with the same key are identical 227 operations, creating the same multiprecision integer result. For 228 other algorithms, like ElGamal [25], these are not the same 229 mathematical formula. I.e. signing and encrypting with the same key 230 will create different multiprecision integer results. The only 231 asymmetric algorithms specified are RSA and ElGamal. 233 Symmetric algorithms use only one key for both encryption and 234 decryption of bulk data, such as an SNMP packet. The only 235 symmetric algorithms specified are; RC2, RC4 [27], DES [13, 16, 17, 236 18], Triple DES [25], and IDEA [14]. 238 In summary, for authentication, an encrypted signature, we use the 239 public and private keys. While for privacy, an encrypted SNMP 240 packet, we use a symmetric key. Note that full SNMP security 241 requires both authentication and privacy. 243 7. Security Nomenclature 245 Security is usually defined as all of the following. 247 1. Authentication, integrity 248 2. Privacy, secrecy, confidential 249 3. Availability, denial of service 250 4. Access control, authorization 251 5. Non-repudiation 253 In the context of this document they are defined as follows. 255 1. Authentication or integrity means that sender and the receiver 256 are known to each other, via asymmetric encryption, such as RSA, 257 and are associated with this encapsulated packet. 259 2. Privacy, secrecy or confidential means that the data payload of 260 this encapsulation packet, e.g. the SNMP packet, is encrypted 261 with a symmetric encryption algorithm, such as DES. 263 3. Availability means that the agent can ensure that it is still 264 functioning properly after an illegal attempt to modify its 265 MIB content. Denial of service means a valid manager could be 266 denied access to an agent. Unfortunately this document cannot 267 propose any solution for this attack. 269 4. Access control or authorization means that a manager may only 270 have access to portions of an agent's MIB or may only be able to 271 perform limited SNMP operations. This document does not describe 272 this. The underlying SNMP protocol inside the encapsulation 273 supports this. 275 5. Non-repudiation means that a manager cannot deny they performed 276 an operation on the agent. This document provides the foundation 277 mechanism for this (authentication), but does not describe how 278 to do it. 280 8. Requirements for Authenticated SNMP Packets 282 1. To prevent an unauthorized manager from initiating a destructive 283 operation on an agent e.g. a malicious Set request. 285 2. To allow an agent to accurately distinguish between management 286 stations or individuals. This will allow an agent to tailor 287 access rights to portions of a MIB. 289 3. To meet USA export requirements for software containing 290 encryption which is used only for authentication purposes. 292 9. Requirements for Private SNMP Packets 294 1. To prevent sensitive information from being read by unauthorized 295 recipients. 297 2. To allow the implementer to meet USA export requirements for 298 software containing encryption which is used for data 299 encryption purposes. 301 10. Secure Encapsulation Header 303 The secure encapsulation header for an SNMP packet contains 304 information to support the protocol operations and to provide 305 authentication of the sender. The SNMP packet is appended to it 306 either in plain or encrypted form. 308 The version field indicates the protocol described in this 309 document. The specified value is two. 311 The opaqueValue field allows the manager to match requests 312 with agent responses. This is needed in particular when the 313 SNMP packet is encrypted, shrouding the request identifer. 314 It can be any value, except zero. A simple count is recommended. 315 Traps set this to zero. 317 The errorStatus field is used by the agent to report any 318 encapsulation processing errors. 320 Error Name Description 321 ----------------------- --------------------------------------- 322 noError Request encapsulation was correct. 323 Traps always use this code. 325 generalError An unspecified error occured. 327 badSignature The manager's public key is not 328 registered with the agent. Or the 329 signature is malformed; the one-way 330 hash is invalid or the decryption 331 failed to produce the correct 332 signature. This means that the 333 signature verification failed. 335 unsupportedPublicKey This type of public key is not 336 supported. RSA is required for all 337 implementations. This means that the 338 signature verification failed. 340 unsupportedHash This one-way hash algorithm is not 341 supported. 343 badTimeStamp The agent has an accurate clock and 344 requires a valid time. The manager's 345 time stamp is too old or incorrect. 347 badSymmetricKey The symmetric key is malformed. This 348 means the SNMP packet could not be 349 recovered from the encrypted data. 351 tooLargeSymmetricKey The agent does not allow too large a 352 symmetric key. This is to allow 353 encryption of the SNMP packet 354 conforming to export restrictions. 356 unsupportedSymmetricKey This symmetric key is not supported. 357 If encryption of the SNMP packet is 358 supported then RC2 and RC4, up to 40 359 bit key sizes, must be implemented. 361 unsupportedSymmetricMode This symmetric mode is not supported. 362 If encryption of the SNMP packet is 363 supported then ECB mode must be 364 supported. Other modes are optional. 366 noEncryptedDataAllowed The agent does not allow encrypted 367 SNMP packets. 369 badEncryptedData After decryption the data could not 370 be interpreted as a valid SNMP packet. 372 The timeStamp field is to reduce the probability of an authentic 373 packet being replayed. It represents the number of seconds since 374 midnight January 1, 1900 GMT. The manager fills this out with 375 a time value. The agent checks to see if this time is what it 376 expects i.e. the timestamp falls within a certain delay period. 377 This interval is not specified by this document. It is recommended 378 that it be configurable value on the agent. Some agents may not 379 have a reliable timer available. In this case the field can be 380 ignored by the agent. The return value should be an accurate copy 381 of the agent's timer when the response encapsulation is created. 382 If no reliable timer is available, then this field should be set to 383 zero by the agent. 385 The encryptedSignature is the computed one-way hash of the entire 386 encapsulation, not including this field, and the appended SNMP 387 packet (plain or encrypted). It is signed first by the sender's 388 private key and then encrypted by the receiver's public key. This 389 is called an encrypted signature. If the SNMP packet is encrypted 390 then the symmetric key is included with the hash before the 391 signature is created. 393 The final field is the SNMP packet, either plain or symmetric 394 algorithm encrypted. 396 -- Authenticated or secure encapsulation of SNMP message. 398 Encapsulation-Message ::= 399 SEQUENCE { 400 version -- Version 3 for this RFC. 401 INTEGER { 402 version-3(2) 403 }, 405 opaqueValue -- Manager sets this, agent must 406 INTEGER, -- echo it back. Traps use 0. 408 errorStatus -- Response from agent, 0 otherwise. 409 INTEGER { 410 noError(0), 411 generalError(1), 412 badSignature(2), 413 unsupportedPublicKey(3), 414 unsupportedHash(4), 415 badTimeStamp(5), 416 badSymmetricKey(6), 417 tooLargeSymmetricKey(7), 418 unsupportedSymmetricKey(8), 419 unsupportedSymmetricMode(9), 420 noEncryptedDataAllowed(10), 421 badEncryptedData(11) 422 }, 424 timeStamp -- Synchronized time value. 425 INTEGER, -- Agent returns current value. 427 encryptedSignature -- May contain symmetric key. 428 EncryptedSignature, 430 CHOICE { 431 data -- SNMPv1, SNMPv2, etc., packet 432 ANY, 433 encryptedData -- The encrypted SNMP packet. 434 EncryptedData 435 } 437 } 439 11. Authentication-only SNMP 441 Initially the sender, either a manager or agent, generates a public 442 and private key pair. The manager then registers its public key 443 with the agent. This registration can be done using SNMP or by 444 another mechanism. The manager can retrieve the agent's public key 445 using SNMP or by another mechanism. Once this exchange has taken 446 place then authenticated SNMP packets can be emitted and received. 448 Authenticated Requests 449 ---------------------- 451 When the manager wishes to send an authenticated SNMP request packet 452 the following steps need to be followed. 454 1. Retrieve a current time from the agent or use an internal timer 455 if the manager is confident that it is synchronized with the 456 agent. 458 2. Construct the encapsulation header and append the SNMP packet. 459 Set the encrypted signature and error values to zero. The opaque 460 value is set to some useful value, typically a unique count. 462 3. Compute a hash of the encapsulation header (see below) and 463 the SNMP packet. Everything must already be in its ASN.1 464 encoded form, including the current time stamp. 466 4. Sign the hash value with the manager's private key, then encrypt 467 the resulting signature with the agent's public key. This not 468 only authenticates the manager to the agent, but prevents a replay 469 attack against another agent which has also registered this 470 manager's public key. 472 When the agent receives this authenticated SNMP request packet, the 473 following steps are followed. 475 1. Decrypt the encrypted signature using the agent's private key, 476 then verify the signature with the manager's public key. If the 477 manager's public key is not registered then issue an authenticated 478 response indicating that a bad public key was encountered. If 479 the decryption or verification fails then send an appropriate 480 error response back to the sender. 482 2. Compute a hash of the encapsulation header (see below) and the 483 appended SNMP packet. The encrypted signature field is zeroed 484 during the calculation. 486 3. Compare the computed hash and the received hash. If they are 487 equal then proceed. Otherwise send an authenticated response 488 indicating a bad signature was encountered. 490 4. Check the time stamp. The agent should allow for network delays 491 time skews. If the time stamp is within an acceptable delay 492 period (this can be a configurable value on the agent) then 493 proceed. Otherwise send an authenticated response indicating 494 a bad time stamp was encountered. 496 Note: If any errors occur, such as a bad public key, then the 497 agent constructs a new encapsulation header and sends it and the 498 data (the SNMP packet) back to the manager. 500 Authenticated Responses 501 ----------------------- 503 When the agent issues an authenticated SNMP response packet, the 504 following steps are followed. 506 1. Use an internal timer (secureSystemTime) to set the time stamp. 507 This can be used to synchronize the manager's timer. 509 2. Construct the encapsulation header and append the SNMP packet. 510 The encrypted signature and error values are set to zero. The 511 opaque value is set to some useful value, typically a unique 512 count. Copy the opaque value from the original request 513 encapsulation header to this one. 515 3. Compute a hash of the encapsulation header (see below) and 516 the SNMP packet. Everything must already be in its ASN.1 517 encoded form, including the current time stamp. 519 4. Sign the hash value with the agent's private key, then encrypt it 520 with the manager's public key. This not only authenticates 521 the agent to the manager, but prevents a replay attack against 522 another manager. 524 When the manager receives this authenticated SNMP response packet, the 525 following steps are followed. 527 1. Decrypt the encrypted signature using the manager's private key, 528 then verify it with the agent's public key. If the decryption or 529 verification fails then ignore the packet and optionally report 530 the error back up the protocol stack. 532 2. Compute a hash of the encapsulation header (see below) and the 533 SNMP packet. The encrypted signature field is zeroed during 534 the calculation. 536 3. Compare the computed hash and the received hash. If they are 537 equal then proceed. If not then ignore the packet and optionally 538 report the error back up the protocol stack. 540 4. The time stamp can be used to resynchronize the manager's timer. 542 5. Use the opaque value to demultiplex the response, e.g. to match 543 it with a pending request in the protocol machinery. 545 Authenticated Traps 546 ------------------- 548 When the agent issues an authenticated SNMP trap packet, the 549 following steps are followed. 551 1. Use an internal timer (authSystemTime) to set the time stamp. 552 This can be used to synchronize the manager's timer. 554 2. Construct the encapsulation header and appended SNMP trap packet. 555 The encrypted signature, error and opaque values are set to zero. 557 3. Compute a hash of the encapsulation header (see below) and 558 the SNMP packet. Everything must already be in its ASN.1 559 encoded form, including the current time stamp. 561 4. Sign the hash value with the agent's private key, then encrypt it 562 with the manager's public key. This not only authenticates the 563 agent to the manager, but prevents a replay attack against 564 another manager. 566 When the manager receives this authenticated SNMP trap packet, the 567 following steps are followed. 569 1. Decrypt the encrypted signature using the manager's private key, 570 then verify it with the agents's public key. If the decryption 571 or verification fails then ignore the packet and optionally 572 report the error back up the protocol stack. 574 2. Compute a hash of the encapsulation header (see below) and the 575 SNMP packet. The encrypted signature field is zeroed during 576 the calculation. 578 3. Compare the computed hash and the received hash. If they are 579 equal then proceed. If not then ignore the packet and optionally 580 report the error back up the protocol stack. 582 4. The time stamp can be used to resynchronize the manager's timer. 584 Authenticated SNMP Transaction or Trap 586 +--------------------------+ 587 | | 588 | Encapsulation | 589 | Header | 590 | using an | 591 | Encrypted Signature | 592 | | 593 +-------------+ | +----------------------+ | +------------+ 594 | | | | | | | | 595 | Sender | | | | | | Receiver | 596 | |---->| | SNMP Packet | |---->| | 597 |(Private Key)| | | | | |(Public Key)| 598 | | | | | | | | 599 +-------------+ | +----------------------+ | +------------+ 600 +--------------------------+ 602 12. Secure SNMP 604 For full SNMP security, authentication information and the 605 encryption of the encapsulated SNMP packet is required. The 606 preparation of the encapsulation header is identical to the 607 authentication steps outlined above, except that the encrypted 608 symmetric key field is now used and that the data, an SNMP packet, 609 is encrypted using this symmetric key. It is recommended that each 610 pair of manager and agent use a different symmetric key during 611 their secure communications. For maximum security, each packet 612 sent should use a different symmetric key for encrypting the 613 SNMP packet. If the software is to be exported outside the USA 614 then it is recommended to use either the RC2 or RC4 algorithms 615 with a maximum of 40 bit keys. 617 Secure Requests 618 --------------- 620 When the manager wishes to send a secure SNMP request packet the 621 following steps need to be followed. 623 1. Retrieve a current time from the agent or use an internal timer 624 if the manager is confident that it is synchronized with the 625 agent. 627 2. Using the symmetric key encrypt the SNMP packet. ASN.1 encode 628 the results as an OCTET STRING. The symmetric key is generated, 629 then signed by the manager's private key and then it is encrypted 630 by the agent's public key, and finally ASN.1 encoded. These two 631 ASN.1 variables are then appended to the encapsulation header as 632 a SEQUENCE. 634 3. Construct the encapsulation header and append the SNMP packet. 635 The encrypted signature and error values are set to zero, and 636 ASN.1 encoded. The opaque value is set to some useful value, 637 typically a unique count. 639 4. Compute a hash of the encapsulation header (see below) and 640 the encrypted SNMP packet. Everything must already be in its 641 ASN.1 encoded form, including the time stamp. The only exception 642 is the asymmetric key encrypted signature field which is zeroed 643 during the calculation. 645 5. Sign the hash value with the manager's private key, then encrypt 646 it with the agent's public key. This not only authenticates 647 the manager to the agent, but prevents a replay attack against 648 another agent which has also registered this agent's public key. 650 When the agent receives this secured SNMP request packet, the 651 following steps are followed. 653 1. Decrypt the encrypted signature using the agent's private key, 654 then verify it with the manager's public key. If the manager's 655 public key is not registered then issue a secure response 656 indicating that a bad public key was encountered. This operation 657 will also recover the symmetric key. 659 2. Compute a hash of the encapsulation header (see below) and the 660 SNMP packet. The encrypted signature field is zeroed during 661 the calculation. 663 3. Compare the computed hash and the received hash. If they are 664 equal then proceed. Otherwise send a secure response indicating 665 a bad signature was encountered. 667 4. Check the time stamp. The agent should allow for network delays 668 time skews. If the time stamp is within an acceptable delay 669 period (this can be a configurable value on the agent) then 670 proceed. Otherwise send a secure response indicating a bad time 671 stamp was encountered. 673 5. Using the symmetric key from step one ASN.1 decode and decrypt 674 the SNMP packet. 676 Note: If any errors occur, such as a bad signature, then the agent 677 constructs a new encapsulation header and sends it and the 678 encrypted data (the SNMP packet) back to the manager. 680 Secure Responses 681 ---------------- 683 When the agent issues a secure SNMP response packet, the following 684 steps are followed. 686 1. Use an internal timer (authSystemTime) to set the time stamp. 687 This can be used to synchronize the manager's timer. 689 2. Using the symmetric key encrypt the SNMP packet. ASN.1 encode 690 the results as an OCTET STRING. The symmetric key is generated, 691 then encrypted by the manager's private key and then the agent's 692 public key, and finally ASN.1 encoded. These two ASN.1 variables 693 are then appended to the encapsulation header as a SEQUENCE. 695 3. Construct the encapsulation header and append the SNMP packet. 696 The encrypted signature value is set to zero. Set the error 697 status value. Copy the opaque value from the original request 698 encapsulation header to this one. 700 4. Compute a hash of the encapsulation header (see below) and 701 the encrypted SNMP packet. Everything must already be in its 702 ASN.1 encoded form, including the time stamp. 704 5. Sign the hash value with the agent's private key, then encrypt it 705 with the manager's public key. This not only authenticates the 706 agent to the manager, but prevents a replay attack against 707 another manager. 709 When the manager receives this secure SNMP response packet, the 710 following steps are followed. 712 1. Decrypt the encrypted signature using the manager's private key, 713 then verify it with the agents's public key. If the decryption 714 fails then ignore the packet and optionally report the error back 715 up the protocol stack. 717 2. Compute a hash of the encapsulation header (see below) and the 718 SNMP packet. The encrypted signature field is zeroed during 719 the calculation. 721 3. Compare the computed hash and the received hash. If they are 722 equal then proceed. If not then ignore the packet and optionally 723 report the error back up the protocol stack. 725 4. The time stamp can be used to resynchronize the manager's timer. 727 5. Using the symmetric key from step one ASN.1 decode and decrypt 728 the SNMP packet. 730 6. Use the opaque value to demultiplex the response, e.g. to match 731 it with a pending request in the protocol machinery. 733 Secure Traps 734 ------------ 736 When the agent issues a secure SNMP trap packet, the following steps 737 are followed. 739 1. Use an internal timer (authSystemTime) to set the time stamp. 740 This can be used to synchronize the manager's timer. 742 2. Construct the encapsulation header. The encrypted signature, 743 error, and opaque values are set to zero. Since this is for 744 authentication only the encrypted symmetric key is set to an 745 ASN.1 NULL value. 747 3. Compute a hash of the encapsulation header (see below) and 748 the SNMP packet. Everything must already be in its ASN.1 749 encoded form, including the time stamp. The only exception is 750 the encrypted signature field which is zeroed during the 751 calculation. 753 4. Sign the hash value with the agent's private key, then encrypt it 754 with the manager's public key. This not only authenticates 755 the agent to the manager, but prevents a replay attack against 756 another manager. 758 When the manager receives this authenticated SNMP trap packet, the 759 following steps are followed. 761 1. Decrypt the doubly encrypted hash, first using the manager's 762 private key, then the agents's public key. If the decryption 763 fails then ignore the packet and optionally report the error back 764 up the protocol stack. 766 2. Compute a hash of the encapsulation header (see below) and the 767 SNMP packet. The encrypted signature field is zeroed during 768 the calculation. 770 3. Compare the computed hash and the received hash. If they are 771 equal then proceed. If not then ignore the packet and optionally 772 report the error back up the protocol stack. 774 4. The time stamp can be used to resynchronize the manager's timer. 776 5. Using the symmetric key from step one ASN.1 decode and decrypt 777 the SNMP packet. 779 Secure SNMP Transaction or Trap 781 +--------------------------+ 782 | | 783 | Encapsulation | 784 | Header | 785 | using an | 786 | Encrypted Signature | 787 | | 788 +-------------+ | +----------------------+ | +------------+ 789 | | | | | | | | 790 | | | | Encrypted | | | | 791 | Sender | | | Symmetric Key | | | Receiver | 792 | | | | and | | | | 793 |(Private Key)|---->| | Encrypted | |---->|(Public Key)| 794 | | | | SNMP Packet | | | | 795 | | | | | | | | 796 +-------------+ | +----------------------+ | +------------+ 797 +--------------------------+ 799 13. Time Stamp Format 801 The timer (secureSystemTime) is maintained by the agent. When a 802 manager wishes to synchronize it's own copy of this timer then 803 it can retrieve the time from the agent. Whenever the manager 804 sends a SNMP request it includes a copy of it's syncronized timer 805 value. Likewise the manager uses it's own timer when sending a 806 response or trap. 808 secureSystemTime OBJECT-TYPE 809 SYNTAX Time 810 ACCESS read-only 811 STATUS optional 812 DESCRIPTION 813 "This is the Agent's system date and time 814 expressed as the number of seconds since 815 midnight January 1, 1900 GMT. The manager 816 can retrieve this to synchronize its time 817 stamps. A practical implementation will 818 allow a certain amount of clock skew when 819 comparing incoming timestamps with this 820 value. 821 " 822 ::= { secure 2 } 824 14. Hash Format 826 This is the ASN.1 format of a hash. Implicit values 0 to 3 are 827 reserved for one-way hashes. 829 HashMd5 ::= [0] IMPLICIT OCTET STRING (SIZE (16)) 831 HashSha ::= [1] IMPLICIT OCTET STRING (SIZE (20)) 833 Hash ::= 834 CHOICE { 835 hashMd5 836 HashMd5, 837 hashSha 838 HashSha 839 } 841 The MD5 [6] and SHA [21] one-way hashes are the only ones defined. 843 15. Public Key Format 845 This is the ASN.1 format of a public key [28]. When a public and 846 private key are generated by a manager or agent, two additional 847 pieces of information must be associated with this key pair. A 848 validity period and an identification number. The validity period 849 is used to age the key. If a key is older than the validity period 850 date then it is considered to be invalid. Implicit values 4 to 7 851 are reserved for public keys. 853 PublicKeyRsa ::= [4] IMPLICIT SEQUENCE { 854 validityPeriod 855 INTEGER, 856 modulus -- n 857 INTEGER, 858 encryption -- e 859 INTEGER 860 } 862 The validityPeriod is in number of seconds since midnight January 1, 863 1900 GMT (0 means forever). 865 The modulus and exponent are multiprecision integers which together 866 represent the public key. 868 For RSA it is recommended that the modulus is at least 768 bits in 869 length. 871 PublicKeyElGamal ::= [5] IMPLICIT SEQUENCE { 872 validityPeriod 873 INTEGER, 874 modulus -- p 875 INTEGER, 876 constant -- g 877 INTEGER, 878 resultant -- y 879 INTEGER 880 } 882 The validityPeriod is in number of seconds since midnight January 1, 883 1900 GMT (0 means forever). 885 The modulus, constant, and resultant, are multiprecision integers 886 which together represent the public key. 888 For ElGamal in DSS it is recommended that the modulus is 512 to 1024 889 bits in length. 891 PublicKey ::= 892 CHOICE { 893 publicKeyRsa 894 PublicKeyRsa 895 } 897 The RSA [15] and ElGamal [25] algorithms are the only ones defined. 899 16. Private Key Signature Format 901 This is the format of the private key signature format [14]. 902 For this document the signature data will consist of a calculated 903 hash and possibly a symmetric key. When data is encrypted, a 904 unique identifier (keyIdentifier) is prepended to it. This is a 905 unique value associated with this public and private key pair. This 906 identifier is computed by taking a hash of a phase phrase or text, 907 and using only the lower 8 octets. While this increases the chance 908 of a duplicate value, it should be sufficient for manager and agent 909 communications. Implicit values 8 to 11 are reserved for private 910 key encrypted data. 912 PrivateKeySignatureRsa ::= [8] IMPLICIT SEQUENCE { 913 keyIdentifier 914 OCTET STRING (SIZE(8)), 915 encryptedData, 916 OCTET STRING 917 } 919 PrivateKeySignatureElGamal ::= [9] IMPLICIT SEQUENCE { 920 keyIdentifier 921 OCTET STRING (SIZE(8)), 922 encryptedData, 923 OCTET STRING 924 } 926 PrivateKeySignatureData ::= 927 CHOICE { 928 privateKeySignatureRsa 929 PrivateKeySignatureRsa, 930 privateKeySignatureElGamal 931 PrivateKeySignatureElGamal 932 } 934 The RSA [15] and ElGamal [25] algorithms are the only ones defined. 936 17. Public Key Encrypted Data Format 938 This is the format of the public key encrypted data format [28]. 939 For this document the encrypted data will consist only of a private 940 key signature. When data is encrypted, a unique identifier 941 (keyIdentifier) is prepended to it. This is a unique value 942 associated with this public and private key pair. This identifier 943 is computed by taking a hash of the RSA modulus and using only the 944 lower 8 octets. While this increases the chance of a duplicate 945 value, it should be sufficient for manager and agent communications. 946 Implicit values 12 to 15 are reserved for public key encrypted data. 948 PublicKeyEncryptedDataRsa ::= [12] IMPLICIT SEQUENCE { 949 keyIdentifier 950 OCTET STRING (SIZE(8)), 951 encryptedData, 952 OCTET STRING 953 } 955 PublicKeyEncryptedDataElGamal ::= [13] IMPLICIT SEQUENCE { 956 keyIdentifier 957 OCTET STRING (SIZE(8)), 958 encryptedData, 959 OCTET STRING 960 } 962 PublicKeyEncryptedData ::= 963 CHOICE { 964 privateKeyEncryptedDataRsa 965 PrivateKeyEncryptedDataRsa, 966 privateKeyEncryptedDataElGamal 967 PrivateKeyEncryptedDataElGamal 968 } 970 The RSA [15] and ElGamal [25] algorithms are the only ones defined. 972 18. Symmetric Key Format 974 This is the ASN.1 format of a symmetric key. Implicit values 16 to 975 30 are reserved for symmetric keys. 977 SymmetricKeyRc2 ::= [16] IMPLICIT SEQUENCE { 978 numberOfBits -- recommend 40 bits for export software 979 INTEGER, 980 key 981 OCTET STRING 982 } 984 SymmetricKeyRc4 ::= [17] IMPLICIT SEQUENCE { 985 numberOfBits -- recommend 40 bits for export software 986 INTEGER, 987 key 988 OCTET STRING 989 } 991 SymmetricKeyDes ::= [18] IMPLICIT SEQUENCE { 992 modes -- ECB, CBC, etc... 993 INTEGER { ecb(0), cbc(1), cfb(2), ofb(3) }, 994 vector -- Used by CBC, CFB and OFB modes 995 OCTET STRING OPTIONAL (SIZE (8)), 996 numBytes -- Used by CFB and OFB modes 997 INTEGER OPTIONAL { 1..7 }, 998 key 999 OCTET STRING (SIZE (8)) 1000 } 1002 SymmetricKeyTripleDes ::= [19] IMPLICIT SEQUENCE { 1003 modes, -- normal or encrypt-decrypt-encrypt modes 1004 INTEGER { normal(0), ede2(1), ede3(2) }, 1005 pad1, -- random bits of half a block 1006 OCTET STRING (SIZE (4)) OPTIONAL, 1007 pad2, -- random bits of half a block 1008 OCTET STRING (SIZE (4)) OPTIONAL, 1009 key1 1010 SymmetricKeyDes, 1011 key2 1012 SymmetricKeyDes, 1013 key3 1014 SymmetricKeyDes 1015 } 1017 SymmetricKeyIdea ::= [20] IMPLICIT SEQUENCE { 1018 modes -- ECB, CBC, etc... 1019 INTEGER { ecb(0), cbc(1), cfb(2), ofb(3) }, 1020 vector -- Used by CBC, CFB and OFB modes 1021 OCTET STRING (SIZE(8)) OPTIONAL, 1022 numBytes -- Used by CFB and OFB modes 1023 INTEGER OPTIONAL { 1..7 }, 1024 key 1025 OCTET STRING (SIZE(16)) 1026 } 1028 SymmetricKey ::= 1029 CHOICE { 1030 symmetricKeyRc2 1031 SymmetricKeyRc2, 1032 symmetricKeyRc4 1033 SymmetricKeyRc4, 1034 symmetricKeyDes 1035 SymmetricKeyDes, 1036 symmetricKeyTripleDes 1037 SymmetricKeyTripleDes, 1038 symmetricKeyIdea 1039 SymmetricKeyIdea 1040 } 1042 19. Hash Only Encrypted Signature 1044 The one-way hash (message digest) [6, 21] computation is done after 1045 the assembly of an SNMP packet and the encapsulation header. The 1046 encrypted signature field data octets are set to zero during the 1047 calculation. 1049 Step 1: One-way hash computation. 1051 H = Hash ( Encapsulation-Message including zeroed encrypted 1052 signature field ) 1054 Step 2: Sign the computed hash value with the sender's 1055 private key. 1057 S = Sign( H, Sender's Private Key ) 1059 Step 3: Encrypt the signature with the receiver's public key. 1061 E = Encrypt( S, Receiver's PublicKey ) 1063 20. Hash And Symmetric Key Encrypted Signature 1065 The one-way hash (message digest) [6, 21] computation is done after 1066 the assembly of an SNMP packet and the encapsulation header. The 1067 encrypted signature field data octets are set to zero during the 1068 calculation. 1070 Step 1: One-way hash computation. 1072 H = Hash ( Encapsulation-Message including zeroed encrypted 1073 signature field ) 1075 Step 2: Randomly generate a symmetric key. 1077 Step 3: Sign the computed hash value and the symmetric key with 1078 the sender's private key. 1080 S = Sign( H, Symmetric Key, Sender's Private Key ) 1082 Step 4: Encrypt the signature with the receiver's public key. 1084 E = Encrypt( S, Receiver's PublicKey ) 1086 21. Encrypted Signature Format 1088 This is the format of the above encrypted signatures. 1090 EncryptedSignatureHash ::= { 1091 { 1092 hash 1093 Hash 1094 } 1095 PrivateKeySignature 1096 } 1097 PublicKeyEncryptedData 1099 EncryptedSignatureHashSymmetricKey ::= { 1100 { 1101 SEQUENCE { 1102 hash 1103 Hash, 1104 symmetricKey 1105 SymmetricKey 1106 } 1107 } 1108 PrivateKeySignature 1109 } 1110 PublicKeyEncryptedData 1112 EncryptedSignature ::= { 1113 CHOICE { 1114 encryptedSignatureHash 1115 EncryptedSignatureHash, 1116 encryptedSignatureHashSymmetricKey 1117 EncryptedSignatureHashSymmetricKey 1118 } 1119 } 1121 22. Encrypted Data Format 1123 This is the encrypted SNMP packet. It is encrypted using the 1124 key to a selected symmetric algorithm. The symmetric key 1125 encoding will indicate which algorithm, mode, etc., to use. 1127 EncryptedData ::= [31] IMPLICIT { 1128 encryptedData, 1129 OCTET STRING 1130 } 1132 Note: Some algorithms require the data to be encrypted to be padded. 1133 For example, DES requires data to be in discrete eight (8) 1134 byte blocks. The data may need to be padded out to the 1135 nearest eight byte boundary. 1137 Note: A DES key is 8 octets of data. This consists of 56 bits of 1138 key, and 8 parity bits (one per octet). The key is encoded 1139 as a series of 8 octets written in MSB-first order. The bits 1140 within the key are also encoded in MSB order. For example, 1141 if the encryption key is: (B1,B2,...,B7,P1,B8,...,B14,P2,B15, 1142 ...,B49,P7,B50,...,B56,P8) where B1,B2,...,B56 are the key 1143 bits in MSB order, and P1,P2,...,P8 are the parity bits, the 1144 first octet of the key would be B1,B2,...,B7,P1 (with B1 as 1145 the MSbit). [17] (This text was derived from section 6.3.4 1146 in RFC 1510). 1148 23. Distributing and Certifying Encryption Keys 1150 Only the public keys can be distributed by any means. Private keys 1151 can never be distributed. Symmetric keys can only be distributed 1152 when they are first encrypted by the sender's private key and then 1153 by the receiver's public key. Symmetric keys typically have a 1154 restricted lifetime, only for one or a limited series of requests. 1156 An agent can receive and certify a manager's key in one of two ways, 1157 either by the administrator or across the network from a trusted 1158 manager. A manager's public key can be deposited in a secure 1159 location on the agent by an administrator. This should be done 1160 during the agent's initial installation. These keys are then 1161 certified by the person installing them. Each key has a privilege 1162 level associated with it. Note asymmetric key pairs are generated 1163 by each manager, only the public key is registered and certified on 1164 the agent, the private key is never distributed. Once a manager's 1165 public key is registered, certified, and given a privilege level, 1166 then it in turn can use an authenticated SNMP Set to deposit other 1167 public keys. These keys are implicitly certified by this manager 1168 an cannot have privilege levels better than his privilege level. 1169 The highest privilege level is zero, and declines with higher 1170 values. 1172 During the installation of the agent, the installer should generate 1173 its asymmetric key pair using proper key generation techniques 1174 [12, 24, 28]. The public key is then made available to managers via 1175 a MIB variable (securePublicKey). The agent's public key is always 1176 available as a read-only variable (securePublicKey). It is 1177 recommended that managers use an authenticated SNMP Get to retrieve 1178 the agent's public key. 1180 This document specifies an optional MIB table (securePublicKeyTable) 1181 which allows managers to write a public key. Only manager's which 1182 have been previously registered can place a public key in this 1183 table, in essence they are certifying the new key. The very first 1184 public key would have to be set up by a non-SNMP mechanism. This 1185 could be done during the initial set up and configuration of the 1186 agent. 1188 The Agent Public Key 1189 -------------------- 1191 securePublicKey OBJECT-TYPE 1192 SYNTAX PublicKey 1193 ACCESS read-only 1194 STATUS mandatory 1195 DESCRIPTION 1196 "The agent's public key. 1197 " 1198 ::= { secure 1 } 1200 Table of Certified Manager Public Keys 1201 -------------------------------------- 1203 securePublicKeyTable OBJECT-TYPE 1204 SYNTAX SEQUENCE OF securePublicKeyEntry 1205 ACCESS not-accessible 1206 STATUS optional 1207 ::= { secure 3 } 1209 securePublicKeyEntry OBJECT-TYPE 1210 SYNTAX SecurePublicKeyEntry 1211 ACCESS not-accessible 1212 STATUS mandatory 1213 INDEX { publicKeyIndex } 1214 ::= { securePublicKeyTable 1 } 1216 AuthPublicKeyEntry ::= SEQUENCE { 1217 securePublicKeyIndex 1218 INTEGER, 1219 securePublicKeyPrivilegeLevel 1220 INTEGER, 1221 securePublicKeyIdentifier, 1222 OCTET STRING, 1223 securePublicKey 1224 PublicKey 1225 } 1227 securePublicKeyIndex OBJECT-TYPE 1228 SYNTAX INTEGER 1229 ACCESS read-only 1230 STATUS mandatory 1231 DESCRIPTION 1232 "This is an index value." 1233 ::= { securePublicKeyEntry 1 } 1235 securePublicKeyPrivilegeLevel OBJECT-TYPE 1236 SYNTAX INTEGER 1237 ACCESS read-write 1238 STATUS mandatory 1239 DESCRIPTION 1240 "This indicates what privileges are 1241 allowed for the manager associated with 1242 this public key. This entry can only be 1243 written using an authenticated Set request 1244 which is accepted by the agent. The highest 1245 privilege level is zero, and the lower the 1246 level the greater the integer value." 1247 ::= { securePublicKeyEntry 2 } 1249 securePublicKeyIdentifier OBJECT-TYPE 1250 SYNTAX OCTET STRING (SIZE(8)) 1251 ACCESS read-write 1252 STATUS mandatory 1253 DESCRIPTION 1254 "A unique identifier associated with the 1255 public key. It is generated by the 1256 manager. This helps associate the 1257 incoming encrypted variables with the 1258 correct public key to decrypt them. This 1259 entry can only be written using an 1260 authenticated Set request which is 1261 accepted by the agent." 1262 ::= { securePublicKeyEntry 3 } 1264 securePublicKeyValue OBJECT-TYPE 1265 SYNTAX PublicKey 1266 ACCESS read-write 1267 STATUS mandatory 1268 DESCRIPTION 1269 "The manager's public key. This is 1270 used by the agent to authenticate the 1271 manager. This entry can only be written 1272 using an authenticated Set request which 1273 is accepted by the agent." 1274 ::= { securePublicKeyEntry 4 } 1276 24. Levels of Security 1278 Different implementations of managers and agents need varying grades 1279 of security. An agent controlling a RAID device may need a higher 1280 level of security than one which tells you the configuration of a 1281 user's personal computer. This document divides security into four 1282 levels. 1284 Level A = Authentication and strong privacy. 1285 Level B = Authentication and medium privacy. 1286 Level C = Authentication and weak privacy. 1287 Level D = Authentication only. 1289 A timestamp is an optional part of the authentication information. 1290 If it is included then it has enhanced the level and the letter has 1291 a plus sign appended as follows. 1293 Level A+ = Authentication (w/timestamp) and strong privacy. 1294 Level B+ = Authentication (w/timestamp) and medium privacy. 1295 Level C+ = Authentication (w/timestamp) and weak privacy. 1296 Level D+ = Authentication (w/timestamp) only. 1298 Note: Traps do not support enhanced levels. 1300 There are two possible authentication types, each has a one-way hash 1301 and uses asymmetric encryption. They are numbered as follows. 1303 0 = MD5 and RSA (768 bit modulus or greater) algorithms 1304 1 = SHA and ElGamal algorithms 1306 There are two possible strong privacy types, each uses symmetric 1307 encryption. They are numbered as follows. 1309 0 = Triple DES algorithm 1310 2 = IDEA algorithm 1312 There is one possible medium privacy type, which uses symmetric 1313 encryption. It is numbered as follows. 1315 0 = DES algorithm 1317 There are two possible weak privacy types, each uses symmetric 1318 encryption. They are numbered as follows. 1320 0 = RC2 algorithm (40 bit key or less) 1321 2 = RC4 algorithm (40 bit key or less) 1323 By adding the numbers for authentication and privacy a unique 1324 value will exactly indicate which algorithms are used for each 1325 level. 1327 A0 = MD5, RSA and Triple DES 1328 A1 = SHA, ElGamal and Triple DES 1329 A2 = MD5, RSA and IDEA 1330 A3 = SHA, ElGamal and IDEA 1331 B0 = MD5, RSA and DES 1332 B1 = SHA, ElGamal and DES 1333 C0 = MD5, RSA and RC2 1334 C1 = SHA, ElGamal and RC2 1335 C2 = MD5, RSA and RC4 1336 C3 = SHA, ElGamal and RC4 1337 D0 = MD5 and RSA 1338 D1 = SHA and ElGamal 1340 If the authentication uses a valid timestamp then the security 1341 levels are considered enhanced. Traps do not support enhanced 1342 levels. 1344 A0+ = MD5, RSA, timestamp and Triple DES 1345 A1+ = SHA, ElGamal, timestamp and Triple DES 1346 A2+ = MD5, RSA, timestamp and IDEA 1347 A3+ = SHA, ElGamal, timestamp and IDEA 1348 B0+ = MD5, RSA, timestamp and DES 1349 B1+ = SHA, ElGamal, timestamp and DES 1350 C0+ = MD5, RSA, timestamp and RC2 1351 C1+ = SHA, ElGamal, timestamp and RC2 1352 C2+ = MD5, RSA, timestamp and RC4 1353 C3+ = SHA, ElGamal, timestamp and RC4 1354 D0+ = MD5, RSA and timestamp 1355 D1+ = SHA, ElGamal and timestamp 1357 25. Implementation Requirements of Security Levels 1359 General 1360 ------- 1362 The maximum level of security is always determined by the agent. 1363 A manager must send a series of encapsulated SNMP requests at 1364 different levels to determine which level will be accepted by the 1365 agent. The agent will indicate with the error codes what levels it 1366 will accept. If the manager cannot support the level required by 1367 the agent then it cannot communicate with the agent. If an agent 1368 supports multiple levels then the manager may select which level it 1369 wishes to communicate on. Some agents may require a higher level 1370 for some MIB variables and a lower level for others. A manager 1371 should try to seek the highest level it and the agent mutually 1372 support together. 1374 All managers are required to support D0 and D0+. If a manager can 1375 support a higher level then it must also be able to support enhanced 1376 version of that level. For example if it can support B1 then it 1377 must also be prepared to support B1+. 1379 All agents must at least support one of the following levels; A0, 1380 A0+, A2, A2+, B0, B0+, C0, C0+, C2, C2+, D0, D0+. They must support 1381 the securePublicKey variable. They can optionally support the 1382 secureSystemTime variable and the securePublicKeyTable table. 1384 Authentication-only SNMP 1385 ------------------------ 1387 The easiest USA export license is for authentication-only software. 1388 For this license it is required to implement the agent or manager 1389 with one of the following combinations. 1391 Manager: D0, or D0+, or D0 and D1, or D0+ and D1+. 1392 Agent: D0, or D0+, or D0 and D1, or D0+ and D1+. 1394 Exportable Secure SNMP 1395 ---------------------- 1396 USA export licenses are usually granted for (weak) encryption 1397 software using RC2 or RC4 with 40 bit keys. For this license it is 1398 required to implement the agent or manager with one of the following 1399 combinations. 1401 Manager: D0, or D0+, or D0 and D1, or D0+ and D1+. Plus C0, or C0+, 1402 or C1, or C1+, or C2, or C2+, or C3, or C3+. 1403 Agent: D0, or D0+, or D0 and D1, or D0+ and D1+. Plus C0, or C0+, 1404 or C1, or C1+, or C2, or C2+, or C3, or C3+. 1406 26. Agent Requirements 1408 An agent must use the same level of security for its response as the 1409 manager used for its request. If the agent cannot or will not 1410 support an algorithm (or key size) then it should return an 1411 appropriate error. It is up to the manager to choose another 1412 security level. 1414 Only for traps can an agent select any level, besides enhanced, 1415 however it is recommended to use the lowest available level. If 1416 possible, D0 is the best since all managers guarentee to support 1417 this level. 1419 For the opaqueValue field it must respond with the exact same value 1420 it received during the request. For traps this field is set to zero. 1422 The timeStamp field should be set to a copy of its internal clock when 1423 creating the response encapsulation header. If no clock is available 1424 then this should be set to zero. 1426 27. Explanation of Certain Design Details 1428 Time Synchronization 1429 -------------------- 1431 Time synchronization is quite simple. Each agent is considered 1432 to keep an accurate timer. Any manager which wishes to communicate 1433 with an agent, gets this timer to synchronize with their internal 1434 timer. Once the flow of encapsulated packets has begun, then 1435 the manager can automatically synchronize from the timeStamp 1436 field when receiving a packet from the agent. Each agent 1437 maintains what it considers to be an acceptable amount of delay 1438 from its current time for any incoming packets. Packets 1439 which fall outside this delay range must be returned to the 1440 sender with an error (badTimeStamp) and a current copy of its 1441 internal time in the timeStamp field. This gives the manager 1442 a chance to correct its timestamp and to resubmit its request. 1443 This also makes analyzing errors simpler. Managers do not test time 1444 stamps, they only examine them to resynchronize their internal 1445 timers for each agent they are communicating with. This does expose 1446 managers to a replay attack. There are no real benefits to be 1447 gained by this type of attack, in fact a good SNMP manager protocol 1448 stack implementation should ignore duplicate SNMP responses. 1450 Some agents may not be able to support an accurate timer. In 1451 this case time synchronization is not possible. Any timeStamp 1452 field value sent by the manager can be ignored by the agent. 1453 When the agent responds it sets this field to zero, indicating 1454 that there is no time stamp support. This degrades the 1455 authentication robustness by increasing the possibility of replay 1456 attacks against the agent. 1458 Encrypted Signature 1459 ------------------- 1461 The encrypted signature, where the signature contains the one-way 1462 hash and potentially the symmetric key, ensures that only the 1463 authorized sender and receiver can communicate. 1465 Asymmetric Key Identification 1466 ----------------------------- 1468 When the receiving an encapsulated SNMP packet with data that 1469 has been signed by a private key, e.g. the hash and possibly the 1470 symmetric key, there is a problem of looking up the correct public 1471 key. All asymmetric algorithm signed or encrypted data, with either 1472 the public or private key respectively, has a unique identifier 1473 prepended to it. This allows the receiver to find the corresponding 1474 key, usually a public key, to verify or decrypt the data. This 1475 unique identifier is generated by whomever created the public and 1476 private key pair. This document recommends that a hash be run over 1477 a pass phrase or text, and then the lower 8 octets are used as the 1478 unique identifier of the keys. 1480 28. Exporting Encryption Software 1482 According to the USA government, cryptography is a munition. You 1483 must obtain the proper export license to sell any software with 1484 cryptography [27]. There are two USA government agencies that 1485 control export of encryption software. 1487 One is the Bureau of Export Administration (BXA) in the Department 1488 of Commerce, authorized by the Export Administration Regulations. 1489 The other is the Office of Defense Trade Controls (DTC) in the State 1490 Department, authorized by the Defense Trade Regulations. The 1491 National Security Agency (NSA) controls the DTC. 1493 The BXA has less stringent requirements. The DTC usually inspects 1494 an application first and can refuse to transfer jurisdiction to BXA. 1495 The Defense Trade Regulations regulates the export sales of 1496 munitions. An encryption product may need approval for every 1497 product revision or even every sale. 1499 The State Department does not approve the export of products with the 1500 DES algorithm. The Software Publishers Association (SPA) has recently 1501 been negotiating with the government to ease the export license 1502 restrictions. A 1992 agreement eased the export license rules for two 1503 ciphers, RC2 and RC4, as long as the key size is 40 bits or less. 1504 Products that implement one of these two algorithms have a much 1505 simpler export approval process, provided that the keys are no more 1506 than 40 bits in size. 1508 Please note that these export rules do not apply to sales within the 1509 USA, or to foreign subsidiaries of USA corporations in friendly 1510 countries, or for financial uses in friendly countries, or to 1511 Canada [22]. There are no restrictions in these cases. However, 1512 they do apply to sales to foreign nationals residing within the USA. 1514 Some foreign countries, most notably France, restrict the import of 1515 encryption software. 1517 29. Exporting Authentication-only Software 1519 It is the stated policy of the NSA not to restrict the export of 1520 authentication products, only encryption products. To export an 1521 authentication-only product approval is subject to showing that the 1522 device cannot easily be converted to an encryption device. The 1523 bureaucratic procedures are much simpler for authentication products 1524 than encryption products. An authentication product needs NSA and 1525 State Department export approval only once. 1527 30. Definitions 1529 SECURE-SNMP DEFINITIONS ::= BEGIN 1531 -- Authenticated or secure encapsulation of SNMP message. 1533 Encapsulation-Message ::= 1534 SEQUENCE { 1535 version -- Version 3 for this RFC. 1536 INTEGER { 1537 version-3(2) 1538 }, 1540 opaqueValue -- Manager sets this, agent must 1541 INTEGER, -- echo it back. Traps use 0. 1543 errorStatus -- Response from agent, 0 otherwise. 1544 INTEGER { 1545 noError(0), 1546 generalError(1), 1547 badSignature(2), 1548 unsupportedPublicKey(3), 1549 unsupportedHash(4), 1550 badTimeStamp(5), 1551 badSymmetricKey(6), 1552 tooLargeSymmetricKey(7), 1553 unsupportedSymmetricKey(8), 1554 unsupportedSymmetricMode(9), 1555 noEncryptedDataAllowed(10), 1556 badEncryptedData(11) 1557 }, 1559 timeStamp -- Synchronized time value. 1560 INTEGER, -- Agent returns current value. 1562 encryptedSignature -- May contain symmetric key. 1563 EncryptedSignature, 1565 CHOICE { 1566 data -- SNMPv1, SNMPv2, etc., packet 1567 ANY, 1568 encryptedData -- The data encrypted w/symm. key. 1569 EncryptedData 1570 } 1572 } 1574 END 1576 AUTHENTICATION-MIB DEFINITIONS ::= BEGIN 1578 IMPORTS 1579 mgmt 1580 FROM RFC1155-SMI 1581 OBJECT-TYPE 1582 FROM RFC-1212; 1584 -- MIB I and MIB II have the same object identifier. 1586 mib-2 OBJECT IDENTIFIER ::= { mgmt 1 } 1588 secure OBJECT IDENTIFIER ::= { mib-2 111 } 1590 -- Textual conventions 1592 Time ::= INTEGER 1593 -- The date and time expressed as the number of seconds 1594 -- since midnight January 1, 1900 GMT 1596 -- ==================================================================== 1597 -- 1598 -- Support Variables 1599 -- 1601 securePublicKey OBJECT-TYPE 1602 SYNTAX PublicKey 1603 ACCESS read-only 1604 STATUS mandatory 1605 DESCRIPTION 1606 "The agent's public key. 1607 " 1608 ::= { secure 1 } 1610 secureSystemTime OBJECT-TYPE 1611 SYNTAX Time 1612 ACCESS read-only 1613 STATUS optional 1614 DESCRIPTION 1615 "This is the Agent's system date and time 1616 expressed as the number of seconds since 1617 midnight January 1, 1900 GMT. The manager 1618 can retrieve this to synchronize its time 1619 stamps. A practical implementation will 1620 allow a certain amount of clock skew when 1621 comparing incoming timestamps with this 1622 value. 1623 " 1624 ::= { secure 2 } 1626 -- ==================================================================== 1627 -- 1628 -- The Public Key Table 1629 -- 1630 -- It is optional to implement this table. 1631 -- 1632 -- This table is for managers to deposit their public keys with an agent. 1633 -- They must use their private keys to encrypt the hash and time stamps 1634 -- but the agent uses the public keys to decrypt them and thus certify 1635 -- the incoming SNMP request. 1636 -- 1637 -- For a public key to be allowed into this table from across the 1638 -- network it will have to be authenticated by a trusted person. This 1639 -- person's public key must already be registered in this table before 1640 -- they can add another person's public key i.e. certifing the new key. 1641 -- This table controls which SNMP requests will be accepted by the 1642 -- agent, and what privilege level will be associated with it. The 1643 -- actual details of how the privilege levels will work and an acceptable 1644 -- certification alogrithm is left up to the agent designer. 1646 securePublicKeyTable OBJECT-TYPE 1647 SYNTAX SEQUENCE OF securePublicKeyEntry 1648 ACCESS not-accessible 1649 STATUS optional 1650 ::= { secure 3 } 1652 securePublicKeyEntry OBJECT-TYPE 1653 SYNTAX SecurePublicKeyEntry 1654 ACCESS not-accessible 1655 STATUS mandatory 1656 INDEX { publicKeyIndex } 1657 ::= { securePublicKeyTable 1 } 1659 AuthPublicKeyEntry ::= SEQUENCE { 1660 securePublicKeyIndex 1661 INTEGER, 1662 securePublicKeyPrivilegeLevel 1663 INTEGER, 1664 securePublicKeyIdentifier, 1665 OCTET STRING, 1666 securePublicKey 1667 PublicKey 1668 } 1670 securePublicKeyIndex OBJECT-TYPE 1671 SYNTAX INTEGER 1672 ACCESS read-only 1673 STATUS mandatory 1674 DESCRIPTION 1675 "This is an index value." 1676 ::= { securePublicKeyEntry 1 } 1678 securePublicKeyPrivilegeLevel OBJECT-TYPE 1679 SYNTAX INTEGER 1680 ACCESS read-write 1681 STATUS mandatory 1682 DESCRIPTION 1683 "This indicates what privileges are 1684 allowed for the manager associated with 1685 this public key. This entry can only be 1686 written using an authenticated Set request 1687 which is accepted by the agent. The highest 1688 privilege level is zero, and the lower the 1689 level the greater the integer value." 1690 ::= { securePublicKeyEntry 2 } 1692 securePublicKeyIdentifier OBJECT-TYPE 1693 SYNTAX OCTET STRING (SIZE(8)) 1694 ACCESS read-write 1695 STATUS mandatory 1696 DESCRIPTION 1697 "A unique identifier associated with the 1698 public key. It is generated by the 1699 manager. This helps associate the 1700 incoming encrypted variables with the 1701 correct public key to decrypt them. This 1702 entry can only be written using an 1703 authenticated Set request which is 1704 accepted by the agent." 1705 ::= { securePublicKeyEntry 3 } 1707 securePublicKeyValue OBJECT-TYPE 1708 SYNTAX PublicKey 1709 ACCESS read-write 1710 STATUS mandatory 1711 DESCRIPTION 1712 "The manager's public key. This is 1713 used by the agent to authenticate the 1714 manager. This entry can only be written 1715 using an authenticated Set request which 1716 is accepted by the agent." 1717 ::= { securePublicKeyEntry 4 } 1719 END 1721 31. An Example Encoding 1723 We wish to set the following value on an agent. 1725 Object Identifier = 1.3.6.1.4.1.123.5.0 1726 Data Type = Integer 1727 Data = 65 1729 A standard SNMP Set request packet. 1731 30 27 02 01 00 04 06 70 75 62 6C 69 63 A4 1A 02 1732 01 01 02 01 00 02 01 00 30 0F 30 0D 06 08 2B 06 1733 01 04 01 7B 05 00 02 01 41 1735 The authenticated SNMP Set request packet. Using MD5 and 1736 and RSA with a 512 bit modulus. 1738 30 81 C8 02 01 02 02 01 00 02 01 00 02 04 30 9D 1739 96 E5 AC 81 8D 04 08 02 00 00 00 00 00 00 00 04 1740 81 80 80 58 D0 EB 7A C2 71 7B A8 9E 66 28 CD 2D 1741 41 74 4F 6F 3D BE AC 22 6C 25 57 23 3D BF EF CE 1742 21 9B AA 44 02 EA 32 B7 9D 92 BB 88 72 FC 86 32 1743 66 B7 E0 75 3A 0D D6 87 0E 77 37 91 F1 EF B0 D7 1744 F2 75 24 69 8D F2 C8 76 50 62 15 31 6E 7E 8D 9C 1745 16 CD 72 AA 05 8E 1F 18 80 DA 99 54 77 78 DE 8E 1746 2F 2F EA BF 39 A0 92 40 BB F3 E6 79 59 76 2E 49 1747 B5 47 6A 32 0F 50 51 4E 13 A9 88 54 5C 69 1B F8 1748 36 24 30 27 02 01 00 04 06 70 75 62 6C 69 63 A4 1749 1A 02 01 01 02 01 00 02 01 00 30 0F 30 0D 06 08 1750 2B 06 01 04 01 7B 05 00 02 01 41 1752 A secure SNMP Set request packet (it is encrypted). Note the hash 1753 was calculated over both the encapsulation (using a zeroed encrypted 1754 signature field) header and the encrypted packet (ASN.1 encoded). 1755 Using MD5 and RSA with a 512 bit modulus. The symmetric key is RC4 1756 using 40 bits. 1758 30 81 CA 02 01 02 02 01 00 02 01 00 02 04 30 9D 1759 96 E9 AC 81 8D 04 08 02 00 00 00 00 00 00 00 04 1760 81 80 2A 07 77 61 BE E4 9B 16 E6 D0 1A BE 66 B3 1761 B7 F1 71 22 20 7D D2 9F D0 65 12 8C 0B 42 56 52 1762 02 B6 66 C9 3E 82 C5 F7 19 95 C3 D8 8A FB BD 6E 1763 B9 F8 F1 08 47 30 5E 4E 89 9C 9A 0A 3E 47 A2 F9 1764 83 67 9C 03 66 BE D0 16 C2 2C B9 BD 0D 89 BA 84 1765 66 87 2D 33 81 65 CA 4B 2E 7D DA D8 C7 00 4C B3 1766 58 05 43 1F 5A 7D 3B 22 F8 87 94 E8 79 05 76 94 1767 A8 E4 E4 03 CB BF 79 DE DA FE E1 6A 8A 0E 08 C6 1768 BA 8F B1 29 9E 84 36 54 A3 C1 A4 35 3A 34 46 E3 1769 37 01 B2 CB 63 8F DF 21 8C 89 ED 58 81 AB C6 DD 1770 FB 51 A7 F5 A9 A9 E1 39 B3 99 CB 48 85 1772 Note: This example uses a smaller RSA modulus than this document 1773 recommends. 1775 32. Acknowledgements 1777 I would like to thank the following people for their excellent 1778 suggestions and comments. 1780 Don Provan Novell, Inc., USA 1781 Denis Pinkas Bull SA, France 1783 33. References 1785 Request For Comments 1786 -------------------- 1788 [1] RFC 1155, Case, J.D., et. al., Structure and Identification of 1789 Management Information for TCP/IP-based Internets. 1790 (SNMPv1), May 1990 1792 [2] RFC 1157, Case, J.D., et. al., Simple Network Management Protocol 1793 (SNMPv1), May 1990 1795 [3] RFC 1158, Rose, M.T., Management Information Base for Network 1796 Management of TCP/IP-based Internets: MIB-II 1797 May 1990 1799 [4] Fougner, R., RFC 1170, Public Key Standards and Licenses, Jan. 1800 1991. Public Key Partners, Inc. 1802 [5] RFC 1212, Rose, M., et al., Concise MIB Definitions, March 1991 1804 [6] RFC 1321, Rivest, R., The MD5 Message-Digest Algorithm. 1805 April 1992. 1807 [7] RFC 1351, Davin, J., et. al., SNMP Administrative Model, 1808 July 1992 1810 [8] RFC 1352, Galvin, J., et. al., SNMP Security Protocols, 1811 July 1992 1813 [9] RFC 1445, Galvin, J., et. al., Administrative Model for version 1814 2 of the Simple Network Management Protocol (SNMPv2). 1815 April 1993. 1817 [10] RFC 1446, Galvin, J., et. al., Security Protocols for version 2 1818 of the Simple Network Management Protocol (SNMPv2). 1819 April 1993. 1821 [11] RFC 1448, Case, J.D., et. al., Protocol Operations for version 1822 2 of the Simple Network Management Protocol (SNMPv2), April 1823 1993. 1825 [12] RFC 1750, Eastlake, D. E., et al., Randomness Recommendations 1826 for Security 1828 Patents 1829 ------- 1831 [13] Meyer, C.H. et. al., USA Patent 3,962,539, Product Block Cipher 1832 for Data Security. Held by IBM. Expired. 1834 [14] Lai, X., et. al., European Patent PCT/CH91/00117. Patent 1835 pending in USA. International Data Encryption Algorithm (IDEA). 1836 Held by ETH and Ascom-Tech Ab, Switzerland. 1838 [15] Rivest, R., et al., USA Patent 4,405,829. Cryptographic 1839 Communications System and Method. Held by Public Key Partners. 1840 This is also known as the RSA public key algorithm. 1842 Standards 1843 --------- 1845 [16] NBS FIPS PUB 46, "Data Encryption Standard", National Bureau of 1846 Standards, U.S. Deparment of Commerce, Jan. 1977 1848 [17] NBS FIPS PUB 81, "DES Modes of Operation", National Bureau of 1849 Standards, U.S. Deparment of Commerce, Dec. 1980 1851 [18] NBS FIPS PUB 74, "Guidelines for Implementing and Using the 1852 NBS Data Encryption Standard", National Bureau of Standards, 1853 U.S. Deparment of Commerce, Apr. 1981 1855 [19] ANSI X9.17 (Revised), "American National Standard for Financial 1856 Institution Key Management (Wholesale)", American Bankers 1857 Association, 1985 1859 [20] ISO DIS 8732, "Banking Key Management (Wholesale)", Association 1860 for Payment Clearing Services, London, Dec. 1987 1862 [21] NIST FIPS PUB 180, "Secure Hash Standard", National Institute 1863 of Standards and Technology, Federal Information Processing 1864 Standards Publication, U.S. Department of Commerce, 1865 May 11, 1993. 1867 Publications 1868 ------------ 1870 [22] Hoffman, L., ed., "Building In Big Brother, The Cryptographic 1871 Policy Debate", Springer-Verlag, 1995 1873 [23] Robshaw, M., "Security Estimates for 512-bit RSA", RSA 1874 Laboratories, June 1995. 1876 [24] Schneier, B., "Untangling Public-Key Cryptography", pp. 16-28, 1877 Dr. Dobbs Journal, April 1992. 1879 [25] Schneier, B., "Applied Cryptography", 2nd ed., John Wiley & 1880 Sons, Inc., 1996. 1882 [26] Imported and Exported Defense Articles and Services (ITAR), 1883 Vol. 57, No. 89, Part II, 56 FR 19666, May 7, 1992. 1884 U.S. Department of State, Bureau of Politico-Military Affairs 1886 Code 1887 ---- 1889 [27] Rivest, R. Ron's Code 2 (RC2) and 4 (RC4). Variable key size 1890 encryption algorithms owned by RSA Data Security, Inc. 1891 Unpublished. (RC4 was stolen and distributed on the Internet.) 1893 [28] Zimmerman, P., Pretty Good Privacy, 2.3a source code, 1994. 1895 34. Glossary of Terms 1897 ASN.1, Abstract Syntax Notation version 1 1898 BXA, Bureau of Export Administration in the Department of Commerce, 1899 authorized by the Export Administration Regulations. 1900 DES, Digital Encryption Standard, a USA symmetric key standard 1901 [13, 16, 17, 18]. 1902 DSA, Digital Signature Algorithm, part of DSS, a public key algorithm 1903 DSS, Digital Signature Standard, a USA public key standard 1904 DTC, Office of Defense Trade Controls in the State Department, 1905 authorized by the Defense Trade Regulations. 1906 LUC, Public key algorithm using Lucas functions, invented by Peter 1907 Smith. 1908 IDEA, International Digital Encryption Algorithm, a symmetric key 1909 algorithm [14]. 1910 MD, Message Digest, a one-way hash 1911 MIB, Management Information Base, used with SNMP 1912 MIT, Massachusetts Institute of Technology. 1913 NSA, National Security Agency 1914 PDU, Packet Data Unit 1915 PKP, Public Key Partners of Sunnyvale, California, a consortium of 1916 RSADSI, Cylink, Inc., Stanford University and MIT. 1917 RC, Ron's Code 1918 RFC, Request For Comment, Internet standards 1919 RSA, Rivest-Shamir-Adleman, public key algorithm [15] 1920 RSADSI, RSA Data Security Inc. 1921 SHA, Secure Hash Algorithm, a one-way hash 1922 SNMP, Simple Network Management Protocol, see also MIB 1923 SNMPv1, SNMP version 1 (RFCs 1155 1157, 1212) 1924 SNMPv2, SNMP version 2 (RFCs 1441 to 1452) 1925 SNMPSec,SNMP Security (RFCs 1351, 1352) 1927 Security Considerations 1929 Security issues for SNMP authentication and privacy are discussed 1930 in this document. 1932 Author Address 1934 Alexander I. Alten 1935 Alten@Novell.Com 1936 (408) 577-8224 1938 Novell, Inc. 1939 Mail Stop F1-42-D2 1940 2180 Fortune Drive 1941 San Jose, CA 95131 1942 USA