draft M. Kornegay
I. Hanson
November 1995
A Convention for Implementing Security
Models for use with the
Simple Network Management Protocol (SNMP)
draft-kornegay-snmpv2-secconv-00.txt
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute working
documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as ``work in progress.''
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Abstract
The purpose of this memo is to focus discussion and work on security
models for the Internet SNMP, and to define conventions promoting
experimentation with various potential methods of solution. These
conventions are based on the concepts of authentication service and
authentication schemes as defined in RFC 1157.
These conventions promote such experimentation in a transparent way
without changing the formats of messages exchanged by SNMP protocol
entities, and without changing the elements of procedure for SNMP
entities. In fact, most currently deployed SNMP implementations could
be classified as one of the compliance definitions defined in this memo.
These conventions rely on the consistent configuration of the peer SNMP
protocol entities, and on non-null authentication service transforms of
the SNMP 'Message.data' field (trivial authentication is considered an
implementation of a null authentication service transform).
It is hoped that this memo, along with complementary memos written by
other interested parties, will result in a better understanding of SNMP
security models, interoperable experimental security models, and
eventually the adoption of standards.
This is a work-in-progress. The authors have considered indexing and
row selection in the authSchemeTable, and the lcdOnlyCompliance as
potentially problematic as they are currently described. Comments on
these and other areas are requested.
Kornegay & Hanson Expires May 1996 [Page 1]
draft Convention for Implementing Security Models November 1995
1. Introduction
A management system contains: several (potentially many) nodes, each
with a processing entity, termed an agent, which has access to
management instrumentation; at least one management station; and a
management protocol, used to convey management information between the
agents and management stations. Operations of the protocol are carried
out under 'security models' which define authentication, authorization,
access control, and privacy policies.
Management stations execute management applications which monitor and
control managed elements. Managed elements are devices such as hosts,
routers, terminal servers, etc., which are monitored and controlled via
access to their management information.
This memo presents a convention for implementing security models for use
with the SNMP frameworks.
Such conventions are considered important and necessary because:
- The current Internet standards track network management
protocols, SNMPv1 and SNMPv2, do not specifically address secure
communications between SNMP protocol entities (trivial
authentication is not considered secure).
- The Network Management Area of the IETF has deferred work on
SNMP security until late 1996.
- There is a market demand for secure SNMP. The conventions defined
within, and in anticipated related memos, will allow
experimentation with and structured deployment of experimental
SNMP security models to take place.
- Implementors may reach implementor's agreements that could result
in potentially interoperable implementations (until such a time
that the Internet standards track addresses secure SNMP).
- The ability to support extendibility in security models allows
SNMP to be specified independent of and not be closely coupled to
any defined security models [a].
- Current and future versions of both SNMP and its security
models will continue to use the same conventions and unified
message format allowing for more interoperability and transition
options as SNMP evolves over time.
----------
[a] This is important since some believe that the lack of experience
with more complex security models and the remote configuration of
such models has resulted in the inability to reach an agreement on
SNMP security for the Internet standards track.
Kornegay & Hanson Expires May 1996 [Page 1]
draft Convention for Implementing Security Models November 1995
- This proposal is intended to result in experimentation with
a variety of security models. It is recommended that the
number of future Internet standards track security models be
kept 'very small' to promote interoperability and simplify
implementations.
- This proposal illustrates that there never was a need to deviate
from the excellent framework defined in [3] when Secure SNMP, SMP,
and SNMPv2/SNMP Administrative Model (now Historical) were
designed. When understood and properly used, it is very flexible,
extensible, and meets all currently anticipated needs.
1.1 A note on terminology
For the purpose of exposition, the original Internet-standard Network
Management Framework, as described in [1-4], is termed the SNMP version
1 framework (SNMPv1). The current framework, as described in [5-15], is
termed the SNMP version 2 framework (SNMPv2). The community-based
SNMPv2 implementation is termed SNMPv2C.
In this memo, the term 'security model' is used to avoid confusion that
may be caused by the use of other terms. For example, the term
'administrative model' might be confused with the SNMP Administrative
Model.
2. Elements of the Model
The elements of the model presented in this memo are based on the high-
level elements of the model as defined in [3].
This section specifically reviews the purposes of these elements and
describes the use of these definitions in the scope of the proposal
presented in this memo.
2.1. 'Message.version' field
The 'version' field of Message indicates which version of SNMP the
message complies with, particularly which type PDUs are contained.
If the 'version' field of Message is 'version-1', that indicates that
the 'data' field of Message contains a possibly transformed encoding of
an SNMPv1 PDU.
If the 'version' field of Message is 'version-2', that indicates that
the 'data' field of Message contains a possibly transformed encoding of
an SNMPv2 PDU.
2.2. 'Message.community' field
The 'community' field of Message indicates the community name for the
message. The community name, the source transport address, and the
Kornegay & Hanson Expires May 1996 [Page 1]
draft Convention for Implementing Security Models November 1995
destination transport address are used by the SNMPv1 authentication
service and its schemes to generate and authenticate SNMP messages.
In practice, current SNMPv1 and future SNMPv2 implementations generally
use this field alone to implement what is termed 'community
authentication', an insecure authentication scheme that accepts and
returns an un-transformed PDU for the 'data' field of Message. This use
generally considers an SNMP message authentic if the community name of
the message matches community names configured for the SNMP entity.
The 'community' field continues to be used exactly as specified in [3],
specifically the flexibility provided by the conceptual authentication
service and its conceptual authentication schemes are utilized.
2.3. 'Message.data' field
The 'data' field of Message contains a possibly transformed SNMP PDU for
the message.
The 'data' field continues to be used exactly as specified in [3],
specifically the flexibility provided by the conceptual authentication
service and its conceptual authentication schemes are utilized.
2.4. Authentication Service
A conceptual authentication service is described in [3] which can
implement various authentication schemes. An authentication scheme is a
transform from a PDU to the 'Message.data' field when generating a
message, or from the 'Message.data' field to a PDU when processing a
received message. The authentication service and its schemes, as
described in [3], provide the following transforms:
Message.data <- f(community, sourceAddress, destinationAddress, PDU)
PDU <- f(Message.community, sourceAddress, destinationAddress,
Message.data)
Where the authentication service is the conceptual function f(). The
former transform is used for generating messages and the latter for
processing received messages.
Authentication schemes were the original intended mechanism for
implementing security mechanisms for SNMP. The description in [3]
avoided defining any specific authentication schemes except the 'trivial
authentication' scheme which provides no transform (and provides no
security benefit).
This memo defines a convention, potentially local and/or SNMP
accessible, for defining and implementing alternative authentication
schemes for the conceptual authentication service in the protocol
entity.
Kornegay & Hanson Expires May 1996 [Page 1]
draft Convention for Implementing Security Models November 1995
The concepts of authentication service and schemes continues to be used
exactly as specified in [3], specifically the flexibility provided by
these concepts is utilized.
2.5. Local Configuration Datastore (LCD)
SNMP protocol entities require some form of LCD to store configuration
information including the entity's transport protocol address, its
communities, and so on.
The LCD information is normally configured when the network element is
initially installed, often using a terminal device connected to a local
port that interacts with a simple configuration program within the
network element.
A table in the LCD that relates communities, source addresses, and
destination addresses to the authentication schemes implemented by that
network element is necessary to implement the conventions specified by
this memo. This table is actually the same table that most likely
already exists in the network element's LCD with the exception of the
column indicating the authentication scheme. In fact, it could be said
that most current implementations implement this LCD table with an
implied scheme for all communities, the trivial authentication scheme.
To implement the conventions specified by this memo, this LCD can remain
an internal private component of the network element as it currently is
for most current implementations, or could be made SNMP accessible to
allow discovery and remote configuration of authentication schemes.
To facilitate a description of the LCD, it is specified as a MIB module
in section 4 of this memo. This specification is not intended to
require or suggest that the LCD must be SNMP accessible, that is an
implementation option.
These concepts for the LCD continue the current practice used in widely
deployed implementations of SNMP, and with this simple extension
facilitate the goals of this memo.
3. Elements of Procedure
The elements of procedure for SNMPv1 and SNMPv2 are not changed at all
by this memo.
What has changed is the explicit specification of conventions for
extending the behavior of the authentication service to implement new
and varying authentication schemes. This in no way affects any of the
elements of procedure.
Kornegay & Hanson Expires May 1996 [Page 1]
draft Convention for Implementing Security Models November 1995
4. Definitions
SNMP-SEC-MODEL-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-IDENTITY, OBJECT-TYPE,
experimental, enterprises, Integer32
FROM SNMPv2-SMI
AutonomousType, RowStatus
FROM SNMPv2-TC
MODULE-COMPLIANCE, OBJECT-GROUP
FROM SNMPv2-CONF;
-- temporary until an 'internet.experimental' assignment is made
objectQuest OBJECT-IDENTIFIER ::= { enterprises 988 }
oqExperimental OBJECT-IDENTIFIER ::= { objectQuest 64 }
secModelMIB MODULE-IDENTITY
LAST-UPDATED "9511??0000Z"
ORGANIZATION "None. Independent submission."
CONTACT-INFO
"Michael L. Kornegay Iain K. Hanson
Postal: Object Quest, Inc. 45, Ouseley Road,
3343 P'Tree Cor Cir, Ste B Wraysbury,
Norcross, GA 30092 Berkshire TW19 5JB
US UK
Tel: +44 1784 482733
E-mail: mlk@mlksys.atl.ga.us iain@hansons.demon.co.uk"
DESCRIPTION
"A conceptual definition of a local configuration datastore
(LCD) for SNMP entities implementing the Conventions for
Implementing Security Models.
Although specified as a MIB module, implementors may choose
whether these conceptual objects are accessible locally and/
or accessible using the SNMP.
See the conformance statements for more details."
-- temporary until an 'internet.experimental' assignment is made
-- ::= { experimental 999 }
::= { oqExperimental 1 }
Kornegay & Hanson Expires May 1996 [Page 1]
draft Convention for Implementing Security Models November 1995
-- registration points
--
-- assignments for authentication schemes and related MIBs
secModelSchemes OBJECT-IDENTITY
STATUS current
DESCRIPTION
"A registration point for security model schemes.
New security model schemes intended to implement the
conventions of this memo and published as experimental RFCs
are encouraged to register under this registration point, or
to define their scheme in their own enterprises name space.
Please direct requests for assignments under this
registration point to one of the contacts listed in this MIB
module."
::= { secModelMIB 1 }
secModelMIBs OBJECT-IDENTITY
STATUS current
DESCRIPTION
"A registration point for security model MIBs."
New security model MIBs intended to implement the
conventions of this memo and published as experimental RFCs
are encouraged to register under this registration point, or
to define their MIB in their own enterprises name space.
Please direct requests for assignments under this
registration point to one of the contacts listed in this MIB
module."
::= { secModelMIB 2 }
Kornegay & Hanson Expires May 1996 [Page 1]
draft Convention for Implementing Security Models November 1995
-- scheme definitions
--
-- assignments for authentication schemes
trivialUnknownAccessControlScheme OBJECT-IDENTITY
STATUS current
DESCRIPTION
"The authentication scheme implementing trivial
authentication with an unknown form of access control on
management information.
Such access control refers to any SNMP implementations that
implement any trivial authentication scheme with an access
control implementation other than that specified by the
trivialRFC1157AccessControlScheme scheme."
::= { secModelSchemes 1 }
trivialRFC1157AccessControlScheme OBJECT-IDENTITY
STATUS current
DESCRIPTION
"The authentication scheme implementing trivial
authentication with RFC 1157 style access control on
management information.
Such access control implements all the concepts described in
section 3.2.5 of RFC 1157 including 'SNMP Community', 'SNMP
MIB view', 'SNMP access mode', 'SNMP community profile', and
'SNMP access policy'."
::= { secModelSchemes 2 }
Kornegay & Hanson Expires May 1996 [Page 1]
draft Convention for Implementing Security Models November 1995
-- the security model authentication service MIB
secModelAuthServiceMIB OBJECT IDENTIFIER ::= { secModelMIB 3 }
authServiceMIBObjects OBJECT IDENTIFIER ::= { secModelAuthServiceMIB 1 }
-- authServiceMIBBasic objects
--
-- a collection of objects providing a conceptual or actually realized
-- LCD for an SNMP entity implementing the conventions in this memo
authServiceMIBBasic OBJECT IDENTIFIER ::= { authServiceMIBObjects 1 }
authServiceCompliance OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of the MODULE-COMPLIANCE macro describing the
level of compliance implemented by this entity."
::= { authServiceMIBBasic 1 }
authSchemeTable OBJECT-TYPE
SYNTAX SEQUENCE OF AuthSchemeEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The (conceptual) table listing the authentication schemes
configured by this entity.
The authentication service will choose an entry from this
table using the following rule:
When traversing this table in its lexical order, the
first entry encountered that matches the authentication
service's parameters (wild card matches are considered
a match) will be the target authentication scheme for
that SNMP message.
Entries in this table need not have sequential values of the
authSchemeIndex (conceptual) column. For the purposes of
matching, lower values have precedence.
In practice, the number of entries in this table will most
likely be very small. It will also be likely that rarely
are more than the authSchemeIndex, authSchemeCommunity, and
authScheme (conceptual) columns are actually specified.
This is because most authentication schemes implementing
security models will most likely define their own source and
destination entities."
::= { authServiceMIBBasic 2 }
Kornegay & Hanson Expires May 1996 [Page 1]
draft Convention for Implementing Security Models November 1995
authSchemeEntry OBJECT-TYPE
SYNTAX AuthSchemeEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry (conceptual row) in the authSchemeTable."
INDEX { authSchemeIndex }
::= { authSchemeTable 1 }
AuthSchemeEntry ::= SEQUENCE {
authSchemeIndex Integer32,
authSchemeCommunity OCTET STRING,
authSchemeTransportDomain AutonomousType,
authSchemeSourceAddr OCTET STRING,
authSchemeDestinationAddr OCTET STRING,
authScheme AutonomousType,
authSchemeStatus RowStatus
}
authSchemeIndex OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A unique value for each entry."
::= { authSchemeEntry 1 }
authSchemeCommunity OBJECT-TYPE
SYNTAX OCTET STRING
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The community string.
The zero length string acts as a wild card matching any
community."
DEFVAL { ''H }
::= { authSchemeEntry 2 }
Kornegay & Hanson Expires May 1996 [Page 1]
draft Convention for Implementing Security Models November 1995
authSchemeTransportDomain OBJECT-TYPE
SYNTAX AutonomousType
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"A transport domain (protocol).
The value { 0 0 } acts as a wild card matching any domain.
One of the values specified by the transport domains
defined in [11]. The value of this object must be
consistent with all address related objects in this
(conceptual) row of the table."
DEFVAL { { 0 0 } }
::= { authSchemeEntry 3 }
authSchemeSourceAddr OBJECT-TYPE
SYNTAX OCTET STRING
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The source transport address for an SNMP message.
The zero length string acts as a wild card matching any
address.
Formatting is that specified by the textual conventions
defined in [11]. The value of this object must be
consistent with all address related objects in this
(conceptual) row of the table."
DEFVAL { ''H }
::= { authSchemeEntry 4 }
authSchemeDestinationAddr OBJECT-TYPE
SYNTAX OCTET STRING
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The destination transport address for an SNMP message.
For purposes of determining matches for authentication
scheme selection the value of this object may be:
- The zero length string which acts as a wild card
indicating any of the local transport addresses of this
protocol entity,
- The value of one of the local transport addresses, or
- The value of a non-local transport address (in this case
it is processed as a match, but authentication scheme
processing of such a message is implementation
specific).
Kornegay & Hanson Expires May 1996 [Page 1]
draft Convention for Implementing Security Models November 1995
In practice, the value will most likely be the wild card or
one of this protocol entity's transport addresses. Other
values of this object result in unspecified implementation
specific behavior.
Formatting is that specified by the textual conventions
defined in [11]. The value of this object must be
consistent with all address related objects in this
(conceptual) row of the table."
DEFVAL { ''H }
::= { authSchemeEntry 5 }
authScheme OBJECT-TYPE
SYNTAX AutonomousType
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The authentication scheme.
One of the values specified by this or related memos."
DEFVAL { trivialUnknownAccessControlScheme }
::= { authSchemeEntry 6 }
authSchemeStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The status of this entry (conceptual row) in the
authSchemeTable."
DEFVAL { createAndGo }
::= { authSchemeEntry 7 }
Kornegay & Hanson Expires May 1996 [Page 1]
draft Convention for Implementing Security Models November 1995
-- conformance information
authServiceMIBConformance
OBJECT IDENTIFIER ::= { secModelAuthServiceMIB 2 }
authServiceMIBCompliances
OBJECT IDENTIFIER ::= { authServiceMIBConformance 1 }
authServiceMIBGroups
OBJECT IDENTIFIER ::= { authServiceMIBConformance 2 }
-- compliance statements
lcdOnlyCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for SNMP entities which
conceptually implement the objects in the authSchemeTable
of this MIB module as only an LCD which is not SNMP
accessible.
It is highly recommended that the least secure access
control for each security model provide read-only access to
these objects (much like the read-only access provided
for the system and snmp groups, often using the community
'public')."
MODULE -- this module
GROUP authServiceBasicGroup
DESCRIPTION
"This group may be accessible using SNMP."
OBJECT authSchemeCompliance
MIN-ACCESS not-accessible
DESCRIPTION
"A compliant implementation need not allow
access to this object."
-- the authServiceTableGroup group is unconditionally optional
-- for this compliance
::= { authServiceMIBCompliances 1 }
snmpMinimumCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for SNMP entities which
implement the objects in this MIB module as SNMP
accessible.
It is highly recommended that the least secure access
control for each security model provide read-only access to
these objects (much like the read-only access using the
community 'public' often provided for the system and snmp
groups).
Kornegay & Hanson Expires May 1996 [Page 1]
draft Convention for Implementing Security Models November 1995
Note that this compliance allows a great deal of choice to
the implementor on which and how various objects are
accessible (note the MIN-ACCESS clauses).
The implementor could limit their implementation of the
table to being read-only, can omit the specified
(conceptual) columns, and so on."
MODULE -- this module
GROUP authServiceBasicGroup
DESCRIPTION
"This group must be fully accessible using SNMP."
GROUP authServiceTableGroup
DESCRIPTION
"This group may be fully or partially accessible using
SNMP."
OBJECT authSchemeIndex
MIN-ACCESS read-only
DESCRIPTION
"A compliant implementation need only allow
read-only access to this object."
OBJECT authSchemeCommunity
MIN-ACCESS read-only
DESCRIPTION
"A compliant implementation need only allow
read-only access to this object."
OBJECT authSchemeTransportDomain
MIN-ACCESS not-accessible
DESCRIPTION
"A compliant implementation need not allow
access to this object."
OBJECT authSchemeSourceAddr
MIN-ACCESS not-accessible
DESCRIPTION
"A compliant implementation need not allow
access to this object."
OBJECT authSchemeDestinationAddr
MIN-ACCESS not-accessible
DESCRIPTION
"A compliant implementation need not allow
access to this object."
OBJECT authScheme
MIN-ACCESS read-only
DESCRIPTION
"A compliant implementation need only allow
read-only access to this object."
Kornegay & Hanson Expires May 1996 [Page 1]
draft Convention for Implementing Security Models November 1995
OBJECT authSchemeStatus
MIN-ACCESS not-accessible
DESCRIPTION
"A compliant implementation need not allow
access to this object."
::= { authServiceMIBCompliances 2 }
snmpFullCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for SNMP entities which fully
implement the objects in this MIB module as SNMP
accessible.
It is highly recommended that the least secure access
control for each security model provide read-only access to
these objects (much like the read-only access using the
community 'public' often provided for the system and snmp
groups)."
MODULE -- this module
GROUP authServiceBasicGroup
DESCRIPTION
"This group must be fully accessible using SNMP."
GROUP authServiceTableGroup
DESCRIPTION
"This group must be fully accessible using SNMP."
::= { authServiceMIBCompliances 3 }
-- units of conformance
authServiceBasicGroup OBJECT-GROUP
OBJECTS { authServiceConformance }
STATUS current
DESCRIPTION
"A collection of objects providing instrumentation of the
conformance level implemented at this SNMP entity."
::= { authServiceMIBGroups 1 }
authServiceTableGroup OBJECT-GROUP
OBJECTS { authSchemeIndex, authSchemeCommunity,
authSchemeTransportDomain, authSchemeSourceAddr,
authSchemeDestinationAddr, authScheme, authSchemeStatus }
STATUS current
DESCRIPTION
"A collection of objects providing instrumentation of the
authentication schemes implemented at this SNMP entity."
::= { authServiceMIBGroups 2 }
END
Kornegay & Hanson Expires May 1996 [Page 1]
draft Convention for Implementing Security Models November 1995
5. Examples
Various existing and anticipated implementations are discussed in these
examples to illustrate the application of the conventions presented in
this memo. See the appendices for possible scheme definitions of some
of the schemes used in these examples.
5.1 Currently Deployed Implementations
Any current implementation of SNMPv1, without any changes, can be
considered a conformant implementation of the lcdOnlyCompliance. The
trivialUnknownAccessControlScheme is most likely the implemented
authentication scheme.
Such an implementation does not support any other authentication
schemes, but is fully conformant with the conventions presented in this
memo.
5.2 Adapted Currently Deployed Implementations
Any current bi-lingual (SNMPv1 and historic SNMPv2) SNMP entity
implementing the trivialUnknownAccessControlScheme and the
historicSnmpAdministrativeModelScheme, with minor changes, can be
considered a conformant implementation of the lcdOnlyCompliance.
The definition of historicSnmpAdministrativeModelScheme specifies the
required minor changes.
Such an implementation can be considered a conformant implementation of
the snmpMinimumCompliance or snmpFullCompliance if the appropriate
objects of this MIB module are made SNMP accessible. In such a case,
the table might be populated as:
...Index ...Community ...Scheme
---------- -------------- --------------------------------------
1 'public' trivialUnknownAccessControlScheme
2 'secret' trivialUnknownAccessControlScheme
3 '' historicSnmpAdministrativeModelScheme
Notice that community public most likely provides access to limited
information and community secret provides restricted access to specific
information (both using trivial authentication). Since the entry for
row 3 contains a wild card community, and is lexically after the other
definitions, any other community will result in the use of the
historicSnmpAdministrativeModelScheme authentication scheme. (Note that
the same functionality also results if these entries were implemented
using the lcdOnlyCompliance, they just would not be SNMP accessible.)
5.3 Newly Deployed Implementations
Newly deployed implementations would be implemented in a very similar
way to what was described in section 5.2 above.
Kornegay & Hanson Expires May 1996 [Page 1]
draft Convention for Implementing Security Models November 1995
An implementation might only support a new fictional authentication
scheme, fictionalScheme. In such a case, the table might be populated
as:
...Index ...Community ...Scheme
---------- -------------- --------------------------------------
1 '' fictionalScheme
A network manager may desire to name all the communities. In such a
case, the table might be populated as:
...Index ...Community ...Scheme
---------- -------------- --------------------------------------
1 'secure' historicSnmpAdministrativeModelScheme
2 'public' trivialUnknownAccessControlScheme
3 'secret' trivialUnknownAccessControlScheme
Other similar configurations could exist.
Kornegay & Hanson Expires May 1996 [Page 1]
draft Convention for Implementing Security Models November 1995
6. Recommendations
It is recommended that individuals or groups interested in security
models for SNMP take the following steps:
- define a desired security model design as an authentication scheme
that can be integrated with the framework provided by this memo,
- assign an OBJECT IDENTIFIER that identifies that authentication
scheme, and
- publish an experimental RFC that includes the definition of the
scheme, the OBJECT IDENTIFIER that identifies the scheme, and
defines any MIB objects necessary to implement the proposed
security model design.
In the past, the SNMPv2 working group has discussed various works-in-
progress such as 'SNMPv2 Classic (The SNMP Administrative Model)',
'SNMPv2*', 'USEC', and so on that would be possible candidates for such
experimental RFCs describing those proposals as authentication schemes
under the framework proposed by this memo. Since these are high profile
and likely candidates for experimentation with SNMP security, they were
included in the definitions in section 4 of this memo.
7. Security Considerations
Security issues are not discussed in this memo.
Specific security considerations are addressed by the memos describing
each authentication scheme, implementing a security model, that may be
supported by this memo.
8. Acknowledgements
This memo is based on previous work referred to as SNMPemf that was
presented to and discussed within the SNMPv2 working group, and on
informal comments and suggestions related to that work.
The authors wish to acknowledge the excellent work done by the SNMPv1
working group, specifically their work on RFC 1157. The general
framework provided in that memo remains applicable to solving current
problems related to secure SNMP.
Kornegay & Hanson Expires May 1996 [Page 1]
draft Convention for Implementing Security Models November 1995
9. Appendices
These appendices present miscellaneous information related to the
proposal specified in this memo. The information in these appendices is
not considered a part of the proposal specified in this memo and should
not be viewed or referenced as such.
Such information is either considered as purely suggestions, or too
controversial to be included in this proposal.
9.1 Authentication Scheme Based Native Proxy
This is viewed as a controversial topic. Many would suggest that a more
sophisticated security model should implement any proxy capabilities.
The concept of the authentication service and schemes in [3],
particularly the handling of the destination transport address, could
lead to the idea that authentication schemes could implement native
proxy operations.
Suppose a message is received, an authSchemeTable entry is matched and
that entry's destination transport address is not a local transport
address, and the message is directed to a specific authentication scheme
as provided by this memo. As defined by authSchemeDestinationAddr, the
resulting behavior is implementation specific.
It would be possible to define that implementation specific behavior to
result in that authentication scheme acting in a proxy role, forwarding
the message to another SNMP entity, processing the resulting response
from that entity, and returning the appropriate response to the original
requesting SNMP entity.
9.2 Historic SNMPv2 Administrative Model Authentication Scheme
Implementation Suggestions
This appendix provides suggestions for implementing the historic SNMPv2
Administrative Model as an authentication scheme,
historicSnmpAdministrativeModelScheme, that is compliant with the
proposal in this memo. These suggestions are not intended to constrain
the proponents of the historic SNMPv2 Administrative Model, they are
just suggestions. This may appear an improper recommendation for a
historic protocol, but such implementations are currently deployed and
may be desirable until alternatives emerge.
A historic SNMPv2 Administrative Model message could place an ASN.1
value with the following syntax in the Message.data field:
Kornegay & Hanson Expires May 1996 [Page 1]
draft Convention for Implementing Security Models November 1995
SnmpPrivMsg ::= [1] IMPLICIT SEQUENCE {
privDst
OBJECT IDENTIFIER,
privData
[1] IMPLICIT OCTET STRING -- possibly encrypted SnmpAuthMsg
}
-- Where:
SnmpAuthMsg ::= [1] IMPLICIT SEQUENCE {
authInfo
ANY, -- defined by authentication protocol
authData
SnmpMgmtCom
}
-- And:
SnmpMgmtCom ::= [2] IMPLICIT SEQUENCE {
dstParty
OBJECT IDENTIFIER,
srcParty
OBJECT IDENTIFIER,
context
OBJECT IDENTIFIER,
pdu
PDUs
}
As suggested in section 6, the proponents of this suggestion need only
author an experimental RFC specifying historic SNMPv2 Administrative
Model as an authentication scheme, and define an OBJECT IDENTIFIER such
as:
historicSnmpAdministrativeModelScheme OBJECT-IDENTITY
STATUS current
DESCRIPTION
"The authentication scheme implementing a security model
known as 'The SNMP Administrative Model' [16-18], now a
historic protocol.
It is suggested that current implementations of this
security model be modified to conform with this memo, and
that their SnmpPrivMsg be contained in the 'Message.data'
field (this may appear an improper recommendation for a
historic protocol, but such implementations are currently
deployed and may be desirable until alternatives emerge)."
::= { secModelSchemes 3 }
Kornegay & Hanson Expires May 1996 [Page 1]
draft Convention for Implementing Security Models November 1995
For such an implementation, the authSchemeTable might be populated as:
...Index ...Community ...Scheme
---------- -------------- --------------------------------------
1 'public' trivialUnknownAccessControlScheme
2 'secret' trivialUnknownAccessControlScheme
3 'secure' historicSnmpAdministrativeModelScheme
9.2 SNMPv2* Authentication Scheme Implementation Suggestions
This appendix provides suggestions for implementing SNMPv2* as an
authentication scheme, snmpv2StarScheme, that is compliant with the
proposal in this memo. These suggestions are not intended to constrain
the proponents of SNMPv2*, they are just suggestions.
An SNMPv2* message could place an ASN.1 value with the following syntax
in the Message.data field:
SnmpV2StarMessageDataPayload ::= SEQUENCE {
mms
INTEGER (484..2147483647),
securityFlags
INTEGER (1..2147483647),
authMessage
SnmpV2AuthMessage
}
-- Where:
SnmpV2AuthMessage ::= [9] IMPLICIT SEQUENCE {
authInfo -- defined by an authentication and
ANY, -- privacy service definition
contextSnmpID
OCTET STRING (SIZE(12)),
contextName
OCTET STRING,
pdu
PlainOrEncryptedPDU
}
-- and:
PlainOrEncryptedPDU ::= CHOICE {
plaintext
PDUs,
encrypted
OCTET STRING
}
Kornegay & Hanson Expires May 1996 [Page 1]
draft Convention for Implementing Security Models November 1995
As suggested in section 6, the proponents of this suggestion need only
author an experimental RFC specifying SNMPv2* as an authentication
scheme, and define an OBJECT IDENTIFIER such as:
snmpv2StarScheme OBJECT-IDENTITY
STATUS current
DESCRIPTION
"The authentication scheme implementing a security model
known as 'SNMPv2*', not formally specified.
It is suggested that the proponents of this security
model formally specify it as an authentication scheme in an
experimental RFC as is suggested by this memo."
::= { secModelSchemes ? }
For such an implementation, the authSchemeTable might be populated as:
...Index ...Community ...Scheme
---------- -------------- --------------------------------------
1 'public' trivialUnknownAccessControlScheme
2 'secret' trivialUnknownAccessControlScheme
3 'secure' snmpv2StarScheme
9.3 USEC Authentication Scheme Implementation Suggestions
This appendix provides suggestions for implementing USEC as an
authentication scheme, userBasedSecurityScheme, that is compliant with
the proposal in this memo. These suggestions are not intended to
constrain the proponents of USEC, they are just suggestions.
9.3.1 Suggestion One
The proponents of USEC would most likely prefer this suggestion.
A USEC message is an ASN.1 value with the following syntax:
Message ::=
SEQUENCE {
version
INTEGER { version-2(1) },
parameters
OCTET STRING,
-- <model=0>
-- <qoS><agentID><agentBoots><agentTime>
-- <userLen><userName><authLen><authDigest>
-- <maxSize><contextSelector>
Kornegay & Hanson Expires May 1996 [Page 1]
draft Convention for Implementing Security Models November 1995
data
CHOICE {
plaintext
PDUs,
encrypted
OCTET STRING
}
}
If creative use of the wild card capability for authSchemeCommunity in
the authSchemeTable is utilized, USEC can use the community string and
the above Message format as desired by the proponents of USEC. (Note:
This does potentially limit the capabilities provided by the community
wild card in other situations.)
As suggested in section 6, the proponents of this suggestion need only
author an experimental RFC specifying USEC as an authentication scheme,
specify the limitations on the community wild card capability that would
be imposed by such an implementation, and define an OBJECT IDENTIFIER
such as:
userBasedSecurityScheme OBJECT-IDENTITY
STATUS current
DESCRIPTION
"The authentication scheme implementing a security model
known as 'User-based Security', not formally specified.
It is suggested that the proponents of this security
model formally specify it as an authentication scheme in an
experimental RFC as is suggested by this memo."
::= { secModelSchemes ? }
For such an implementation, the authSchemeTable might be populated as
(note that the community in this case must be the zero length string
''):
...Index ...Community ...Scheme
---------- -------------- --------------------------------------
1 'public' trivialUnknownAccessControlScheme
2 'secret' trivialUnknownAccessControlScheme
3 '' userBasedSecurityScheme
9.3.1 Suggestion Two
Some have suggested that USEC misuses the Message.community field.
These individuals would most likely prefer this suggestion.
An alternative USEC message could place an ASN.1 value with the
following syntax in the Message.data field:
Kornegay & Hanson Expires May 1996 [Page 1]
draft Convention for Implementing Security Models November 1995
UsecMessageDataPayload ::=
SEQUENCE {
usecParameters
OCTET STRING,
-- <model=0>
-- <qoS><agentID><agentBoots><agentTime>
-- <userLen><userName><authLen><authDigest>
-- <maxSize><contextSelector>
usecData
CHOICE {
plaintext
PDUs,
encrypted
OCTET STRING
}
}
Note: This does not limit the capabilities provided by the community
wild card in any other situations.
As suggested in section 6, the proponents of this suggestion need only
author an experimental RFC specifing USEC as an authentication scheme,
and define an OBJECT IDENTIFIER such as:
userBasedSecurityScheme OBJECT-IDENTITY
STATUS current
DESCRIPTION
"The authentication scheme implementing a security model
known as 'User-based Security', not formally specified.
It is suggested that the proponents of this security
model formally specify it as an authentication scheme in an
experimental RFC as is suggested by this memo."
::= { secModelSchemes ? }
For such an implementation, the authSchemeTable might be populated as:
...Index ...Community ...Scheme
---------- -------------- --------------------------------------
1 'public' trivialUnknownAccessControlScheme
2 'secret' trivialUnknownAccessControlScheme
3 'secure' userBasedSecurityScheme
Kornegay & Hanson Expires May 1996 [Page 1]
draft Convention for Implementing Security Models November 1995
10. References
[1] Rose, M., and McCloghrie, K., "Structure and Identification of
Management Information for TCP/IP-based internets", STD 16, RFC
1155, May 1990.
[2] Rose, M., and McCloghrie, K., "Concise MIB Definitions", STD 16,
RFC 1212, March 1991.
[3] Case, J., Fedor, M., Schoffstall, M., Davin, J., "Simple Network
Management Protocol", STD 15, RFC 1157, May 1990.
[4] McCloghrie, K., and Rose, M., "Management Information Base for
Network Management of TCP/IP-based internets: MIB II", STD ????,
RFC 1213, March 1991.
[5] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S.,
"Introduction to Version 2 of the Internet-standard Network
Management Framework", STD ????, RFC ????, November 1995.
[6] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S.,
"Coexistence between Version 1 and Version 2 of the Internet-
standard Network Management Framework", STD ????, RFC ????,
November 1995.
[7] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Structure
of Management Information for Version 2 of the Simple Network
Management Protocol (SNMPv2)", STD ????, RFC ????, November 1995.
[8] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Textual
Conventions for Version 2 of the Simple Network Management
Protocol (SNMPv2)", STD ????, RFC ????, November 1995.
[9] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S.,
"Conformance Statements for Version 2 of the Simple Network
Management Protocol (SNMPv2)", STD ????, RFC ????, November 1995.
[10] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Protocol
Operations for Version 2 of the Simple Network Management Protocol
(SNMPv2)", STD ????, RFC ????, November 1995.
[11] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Transport
Mappings for Version 2 of the Simple Network Management Protocol
(SNMPv2)", STD ????, RFC ????, November 1995.
[12] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Management
Information Base for Version 2 of the Simple Network Management
Protocol (SNMPv2)", STD ????, RFC ????, November 1995.
[13] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "SNMPv2
Management Information Base for the Internet Protocol", STD ????,
RFC ????, November 1995.
Kornegay & Hanson Expires May 1996 [Page 1]
draft Convention for Implementing Security Models November 1995
[14] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "SNMPv2
Management Information Base for the Transmission Control Protocol",
STD ????, RFC ????, November 1995.
[15] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "SNMPv2
Management Information Base for the User Datagram Protocol",
STD ????, RFC ????, November 1995.
[16] Case, J., Galvin, J., McCloghrie, K., Rose, M., and Waldbusser, S.,
"Administrative Infrastructure for Version 2 of the Simple Network
Management Protocol (SNMPv2)", RFC 1445, ???? 1994.
[17] Case, J., Galvin, J., McCloghrie, K., Rose, M., and Waldbusser, S.,
"Security Protocols for Version 2 of the Simple Network Management
Protocol (SNMPv2)", RFC 1446, ???? 1994.
[18] Case, J., Galvin, J., McCloghrie, K., Rose, M., and Waldbusser, S.,
"Party MIB for Version 2 of the Simple Network Management Protocol
(SNMPv2)", RFC 1447, ???? 1994.
11. Authors' Addresses
Michael L. Kornegay
Object Quest, Inc.
3343 Peachtree Corners Circle, Suite B
Norcross, GA 30092
US
EMail: mlk@mlksys.atl.ga.us
Iain K. Hanson
45, Ouseley Road,
Wraysbury,
Berkshire TW19 5JB.
UK.
Phone: +44 1784 482733
EMail: iain@hansons.demon.co.uk
Kornegay & Hanson Expires May 1996 [Page 1]