Network Working Group D. Harrington Internet-Draft Huawei Technologies (USA) Intended status: Standards Track October 11, 2006 Expires: April 14, 2007 Transport Security Model for SNMP draft-ietf-isms-transport-security-model-00.txt Status of This Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 14, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This memo describes a Transport Security Model for the Simple Network Management Protocol. Harrington Expires April 14, 2007 [Page 1] Internet-Draft Transport Security Model for SNMP October 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. The Internet-Standard Management Framework . . . . . . . . 4 1.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Modularity . . . . . . . . . . . . . . . . . . . . . . . . 5 1.4. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 5 1.5. Constraints . . . . . . . . . . . . . . . . . . . . . . . 6 2. How Transport Security Model Fits in the Architecture . . . . 6 2.1. Security Capabilities of this Model . . . . . . . . . . . 7 2.1.1. Threats . . . . . . . . . . . . . . . . . . . . . . . 7 2.1.2. Security Levels . . . . . . . . . . . . . . . . . . . 7 2.2. No Sessions . . . . . . . . . . . . . . . . . . . . . . . 7 2.3. Coexistence . . . . . . . . . . . . . . . . . . . . . . . 8 2.4. Security Parameter Passing . . . . . . . . . . . . . . . . 9 2.5. Notifications and Proxy . . . . . . . . . . . . . . . . . 9 3. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 10 3.1. SNMPv3 Message Fields . . . . . . . . . . . . . . . . . . 10 3.1.1. msgGlobalData . . . . . . . . . . . . . . . . . . . . 12 3.1.2. securityLevel and msgFlags . . . . . . . . . . . . . . 12 3.1.3. msgSecurityParameters . . . . . . . . . . . . . . . . 13 3.2. Cached Information and References . . . . . . . . . . . . 13 3.2.1. securityStateReference . . . . . . . . . . . . . . . . 14 3.2.2. tmStateReference . . . . . . . . . . . . . . . . . . . 14 4. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 15 4.1. Generating an Outgoing SNMP Message . . . . . . . . . . . 15 4.2. Security Processing for an Outgoing Message . . . . . . . 16 4.3. Processing an Incoming SNMP Message . . . . . . . . . . . 19 4.4. Prepare Data Elements from Incoming Messages . . . . . . . 19 4.5. Security Processing for an Incoming Message . . . . . . . 20 5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 5.1. Structure of the MIB Module . . . . . . . . . . . . . . . 21 5.2. Textual Conventions . . . . . . . . . . . . . . . . . . . 21 5.3. The transportStats Subtree . . . . . . . . . . . . . . . . 21 5.4. The transportState Subtree . . . . . . . . . . . . . . . . 21 5.5. Relationship to Other MIB Modules . . . . . . . . . . . . 22 5.5.1. Relationship to the SNMPv2-MIB . . . . . . . . . . . . 22 5.5.2. Relationship to the SNMP-FRAMEWORK-MIB . . . . . . . . 22 5.5.3. Relationship to the Transport-Subsystem-MIB . . . . . 22 5.5.4. MIB Modules Required for IMPORTS . . . . . . . . . . . 22 6. MIB module definition . . . . . . . . . . . . . . . . . . . . 22 7. Security Considerations . . . . . . . . . . . . . . . . . . . 27 7.1. MIB module security . . . . . . . . . . . . . . . . . . . 28 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 10.1. Normative References . . . . . . . . . . . . . . . . . . . 29 10.2. Informative References . . . . . . . . . . . . . . . . . . 30 Harrington Expires April 14, 2007 [Page 2] Internet-Draft Transport Security Model for SNMP October 2006 Appendix A. Notification Tables Configuration . . . . . . . . . . 30 A.1. Security Model Configuration . . . . . . . . . . . . . . . 32 A.2. Transport Model Configuration . . . . . . . . . . . . . . 33 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 33 Harrington Expires April 14, 2007 [Page 3] Internet-Draft Transport Security Model for SNMP October 2006 1. Introduction This memo describes a Transport Security Model for the Simple Network Management Protocol, for use with secure transport models in the Transport Subsystem [I-D.ietf-isms-tmsm]. This memo also defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular it defines objects for monitoring and managing the Transport Security Model for SNMP. It is important to understand the SNMP architecture and the terminology of the architecture to understand where the Transport Security Model described in this memo fits into the architecture and interacts with other subsystems and models within the architecture. 1.1. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 1.2. Conventions The terms "manager" and "agent" are not used in this document, because in the RFC 3411 architecture, all SNMP entities have the capability of acting as either manager or agent or both depending on the SNMP applications included in the engine. Where distinction is required, the application names of Command Generator, Command Responder, Notification Originator, Notification Receiver, and Proxy Forwarder are used. See "SNMP Applications" [RFC3413] for further information. While security protocols frequently refer to a user, the terminology used in RFC3411 [RFC3411] and in this memo is "principal". A principal is the "who" on whose behalf services are provided or processing takes place. A principal can be, among other things, an individual acting in a particular role; a set of individuals, with each acting in a particular role; an application or a set of Harrington Expires April 14, 2007 [Page 4] Internet-Draft Transport Security Model for SNMP October 2006 applications, or a combination of these within an administrative domain. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Sections requiring further editing are identified by [todo] markers in the text. Points requiring further WG research and discussion are identified by [discuss] markers in the text. 1.3. Modularity The reader is expected to have read and understood the description of the SNMP architecture, as defined in [RFC3411],and the architecture extension specified in "Transport Subsystem for the Simple Network Management Protocol" [I-D.ietf-isms-tmsm], which enables the use of external "lower layer transport" protocols to provide message security, tied into the SNMP architecture through the transport subsystem. The Transport Security Model is designed to work with such lower-layer secure transport models. In keeping with the RFC 3411 design decisions to use self-contained documents, this memo includes the elements of procedure plus associated MIB objects which are needed for processing the Transport Security Model for SNMP. These MIB objects SHOULD not be referenced in other documents. This allows the Transport Security Model to be designed and documented as independent and self- contained, having no direct impact on other modules, and allowing this module to be upgraded and supplemented as the need arises, and to move along the standards track on different time-lines from other modules. This modularity of specification is not meant to be interpreted as imposing any specific requirements on implementation. 1.4. Motivation Version 3 of the Simple Network Management Protocol (SNMPv3) added security to the previous versions of the protocol. The User Security Model (USM) [RFC3414] was designed to be independent of other existing security infrastructures, to ensure it could function when third party authentication services were not available, such as in a broken network. As a result, USM typically utilizes a separate user and key management infrastructure. Operators have reported that deploying another user and key management infrastructure in order to use SNMPv3 is a reason for not deploying SNMPv3 at this point in time. Harrington Expires April 14, 2007 [Page 5] Internet-Draft Transport Security Model for SNMP October 2006 This memo describes a security model that will make use of transport models that rely on lower layer secure transports and existing and commonly deployed security infrastructures. This security model is designed to meet the security and operational needs of network administrators, maximize usability in operational environments to achieve high deployment success and at the same time minimize implementation and deployment costs to minimize the time until deployment is possible. 1.5. Constraints The design of this SNMP Security Model is also influenced by the following constraints: 1. When the requirements of effective management in times of network stress are inconsistent with those of security, the design of this model gives preference to effective management. 2. In times of network stress, the security protocol and its underlying security mechanisms SHOULD NOT depend upon the ready availability of other network services (e.g., Network Time Protocol (NTP) or AAA protocols). 3. When the network is not under stress, the security model and its underlying security mechanisms MAY depend upon the ready availability of other network services. 4. It may not be possible for the security model to determine when the network is under stress. 5. A security model should require no changes to the SNMP architecture. 6. A security model should require no changes to the underlying security protocol. 2. How Transport Security Model Fits in the Architecture The Transport Security Model is designed to fit into the RFC3411 architecture as a security model in the security subsystem, and to utilize the services of a secure transport model. Within an engine using secure transport model, outgoing SNMP messages are passed unencrypted from the message dispatcher to the transport model, and incoming messages are passed unencrypted from the transport model to the message dispatcher. [todo] locate and eliminate discussion of "dispatcher" functionality. The transport model of an SNMP engine will perform the translation between transport-specific security parameters and SNMP-specific, model-independent parameters. Some security parameters may also be translated within a security model, for compatibility with the ASIs between the RFC 3411 Security Subsystem and the Message Processing Harrington Expires April 14, 2007 [Page 6] Internet-Draft Transport Security Model for SNMP October 2006 Subsystem. 2.1. Security Capabilities of this Model 2.1.1. Threats The Transport Security Model, when used with suitable secure transport models, provides protection against the threats identified by the RFC 3411 architecture [RFC3411]. Which threats are addressed depends on the transport model. The Transport Security Model does not address any threats itself, but delegates that responsibility to a secure transport model. The Transport Security Model is called a security model to be compatible with the RFC3411 architecure. However, this security model provides no security itself, so it SHOULD always be used with a transport model that provides appropriate security. 2.1.2. Security Levels The RFC 3411 architecture recognizes three levels of security: - without authentication and without privacy (noAuthNoPriv) - with authentication but without privacy (authNoPriv) - with authentication and with privacy (authPriv) The model-independent securityLevel parameter is used to request specific levels of security for outgoing messages, and to assert that specific levels of security were applied during the transport and processing of incoming messages. The transport layer algorithms used to provide security SHOULD NOT be exposed to the Transport Security Model, s the Transport Security Model has no mechanisms by which it can test whether an assertion made by a transport model is accurate. The Transport Security Model trusts that the underlying secure transport connection has been properly configured to support security characteristics at least as strong as requested in securityLevel. 2.2. No Sessions The Transport Security Model will associate state regarding each message and each known remote engine with a single combination of transportType, transportAddress, securityName, securityModel, and securityLevel. Some transport models will utilize sessions to maintain long-lived Harrington Expires April 14, 2007 [Page 7] Internet-Draft Transport Security Model for SNMP October 2006 state; others will use stateless transport. For reasons of module independence, the Transport Security Model will make no assumptions about there being a session of any kind. Each message may be totally independent of other messages. Any binding of multiples messages into a session is specific to the transport model. There may be circumstances where having an snmp-specific session provided by a security model is useful; such functionality is left to future security models. 2.3. Coexistence In RFC3411, there are dependencies between the message model and the security models; the security model fills in portions of the message, and thus must know the message format. When considering coexistence, one must consider coexistence with other message formats and other security models. RFC3584 describes how to transfer fields between SNMPv3 and SNMPv1/ v2c messages. The Transport Security Model usage of the msgSecurityParameters fields in SNMPv3 messages will be covered below. The coexistence of the Transport Security Model with the community- based secruity used by SNMPv1 and SNMPv2c can be described in a different document. The Transport Security Model can coexist with the USM security model, the only other currently defined security model. This can occur in multiple ways. o USM is combined with a non-secure transport model (the normal way to use USM). The SNMPv3 messaging model would pass the message to the USM security model for processing based on the securityModel expressed in msgSecurityParameters. o USM is combined with a secure transport model, which would encapsulate the whole SNMPv3 message to provide secure transport, but the global parameters specify USM as the security model, so SNMPv3 would pass the wholeMessage to the SNMPv3 messaging model. The SNMPv3 messaging model would pass the message to the USM security model for processing based on the securityModel expressed in msgSecurityParameters. o The SNMPv3 message specifies the Transport Security Model, so SNMPv3 sends the message to this security model for processing. Should secure transport models specify the securityModel as being the Transport Security Model, as well as determining the securityname and securityLevel? This has the unfortunate property of binding specific transport models to a specific security model. [discuss: this must be done by the transport model, because only Harrington Expires April 14, 2007 [Page 8] Internet-Draft Transport Security Model for SNMP October 2006 the transport model knows the message was secured at the transport level; it makes this assertion by setting securityLevel for incoming mesages, so it is possible that the transport **subsystem** could handle the choice of securityModel, if all transport models must default to an "unknown" securityLevel unless it actually does provide a known security level. Then the transport subsystem could check the securityLevel coming from the transport model, and if securityLevel is not "unknown", it could specify the transportSecurityModel. But this is a side-effect approach that could be problematic for future transport models and security models, so I prefer to not go that direction. It seems simpler to have the transport model specify it should be used with the Transport Security Model. An alternative could be to add a table in the trasnport subsystem that provided a mapping between transport model and security model, but that smacks of over- engineering ] 2.4. Security Parameter Passing For incoming messages, the transport model accepts messages from the lower layer transport, and records the transport-related information and security-related information, including the authenticated identity, in a cache referenced by tmStateReference. Then the transport model passes the WholeMsg and the tmStateReference to the security subsystem. For outgoing messages, Transport Security Model takes input provided by the SNMP application, converts that information into suitable transport and security parameters, and passes these in a cache referenced by tmStateReference to the transport subsystem. The cache reference is an additional parameter in the ASIs between the transport model and the security model. Passing a model- independent cache reference as a parameter in an ASI is consistent with the securityStateReference cache already being passed around in the ASI. 2.5. Notifications and Proxy The SNMP-TARGET-MIB module [RFC3413] contains objects for defining management targets, including transportType, transportAddress, securityName, securityModel, and securityLevel parameters, for applications such as notifications and proxy. For the Transport Security Model, transport type and address are configured in the snmpTargetAddrTable, and the securityModel, securityName, and securityLevel parameters are configured in the snmpTargetParamsTable. The default approach is for an administrator to statically Harrington Expires April 14, 2007 [Page 9] Internet-Draft Transport Security Model for SNMP October 2006 preconfigure this information to identify the targets authorized to receive notifications or perform proxy. 3. Message Formats The syntax of an SNMP message using this Security Model adheres to the message format defined in the version-specific Message Processing Model document (for example [RFC3412]). At the time of this writing, there are three defined message formats - SNMPv1, SNMPv2c, and SNMPv3. SNMPv1 and SNMPv2c have been declared Historic, so this memo only deals with SNMPv3 messages. The processing is compatible with the RFC 3412 primitives, generateRequestMsg() and processIncomingMsg(), that show the data flow between the Message Processor and the security model. 3.1. SNMPv3 Message Fields The SNMPv3Message SEQUENCE is defined in [RFC3412] and [RFC3416]. Harrington Expires April 14, 2007 [Page 10] Internet-Draft Transport Security Model for SNMP October 2006 SNMPv3MessageSyntax DEFINITIONS IMPLICIT TAGS ::= BEGIN SNMPv3Message ::= SEQUENCE { -- identify the layout of the SNMPv3Message -- this element is in same position as in SNMPv1 -- and SNMPv2c, allowing recognition -- the value 3 is used for snmpv3 msgVersion INTEGER ( 0 .. 2147483647 ), -- administrative parameters msgGlobalData HeaderData, -- security model-specific parameters -- format defined by Security Model msgSecurityParameters OCTET STRING, msgData ScopedPduData } HeaderData ::= SEQUENCE { msgID INTEGER (0..2147483647), msgMaxSize INTEGER (484..2147483647), msgFlags OCTET STRING (SIZE(1)), -- .... ...1 authFlag -- .... ..1. privFlag -- .... .1.. reportableFlag -- Please observe: -- .... ..00 is OK, means noAuthNoPriv -- .... ..01 is OK, means authNoPriv -- .... ..10 reserved, MUST NOT be used. -- .... ..11 is OK, means authPriv msgSecurityModel INTEGER (1..2147483647) } ScopedPduData ::= CHOICE { plaintext ScopedPDU, encryptedPDU OCTET STRING -- encrypted scopedPDU value } ScopedPDU ::= SEQUENCE { contextEngineID OCTET STRING, contextName OCTET STRING, data ANY -- e.g., PDUs as defined in [RFC3416] } END The following describes how Transport Security Model treats certain fields in the message: Harrington Expires April 14, 2007 [Page 11] Internet-Draft Transport Security Model for SNMP October 2006 3.1.1. msgGlobalData The msgGlobalData values are set by the Message Processing model (e.g., SNMPv3 Message Processing), and are not modified by the Transport Security Model. msgMaxSize is determined by the implementation. For outgoing messages, msgSecurityModel is set by the Message Processing model (e.g., SNMPv3) to the IANA-assigned value for the Transport Security Model. See http://www.iana.org/assignments/snmp-number-spaces. For outgoing messages, the value of msgFlags is set by the Message Processing model (e.g., SNMPv3 Message Processing), which is not necessarily the actual securityLevel applied to the message by the transport model. For incoming messages, the value of msgFlags is determined by the Message Processing model (e.g., SNMPv3 Message Processing), and the value is passed in the securityLevel parameter in the ASI between the messaging model and the security model. 3.1.2. securityLevel and msgFlags For an outgoing message, securityLevel is the requested security for the message, passed in the ASIs. If a Transport Model cannot provide the requested securityLevel, the model MUST describe a standard behavior that is followed for that situation. if the Transport Model is able to provide stronger than requested security, that may be acceptable. If the Transport Model cannot provide at least the requested level of security, the Transport Model MUST discard the request and SHOULD notify the message processing model that the request failed. The msgFlags field in the SNMPv3 message is closely related to securityLevel. msgFlags is Messaging Model dependent, while securityLevel is Messaging Model independent. To maintain the separation between subsystems, the Transport Model SHOULD NOT modify Message Model dependent fields. As a result, msgFlags in the SNMPv3 message MAY reflect the requested securityLevel, not the actual securityLevel applied to the message by the Transport Model. Part of the responsibility of a Security Model is to ensure that the actual security provided by the underlying transport layer security mechanisms is configured to meet or exceed the securityLevel requested. When the Security Model processes the incoming message, it should compare the securityLevel provided by the messaging model Harrington Expires April 14, 2007 [Page 12] Internet-Draft Transport Security Model for SNMP October 2006 to the securityLevel provided by the transport model in tmStateReference. If they differ, the Security Model should determine whether the securityLevel provided by the transport model is acceptable (e.g. the transport securityLevel is greater than or equal to the requested securityLevel. If not, it should discard the message. Depending on the model, the Security Model may issue a reportPDU with a model-specific counter. 3.1.3. msgSecurityParameters Since message security is provided by a "lower layer", and the securityName parameter is always determined by the transport model from the lower layer authentication method, the SNMP message does not need to carry message security parameters within the msgSecurityParameters field. The field msgSecurityParameters in SNMPv3 messages has a data type of OCTET STRING. To prevent its being used in a manner that could be damaging, such as for carrying a virus or worm, when used with Transport Security Model its value MUST be the BER serialization of a zero-length OCTET STRING. TransportSecurityParametersSyntax DEFINITIONS IMPLICIT TAGS ::= BEGIN TransportSecurityParameters ::= SEQUENCE { OCTET STRING } END 3.2. Cached Information and References The RFC3411 architecture uses caches to store dynamic model-specific information, and uses references in the ASIs to indicate in a model- independent manner which cached information must flow between subsystems. There are two levels of state that may need to be maintained: the security state in a request-response pair, and potentially long-term state relating to transport and security. This state is maintained in caches and a Local Configuration Datastore (LCD). To simplify the elements of procedure, the release of state information is not always explicitly specified. As a general rule, if state information is available when a message being processed gets discarded, the state related to that message should also be discarded, and if state information is available when a Harrington Expires April 14, 2007 [Page 13] Internet-Draft Transport Security Model for SNMP October 2006 relationship between engines is severed, such as the closing of a transport session, the state information for that relationship might also be discarded. This document differentiates the tmStateReference from the securityStateReference. This document does not specify an implementation strategy, only an abstract discussion of the data that must flow between subsystems. An implementation MAY use one cache and one reference to serve both functions, but an implementer must be aware of the cache-release issues to prevent the cache from being released before a security or transport model has had an opportunity to extract the information it needs. 3.2.1. securityStateReference From RFC3411: "For each message received, the Security Model caches the state information such that a Response message can be generated using the same security information, even if the Local Configuration Datastore is altered between the time of the incoming request and the outgoing response. A Message Processing Model has the responsibility for explicitly releasing the cached data if such data is no longer needed. To enable this, an abstract securityStateReference data element is passed from the Security Model to the Message Processing Model. The cached security data may be implicitly released via the generation of a response, or explicitly released by using the stateRelease primitive, as described in RFC3411 section 4.5.1." The information saved should include the model-independent parameters (transportType, transportAddress, securityName, securityModel, and securityLevel), related security parameters, and other information needed to imatch the response with the request. The Message Processing Model has the responsibility for explicitly releasing the securityStateReference when such data is no longer needed. The securityStateReference cached data may be implicitly released via the generation of a response, or explicitly released by using the stateRelease primitive, as described in RFC 3411 section 4.5.1." If the transport model connection is closed between the time a Request is received and a Response message is being prepared, then the Response message MAY be discarded. 3.2.2. tmStateReference For each message or transport session, information about the message security is stored in the Local Configuration Datastore (LCD), supplemented with a cache, to pass model- and mechanism-specific Harrington Expires April 14, 2007 [Page 14] Internet-Draft Transport Security Model for SNMP October 2006 parameters. The state referenced by tmStateReference may be saved across multiple messages, as compared to securityStateReference which is only saved for the life of a request-response pair of messages. The format of the cache and the LCD are implementation-specific. For ease of explanation, this document defines a MIB module to conceptually represent the LCD, but this is not meant to contrain implementations from doing it differently. It is expected that the LCD will allow lookup based on the combination of transportType, transportAddress, securityName, securityModel, and securityLevel. It is expected that the cache contain these values or contain pointers/references to entries in the LCD. It is expected that a transport model may store transport-specific parameters in the LCD for subsequent usage. 4. Elements of Procedure An error indication may return an OID and value for an incremented counter and a value for securityLevel, and values for contextEngineID and contextName for the counter, and the securityStateReference if the information is available at the point where the error is detected. 4.1. Generating an Outgoing SNMP Message This section describes the procedure followed by an RFC3411- compatible system whenever it generates a message containing a management operation (such as a request, a response, a notification, or a report) on behalf of a user. Harrington Expires April 14, 2007 [Page 15] Internet-Draft Transport Security Model for SNMP October 2006 statusInformation = -- success or errorIndication prepareOutgoingMessage( IN transportDomain -- transport domain to be used IN transportAddress -- transport address to be used IN messageProcessingModel -- typically, SNMP version IN securityModel -- Security Model to use IN securityName -- on behalf of this principal IN securityLevel -- Level of Security requested IN contextEngineID -- data from/at this entity IN contextName -- data from/in this context IN pduVersion -- the version of the PDU IN PDU -- SNMP Protocol Data Unit IN expectResponse -- TRUE or FALSE IN sendPduHandle -- the handle for matching incoming responses OUT destTransportDomain -- destination transport domain OUT destTransportAddress -- destination transport address OUT outgoingMessage -- the message to send OUT outgoingMessageLength -- its length ) The IN parameters of the prepareOutgoingMessage() ASI are used to pass information from the dispatcher (for the application subsystem) to the message processing subsystem. The abstract service primitive from a Message Processing Model to a security model to generate the components of a Request message is generateRequestMsg(), as described in Section 4.2. The abstract service primitive from a Message Processing Model to a Security Model to generate the components of a Response message is generateResponseMsg(), as described in Section 4.2.: Upon completion of processing, the Transport Security Model returns statusInformation. If the process was successful, the completed message is returned, without any privacy and authentication applied yet. If the process was not successful, then an errorIndication is returned. The OUT parameters are used to pass information from the message processing subsystem to the dispatcher and on to the transport subsystem: 4.2. Security Processing for an Outgoing Message This section describes the procedure followed by the Transport Security Model. Harrington Expires April 14, 2007 [Page 16] Internet-Draft Transport Security Model for SNMP October 2006 The parameters needed for generating a message are supplied to the security model by the message processing model via the generateRequestMsg() or the generateResponseMsg() ASI. The Transport Subsystem architectural extension has added the transportDomain, transportAddress, and tmStateReference parameters to the original RFC3411 ASIs. statusInformation = -- success or errorIndication generateRequestMsg( IN messageProcessingModel -- typically, SNMP version IN globalData -- message header, admin data IN maxMessageSize -- of the sending SNMP entity IN transportDomain -- as specified by application IN transportAddress -- as specified by application IN securityModel -- for the outgoing message IN securityEngineID -- authoritative SNMP entity IN securityName -- on behalf of this principal IN securityLevel -- Level of Security requested IN scopedPDU -- message (plaintext) payload OUT securityParameters -- filled in by Security Module OUT wholeMsg -- complete generated message OUT wholeMsgLength -- length of generated message OUT tmStateReference -- reference to session info ) statusInformation = -- success or errorIndication generateResponseMsg( IN messageProcessingModel -- typically, SNMP version IN globalData -- message header, admin data IN maxMessageSize -- of the sending SNMP entity IN transportDomain -- as specified by application IN transportAddress -- as specified by application IN securityModel -- for the outgoing message IN securityEngineID -- authoritative SNMP entity IN securityName -- on behalf of this principal IN securityLevel -- Level of Security requested IN scopedPDU -- message (plaintext) payload IN securityStateReference -- reference to security state -- information from original -- request OUT securityParameters -- filled in by Security Module OUT wholeMsg -- complete generated message OUT wholeMsgLength -- length of generated message OUT tmStateReference -- reference to session info ) Harrington Expires April 14, 2007 [Page 17] Internet-Draft Transport Security Model for SNMP October 2006 o statusInformation - An indication of whether the construction of the message was successful. If not it contains an indication of the problem. o messageProcessingModel - The SNMP version number for the message to be generated. o globalData - The message header (i.e., its administrative information). This data is opaque to Transport Security Model. o maxMessageSize - The maximum message size as included in the message. This data is not used by Transport Security Model. o transportDomain - as specified by the application. o transportAddress - as specified by the application. o securityEngineID - Transport Security Model always sets this to the snmpEngineID of the sending SNMP engine. o securityName - identifies a principal to be used for securing an outgoing message. The securityName has a format that is independent of the Security Model. In case of a response this parameter is ignored and the value from the securityStateReference cache is used. o securityLevel o scopedPDU - The message payload. The scopedPDU is opaque to Transport Security Model. o securityStateReference - A handle/reference to cachedSecurityData that is used when sending an outgoing Response message. This is the exact same securityStateReference as was generated by the Transport Security module when processing the incoming Request message to which this is the Response message. o securityParameters - Always set to empty by Transport Security Model. o wholeMsg - The fully encoded SNMP message ready for sending on the wire. o wholeMsgLength - The length of the encoded SNMP message (wholeMsg). o tmStateReference - a handle/reference to the session information to be passed to the transport model. Note that the Transport Subystem architectural extension adds transportDomain, transportAddress, and tmStateReference to these ASIs. 1) verify that securityModel is transportSecurityModel. If not, then an error indication is returned to the calling message model, and security model processing stops for this message. 2) If there is a securityStateReference, then this is a response to a request, so extract the cached security data. This should include transportDomain, transportAddress, securityName, securityLevel, and securityModel, and a tmStateReference. At this point, the data cache referenced by the securityStateReference can be released. Harrington Expires April 14, 2007 [Page 18] Internet-Draft Transport Security Model for SNMP October 2006 [todo: is the securityStateReference still accessible? Doesn't the MPM release the cache before calling the security model?] 3) If there is no securityStateReference, then find or create an entry in a Local Configuration Datastore containing the provided transportDomain, transportAddress, securityName, securityLevel, and securityModel, and create a tmStateReference to reference the entry. 4) fill in the securityParameters with the serialization of a zero-length OCTET STRING. 5) Combine the message parts into a wholeMsg and calculate wholeMsgLength. 6) The completed message (wholeMsg) with its length (wholeMsgLength) and securityParameters (a zero-length octet string) and tmStateReference is returned to the calling messaging model with the statusInformation set to success. 4.3. Processing an Incoming SNMP Message 4.4. Prepare Data Elements from Incoming Messages The abstract service primitive from the Dispatcher to a Message Processing Model for a received message is: result = -- SUCCESS or errorIndication prepareDataElements( IN transportDomain -- origin transport domain IN transportAddress -- origin transport address IN wholeMsg -- as received from the network IN wholeMsgLength -- as received from the network IN tmStateReference -- from the transport model OUT messageProcessingModel -- typically, SNMP version OUT securityModel -- Security Model to use OUT securityName -- on behalf of this principal OUT securityLevel -- Level of Security requested OUT contextEngineID -- data from/at this entity OUT contextName -- data from/in this context OUT pduVersion -- the version of the PDU OUT PDU -- SNMP Protocol Data Unit OUT pduType -- SNMP PDU type OUT sendPduHandle -- handle for matched request OUT maxSizeResponseScopedPDU -- maximum size sender can accept OUT statusInformation -- success or errorIndication -- error counter OID/value if error OUT stateReference -- reference to state information -- to be used for possible Response ) Harrington Expires April 14, 2007 [Page 19] Internet-Draft Transport Security Model for SNMP October 2006 Note that tmStateReference has been added to this ASI. 4.5. Security Processing for an Incoming Message This section describes the procedure followed by the Transport Security Model whenever it receives an incoming message containing a management operation on behalf of a user from a Message Processing model. The Message Processing Model extracts some information from the wholeMsg. The abstract service primitive from a Message Processing Model to the Security Subsystem for a received message is:: statusInformation = -- errorIndication or success -- error counter OID/value if error processIncomingMsg( IN messageProcessingModel -- typically, SNMP version IN maxMessageSize -- of the sending SNMP entity IN securityParameters -- for the received message IN securityModel -- for the received message IN securityLevel -- Level of Security IN wholeMsg -- as received on the wire IN wholeMsgLength -- length as received on the wire IN tmStateReference -- from the transport model OUT securityEngineID -- authoritative SNMP entity OUT securityName -- identification of the principal OUT scopedPDU, -- message (plaintext) payload OUT maxSizeResponseScopedPDU -- maximum size sender can handle OUT securityStateReference -- reference to security state ) -- information, needed for response 1) If the received securityParameters is not the serialization of an OCTET STRING formatted according to the transportSecurityParameters, and the contained OCTET STRING is not empty, then the snmpInASNParseErrs counter [RFC3418] is incremented, and an error indication (parseError) is returned to the calling module. 2) [todo: discuss how to compare the requested security parameters (extracted from msgFlags by the MPM), and the transport-model- provided actual security (reported in tmStateReference); compare securityLevel, securityModel, and securityName. While a different user-name may be used during authnentication, the tmStateReference should contain the model-independent securityName. This does imply we need to provide the securityName in the securityParameters of the SNMPv3 message, right? 2) Extract the value of securityName from the Local Configuration Datastore entry referenced by tmStateReference. Harrington Expires April 14, 2007 [Page 20] Internet-Draft Transport Security Model for SNMP October 2006 1) The securityEngineID is set to the local snmpEngineID, to satisfy the SNMPv3 message processing model in RFC 3412 section 7.2 13a). 3) The scopedPDU component is extracted from the wholeMsg. 4) The maxSizeResponseScopedPDU is calculated. This is the maximum size allowed for a scopedPDU for a possible Response message. 5)The security data is cached as cachedSecurityData, so that a possible response to this message can and will use the same security parameters. Then securityStateReference is set for subsequent reference to this cached data. For Transport Security Model, the securityStateReference should include a reference to the tmStateReference. 4) The statusInformation is set to success and a return is made to the calling module passing back the OUT parameters as specified in the processIncomingMsg primitive. 5. Overview This MIB module provides management of the Transport Security Model. It defines some needed textual conventions, and some statistics. 5.1. Structure of the MIB Module Objects in this MIB module are arranged into subtrees. Each subtree is organized as a set of related objects. The overall structure and assignment of objects to their subtrees, and the intended purpose of each subtree, is shown below. 5.2. Textual Conventions Generic and Common Textual Conventions used in this document can be found summarized at http://www.ops.ietf.org/mib-common-tcs.html 5.3. The transportStats Subtree This subtree contains counters specific to the Transport Security Model. This subtree provides information for identifying fault conditions and performance degradation. 5.4. The transportState Subtree This subtree contains information specific to state related to tmStateReference. Most of the state referenced by tmStateReference Harrington Expires April 14, 2007 [Page 21] Internet-Draft Transport Security Model for SNMP October 2006 should be transport-model-specific, and not needed here. 5.5. Relationship to Other MIB Modules Some management objects defined in other MIB modules are applicable to an entity implementing Transport Security Model. In particular, it is assumed that an entity implementing Transport Security Model will implement the SNMPv2-MIB [RFC3418], the SNMP-FRAMEWORK-MIB [RFC3411] and the Transport-Subsystem-MIB [I-D.ietf-isms-tmsm]. 5.5.1. Relationship to the SNMPv2-MIB The 'system' group in the SNMPv2-MIB [RFC3418] is defined as being mandatory for all systems, and the objects apply to the entity as a whole. The 'system' group provides identification of the management entity and certain other system-wide data. The TSM-MIB does not duplicate those objects. 5.5.2. Relationship to the SNMP-FRAMEWORK-MIB [todo] if the TSM-MIB does not actually have dependencies on SNMP- FRAMEWORK-MIB other than imports, then remove this paragraph. 5.5.3. Relationship to the Transport-Subsystem-MIB The 'tmsmSession' group in the Transport-Subsystem-MIB [I-D.ietf-isms-tmsm] is defined as being applicable to all Transport Models. [todo] if the MIB module defined here does not actually have dependencies on Transport-Subsystem-MIB other than imports, then remove this paragraph. 5.5.4. MIB Modules Required for IMPORTS The following MIB module imports items from [RFC2578], [RFC2579], [RFC2580], [RFC3411], [RFC3419], and [I-D.ietf-isms-tmsm] 6. MIB module definition TSM-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, OBJECT-IDENTITY, mib-2, Counter32, Integer32 FROM SNMPv2-SMI TestAndIncr, AutonomousType FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP Harrington Expires April 14, 2007 [Page 22] Internet-Draft Transport Security Model for SNMP October 2006 FROM SNMPv2-CONF SnmpAdminString, SnmpSecurityLevel, SnmpEngineID FROM SNMP-FRAMEWORK-MIB TransportAddress, TransportAddressType FROM TRANSPORT-ADDRESS-MIB TransportAddressSSH, transportDomainSSH FROM SSHTM-MIB ; tsmMIB MODULE-IDENTITY LAST-UPDATED "200509020000Z" ORGANIZATION "ISMS Working Group" CONTACT-INFO "WG-EMail: isms@lists.ietf.org Subscribe: isms-request@lists.ietf.org Chairs: Juergen Quittek NEC Europe Ltd. Network Laboratories Kurfuersten-Anlage 36 69115 Heidelberg Germany +49 6221 90511-15 quittek@netlab.nec.de Juergen Schoenwaelder International University Bremen Campus Ring 1 28725 Bremen Germany +49 421 200-3587 j.schoenwaelder@iu-bremen.de Editor: David Harrington Effective Software 50 Harding Rd Portsmouth, New Hampshire 03801 USA +1 603-436-8634 ietfdbh@comcast.net " DESCRIPTION "The Secure Shell Security Model MIB Copyright (C) The Internet Society (2006). This version of this MIB module is part of RFC XXXX; see the RFC itself for full legal notices. -- NOTE to RFC editor: replace XXXX with actual RFC number Harrington Expires April 14, 2007 [Page 23] Internet-Draft Transport Security Model for SNMP October 2006 -- for this document and remove this note " REVISION "200509020000Z" -- 02 September 2005 DESCRIPTION "The initial version, published in RFC XXXX. -- NOTE to RFC editor: replace XXXX with actual RFC number -- for this document and remove this note " ::= { mib-2 xxxx } -- RFC Ed.: replace xxxx with IANA-assigned number and -- remove this note -- ---------------------------------------------------------- -- -- subtrees in the TSM-MIB -- ---------------------------------------------------------- -- tsmNotifications OBJECT IDENTIFIER ::= { tsmMIB 0 } tsmMIBObjects OBJECT IDENTIFIER ::= { tsmMIB 1 } tsmConformance OBJECT IDENTIFIER ::= { tsmMIB 2 } -- ------------------------------------------------------------- -- Objects -- ------------------------------------------------------------- -- Statistics for the Transport Security Model tsmStats OBJECT IDENTIFIER ::= { tsmMIBObjects 1 } -- [todo] do we need any stats? -- The tsmUser Group ************************************************ tsmUser OBJECT IDENTIFIER ::= { tsmMIBObjects 2 } tsmUserSpinLock OBJECT-TYPE SYNTAX TestAndIncr MAX-ACCESS read-write STATUS current DESCRIPTION "An advisory lock used to allow several cooperating Command Generator Applications to coordinate their use of facilities to alter the tsmUserTable. " ::= { tsmUser 1 } -- The table of valid users for the SSH Transport Model ******** Harrington Expires April 14, 2007 [Page 24] Internet-Draft Transport Security Model for SNMP October 2006 tsmUserTable OBJECT-TYPE SYNTAX SEQUENCE OF tsmUserEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table of users configured in the SNMP engine's Local Configuration Datastore (LCD). To create a new user (i.e., to instantiate a new conceptual row in this table), it is recommended to follow this procedure: 1) GET(tsmUserSpinLock.0) and save in sValue. 2) SET(tsmUserSpinLock.0=sValue, tsmUserStatus=createAndWait) Finally, activate the new user: 3) SET(tsmUserStatus=active) The new user should now be available and ready to be used for SNMPv3 communication. The use of tsmUserSpinlock is to avoid conflicts with another SNMP command generator application which may also be acting on the tsmUserTable. " ::= { tsmUser 2 } tsmUserEntry OBJECT-TYPE SYNTAX tsmUserEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A user configured in the SNMP engine's Local Configuration Datastore (LCD) for the Session Security Model. " INDEX { tsmUserSecurityName } ::= { tsmUserTable 1 } tsmUserEntry ::= SEQUENCE { tsmUserSecurityName SnmpAdminString, tsmUserStorageType StorageType, tsmUserStatus RowStatus } tsmUserSecurityName OBJECT-TYPE Harrington Expires April 14, 2007 [Page 25] Internet-Draft Transport Security Model for SNMP October 2006 SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "A human readable string representing the user in Security Model independent format. [todo: Wehn used with transport models that perform authentication, the tsmUserSecurityName is the securityName passed in tmStateReference. " ::= { tsmUserEntry 1 } tsmUserStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this conceptual row. It is an implementation issue to decide if a SET for a readOnly or permanent row is accepted at all. In some contexts this may make sense, in others it may not. If a SET for a readOnly or permanent row is not accepted at all, then a 'wrongValue' error must be returned. " DEFVAL { nonVolatile } ::= { tsmUserEntry 4 } tsmUserStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this conceptual row. Until instances of all corresponding columns are appropriately configured, the value of the corresponding instance of the tsmUserStatus column is 'notReady'. The RowStatus TC [RFC2579] requires that this DESCRIPTION clause states under which circumstances other objects in this row can be modified: The value of this object has no effect on whether other objects in this conceptual row can be modified. " ::= { tsmUserEntry 5 } Harrington Expires April 14, 2007 [Page 26] Internet-Draft Transport Security Model for SNMP October 2006 -- ------------------------------------------------------------- -- tsmMIB - Conformance Information -- ------------------------------------------------------------- tsmGroups OBJECT IDENTIFIER ::= { tsmConformance 1 } tsmCompliances OBJECT IDENTIFIER ::= { tsmConformance 2 } -- ------------------------------------------------------------- -- Units of conformance -- ------------------------------------------------------------- tsmGroup OBJECT-GROUP OBJECTS { } STATUS current DESCRIPTION "A collection of objects for maintaining information of an SNMP engine which implements the SNMP Transport Security Model. " ::= { tsmGroups 2 } -- ------------------------------------------------------------- -- Compliance statements -- ------------------------------------------------------------- tsmCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP engines that support the TSM-MIB" MODULE MANDATORY-GROUPS { tsmGroup } ::= { tsmCompliances 1 } END 7. Security Considerations This document describes a security model that permits SNMP to utilize security services provided through an SNMP transport model. The Transport Security Model relies on transport models for mutual authentication, binding of keys, confidentiality and integrity. The security threats and how those threats are mitigated should be covered in detail in the specification of the transport model and the underlying secure transport. Harrington Expires April 14, 2007 [Page 27] Internet-Draft Transport Security Model for SNMP October 2006 Transport Security Model relies on a transport model to provide an authenticated principal for mapping to securityName, and an assertion for mapping to securityLevel, for access control purposes. The Transport Security Model is called a security model to be compatible with the RFC3411 architecure. However, this security model provides no security itself. It SHOULD always be used with a transport model that provides security, but this is a run-time decision of the operator or management application, or a configuration decision of an operator. 7.1. MIB module security There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. These are the tables and objects and their sensitivity/vulnerability: o [todo] There are no management objects defined in this MIB module that have a MAX-ACCESS clause of read-write and/or read-create. So, if this MIB module is implemented correctly, then there is no risk that an intruder can alter or create any management objects of this MIB module via direct SNMP SET operations. Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects and their sensitivity/vulnerability: o [todo] SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPSec or SSH), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410] section 8), including full support for the USM and Transport Security Model cryptographic mechanisms (for authentication and privacy). Harrington Expires April 14, 2007 [Page 28] Internet-Draft Transport Security Model for SNMP October 2006 Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 8. IANA Considerations IANA is requested to assign: 1. an SMI number under mib-2, for the MIB module in this document, 2. an SnmpSecurityModel for the Transport Security Model, as documented in the MIB module in this document, 9. Acknowledgements 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. [RFC3412] Case, J., Harrington, D., Presuhn, R., and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3412, December 2002. Harrington Expires April 14, 2007 [Page 29] Internet-Draft Transport Security Model for SNMP October 2006 [RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple Network Management Protocol (SNMP) Applications", STD 62, RFC 3413, December 2002. [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", STD 62, RFC 3414, December 2002. [RFC3416] Presuhn, R., "Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3416, December 2002. [RFC3418] Presuhn, R., "Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3418, December 2002. [RFC3419] Daniele, M. and J. Schoenwaelder, "Textual Conventions for Transport Addresses", RFC 3419, December 2002. [I-D.ietf-isms-tmsm] Harrington, D. and J. Schoenwaelder, "Transport Mapping Security Model (TMSM) Architectural Extension for the Simple Network Management Protocol (SNMP)", draft-ietf-isms-tmsm-03 (work in progress), June 2006. 10.2. Informative References [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. Appendix A. Notification Tables Configuration The SNMP-TARGET-MIB and SNMP-NOTIFICATION-MIB [RFC3413] are used to configure notification originators with the destinations to which notifications should be sent. Most of the configuration is security-model-independent and transport-model-independent. The values we will use in the examples for the five model-independent security and transport parameters are: transportType = transportDomainSSH Harrington Expires April 14, 2007 [Page 30] Internet-Draft Transport Security Model for SNMP October 2006 transportAddress = 10.0.0.1:162 securityModel = Transport Security Model securityName = sampleUser securityLevel = authPriv The following example will configure the Notification Originator to send informs to a Notification Receiver at host 10.0.0.1 port 162 using the securityName "sampleUser". The columns marked with a "*" are the items that are Security Model or Transport Model specific. The configuration for the "sampleUser" settings in the SNMP-VIEW- BASED-ACM-MIB objects are not shown here for brevity. First we configure which type of notification should be sent for this taglist (toCRTag). In this example, we choose to send an Inform. (preamble) snmpNotifyTable row: snmpNotifyName CRNotif snmpNotifyTag toCRTag snmpNotifyType inform snmpNotifyStorageType nonVolatile snmpNotifyColumnStatus createAndGo (postamble) Then we configure a transport address to which notifications associated with this taglist should be sent, and we specify which snmpTargetParamsEntry should be used (toCR) when sending to this transport address. (preamble) snmpTargetAddrTable row: snmpTargetAddrName toCRAddr * snmpTargetAddrTDomain transportDomainSSH snmpTargetAddrTAddress 10.0.0.1:162 snmpTargetAddrTimeout 1500 snmpTargetAddrRetryCount 3 snmpTargetAddrTagList toCRTag snmpTargetAddrParams toCR (must match below) snmpTargetAddrStorageType nonVolatile snmpTargetAddrColumnStatus createAndGo (postamble) Then we configure which prinicipal at the host should receive the notifications associated with this taglist. Here we choose "sampleUser", who uses the Transport Security Model. Harrington Expires April 14, 2007 [Page 31] Internet-Draft Transport Security Model for SNMP October 2006 (preamble) snmpTargetParamsTable row: snmpTargetParamsName toCR snmpTargetParamsMPModel SNMPv3 * snmpTargetParamsSecurityModel TransportSecurityModel * snmpTargetParamsSecurityName "sampleUser" snmpTargetParamsSecurityLevel authPriv snmpTargetParamsStorageType nonVolatile snmpTargetParamsRowStatus createAndGo (postamble) A.1. Security Model Configuration In the Transport Security Model MIB module (TSM-MIB), we configure the Security Model Parameters. Since we are using a Transport Security Model, we provide a pointer to the appropriate transport model entry [discuss: there are problems here. Users need additional qualification, such as address/user or engineID/user. This is transport-model specific. While we identify the securtyModel, there is no ppace that has the mapping from transport model to MIB module. A RowPointer would be more accurate, and able to support multiple multi-field indices, such as engineID/user or address/user, but it would be harder for an operator to configure. In addition, the transport model needs to be able to lookup an entry in the LCD, given the address it received a message from, and the username used to perform authentication. if that name is not the same as the securityName, then there needs to be a table to perform the username- to-securityName conversion, and another to perform securityname-to- username conversion. ] (preamble) tsmUserEntry ::= SEQUENCE { tsmUserSecurityName "sampleUser" tmsUserTransportModel transportDomainSSH tsmUserTransportParams "sshUser" tsmUserStorageType StorageType, tsmUserStatus RowStatus } An Entry from the Transport Security Model MIB module Harrington Expires April 14, 2007 [Page 32] Internet-Draft Transport Security Model for SNMP October 2006 A.2. Transport Model Configuration In the Secure Shell Transport Model MIB module (SSH-TM-MIB), we configure the transport model parameters. (preamble) sshtmUserEntry ::= SEQUENCE { sshtmUserName sshUser sshtmUserSecurityName "sampleUser" sshtmUserStorageType StorageType, sshtmUserStatus RowStatus } An entry from the SSH Transport Model MIB module Appendix B. Change Log From SSHSM-04- to Transport-security-model-00 added tsmUserTable updated Appendix - Notification Tables Configuration remove open/closed issue appendices changed tmSessionReference to tmStateReference Author's Address David Harrington Huawei Technologies (USA) 1700 Alma Dr. Suite 100 Plano, TX 75075 USA Phone: +1 603 436 8634 EMail: dharrington@huawei.com Harrington Expires April 14, 2007 [Page 33] Internet-Draft Transport Security Model for SNMP October 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Harrington Expires April 14, 2007 [Page 34]