Network Working Group D. Harrington Internet-Draft Huawei Technologies (USA) Expires: December 10, 2006 J. Salowey Cisco Systems June 8, 2006 Secure Shell Security Model for SNMP draft-ietf-isms-secshell-03.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 December 10, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This memo describes a Security Model for the Simple Network Management Protocol, using the Secure Shell protocol within a Transport Mapping. Harrington & Salowey Expires December 10, 2006 [Page 1] Internet-Draft Secure Shell Security Model for SNMP June 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. The Internet-Standard Management Framework . . . . . . . . 4 1.2. Modularity . . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 5 1.4. Conventions . . . . . . . . . . . . . . . . . . . . . . . 6 1.5. The Secure Shell Protocol . . . . . . . . . . . . . . . . 7 1.6. Constraints . . . . . . . . . . . . . . . . . . . . . . . 7 2. How SSHSM Fits into the TMSM Architecture . . . . . . . . . . 8 2.1. Security Capabilities of this Model . . . . . . . . . . . 9 2.1.1. Threats . . . . . . . . . . . . . . . . . . . . . . . 9 2.1.2. SSHSM Sessions . . . . . . . . . . . . . . . . . . . . 11 2.1.3. Authentication Protocol . . . . . . . . . . . . . . . 11 2.1.4. Privacy Protocol . . . . . . . . . . . . . . . . . . . 12 2.1.5. Protection against Message Replay, Delay and Redirection . . . . . . . . . . . . . . . . . . . . . 12 2.1.6. Security Protocol Requirements . . . . . . . . . . . . 12 2.2. Security Parameter Passing . . . . . . . . . . . . . . . . 13 2.3. Notifications and Proxy . . . . . . . . . . . . . . . . . 14 3. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 15 3.1. SNMPv3 Message Fields . . . . . . . . . . . . . . . . . . 15 3.1.1. msgGlobalData . . . . . . . . . . . . . . . . . . . . 17 3.1.2. msgSecurityParameters . . . . . . . . . . . . . . . . 17 3.2. Passing Security Parameters . . . . . . . . . . . . . . . 17 3.2.1. tmStateReference . . . . . . . . . . . . . . . . . . . 17 3.2.2. securityStateReference . . . . . . . . . . . . . . . . 18 4. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 19 4.1. Generating an Outgoing SNMP Message . . . . . . . . . . . 19 4.2. MPSP for an Outgoing Message . . . . . . . . . . . . . . . 20 4.2.1. MPSP Procedures . . . . . . . . . . . . . . . . . . . 22 4.3. TMSP for an Outgoing Message . . . . . . . . . . . . . . . 23 4.3.1. TMSP Procedures . . . . . . . . . . . . . . . . . . . 23 4.4. Processing an Incoming SNMP Message . . . . . . . . . . . 24 4.4.1. TMSP for an Incoming Message . . . . . . . . . . . . . 24 4.5. Prepare Data Elements from Incoming Messages . . . . . . . 25 4.6. MPSP for an Incoming Message . . . . . . . . . . . . . . . 25 4.7. Establishing a Session . . . . . . . . . . . . . . . . . . 27 4.8. Closing a Session . . . . . . . . . . . . . . . . . . . . 29 5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 5.1. Structure of the MIB Module . . . . . . . . . . . . . . . 30 5.2. Textual Conventions . . . . . . . . . . . . . . . . . . . 30 5.3. The sshsmStats Subtree . . . . . . . . . . . . . . . . . . 30 5.4. The sshsmsSession Subtree . . . . . . . . . . . . . . . . 30 5.5. Relationship to Other MIB Modules . . . . . . . . . . . . 30 5.5.1. Relationship to the SNMPv2-MIB . . . . . . . . . . . . 30 5.5.2. Relationship to the SNMP-FRAMEWORK-MIB . . . . . . . . 30 5.5.3. Relationship to the TMSM-MIB . . . . . . . . . . . . . 31 Harrington & Salowey Expires December 10, 2006 [Page 2] Internet-Draft Secure Shell Security Model for SNMP June 2006 5.5.4. MIB Modules Required for IMPORTS . . . . . . . . . . . 31 6. MIB module definition . . . . . . . . . . . . . . . . . . . . 31 7. Security Considerations . . . . . . . . . . . . . . . . . . . 35 7.1. noAuthPriv . . . . . . . . . . . . . . . . . . . . . . . . 35 7.2. skipping public key verification . . . . . . . . . . . . . 36 7.3. the 'none' MAC algorithm . . . . . . . . . . . . . . . . . 36 7.4. MIB module security . . . . . . . . . . . . . . . . . . . 37 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 38 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38 10.1. Normative References . . . . . . . . . . . . . . . . . . . 38 10.2. Informative References . . . . . . . . . . . . . . . . . . 40 Appendix A. Open Issues . . . . . . . . . . . . . . . . . . . . . 40 A.1. Closed Issues . . . . . . . . . . . . . . . . . . . . . . 40 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 45 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 46 Intellectual Property and Copyright Statements . . . . . . . . . . 46 Harrington & Salowey Expires December 10, 2006 [Page 3] Internet-Draft Secure Shell Security Model for SNMP June 2006 1. Introduction This memo describes a Security Model for the Simple Network Management Protocol, using the Secure Shell protocol within a Transport Mapping Security Model extension [I-D.ietf-isms-tmsm]. The security model specified in this memo is referred to as the Secure Shell Security Model (SSHSM). 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 Secure Shell Security Model for SNMP. It is important to understand the SNMP architecture and the terminology of the architecture to understand where the Security Model described in this memo fits into the architecture and interacts with other subsystems 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. Modularity The reader is expected to have read and understood the description of the SNMP architecture, as defined in [RFC3411],and the TMSM architecture extension specified in "Transport Mapping Security Model (TMSM) Architectural Extension for the Simple Network Management Protocol" [I-D.ietf-isms-tmsm], which enables the use of external "lower layer" protocols to provide message security, tied into the SNMP architecture through the transport mapping subsystem. One such external protocol is the Secure Shell protocol [RFC4251]. This memo describes the Secure Shell Security Model for SNMP, a specific SNMP security model to be used within the SNMP Architecture, to provide authentication, encryption, and integrity checking of SNMP messages. Harrington & Salowey Expires December 10, 2006 [Page 4] Internet-Draft Secure Shell Security Model for SNMP June 2006 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 Secure Shell Security Model for SNMP. These MIB objects SHOULD not be referenced in other documents. This allows the Secure Shell Security Model for SNMP 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.3. 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. This memo describes a security model that will make use of the existing and commonly deployed Secure Shell security infrastructure. It 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. The work will address the requirement for the SSH client to authenticate the SSH server, for the SSH server to authenticate the SSH client, and how SNMP can make use of the authenticated identities in message authentication and access control. The work will include the ability to use any of the client authentication methods described in "SSH Authentication Protocol" [RFC4252] - public key, password, and host-based. Local accounts may be supported through the use of the public key, host-based or password based mechanisms. The password based mechanism allows for integration with deployed password infrastructure such as AAA servers using the RADIUS protocol [RFC2865]. SSHSM SHOULD be able to take advantage of other defined authentication mechanism such as those Harrington & Salowey Expires December 10, 2006 [Page 5] Internet-Draft Secure Shell Security Model for SNMP June 2006 defined in [RFC4462] and future mechanisms such as those that make use of X.509 certificate credentials. This will allow SSHSM to utilize client authentication and key exchange mechanisms which support different security infrastructures and provide different security properties. It is desirable to use mechanisms that could unify the approach for administrative security for SNMPv3 and Command Line interfaces (CLI) and other management interfaces. The use of security services provided by Secure Shell is the approach commonly used for the CLI, and is the approach being adopted for use with NETCONF [I-D.ietf- netconf-ssh]. This memo describes a method for invoking and running the SNMP protocol within a Secure Shell (SSH) session as an SSH subsystem. This memo describes how SNMP can be used within a Secure Shell (SSH) session, using the SSH connection protocol [RFC4254] over the SSH transport protocol, using SSH user-auth [RFC4252] for authentication. There are a number of challenges to be addressed to map Secure Shell authentication method parameters into the SNMP architecture so that SNMP continues to work without any surprises. These are discussed in detail below. 1.4. 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 Generator, Notification Responder, and Proxy Forwarder are used. See "SNMP Applications" [RFC3413] for further information. Throughout this document, the terms "client" and "server" are used to refer to the two ends of the SSH transport connection. The client actively opens the SSH connection, and the server passively listens for the incoming SSH connection. Either SNMP entity may act as client or as server, as discussed further below. While SSH and USM 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 applications; and combinations thereof. Harrington & Salowey Expires December 10, 2006 [Page 6] Internet-Draft Secure Shell Security Model for SNMP June 2006 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.5. The Secure Shell Protocol SSH is a protocol for secure remote login and other secure network services over an insecure network. It consists of three major components: o The Transport Layer Protocol [RFC4253] provides server authentication, and message confidentiality and integrity. It may optionally also provide compression. The transport layer will typically be run over a TCP/IP connection, but might also be used on top of any other reliable data stream. o The User Authentication Protocol [RFC4252] authenticates the client-side principal to the server. It runs over the transport layer protocol. o The Connection Protocol [RFC4254] multiplexes the encrypted tunnel into several logical channels. It runs over the transport after successfully authenticating the principal. The client sends a service request once a secure transport layer connection has been established. A second service request is sent after client authentication is complete. This allows new protocols to be defined and coexist with the protocols listed above. The connection protocol provides channels that can be used for a wide range of purposes. Standard methods are provided for setting up secure interactive shell sessions and for forwarding ("tunneling") arbitrary TCP/IP ports and X11 connections. 1.6. 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). Harrington & Salowey Expires December 10, 2006 [Page 7] Internet-Draft Secure Shell Security Model for SNMP June 2006 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 SSHSM Fits into the TMSM Architecture SSH is a security layer which is plugged into the TMSM architecture extension between the underlying transport layer and the message dispatcher [RFC3411]. The SSHSM model will establish an encrypted tunnel between the transport mappings of two SNMP engines. The sending transport mapping security model instance encrypts outgoing messages, and the receiving transport mapping security model instance decrypts the messages. After the transport layer tunnel is established, then SNMP messages can conceptually be sent through the tunnel from one SNMP message dispatcher to another SNMP message dispatcher. Once the tunnel is established, multiple SNMP messages may be able to be passed through the same tunnel. Within an engine, outgoing SNMP messages are passed unencrypted from the message dispatcher to the transport mapping, and incoming messages are passed unencrypted from the transport mapping to the message dispatcher. SSHSM follows the TMSM approach, in which the security-model has two separate areas of security processing - transport-mapping-related security processing (TMSP) within the transport mapping section of the dispatcher, and message processor security processing (MPSP) which happens within the security model subsystem of the message processor. SSHSM security processing will be called from within the Transport Mapping functionality of an SNMP engine dispatcher to perform the translation of transport security parameters to/from security-model- independent parameters. Some SSHSM security processing will also be performed within a message processing portion of the model, for compatibility with the ASIs between the RFC 3411 Security Subsystem and the Message Processing Subsystem. Harrington & Salowey Expires December 10, 2006 [Page 8] Internet-Draft Secure Shell Security Model for SNMP June 2006 2.1. Security Capabilities of this Model 2.1.1. Threats The security protocols used in this memo are considered acceptably secure at the time of writing. However, the procedures allow for new authentication and privacy methods to be specified at a future time if the need arises. The Secure Shell Security Model provides protection against the threats identified by the RFC 3411 architecture [RFC3411]: 1. Message stream modification - SSHSM provides for verification that each received SNMP message has not been modified during its transmission through the network. 2. Information modification - SSHSM provides for verification that the contents of each received SNMP message has not been modified during its transmission through the network, data has not been altered or destroyed in an unauthorized manner, nor have data sequences been altered to an extent greater than can occur non- maliciously. 3. Masquerade - SSHSM provides for both verification of the identity of the SSH server and verification of the identity of the SSH client - the principal on whose behalf a received SNMP message claims to have been generated. It is not possible to assure the specific principal that originated a received SNMP message; rather, it is the principal on whose behalf the message was originated that is authenticated. SSH provides verification of the identity of the SSH server through the SSH Transport Protocol server authentication [RFC4253] 4. Verification of principal identity is important for use with the SNMP access control subsystem, to ensure that only authorized principals have access to potentially sensitive data. The SSH user identity will be used to map to an SNMP model-independent securityName for use with SNMP access control. 5. Authenticating both the SSH server and the SSH client ensures the authenticity of the SNMP engine that provides MIB data, whether that engine resides on the server or client side of the association. Operators or management applications might act upon the data they receive (e.g., raise an alarm for an operator, modify the configuration of the device that sent the notification, modify the configuration of other devices in the network as the result of the notification, and so on), so it is important to know that the provider of MIB data is authentic. 6. Disclosure - SSHSM provides that the contents of each received SNMP message are protected from disclosure to unauthorized persons. Harrington & Salowey Expires December 10, 2006 [Page 9] Internet-Draft Secure Shell Security Model for SNMP June 2006 7. Replay - SSH ensures that cryptographic keys established at the beginning of the SSH session and stored in the SSH session state are fresh new session keys generated for each session. These are used to authenticate and encrypt data, and to prevent replay across sessions. SSH uses sequence information to prevent the replay and reordering of messages within a session. 2.1.1.1. Data Origin Authentication Issues 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 Secure Shell protocol provides support for encryption and data integrity. While it is technically possible to support no authentication and no encryption in SSH it is NOT RECOMMENDED by [RFC4253]. SSHSM extracts from SSH the identity of the authenticated principal, and the type and address associated with an incoming message, and SSHSM provides this information to SSH for an outgoing message. The transport layer algorithms used to provide authentication, data integrity and encryption SHOULD NOT be exposed to the SSHSM layer. In SNMPv3, we deliberately avoided this and settled for an assertion, using msgFlags, that auth and priv were applied according to the rules of the security model. However, SSHSM has no mechanisms by which it can test whether an underlying SSH connection provides auth or priv to meet a desired msgFlags setting, so the SSHSM trusts that the underlying SSH connection has been properly configured to support security characteristics at least as strong as requested in msgFlags. SSH does not understand msgFlags, and SSHSM does not know about the algorithms or options for the SSH session to open SSH sessions that match different securityLevels. For interoperability of the trust assumptions between SNMP engines, an SSHSM-compliant implementation MUST use an SSH connection that provides authentication, data integrity and encryption that meets the highest level of SNMP security (authPriv). Outgoing messages requested by SNMP applications and specified with a lesser securityLevel (noAuthNoPriv or authNoPriv) are sent by SSHSM as authPriv securityLevel. Other security models, where the actual securityLevel applied to the connection can be determined or controlled, can be used when a lesser level of security is desired. Implementations SHOULD support whatever authentications are provided by SSH. The security protocols used in [RFC4253] are considered acceptably secure at the time of writing. However, the procedures Harrington & Salowey Expires December 10, 2006 [Page 10] Internet-Draft Secure Shell Security Model for SNMP June 2006 allow for new authentication and privacy methods to be specified at a future time if the need arises. 2.1.2. SSHSM Sessions The Secure Shell security model will utilize TMSM sessions, with a single combination of transportAddress, engineID, securityName, securityModel, and securityLevel associated with each session. A TMSM session is associated with state information that is maintained for its lifetime. All SSHSM sessions will utilize the authPriv securityLevel, and all incoming SSHSM messages will be treated as having been delivered through authenticated, integrity-checked, and encrypted connections. SSHSM sessions are opened during the elements of procedure for an outgoing SNMP message, never during the elements of procedure for an incoming message. Implementations MAY choose to instantiate sessions in anticipation of outgoing messages. 2.1.2.1. Message security versus session security As part of session creation, the client and server entities are authenticated and authorized access to the session. In addition, as part of session establishment, cryptographic key material is exchanged and is then used to control access to the session on a message by message basis. Messages that fail the basic data origin authenticaiton/ data integrity checks will be rejected. 2.1.3. Authentication Protocol SSHSM should support any client authentication mechanism supported by SSH. This includes the three authentication methods described in the SSH Authentication Protocol document [RFC4252] - publickey, password, and host-based. The password authentication mechanism allows for integration with deployed password based infrastructure. It is possible to hand a password to a service such as RADIUS [RFC2865] or Diameter [RFC3588] for validation. The validation could be done using the user-name and user-password attributes. It is also possible to use a different password validation protocol such as CHAP [RFC1994] or digest authentication [RFC 2617, draft-ietf-radext-digest-auth-04] to integrate with RADIUS or Diameter. These mechanisms leave the password in the clear on the device that is authenticating the password which introduces threats to the authentication infrastructure. GSSKeyex [RFC4462] provides a framework for the addition of client Harrington & Salowey Expires December 10, 2006 [Page 11] Internet-Draft Secure Shell Security Model for SNMP June 2006 authentication mechanisms which support different security infrastructures and provide different security properties. Additional authentication mechanisms, such as one that supports X.509 certificates, may be added to SSH in the future. 2.1.4. Privacy Protocol The Secure Shell Security Model uses the SSH transport layer protocol, which provides strong encryption, server authentication, and integrity protection. 2.1.5. Protection against Message Replay, Delay and Redirection The Secure Shell Security Model uses the SSH transport layer protocol. SSH uses sequence numbers and integrity checks to protect against replay and reordering of messages within a connection. SSH also provides protection against replay of entire sessions. In a properly-implemented DH exchange, both sides will generate new random numbers for each exchange, which means the exchange hash and thus the encryption and integrity keys will be distinct for every session. This would prevent capturing an SNMP message and redirecting it to another SNMP engine. Message delay is not as important an issue with SSH as it is with USM. USM checks the timeliness of messages because it does not provide session protection or message sequence ordering. The only delay that would seem to be possible would be to delay the transmission of all packets from a particular point in a session since SSH protects the ordering of packets. 2.1.6. Security Protocol Requirements Modifying the Secure Shell protocol, or configuring it in a particular manner, may change its security characteristics in ways that would impact other existing usages. If a change is necessary, the change should be an extension that has no impact on the existing usages. This document will describe the use of an SSH subsystem for SNMP to make SNMP usage distinct from other usages. 2.1.6.1. Troubleshooting SSHSM will likely not work in conditions where access to the CLI has stopped working. In situations where SNMP access has to work when the CLI has stopped working, the use of USM should be considered instead of SSHSM. Harrington & Salowey Expires December 10, 2006 [Page 12] Internet-Draft Secure Shell Security Model for SNMP June 2006 2.1.6.2. Coexistence The Secure Shell security model can coexist with the USM security model, the only other currently defined security model. RFC3584 describes how to transfer fields between SNMPv3 and SNMPv1/ v2c messages. If necessary, the coexistence of SSHSM with v1/v2c can be described in a different document. The translation of fields from SNMPv3 messages will need detailed analysis, since SSHSM does not fill the msgSecurityParameters the same way as USM. 2.1.6.3. Mapping SSH to EngineID In the RFC3411 architecture, there are three use cases for an engineID: snmpEngineID - RFC3411 includes the SNMP-FRAMEWORK-MIB, which defines a snmpEngineID object. An snmpEngineID is the unique and unambiguous identifier of an SNMP engine. Since there is a one- to-one association between SNMP engines and SNMP entities, it also uniquely and unambiguously identifies the SNMP entity within an administrative domain. contextEngineID - Management information resides at an SNMP entity where a Command Responder Application has local access to potentially multiple contexts. A Command Responder application uses a contextEngineID equal to the snmpEngineID of its associated SNMP engine, and the contextEngineID is included in a scopedPDU to identify the engine associated with the data contained in the PDU. securityEngineID - The securityEngineID is used by USM when performing integrity checking and authentication, to look up values in the USM tables, and to synchronize "clocks". The securityEngineID is not needed by SSHSM, since integrity checking and authentication are handled outside the SNMP engine. The RFC3411 architecture defines ASIs that include a securityEngineID; SSHSM should always set the securityEngineID equal to the local value of snmpEngineID.0 to satisfy the elements of procedure for generateRequestMsg() defined in RFC3412. 2.2. Security Parameter Passing Security-model-specific parameters for an incoming message are determined from the SSH layer by the transport mapping security processor (TMSP), before the message processing begins. The TMSP accepts (decrypted) messages from the SSH subsystem, and records the transport-related information and the security-related information, including authenticated identity, in a cache referenced by tmStateReference, and passes the WholeMsg and the tmStateReference to the MPSP (via the dispatcher). Harrington & Salowey Expires December 10, 2006 [Page 13] Internet-Draft Secure Shell Security Model for SNMP June 2006 For outgoing messages, the security-model-specific parameters are gathered by the messaging-security-processor (MPSP) and passed with the outgoing message to the transport mapping. The MPSP portion of the security model creates the WholeMsg from its component parts. In the SSHSM model, an SNMPv3 message is built without any content in the SecurityParameters field of the message, and the WholeMsg is passed unencrypted back to the Message Processing Model for forwarding to the Transport Mapping. The MPSP takes input provided by the SNMP application, converts that information into suitable security parameters for SSHSM, and passes these in a cache referenced by tmStateReference to the TMSP (via the dispatcher). The TMSP establishes sessions as needed and passes messages to the SSH subsystem for processing. The cache reference is an additional parameter in the ASIs between the transport mapping and the messaging security model. This approach does create dependencies between a model-specific TMSP and a corresponding specific MPSP. 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.3. Notifications and Proxy SSH connections may be initiated by command generators or by notification originators. Command generators are frequently operated by a human, but notification originators frequently are unmanned automated processes. As a result, it usually will be necessary to provision authentication credentials on the SNMP engine containing the notification originator, or use a third party key provider such as Kerberos, so the engine can successfully authenticate to an engine containing a notification receiver. The SNMP-TARGET-MIB module [RFC3413] contains objects for defining management targets, including transport domains and addresses and security parameters, for applications such as notifications and proxy. For SSHSM, 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 preconfigure this information to identify the targets authorized to receive notifications or perform proxy. Harrington & Salowey Expires December 10, 2006 [Page 14] Internet-Draft Secure Shell Security Model for SNMP June 2006 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 MPSP. 3.1. SNMPv3 Message Fields The SNMPv3Message SEQUENCE is defined in [RFC3412] and [RFC3416]. Harrington & Salowey Expires December 10, 2006 [Page 15] Internet-Draft Secure Shell Security Model for SNMP June 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 SSHSM treats certain fields in the message: Harrington & Salowey Expires December 10, 2006 [Page 16] Internet-Draft Secure Shell Security Model for SNMP June 2006 3.1.1. msgGlobalData msgGlobalData is opaque to SSHSM. The values are set by the Message Processing model (e.g., SNMPv3 Message Processing), and are not modified by SSHSM. msgMaxSize is determined by the implementation. To avoid the need to mess with the ASN.1 encoding, msgGlobalData contains the value of msgFlags set by the Message Processing model (e.g., SNMPv3 Message Processing), not the actual (authPriv) securityLevel applied to the message by SSHSM. msgSecurityModel is set by the Message Processing model (e.g., SNMPv3) to the IANA-assigned value for the Secure Shell Security Model. See http://www.iana.org/assignments/snmp-number-spaces. 3.1.2. msgSecurityParameters Since message security is provided by a "lower layer", and the securityName parameter is always determined from the SSH 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 SSHSM its value MUST be the BER serialization of a zero-length OCTET STRING. SSHSMSecurityParametersSyntax DEFINITIONS IMPLICIT TAGS ::= BEGIN SSHsmSecurityParameters ::= SEQUENCE { OCTET STRING } END 3.2. Passing Security Parameters For SSHSM, there are two levels of state that need to be maintained: the session state, and the message state. 3.2.1. tmStateReference For each session, SSHSM stores information about the session in the Local Configuration Datastore, supplemented with a cache to store model- and mechanism-specific parameters. Harrington & Salowey Expires December 10, 2006 [Page 17] Internet-Draft Secure Shell Security Model for SNMP June 2006 Upon opening an SSH connection, the TMSP will store the transport parameters in the tmSessionTable of the TMSM-MIB [I-D.ietf-isms-tmsm] for subsequent usage. tmsmSessionID = a unique local identifier tmsmTransport = transportDomainSSH tmsmSessionAddress = a TransportAddressSSH tmsmSessionSecurityModel - SSHSM tmsmSessionSecurityLevel = "authPriv" tmsmSessionSecurityName = the principal name authenticated by SSH. How this data is extracted from the SSH environment and how it is translated into a securityName is implementation-dependent. By default, the tmSecurityName is the name that has been successfully authenticated by SSH, from the user name field of the SSH_MSG_USERAUTH_REQUEST message. tmsmSessionEngineID = if known, the value of the remote engine's snmpEngineID. How the SSH identity is extracted from the SSH layer, and how the SSH identity is mapped to a securityName for storage in tmsmSessionTable is implementation-dependent. Additional information may be stored in a local datastore (such as a preconfigured mapping table) or in a cache, such as the value of an SSH session identifier (as distinct from the tmsmSessionID). The tmStateReference is used to pass references to the appropriate session information between the TMSP and MPSP through the ASIs. The SSHSM has the responsibility for explicitly releasing the complete tmStateReference and deleting the associated tmsmSessionEntry in the tmsmSessionTable when the session is destroyed. 3.2.2. securityStateReference For each message received, SSHSM caches message-specific security information such that a Response message can be generated using the same security information, even if the Configuration Datastore is altered between the time of the incoming request and the outgoing response. The securityStateReference is used to preserve the data needed to generate a Response message with the same security information. This information includes the model-independent parameters (securityName, securityLevel, transport address, and transport type). 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 Harrington & Salowey Expires December 10, 2006 [Page 18] Internet-Draft Secure Shell Security Model for SNMP June 2006 3411 section 4.5.1." The SSH standard does not require that a session be maintained nor that it be closed when the keys associated with the host or client associated with the session are changed. Some SSH implementations might close an existing session if the keys associated with the session change. For SSHSM, if the session is closed between the time a Request is received and a Response message is being prepared, then the Response should be discarded. The parameters associated with an incoming request message to be applied to the outgoing response. messageProcessingModel = SNMPv3 securityModel = SSHSM sessionID = tmSessionID 4. Elements of Procedure Abstract service interfaces have been defined by RFC 3411 to describe the conceptual data flows between the various subsystems within an SNMP entity. The Secure Shell Security Model uses some of these conceptual data flows when communicating between subsystems, such as the dispatcher and the Message Processing Subsystem. These RFC 3411- defined data flows are referred to here as public interfaces. 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 gets discarded, the message-state information should also be released, and if state information is available when a session is closed, the session state information should also be released. 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 & Salowey Expires December 10, 2006 [Page 19] Internet-Draft Secure Shell Security Model for SNMP June 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 the MPSP processing, the SSH Security module returns statusInformation. If the process was successful, the completed message is returned, without the 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 mapping: 4.2. MPSP for an Outgoing Message This section describes the procedure followed by the Secure Shell Security Model. Harrington & Salowey Expires December 10, 2006 [Page 20] Internet-Draft Secure Shell Security Model for SNMP June 2006 The parameters needed for generating a message are supplied to the MPSP by the Message Processing Model via the generateRequestMsg() or the generateResponseMsg() ASI. The TMSM 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 & Salowey Expires December 10, 2006 [Page 21] Internet-Draft Secure Shell Security Model for SNMP June 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 SSHSM. o maxMessageSize - The maximum message size as included in the message. This data is not used by SSHSM. o transportDomain - as specified by the application. o transportAddress - as specified by the application. o securityModel - The securityModel in use. In this case, the SSH Security Model. o securityEngineID - SSHSM 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 - Ignored by SSHSM, which always uses an authPriv securityLevel. o scopedPDU - The message payload. The scopedPDU is opaque to SSHSM. 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 SSH Security module when processing the incoming Request message to which this is the Response message. o securityParameters - Always set to empty by SSHSM. 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 TMSP portion of the SSH Security Model. Note that SSHSM adds transportDomain, transportAddress, and tmStateReference have been added to these ASIs. 4.2.1. MPSP Procedures 1) verify that securityModel is sshsmSecurityModel. If not, then an error indication is returned to the calling message model, and MPSP processing stops for this message. 2) If there is a securityStateReference, then extract the tmStateReference from the cachedSecurityData. At this point, the SecurityDataCache can now be released. Harrington & Salowey Expires December 10, 2006 [Page 22] Internet-Draft Secure Shell Security Model for SNMP June 2006 2b) If the session referenced by securityStateReference does not still exist (i.e., the session used to receive the request is no longer available to send the corresponding response) then the tmsmSessionNoAvailableSessions counter is incremented, an error indication is returned to the calling module, the message is discarded, and MPSP processing stops for this message. 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 module with the statusInformation set to success. The Message Processing Model then passes information to the disptacher for forwarding to the Transport Mapping. 4.3. TMSP for an Outgoing Message The Dispatcher passes the information to the Transport Mapping using the ASI defined in the TMSM extension: statusInformation = sendMessage( IN destTransportDomain -- transport domain to be used IN destTransportAddress -- transport address to be used IN outgoingMessage -- the message to send IN outgoingMessageLength -- its length IN tmStateReference ) The TMSP portion of the SSHSM performs the following tasks: 4.3.1. TMSP Procedures 7) Lookup the session in the Local Configuration Datastore using the transportDomain, transportAddress, securityName, securityLevel, and securityModel from the tmStateReference. Extract any implementation-specific parameters from the LCD. Harrington & Salowey Expires December 10, 2006 [Page 23] Internet-Draft Secure Shell Security Model for SNMP June 2006 8) If there is no session open associated with the transportDomain, transportAddress, securityName, securityLevel, and securityModel, then call openSession(). If an error is returned from OpenSession(), then discard the message and return the error indication in the statusInformation. 9) Store any implementation-specific information in the LCD for subsequent use. 10) Pass the wholeMessage to SSH for encapsulation in an SSH_MSG_CHANNEL_DATA message. 4.4. Processing an Incoming SNMP Message 4.4.1. TMSP for an Incoming Message For an incoming message, the TMSP will need to put information from the SSH layer into a Local Configuration Datastore referenced by tmStateReference. 1) The SSHSM queries the associated SSH engine, in an implementation-dependent manner, to determine the transport and security parameters for the received message. transportDomain = transportDomainSSH transportAddress = a TransportAddressSSH tmsmSecurityModel - SSHSM tmsmSecurityLevel = "authPriv" tmsmSecurityName = the principal name authenticated by SSH. How this data is extracted from the SSH environment and how it is translated into a securityName is implementation-dependent. By default, the tmSecurityName is the name that has been successfully authenticated by SSH, from the user name field of the SSH_MSG_USERAUTH_REQUEST message. 2) If one does not exist, the TMSP creates an entry in a Local Configuration Datastore, in an implementation-dependent format, containing the information and any implementation-specific parameters desired, and creates a tmStateReference for subsequent reference to the information. Then the Transport mapping passes the message to the Dispatcher using the following primitive: statusInformation = recvMessage( OUT transportDomain -- domain for the received message OUT transportAddress -- address for the received message OUT wholeMessage -- the whole SNMP message from SSH OUT wholeMessageLength -- the length of the SNMP message OUT tmStateReference ) Harrington & Salowey Expires December 10, 2006 [Page 24] Internet-Draft Secure Shell Security Model for SNMP June 2006 4.5. 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 mapping 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 ) Note that tmStateReference has been added to this ASI. 4.6. MPSP for an Incoming Message This section describes the procedure followed by the MPSP 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:: Harrington & Salowey Expires December 10, 2006 [Page 25] Internet-Draft Secure Shell Security Model for SNMP June 2006 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 mapping 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) The securityEngineID is set to the local snmpEngineID, to satisfy the SNMPv3 message processing model in RFC 3412 section 7.2 13a). 2) Extract the value of securityName from the Local Configuration Datastore entry referenced by tmStateReference. 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 SSHSM, the securityStateReference should include a reference to the tmStateReference. 3) If the received securityParameters is not the serialization of an OCTET STRING formatted according to the SSHsmSecurityParameters, 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. 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. Harrington & Salowey Expires December 10, 2006 [Page 26] Internet-Draft Secure Shell Security Model for SNMP June 2006 4.7. Establishing a Session The Secure Shell Security Model provides the following primitive to pass data back and forth between the Transport Mapping portion of the Security Model and the SSH service: statusInformation = openSession( IN destTransportDomain -- transport domain to be used IN destTransportAddress -- transport address to be used IN maxMessageSize -- of the sending SNMP entity IN securityModel -- Security Model to use IN securityName -- on behalf of this principal IN securityLevel -- Level of Security requested OUT tmStateReference ) The following describes the procedure to follow to establish a session between a client and server to run SNMP over SSH. This process is followed by any SNMP engine establishing a session for subsequent use. This will be done automatically for an SNMP application that initiates a transaction, such as a Command Generator or a Notification Originator or a Proxy Forwarder. It is never triggered by an application preparing a response message, such as a Command Responder or Notification Receiver, because securityStateReference will always have the session information for a response message 1) Using destTransportDomain and destTransportAddress, the client will establish an SSH transport connection using the SSH transport protocol, authenticate the server, and exchange keys for message integrity and encryption. The parameters of the transport connection and the credentials used to authenticate are provided in an implementation-dependent manner. If the attempt to establish a connection is unsuccessful, or server authentication fails, then an error indication is returned, and openSession processing stops. 2) The provided transport domain, transport address, securityModel, securityName and securityLevel are used to lookup an associated entry in the Local Configuration Datastore (LCD). Any model-specific information concerning the principal at the destination is extracted. This step allows preconfiguration of model-specific principals mapped to the transport/name/level, for example, for sending notifications. Set the username in the SSH_MSG_USERAUTH_REQUEST to the username Harrington & Salowey Expires December 10, 2006 [Page 27] Internet-Draft Secure Shell Security Model for SNMP June 2006 extracted from the LCD. If information about the principal is absent from the LCD, then set the username in the SSH_MSG_USERAUTH_REQUEST to the value of securityName. This allows a deployment without preconfigured mappings between model-specific and model-independent names, but the securityName will need to contain a username recognized by the authentication mechanism. 3)The client will then invoke the "ssh-userauth" service to authenticate the user, as described in the SSH authentication protocol [RFC4252]. If the authentication is unsuccessful, then the transport connection is closed, tmStateReference is released, the message is discarded, an error indication (unknownSecurityName) is returned to the calling module, and processing stops for this message. 4) Once the principal has been successfully authenticated, the client will invoke the "ssh- connection" service, also known as the SSH connection protocol [RFC4254]. 5) After the ssh-connection service is established, the client will use an SSH_MSG_CHANNEL_OPEN message to open a channel of type "session", providing a selected sender channel number, and a maximum packet size calculated from the SNMP maxMessageSize. 6) If successful, this will result in an SSH session. The destTransportDomain and the destTransportAddress, plus the "recipient channel" and "sender channel" and other relevant data from the SSH_MSG_CHANNEL_OPEN_CONFIRMATION should be retained so they can be added to the LCD for subsequent use. 7) Once the SSH session has been established, the client will invoke SNMP as an SSH subsystem, as indicated in the "subsystem" parameter. In order to allow SNMP traffic to be easily identified and filtered by firewalls and other network devices, servers associated with SNMP entities using the Secure Shell Security Model MUST default to providing access to the "SNMP" SSH subsystem only when the SSH session is established using the IANA-assigned TCP port (TBD by IANA). Servers SHOULD be configurable to allow access to the SNMP SSH subsystem over other ports. 8) Create an entry in a Local Configuration Datastore containing the provided transportDomain, transportAddress, securityName, securityLevel, and securityModel, and SSH-speciifc parameters and create a tmStateReference to reference the entry. Harrington & Salowey Expires December 10, 2006 [Page 28] Internet-Draft Secure Shell Security Model for SNMP June 2006 9) At this point an implementation MAY perform some type of engineID discovery to determine a mapping between the remote transport address, SSH session, TMSM session, and a contextEngineID. The contextEngineID of a remote engine needs to be "discovered" for use in request messages. USM, the mandatory-to-implement security model, can perform discovery of the snmpEngineIDs of adjacent engines using Reports (see [RFC3414] section 3.2 3b). Then the discovered snmpEngineID for the remote engine can be used as the contextEngineID in requests passed using the SSH security model. 10) The Local Configuration Datastore may also record implement- specific information, such as recording the following information: the remote engine's snmpEngineID the recipient and sender channels from the SSH_MSG_CHANNEL_OPEN_CONFIRMATION message the IP address corresponding to the hostname The SSH subsystem that was opened for this session for Request/ Responses ("SNMP"), or for Notifications ("SNMPNotification"). Return the tmStateReference to the calling module. 4.8. Closing a Session The Secure Shell Security Model provides the following primitive to pass data back and forth between the Security Model and the SSH service: statusInformation = closeSession( IN tmStateReference ) The following describes the procedure to follow to close a session between a client and sever to run SNMP over SSH. This process is followed by any SNMP engine closing the corresponding SNMP session. The Secure Shell Security Model identifies which session should be closed to the SSH client code, using the closeSession() ASI. 5. Overview This MIB module provides management of the Secure Shell Security Model. It defines some needed textual conventions, and some statistics. Harrington & Salowey Expires December 10, 2006 [Page 29] Internet-Draft Secure Shell Security Model for SNMP June 2006 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 sshsmStats Subtree This subtree contains SSHSM security-model-dependent counters. This subtree provides information for identifying fault conditions and performance degradation. 5.4. The sshsmsSession Subtree This subtree contains SSHSM security-model-dependent information about sessions. 5.5. Relationship to Other MIB Modules Some management objects defined in other MIB modules are applicable to an entity implementing SSHSM. In particular, it is assumed that an entity implementing SSHSM will implement the SNMPv2-MIB [RFC3418], the SNMP-FRAMEWORK-MIB [RFC3411] and the TMSM-MIB [I-D.ietf-isms- tmsm]. This MIB module is for managing SSHSM-specific information. 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 SSHSM-MIB does not duplicate those objects. 5.5.2. Relationship to the SNMP-FRAMEWORK-MIB [todo] if the SSHSM-MIB does not actually have dependencies on SNMP- FRAMEWORK-MIB other than imports, then remove this paragraph. Harrington & Salowey Expires December 10, 2006 [Page 30] Internet-Draft Secure Shell Security Model for SNMP June 2006 5.5.3. Relationship to the TMSM-MIB The 'tmsmSession' group in the TMSM-MIB [I-D.ietf-isms-tmsm] is defined as being applicable to all Transport-Mapping Security Models that use sessions. [todo] if the SSHSM-MIB does not actually have dependencies on TMSM-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] This MIB module also references [RFC3490] 6. MIB module definition ** Is AES the only officially required to support SSH encryption ** mechanisms? It seems RFC 4344 has much more to offer. BTW, is it ** useful to export all this information in an SSHSM MIB module? Some ** of the stuff seems generic SSH... SSHSM-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 FROM SNMPv2-CONF SnmpAdminString, SnmpSecurityLevel, SnmpEngineID FROM SNMP-FRAMEWORK-MIB TransportAddress, TransportAddressType FROM TRANSPORT-ADDRESS-MIB ; sshsmMIB 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. Harrington & Salowey Expires December 10, 2006 [Page 31] Internet-Draft Secure Shell Security Model for SNMP June 2006 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 Co-editors: David Harrington Effective Software 50 Harding Rd Portsmouth, New Hampshire 03801 USA +1 603-436-8634 ietfdbh@comcast.net Joseph Salowey Cisco Systems 2901 3rd Ave Seattle, WA 98121 USA jsalowey@cisco.com " 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 -- 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 Harrington & Salowey Expires December 10, 2006 [Page 32] Internet-Draft Secure Shell Security Model for SNMP June 2006 -- remove this note -- ---------------------------------------------------------- -- -- subtrees in the SSHSM-MIB -- ---------------------------------------------------------- -- sshsmNotifications OBJECT IDENTIFIER ::= { sshsmMIB 0 } sshsmObjects OBJECT IDENTIFIER ::= { sshsmMIB 1 } sshsmConformance OBJECT IDENTIFIER ::= { sshsmMIB 2 } -- ------------------------------------------------------------- -- Objects -- ------------------------------------------------------------- TransportAddressSSH ::= TEXTUAL-CONVENTION DISPLAY-HINT "1a" STATUS current DESCRIPTION "Represents either a hostname encoded in ASCII using the IDNA protocol, as specified in RFC3490, followed by a colon ':' (ASCII character 0x3A) and a decimal port number in ASCII, or an IP address followed by a colon ':' (ASCII character 0x3A) and a decimal port number in ASCII. The name SHOULD be fully qualified whenever possible. Values of this textual convention are not directly useable as transport-layer addressing information, and require runtime resolution. As such, applications that write them must be prepared for handling errors if such values are not supported, or cannot be resolved (if resolution occurs at the time of the management operation). The DESCRIPTION clause of TransportAddress objects that may have TransportAddressSSH values must fully describe how (and when) such names are to be resolved to IP addresses and vice versa. This textual convention SHOULD NOT be used directly in object definitions since it restricts addresses to a specific format. However, if it is used, it MAY be used either on its own or in conjunction with TransportAddressType or TransportDomain as a pair. When this textual convention is used as a syntax of an index object, there may be issues with the limit of 128 sub-identifiers specified in SMIv2, STD 58. In this case, the OBJECT-TYPE declaration MUST include a 'SIZE' clause to limit the number of potential instance sub-identifiers." Harrington & Salowey Expires December 10, 2006 [Page 33] Internet-Draft Secure Shell Security Model for SNMP June 2006 SYNTAX OCTET STRING (SIZE (1..255)) transportDomainSSH OBJECT-IDENTITY STATUS current DESCRIPTION "The SSH transport domain. The corresponding transport address is of type TransportAddressSSH. When an SNMP entity uses the transportDomainSSH transport mapping, it must be capable of accepting messages up to and including 8192 octets in size. Implementation of larger values is encouraged whenever possible." ::= { snmpDomains xxxx } -- RFC Ed.: replace xxxx with IANA-assigned number and -- remove this note -- Statistics for the Secure Shell Security Model sshsmStats OBJECT IDENTIFIER ::= { sshsmObjects 1 } -- [todo] do we need any stats? -- ------------------------------------------------------------- -- sshsmMIB - Conformance Information -- ------------------------------------------------------------- sshsmGroups OBJECT IDENTIFIER ::= { sshsmConformance 1 } sshsmCompliances OBJECT IDENTIFIER ::= { sshsmConformance 2 } -- ------------------------------------------------------------- -- Units of conformance -- ------------------------------------------------------------- sshsmGroup OBJECT-GROUP OBJECTS { } STATUS current DESCRIPTION "A collection of objects for maintaining information of an SNMP engine which implements the SNMP Secure Shell Security Model. " Harrington & Salowey Expires December 10, 2006 [Page 34] Internet-Draft Secure Shell Security Model for SNMP June 2006 ::= { sshsmGroups 2 } -- ------------------------------------------------------------- -- Compliance statements -- ------------------------------------------------------------- sshsmCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP engines that support the SSHSM-MIB" MODULE MANDATORY-GROUPS { sshsmGroup } ::= { sshsmCompliances 1 } END 7. Security Considerations This document describes a security model that would permit SNMP to utilize SSH security services. The security threats and how SSHSM mitigates those threats is covered in detail throughout this memo. SSHSM relies on SSH mutual authentication, binding of keys, confidentiality and integrity. Any authentication method that meets the requirements of the SSH architecture will provide the properties of mutual authentication and binding of keys. While SSH does support turning off confidentiality and integrity, they SHOULD NOT be turned off when used with SSHSM. SSHv2 provides Perfect Forward Security (PFS) for encryption keys. PFS is a major design goal of SSH, and any well-designed keyex algorithm will provide it. The security implications of using SSH are covered in [RFC4251]. SSHSM has no way to verify that server authentication was performed, to learn the host's public key in advance, or verify that the correct key is being used. SSHSM simply trusts that these are properly cvonfigured by the implementer and deployer. 7.1. noAuthPriv SSH provides the "none" userauth method, which is normally rejected by servers and used only to find out what userauth methods are supported. However, it is legal for a server to accept this method, Harrington & Salowey Expires December 10, 2006 [Page 35] Internet-Draft Secure Shell Security Model for SNMP June 2006 which has the effect of not authenticating the ssh client to the ssh server. Doing this does not compromise authentication of the ssh server to the ssh client, nor does it compromise data confidentiality or data integrity. SSH supports anonymous access. If SSHSM can extract from SSH an authenticated principal to map to securityName, then anonymous access SHOULD be supported. It is possible for SSH to skip entity authentication of the client through the "none" authentication method to support anonymous clients, however in this case an implementation MUST still support data integrity within the SSH transport protocol and provide an authenticated principal for mapping to securityName for access control purposes. The RFC 3411 architecture does not permit noAuthPriv. SSHSM should not be used with an SSH connection with the "none" userauth method. 7.2. skipping public key verification Most key exchange algorithms are able to authenticate the SSH server's identity to the client. However, for the common case of DH signed by public keys, this requires the client to know the host's public key a priori and to verify that the correct key is being used. If this step is skipped, then authentication of the ssh server to the ssh client is not done. Data confidentiality and data integrity protection to the server still exist, but these are of dubious value when an attacker can insert himself between the client and the real ssh server. Note that some userauth methods may defend against this situation, but many of the common ones (including password and keyboard-interactive) do not, and in fact depend on the fact that the server's identity has been verified (so passwords are not disclosed to an attacker). SSH MUST NOT be configured to skip public key verification for use with the SSHSM security model. 7.3. the 'none' MAC algorithm SSH provides the "none" MAC algorithm, which would allow you to turn off data integrity while maintaining confidentiality. However, if you do this, then an attacker may be able to modify the data in flight, which means you effectively have no authentication. SSH MUST NOT be configured using the "none" MAC algorithm for use with the SSHSM security model. Harrington & Salowey Expires December 10, 2006 [Page 36] Internet-Draft Secure Shell Security Model for SNMP June 2006 7.4. 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 SSHSM cryptographic mechanisms (for authentication and privacy). 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. Harrington & Salowey Expires December 10, 2006 [Page 37] Internet-Draft Secure Shell Security Model for SNMP June 2006 8. IANA Considerations IANA is requested to assign: 1. a TCP port number in the range 1..1023 in the http://www.iana.org/assignments/port-numbers registry which will be the default port for SNMP over SSH sessions as defined in this document, 2. an SMI number under mib-2, for the MIB module in this document, 3. an SnmpSecurityModel for the Secure Shell Security Model, as documented in the MIB module in this document, 4. "snmp" as an SSH Service Name in the http://www.iana.org/assignments/ssh-parameters registry. 9. Acknowledgements The editors would like to thank Jeffrey Hutzelman for sharing his SSH insights. 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. [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [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. Harrington & Salowey Expires December 10, 2006 [Page 38] Internet-Draft Secure Shell Security Model for SNMP June 2006 [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. [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. [RFC3430] Schoenwaelder, J., "Simple Network Management Protocol Over Transmission Control Protocol Transport Mapping", RFC 3430, December 2002. [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003. [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006. [RFC4252] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Authentication Protocol", RFC 4252, January 2006. [RFC4253] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, January 2006. [RFC4254] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Connection Protocol", RFC 4254, January 2006. [I-D.ietf-isms-tmsm] Harrington, D. and J. Schoenwaelder, "Transport Mapping Security Model (TMSM) Architectural Extension for the Simple Network Management Protocol (SNMP)", Harrington & Salowey Expires December 10, 2006 [Page 39] Internet-Draft Secure Shell Security Model for SNMP June 2006 draft-ietf-isms-tmsm-02 (work in progress), May 2006. 10.2. Informative References [RFC1994] Simpson, W., "PPP Challenge Handshake Authentication Protocol (CHAP)", RFC 1994, August 1996. [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003. [RFC4462] Hutzelman, J., Salowey, J., Galbraith, J., and V. Welch, "Generic Security Service Application Program Interface (GSS-API) Authentication and Key Exchange for the Secure Shell (SSH) Protocol", RFC 4462, May 2006. [I-D.ietf-netconf-ssh] Wasserman, M. and T. Goddard, "Using the NETCONF Configuration Protocol over Secure Shell (SSH)", draft-ietf-netconf-ssh-06 (work in progress), March 2006. Appendix A. Open Issues We need to reach consensus on some issues. Here is the current list of issues from the SSHSM document where we need to reach consensus. The MIB module needs to be defined. Consistency with TMSM needs to be done (TMSM needs some changes due to changes in SSHSM) A.1. Closed Issues #1: is it important to support anonymous user access to SNMP? Resolution: We should support whatever authorizations are provided by SSH; if SSH supports anonymous access, and SSHSM can extract a username, then it should be supported. #2: a) is server authentication a requirement that SNMP will require of the client? yes. b) how can we verify that server authentication was performed, or do we take simply trust the SSH client layer to perform such authentication? we trust the SSH layer to provide such Harrington & Salowey Expires December 10, 2006 [Page 40] Internet-Draft Secure Shell Security Model for SNMP June 2006 auithentication. c) for the common case of DH signed by public keys, how does the client learn the host's public key in advance, and verify that the correct key is being used? this is out of scope for this document #3: we need some text contributed to discuss the implications of sessions on SNMP. See TMSM. #4: Should the SSHSM document include a discussion of the operational expectations of this model for use in troubleshooting a broken network, or can this be covered in the TMSM document? (Either way, we could use some contributed text on the topic). See TMSM. #5: Should the SSHSM document include a discussion of ways SNMP could be extended to better support management/monitoring needs when a network is running just fine, or can this be covered in the TMSM document, or in an applicability document? Out of scope for this document. #6: Are there are any wrinkles to coexistence with SNMPv1/v2c/USM? #7: is there still a need for an "authoritative SNMP engine"? No. #8: Do we need a mapping between the SSH key (or other SSH engine identifier) and SNMP engineID? No. What happens if an agent "spoofs" another engineID, and an NMS perfoms a SET of sensitive parameters to the agent? Resolution: we do not need to address this for local SSH and local snmpEngineID, unless smebody can show a use case requirement. There is likely to be a need to map, in an implementation-dependent manner, the remote engineIDs with the associated SSH host (mapping of engineID/transport address/host key). #9: Can an existing R/R session be reused for notifications? Yes. #10: a) which securityparameters must be supported for the SSHSM model? b) Which services provided in USM are needed in TMSM/SSHSM? C) How does the Message Processing model provide this information to the security model via generateRequestMsg() and processIncomingMsg() primitives? #11: If we eliminate all msgSecurityParameters, should the msgSecurityParameters field in the SNMPv3 message simply be a zero- length OCTET STRING, or should it be an ASN.1 NULL? It MUST be a BER-encoded OCTET STRING #12: a) how does SSHSM determine whether SSH can provide the security services requested in msgFlags? It doesn't. B) There were discussions about whether it was acceptable for a transport-mapping- Harrington & Salowey Expires December 10, 2006 [Page 41] Internet-Draft Secure Shell Security Model for SNMP June 2006 model to provide stronger security than requested. Does this need to be discussed in the SSHSM document, or should we discuss this in the TMSM document? Both. c) when sending a message into an environment where encryption is not legal, how do we ensure that encryption is not provided? The Danvers Doctrine seems to indicate this in not necessary to discuss. #13: will SSHSM be impacted by keychanges to the SSH local datastore? Resolution: if the session is closed while the Response is being prepared, discard the Response. #14: MUST the SSHSM model provide mutual authentication of the client and server, and MUST it authenticate, integrity-check, and encrypt the messages? Resolution: yes. #15: What data needs to be stored in the tmStateReference, and how does SSHSM get the information from SSH, for the various authentication and transport options? #16: The SSH server doesn't necessarily authorize the name carried in the SSH_MSG_USERAUTH_REQUEST message, but may return a different name or list of names that are authorized to be used given the authentication of the provided username. Resolution: this is mistaken; the username from the SSH_MSG_USERAUTH_REQUEST SHOULD be used. A) What should be the source of the SSHSM mechanism-specific username for mapping to securityname? Resolution: the username from the SSH_MSG_USERAUTH_REQUEST SHOULD be used. #16 B) passing a securityName might be useful for passing as a hint to RADIUS or other authorization mechanism to indicate which identity we want to use when doing access control, and RADIUS,etc. can tell us whether the username being authenticated is allowed to be mapped to that authorization/accounting identity. Should we provide securityName when establishing a session, so the authentication machanisms can use it as a hint? SSHSM provides securityName/Model/ Level and tranport; whether SSH passes this to RADIUS is out of scope for this document. #17: I believe somebody suggested we require mutual authentication. I'm not sure I understand the edits. Done. #18: I currently have multiple sections, one for each known auth mechanism. We need to discuss the parameters that need to be cached for each, and determine whether we can collapse this into one section. a) Using Passwords to Authenticate SNMP Principals B) Using Public keys to Authenticate SNMP Principals C) Using Host-based Authentication of SNMP Principals Resolution: I will collapse this later, after we have verified we have considered all current/likely Harrington & Salowey Expires December 10, 2006 [Page 42] Internet-Draft Secure Shell Security Model for SNMP June 2006 scenarios. Done. #19: RADIUS is just an instance of the password authentication protocol. The details of RADIUS are within the SSH layer. I don't think it is a good idea to expose this outside of SSH. Resolution: If possible, the details of RADIUS should not be exposed in SSHSM. There may be an issue with receiving authorization without exposing the details. #20: How do we get the mapping from model-specific identity to a model independent securityName?. Resolution: Implementation- dependent, both in the case of extracting tmSecurityname from SSH for an incoming message, and for providing an LCD mapping. #21: we need to determine what data should be persistent and stored in the LCD for notification purposes. #22: Joe: There are a significant number of security problems associated with mapping to a transport address which may need to be discussed in the security considerations section. Resolution: add a transporttype for hostname. #23: We need to discuss the circumstances under which a session should be closed, and how an SNMP engine should determine if, and respond if the SSH session is closed by other means, See TMSM, and implementation-dependent. #24: How should we enable auto-discovery? #25: Where is the best place to call openSession()? Note that the whole message is completely put together within the message- processing portion of the security model, in the hopes that a session will be able to be established when the message gets to the transport mapping portion of the architecture. It is done this way because the RFC3411 arcitecture doesn't pass the transport addressing info into the security model via messaging model. It would seem a much more efficient approach to verify that the session can be established, while still in the security model portion of the messaging model. If we don't establish the session until we get to the transport mapping, we've done a lot of work for nothing. And thus far, there is no place to record failed attempts to establish a session, so an engine doesn't learn to not try to open a session. In an environment where the SNMP engine might be a daemon used by multiple applications, an attacker could use this to cause a denial of service attack at the NMS. This would likely occur on the NMS side. I don't know if there's any way to cause it to happen on the agent side. I suppose a rogue agent with callhome functionality might be able to cause a denial of service for an NMS by repeatedly requesting callhome and Harrington & Salowey Expires December 10, 2006 [Page 43] Internet-Draft Secure Shell Security Model for SNMP June 2006 then refusing the connections. Resolution: called from TMSP. #26: According to RFC 3411, section 4.1.1, the application provides the transportDomain and transportAddress to the PDU dispatcher via the sendPDU() primitive. If we permit multiple sessions per transportAddress, then we would need to define how session identifiers get passed from the application to the PDU dispatcher (and then to the MP model).Resolution: applications do not know about sessions. #27: The SNMP over TCP Transport Mapping document [RFC3430] says that TCP connections can be recreated dynamically or kept for future use and actually leaves all that to the transport mapping. Do we need to discuss these issues? Where? in the security considerations? See TMSM. #28: For notification tables, how do we predefine the dynamic session identifiers? We might have a MIB module that records the session information for subsequent use by the applications and other subsytems, or it might be passed in the tmStateReference cache. For notifications, I assume the SNMPv3 notification tables would be a place to find the address, but I'm not sure how to identify the presumably-dynamic session identifiers. The MIB module could identify whether the session was initiated by the remote engine or initiated by the current engine, and possibly assigned a purpose (incoming request/response or outgoing notifications).. Resolution: applications do not know about sessions, only transport and securityN/M/L; if separate sessions are desired, then they can be differentiated by transport and securityN/M/L parameters. #29: do we need to support reports? For what purpose? Yes, reports are used from application processing and for contextEngine discovery. #30: If we actually do not extract anything from securityParameters, do we need to check whether this field parses correctly? It apparently parsed well enough to pass the parse test in the messaging model. Could we simply ignore the securityParameters being passed in? The only argument I see for checking to ensure this is empty is to ensure somebody isn't using the filed for non-standard purposes, such as passing a virus in the field. If we do check it, do we need to report it through Reports? Resolution: yes; it won't hurt to check it. #32: For an incoming message (Processing an Incoming Message section 10), is using a default securityName mapping the right thing to do? Resolution: Yes, it is the right thing to do. #31: Is maxSizeResponseScopedPDU relevant? Can it be calculated once Harrington & Salowey Expires December 10, 2006 [Page 44] Internet-Draft Secure Shell Security Model for SNMP June 2006 for the session? Do we need to take into consideration the SSH window size? Resolution: It can probably be calculated once per session. #33: does the mib need to be writable, so sessions can be preconfigured, such as for callhome, or would it be populated at creation time by the underlying instrumentation, and not writable by SNMP? This is about the session table, which has been moved to TMSM. [discuss] #34 - how do we determine whether a PDU contains a Request /Response or a Notification? By configuring the securityName or the transport parameters. [discuss] #35 - which subsystem is used for Reports? ** Reports are a reaction to a previously received message and thus they go wherever the previous message triggering the report came from. Appendix B. Change Log "From -02- to -03-" rewrote almost all sections merged ASI section and Elements of Procedure sections removed references to the SSH user, in preference to SSH client updated references creayted a conventions section to identify common terminology. rewrote sections on how SSH addresses threats rewrote mapping SSH to engineID eliminated discovery section detailed the Elements of Procedure eliminated secrtions on msgFlags, transport parameters resolved issues of opening notifications eliminated sessionID (TMSM needs to be updated to match) eliminated use of tmsmSessiontable except as an example updated Security Considerations "From -01- to -02-" Added TransportDomainSSH and Address Removed implementation considerations Changed all "user auth" to "client auth" Removed unnecessary MIB module objects updated references improved consistency of references to TMSM as architecural extension updated conventions Harrington & Salowey Expires December 10, 2006 [Page 45] Internet-Draft Secure Shell Security Model for SNMP June 2006 updated threats to be more consistent with RFC3552 discussion of specific SSH mechanism configurations moved to security considerations modified session discussions to reference TMSM sessions expanded discussion of engineIDs wrote text to clarify the roles of MPSP and TMSP clarified how snmpv3 message parts are ised by SSHSM modified nesting of subsections as needed securityLevel used by SSHSM always equals authpriv removed discussion of using SSHSM with SNMPv1/v2c started updating Elements of Procedure, but realized missing info needs discussion. updated MIB module relationship to other MIB modules "From -00- to -01-" -00- initial draft as ISMS work product: updated references to SecSH RFCs Modified text related to issues# 1, 2, 8, 11, 13, 14, 16, 18, 19, 20, 29, 30, and 32. updated security considerations removed Juergen Schoenwaelder from authors, at his request ran the mib module through smilint Authors' Addresses David Harrington Huawei Technologies (USA) 1700 Alma Dr. Suite 100 Plano, TX 75075 USA Phone: +1 603 436 8634 EMail: dharrington@huawei.com Joseph Salowey Cisco Systems 2901 3rd Ave Seattle, WA 98121 USA EMail: jsalowey@cisco.com Full Copyright Statement Copyright (C) The Internet Society (2006). Harrington & Salowey Expires December 10, 2006 [Page 46] Internet-Draft Secure Shell Security Model for SNMP June 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 currently provided by the Internet Society. Harrington & Salowey Expires December 10, 2006 [Page 47]