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, -- -- -- -- 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, -- -- -- -- 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]