INTERNET-DRAFT July 1990 Authentication and Privacy in the SNMP James M. Galvin Trusted Information Systems, Inc. Keith McCloghrie Hughes LAN Systems, Inc. James R. Davin MIT Laboratory for Computer Science 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 M. Galvin , Keith McCloghrie , and James R. Davin . 2 Introduction The Simple Network Management Protocol (SNMP) specifica- tion [1] allows for the authentication of network management operations by a variety of authentication algorithms. This memo specifies alternatives to the trivial authentication algo- rithm defined in [1]. It also describes an abstract Authenti- cation Service Interface (ASI) by which SNMP-based manage- ment applications or agents may--in a convenient and uniform way--benefit from the algorithms described here and a wide range of others. The terms of the ASI are used to describe three distinct algorithms, including one with support for privacy. Galvin, McCloghrie, Davin [Page 1] INTERNET-DRAFT July 1990 The first of these algorithms is the so-called trivial authentica- tion algorithm initially described in [1]. Although use of the trivial algorithm affords no security whatever, for the sake of consistency, its definition is recast here in terms of the ASI. This alternative definition does not differ in substance from the original. USE OF THE TRIVIAL ALGORITHM ALONE DOES NOT CONSTITUTE SECURE NETWORK MANAGEMENT. THEREFORE, A NETWORK MANAGEMENT SYSTEM THAT IMPLEMENTS ONLY THE TRIVIAL ALGORITHM IS NOT CONFORMANT TO THIS SPECIFICATION. The second algorithm described by this memo is the SNMP authentication algorithm. It provides both for verifying the integrity of a received message (i.e., its correspondence to the original transmission) and for verifying the origin of a message (i.e., the identity of the generator of the message). Message integrity is protected by a checksum of the data and certain other message information. This checksum is computed by the generator of the message, transmitted with the message, and verified by the receiver of the message. Message origin is verified by initializing the checksum computation with a shared secret value. The third algorithm described by this memo is the SNMP authentication and privacy algorithm. In addition to validating message integrity and origin, this algorithm protects messages from disclosure by encrypting their contents according to a shared, secret cryptographic key. The additional functionality afforded by this algorithm is assumed to justify its additional computational cost. This memo does not describe any mechanism for realizing privacy without authentication. Two of the three algorithms described here require the sharing of secret information between the generator of a message and its receiver. The selection of such secrets and their secure distribution to appropriate parties may be accomplished by a variety of strategies. No such strategy is presented in this memo. Strategies for managing the shared secrets required by these algorithms are described in a companion memo [2]. Galvin, McCloghrie, Davin [Page 2] INTERNET-DRAFT July 1990 3 Definitions 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 Galvin, McCloghrie, Davin [Page 3] INTERNET-DRAFT July 1990 TimeTicks, apCommunityInterval INTEGER, apCommunityAdmin OCTET STRING, apCommunityTime 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. 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 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. Galvin, McCloghrie, Davin [Page 4] INTERNET-DRAFT July 1990 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. Relevant administrative strategies are described elsewhere [2]. 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. 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. Relevant administrative strategies are described elsewhere [2]. 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. Relevant administrative strategies are described elsewhere [2]. 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 Galvin, McCloghrie, Davin [Page 5] INTERNET-DRAFT July 1990 (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 Service User An authentication service user is a set of human beings and/or application processes for which the use of SNMP management services is administratively equivalent. An authentication service user is named by an ASN.1 OCTET STRING value. The naming of authentication service users by OCTET STRING values is a local administrative issue. 3.5 Service Identity An authentication service identity is a pairing of the name of an authentication service user with the name of an authentication community by which the identity of the service user may be verified. An authentication service identity is represented by an ASN.1 value with the following syntax: ApServiceId ::= SEQUENCE { apIdUser OCTET STRING, apIdCommunity OCTET STRING } Galvin, McCloghrie, Davin [Page 6] INTERNET-DRAFT July 1990 Typical ApServiceId values might be { apIdUser "galvin", apIdCommunity "keepOut" }, { apIdUser "kzm", apIdCommunity "hushHush" }, { apIdUser "public", apIdCommunity "public" }, or, { apIdUser "jis", apIdCommunity "ATHENA.MIT.EDU" }. 3.6 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. 4 Authentication Service Interface This section describes an abstract Authentication Service Interface (ASI) by which SNMP-based applications and agents may conveniently and uniformly benefit from a range of authentication algorithms. The interface is defined below in terms of three primitive functions. This definition is intended only as an expository aid and as a suggestive guide to implementors; accordingly, no aspect of its form or articulation should be construed as a restriction upon SNMP implementations. The definition of the ASI refers to the following ASN.1 definitions from [1]: Message ::= SEQUENCE { version INTEGER { version-1(0) } Galvin, McCloghrie, Davin [Page 7] INTERNET-DRAFT July 1990 community OCTET STRING data - e.g., PDUs if trivial ANY - authentication is used. } PDUs ::= CHOICE { get-request GetRequest-PDU, get-next-request GetNextRequest-PDU, get-response GetResponse-PDU, set-request SetRequest-PDU, trap Trap-PDU } 4.1 Verification Function ApServiceId authVerify (msg) Message msg; The authVerify function is applied to a SNMP message, an ASN.1 value of type Message, and returns a value of type ApServiceId that names both the authentication service user who generated said message and the authentication community by which that user's identity is authenticated. The authentication community by which this function evaluates the source and/or integrity of said message is that named by the community component of said message. If the community component of said message is not exactly equal to the name of an authentication community supported by the local authentication service, or if the source and/or integrity of said message cannot be appropriately verified, then this function returns an exceptional value indicating failed authentication. Galvin, McCloghrie, Davin [Page 8] INTERNET-DRAFT July 1990 4.2 Encoding Function Message authEncode (pdu, version, userid) PDUs pdu; INTEGER version; ApServiceId userid; The authEncode function is applied to a SNMP PDU, an ASN.1 value of type PDUs, to an INTEGER value that indicates an SNMP protocol version, and to a value of type ApServiceId that specifies both the authentication service user generating said PDU and an authentication community by which the source and/or integrity of said PDU is to be verified or its contents protected from disclosure. This function returns a SNMP message, an ASN.1 value of type Message, that is an encoding of said PDU so that its source is verifiable and/or its contents are protected according to the named authentication community. In particular, the community component of said returned message is the name of the specified authentication community, its data component is an encoding of said PDU according to the conventions of said community, and its version component corresponds to the specified INTEGER value. 4.3 Decoding Function PDUs authDecode (msg) Message msg; The authDecode function is applied to a SNMP message, an ASN.1 value of type Message, and returns a SNMP PDU, an ASN.1 value of type PDUs. The value returned by this function is the PDU that is encapsulated in said message according to the conventions of the authentication community that is named by the community component of said message. Galvin, McCloghrie, Davin [Page 9] INTERNET-DRAFT July 1990 5 Authentication Algorithms This section describes three authentication algorithms: the triv- ial authentication algorithm, the SNMP authentication algo- rithm, and the SNMP authentication and privacy algorithm. Each is articulated as partial definitions of the three primitive functions of the abstract authentication service interface defined elsewhere in this memo. 5.1 Trivial Authentication The trivial authentication algorithm is initially described in [1]. It affords neither authentication of message origin nor authentication of message integrity nor protection against message disclosure. This alternative definition is articulated for the sake of consistency and does not differ in substance from the original. It refers to the following ASN.1 definitions: apAlgorithms ::= { ap 2 } apTrivialAuthAlg ::= { apAlgorithms 1 } USE OF THE TRIVIAL ALGORITHM ALONE DOES NOT CONSTITUTE SECURE NETWORK MANAGEMENT. THEREFORE, A NETWORK MANAGEMENT SYSTEM THAT IMPLEMENTS ONLY THE TRIVIAL ALGORITHM IS NOT CONFORMANT TO THIS SPECIFICATION. For each ASN.1 ApCommunity value that represents a community based upon the trivial authentication algorithm, the significance attributed to each component of that value is described below: o apCommunityName -- This component uniquely identifies the represented community. o apCommunityAlgorithm -- By its correspondence to the value { apTrivialAuthAlg }, Galvin, McCloghrie, Davin [Page 10] INTERNET-DRAFT July 1990 this component unambiguously identifies the trivial authentication algorithm as the basis for the represented community. o apCommunityPrivate -- This component is not significant and may correspond to any ASN.1 OCTET STRING value (e.g., the OCTET STRING value of zero length). o apCommunityPublic -- This component is not significant and may correspond to any ASN.1 OCTET STRING value (e.g., the OCTET STRING value of zero length). o apCommunityClock -- This component is not signifi- cant and may correspond to any ASN.1 TimeTicks value (e.g., the TimeTicks value zero). o apCommunityInterval -- This component is not significant and may correspond to any ASN.1 INTEGER value (e.g., the INTEGER value zero). o apCommunityAdmin -- This component is not significant and may correspond to any ASN.1 OCTET STRING value (e.g., the OCTET STRING value of zero length). o apCommunityAdminTime -- This component is not significant and may correspond to any ASN.1 TimeTicks value (e.g., the TimeTicks value zero). For a community based upon the trivial authentication algorithm, every SNMP Message value for which the community component matches the name of said community is attributed to a (possibly fictitious) authentication service user whose name is also that of the community. The trivial authentication algorithm affords no protection against message disclosure and no assurance of message source or integrity. Authentication communities based upon the trivial authentication algorithm afford no effective support for multiple, distinct authentication service users. Galvin, McCloghrie, Davin [Page 11] INTERNET-DRAFT July 1990 5.1.1 Trivial Verification If the community component of a SNMP message names a community based upon the trivial authentication algorithm, then application of the ASI authVerify function to said Message value returns an ApServiceId value computed according to the following sequence of steps: 1. If the syntax of the data component of said Message value is not PDUs, then the value of said function is an exceptional value indicating failed authentication. 2. Otherwise, the value of said function is the ApServiceId value that represents the community component of said Message value as both the name of the originating authentication service user and the name of the authentication community by which the source of said message is verified. 5.1.2 Trivial Encoding If an ApServiceId value names a community based upon the trivial authentication algorithm, then application of the ASI authEncode function to that value, an INTEGER value, and a SNMP PDUs value returns a SNMP Message value such that o its community component is the community name represented by said ApServiceId value, o its version component is said INTEGER value, and o its data component is said PDUs value. 5.1.3 Trivial Decoding If the community component of a SNMP Message value to which the ASI authDecode function is applied names a community based upon the trivial authentication algorithm, Galvin, McCloghrie, Davin [Page 12] INTERNET-DRAFT July 1990 then the result of that application is the data component of said Message value. 5.2 SNMP Authentication This section describes the SNMP authentication algorithm. While the SNMP authentication algorithm affords some assurances with respect to message origin and integrity, it provides no protection against message disclosure. The definition of this algorithm refers to the MD4 message digest computation described in [8] and to the following ASN.1 definitions: apMD4AuthAlg ::= { apAlgorithms 2 } AuthenticatedPDU ::= [5] IMPLICIT SEQUENCE { digest OCTET STRING (SIZE (16)), authenticData - serialized OCTET STRING - AuthenticatedData } AuthenticatedData ::= [6] IMPLICIT SEQUENCE { timeStamp TimeTicks, serviceUser OCTET STRING, pduData PDUs } For each ASN.1 ApCommunity value that represents a community based upon the SNMP authentication algorithm, the significance attributed to each component of that value is described below: Galvin, McCloghrie, Davin [Page 13] INTERNET-DRAFT July 1990 o apCommunityName -- This component uniquely identifies the represented community. o apCommunityAlgorithm -- By its correspondence to the value { apMD4AuthAlg }, this component unambiguously identifies the SNMP authentication algorithm as the basis for the represented community. o apCommunityPrivate -- This component represents a 16-octet binary value used to seed the MD4 message digest computation when invoked in connection with the represented community. o apCommunityPublic -- This component is not significant and may correspond to any ASN.1 OCTET STRING value (e.g., the OCTET STRING value of zero length). o apCommunityClock -- This component represents a notion of time that is common to all participants in the represented community. o apCommunityInterval -- This component represents an administrative limit on the lifetime of SNMP messages associated with the represented community. o apCommunityAdmin -- The significance of this component is specific to the local administrative strategy. o apCommunityAdminTime -- The significance of this component is specific to the local administrative strategy. To verify the integrity of a message is to verify that it has not been modified enroute from the generator to the receiver. In this algorithm, message integrity is verified by use of the MD4 message digest. The message digest is computed for the message, prefixed by a secret quantity, which, if judiciously chosen, also provides verification of the source of Galvin, McCloghrie, Davin [Page 14] INTERNET-DRAFT July 1990 a message. Thus, message integrity is assured explicitly, while the authentication of message source is realized implicitly in verification of the MD4 message digest. Use of the MD4 mesage digest to protect message integrity represents a thoughtful compromise between engineering economy and the requirements of effective, secure network management. On one hand, the attractive level of protection afforded by cryptographic checksum algorithms is associated with a computational cost that is in many cases prohibitive. On the other hand, the attractively low cost of strategies based on User Datagram Protocol (UDP) [7] checksums, for instance, is associated with an unacceptable level of vulnerability. Effective use of the MD4 mesage digest requires that the representation of ASN.1 values to which it may be applied be consistent among communicating peers. To this end, the definition of the SNMP authentication algorithm entails serialization (according to the conventions of [1]) of ASN.1 values before the digest computation is applied. 5.2.1 SNMP Verification If the community component of a SNMP message names a community based upon the SNMP authentication algorithm, then application of the ASI authVerify function to said Message value returns an ApServiceId value computed according to the following sequence of steps: 1. If the private key for said community is the OCTET STRING value of zero length, then the value of said function is an exceptional value indicating failed authentication. 2. If the syntax of the data component of said Message value is not AuthenticatedPDU, then the value of said function is an exceptional value indicating failed authentication. 3. If the contents octets of the ASN.1 serial encoding for the authenticData component of said Authenticated- Galvin, McCloghrie, Davin [Page 15] INTERNET-DRAFT July 1990 PDU value are not the serialized representation of an AuthenticatedData value, then the value of said func- tion is an exceptional value indicating failed authentica- tion. 4. From the private key for said community, extract the binary seed value. Construct an octet sequence that is the concatenation of said seed value followed by the con- tents octets of the ASN.1 serial encoding for the authen- ticData component of said AuthenticatedPDU value. Compute the MD4 message digest for said octet sequence. 5. If the computed message digest is not equal to the digest component of said AuthenticatedPDU value, then the value of said function is an exceptional value indicating failed authentication. 6. If the timeStamp component of said Authenticated- Data value does not satisfy an appropriate definition of timeliness with respect to the clock for said community, then the value of said function is an exceptional value in- dicating failed authentication. Definitions of timeliness are presented elsewhere in this memo. 7. Otherwise, the value of said function is the ApServiceId value that pairs the serviceUser component of said AuthenticatedData value with the name of said community. 5.2.2 SNMP Encoding If an ApServiceId value names a community based upon the SNMP authentication algorithm, then application of the ASI authEncode function to that value, an INTEGER value, and a SNMP PDUs value returns a SNMP Message value with the following properties: o Its version component is said INTEGER value. o Its community component is the community name represented by said ApServiceId value. Galvin, McCloghrie, Davin [Page 16] INTERNET-DRAFT July 1990 o Its data component is an AuthenticatedPDU value. o The digest component of said AuthenticatedPDU value is the MD4 message digest of an octet sequence that is the concatentation of the binary seed value extracted from the private key for said community followed by the contents octets of the ASN.1 serial encoding for its authenticData component. o The contents octets of the ASN.1 serial encoding for the authenticData component of said Authenticated- PDU value are the serial representation of an Authen- ticatedData value. o The timeStamp component of said Authenticated- Data value satisfies an appropriate definition of timeli- ness with respect to the clock for said community. Defini- tions of timeliness are presented elsewhere in this memo. o The serviceUser component of said Authenticated- Data value names the authentication service user identi- fied by said ApServiceId value. o The pduData component of said AuthenticatedData value is said PDUs value. 5.2.3 SNMP Decoding If the community component of a SNMP message to which the ASI authDecode function is applied names a community based upon the SNMP authentication algorithm, then the result of that application is the pduData component of the AuthenticatedData value that is serially represented by the contents octets of the ASN.1 serial encoding for the authenticData component of said message. 5.3 SNMP Authentication and Privacy This section describes the SNMP authentication and privacy algorithm. This algorithm affords both protection against Galvin, McCloghrie, Davin [Page 17] INTERNET-DRAFT July 1990 message disclosure and equal assurances with respect to message origin and integrity. Implementation of the SNMP authentication and privacy algorithm entails implementation both of the MD4 message digest algorithm and the Data Encryption Standard (DES) [5] encryption algorithm in the cipher block chaining mode (CBC) [6] of operation. Verification of message integrity is provided by the generation of a MD4 message digest and the subsequent encryption of that digest according to the DES. The privacy afforded by the use of encryption is assumed to justify its additional computational cost. Since the DES encryption algorithm is in the public domain, as are several implementations, it is likely that management stations can easily be upgraded to support privacy. In an agent, however, resource considerations may prevail. The definition of this algorithm refers to the MD4 message digest computation described in [8] and to the following ASN.1 definitions: apMD4PrivAlg ::= { apAlgorithms 3 } PrivatePDU ::= [7] IMPLICIT OCTET STRING - encrypted, serialized - AuthenticatedPDU AuthenticatedPDU ::= [5] IMPLICIT SEQUENCE { digest OCTET STRING (SIZE (16)), authenticData - serialized OCTET STRING - AuthenticatedData } AuthenticatedData ::= [6] IMPLICIT SEQUENCE { timeStamp TimeTicks, serviceUser OCTET STRING, Galvin, McCloghrie, Davin [Page 18] INTERNET-DRAFT July 1990 pduData PDUs } For each ASN.1 ApCommunity value that represents a community based upon the SNMP authentication and privacy algorithm, the significance attributed to each component of that value is described below: o apCommunityName -- This component uniquely identifies the represented community. o apCommunityAlgorithm -- By its correspondence to the value { apMD4PrivAlg }, this component unambiguously identifies the SNMP authentication and privacy algorithm as the basis for the represented community. o apCommunityPrivate -- This component is the concatenation of - a 16-octet binary value used to seed the MD4 message digest computation when invoked in connection with the represented community, - a 8-octet DES key used in connection with the represented community, and - a 8-octet DES Initialization Vector (IV) used to prime all DES computations performed in connection with the represented community. o apCommunityPublic -- This component is not significant and may correspond to any ASN.1 OCTET STRING value (e.g., the OCTET STRING value of zero length). o apCommunityClock -- This component represents a notion of time that is common to all participants in the represented community. Galvin, McCloghrie, Davin [Page 19] INTERNET-DRAFT July 1990 o apCommunityInterval -- This component represents an administrative limit on the lifetime of SNMP messages associated with the represented community. o apCommunityAdmin -- The significance of this component is specific to the local administrative strategy. o apCommunityAdminTime -- The significance of this component is specific to the local administrative strategy. To verify the integrity of a message is to verify that it has not been modified enroute from the generator to the receiver. In this algorithm, message integrity is verified by use of the MD4 message digest. The message digest is computed for the message, prefixed by a secret quantity, which, if judiciously chosen, also provides verification of the source of a message. Thus, message integrity is assured explicitly, while the authentication of message source is realized implicitly in verification of the MD4 digest. In the SNMP authentication and privacy algorithm, both message contents and the MD4 digest of those contents are encrypted according to the DES algorithm. This practice not only affords message privacy but also -- by encryption of the digest -- enhances the protection of message integrity. Any additional computational costs entailed by this strategy are outweighed by this additional protection. Effective use of both the DES algorithm and the MD4 message digest requires that the representation of ASN.1 values to which they are applied be consistent among communicating peers. To this end, the definition of the SNMP authentication and privacy algorithm entails serialization (according to the conventions of [1]) of ASN.1 values before either the DES or the digest computation is applied. 5.3.1 SNMP Privacy Verification If the community component of a SNMP message names a community based upon the SNMP authentication and privacy algorithm, then application of the ASI authVerify function to Galvin, McCloghrie, Davin [Page 20] INTERNET-DRAFT July 1990 said Message value returns an ApServiceId value computed according to the following sequence of steps: 1. If the private key for said community is the OCTET STRING value of zero length, then the value of said function is an exceptional value indicating failed authentication. 2. If the syntax of the data component of said Message value is not PrivatePDU, then the value of said function is an exceptional value indicating failed authentication. 3. From the private key for said community, extract the DES key and DES IV quantities. Using the CBC operational mode of the DES algorithm, decrypt the contents octets of the ASN.1 serial encoding for the data component of said message. 4. If the decrypted contents octets of the ASN.1 serial encod- ing for the data component of said Message value are not the serialized representation of an AuthenticatedPDU value, then the value of said function is an exceptional value indicating failed authentication. 5. If the contents octets of the ASN.1 serial encoding for the authenticData component of said Authenticated- PDU value are not the serialized representation of an AuthenticatedData value, then the value of said func- tion is an exceptional value indicating failed authentica- tion. 6. From the private key for said community, extract the binary seed value. Construct an octet sequence that is the concatenation of said seed value followed by the con- tents octets of the ASN.1 serial encoding for the authen- ticData component of said AuthenticatedPDU value. Compute the MD4 message digest for said octet sequence. 7. If the computed message digest is not equal to the digest component of said AuthenticatedPDU value, then the value of said function is an exceptional value indicating failed authentication. Galvin, McCloghrie, Davin [Page 21] INTERNET-DRAFT July 1990 8. If the timeStamp component of said Authenticated- Data value does not satisfy an appropriate definition of timeliness with respect to the clock for said community, then the value of said function is an exceptional value in- dicating failed authentication. Definitions of timeliness are presented elsewhere in this memo. 9. Otherwise, the value of said function is the ApServiceId value that pairs the serviceUser component of said AuthenticatedData value with the name of said community. 5.3.2 SNMP Privacy Encoding If an ApServiceId value names a community based upon the SNMP authentication and privacy algorithm, then application of the ASI authEncode function to that value, an INTEGER value, and a SNMP PDUs value returns a SNMP Message value with the following properties: o Its version component is said INTEGER value. o Its community component is the community name represented by said ApServiceId value. o Its data component is a PrivatePDU value. o The contents octets of the ASN.1 serial encoding for its data component are the serial representation of an AuthenticatedPDU value, encrypted according to the DES key and DES IV extracted from the private key for said community, using the CBC operational mode of the DES algorithm. o The digest component of said AuthenticatedPDU value is the MD4 message digest of an octet sequence that is the concatentation of the binary seed value extracted from the private key for said community followed by the contents octets of the ASN.1 serial encoding for its authenticData component. Galvin, McCloghrie, Davin [Page 22] INTERNET-DRAFT July 1990 o The contents octets of the ASN.1 serial encoding for the authenticData component of said Authenticated- PDU value are the serial representation of an Authen- ticatedData value. o The timeStamp component of said Authenticated- Data value satisfies an appropriate definition of timeli- ness with respect to the clock for said community. Defini- tions of timeliness are presented elsewhere in this memo. o The serviceUser component of said Authenticated- Data value names the authentication service user identi- fied by said ApServiceId value. o The pduData component of said AuthenticatedData value is said PDUs value. 5.3.3 SNMP Privacy Decoding If the community component of a SNMP message to which the ASI authDecode function is applied names a community based upon the SNMP authentication and privacy algorithm, then the result of that application is the pduData component of the AuthenticatedData value that is serially represented by the contents octets of the ASN.1 serial encoding for the authenticData component of the AuthenticatedPDU value that is serially represented by the ASN.1 contents octets of the data component of said message -- when decrypted according to the DES key and DES IV extracted from the private key for said community, using the CBC operational mode of the DES algorithm. 6 Timeliness Reliable identification of message origin requires that authentic messages be distinguished from spurious replays of previous legitimate messages. Galvin, McCloghrie, Davin [Page 23] INTERNET-DRAFT July 1990 In a connection-oriented protocol, replay protection can take the form of a monotonically increasing counter maintained by both communicating peers. The incremented counter value is enclosed in each message. Ideally, for a given connection, the initial value of the counter is random. In this situation, the message sequence numbers are often a sufficient indication of message timeliness. In a connectionless protocol, replay protection can be effected by a challenge-response, three-way handshake exchange. In such an exchange, the generator of a message encloses a value that must be returned by the receiver of the message, and the receiver of the message encloses a different but related value in the response that the generator must return in an acknowledgement of said response. Because neither strategy is particularly well-suited to the requirements of effective network management in general or to the operation of the SNMP in particular, algorithms described in this memo adopt a third strategy for replay protection -- the evaluation of message timeliness. By this strategy, with each authentic message is conceptually associated an expiration, a moment in time after which it is considered invalid. Receivers distinguish spurious, duplicated messages from legitimate, authentic ones by comparing their conceptual expirations to some common notion of the current time. The notion of time that is shared among the participants in a particular SNMP authentication community is called the clock for said community. Strategies by which a common sense of time may be maintained among communicating SNMP peers are described elsewhere [2]. Because geographically distributed clocks are rarely synchro- nized, and because communication among SNMP entities is rarely instantaneous, effective use of the timeliness strategy re- quires that the lifetime of a message -- the interval between its generation and its expiration -- approximate the communica- tions delay and clock skew among communicating peers. Thus, in practice, this strategy admits spurious replays of legitimate messages for some bounded period after their generation. Hap- Galvin, McCloghrie, Davin [Page 24] INTERNET-DRAFT July 1990 pily, however, owing to the idempotence of SNMP management operations with respect to managed elements, this limited vul- nerability to replay attack does not significantly compromise a manager's capacity to control the network. (Excluded from this analysis are SNMP operations with catastrophic side-effects such as system reboot or detachment from the network.) A management station may enforce any desired sequence of states upon a managed element by delaying successive state-altering requests until previous requests have expired. The definitions by which an authentication service generates timely SNMP messages and evaluates the timeliness of received SNMP messages are presented below. Although these definitions are completely symmetric in their application to management stations and management agents, they also admit assignment -- consistent with the architectural philosophy of the SNMP -- of primary administrative responsibility to the management station. 6.1 Message Generation The timeStamp component of a SNMP message generated by an authentication service is timely with respect to a given community if said component corresponds to the local sense of the clock for said community. 6.2 Message Receipt The timeStamp component of a SNMP message received at an authentication service is timely with respect to a given community if said component, when added to the allowed interval for said community, exceeds the local sense of the clock for said community. 7 Security Considerations To the extent that a SNMP PDU does not explicitly identify the portion of the global management information base to Galvin, McCloghrie, Davin [Page 25] INTERNET-DRAFT July 1990 which a SNMP management operation applies, a SNMP community comprising more than two participants is vulnerable to attacks involving the duplication or redirection of authentic SNMP messages to unintended destinations with unintended effect. SNMP communities that are based on algorithms that authenticate both data origin and integrity and that comprise only a single management station and a single management agent are not subject to this class of attack. To address the possibility of message duplication (malicious or otherwise), a management station discards SNMP responses for which neither the request-id component nor the represented management information corresponds to any currently outstanding request. 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 (as described in [2]) of an authentication com- munity for which clock synchronization may be lapsed or to provide for continued management in times of network stress, a management station implementation 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 management 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 either the SNMP authentication algorithm or the SNMP authentication and privacy algorithm 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, Galvin, McCloghrie, Davin [Page 26] INTERNET-DRAFT July 1990 relevant round-trip communications delays, and the frequency with which a responsible management station will be able to verify all clock values. The implementation of a management station may provide for dynamic adjustment of the allowed interval in order to accommodate changing network conditions. In general, the timeliness strategy described in this memo admits spurious replays of legitimate messages for some bounded period after their generation. Happily, however, owing to the idempotence of SNMP management operations with respect to managed elements, this limited vulnerability to replay attack does not significantly compromise a manager's capacity to control the network, for a management station may enforce any desired sequence of states upon a managed element by delaying successive state-altering requests until previous requests have expired. An authentication community based upon the trivial authenti- cation algorithm affords no security whatever nor any support for multiple, distinct authentication service users. An authentication community based upon either the SNMP authentication algorithm or the SNMP authentication and privacy algorithm affords support for multiple, distinct authentication service users only when local administrative policy admits a mutual trust among all participants in said community that distinct service users are reliably identified in protocol exchanges. Any access policy that distinguishes among multiple authentication service identities associated with a single community requires this form of trust and is, accordingly, inappropriate in its absence. Galvin, McCloghrie, Davin [Page 27] INTERNET-DRAFT July 1990 A Performance Considerations Effective network management is likely to require widespread deployment of one or more of the authentication algorithms defined in this memo in a wide variety of systems. Accordingly, the performance of the digest computations on which those algorithms depend is critical to the overall success of a management system. To the extent that two algorithms afford a comparable level of security, the algorithm that entails a lower run-time cost is preferable to the other. Performance measurements for a number of candidate digest computations are presented below. Measurements (by J. Mogul, K. McCloghrie, and J. Davin) are times in seconds for 10000 iterations of each algorithm over a 136 octet message. Observations are presented for several machine types, although not all algorithms were tested on all machine types. The MD4 trials are based on Rivest's reference implementation. MD2 trials are based on the implementation (by Rivest) in RFC 1115. The Snefru trials are based on Snefru version 2.0C, modified to accept input from memory rather than a file. The modified version produces the same results as the original. Measures for both 2-pass and 4-pass Snefru are presented, although only the latter merits consideration in this application. The QCMDC trials (both 1-pass and 4-pass) are based on code in the initial public distribution of Kerberos, patch level 8. This code does not support use of the S seed described in [4]. Because this implementation does not fully realize the required arithmetic precision, the QCMDC measurements should be regarded as a lower bound on the performance of a totally conformant implementation. Galvin, McCloghrie, Davin [Page 28] INTERNET-DRAFT July 1990 CPU QCMDC4 SNEFRU2 SNEFRU4 DEC DS5000 14.54 2.07 3.74 DEC DS3100 21.95 3.36 5.71 DEC VAX8800 42.34 13.48 25.46 DEC VAX785 170.16 49.52 88.09 DEC VAX2000 240.69 75.76 134.20 DEC VS3200 89.46 30.22 54.62 Sun SPARC1 4.00 7.00 Sun 4/370 3.40 5.70 MIPS M/120 2.89 5.26 IBM RT 14.77 27.28 CPU MD2 MD4 QCMDC1 DEC DS5000 1.21 3.65 DEC DS3100 2.00 5.56 DEC VAX8800 7.62 10.66 DEC VAX785 23.44 43.51 DEC VAX2000 36.39 60.77 DEC VS3200 299.42 11.71 22.56 Sun SPARC1 63.60 1.70 Sun 4/370 51.30 1.50 MIPS M/120 82.35 1.88 IBM RT 166.23 5.47 On the basis of these measurements, and in the absence of information that distinguishes one algorithm from another in terms of the level of security provided, the MD4 message digest is adopted in this memo on the basis of its superior performance. Galvin, McCloghrie, Davin [Page 29] 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 R. Davin, James M. Galvin, and Keith McCloghrie. Administration of SNMP Communities. 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] Robert R. Jueneman, Stephan M. Matyas, and Carl H. Meyer. Message Authentication. IEEE Communications Magazine, 23(9), Sept 1985. [5] National Institute of Standards and Technology. Data Encryption Standard. Federal Information Processing Standard (FIPS) 46-1, U. S. Department of Commerce, Washington, DC, January 1977. [6] National Institute of Standards and Technology. DES Modes of Operation. Federal Information Processing Standard (FIPS) 81, U. S. Department of Commerce, Washington, DC, December 1980. [7] Jon B. Postel. User Datagram Protocol. Request for Comments 768, DDN Network Information Center, SRI International, August 1980. [8] Ronald L. Rivest. The MD4 Message Digest Algorithm. Unpublished Draft, MIT Laboratory for Computer Science, Cambridge, Massachusetts, February 1990. Galvin, McCloghrie, Davin [Page 30] INTERNET-DRAFT July 1990 Contents 1 Status of this Memo 1 2 Introduction 1 3 Definitions 3 3.1 Algorithm 3 3.2 Community 3 3.3 Service 6 3.4 Service User 6 3.5 Service Identity 6 3.6 Message Lifetime 7 4 Authentication Service Interface 7 4.1 Verification Function 8 4.2 Encoding Function 9 4.3 Decoding Function 9 5 Authentication Algorithms 10 5.1 Trivial Authentication 10 5.1.1 Trivial Verification 12 5.1.2 Trivial Encoding 12 5.1.3 Trivial Decoding 13 5.2 SNMP Authentication 13 5.2.1 SNMP Verification 15 5.2.2 SNMP Encoding 16 5.2.3 SNMP Decoding 17 5.3 SNMP Authentication and Privacy 18 5.3.1 SNMP Privacy Verification 21 5.3.2 SNMP Privacy Encoding 22 Galvin, McCloghrie, Davin [Page 31] INTERNET-DRAFT July 1990 5.3.3 SNMP Privacy Decoding 23 6 Timeliness 24 6.1 Message Generation 25 6.2 Message Receipt 25 7 Security Considerations 26 A Performance Considerations 28 Galvin, McCloghrie, Davin [Page 32] ------- End of Forwarded Message