idnits 2.17.1 draft-ietf-snmpv2-sec-ds-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-23) 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. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** 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 293 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** 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 990: '...above SHOULD be performed with these p...' RFC 2119 keyword, line 1049: '...v2 set operation MUST be encapsulated ...' RFC 2119 keyword, line 1108: '...rty in an agent, MAY be generated with...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (March 1995) is 10632 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) -- Possible downref: Non-RFC (?) normative reference: ref. '1' ** Downref: Normative reference to an Historic RFC: RFC 1157 (ref. '2') ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. '3') -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Possible downref: Non-RFC (?) normative reference: ref. '10' -- Possible downref: Non-RFC (?) normative reference: ref. '11' -- Possible downref: Non-RFC (?) normative reference: ref. '12' -- Possible downref: Non-RFC (?) normative reference: ref. '13' -- Possible downref: Non-RFC (?) normative reference: ref. '14' Summary: 13 errors (**), 0 flaws (~~), 1 warning (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Security Protocols for SNMPv2 March 1995 4 Security Protocols 5 for Version 2 of the 6 Simple Network Management Protocol (SNMPv2) 8 19 March 1995 | 10 draft-ietf-snmpv2-sec-ds-01.txt | 12 Jeffrey D. Case | 13 SNMP Research, Inc. | 14 case@snmp.com | 16 James Galvin | 17 Trusted Information Systems 18 galvin@tis.com 20 Keith McCloghrie | 21 Cisco Systems, Inc. 22 kzm@cisco.com 24 Marshall T. Rose + 25 Dover Beach Consulting, Inc. + 26 mrose@dbc.mtview.ca.us + 28 Steven Waldbusser + 29 Carnegie Mellon University + 30 waldbusser@cmu.edu + 32 Status of this Memo 34 This document is an Internet-Draft. Internet-Drafts are working 35 documents of the Internet Engineering Task Force (IETF), its areas, and 36 its working groups. Note that other groups may also distribute working 37 documents as Internet-Drafts. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet- Drafts as reference material 42 or to cite them other than as ``work in progress.'' 44 To learn the current status of any Internet-Draft, please check the 45 ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow 46 Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), 47 ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 49 1. Introduction 51 A management system contains: several (potentially many) nodes, each 52 with a processing entity, termed an agent, which has access to 53 management instrumentation; at least one management station; and, a 54 management protocol, used to convey management information between the 55 agents and management stations. Operations of the protocol are carried 56 out under an administrative framework which defines authentication, 57 authorization, access control, and privacy policies. 59 Management stations execute management applications which monitor and 60 control managed elements. Managed elements are devices such as hosts, 61 routers, terminal servers, etc., which are monitored and controlled via 62 access to their management information. 64 In the Administrative Infrastructure for SNMPv2 document [1], | 65 each SNMPv2 party is, by definition, associated with a single 66 authentication protocol and a single privacy protocol. It is the 67 purpose of this document, Security Protocols for SNMPv2, to define one 68 such authentication and one such privacy protocol. 70 The authentication protocol provides a mechanism by which SNMPv2 71 messages transmitted by a party may be reliably identified as having 72 originated from that party. The authentication protocol defined in this 73 memo also reliably determines that the message received is the message 74 that was sent. 76 The privacy protocol provides a mechanism by which SNMPv2 messages 77 transmitted to a party are protected from disclosure. The privacy 78 protocol in this memo specifies that only authenticated messages may be 79 protected from disclosure. 81 These protocols are secure alternatives to the so-called "noAuth/noPriv" 82 protocol defined in [1]. 84 USE OF THE noAuth/noPriv PROTOCOL ALONE DOES NOT CONSTITUTE SECURE 85 NETWORK MANAGEMENT. THEREFORE, A NETWORK MANAGEMENT SYSTEM THAT 86 IMPLEMENTS ONLY THE noAuth/noPriv PROTOCOL IS NOT CONFORMANT TO 87 THIS SPECIFICATION. 89 The Digest Authentication Protocol is described in Section 3. It 90 provides a data integrity service by transmitting a message digest - 91 computed by the originator and verified by the recipient - with each 92 SNMPv2 message. The data origin authentication service is provided by 93 prefixing the message with a secret value known only to the originator 94 and recipient, prior to computing the digest. Thus, data integrity is 95 supported explicitly while data origin authentication is supported 96 implicitly in the verification of the digest. 98 The Symmetric Privacy Protocol is described in Section 4. It protects 99 messages from disclosure by encrypting their contents according to a 100 secret cryptographic key known only to the originator and recipient. 101 The additional functionality provided by this protocol is assumed to 102 justify its additional computational cost. 104 The Digest Authentication Protocol depends on the existence of loosely 105 synchronized clocks between the originator and recipient of a message. 106 The protocol specification makes no assumptions about the strategy by 107 which such clocks are synchronized. Section 5.3 presents one strategy 108 that is particularly suited to the demands of SNMP network management. 110 Both protocols described here require the sharing of secret information 111 between the originator of a message and its recipient. The protocol 112 specifications assume the existence of the necessary secrets. The 113 selection of such secrets and their secure distribution to appropriate 114 parties may be accomplished by a variety of strategies. Section 5.4 115 presents one such strategy that is particularly suited to the demands of 116 SNMP network management. 118 1.1. A Note on Terminology 120 For the purpose of exposition, the original Internet-standard Network 121 Management Framework, as described in RFCs 1155, 1157, and 1212, is 122 termed the SNMP version 1 framework (SNMPv1). The current framework is 123 termed the SNMP version 2 framework (SNMPv2). 125 1.1.1. Change Log 127 For the 19 March version: + 129 - The changes adopted by the SNMPv2 Working Group. + 131 For the 1 November version: 133 - recast RFC 1446 into an Internet-Draft, 135 - fixed typos, 136 - rewrote various paragraphs, sentences, phrases throughout the 137 document to use less formal, but more easily understood, language, 138 and to omit unnecessary/redundant text. 140 - rewrote text in various sections on the maintenance of party 141 secrets to be consistent with the use of the desPrivProtocol being 142 optional. 144 - removed text describing implementation-specific considerations. 146 - incorporated new text on the creation of parties, discussing 147 "cloning" as defined in the Party MIB. 149 1.2. Threats 151 Several of the classical threats to network protocols are applicable to 152 the network management problem and therefore would be applicable to any 153 SNMPv2 security protocol. Other threats are not applicable to the 154 network management problem. This section discusses principal threats, 155 secondary threats, and threats which are of lesser importance. 157 The principal threats against which any SNMPv2 security protocol should 158 provide protection are: 160 Modification of Information 161 The SNMPv2 protocol provides the means for management stations to 162 interrogate and to manipulate the value of objects in a managed 163 agent. The modification threat is the danger that some party may 164 alter in-transit messages generated by an authorized party in such 165 a way as to effect unauthorized management operations, including 166 falsifying the value of an object. 168 Masquerade 169 The SNMPv2 administrative model includes an access control model. 170 Access control necessarily depends on knowledge of the origin of a 171 message. The masquerade threat is the danger that management 172 operations not authorized for some party may be attempted by that 173 party by assuming the identity of another party that has the 174 appropriate authorizations. 176 Two secondary threats are also identified. The security protocols 177 defined in this memo do provide protection against: 179 Message Stream Modification 180 The SNMPv2 protocol is typically based upon a connectionless 181 transport service which may operate over any subnetwork service. 182 The re-ordering, delay or replay of messages can and does occur 183 through the natural operation of many such subnetwork services. 184 The message stream modification threat is the danger that messages 185 may be maliciously re-ordered, delayed or replayed to an extent 186 which is greater than can occur through the natural operation of a 187 subnetwork service, in order to effect unauthorized management 188 operations. 190 Disclosure 191 The disclosure threat is the danger of eavesdropping on the 192 exchanges between managed agents and a management station. 193 Protecting against this threat may be required as a matter of local 194 policy. 196 There are at least two threats that an SNMPv2 security protocol need not 197 protect against. The security protocols defined in this memo do not 198 provide protection against: 200 Denial of Service 201 An SNMPv2 security protocol need not attempt to address the broad 202 range of attacks by which service to authorized parties is denied. 203 Indeed, such denial-of-service attacks are in many cases 204 indistinguishable from the type of network failures with which any 205 viable network management protocol must cope as a matter of course. 207 Traffic Analysis 208 In addition, an SNMPv2 security protocol need not attempt to 209 address traffic analysis attacks. Indeed, many traffic patterns 210 are predictable - agents may be managed on a regular basis by a 211 relatively small number of management stations - and therefore 212 there is no significant advantage afforded by protecting against 213 traffic analysis. 215 1.3. Goals and Constraints 217 Based on the foregoing account of threats in the SNMP network management 218 environment, the goals of an SNMPv2 security protocol are enumerated 219 below. 221 (1) The protocol should provide for verification that each received 222 SNMPv2 message has not been modified during its transmission 223 through the network in such a way that an unauthorized management 224 operation might result. 226 (2) The protocol should provide for verification of the identity of the 227 originator of each received SNMPv2 message. 229 (3) The protocol should provide that the apparent time of generation 230 for each received SNMPv2 message is recent. 232 (4) The protocol should provide, when necessary, that the contents of 233 each received SNMPv2 message are protected from disclosure. 235 In addition to the principal goal of supporting secure network 236 management, the design of any SNMPv2 security protocol is also 237 influenced by the following constraints: 239 (1) When the requirements of effective management in times of network 240 stress are inconsistent with those of security, the design should 241 prefer the former. 243 (2) Neither the security protocol nor its underlying security 244 mechanisms should depend upon the ready availability of other 245 network services (e.g., Network Time Protocol (NTP) or secret/key 246 management protocols). 248 (3) A security mechanism should entail no changes to the basic SNMP 249 network management philosophy. 251 1.4. Security Services 253 The security services necessary to support the goals of an SNMPv2 254 security protocol are as follows. 256 Data Integrity 257 is the provision of the property that data has not been altered or 258 destroyed in an unauthorized manner, nor have data sequences been 259 altered to an extent greater than can occur non-maliciously. 261 Data Origin Authentication 262 is the provision of the property that the claimed origin of 263 received data is corroborated. 265 Data Confidentiality 266 is the provision of the property that information is not made 267 available or disclosed to unauthorized individuals, entities, or 268 processes. 270 The protocols specified in this memo require both data integrity and 271 data origin authentication to be used at all times. For these 272 protocols, it is not possible to obtain data integrity without data 273 origin authentication, nor is it possible to obtain data origin 274 authentication without data integrity. 276 Further, there is no provision for data confidentiality without both 277 data integrity and data origin authentication. 279 1.5. Mechanisms 281 The security protocols defined in this memo employ several types of 282 mechanisms in order to realize the goals and security services described 283 above: 285 - In support of data integrity, a message digest algorithm is 286 required. A digest is calculated over an appropriate portion of an 287 SNMPv2 message and included as part of the message sent to the 288 recipient. 290 - In support of data origin authentication and data integrity, the 291 portion of an SNMPv2 message that is digested is first prefixed 292 with a secret value shared by the originator of that message and 293 its intended recipient. 295 - To protect against the threat of message delay or replay, (to an 296 extent greater than can occur through normal operation), a 297 timestamp value is included in each message generated. A recipient 298 evaluates the timestamp to determine if the message is recent. 299 This protection against the threat of message delay or replay does 300 not imply nor provide any protection against unauthorized deletion 301 or suppression of messages. Other mechanisms defined independently 302 of the security protocol can also be used to detect message replay 303 (e.g., the request-id [12]), or for set operations, the re- 304 ordering, replay, deletion, or suppression of messages (e.g., the 305 MIB variable snmpSetSerialNo [14]). 307 - In support of data confidentiality, a symmetric encryption 308 algorithm is required. An appropriate portion of the message is 309 encrypted prior to being transmitted to its recipient. 311 The security protocols in this memo are defined independently of the 312 particular choice of a message digest and encryption algorithm - owing 313 principally to the lack of a suitable metric by which to evaluate the 314 security of particular algorithm choices. However, in the interests of 315 completeness and in order to guarantee interoperability, Sections 1.5.1 316 and 1.5.2 specify particular choices, which are considered acceptably 317 secure as of this writing. In the future, this memo may be updated by 318 the publication of a memo specifying substitute or alternate choices of 319 algorithms, i.e., a replacement for or addition to the sections below. 321 1.5.1. Message Digest Algorithm 323 In support of data integrity, the use of the MD5 [3] message digest 324 algorithm is chosen. A 128-bit digest is calculated over the designated 325 portion of an SNMPv2 message and included as part of the message sent to 326 the recipient. 328 An appendix of [3] contains a C Programming Language implementation of 329 the algorithm. This code was written with portability being the 330 principal objective. Implementors may wish to optimize the 331 implementation with respect to the characteristics of their hardware and 332 software platforms. 334 The use of this algorithm in conjunction with the Digest Authentication 335 Protocol (see Section 3) is identified by the ASN.1 object identifier 336 value v2md5AuthProtocol, defined in [4]. 338 For any SNMPv2 party for which the authentication protocol is 339 v2md5AuthProtocol, the size of its private authentication key is 16 340 octets. 342 Within an authenticated management communication generated by such a 343 party, the size of the authDigest component of that communication (see 344 Section 3) is 16 octets. 346 1.5.2. Symmetric Encryption Algorithm 348 In support of data confidentiality, the use of the Data Encryption 349 Standard (DES) in the Cipher Block Chaining mode of operation is chosen. 350 The designated portion of an SNMPv2 message is encrypted and included as 351 part of the message sent to the recipient. 353 Two organizations have published specifications defining the DES: the 354 National Institute of Standards and Technology (NIST) [5] and the 355 American National Standards Institute [6]. There is a companion Modes 356 of Operation specification for each definition (see [7] and [8], 357 respectively). 359 The NIST has published three additional documents that implementors may 360 find useful. 362 - There is a document with guidelines for implementing and using the 363 DES, including functional specifications for the DES and its modes 364 of operation [9]. 366 - There is a specification of a validation test suite for the DES 367 [10]. The suite is designed to test all aspects of the DES and is 368 useful for pinpointing specific problems. 370 - There is a specification of a maintenance test for the DES [11]. 371 The test utilizes a minimal amount of data and processing to test 372 all components of the DES. It provides a simple yes-or-no 373 indication of correct operation and is useful to run as part of an 374 initialization step, e.g., when a computer reboots. 376 The use of this algorithm in conjunction with the Symmetric Privacy 377 Protocol (see Section 4) is identified by the ASN.1 object identifier 378 value desPrivProtocol, defined in [4]. 380 For any SNMPv2 party for which the privacy protocol is desPrivProtocol, 381 the size of the private privacy key is 16 octets, of which the first 8 382 octets are a DES key and the second 8 octets are a DES Initialization 383 Vector. The 64-bit DES key in the first 8 octets of the private key is 384 a 56 bit quantity used directly by the algorithm plus 8 parity bits - 385 arranged so that one parity bit is the least significant bit of each 386 octet. The setting of the parity bits is ignored by the 387 desPrivProtocol. 389 The length of the octet sequence to be encrypted by the DES must be an 390 integral multiple of 8. When encrypting, the data should be padded at 391 the end as necessary; the actual pad value is irrelevant. 393 If the length of the octet sequence to be decrypted is not an integral 394 multiple of 8 octets, the processing of the octet sequence should be 395 halted and an appropriate exception noted. Upon decrypting, the padding 396 should be ignored. 398 2. SNMPv2 Party 400 Recall from [1] that: 402 - an SNMPv2 entity is an SNMPv2 protocol implementation used by an 403 SNMPv2 agent and/or by one or more management applications; 405 - an SNMPv2 party is an identity assumed by an SNMPv2 entity in order 406 to restrict its actions (for security or other purposes) to an 407 administratively defined subset of all SNMPv2 possible actions; 409 - each SNMPv2 entity maintains a local database, called the Local | 410 Party Datastore (LPD), in which it retains | 411 its own set of information about local and remote SNMPv2 parties 412 and other associated (e.g., access control) information. 414 - each SNMPv2 party has a set of attributes, the generic significance 415 of which is defined in [1]. 417 For each SNMPv2 party that supports the Digest Authentication Protocol, 418 some attributes have additional, specific significance: 420 partyAuthProtocol - 421 the party's authentication protocol which identifies a combination 422 of the Digest Authentication Protocol with a particular digest 423 algorithm (such as that defined in Section 1.5.1). This combined 424 mechanism is used to authenticate the origin and integrity of all 425 messages generated by the party. 427 partyAuthClock - 428 the party's authentication clock which is the local notion of the 429 current time that is specific to the party. 431 partyAuthPrivate - 432 the party's private authentication key which represents the secret 433 value needed to support the Digest Authentication Protocol and 434 associated digest algorithm. 436 partyAuthPublic - 437 the party's public authentication key which represents any public 438 value that may be needed to support the authentication protocol. 439 This attribute is not significant except as suggested in Section 440 5.4. 442 partyAuthLifetime - 443 the lifetime which represents an administrative upper bound on 444 acceptable delivery delay for protocol messages generated by the 445 party. 447 For each SNMPv2 party that supports the Symmetric Privacy Protocol, some 448 attributes have additional, specific significance: 450 partyPrivProtocol - 451 the party's privacy protocol which identifies a combination of the 452 Symmetric Privacy Protocol with a particular encryption algorithm 453 (such as that defined in Section 1.5.2). This combined mechanism 454 is used to protect from disclosure all protocol messages received 455 by the party. 457 partyPrivPrivate - 458 the party's private privacy key which represents any secret value 459 needed to support the Symmetric Privacy Protocol and associated 460 encryption algorithm. 462 partyPrivPublic - 463 the party's public privacy key which represents any public value 464 that may be needed to support the privacy protocol. This attribute 465 is not significant except as suggested in Section 5.4. 467 3. Digest Authentication Protocol 469 The Digest Authentication Protocol provides both for verifying the 470 integrity of a received message (i.e., the message received is the 471 message sent) and for verifying the origin of a message (i.e., the 472 reliable identification of the originator). The integrity of the 473 message is protected by computing a digest over an appropriate portion 474 of a message. The digest is computed by the originator of the message, 475 transmitted with the message, and verified by the recipient of the 476 message. 478 A secret value known only to the originator and recipient of the message 479 is prefixed to the message prior to the digest computation. Thus, the 480 origin of the message is known implicitly with the verification of the 481 digest. 483 A requirement on parties using this Digest Authentication Protocol is 484 that they shall not originate messages for transmission to any receiving 485 party which does not also use this Digest Authentication Protocol. This 486 restriction excludes undesirable side effects of communication between a 487 party which uses these security protocols and a party which does not. 489 Recall from [1] that an SNMPv2 management communication is an ASN.1 490 value with the following syntax: 492 SnmpMgmtCom ::= [2] IMPLICIT SEQUENCE { 493 dstParty 494 OBJECT IDENTIFIER, 495 srcParty 496 OBJECT IDENTIFIER, 497 context 498 OBJECT IDENTIFIER, 499 pdu 500 PDUs 501 } 503 where: 505 dstParty - 506 the destination SNMPv2 party of the SNMPv2 message. 508 srcParty - 509 the source SNMPv2 party of the SNMPv2 message. 511 context - 512 the SNMPv2 context containing the management information referenced 513 by the SNMPv2 message. 515 pdu - 516 an SNMPv2 PDU as defined in [12]. 518 Also recall from [1] that an SNMPv2 authenticated management 519 communication is an ASN.1 value with the following syntax: 521 SnmpAuthMsg ::= [1] IMPLICIT SEQUENCE { 522 authInfo 523 ANY, -- defined by authentication protocol 524 authData 525 SnmpMgmtCom 526 } 528 where: 530 authInfo - 531 the authentication information required in support of the 532 authentication protocol used by the source SNMPv2 party. The 533 detailed significance of the authentication information is specific 534 to the authentication protocol in use, and its only use is in 535 determining whether the communication is authentic or not. 537 authData - 538 an SNMPv2 management communication. 540 In support of the Digest Authentication Protocol, an authInfo component 541 is of type AuthInformation: 543 AuthInformation ::= [2] IMPLICIT SEQUENCE { 544 authDigest 545 OCTET STRING, 546 authDstTimestamp 547 UInteger32 (0..2147483647), | 548 authSrcTimestamp 549 UInteger32 (0..2147483647) | 550 } 552 where: 554 authDigest - 555 the authentication digest which is the value of the digest computed 556 over an appropriate portion of the message, where the message is 557 temporarily prefixed with a secret value for the purposes of 558 computing the digest. 560 authSrcTimestamp - 561 the source authentication timestamp which represents the time of 562 the generation of the message according to the partyAuthClock of 563 the source SNMPv2 party. Note that the granularity of the 564 authentication timestamp is 1 second. 566 authDstTimestamp - 567 the destination authentication timestamp which represents the time 568 of the generation of the message according to the partyAuthClock of 569 the destination SNMPv2 party. Note that the granularity of the 570 authentication timestamp is 1 second. 572 3.1. Generating a Message 574 This section describes the behavior of an SNMPv2 entity when it assumes 575 the identity of an SNMPv2 party using the Digest Authentication Protocol 576 in order to generate a message. Since the behavior of an SNMPv2 entity 577 when generating protocol messages is defined generically in [1], only 578 those aspects of that behavior that are specific to the Digest 579 Authentication Protocol are described below. In particular, this 580 section describes the encapsulation of an SNMPv2 management 581 communication into an SNMPv2 authenticated management communication. 583 According to Section 3.1 of [1], a SnmpAuthMsg value is constructed 584 during Step 3 of generic processing. When the authentication protocol 585 is the Digest Authentication Protocol, the procedure is as follows. 587 (1) The LPD is consulted to retrieve the current values of the | 588 authentication clock and private authentication key of the source 589 SNMPv2 party. The LPD is also consulted to retrieve the current | 590 value of the | 591 authentication clock of the destination SNMPv2 party. 593 (2) The authSrcTimestamp component is set to the retrieved 594 authentication clock value of the source SNMPv2 party. The 595 authDstTimestamp component is set to the retrieved authentication 596 clock value of the destination SNMPv2 party. 598 (3) The authDigest component is temporarily set to the private 599 authentication key of the source SNMPv2 party. The SnmpAuthMsg 600 value is serialized (i.e., encoded) according to the conventions of 601 [13] and [12]. A digest is computed over the octet sequence 602 representing the serialized SnmpAuthMsg value using, for example, 603 the algorithm specified in Section 1.5.1. The authDigest component 604 is then set to the computed digest value. 606 As set forth in [1], the SnmpAuthMsg value is then encapsulated 607 according to the appropriate privacy protocol into a SnmpPrivMsg value. 608 This latter value is then serialized and transmitted to the destination 609 SNMPv2 party. 611 3.2. Receiving a Message 613 This section describes the behavior of an SNMPv2 entity upon receipt of 614 a protocol message from an SNMPv2 party using the Digest Authentication 615 Protocol. Since the behavior of an SNMPv2 entity when receiving 616 protocol messages is defined generically in [1], only those aspects of 617 that behavior that are specific to the Digest Authentication Protocol 618 are described below. 620 According to Section 3.2 of [1], a SnmpAuthMsg value is evaluated during 621 Step 9 of generic processing. When the authentication protocol is the 622 Digest Authentication Protocol, the procedure is as follows. 624 (1) If the ASN.1 type of the authInfo component is not AuthInformation, | 625 then the message is evaluated as unauthentic, the snmpStatsBadAuths | 626 counter [14] is incremented, and a report PDU [1] is generated. | 627 Otherwise, the authSrcTimestamp, authDstTimestamp, and authDigest 628 components are extracted from the SnmpAuthMsg value. 630 (2) The LPD is consulted to retrieve the current values of the | 631 authentication clock, private authentication key and lifetime of 632 the source SNMPv2 party. 634 (3) If the authSrcTimestamp component plus the lifetime is less than | 635 the retrieved authentication clock, then the message is | 636 evaluated as unauthentic, the snmpStatsNotInLifetimes counter [14] | 637 is incremented, and a report PDU [1] is generated. | 639 (4) The authDigest component is extracted and temporarily recorded. 641 (5) A new SnmpAuthMsg value is constructed such that its authDigest 642 component is set to the private authentication key and its other 643 components are set to the value of the corresponding components in 644 the received SnmpAuthMsg value. This new SnmpAuthMsg value is 645 serialized according to the conventions of [13] and [12]. A digest 646 is computed over the octet sequence representing that serialized 647 value using, for example, the algorithm specified in Section 1.5.1. 649 NOTE 650 Because serialization rules are unambiguous but may not be 651 unique, great care must be taken in reconstructing the 652 serialized value prior to computing the digest. 653 Implementations may find it useful to keep a copy of the 654 original serialized value and then simply modify the octets 655 which directly correspond to the placement of the authDigest 656 component, rather than re-applying the serialization algorithm 657 to the new SnmpAuthMsg value. 659 (6) If the computed digest value is not equal to the digest value 660 temporarily recorded in step 4 above, the message is evaluated as 661 unauthentic, then the snmpStatsWrongDigestValues counter [14] is | 662 incremented and a report PDU [1] is generated. | 663 Otherwise, the message is evaluated as authentic. 665 (7) The LPD is consulted for access privileges | 666 permitted by local access policies for the given source destination 667 SNMPv2 parties. If any level of access is permitted, then the | 668 Selective Clock Acceleration mechanism is invoked as follows: | 670 if the authSrcTimestamp value is greater than the current 671 value of the authentication clock stored in the LPD for the | 672 source | 673 SNMPv2 party, then that current value is advanced to the 674 authSrcTimestamp value; and, 676 if the authDstTimestamp value is greater than the current 677 value of the authentication clock stored in the LPD for the | 678 destination | 679 SNMPv2 party, then that current value is advanced to the 680 authDstTimestamp value. 682 (Note that this step is conceptually independent from Steps 15-17 683 of Section 3.2 in [1]). 685 If the SnmpAuthMsg value is evaluated as unauthentic, an authentication 686 failure is noted and the received message is discarded without further 687 processing. Otherwise, processing of the received message continues as 688 specified in [1]. 690 4. Symmetric Privacy Protocol 692 The Symmetric Privacy Protocol provides for an appropriate portion of a 693 message to be encrypted according to a secret key known only to the 694 originator and recipient of the message. 696 This protocol assumes the underlying mechanism is a symmetric encryption 697 algorithm. In addition, the message to be encrypted must be protected 698 according to the conventions of the Digest Authentication Protocol. 700 Recall from [1] that an SNMPv2 private management communication is an 701 ASN.1 value with the following syntax: 703 SnmpPrivMsg ::= [1] IMPLICIT SEQUENCE { 704 privDst 705 OBJECT IDENTIFIER, 706 privData 707 [1] IMPLICIT OCTET STRING 708 } 710 where: 712 privDst - 713 the destination SNMPv2 party of the SNMPv2 message. 715 privData - 716 the (possibly encrypted) serialization (i.e., encoding according to 717 the conventions of [13] and [12]) of an SNMPv2 authenticated 718 management communication. 720 4.1. Generating a Message 722 This section describes the behavior of an SNMPv2 entity when it 723 generates a message having a destination SNMPv2 party which uses the 724 Symmetric Privacy Protocol. Since the behavior of an SNMPv2 entity when 725 generating a protocol message is defined generically in [1], only those 726 aspects of that behavior that are specific to the Symmetric Privacy 727 Protocol are described below. In particular, this section describes the 728 encapsulation of an SNMPv2 authenticated management communication into 729 an SNMPv2 private management communication. 731 According to Section 3.1 of [1], a SnmpPrivMsg value is constructed 732 during Step 5 of generic processing. When the privacy protocol is the 733 Symmetric Privacy Protocol, the procedure is as follows. 735 (1) If the SnmpAuthMsg value is not authenticated according to the 736 conventions of the Digest Authentication Protocol, the generation 737 of the private management communication fails without further 738 processing. 740 (2) The LPD is consulted to retrieve the private | 741 privacy key of the destination SNMPv2 party. 743 (3) The SnmpAuthMsg value is serialized according to the conventions of 744 [13] and [12]. 746 (4) The octet sequence representing the serialized SnmpAuthMsg value is 747 encrypted using, for example, the algorithm specified in Section 748 1.5.2 and the retrieved private privacy key. 750 (5) The privData component is set to the encrypted value. 752 As set forth in [1], the SnmpPrivMsg value is then serialized and 753 transmitted to the destination SNMPv2 party. 755 4.2. Receiving a Message 757 This section describes the behavior of an SNMPv2 entity upon receipt of 758 a protocol message having a destination SNMPv2 party which uses the 759 Symmetric Privacy Protocol. Since the behavior of an SNMPv2 entity when 760 receiving a protocol message is defined generically in [1], only those 761 aspects of that behavior that are specific to the Symmetric Privacy 762 Protocol are described below. 764 According to Section 3.2 of [1], the privData component of a received 765 SnmpPrivMsg value is evaluated during Step 4 of generic processing. 766 When the privacy protocol is the Symmetric Privacy Protocol, the 767 procedure is as follows. 769 (1) The LPD is consulted to retrieve the private | 770 privacy key of the destination SNMPv2 party. 772 (2) The contents octets of the privData component are decrypted using, 773 for example, the algorithm specified in Section 1.5.2 and the 774 retrieved private privacy key. 776 Processing of the received message continues as specified in [1]. 778 5. Clock and Secret Distribution 780 The protocols described in Sections 3 and 4 assume the existence of 781 loosely synchronized clocks and shared secret values. Three 782 requirements constrain the strategy by which clock values and secrets 783 are distributed. 785 - If the value of an authentication clock is decreased, the private 786 authentication key must be changed concurrently. 788 When the value of an authentication clock is decreased, messages 789 that have been sent with a timestamp value between the value of the 790 authentication clock and its new value may be replayed and appear 791 to be recently generated. Changing the private authentication key 792 ensures that such replays will not be evaluated as authentic. 794 - The private authentication key and private privacy key must be 795 known only to the parties requiring knowledge of them. 797 Protecting the secrets from disclosure is critical to the security 798 of the protocols. Knowledge of the secrets must be as restricted 799 as possible within an implementation. A management station has the 800 additional responsibility of remembering the state of all parties 801 across reboots, e.g., by recording the secrets on a long-term 802 storage device. Access to information on this device must be as 803 restricted as is practically possible. 805 - There must exist at least one SNMPv2 entity that assumes the role 806 of a responsible management station. 808 This management station is responsible for ensuring that all 809 authentication clocks are synchronized and for changing the secret 810 values when necessary. Although more than one management station 811 may share this responsibility, their coordination is essential to 812 the secure management of the network. The mechanism by which 813 multiple management stations ensure that no more than one of them 814 attempts to synchronize the clocks or update the secrets at any one 815 time is a local implementation issue. 817 A responsible management station may either support clock 818 synchronization and secret distribution as separate functions, or 819 combine them into a single functional unit. 821 5.1. Initial Configuration 823 This section describes the initial configuration of an SNMPv2 entity 824 that supports the Digest Authentication Protocol or both the Digest 825 Authentication Protocol and the Symmetric Privacy Protocol. 827 When a network device is first installed, its initial, secure 828 configuration must be done manually, i.e., a person must physically 829 visit the device (or perhaps, the device is initially configured on an 830 secure, physically-isolated network), and enter the initial secret 831 values for at least its first pair of secure SNMPv2 parties. 833 Requiring a person to physically visit a device every time an SNMPv2 834 party is configured is administratively prohibitive. The recommended 835 procedure is to configure a small set of initial SNMPv2 parties for each 836 SNMPv2 entity, one pair of which may be subsequently used to configure 837 all other SNMPv2 parties. 839 Configuring one pair of SNMPv2 parties which are then used to configure 840 all other parties has the advantage of exposing (to humans) only one 841 pair of secrets. To limit this exposure, the responsible management 842 station should change these values as its first operation upon 843 completion of the initial configuration. In this way, secrets are known 844 only to the peers requiring knowledge of them in order to communicate. - 845 For enhanced security, it is further recommended that this one pair of 846 parties not be used for any purpose other than the configuration of 847 other SNMPv2 parties. 849 The minimal, useful set of SNMPv2 parties that can be configured for 850 each managed agent is four parties, one of each of the following for 851 both the responsible management station and the managed agent: 853 - an SNMPv2 party for which the authentication protocol and privacy 854 protocol are noAuth and noPriv [1], respectively, and 856 - an SNMPv2 party for which the authentication protocol identifies 857 the mechanism defined in Section 1.5.1, and its privacy protocol is 858 either: noPriv, or the mechanism defined in Section 1.5.2. (Note 859 that the use of a privacy protocol other than noPriv provides a 860 greater level of security, but is not required by this 861 specification.) 863 When installing a managed agent, these parties need to be configured - 864 with their initial secrets, etc., both in the responsible management 865 station and in the new agent. If the responsible management station is 866 configured first, it can be used to generate the initial secrets and 867 provide them to a person for distribution to the managed agent. The 868 following sequence of steps describes the initial configuration of a 869 managed agent and its responsible management station. 871 (1) Determine the initial values for each of the attributes of the 872 SNMPv2 party to be configured. Some of these values may be 873 specified in the MIB document, some may be administratively 874 determined, and some may be computed by the responsible management 875 station. 877 (2) Configure the parties in the responsible management station, 878 recording any initial values computed by the management station. 880 (3) Configure the parties in the managed agent, according to the set of 881 initial values. 883 (4) The responsible management station must then synchronize the 884 authentication clock values for each party it shares with each 885 managed agent. Section 5.3 specifies one strategy by which this 886 could be accomplished. 888 (5) The responsible management station should change the secret values 889 manually configured to ensure the actual values are known only to 890 the peers requiring knowledge of them in order to communicate. To 891 do this, the management station generates new secrets for each 892 party to be reconfigured and distributes the updates using any 893 strategy which protects the new values from disclosure (e.g., the | 894 recommended strategy and procedure described in section 5.4). | 895 Upon receiving positive acknowledgement that the new values have 896 been distributed, the management station should update its LPD with | 897 the new values. | 899 If there are other SNMPv2 entities requiring knowledge of the secrets, 900 the responsible management station must distribute the information upon 901 completion of the initial configuration. The considerations, mentioned 902 above, concerning the protection of secrets from disclosure, also apply 903 in this case. 905 5.2. Clock Distribution 907 For each SNMPv2 party using the Digest Authentication Protocol, the 908 responsible management station must ensure that the party's 909 authentication clock value 911 - is loosely synchronized among all the LPDs in which it appears, | 913 - is reset, as indicated below, upon reaching its maximal value, and 915 - is non-decreasing, except as indicated below. 917 The skew among the clock values must be accounted for in the lifetime 918 value, in addition to the expected communication delivery delay. 920 A skewed authentication clock may be detected by a number of strategies, 921 including knowledge of the accuracy of the system clock, unauthenticated 922 queries of the appropriate MIB object [4], and recognition of 923 authentication failures originated by the party. A procedure for 924 correcting clock skew is presented in Section 5.3. 926 Every SNMPv2 entity must react correctly as an authentication clock 927 approaches its maximal value. If the authentication clock for a 928 particular SNMPv2 party ever reaches the maximal time value, the clock 929 must halt at that value. (The value of interest may be the maximum less 930 lifetime. When authenticating a message, its authentication timestamp 931 is added to lifetime and compared to the authentication clock. An 932 SNMPv2 entity must guarantee that the sum is never greater than the 933 maximal time value.) In this state, the only authenticated request a 934 management station should generate for this party is one that alters the 935 value of at least its authentication clock and private authentication 936 key. In order to reset these values, the responsible management station 937 may set the authentication timestamp in the message to the maximal time 938 value. 940 The value of the authentication clock for a particular SNMPv2 party must 941 never be altered such that its new value is less than its old value, 942 unless its private authentication key is also altered at the same time. 944 5.3. Clock Synchronization 946 Unless the secrets are changed at the same time, the correct way to 947 synchronize clocks is to advance the slower clock to be equal to the 948 faster clock. 950 Suppose that agentParty is a party in a managed agent, and that mgrParty 951 is a party in a corresponding responsible management station. Then, 952 there are four possible conditions of the authentication clocks that 953 could require correction: 955 (1) The management station's notion of the value of agentParty's 956 authentication clock is greater than the agent's notion. 958 (2) The management station's notion of the value of mgrParty's 959 authentication clock is greater than the agent's notion. 961 (3) The agent's notion of the value of agentParty's authentication 962 clock is greater than the management station's notion. 964 (4) The agent's notion of the value of mgrParty's authentication clock 965 is greater than the management station's notion. 967 The Selective Clock Acceleration mechanism described in step 7 of | 968 Section 3.2 corrects conditions 1, 2 and 3 as part of the normal 969 processing of an authentic message. Thus, the clock adjustment 970 procedure below need not provide for any adjustments in those cases. 971 Rather, the following sequence of steps specifies how the clocks may be 972 synchronized when condition 4 occurs. 974 (1) - 975 The responsible management station retrieves the authentication 976 clock value for mgrParty from the agent. This retrieval must be an 977 unauthenticated request, since the management station | 978 knows/suspects that the clocks are unsynchronized. | 979 If the request fails, the clocks cannot be synchronized, and the 980 clock adjustment procedure is aborted without further processing. 982 (2) If the notion of the authentication clock for mgrParty just 983 retrieved from the agent exceeds the management station's notion, 984 then condition 4 is manifest, and the responsible management 985 station advances its notion of the authentication clock for 986 mgrParty to match the agent's notion. - 988 By virtue of the mandatory support for maintenance functions using | 989 internalParty and internalContext [1], the retrieval performed in Step 1 | 990 above SHOULD be performed with these parameters: | 992 srcParty = internalParty | 993 dstParty = internalParty | 994 context = internalContext | 995 operation = get, get-next, or get-bulk | 997 A potential operational problem is the rejection of authentic management | 998 operations which were authenticated using a previous value of the | 999 relevant party clock. This possibility may be avoided if a management | 1000 station defers generation of management traffic between relevant parties | 1001 while this clock adjustment procedure is in progress. | 1003 When authenticated parties are used for sending traps, the above steps | 1004 will not be performed by the agent, nor will the agent detect | 1005 unsynchronized clock conditions. Rather, the manager must perform these | 1006 functions, either as a by-product of using the same set of parties for | 1007 other management operations, or by periodic use of these parties just | 1008 for this purpose. (Note that periodic communication with the agent | 1009 using these parties can be used not only as a means to keep the clocks | 1010 synchronized, but also as a means to detect agent/network failures which | 1011 also affect the delivery of such traps.) | 1013 Advancement of the value of a clock as described above does not | 1014 introduce any new security vulnerabilities since the value of the clock | 1015 is intended to increase with the passage of time. While it is possible | 1016 for an attacker to respond to the unauthenticated retrieval with a clock | 1017 value more advanced than that held by the agent, the first succeeding | 1018 exchange of messages between the manager and the agent negates any | 1019 benefit in doing so, with the possible exception that it causes the | 1020 party's clock to reach its maximum value sooner, a form of denial of | 1021 service against which protection is not provided. | 1023 In general, the advancement of clock values by the manager except as | 1024 required by the synchronization algorithm above (or its equivalent) or | 1025 as required by the Selective Clock Acceleration mechanism (see step 7 of | 1026 Section 3.2), is termed artificial clock advancement of the clock and | 1027 strongly discouraged. | 1028 5.4. Secret Distribution 1030 This section describes one strategy by which SNMPv2 entities which 1031 support at least the Digest Authentication Protocol can change the 1032 secrets for a particular SNMPv2 party. This strategy makes use of the 1033 MIB [4] which provides access via SNMPv2 messages to the parameters of 1034 all SNMPv2 parties known to an SNMPv2 entity. 1036 The frequency with which the secrets of an SNMPv2 party should be 1037 changed is a local administrative issue. However, the more frequently a 1038 secret is used, the more frequently it should be changed. At a minimum, 1039 the secrets must be changed whenever the associated authentication clock 1040 approaches its maximal value. Note that, owing to automatic advances of | 1041 the | 1042 authentication clock described in this memo, the authentication clock 1043 for an SNMPv2 party may well approach its maximal value sooner than 1044 might otherwise be expected. 1046 One of the capabilities provided by [4] is the ability to change the 1047 value of a party's private authentication key and/or private privacy 1048 key, through the use of an SNMPv2 set operation upon the relevant MIB 1049 object(s). This SNMPv2 set operation MUST be encapsulated in an SNMPv2 | 1050 message | 1051 having source and destination parties which use the Digest 1052 Authentication Protocol. 1054 In addition, a mechanism is needed to prevent the disclosure of the (new | 1055 or old) values to eavesdroppers. To achieve this, [4] defines two | 1056 mechanisms. | 1058 First, the | 1059 values of both the authentication key and the privacy key are not 1060 directly represented as MIB objects. Rather, they are represented 1061 according to an encoding. This encoding is the bitwise exclusive-OR of 1062 the old key value with the new key value. - 1063 Use of this encoding provides that neither the new value nor the old | 1064 value are exposed even if a SNMPv2 set operation to modify the values | 1065 directly is encapsulated in | 1066 an SNMPv2 message having source and destination parties which use the 1067 noPriv protocol. In addition, it allows the value of the party's 1068 authentication key to be changed, thereby allowing the value of the 1069 party's authentication clock to be decreased (e.g., when approaching its 1070 maximal value). However, it does nothing to prevent an eavesdropper 1071 with knowledge of the old value from immediately computing the new 1072 value. 1074 Second, [4] defines a mechanism whereby the concatenation of an | 1075 unpredictable value and the old key is subjected to the MD5 one-way hash | 1076 algorithm and the resulting digest exclusive-OR-ed with a pre-computed | 1077 'delta' value to obtain a desired value for the new key (see the | 1078 recommended procedure below). Since this second mechanism employs a | 1079 one-way function, an attacker who learns the new value of the secret | 1080 cannot calculate the previous value, even if he has observed all the | 1081 management traffic used to make the change. | 1083 Nevertheless, there are times (e.g., when there is a possibility that | 1084 the old value of a secret has been compromised) when a network | 1085 administration may require | 1086 the assured ability to set a new uncompromised value. Such a 1087 requirement can normally be met by using source and destination parties 1088 which use encryption (e.g., the Symmetric Privacy Protocol) for the 1089 SNMPv2 set operation. Of course, if the privacy key of either of those 1090 parties is also compromised, the eavesdropper can still easily compute 1091 the new value. Alternatively, a party whose secrets are possibly | 1092 compromised can be destroyed, and recreated (see section 5.5) based on | 1093 the secrets of some other uncompromised party. | 1095 When an SNMPv2 party is used to change its own secrets (e.g., using the + 1096 maintenance function and recommended procedure detailed below) or to + 1097 destroy itself, the destination is required to change the secret + 1098 value(s) stored in its LPD after generating its response. Thus, the + 1099 response will be constructed according to the old value. As the + 1100 responsible management station will not update its LPD until after the + 1101 response is received, it is able to interpret unambiguously any response + 1102 it receives regardless of whether an error occurred in processing the + 1103 set operation. + 1105 By virtue of the mandatory support for maintenance functions on the + 1106 internalContext [1], the set operation to change the secrets of an + 1107 existing party, either , a party in the manager, or + 1108 , a party in an agent, MAY be generated with these + 1109 parameters: + 1111 srcParty = + 1112 dstParty = + 1113 context = internalContext + 1114 operation = set + 1116 to update the secrets within the conceptual row in the partyTable which + 1117 corresponds to either of the authenticated parties, or + 1118 . + 1119 This operation is authorized for any combination of and + 1120 for which at least one ACL exists having: + 1122 acTarget + 1123 acSubject + 1124 acContext any + 1126 When such an authorized combination of and is + 1127 used to access , the operation uses a pseudo-ACL: + 1129 acTarget + 1130 acSubject + 1131 acContext internalContext + 1132 acReadViewIndex + 1133 acWriteViewIndex + 1134 acPrivileges 43 (Get, GetNext, GetBulk, Set) + 1136 where is statically defined to be exactly the following + 1137 subtrees: + 1139 partyAuthClock.agentParty + 1140 partyAuthPrivate.agentParty + 1141 partyAuthPublic.agentParty + 1142 partyPrivPrivate.agentParty + 1143 partyPrivPublic.agentParty + 1144 partyAuthChange.agentParty + 1145 partyPrivChange.agentParty + 1146 partyAuthClock.mgrParty + 1147 partyAuthPrivate.mgrParty + 1148 partyAuthPublic.mgrParty + 1149 partyPrivPrivate.mgrParty + 1150 partyPrivPublic.mgrParty + 1151 partyAuthChange.mgrParty + 1152 partyPrivChange.mgrParty + 1153 partySecretSpinLock + 1155 After transmitting an SNMPv2 set operation to request the value of a 1156 secret be changed, if the responsible management station does not 1157 receive a response, there are two possible causes. 1159 - The request may not have been delivered to the destination. 1161 - The response may not have been delivered to the originator of the 1162 request. 1164 In order to distinguish these two possible error conditions, a 1165 responsible management station could check the destination to see if the 1166 change has occurred. Unfortunately, since the secret values are 1167 unreadable, this is not directly possible. 1169 The recommended strategy for verifying key changes is to set the public 1170 value corresponding to the secret being changed to a recognizable, novel 1171 value: that is, alter the public authentication key value for the 1172 relevant party when changing its private authentication key, or alter 1173 its public privacy key value when changing its private privacy key. In 1174 this way, the responsible management station may retrieve the public 1175 value when a response is not received, and verify whether or not the 1176 change has taken place. (This strategy is available since the public 1177 values are not used by the protocols defined in this memo. If this 1178 strategy is employed, then the public values do become significant. Of 1179 course, protocols using the public values can make use of this strategy 1180 directly.) 1182 In particular, the following procedure is recommended to change the | 1183 secrets of a pair of parties (note that if a party's secrets are | 1184 compromised, some other party should be used to perform these | 1185 operations): | 1187 (1) The management station determines the values for the new secrets, | 1188 generates an unpredictable value for each, and computes the | 1189 appropriate delta values: | 1191 determine desired values for key1New and key2New | 1192 randomValue1 = unpredictable() | 1193 randomValue2 = unpredictable() | 1194 keyIntermediate1 = md5(key1Old || randomValue1) | 1195 deltaValue1 = key1New XOR keyIntermediate1 | 1196 keyIntermediate2 = md5(key2Old || randomValue2) | 1197 deltaValue2 = key2New XOR keyIntermediate2 | 1199 (2) The management station initialises its knowledge of the current | 1200 state of the agent using an authenticated get operation, retrying | 1201 as necessary until a response is received: | 1203 get ( | 1204 lastLock = partySecretSpinLock.0, | 1205 lastNovel = partyAuthPublic. | 1206 ) | 1208 (3) The management station generates a unique novel value (which must | 1209 be different from all previous values of lastNovel used with these | 1210 new secret values). It then concatenates the unpredictable and | 1211 delta values for each party, and conveys them to the agent in a | 1212 single varbindlist, together with the most recently retrieved value | 1213 of the advisory lock and the most recently generated unique novel | 1214 value, using an authenticated set operation with a previously | 1215 unused value of request-id. | 1217 set ( | 1218 partySecretSpinLock.0 = lastLock, | 1219 partyAuthChange. = , | 1220 partyAuthChange. = , | 1221 partyAuthPublic. = uniqueNovelValue | 1222 ) | 1224 If a successful response with the correct request-id value is | 1225 received, then goto step 4. | 1227 If no response or an error response (with the correct request-id) | 1228 is received, then the operation may or may not have been | 1229 successful, due to duplication and/or loss of the request and/or | 1230 the response(s). So, | 1232 - save the error-index and error-status values, | 1233 - re-issue the get operation in step 2; if and | 1234 are being used to change their own secrets, then this | 1235 operation is performed using the new secrets, key1New and | 1236 key2New, and if this operation fails due to an increment of | 1237 snmpStatsWrongDigestValues [4], then goto step 2; | 1238 - retry this get operation as necessary until a response is | 1239 received, | 1240 - if this response indicates that partyAuthPublic has the unique | 1241 novel value assigned in the last set operation, goto step 4. | 1243 Otherwise, the set operation failed, and the saved error values are | 1244 inspected to determine the cause of the failure. | 1246 - if no response was received or the error-index indicates a | 1247 problem with partySecretSpinLock, goto step 2. | 1248 - if the error-index indicates a problem with partyAuthChange or | 1249 partyAuthPublic, the secret cannot be changed to the new | 1250 value. | 1252 (4) Record the new secret values in stable storage. The operation is | 1253 now successfully completed. | 1255 [Retry counts to prevent endlessly looping in the presence of certain | 1256 failures were omitted from the above procedure in the interest of | 1257 brevity.] | 1259 Note that during the period of time after the request has been sent and | 1260 before the success of the operation is determined, the management | 1261 station must keep track of both the old and new secret values. | 1262 Since the delay may be the result of a network failure, the management 1263 station must be prepared to retain both values for an extended period of 1264 time, including across reboots. 1266 5.5. Party Cloning 1268 Another capability provided by [4] is the ability to create a new SNMPv2 1269 party as a "clone" of an existing party. That is, when a new party is 1270 created, if values are not specified for any of its authentication and 1271 privacy parameters, then those parameters take the same values as those 1272 of the party being "cloned". Specifically, the parameters are the 1273 authentication protocol, the public authentication key, the lifetime, 1274 the privacy protocol and the public privacy key. In addition, the 1275 appropriate values of the party being cloned are used as the initial 1276 "old key" values of the new party's private authentication key and the 1277 private privacy key for the purposes of the exclusive-OR encoding 1278 associated with an SNMPv2 set operation. 1280 Further, the new party is not allowed to become active until SNMPv2 set 1281 operation(s) have not only specified the party being cloned but also 1282 changed the new party's private authentication key and private privacy 1283 key. 1285 Similar considerations to those mentioned in the preceding section on 1286 exposure of key values and on the possibility of compromised values, 1287 also apply in this situation. 1289 5.6. Crash Recovery 1291 This section describes the requirements for SNMPv2 entities in 1292 connection with recovery from system crashes or other service 1293 interruptions. 1295 For each SNMPv2 party in the LPD for a particular SNMPv2 | 1296 entity, the SNMPv2 entity must retain the values of the following 1297 information in non-volatile storage: 1299 - its identity, 1301 - an indication of its authentication and privacy protocols, 1303 - its authentication clock, 1305 - its lifetime, 1307 - its private authentication key, and 1309 - its private privacy key. 1311 The authentication clock of an SNMPv2 party is a critical component of 1312 the overall security of the protocols. The inclusion of a reliable 1313 representation of a clock in an SNMPv2 entity is required for overall 1314 security. A reliable clock representation ensures that a clock's value 1315 is monotonically increasing, even across a power loss or other system 1316 failure of the local SNMPv2 entity. One example of a reliable clock 1317 representation is that provided by battery-powered clock-calendar 1318 devices incorporated into some contemporary systems. Another example is 1319 storing and updating a clock value in non-volatile storage at a 1320 frequency of once per U (e.g., 24) hours, and re-initialising that clock | 1321 value on every reboot as the stored value plus U hours. | 1322 It is assumed that management stations always support reliable clock 1323 representations, where clock adjustment by a human operator during crash 1324 recovery may contribute to that reliability. 1326 If a managed agent crashes and does not reboot in time for its 1327 responsible management station to prevent its authentication clock from 1328 reaching its maximal value, upon reboot the clock must be halted at its 1329 maximal value. The procedures specified in Section 5.3 would then 1330 apply. 1332 6. Security Considerations 1334 6.1. Recommended Practices 1336 This section describes practices that contribute to the secure, 1337 effective operation of the mechanisms defined in this memo. 1339 - A management station should discard SNMPv2 responses for which 1340 neither the request-id component nor the represented management 1341 information corresponds to any currently outstanding request. 1343 Although it would be typical for a management station to do this as 1344 a matter of course, when using these security protocols it is 1345 significant due to the possibility of message duplication 1346 (malicious or otherwise). 1348 - A management station should not interpret an agent's lack of 1349 response to an authenticated SNMPv2 management communication as a 1350 conclusive indication of agent or network failure. Authentication | 1351 clock skew or inconsistent notions of shared secrets can also | 1352 result in a lack of response. To distinguish between these causes, | 1353 an unauthenticated retrieval of the party clocks should be used; a | 1354 lack of response to this unauthenticated request will indicate | 1355 agent/network failure; alternatively, the retrieved clock values | 1356 will reveal if clock skew has occurred. If neither of these | 1357 conditions apply, then inspection of the agent's snmpStats counters | 1358 [14] will reveal the cause. | 1360 - The lifetime value for an SNMPv2 party should be chosen by the | 1361 local administration as a compromise between: a) the need to limit | 1362 the size of the "window" during which replay is possible, and b) | 1363 the accuracy of available clock mechanisms, the relevant round-trip | 1364 communications delays, and the frequency | 1365 with which a responsible management station will be able to verify 1366 all clock values. In particular, lifetime needs to be greater than + 1367 all reasonable values of round-trip communications delay, including + 1368 those at times of network stress conditions. + 1370 - When sending state altering messages to a managed agent, a 1371 management station should delay sending successive messages to the 1372 managed agent until a positive acknowledgement is received for the 1373 previous message or until the previous message expires. 1375 No message ordering is imposed by the SNMPv2. Messages may be 1376 received in any order relative to their time of generation and each 1377 will be processed in the ordered received. Note that when an 1378 authenticated message is sent to a managed agent, it will be valid 1379 for a period of time that does not exceed lifetime under normal 1380 circumstances, and is subject to replay during this period. 1382 Indeed, a management station must cope with the loss and re- 1383 ordering of messages resulting from anomalies in the network as a 1384 matter of course. 1386 However, a managed object, snmpSetSerialNo [14], is specifically 1387 defined for use with SNMPv2 set operations in order to provide a 1388 mechanism to ensure the processing of SNMPv2 messages occurs in a 1389 specific order. 1391 - The frequency with which the secrets of an SNMPv2 party should be 1392 changed is indirectly related to the frequency of their use. 1394 Protecting the secrets from disclosure is critical to the overall 1395 security of the protocols. Frequent use of a secret provides a 1396 continued source of data that may be useful to a cryptanalyst in 1397 exploiting known or perceived weaknesses in an algorithm. Frequent 1398 changes to the secret avoid this vulnerability. 1400 Changing a secret after each use is generally regarded as the most 1401 secure practice, but a significant amount of overhead may be 1402 associated with that approach. 1404 Note, too, in a local environment the threat of disclosure may be 1405 insignificant, and as such the changing of secrets may be less 1406 frequent. However, when public data networks are the communication 1407 paths, more caution is prudent. 1409 - In order to foster the greatest degree of security, a management 1410 station implementation must support constrained, pairwise sharing 1411 of secrets among SNMPv2 entities as its default mode of operation. 1413 Owing to the use of symmetric cryptography in the protocols defined 1414 here, the secrets associated with a particular SNMPv2 party must be 1415 known to all other SNMPv2 parties with which that party may wish to 1416 communicate. As the number of locations at which secrets are known 1417 and used increases, the likelihood of their disclosure also 1418 increases, as does the potential impact of that disclosure. 1419 Moreover, if more than two SNMPv2 entities know a particular 1420 secret, then data origin cannot be reliably authenticated because 1421 each such entity has the knowledge needed to generate a message 1422 which will be evaluated as authentic. Thus, the greatest degree of 1423 security is obtained through configurations in which the secrets 1424 for each SNMPv2 party are known to at most two SNMPv2 entities. 1426 6.2. Conformance 1428 An SNMPv2 entity implementation that claims conformance to this memo 1429 must satisfy the following requirements: 1431 (1) It must implement the Digest Authentication Protocol in conjunction 1432 with the algorithm defined in Section 1.5.1. 1434 (2) It must support maintenance operations using internalParty and | 1435 internalContext [1]. | 1437 (3) For each SNMPv2 party about which it maintains information in a | 1438 LPD, an implementation must | 1439 satisfy the following requirements: 1441 (a) It must not allow a party's parameters to be set to a 1442 value inconsistent with its expected syntax. 1444 (b) It must, to the maximal extent possible, prohibit read- 1445 access to the private authentication key and private 1446 encryption key under all circumstances except as required to 1447 generate and/or validate SNMPv2 messages with respect to that 1448 party. 1450 (c) It must allow the party's authentication clock to be 1451 publicly accessible. The correct operation of the Digest 1452 Authentication Protocol requires that it be possible to 1453 determine this value at all times in order to guarantee that 1454 skewed authentication clocks can be resynchronized. 1456 (d) It must prohibit alterations to its local value of the 1457 party's authentication clock independently of alterations to 1458 its value of the private authentication key (unless the clock 1459 alteration is an advancement). 1461 (e) It must never allow its local value of the party's 1462 authentication clock to be incremented beyond the maximal time 1463 value and so "roll-over" to zero. 1465 (f) It must never increase its value of the party's lifetime 1466 except as may be explicitly authorized (via imperative command 1467 or securely represented configuration information) by the 1468 responsible network administrator. 1470 (g) In the event that the non-volatile storage of a party's 1471 parameters (in particular, either the private authentication 1472 key or private encryption key) are lost or destroyed, it must 1473 alter the recorded values of these parameters to random values 1474 so subsequent interaction with that party requires manual 1475 redistribution of new secrets and other parameters. 1477 (4) If it selects new value(s) for a party's secret(s), it must avoid 1478 bad or obvious choices for said secret(s). Choices to be avoided 1479 are boundary values (such as all-zeros) and predictable values 1480 (such as the same value as previously or selecting from a 1481 predetermined set). 1483 (5) It must ensure that a received message for which the source party 1484 uses the Digest Authentication Protocol but the destination party 1485 does not, is always declared to be unauthentic. This may be 1486 achieved explicitly via an additional step in the procedure for 1487 processing a received message, or implicitly by verifying that all 1488 local access control policies enforce this requirement. 1490 7. Acknowledgements 1492 The authors wish to acknowledge the contributions of the SNMPv2 Working 1493 Group in general. In particular, the following individuals 1495 Dave Arneson (Cabletron), 1496 Uri Blumenthal (IBM), 1497 Doug Book (Chipcom), 1498 Maria Greene (Ascom Timeplex), 1499 Deirdre Kostik (Bellcore), 1500 Dave Harrington (Cabletron), 1501 Jeff Johnson (Cisco Systems), 1502 Brian O'Keefe (Hewlett Packard), 1503 Dave Perkins (Bay Networks), 1504 Randy Presuhn (Peer Networks), 1505 Shawn Routhier (Epilogue), 1506 Bob Stewart (Cisco Systems), 1507 Kaj Tesink (Bellcore). 1509 deserve special thanks for their contributions. 1511 8. References 1513 [1] Case, J., Galvin, J., McCloghrie, K., Rose, M., and Waldbusser, S., | 1514 "Administrative Infrastructure for Version 2 of the Simple Network | 1515 Management Protocol (SNMPv2)", | 1516 Internet Draft, SNMP Research, Inc., Trusted Information Systems, | 1517 Cisco Systems, Dover Beach Consulting, Inc., Carnegie Mellon | 1518 University, March 1995. | 1520 [2] Case, J., Fedor, M., Schoffstall, M., Davin, J., "Simple Network 1521 Management Protocol", STD 15, RFC 1157, SNMP Research, Performance 1522 Systems International, MIT Laboratory for Computer Science, May 1523 1990. 1525 [3] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, MIT 1526 Laboratory for Computer Science, April 1992. 1528 [4] Case, J., Galvin, J., McCloghrie, K., Rose, M., and Waldbusser, S., | 1529 "Party MIB for Version 2 of the Simple Network Management Protocol 1530 (SNMPv2)", Internet Draft, SNMP Research, Inc., Trusted Information | 1531 Systems, Cisco Systems, Dover Beach Consulting, Inc., Carnegie | 1532 Mellon University, March 1995. | 1534 [5] Data Encryption Standard, National Institute of Standards and 1535 Technology. Federal Information Processing Standard (FIPS) 1536 Publication 46-1. Supersedes FIPS Publication 46, (January, 1977; 1537 reaffirmed January, 1988). 1539 [6] Data Encryption Algorithm, American National Standards Institute. 1540 ANSI X3.92-1981, (December, 1980). 1542 [7] DES Modes of Operation, National Institute of Standards and 1543 Technology. Federal Information Processing Standard (FIPS) 1544 Publication 81, (December, 1980). 1546 [8] Data Encryption Algorithm - Modes of Operation, American National 1547 Standards Institute. ANSI X3.106-1983, (May 1983). 1549 [9] Guidelines for Implementing and Using the NBS Data Encryption 1550 Standard, National Institute of Standards and Technology. Federal 1551 Information Processing Standard (FIPS) Publication 74, (April, 1552 1981). 1554 [10] Validating the Correctness of Hardware Implementations of the NBS 1555 Data Encryption Standard, National Institute of Standards and 1556 Technology. Special Publication 500-20. 1558 [11] Maintenance Testing for the Data Encryption Standard, National 1559 Institute of Standards and Technology. Special Publication 500-61, 1560 (August, 1980). 1562 [12] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Protocol 1563 Operations for Version 2 of the Simple Network Management Protocol 1564 (SNMPv2)", Internet Draft, SNMP Research, Inc., Cisco Systems, 1565 Dover Beach Consulting, Inc., Carnegie Mellon University, March | 1566 1995. | 1568 [13] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Transport 1569 Mappings for Version 2 of the Simple Network Management Protocol 1570 (SNMPv2)", Internet Draft, SNMP Research, Inc., Cisco Systems, 1571 Dover Beach Consulting, Inc., Carnegie Mellon University, March | 1572 1995. | 1574 [14] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Management 1575 Information Base for Version 2 of the Simple Network Management 1576 Protocol (SNMPv2)", Internet Draft, SNMP Research, Inc., Cisco 1577 Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, | 1578 March 1995. | 1580 APPENDIX A - Protocol Correctness 1582 The correctness of these SNMPv2 security protocols with respect to the 1583 goals stated in Section 1.4 depends on the following assumptions: 1585 (1) The chosen message digest algorithm satisfies its design criteria. 1586 In particular, it is computationally infeasible to discover two 1587 messages that share the same digest value. 1589 (2) It is computationally infeasible to determine the secret used in 1590 calculating a digest on the concatenation of the secret and a 1591 message when both the digest and the message are known. 1593 (3) The chosen symmetric encryption algorithm satisfies its design 1594 criteria. In particular, it is computationally infeasible to 1595 determine the cleartext message from the ciphertext message without 1596 knowledge of the key used in the transformation. 1598 (4) Local notions of a party's authentication clock while it is 1599 associated with a specific private key value are monotonically 1600 non-decreasing (i.e., they never run backwards) in the absence of 1601 administrative manipulations. 1603 (5) The secrets for a particular SNMPv2 party are known only to 1604 authorized SNMPv2 entities. 1606 (6) Local notions of the authentication clock for a particular SNMPv2 1607 party are never altered such that the authentication clock's new 1608 value is less than the current value without also altering the 1609 private authentication key. 1611 For each mechanism of the protocol, an informal account of its 1612 contribution to the required goals is presented below. Pseudocode 1613 fragments are provided where appropriate as examples of possible 1614 implementations; they are intended to be self-explanatory. 1616 A.1 Clock Monotonicity Mechanism 1618 By pairing each sequence of a clock's values with a unique key, the 1619 protocols partially realize goal 3, and the conjunction of this property 1620 with assumption 6 above is sufficient for the claim that, with respect 1621 to a specific private key value, all local notions of a party's 1622 authentication clock are, in general, non-decreasing with time. 1624 A.2 Data Integrity Mechanism 1626 The protocols require computation of a message digest computed over the 1627 SNMPv2 message prepended by the secret for the relevant party. By 1628 virtue of this mechanism and assumptions 1 and 2, the protocols realize 1629 goal 1. 1631 Normally, the inclusion of the message digest value with the digested 1632 message would not be sufficient to guarantee data integrity, since the 1633 digest value can be modified in addition to the message while it is 1634 enroute. However, since not all of the digested message is included in 1635 the transmission to the destination, it is not possible to substitute 1636 both a message and a digest value while enroute to a destination. 1638 Strictly speaking, the specified strategy for data integrity does not 1639 detect an SNMPv2 message modification which appends extraneous material 1640 to the end of such messages. However, owing to the representation of 1641 SNMPv2 messages as ASN.1 values, such modifications cannot - consistent 1642 with goal 1 - result in unauthorized management operations. 1644 The data integrity mechanism specified in this memo protects only 1645 against unauthorized modification of individual SNMPv2 messages. A more 1646 general data integrity service that affords protection against the 1647 threat of message stream modification is not realized by this mechanism, 1648 although limited protection against reordering, delay, and duplication 1649 of messages within a message stream are provided by other mechanisms of 1650 the protocol. 1652 A.3 Data Origin Authentication Mechanism 1654 The data integrity mechanism requires the use of a secret value known 1655 only to communicating parties. By virtue of this mechanism and 1656 assumptions 1 and 2, the protocols explicitly prevent unauthorized 1657 modification of messages. Data origin authentication is implicit if the 1658 message digest value can be verified. That is, the protocols realize 1659 goal 2. 1661 A.4 Data Restricted Authentication Mechanism 1663 This memo requires that implementations preclude administrative 1664 alterations of the authentication clock for a particular party 1665 independently from its private authentication key (unless that clock 1666 alteration is an advancement). 1668 A.5 Message Timeliness Mechanism 1670 The definition of the SNMPv2 security protocols requires that, if the 1671 authentication timestamp value on a received message - augmented by an 1672 administratively chosen lifetime value - is less than the local notion 1673 of the clock for the source SNMPv2 party, the message is not delivered. 1675 if (timestampOfReceivedMsg + 1676 party->administrativeLifetime <= 1677 party->localNotionOfClock) { 1678 msgIsValidated = FALSE; 1679 } 1681 By virtue of this mechanism, the protocols realize goal 3. In cases in 1682 which the local notions of a particular SNMPv2 party clock are 1683 moderately well-synchronized, the timeliness mechanism effectively 1684 limits the age of validly delivered messages. Thus, if an attacker 1685 diverts all validated messages for replay much later, the delay 1686 introduced by this attack is limited to a period that is proportional to 1687 the skew among local notions of the party clock. 1689 A.6 Selective Clock Acceleration Mechanism 1691 The definition of the SNMPv2 security protocols requires that, if either 1692 of the timestamp values for the source or destination parties on a 1693 received, validated message exceeds the corresponding local notion of 1694 the clock for that party, then the local notion of the clock for that 1695 party is adjusted forward to correspond to said timestamp value. This 1696 mechanism is neither strictly necessary nor sufficient to the security 1697 of the protocol; rather, it fosters the clock synchronization on which 1698 valid message delivery depends - thereby enhancing the effectiveness of 1699 the protocol in a management context. 1701 if (msgIsValidated) { 1702 if (timestampOfReceivedMsg > 1703 party->localNotionOfClock) { 1704 party->localNotionOfClock = 1705 timestampOfReceivedMsg; 1706 } 1707 } 1709 The effect of this mechanism is to synchronize local notions of a party 1710 clock more closely in the case where a sender's notion is more advanced 1711 than a receiver's. In the opposite case, this mechanism has no effect 1712 on local notions of a party clock and either the received message is 1713 validly delivered or not according to other mechanisms of the protocol. 1715 Operation of this mechanism does not, in general, improve the 1716 probability of validated delivery for messages generated by party 1717 participants whose local notion of the party clock is relatively less 1718 advanced. In this case, queries from a management station may not be 1719 validly delivered and the management station needs to react 1720 appropriately (e.g., by use of the strategy described in Section 5.3). 1721 In contrast, the delivery of SNMPv2 trap messages generated by an agent 1722 that suffers from a less advanced notion of a party clock is more 1723 problematic, for an agent may lack the capacity to recognize and react 1724 to security failures that prevent delivery of its messages. Thus, the 1725 inherently unreliable character of trap messages is likely to be 1726 compounded by attempts to provide for their validated delivery. 1728 A.7 Confidentiality Mechanism 1730 The protocols require the use of a symmetric encryption algorithm when 1731 the data confidentiality service is required. By virtue of this 1732 mechanism and assumption 3, the protocols realize goal 4. 1734 Authors' Addresses 1736 Jeffrey D. Case + 1737 SNMP Research, Inc. + 1738 3001 Kimberlin Heights Rd. + 1739 Knoxville, TN 37920-9716 + 1740 US + 1742 Phone: +1 615 573 1434 + 1743 Email: case@snmp.com + 1745 James M. Galvin 1746 Trusted Information Systems, Inc. 1747 3060 Washington Road, Route 97 1748 Glenwood, MD 21738 1750 Phone: +1 301 854-6889 1751 EMail: galvin@tis.com 1753 Keith McCloghrie 1754 Cisco Systems, Inc. 1755 170 West Tasman Drive, 1756 San Jose CA 95134-1706. 1758 Phone: +1 408 526 5260 1759 Email: kzm@cisco.com 1761 Marshall T. Rose + 1762 Dover Beach Consulting, Inc. + 1763 420 Whisman Court + 1764 Mountain View, CA 94043-2186 + 1765 US + 1767 Phone: +1 415 968 1052 + 1768 Email: mrose@dbc.mtview.ca.us + 1770 Steven Waldbusser + 1771 Carnegie Mellon University + 1772 5000 Forbes Ave + 1773 Pittsburgh, PA 15213 + 1774 US + 1775 Phone: +1 412 268 6628 + 1776 Email: waldbusser@cmu.edu + 1778 Table of Contents 1780 1 Introduction .................................................... 3 1781 1.1 A Note on Terminology ......................................... 4 1782 1.1.1 Change Log .................................................. 4 1783 1.2 Threats ....................................................... 5 1784 1.3 Goals and Constraints ......................................... 6 1785 1.4 Security Services ............................................. 7 1786 1.5 Mechanisms .................................................... 8 1787 1.5.1 Message Digest Algorithm .................................... 9 1788 1.5.2 Symmetric Encryption Algorithm .............................. 9 1789 2 SNMPv2 Party .................................................... 11 1790 3 Digest Authentication Protocol .................................. 13 1791 3.1 Generating a Message .......................................... 15 1792 3.2 Receiving a Message ........................................... 16 1793 4 Symmetric Privacy Protocol ...................................... 19 1794 4.1 Generating a Message .......................................... 19 1795 4.2 Receiving a Message ........................................... 20 1796 5 Clock and Secret Distribution ................................... 22 1797 5.1 Initial Configuration ......................................... 23 1798 5.2 Clock Distribution ............................................ 25 1799 5.3 Clock Synchronization ......................................... 26 1800 5.4 Secret Distribution ........................................... 28 1801 5.5 Party Cloning ................................................. 33 1802 5.6 Crash Recovery ................................................ 34 1803 6 Security Considerations ......................................... 35 1804 6.1 Recommended Practices ......................................... 35 1805 6.2 Conformance ................................................... 37 1806 7 Acknowledgements ................................................ 39 1807 8 References ...................................................... 39 1808 Appendix A Protocol Correctness ................................... 41 1809 A.1 Clock Monotonicity Mechanism .................................. 41 1810 A.2 Data Integrity Mechanism ...................................... 42 1811 A.3 Data Origin Authentication Mechanism .......................... 42 1812 A.4 Data Restricted Authentication Mechanism ...................... 42 1813 A.5 Message Timeliness Mechanism .................................. 43 1814 A.6 Selective Clock Acceleration Mechanism ........................ 43 1815 A.7 Confidentiality Mechanism ..................................... 44 1816 Authors' Addresses ................................................ 45