(manager) (proxy) (proxied)
Domain rfc1351Domain rfc1351Domain rfc1351Domain
Address 1.2.3.4, 2002 1.2.3.5, 161 1.2.3.6, 16
Proxied Party noProxy curly noProxy
Auth Prot md5AuthProtocol md5AuthProtocol md5AuthProtocol
Auth Priv Key "0123456789ABCDEF" "GHIJKL0123456789" "MNOPQR0123456789"
Auth Pub Key "" "" ""
Auth Clock 0 0 0
Auth Last Msg 0 0 0
Auth Lifetime 500 500 500
Priv Prot noPriv noPriv noPriv
Priv Priv Key "" "" ""
Priv Pub Key "" "" ""
Table 9: Party Information for Proxy Agent
Target Subject Privileges
moe larry 3
larry moe 20
curly moe 3
moe curly 20
Table 10: Access Information for Native Proxy
the example manager operates at UDP port 2002 at IP address 1.2.3.4
using the identity larry; the proxied party operates at UDP port 161
at IP address 1.2.3.6 using the party identity curly. Messages
generated by all three SNMP parties are authenticated as to origin
and integrity by using the authentication protocol md5AuthProtocol
and distinct, private authentication keys. Although these private key
values ("0123456789ABCDEF," "GHIJKL0123456789," and
"MNOPQR0123456789") are presented here for expository purposes,
knowledge of private keys is not normally afforded to human beings
and is confined to those portions of the protocol implementation that
require it.
In order to interrogate the proxied device associated with the party
curly, the management station larry constructs a SNMP GetNext request
and transmits it to the party moe operating (see Table 7) at UDP port
161 and IP address 1.2.3.5. This request is authenticated using the
private authentication key "0123456789ABCDEF."
When that request is received by the party moe, the originator of the
message is verified as being the party larry by using local knowledge
(see Table 9) of the private authentication key "0123456789ABCDEF."
Because party larry is authorized to issue GetNext (and Get) requests
with respect to party moe by the relevant access control policy
(Table 10), the request is accepted. Because the local database
records the proxied party for party moe as curly, the request is
satisfied by its translation into a corresponding SNMP GetNext
request directed from party moe to party curly. This new
communication is authenticated using the private authentication key
"GHIJKL0123456789" and transmitted to party curly at the IP address
1.2.3.6.
When this new request is received by the party curly, the originator
of the message is verified as being the party moe by using local
knowledge (see Table 9) of the private authentication key
"GHIJKL0123456789." Because party moe is authorized to issue GetNext
(and Get) requests with respect to party curly by the relevant access
control policy (Table 10), the request is accepted. Because the local
database records the proxied party for party curly as noProxy, the
GetNext request is satisfied by local mechanisms. A SNMP GetResponse
message representing the results of the query is then generated by
party curly. This response communication is authenticated as to
origin and integrity using the private authentication key
"MNOPQR0123456789" and transmitted to party moe at IP address 1.2.3.5
(the source address for the corresponding request).
When this response is received by party moe, the originator of the
message is verified as being the party curly by using local knowledge
(see Table 9) of the private authentication key "MNOPQR0123456789."
Because party curly is authorized to issue GetResponse communications
with respect to party moe by the relevant access control policy
(Table 10), the response is not rejected. Instead, it is translated
into a response to the original GetNext request from party larry.
This response is authenticated as to origin and integrity using the
private authentication key "GHIJKL0123456789" and is transmitted to
the party larry at IP address 1.2.3.4 (the source address for the
original request).
When this response is received by the party larry, the originator of
the message is verified as being the party moe by using local
knowledge (see Table 7) of the private authentication key
"GHIJKL0123456789." Because party moe is authorized to issue
GetResponse communications with respect to party larry by the
relevant access control policy (Table 10), the response is accepted,
and the interrogation is complete.
4.4 Public Key Configuration
This section presents an example configuration predicated upon a
hypothetical security protocol. This hypothetical protocol would be
based on asymmetric (public key) cryptography as a means for
providing data origin authentication (but not protection against
disclosure). This example illustrates the consistency of the
administrative model with public key technology, and the extension of
the example to support protection against disclosure should be
apparent.
Identity ollie stan
(agent) (manager)
Domain rfc1351Domain rfc1351Domain
Address 1.2.3.4, 161 1.2.3.5, 2004
Proxied Party noProxy noProxy
Auth Prot pkAuthProtocol pkAuthProtocol
Auth Priv Key "0123456789ABCDEF" ""
Auth Pub Key "" "ghijkl0123456789"
Auth Clock 0 0
Auth Last Msg 0 0
Auth Lifetime 500 500
Priv Prot noPriv noPriv
Priv Priv Key "" ""
Priv Pub Key "" ""
Table 11: Party Information for Public Key Agent
The example configuration comprises a single SNMP agent that
interacts with a single SNMP management station. Tables 11 and 12
present information about SNMP parties that is by the agent and
manager, respectively, while Table 5 presents information about the
local access policy that is known to both manager and agent.
As represented in Table 11, the example agent party operates at UDP
port 161 at IP address 1.2.3.4 using the party identity ollie; the
example manager operates at UDP port 2004 at IP address 1.2.3.5 using
the identity stan. Both ollie and stan authenticate all messages that
they generate as to origin and integrity by using the hypothetical
SNMP authentication protocol pkAuthProtocol and their distinct,
private
Identity ollie stan
(agent) (manager)
Domain rfc1351Domain rfc1351Domain
Address 1.2.3.4, 161 1.2.3.5, 2004
Proxied Party noProxy noProxy
Auth Prot pkAuthProtocol pkAuthProtocol
Auth Priv Key "" "GHIJKL0123456789"
Auth Pub Key "0123456789abcdef" ""
Auth Clock 0 0
Auth Last Msg 0 0
Auth Lifetime 500 500
Priv Prot noPriv noPriv
Priv Priv Key "" ""
Priv Pub Key "" ""
Table 12: Party Information for Public Key Management
Station
authentication keys. Although these private authentication key values
("0123456789ABCDEF" and "GHIJKL0123456789") are presented here for
expository purposes, knowledge of private keys is not normally
afforded to human beings and is confined to those portions of the
protocol implementation that require it.
In most respects, the interaction between manager and agent in this
configuration is almost identical to that in the example of the
minimal, secure SNMP agent described above. The most significant
difference is that neither SNMP party in the public key configuration
has knowledge of the private key by which the other party
authenticates its transmissions. Instead, for each received
authenticated SNMP communication, the identity of the originator is
verified by applying an asymmetric cryptographic algorithm to the
received message together with the public authentication key for the
originating party. Thus, in this configuration, the agent knows the
manager's public key ("ghijkl0123456789") but not its private key
("GHIJKL0123456789"); similarly, the manager knows the agent's public
key ("0123456789abcdef") but not its private key
("0123456789ABCDEF").
For simplicity, privacy protocols are not addressed in this example
configuration, although their use would be necessary to the secure,
automated distribution of secret keys.
4.5 MIB View Configurations
This section describes a convention for the definition of MIB views
and, using that convention, presents example configurations of MIB
views for SNMP parties.
A MIB view is defined by a collection of view subtrees (see Section
3.6), and any MIB view may be represented in this way. Because MIB
view definitions may, in certain cases, comprise a very large number
of view subtrees, a convention for abbreviating MIB view definitions
is desirable.
The convention adopted in [5] supports abbreviation of MIB view
definitions in terms of families of view subtrees that are either
included in or excluded from the definition of the relevant MIB view.
By this convention, a table locally maintained by each SNMP entity
defines the MIB view associated with each SNMP party realized by that
entity. Each entry in the table represents a family of view subtrees
that (according to the status of that entry) is either included in or
excluded from the MIB view of some SNMP party. Each table entry
represents a subtree family as a pairing of an OBJECT IDENTIFIER
value (called the family name) together with a bitstring value
(called the family mask). The family mask indicates which
subidentifiers of the associated family name are significant to the
definition of the represented subtree family. For each possible MIB
object instance, that instance belongs to the view subtree family
represented by a particular table entry if
o the OBJECT IDENTIFIER name of that MIB
object instance comprises at least as many subidentifiers
as does the family name for said table entry, and
o each subidentifier in the name of said MIB object
instance matches the corresponding subidentifier of the
relevant family name whenever the corresponding bit of
the associated family mask is non-zero.
The appearance of a MIB object instance in the MIB view for a
particular SNMP party is related to the membership of that instance
in the subtree families associated with that party in local table
entries:
o If a MIB object instance belongs to none of the relevant
subtree families, then that instance is not in the MIB
view for the relevant SNMP party.
o If a MIB object instance belongs to the subtree family
represented by exactly one of the relevant table entries,
then that instance is included in, or excluded from, the
relevant MIB view according to the status of that entry.
o If a MIB object instance belongs to the subtree families
represented by more than one of the relevant table
entries, then that instance is included in, or excluded
from, the relevant MIB view according to the status of
the single such table entry for which, first, the associated
family name comprises the greatest number of
subidentifiers, and, second, the associated family name is
lexicographically greatest.
The subtree family represented by a table entry for which the
associated family mask is all ones corresponds to the single view
subtree identified by the family name for that entry. Because the
convention of [5] provides for implicit extension of family mask
values with ones, the subtree family represented by a table entry
with a family mask of zero length always corresponds to a single view
subtree.
Party Identity Status Family Name Family Mask
lucy include internet ""h
Table 13: View Definition for Minimal Agent
Using this convention for abbreviating MIB view definitions, some of
the most common definitions of MIB views may be conveniently
expressed. For example, Table 13 illustrates the MIB view definitions
required for a minimal SNMP entity that locally realizes a single
SNMP party for which the associated MIB view embraces all instances
of all MIB objects defined within the internet network management
framework. The represented table has a single entry. The SNMP party
(lucy) for which that entry defines the MIB view is identified in the
first column. The status of that entry (include) signifies that any
MIB object instance belonging to the subtree family represented by
that entry may appear in the MIB view for party lucy. The family name
for that entry is internet, and the zero-length family mask value
signifies that the relevant subtree family corresponds to the single
view subtree rooted at that node.
Another example of MIB view definition (see Table 14) is that of a
SNMP protocol entity that locally realizes multiple SNMP parties with
distinct MIB views. The MIB view associated with the party lucy
comprises all instances of all MIB objects defined within the
internet network management framework, except those pertaining to the
administration of SNMP parties. In contrast, the MIB view attributed
to the party ricky contains only MIB object instances defined in the
system group of the internet-standard MIB together with those object
instances by which SNMP parties are administered.
A more complicated example of MIB view configuration illustrates the
abbreviation of related collections of view subtrees by view subtree
families (see Table 15). In this
Party Identity Status Family Name Family Mask
lucy include internet ""h
lucy exclude snmpParties ""h
ricky include system ""h
ricky include snmpParties ""h
Table 14: View Definition for Multiple Parties
example, the MIB view associated with party lucy includes all object
instances in the system group of the internet-standard MIB together
with some information related to the second network interface
attached to the managed device. However, this interface-related
information does not include the speed of the interface. The family
mask value "FFA0"h in the second table entry signifies that a MIB
object instance belongs to the relevant subtree family if the initial
prefix of its name places it within the ifEntry portion of the
registration hierarchy and if the eleventh subidentifier of its name
is 2. The MIB object instance representing the speed of the second
network interface belongs to the subtree families represented by both
the second and third entries of the table, but that particular
instance is excluded from the MIB view for party lucy because the
lexicographically greater of the relevant family names appears in the
table entry with status exclude.
The MIB view for party ricky is also defined in this example. The
MIB view attributed to the party ricky includes all object instances
in the icmp group of the internet-standard MIB, together with all
information relevant to the fifth network interface attached to the
managed device. In addition, the MIB view attributed to party ricky
includes the number of octets received on the fourth attached network
interface.
While, as suggested by the examples above, a wide range of MIB view
configurations are efficiently supported by the abbreviated
representation of [5], prudent MIB design can sometimes further
reduce the size and complexity of the most
Party Identity Status Family Name Family Mask
lucy include system ""h
lucy include { ifEntry 0 2 } "FFA0"h
lucy exclude { ifSpeed 2 } ""h
ricky include icmp ""h
ricky include { ifEntry 0 5 } "FFA0"h
ricky include { ifInOctets 4 } ""h
Table 15: More Elaborate View Definitions
likely MIB view definitions. On one hand, it is critical that
mechanisms for MIB view configuration impose no absolute constraints
either upon the access policies of local administrations or upon the
structure of MIB namespaces; on the other hand, where the most common
access policies are known, the configuration costs of realizing those
policies may be slightly reduced by assigning to distinct portions of
the registration hierarchy those MIB objects for which local policies
most frequently require distinct treatment. The relegation in [5] of
certain objects to a distinct arc in the MIB namespace is an example
of this kind of optimization.
5. Compatibility
Ideally, all SNMP management stations and agents would communicate
exclusively using the secure facilities described in this memo. In
reality, many SNMP agents may implement only the insecure SNMP
mechanisms described in [1] for some time to come.
New SNMP agent implementations should never implement both the
insecure mechanisms of [1] and the facilities described here. Rather,
consistent with the SNMP philosophy, the burden of supporting both
sorts of communication should fall entirely upon managers. Perhaps
the best way to realize both old and new modes of communication is by
the use of a SNMP proxy agent deployed locally on the same system
with a management station implementation. The management station
implementation itself operates exclusively by using the newer, secure
modes of communication, and the local proxy agent translates the
requests of the manager into older, insecure modes as needed.
It should be noted that proxy agent implementations may require
additional information beyond that described in this memo in order to
accomplish the requisite translation tasks implicit in the definition
of the proxy function. This information could easily be retrieved
from a filestore.
6. Security Considerations
It is important to note that, in the example configuration for native
proxy operations presented in this memo, the use of symmetric
cryptography does not securely prevent direct communication between
the SNMP management station and the proxied SNMP agent.
While secure isolation of the management station and the proxied
agent can, according to the administrative model set forth in this
memo, be realized using symmetric cryptography, the required
configuration is more complex and is not described in this memo.
Rather, it is recommended that native proxy configurations that
require secure isolation of management station from proxied agent be
implemented using security protocols based on asymmetric (or "public
key") cryptography. However, no SNMP security protocols based on
asymmetric cryptography are currently defined.
In order to participate in the administrative model set forth in this
memo, SNMP implementations must support local, non-volatile storage
of the local party database. Accordingly, every attempt has been made
to minimize the amount of non-volatile storage required.
7. References
[1] Case, J., M. Fedor, M. Schoffstall, and J. Davin, The Simple
Network Management Protocol", RFC1157, University of Tennessee
at Knoxville, Performance Systems International, Performance
Systems International, and the MIT Laboratory for Computer
Science, May 1990. (Obsoletes RFC1098.)
[2] Rose, M., and K. McCloghrie, "Structure and Identification of
Management Information for TCP/IP based internets", RFC1155,
Performance Systems International, Hughes LAN Systems, May 1990.
(Obsoletes RFC1065.)
[3] Information Processing -- Open Systems Interconnection --
Specification of Basic Encoding Rules for Abstract Syntax
Notation One (ASN.1), International Organization for
Standardization/International Electrotechnical Institute, 1987,
International Standard 8825.
[4] Galvin, J., McCloghrie, K., and J. Davin, "SNMP Security
Protocols", RFC1352, Trusted Information Systems, Inc., Hughes
LAN Systems, Inc., MIT Laboratory for Computer Science, July
1992.
[5] McCloghrie, K., Davin, J., and J. Galvin, "Definitions of Managed
Objects for Administration of SNMP Parties", RFC1353, Hughes LAN
Systems, Inc., MIT Laboratory for Computer Science, Trusted
Information Systems, Inc., July 1992.
8. Authors' Addresses
James R. Davin
MIT Laboratory for Computer Science
545 Technology Square
Cambridge, MA 02139
Phone: (617) 253-6020
EMail: jrd@ptt.lcs.mit.edu
James M. Galvin
Trusted Information Systems, Inc.
3060 Washington Road, Route 97
Glenwood, MD 21738
Phone: (301) 854-6889
EMail: galvin@tis.com
Keith McCloghrie
Hughes LAN Systems, Inc.
1225 Charleston Road
Mountain View, CA 94043
Phone: (415) 966-7934
EMail: kzm@hls.com