INTERNET-DRAFT July 1990 Administration of SNMP Communities James R. Davin MIT Laboratory for Computer Science James M. Galvin Trusted Information Systems, Inc. Keith McCloghrie Hughes LAN Systems, Inc. July 3, 1990 1 Status of this Memo This draft document will be submitted to the RFC editor as a protocol specification. Distribution of this memo is unlimited. Please send comments to the authors: James R. Davin , James M. Galvin , and Keith McCloghrie . 2 Introduction The Simple Network Management Protocol (SNMP) specifica- tion [1] allows for the authentication of management opera- tions by a variety of authentication algorithms. This memo de- fines two strategies for administering SNMP communities based upon either the SNMP authentication algorithm or the SNMP authentication and privacy algorithm defined in [2]. Insofar as the administration of SNMP communities based upon the triv- ial authentication algorithm may be realized by straightforward application of familiar network management techniques, admin- Davin, Galvin, McCloghrie [Page 1] INTERNET-DRAFT July 1990 istration of such communities is not directly addressed in this memo. The administrative strategies described here are consistent with typical SNMP operational paradigms and with the requirements for robustness that attend network management systems. The goal of these strategies is to provide a mechanism for network management that is at once robust (in the sense of continued, effective operation in times of network stress) and secure (in the sense of providing reasonable protection against unauthorized management operations). However, when the requirements of robustness are found to be in conflict with the requirements of security, the former is preferred to the latter -- on the premise that an insecure, operational mechanism is, in many environments, of greater value than a secure, disfunctional mechanism. For each SNMP community that may be administered according to one of the strategies described herein, this memo addresses o the distribution of a shared secret among community participants and o the distribution of a common clock among community participants. The principal benefits of the described strategies are their support for reasonably secure network management and the automated administration of shared secrets. Among their costs is the implementation of a SNMP authentication algorithm with support for authentication and privacy (e.g., the SNMP authentication and privacy algorithm described in [2]). 3 Definitions These definitions are consistent with those presented in [2]. Davin, Galvin, McCloghrie [Page 2] INTERNET-DRAFT July 1990 3.1 Algorithm An authentication algorithm is a well-known, possibly parame- terized, distributed algorithm by which o the source of SNMP Protocol Data Units (PDUs) may be verified, o the integrity of SNMP PDUs may be verified, and/or o the content of SNMP PDUs may be protected from disclosure. An authentication algorithm is represented by an ASN.1 OBJECT IDENTIFIER value assigned from an appropriate portion of the registration hierarchy. The value by which an authentication algorithm is represented is called its name. 3.2 Community An authentication community is a named, dynamic instantia- tion of a particular authentication algorithm according to par- ticular values of both the public and private parameters on which said algorithm may depend. A community is represented by an ASN.1 [3] value with the following syntax: ApCommunity ::= SEQUENCE { apCommunityName OCTET STRING, apCommunityAlgorithm OBJECT IDENTIFIER, apCommunityPrivate OCTET STRING, apCommunityPublic OCTET STRING, apCommunityClock TimeTicks, apCommunityInterval Davin, Galvin, McCloghrie [Page 3] INTERNET-DRAFT July 1990 INTEGER, apCommunityAdmin OCTET STRING, apCommunityAdminTime TimeTicks } The following statements are true of every ApCommunity value that represents an authentication community: o The apCommunityName component is called the name for said community and uniquely identifies said community among those recognized by a particular authentication service. The naming of authentication communities by OCTET STRING values is a local administrative issue. o The apCommunityAlgorithm component is called the algorithm for said community and identifies an authentication algorithm by which the source and integrity of SNMP messages may be verified or their contents protected from disclosure. o The apCommunityPrivate component is called the private key or secret for said community and represents secret information on which the algorithm for said community may depend. Secret or private information is information that may be required for operation of a particular authentication algorithm but that may not be known to untrusted parties without adversely affecting the desired level of security. In this memo, uninitialized or corrupt values for the private key of a SNMP community are assumed to be invariably and reliably represented as the ASN.1 OCTET STRING value of zero length. o The apCommunityPublic component is called the public key for said community and represents public information on which the algorithm for said community may depend. Public information is information that may Davin, Galvin, McCloghrie [Page 4] INTERNET-DRAFT July 1990 be required for operation of a particular authentication algorithm and that may be known to untrusted parties without adversely affecting the desired level of security. o The apCommunityClock component is called the clock for said community and represents a common notion of time that is shared among community participants. The epoch from which this common notion of time is reckoned is specific to the local administrative strategy. Two such strategies are defined in this memo. In this memo, uninitialized or corrupt values for the clock of a SNMP community are assumed to be invariably and reliably represented as the ASN.1 TimeTicks value zero. o The apCommunityInterval component is called the allowed interval for said community and represents the administrative limit on the lifetime (defined elsewhere in this memo) of messages associated with said community. In this memo, uninitialized or corrupt values for the allowed interval of a SNMP community are assumed to be invariably and reliably represented as the the ASN.1 INTEGER value zero. o The apCommunityAdmin component is called the administrative key for said community and represents shared (possibly secret) information on which the administration of said community may depend. It may figure in secure management of shared secrets, or it may enjoy other significance that is specific to the local administrative strategy. In this memo, uninitialized or corrupt values for the clock of a SNMP community are assumed to be invariably and reliably represented as the the ASN.1 OCTET STRING value of zero length. o The apCommunityAdminTime component is called the administrative clock for said community and repre- sents shared temporal information on which the adminis- tration of said community may depend. Its significance is specific to the local administrative strategy. Davin, Galvin, McCloghrie [Page 5] INTERNET-DRAFT July 1990 In this memo, uninitialized or corrupt values for the administrative clock of a SNMP community are assumed to be invariably and reliably represented as the the ASN.1 TimeTicks value zero. Intuitively, each authentication community may be represented by an ApCommunity value that comprises information common to all participants of that community. For each such ApCommunity value, the detailed significance attributed to its various components is specific to the authentication algorithm upon which the represented community is based. 3.3 Service An authentication service is a mechanism that provides for verification of the source and integrity of SNMP messages (and/or may protect them from disclosure) according to a particular set of uniquely named authentication communities. An authentication service is represented by an ASN.1 value with the following syntax: ApService ::= SEQUENCE OF ApCommunity For each ApService value that represents an authentication service, each of its components represents an authentication community for which said service supports SNMP message authentication. 3.4 Message Lifetime The lifetime of a particular SNMP message is the time interval between its (supposed) generation and the last possible moment at which said message may be accepted as authentic by a correctly-implemented authentication service. Davin, Galvin, McCloghrie [Page 6] INTERNET-DRAFT July 1990 3.5 Trusted Party A trusted party is o an individual, o a group of individuals, or o a representative of such a group that will protect the integrity and prevent disclosure of a secret from untrusted parties. 3.6 Reliable Clock Representation A reliable representation for the clock of a SNMP authentication community is a representation that continues to increase according to the passage of time even when the local authentication service -- owing to power loss or other system failure -- may not be operating. An example of a reliable clock representation is that provided by battery-powered clock- calendar devices incorporated into some contemporary systems. 4 Strategy A This strategy is appropriate to the administration of a SNMP community for which every participating authentication service affords a reliable representation of the clock for said community. 4.1 Distribution of Shared Secret For each SNMP community administered according to this strategy, its private key enjoys a non-volatile, incorruptible, and private representation at each participating authentication service. The administrative key for a SNMP community administered according to this strategy is not significant; it may correspond Davin, Galvin, McCloghrie [Page 7] INTERNET-DRAFT July 1990 to any ASN.1 OCTET STRING value (e.g., the OCTET STRING value of zero length). The private key for a SNMP community administered by this strategy is (re-) initialized by its manual distribution by a trusted party to the authentication service for each participating SNMP peer. When a managed system is first installed, a trusted party manually configures a SNMP community based on an authentication algorithm (e.g., the SNMP authentication and privacy algorithm defined in [2]) that supports both privacy and authentication of SNMP messages. As part of said manual configuration, o the private key for said community is initialized to correspond to a value already known to a responsible management station, and o the clock for said community is initialized to zero. Because continued operational participation of trusted parties is not desirable, the manually distributed initial key is immediately altered (as described below) by application of authenticated, private SNMP SET operations. The altered key value is shared by both managed and managing systems, and it is properly stored so that its operational use at both managed and managing systems does not require the involvement of trusted parties. The private key for said community is subsequently distributed by successful application of private, authenticated SNMP SET operations to those instances of the "write-only" apPrivate MIB object (defined in [4]) that represent said key values. SNMP access to relevant instances of the apPrivate MIB object is properly restricted to communities based on an authentication algorithm that supports both authentication and privacy. Mechanisms for controlling such access are implementation-specific. For each SNMP community administered according to this strategy, the alteration of the private key for said community by application of SNMP SET operations also properly entails Davin, Galvin, McCloghrie [Page 8] INTERNET-DRAFT July 1990 alteration of the clock for said community to a known and recognizably novel value (e.g., zero) by the same SET operations. By this practice, if the response to such a SNMP SET operation is not received by the originating SNMP peer, then the alteration may be confirmed by trivially authenticated queries of an instance of the apClock MIB object (defined in [4]) that represents the clock for said community. A response to an SNMP SET of this kind may not be received owing to o a failure of the relevant management agent, o the loss or corruption of the response on the network, or o the authentication or encryption of the response according to the newly altered key value. This latter case may be precluded by associating a SNMP SET request that entails key alteration with a SNMP community other than that for which the change is requested. 4.2 Distribution of Common Clock For each SNMP community administered according to this strategy, the clock for said community enjoys an incorruptible and reliable representation within the authentication service for each participating SNMP peer. For each such community, the epoch associated with its clock is implicit in the local practice by which said clock is manipulated. For example, if, in local practice, said clock is reset to zero simultaneously with any alteration of the private key for said community, then that clock's epoch is the moment of the most recent alteration of said private key. The interval represented by said clock is reckoned in the units attributed in [6] to the TimeTicks defined type, and its duration is limited by the maximal TimeTicks value. In particular, no implementation of this strategy admits the advancement of such a clock beyond the maximal TimeTicks value. The administrative clock for a SNMP community administered according to this strategy is not significant; it may correspond Davin, Galvin, McCloghrie [Page 9] INTERNET-DRAFT July 1990 to any ASN.1 TimeTicks value (e.g., the TimeTicks value zero). The clock for a SNMP community administered according to this strategy is distributed by o authenticated SNMP queries of instances of the apClock MIB object (defined in [4]) that represent said community clock and o by successful application of authenticated SNMP SET operations to such object instances together with corresponding instances of the apPrivate MIB object (defined in [4]). In order to preclude any vulnerability to replay attack entailed by administrative alteration of a community clock, any alteration of the clock for a SNMP community is properly accompanied by simultaneous alteration of its private key. Thus, any SNMP SET operation that refers to an instance of the apClock MIB object also properly refers to the corresponding instance of the apPrivate MIB object. SNMP SET operations upon relevant instances of the apClock MIB object are properly restricted to communities based on an authentication algorithm that supports authentication of message origin and integrity. Mechanisms for controlling such access are implementation-specific. For each SNMP community administered according to this strategy, distribution of its clock by trivially authenticated SNMP queries introduces vulnerability to replay attack whenever such a retrieved clock value might form the basis for subsequent protocol operations. Accordingly, retrieval of the clock for said community in this way is properly used only o as tentative evaluation of the need for clock (re-) synchronization among community participants or o as the basis for a subsequent authenticated, private SNMP SET operation that alters both clock and private key for said community (as described elsewhere in this memo). Davin, Galvin, McCloghrie [Page 10] INTERNET-DRAFT July 1990 This latter use admits the restoration of authenticated communication among community participants for which a common notion of the clock for said community is lapsed or otherwise lacking. Either usage of trivially authenticated clock queries admits vulnerability to attacks that may entail denial of service, but such attacks are readily detected and do not entail unauthorized invocation of management operations. 5 Strategy B This strategy is appropriate to the administration of a SNMP community for which some participating authentication service may not afford a reliable representation of the clock for said community. 5.1 Distribution of Shared Secret For each SNMP community administered according to this strategy, both its private and administrative keys enjoy non- volatile, incorruptible, and private representations at each participating authentication service. The private and administrative keys for a SNMP community administered by this strategy are (re-) initialized by their manual distribution by a trusted party to the authentication service for each participating SNMP peer. When a managed system is first installed, a trusted party manually configures a SNMP community based on an authentication algorithm (e.g., the SNMP authentication and privacy algorithm defined in [2]) that supports both privacy and authentication of SNMP messages. As part of said manual configuration, o the private key for said community is initialized to correspond to a value already known to a responsible management station, o the administrative key for said community is initialized to correspond to a value already known to a responsible management station, Davin, Galvin, McCloghrie [Page 11] INTERNET-DRAFT July 1990 o the clock for said community is initialized to zero, and o the administrative clock for said community is initialized to correspond to a value already known to a responsible management station. Because continued operational participation of trusted parties is not desirable, these manually distributed initial keys are immediately altered (as described below) by application of authenticated, private SNMP SET operations. These altered key values are shared by both managed and managing systems, and they are properly stored so that their operational use at both managed and managing systems does not require the involvement of trusted parties. The private and administrative keys for said community are subsequently distributed by successful application of private, authenticated SNMP SET operations to those instances of the "write-only" apPrivate and apAdmin MIB objects (defined in [4]) that represent said key values. SNMP access to relevant instances of the apPrivate and apAdmin MIB objects is properly restricted to communities based on an authentication algorithm that supports both authentication and privacy. Mechanisms for controlling such access are implementation- specific. For each SNMP community administered according to this strategy, the alteration of the private key for said community by application of SNMP SET operations also properly entails alteration of the clock for said community to a known and recognizably novel value (e.g., zero) by the same SET operations. By this practice, if the response to such a SNMP SET operation is not received by the originating SNMP peer, then the alteration may be confirmed by trivially authenticated queries of an instance of the apClock MIB object (defined in [4]) that represents the clock for said community. A response to an SNMP SET of this kind may not be received owing to o a failure of the relevant management agent, o the loss or corruption of the response on the network, or Davin, Galvin, McCloghrie [Page 12] INTERNET-DRAFT July 1990 o the authentication or encryption of the response according to the newly altered key value. This latter case may be precluded by associating a SNMP SET request that entails key alteration with a SNMP community other than that for which the change is requested. For each SNMP community administered according to this strategy, the distribution of the administrative key for said community by application of SNMP SET operations also properly entails alteration of the administrative clock for said community by the same SET operations. By this practice, if the response to such a SNMP SET operation is not received by the originating SNMP peer, then the alteration may be confirmed by trivially authenticated queries of an instance of the apAdminTime MIB object (defined in [4]) that represents the clock for said community. 5.2 Distribution of Common Clock For each SNMP community administered according to this strategy, the clock for said community enjoys an incorruptible representation within the authentication service for each participating SNMP peer. For each such community, the epoch associated with its clock is implicit in the local practice by which said clock is manipulated. For example, if, in local practice, said clock is reset to zero simultaneously with any alteration of the private key for said community, then that clock's epoch is the moment of the most recent alteration of said private key. The interval represented by said clock is reckoned in the units attributed in [6] to the TimeTicks defined type, and its duration is limited by the maximal TimeTicks value. In particular, no implementation of this strategy admits the advancement of such a clock beyond the maximal TimeTicks value. For each SNMP community administered according to this strategy, the administrative clock for said community enjoys a non-volatile, incorruptible representation within the authentication service for each participating SNMP peer. The Davin, Galvin, McCloghrie [Page 13] INTERNET-DRAFT July 1990 period represented by said administrative clock is measured in the units attributed in [6] to the TimeTicks defined type, and its duration is limited by the maximal TimeTicks value. Its epoch is, analogous with the community clock, implicit in the local practice by which it is manipulated. The clock for a SNMP community administered according to this strategy is distributed by o authenticated SNMP queries of instances of the apClock MIB object (defined in [4]) that represent said community clock and o by successful application of authenticated SNMP SET operations to such object instances together with corresponding instances of the apPrivate MIB object (defined in [4]). In order to preclude any vulnerability to replay attack entailed by administrative alteration of a community clock, any alteration of the clock for a SNMP community is properly accompanied by simultaneous alteration of its private key. Thus, any SNMP SET operation that refers to an instance of the apClock MIB object also properly refers to the corresponding instance of the apPrivate MIB object. SNMP SET operations upon relevant instances of the apClock MIB object are properly restricted to communities based on an authentication algorithm that supports authentication of message origin and integrity. Mechanisms for controlling such access are implementation-specific. For each SNMP community administered according to this strategy, distribution of its clock by trivially authenticated SNMP queries introduces vulnerability to replay attack whenever such a retrieved clock value might form the basis for subsequent protocol operations. Accordingly, retrieval of the clock for said community in this way is properly used only o as tentative evaluation of the need for clock (re-) synchronization among community participants or Davin, Galvin, McCloghrie [Page 14] INTERNET-DRAFT July 1990 o as the basis for a subsequent authenticated, private SNMP SET operation that alters both clock and private key for said community (as described elsewhere in this memo). This latter use admits the restoration of authenticated communication among community participants for which a common notion of the clock for said community is lapsed or otherwise lacking. Either usage of trivially authenticated clock queries admits vulnerability to attacks that may entail denial of service, but such attacks are readily detected and do not entail unauthorized invocation of management operations. The administrative clock for a SNMP community administered according to this strategy is distributed by o trivially authenticated SNMP queries of instances of the apAdminTime MIB object (defined in [4]) that represent said administrative clock and o by successful application of authenticated SNMP SET operations to such object instances. SNMP SET operations upon relevant instances of the apAdminTime MIB object are properly restricted to communities based on an authentication algorithm that supports authentication of message origin and integrity. Mechanisms for controlling such access are implementation- specific. Because a SNMP community administered according to this strategy may comprise an authentication service that does not reliably keep time through loss of power or local system failure, secure operation is resumed in the wake of such a failure by the following additional measures: o Upon the recovery of said authentication service from a period of failure, its local representation of the clock for said community is altered to correspond to the administrative clock for said community. o Upon the recovery of said authentication service from a period of failure, its local representation of the private Davin, Galvin, McCloghrie [Page 15] INTERNET-DRAFT July 1990 key for said community is altered to correspond to the administrative key for said community. o Upon the recovery of said authentication service from a period of failure, a responsible management station (as described elsewhere in this memo) applies a single, authenticated, private SNMP SET operation to alter the private key, the administrative key, the clock, and administrative clock for said community. 6 Security Considerations In order to preclude any vulnerability to replay attack entailed by administrative alteration of a community clock, any alteration of the clock for a SNMP community is properly accompanied by simultaneous alteration of its private key. Thus, any SNMP SET operation that refers to an instance of the apClock MIB object also properly refers to the corresponding instance of the apPrivate MIB object. In general, the administration of a SNMP community exclusively by SNMP messages associated with another SNMP community has a positive effect upon both the security and robustness of the administrative activity. A particularly secure practice is the institution of SNMP communities whose only use is the distribution of private keys for other SNMP communities. Although these administrative strategies entail an initial distribution of a shared secret by a trusted party, participation of trusted parties is not required beyond initial system installations, and subsequent distributions may be mechanically effected without any human involvement. The security afforded by these strategies is enhanced by local procedures that confine direct human knowledge of shared secrets to brief periods surrounding system installation or reconfiguration. For a SNMP community administered according to the strategies described in this memo, if the private key for said community is relevant to its secure operation, then secure operation requires the alteration of said key (by procedures Davin, Galvin, McCloghrie [Page 16] INTERNET-DRAFT July 1990 described elsewhere in this memo) no less frequently than the period represented by the maximal TimeTicks value. Satisfaction of even the most modest security requirements is unlikely, however, without daily or weekly key rotation. Moreover, as noted elsewhere, the private key for a community in which one or more participants lacks a reliable clock device is properly changed as the first management operation after each failure (or series of failures) of any such participant. As a rule, secure operation requires rotation of keys that is commensurate with the frequency of their use. When the cost of changing keys is low, frequent changes have a positive effect upon security in general. Owing to the possible loss or suppression of authentication fail- ure traps, to possible community clock skew, or to inconsistent notions of shared community secrets, a management station should not interpret an agent's lack of response to an authen- ticated SNMP management operation as a conclusive indica- tion of agent or network failure. In order either to facilitate administration of an authentication community for which clock synchronization may be lapsed or to provide for continued man- agement in times of network stress, a management station im- plementation may provide for arbitrary, artificial advancement of the timestamp on locally generated messages. Because of the ready vulnerability to replay attack introduced by such an adjustment, it is properly employed only to generate manage- ment requests that -- simultaneously with clock redistribution or other administrative task -- alter the private key for said community. The security of a SNMP community based upon certain authentication algorithms (e.g., the SNMP authentication algorithm or the SNMP authentication and privacy algorithm) depends directly upon the proper maintenance of its clock. A management station that participates in such a community is responsible for assuring that a common notion of said clock is distributed among community participants. Effective, secure operation for such a community requires that the sense of its clock entertained by one its participants not differ from the sense entertained by another participant by Davin, Galvin, McCloghrie [Page 17] INTERNET-DRAFT July 1990 more than the allowed interval for said community. Any reduction of the common notion of the clock for such a community to represent an earlier time introduces a ready vulnerability to replay attack and should, therefore, be avoided. In general, vulnerability to replay attack is reduced for a SNMP community for which participating agents entertain consistently less advanced notions of the community clock than do participating management stations. The security of a SNMP community based upon certain authentication algorithms (e.g., the SNMP authentication algorithm or the SNMP authentication and privacy algorithm) also depends upon the magnitude of the allowed interval for said community: a large allowed interval entails greater vulnerability to replay attacks. Thus, the allowed interval for a community is properly chosen (by the local administration) to be as small as possible, given the accuracy of clock devices available to the participants in said community, relevant round- trip communications delays, and the frequency with which a responsible management station will be able to verify all clock values. To address the possibility of message duplication (either er- roneously by the subnetwork, or maliciously by an attacker) a management station properly discards SNMP responses for which either the request-id component or the represented management information corresponds to no currently outstand- ing request. Owing to the possible loss or suppression of au- thentication failure traps, to possible community clock skew, or to inconsistent notions of shared community secrets, a manage- ment station should not interpret an agent's lack of response to an authenticated SNMP management operation as a conclusive indication of agent or network failure. 7 Implementation This section presents suggestions for implementation of the administrative mechanisms described elsewhere in this memo. None of these suggestions should be construed as a restriction Davin, Galvin, McCloghrie [Page 18] INTERNET-DRAFT July 1990 upon SNMP implementations. Within an authentication service that supports the adminis- tration of multiple SNMP communities according to a strategy described in this memo, the clock for each such community may be conveniently represented as an offset from a single, per- service clock. The implementation of such a service might have the following characteristics: o A single TimeTicks value -- called the system real clock -- is a (possibly reliable) representation of the elapsed time since the last initialization of the network management portion of the local system. This value is incremented in real-time, and, for agent systems, may correspond to the value exported as an instance of the sysUpTime MIB object defined in [5]. o For each SNMP community, a single INTEGER value -- called the clock offset for said community -- represents the difference between the clock for said community and the system real clock. In implementations for which the system real clock enjoys a reliable representation, the clock offset for each community properly enjoys a non- volatile representation. o For each SNMP community, whenever the clock for said community is required, it is computed as the sum of the clock offset for said community and the system real clock. o For each SNMP community, the alteration of the clock for said community (e.g., by successful application of a SNMP SET operation) is effectively realized by updating the clock offset for said community to be the desired new clock value reduced by the system real clock. Davin, Galvin, McCloghrie [Page 19] INTERNET-DRAFT July 1990 References [1] Jeffrey D. Case, Mark S. Fedor, Martin L. Schoffstall, and James R. Davin. A Simple Network Management Protocol. Request for Comments 1098, DDN Network Information Center, SRI International, April 1989. [2] James M. Galvin, Keith McCloghrie, and James R. Davin. Authentication and Privacy in the SNMP. Internet Draft, DDN Network Information Center, SRI International, June 1990. [3] Information Processing -- Open Systems Interconnection -- Specification of Abstract Syntax Notation One (ASN.1). In- ternational Organization for Standardization/International Electrotechnical Institute, 1987. International Standard 8824. [4] Keith McCloghrie, James R. Davin, and James M. Galvin. Experimental Definitions of Managed Objects for Administration of SNMP Communities. Internet Draft, DDN Network Information Center, SRI International, June 1990. [5] Keith McCloghrie and Marshall T. Rose. Management Information Base Network Management of TCP/IP based internets. Request for Comments 1066, DDN Network Information Center, SRI International, August 1988. [6] Marshall T. Rose and Keith McCloghrie. Structure and Identification of Management Information for TCP/IP based internets. Request for Comments 1065, DDN Network Information Center, SRI International, August 1988. Davin, Galvin, McCloghrie [Page 20] INTERNET-DRAFT July 1990 Contents 1 Status of this Memo 1 2 Introduction 1 3 Definitions 2 3.1 Algorithm 3 3.2 Community 3 3.3 Service 6 3.4 Message Lifetime 6 3.5 Trusted Party 7 3.6 Reliable Clock Representation 7 4 Strategy A 7 4.1 Distribution of Shared Secret 7 4.2 Distribution of Common Clock 9 5 Strategy B 11 5.1 Distribution of Shared Secret 11 5.2 Distribution of Common Clock 13 6 Security Considerations 16 7 Implementation 18 Davin, Galvin, McCloghrie [Page 21] ------- End of Forwarded Message