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
<galvin@tis.com>, Keith McCloghrie <kzm@hls.com>, and
James R. Davin <jrd@ptt.lcs.mit.edu>.
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