diff options
Diffstat (limited to 'doc/rfc/rfc5592.txt')
| -rw-r--r-- | doc/rfc/rfc5592.txt | 2019 |
1 files changed, 2019 insertions, 0 deletions
diff --git a/doc/rfc/rfc5592.txt b/doc/rfc/rfc5592.txt new file mode 100644 index 0000000..5228751 --- /dev/null +++ b/doc/rfc/rfc5592.txt @@ -0,0 +1,2019 @@ + + + + + + +Network Working Group D. Harrington +Request for Comments: 5592 Huawei Technologies (USA) +Category: Standards Track J. Salowey + Cisco Systems + W. Hardaker + Cobham Analytic Solutions + June 2009 + + + Secure Shell Transport Model for the + Simple Network Management Protocol (SNMP) + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (c) 2009 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents in effect on the date of + publication of this document (http://trustee.ietf.org/license-info). + Please review these documents carefully, as they describe your rights + and restrictions with respect to this document. + + This document may contain material from IETF Documents or IETF + Contributions published or made publicly available before November + 10, 2008. The person(s) controlling the copyright in some of this + material may not have granted the IETF Trust the right to allow + modifications of such material outside the IETF Standards Process. + Without obtaining an adequate license from the person(s) controlling + the copyright in such materials, this document may not be modified + outside the IETF Standards Process, and derivative works of it may + not be created outside the IETF Standards Process, except to format + it for publication as an RFC or to translate it into languages other + than English. + + + + + + + + + +Harrington, et al. Standards Track [Page 1] + +RFC 5592 Secure Shell Transport Model for SNMP June 2009 + + +Abstract + + This memo describes a Transport Model for the Simple Network + Management Protocol (SNMP), using the Secure Shell (SSH) protocol. + + 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 Transport Model for SNMP. + +Table of Contents + + 1. Introduction ....................................................3 + 1.1. The Internet-Standard Management Framework .................3 + 1.2. Conventions ................................................3 + 1.3. Modularity .................................................5 + 1.4. Motivation .................................................5 + 1.5. Constraints ................................................6 + 2. The Secure Shell Protocol .......................................7 + 3. How SSHTM Fits into the Transport Subsystem .....................8 + 3.1. Security Capabilities of this Model ........................8 + 3.1.1. Threats .............................................8 + 3.1.2. Message Authentication ..............................9 + 3.1.3. Authentication Protocol Support ....................10 + 3.1.4. SSH Subsystem ......................................11 + 3.2. Security Parameter Passing ................................12 + 3.3. Notifications and Proxy ...................................12 + 4. Cached Information and References ..............................13 + 4.1. Secure Shell Transport Model Cached Information ...........13 + 4.1.1. tmSecurityName .....................................13 + 4.1.2. tmSessionID ........................................14 + 4.1.3. Session State ......................................14 + 5. Elements of Procedure ..........................................14 + 5.1. Procedures for an Incoming Message ........................15 + 5.2. Procedures for Sending an Outgoing Message ................17 + 5.3. Establishing a Session ....................................18 + 5.4. Closing a Session .........................................20 + 6. MIB Module Overview ............................................21 + 6.1. Structure of the MIB Module ...............................21 + 6.2. Textual Conventions .......................................21 + 6.3. Relationship to Other MIB Modules .........................21 + 6.3.1. MIB Modules Required for IMPORTS ...................21 + 7. MIB Module Definition ..........................................22 + 8. Operational Considerations .....................................29 + 9. Security Considerations ........................................30 + 9.1. Skipping Public Key Verification ..........................31 + 9.2. Notification Authorization Considerations .................31 + 9.3. SSH User and Key Selection ................................31 + + + +Harrington, et al. Standards Track [Page 2] + +RFC 5592 Secure Shell Transport Model for SNMP June 2009 + + + 9.4. Conceptual Differences between USM and SSHTM ..............31 + 9.5. The 'none' MAC Algorithm ..................................32 + 9.6. Use with SNMPv1/v2c Messages ..............................32 + 9.7. MIB Module Security .......................................32 + 10. IANA Considerations ...........................................33 + 11. Acknowledgments ...............................................33 + 12. References ....................................................34 + 12.1. Normative References .....................................34 + 12.2. Informative References ...................................35 + +1. Introduction + + This memo describes a Transport Model for the Simple Network + Management Protocol, using the Secure Shell (SSH) protocol [RFC4251] + within a Transport Subsystem [RFC5590]. The Transport Model + specified in this memo is referred to as the Secure Shell Transport + Model (SSHTM). + + 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 Transport Model for SNMP. + + It is important to understand the SNMP architecture [RFC3411] and the + terminology of the architecture to understand where the Transport + 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. Conventions + + 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]. + + + +Harrington, et al. Standards Track [Page 3] + +RFC 5592 Secure Shell Transport Model for SNMP June 2009 + + + Lowercase versions of the keywords should be read as in normal + English. They will usually, but not always, be used in a context + that relates to compatibility with the RFC 3411 architecture or the + subsystem defined here but that might have no impact on on-the-wire + compatibility. These terms are used as guidance for designers of + proposed IETF models to make the designs compatible with RFC 3411 + subsystems and Abstract Service Interfaces (ASIs). Implementers are + free to implement differently. Some usages of these lowercase terms + are simply normal English usage. + + For consistency with SNMP-related specifications, this document + favors terminology as defined in STD 62, rather than favoring + terminology that is consistent with non-SNMP specifications. This is + consistent with the IESG decision to not require the SNMPv3 + terminology be modified to match the usage of other non-SNMP + specifications when SNMPv3 was advanced to Full Standard. + + "Authentication" in this document typically refers to the English + meaning of "serving to prove the authenticity of" the message, not + data source authentication or peer identity authentication. + + 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 manager, agent, or both depending on the SNMP + application types supported in the implementation. Where distinction + is required, the application names of command generator, command + responder, notification originator, notification receiver, and proxy + forwarder are used. See "SNMP Applications" [RFC3413] for further + information. + + The User-based Security Model (USM) [RFC3414] is a mandatory-to- + implement Security Model in STD 62. While the SSH and USM + specifications frequently refer to a user, the terminology preferred + in [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 each acting in a + particular role, an application or a set of applications, or a + combination of these within an administrative domain. + + 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. + + + + + + +Harrington, et al. Standards Track [Page 4] + +RFC 5592 Secure Shell Transport Model for SNMP June 2009 + + +1.3. Modularity + + The reader is expected to have read and understood the description of + the SNMP architecture, as defined in [RFC3411], and the Transport + Subsystem architecture extension specified in "Transport Subsystem + for the Simple Network Management Protocol (SNMP)" [RFC5590]. + + This memo describes the Secure Shell Transport Model for SNMP, a + specific SNMP Transport Model to be used within the SNMP Transport + Subsystem to provide authentication, encryption, and integrity + checking of SNMP messages. + + In keeping with the RFC 3411 design decision to use self-contained + documents, this document defines the elements of procedure and + associated MIB module objects that are needed for processing the + Secure Shell Transport Model for SNMP. + + This modularity of specification is not meant to be interpreted as + imposing any specific requirements on implementation. + +1.4. Motivation + + Version 3 of the Simple Network Management Protocol (SNMPv3) added + security to the protocol. The User-based 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 utilizes a separate user and key- + management infrastructure. Operators have reported that having to + deploy another user and key-management infrastructure in order to use + SNMPv3 is a reason for not deploying SNMPv3. + + This memo describes a Transport Model that will make use of the + existing and commonly deployed Secure Shell security infrastructure. + This Transport Model is designed to meet the security and operational + needs of network administrators, maximize usability in operational + environments to achieve high deployment success, and at the same time + minimize implementation and deployment costs to minimize deployment + time. + + This document addresses the requirement for the SSH client to + authenticate the SSH server and for the SSH server to authenticate + the SSH client, and describes how SNMP can make use of the + authenticated identities in authorization policies for data access, + in a manner that is independent of any specific Access Control Model. + + + + + + +Harrington, et al. Standards Track [Page 5] + +RFC 5592 Secure Shell Transport Model for SNMP June 2009 + + + This document addresses the requirement to utilize client- + authentication and key-exchange methods that support different + security infrastructures and provide different security properties. + This document describes how to use client authentication as described + in "The Secure Shell (SSH) Authentication Protocol" [RFC4252]. The + SSH Transport Model should work with any of the ssh-userauth methods, + including the "publickey", "password", "hostbased", "none", + "keyboard-interactive", "gssapi-with-mic", ."gssapi-keyex", "gssapi", + and "external-keyx" (see the SSH Protocol Parameters registry + maintained by IANA). The use of the "none" authentication method is + NOT RECOMMENDED, as described in this document's Security + Considerations. Local accounts may be supported through the use of + the publickey, hostbased, or password methods. The password method + allows for integration with a deployed password infrastructure, such + as Authentication, Authorization, and Accounting (AAA) servers using + the RADIUS protocol [RFC2865]. The SSH Transport Model SHOULD be + able to take advantage of future-defined ssh-userauth methods, such + as those that might make use of X.509 certificate credentials. + + 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 [RFC4742]. + 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, and using ssh-userauth [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.5. Constraints + + The design of this SNMP Transport Model is influenced by the + following constraints: + + 1. In times of network stress, the transport 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, et al. Standards Track [Page 6] + +RFC 5592 Secure Shell Transport Model for SNMP June 2009 + + + 2. When the network is not under stress, the Transport Model and its + underlying security mechanisms MAY depend upon the ready + availability of other network services. + + 3. It may not be possible for the Transport Model to determine when + the network is under stress. + + 4. A Transport Model SHOULD NOT require changes to the SNMP + architecture. + + 5. A Transport Model SHOULD NOT require changes to the underlying + security protocol. + +2. 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 + protocol components and add-on methods for user authentication: + + 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. + + o Generic Message Exchange Authentication [RFC4256] is a general + purpose authentication method for the SSH protocol, suitable for + interactive authentications where the authentication data should + be entered via a keyboard. + + o "Generic Security Service Application Program Interface (GSS-API) + Authentication and Key Exchange for the Secure Shell (SSH) + Protocol" [RFC4462] describes methods for using the GSS-API for + authentication and key exchange in SSH. It defines an SSH user- + authentication method that uses a specified GSS-API mechanism to + authenticate a user; it also defines a family of SSH key-exchange + methods that use GSS-API to authenticate a Diffie-Hellman key + exchange. + + + + + +Harrington, et al. Standards Track [Page 7] + +RFC 5592 Secure Shell Transport Model for SNMP June 2009 + + + 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. + +3. How SSHTM Fits into the Transport Subsystem + + A Transport Model is a component of the Transport Subsystem [RFC5590] + within the SNMP architecture. The SSH Transport Model thus fits + between the underlying SSH transport layer and the Message Dispatcher + [RFC3411]. + + The SSH Transport Model will establish a channel between itself and + the SSH Transport Model of another SNMP engine. The sending + Transport Model passes unencrypted messages from the Dispatcher to + SSH to be encrypted, and the receiving Transport Model accepts + decrypted incoming messages from SSH and passes them to the + Dispatcher. + + After an SSH Transport Model channel is established, then SNMP + messages can conceptually be sent through the channel from one SNMP + Message Dispatcher to another SNMP Message Dispatcher. Multiple SNMP + messages MAY be passed through the same channel. + + The SSH Transport Model of an SNMP engine will perform the + translation between SSH-specific security parameters and SNMP- + specific, model-independent parameters. + +3.1. Security Capabilities of this Model + +3.1.1. Threats + + The Secure Shell Transport Model provides protection against the + threats identified by the RFC 3411 architecture [RFC3411]: + + 1. Modification of Information - SSH provides for verification that + the contents of each message have not been modified during its + transmission through the network by digitally signing each SSH + packet. + + 2. Masquerade - SSH provides for verification of the identity of the + SSH server and the identity of the SSH client. + + + + +Harrington, et al. Standards Track [Page 8] + +RFC 5592 Secure Shell Transport Model for SNMP June 2009 + + + SSH provides for verification of the identity of the SSH server + through the SSH transport protocol server authentication + [RFC4253]. This allows an operator or management station to + ensure the authenticity of the SNMP engine that provides MIB + data. + + SSH provides a number of mechanisms for verification of the + identity of the SSH client-side principal using the Secure Shell + Authentication Protocol [RFC4252]. These include public key, + password, and host-based mechanisms. This allows the SNMP Access + Control Subsystem to ensure that only authorized principals have + access to potentially sensitive data. + + Verification of the client's 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 is provided to the Transport Model, so it + can be used to map to an SNMP model-independent securityName for + use with SNMP access control and notification configuration. + (The identity may undergo various transforms before it maps to + the securityName.) + + 3. Message Stream Modification - SSH protects against malicious re- + ordering or replaying of messages within a single SSH session by + using sequence numbers and integrity checks. SSH protects + against replay of messages across SSH sessions by ensuring that + the cryptographic keys used for encryption and integrity checks + are generated afresh for each session. + + 4. Disclosure - SSH provides protection against the disclosure of + information to unauthorized recipients or eavesdroppers by + allowing for encryption of all traffic between SNMP engines. + +3.1.2. Message Authentication + + 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]. + + + +Harrington, et al. Standards Track [Page 9] + +RFC 5592 Secure Shell Transport Model for SNMP June 2009 + + + The SSH Transport Model determines from SSH the identity of the + authenticated principal and the type and address associated with an + incoming message, and provides this information to SSH for an + outgoing message. The SSH transport-layer algorithms used to provide + authentication, data integrity, and encryption SHOULD NOT be exposed + to the SSH Transport Model layer. The SNMPv3 WG deliberately avoided + this and settled for an assertion by the Security Model that the + requirements of securityLevel were met. The SSH Transport Model has + no mechanisms by which it can test whether an underlying SSH + connection provides auth or priv, so the SSH Transport Model trusts + that the underlying SSH connection has been properly configured to + support authPriv security characteristics. + + An SSH Transport-Model-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 specified with a securityLevel of noAuthNoPriv or + authNoPriv are actually sent by the SSH Transport Model with + authPriv-level protection. + + The security protocols used in the Secure Shell Authentication + Protocol [RFC4252] and the Secure Shell Transport Layer Protocol + [RFC4253] 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. + +3.1.3. Authentication Protocol Support + + The SSH Transport Model should support any server- or 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), keyboard + interactive, and others. + + 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 the Challenge Handshake + Authentication Protocol (CHAP) [RFC1994] or digest authentication + [RFC5090] to integrate with RADIUS or Diameter. At some point in the + processing, these mechanisms require the password to be made + available as cleartext on the device that is authenticating the + password, which might introduce threats to the authentication + infrastructure. + + + + + +Harrington, et al. Standards Track [Page 10] + +RFC 5592 Secure Shell Transport Model for SNMP June 2009 + + + GSS-API key exchange [RFC4462] provides a framework for the addition + of client-authentication mechanisms that 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. + +3.1.4. SSH Subsystem + + This document describes the use of an SSH Subsystem for SNMP to make + SNMP usage distinct from other usages. + + An SSH Subsystem of type "snmp" is opened by the SSH Transport Model + during the elements of procedure for an outgoing SNMP message. Since + the sender of a message initiates the creation of an SSH session if + needed, the SSH session will already exist for an incoming message; + otherwise, the incoming message would never reach the SSH Transport + Model. + + Implementations may choose to instantiate SSH sessions in + anticipation of outgoing messages. This approach might be useful to + ensure that an SSH session to a given target can be established + before it becomes important to send a message over the SSH session. + Of course, there is no guarantee that a pre-established session will + still be valid when needed. + + SSH sessions are uniquely identified within the SSH Transport Model + by the combination of tmTransportAddress and tmSecurityName + associated with each session. + + Because naming policies might differ between administrative domains, + many SSH client software packages support a user@hostname:port + addressing syntax that operators can use to align non-equivalent + account names. The SnmpSSHAddress Textual Convention echos this + common SSH notation. + + When this notation is used in an SnmpSSHAddress, the SSH connection + should be established with an SSH user name matching the "user" + portion of the notation when establishing a session with the remote + SSH server. The user name must be encoded in UTF-8 (per [RFC4252]). + The "user" portion may or may not match the tmSecurityName parameter + passed from the Security Model. If no "user@" portion is specified + in the SnmpSSHAddress, then the SSH connection should be established + using the tmSecurityName as the SSH user name when establishing a + session with the remote SSH server. + + + + + + + +Harrington, et al. Standards Track [Page 11] + +RFC 5592 Secure Shell Transport Model for SNMP June 2009 + + + The SnmpSSHAddress and tmSecurityName associated with an SSH session + MUST remain constant during the life of the session. Different + SnmpSSHAddress values (with different hostnames, "user@" prefix + names, and/or port numbers) will each result in individual SSH + sessions. + +3.2. Security Parameter Passing + + For incoming messages, SSH-specific security parameters are + translated by the Transport Model into security parameters + independent of the Transport and Security Models. The Transport + Model accepts messages from the SSH Subsystem, records the transport- + related and SSH-security-related information, including the + authenticated identity, in a cache referenced by tmStateReference, + and passes the WholeMsg and the tmStateReference to the Dispatcher + using the receiveMessage() ASI (Abstract Service Interface). + + For outgoing messages, the Transport Model takes input provided by + the Dispatcher in the sendMessage() ASI. The SSH Transport Model + converts that information into suitable security parameters for SSH, + establishes sessions as needed, and passes messages to the SSH + Subsystem for sending. + +3.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 are usually unmanned + automated processes. As a result, it may be necessary to provision + authentication credentials on the SNMP engine containing the + notification originator or to use a third-party key provider, such as + Kerberos, so the engine can successfully authenticate to an engine + containing a notification receiver. + + The targets to whom notifications or proxy requests should be sent is + typically determined and configured by a network administrator. The + SNMP-NOTIFICATION-MIB contains a list of targets to which + notifications should be sent. The SNMP-TARGET-MIB module [RFC3413] + contains objects for defining these management targets, including + transport domains and addresses and security parameters, for + applications such as notification generators and proxy forwarders. + + For the SSH Transport Model, transport type and address are + configured in the snmpTargetAddrTable, and the 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 received proxied messages. Local access- + + + +Harrington, et al. Standards Track [Page 12] + +RFC 5592 Secure Shell Transport Model for SNMP June 2009 + + + control processing needs to be performed by a notification originator + before notifications are actually sent, and this processing is done + using the configured securityName. An important characteristic of + this is that authorization is done prior to determining if the + connection can succeed. Thus, the locally configured securityName is + entirely trusted within the notification originator. + + The SNMP-TARGET-MIB and NOTIFICATION-MIB MIB modules may be + configured using SNMP or other implementation-dependent mechanisms, + such as CLI scripting or loading a configuration file. It may be + necessary to provide additional implementation-specific configuration + of SSH parameters. + +4. Cached Information and References + + When performing SNMP processing, there are two levels of state + information that may need to be retained: the immediate state linking + a request-response pair and a potentially longer-term state relating + to transport and security. "Transport Subsystem for the Simple + Network Management Protocol" [RFC5590] defines general requirements + for caches and references. + + This document defines additional cache requirements related to the + Secure Shell Transport Model. + +4.1. Secure Shell Transport Model Cached Information + + The Secure Shell Transport Model has specific responsibilities + regarding the cached information. See the Elements of Procedure in + Section 5 for detailed processing instructions on the use of the + tmStateReference fields by the SSH Transport Model. + +4.1.1. tmSecurityName + + The tmSecurityName MUST be a human-readable name (in snmpAdminString + format) representing the identity that has been set according to the + procedures in Section 5. The tmSecurityName MUST be constant for all + traffic passing through an SSHTM session. Messages MUST NOT be sent + through an existing SSH session that was established using a + different tmSecurityName. + + On the SSH server side of a connection: + + The tmSecurityName should be the SSH user name. How the SSH user + name is extracted from the SSH layer is implementation-dependent. + + + + + + +Harrington, et al. Standards Track [Page 13] + +RFC 5592 Secure Shell Transport Model for SNMP June 2009 + + + The SSH protocol is not always clear on whether the user name + field must be filled in, so for some implementations, such as + those using GSSAPI authentication, it may be necessary to use a + mapping algorithm to transform an SSH identity to a tmSecurityName + or to transform a tmSecurityName to an SSH identity. + + In other cases, the user name may not be verified by the server, + so for these implementations, it may be necessary to obtain the + user name from other credentials exchanged during the SSH + exchange. + + On the SSH client side of a connection: + + The tmSecurityName is presented to the SSH Transport Model by the + application (possibly because of configuration specified in the + SNMP-TARGET-MIB). + + The securityName MAY be derived from the tmSecurityName by a Security + Model and MAY be used to configure notifications and access controls + in MIB modules. Transport Models SHOULD generate a predictable + tmSecurityName so operators will know what to use when configuring + MIB modules that use securityNames derived from tmSecurityNames. + +4.1.2. tmSessionID + + The tmSessionID MUST be recorded per message at the time of receipt. + When tmSameSecurity is set, the recorded tmSessionID can be used to + determine whether the SSH session available for sending a + corresponding outgoing message is the same SSH session as was used + when receiving the incoming message (e.g., a response to a request). + +4.1.3. Session State + + The per-session state that is referenced by tmStateReference may be + saved across multiple messages in a Local Configuration Datastore. + Additional session/connection state information might also be stored + in a Local Configuration Datastore. + +5. Elements of Procedure + + Abstract Service Interfaces have been defined by [RFC3411] and + further augmented by [RFC5590] to describe the conceptual data flows + between the various subsystems within an SNMP entity. The Secure + Shell Transport Model uses some of these conceptual data flows when + communicating between subsystems. + + + + + + +Harrington, et al. Standards Track [Page 14] + +RFC 5592 Secure Shell Transport Model for SNMP June 2009 + + + 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 in statusInformation will typically include the + Object Identifier (OID) and value for an incremented error counter. + This may be accompanied by the requested securityLevel and the + tmStateReference. Per-message context information is not accessible + to Transport Models, so for the returned counter OID and value, + contextEngine would be set to the local value of snmpEngineID and + contextName to the default context for error counters. + +5.1. Procedures for an Incoming Message + + 1. The SSH Transport Model queries the SSH engine, in an + implementation-dependent manner, to determine the address the + message originated from, the user name authenticated by SSH, and + a session identifier. + + 2. Determine the tmTransportAddress to be associated with the + incoming message: + + A. If this is a client-side SSH session, then the + tmTransportAddress is set to the tmTransportAddress used to + establish the session. It MUST exactly include any "user@" + prefix associated with the address provided to the + openSession() ASI. + + B. If this is a server-side SSH session and this is the first + message received over the session, then the + tmTransportAddress is set to the address the message + originated from, determined in an implementation-dependent + way. This value MUST be constant for the entire SSH session, + and future messages received MUST result in the + tmTransportAddress being set to the same value. + + C. If this is a server-side SSH session and this is not the + first message received over the session, then the + tmTransportAddress is set to the previously established + tmTransportAddress for the session (the value from step B, + determined from a previous incoming message). + + + + + + + +Harrington, et al. Standards Track [Page 15] + +RFC 5592 Secure Shell Transport Model for SNMP June 2009 + + + 3. Determine the tmSecurityName to be associated with the incoming + message: + + A. If this is a client-side SSH session, then the tmSecurityName + MUST be set to the tmSecurityName used to establish the + session. + + B. If this is a server-side SSH session and this is the first + message received over the session, then the tmSecurityName is + set to the SSH user name. How the SSH user name is extracted + from the SSH layer is implementation-dependent. This value + MUST be constant for the entire SSH session, and future + messages received MUST result in the tmSecurityName being set + to the same value. + + C. If this is a server-side SSH session and this is not the + first message received over the session, then the + tmSecurityName is set to the previously established + tmSecurityName for the session (the value from step B, + determined from a previous incoming message). + + 4. Create a tmStateReference cache for subsequent reference to the + information. + + tmTransportDomain = snmpSSHDomain + + tmTransportAddress = the derived tmTransportAddress from step + 2. + + tmSecurityName = the derived tmSecurityName from step 3. + + tmTransportSecurityLevel = "authPriv" (authentication and + confidentiality MUST be used to comply with this Transport + Model.) + + tmSessionID = an implementation-dependent value that can be + used to detect when a session has closed and been replaced by + another session. The value in tmStateReference MUST uniquely + identify the session over which the message was received. + This session identifier MUST NOT be reused until there are no + references to it remaining. + + Then the Transport Model passes the message to the Dispatcher using + the following ASI: + + + + + + + +Harrington, et al. Standards Track [Page 16] + +RFC 5592 Secure Shell Transport Model for SNMP June 2009 + + + statusInformation = + receiveMessage( + IN transportDomain -- snmpSSHDomain + IN transportAddress -- the tmTransportAddress for the message + IN wholeMessage -- the whole SNMP message from SSH + IN wholeMessageLength -- the length of the SNMP message + IN tmStateReference -- (NEW) transport info + ) + +5.2. Procedures for Sending an Outgoing Message + + The Dispatcher passes the information to the Transport Model using + the ASI defined in the Transport Subsystem: + + 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 -- (NEW) transport info + ) + + The SSH Transport Model performs the following tasks. + + 1. If tmStateReference does not refer to a cache containing values + for tmTransportDomain, tmTransportAddress, tmSecurityName, + tmRequestedSecurityLevel, and tmSameSecurity, then increment the + snmpSshtmSessionInvalidCaches counter, discard the message, and + return the error indication in the statusInformation. Processing + of this message stops. + + 2. Extract the tmTransportDomain, tmTransportAddress, + tmSecurityName, tmRequestedSecurityLevel, tmSameSecurity, and + tmSessionID from the tmStateReference. + + 3. Identify an SSH session over which to send the messages: + + A. If tmSameSecurity is true and there is no existing session + with a matching tmSessionID, tmSecurityName, and + tmTransportAddress, then increment the + snmpSshtmSessionNoSessions counter, discard the message, and + return the error indication in the statusInformation. + Processing of this message stops. + + B. If there is a session with a matching tmSessionID, + tmTransportAddress, and tmSecurityName, then select that + session. + + + +Harrington, et al. Standards Track [Page 17] + +RFC 5592 Secure Shell Transport Model for SNMP June 2009 + + + C. If there is a session that matches the tmTransportAddress and + tmSecurityName, then select that session. + + D. If the above steps failed to select a session to use, then + call openSession() with the tmStateReference as a parameter. + + + If openSession fails, then discard the message, release + tmStateReference, and pass the error indication returned + by openSession back to the calling module. Processing of + this message stops. + + + If openSession succeeds, then record the + destTransportDomain, destTransportAddress, tmSecurityname, + and tmSessionID in an implementation-dependent manner. + This will be needed when processing an incoming message. + + 4. Pass the wholeMessage to SSH for encapsulation as data in an SSH + message over the identified SSH session. Any necessary + additional SSH-specific parameters should be provided in an + implementation-dependent manner. + +5.3. Establishing a Session + + The Secure Shell Transport Model provides the following Abstract + Service Interface (ASI) to describe the data passed between the SSH + Transport Model and the SSH service. It is an implementation + decision how such data is passed. + + statusInformation = + openSession( + IN tmStateReference -- transport information to be used + OUT tmStateReference -- transport information to be used + IN maxMessageSize -- of the sending SNMP entity + ) + + The following describes the procedure to follow to establish a + session between a client and server to run SNMP over SSH. This + process is used 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, a notification + originator, or a proxy forwarder. + + + + + + + + +Harrington, et al. Standards Track [Page 18] + +RFC 5592 Secure Shell Transport Model for SNMP June 2009 + + + 1. Increment the snmpSshtmSessionOpens counter. + + 2. Using tmTransportAddress, 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 transportAddress associated with a session + MUST remain constant during the lifetime of the SSH session. + Implementations may need to cache the transportAddress passed to + the openSession API for later use when performing incoming + message processing (see Section 5.1). + + 1. To authenticate the server, the client usually stores pairs + (tmTransportAddress, server host public key) in an + implementation-dependent manner. + + 2. The other parameters of the transport connection are provided + in an implementation-dependent manner. + + 3. If the attempt to establish a connection is unsuccessful or + if server-authentication fails, then + snmpSshtmSessionOpenErrors is incremented, an openSession + error indication is returned, and openSession processing + stops. + + 3. The client will then invoke an SSH authentication service to + authenticate the principal, such as that described in the SSH + authentication protocol [RFC4252]. + + 1. If the tmTransportAddress field contains a user name followed + by an '@' character (US-ASCII 0x40), that user name string + should be presented to the SSH server as the "user name" for + user-authentication purposes. If there is no user name in + the tmTransportAddress, then the tmSecurityName should be + used as the user name. + + 2. The credentials used to authenticate the SSH principal are + determined in an implementation-dependent manner. + + 3. In an implementation-specific manner, invoke the SSH user- + authentication service using the calculated user name. + + 4. If the user authentication is unsuccessful, then the + transport connection is closed, the + snmpSshtmSessionUserAuthFailures counter is incremented, an + error indication is returned to the calling module, and + processing stops for this message. + + + + + +Harrington, et al. Standards Track [Page 19] + +RFC 5592 Secure Shell Transport Model for SNMP June 2009 + + + 4. The client should invoke the "ssh-connection" service (also known + as the SSH connection protocol [RFC4254]), and request a channel + of type "session". If unsuccessful, the transport connection is + closed, the snmpSshtmSessionNoChannels counter is incremented, an + error indication is returned to the calling module, and + processing stops for this message. + + 5. The client invokes "snmp" as an SSH Subsystem, as indicated in + the "subsystem" parameter. If unsuccessful, the transport + connection is closed, the snmpSshtmSessionNoSubsystems counter is + incremented, an error indication is returned to the calling + module, and processing stops for this message. + + 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 Transport + Model MUST default to providing access to the "snmp" SSH + Subsystem if the SSH session is established using the IANA- + assigned TCP ports (5161 and 5162). Servers SHOULD be + configurable to allow access to the SNMP SSH Subsystem over other + ports. + + 6. Set tmSessionID in the tmStateReference cache to an + implementation-dependent value to identify the session. + + 7. The tmSecurityName used to establish the SSH session must be the + only tmSecurityName used with the session. Incoming messages for + the session MUST be associated with this tmSecurityName value. + How this is accomplished is implementation-dependent. + +5.4. Closing a Session + + The Secure Shell Transport Model provides the following ASI to close + a session: + + statusInformation = + closeSession( + IN tmSessionID -- session ID of session to be closed + ) + + The following describes the procedure to follow to close a session + between a client and server. This process is followed by any SNMP + engine to close an SSH session. It is implementation-dependent when + a session should be closed. The calling code should release the + associated tmStateReference. + + + + + + +Harrington, et al. Standards Track [Page 20] + +RFC 5592 Secure Shell Transport Model for SNMP June 2009 + + + 1. Increment the snmpSshtmSessionCloses counter. + + 2. If there is no session corresponding to tmSessionID, then + closeSession processing is complete. + + 3. Have SSH close the session associated with tmSessionID. + +6. MIB Module Overview + + This MIB module provides management of the Secure Shell Transport + Model. It defines an OID to identify the SNMP-over-SSH transport + domain, a Textual Convention for SSH Addresses, and several + statistics counters. + +6.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. + +6.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 + +6.3. Relationship to Other MIB Modules + + Some management objects defined in other MIB modules are applicable + to an entity implementing the SSH Transport Model. In particular, it + is assumed that an entity implementing the SNMP-SSH-TM-MIB will + implement the SNMPv2-MIB [RFC3418] and the SNMP-FRAMEWORK-MIB + [RFC3411]. It is expected that an entity implementing this MIB will + also support the Transport Security Model [RFC5591] and, therefore, + implement the SNMP-TSM-MIB. + + This MIB module is for monitoring SSH Transport Model information. + +6.3.1. MIB Modules Required for IMPORTS + + The following MIB module imports items from [RFC2578], [RFC2579], and + [RFC2580]. + + This MIB module also references [RFC1033], [RFC4252], [RFC3490], and + [RFC3986]. + + + + + + +Harrington, et al. Standards Track [Page 21] + +RFC 5592 Secure Shell Transport Model for SNMP June 2009 + + + This document uses TDomain Textual Conventions for the SNMP-internal + MIB modules defined here for compatibility with the RFC 3413 MIB + modules and the RFC 3411 Abstract Service Interfaces. + +7. MIB Module Definition + +SNMP-SSH-TM-MIB DEFINITIONS ::= BEGIN + +IMPORTS + MODULE-IDENTITY, OBJECT-TYPE, + OBJECT-IDENTITY, mib-2, snmpDomains, + Counter32 + FROM SNMPv2-SMI -- RFC 2578 + TEXTUAL-CONVENTION + FROM SNMPv2-TC -- RFC 2579 + MODULE-COMPLIANCE, OBJECT-GROUP + FROM SNMPv2-CONF -- RFC 2580 + ; + +snmpSshtmMIB MODULE-IDENTITY + LAST-UPDATED "200906090000Z" + ORGANIZATION "ISMS Working Group" + CONTACT-INFO "WG-EMail: isms@lists.ietf.org + Subscribe: isms-request@lists.ietf.org + + Chairs: + Juergen Quittek + NEC Europe Ltd. + Network Laboratories + Kurfuersten-Anlage 36 + 69115 Heidelberg + Germany + +49 6221 90511-15 + quittek@netlab.nec.de + + Juergen Schoenwaelder + Jacobs University Bremen + Campus Ring 1 + 28725 Bremen + Germany + +49 421 200-3587 + j.schoenwaelder@jacobs-university.de + + Co-editors: + David Harrington + Huawei Technologies USA + 1700 Alma Drive + Plano Texas 75075 + + + +Harrington, et al. Standards Track [Page 22] + +RFC 5592 Secure Shell Transport Model for SNMP June 2009 + + + USA + +1 603-436-8634 + ietfdbh@comcast.net + + Joseph Salowey + Cisco Systems + 2901 3rd Ave + Seattle, WA 98121 + USA + jsalowey@cisco.com + + Wes Hardaker + Cobham Analytic Solutions + P.O. Box 382 + Davis, CA 95617 + USA + +1 530 792 1913 + ietf@hardakers.net + " + DESCRIPTION + "The Secure Shell Transport Model MIB. + + Copyright (c) 2009 IETF Trust and the persons + identified as authors of the code. All rights reserved. + + Redistribution and use in source and binary forms, with or + without modification, are permitted provided that the + following conditions are met: + + - Redistributions of source code must retain the above copyright + notice, this list of conditions and the following disclaimer. + + - Redistributions in binary form must reproduce the above + copyright notice, this list of conditions and the following + disclaimer in the documentation and/or other materials + provided with the distribution. + + - Neither the name of Internet Society, IETF or IETF Trust, + nor the names of specific contributors, may be used to endorse + or promote products derived from this software without + specific prior written permission. + + THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND + CONTRIBUTORS 'AS IS' AND ANY EXPRESS OR IMPLIED WARRANTIES, + INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF + MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE + DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR + CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, + + + +Harrington, et al. Standards Track [Page 23] + +RFC 5592 Secure Shell Transport Model for SNMP June 2009 + + + SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT + NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; + LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN + CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR + OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, + EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + + This version of this MIB module is part of RFC 5592; + see the RFC itself for full legal notices." + + REVISION "200906090000Z" + DESCRIPTION "The initial version, published in RFC 5592." + + ::= { mib-2 189 } + +-- ---------------------------------------------------------- -- +-- subtrees in the SNMP-SSH-TM-MIB +-- ---------------------------------------------------------- -- + +snmpSshtmNotifications OBJECT IDENTIFIER ::= { snmpSshtmMIB 0 } +snmpSshtmObjects OBJECT IDENTIFIER ::= { snmpSshtmMIB 1 } +snmpSshtmConformance OBJECT IDENTIFIER ::= { snmpSshtmMIB 2 } + +-- ------------------------------------------------------------- +-- Objects +-- ------------------------------------------------------------- + +snmpSSHDomain OBJECT-IDENTITY + STATUS current + DESCRIPTION + "The SNMP-over-SSH transport domain. The corresponding + transport address is of type SnmpSSHAddress. + + When an SNMP entity uses the snmpSSHDomain Transport + Model, it must be capable of accepting messages up to + and including 8192 octets in size. Implementation of + larger values is encouraged whenever possible. + + The securityName prefix to be associated with the + snmpSSHDomain is 'ssh'. This prefix may be used by Security + Models or other components to identify which secure transport + infrastructure authenticated a securityName." + ::= { snmpDomains 7 } + +SnmpSSHAddress ::= TEXTUAL-CONVENTION + DISPLAY-HINT "1a" + STATUS current + + + +Harrington, et al. Standards Track [Page 24] + +RFC 5592 Secure Shell Transport Model for SNMP June 2009 + + + DESCRIPTION + "Represents either a hostname or IP address, along with a port + number and an optional user name. + + The beginning of the address specification may contain a + user name followed by an '@' (US-ASCII character 0x40). This + portion of the address will indicate the user name that should + be used when authenticating to an SSH server. The user name + must be encoded in UTF-8 (per [RFC4252]). If missing, the + SNMP securityName should be used. After the optional user + name field and '@' character comes the hostname or IP + address. + + The hostname is always in US-ASCII (as per RFC1033); + internationalized hostnames are encoded in US-ASCII as + specified in RFC 3490. The hostname is followed by a colon + ':' (US-ASCII character 0x3A) and a decimal port number in + US-ASCII. The name SHOULD be fully qualified whenever + possible. + + An IPv4 address must be in dotted decimal format followed + by a colon ':' (US-ASCII character 0x3A) and a decimal port + number in US-ASCII. + + An IPv6 address must be in colon-separated format, surrounded + by square brackets ('[', US-ASCII character 0x5B, and ']', + US-ASCII character 0x5D), followed by a colon ':' (US-ASCII + character 0x3A) and a decimal port number in US-ASCII. + + Values of this Textual Convention might not be directly usable + as transport-layer addressing information and may 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 snmpSSHAddress 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. + + + + + +Harrington, et al. Standards Track [Page 25] + +RFC 5592 Secure Shell Transport Model for SNMP June 2009 + + + When this Textual Convention is used as a syntax of an + index object, there may be issues with the limit of 128 + sub-identifiers, which is specified in SMIv2 (STD 58). It + is RECOMMENDED that all MIB documents using this Textual + Convention make explicit any limitations on index + component lengths that management software must observe. + This may be done either by including SIZE constraints on + the index components or by specifying applicable + constraints in the conceptual row DESCRIPTION clause or + in the surrounding documentation. + " + REFERENCE + "RFC 1033: DOMAIN ADMINISTRATORS OPERATIONS GUIDE + RFC 3490: Internationalizing Domain Names in Applications + RFC 3986: Uniform Resource Identifier (URI): Generic Syntax + RFC 4252: The Secure Shell (SSH) Authentication Protocol" + SYNTAX OCTET STRING (SIZE (1..255)) + +-- The snmpSshtmSession Group + +snmpSshtmSession OBJECT IDENTIFIER ::= { snmpSshtmObjects 1 } + +snmpSshtmSessionOpens OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION "The number of times an openSession() request has been + executed as an SSH client, whether it succeeded or + failed. + " + ::= { snmpSshtmSession 1 } + +snmpSshtmSessionCloses OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION "The number of times a closeSession() request has been + executed as an SSH client, whether it succeeded or + failed. + " + ::= { snmpSshtmSession 2 } + +snmpSshtmSessionOpenErrors OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + + + + + +Harrington, et al. Standards Track [Page 26] + +RFC 5592 Secure Shell Transport Model for SNMP June 2009 + + + DESCRIPTION "The number of times an openSession() request + failed to open a transport connection or failed to + authenticate the server. + " + ::= { snmpSshtmSession 3 } + +snmpSshtmSessionUserAuthFailures OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION "The number of times an openSession() request + failed to open a session as an SSH client due to + user-authentication failures. + " + ::= { snmpSshtmSession 4 } + +snmpSshtmSessionNoChannels OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION "The number of times an openSession() request + failed to open a session as an SSH client due to + channel-open failures. + " + ::= { snmpSshtmSession 5 } + +snmpSshtmSessionNoSubsystems OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION "The number of times an openSession() request + failed to open a session as an SSH client due to + inability to connect to the requested subsystem. + " + ::= { snmpSshtmSession 6 } + +snmpSshtmSessionNoSessions OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION "The number of times an outgoing message was + dropped because the same session was no longer + available. + " + ::= { snmpSshtmSession 7 } + +snmpSshtmSessionInvalidCaches OBJECT-TYPE + SYNTAX Counter32 + + + +Harrington, et al. Standards Track [Page 27] + +RFC 5592 Secure Shell Transport Model for SNMP June 2009 + + + MAX-ACCESS read-only + STATUS current + DESCRIPTION "The number of outgoing messages dropped because the + tmStateReference referred to an invalid cache. + " + ::= { snmpSshtmSession 8 } + +-- ************************************************ +-- snmpSshtmMIB - Conformance Information +-- ************************************************ + +snmpSshtmCompliances OBJECT IDENTIFIER ::= { snmpSshtmConformance 1 } + +snmpSshtmGroups OBJECT IDENTIFIER ::= { snmpSshtmConformance 2 } + +-- ************************************************ +-- Compliance statements +-- ************************************************ + +snmpSshtmCompliance MODULE-COMPLIANCE + STATUS current + + DESCRIPTION "The compliance statement for SNMP engines that + support the SNMP-SSH-TM-MIB." + MODULE + MANDATORY-GROUPS { snmpSshtmGroup } + ::= { snmpSshtmCompliances 1 } + +-- ************************************************ +-- Units of conformance +-- ************************************************ + +snmpSshtmGroup OBJECT-GROUP + OBJECTS { + snmpSshtmSessionOpens, + snmpSshtmSessionCloses, + snmpSshtmSessionOpenErrors, + snmpSshtmSessionUserAuthFailures, + snmpSshtmSessionNoChannels, + snmpSshtmSessionNoSubsystems, + snmpSshtmSessionNoSessions, + snmpSshtmSessionInvalidCaches + } + STATUS current + DESCRIPTION "A collection of objects for maintaining information + of an SNMP engine that implements the SNMP Secure + Shell Transport Model. + " + + + +Harrington, et al. Standards Track [Page 28] + +RFC 5592 Secure Shell Transport Model for SNMP June 2009 + + + ::= { snmpSshtmGroups 2 } + +END + +8. Operational Considerations + + The SSH Transport Model will likely not work in conditions where + remote access to the CLI has stopped working. The SSH Transport + Model assumes that TCP and IP continue to operate correctly between + the communicating nodes. Failures in either node, death of the + deamon serving the communication, routing problems in the network + between, firewalls that block the traffic, and other problems can + prevent the SSH Transport Model from working. In situations where + management access has to be very reliable, operators should consider + mitigating measures. These measures may include dedicated + management-only networks, point-to-point links, and the ability to + use alternate protocols and transports. + + To have SNMP properly utilize the security services provided by SSH, + the SSH Transport Model MUST be used with a Security Model that knows + how to process a tmStateReference, such as the Transport Security + Model for SNMP [RFC5591]. + + If the SSH Transport Model is configured to utilize AAA services, + operators should consider configuring support for local + authentication mechanisms, such as local passwords, so SNMP can + continue operating during times of network stress. + + The SSH protocol has its own window mechanism, defined in RFC 4254. + The SSH specifications leave it open when window adjustment messages + should be created, and some implementations send these whenever + received data has been passed to the application. There are + noticeable bandwidth and processing overheads to handling such window + adjustment messages, which can be avoided by sending them less + frequently. + + The SSH protocol requires the execution of CPU-intensive calculations + to establish a session key during session establishment. This means + that short-lived sessions become computationally expensive compared + to USM, which does not have a notion of a session key. Other + transport security protocols such as TLS support a session-resumption + feature that allows reusing a cached session key. Such a mechanism + does not exist for SSH and thus SNMP applications should keep SSH + sessions for longer time periods. + + To initiate SSH connections, an entity must be configured with SSH + client credentials plus information to authenticate the server. + While hosts are often configured to be SSH clients, most + + + +Harrington, et al. Standards Track [Page 29] + +RFC 5592 Secure Shell Transport Model for SNMP June 2009 + + + internetworking devices are not. To send notifications over SSHTM, + the internetworking device will need to be configured as an SSH + client. How this credential configuration is done is implementation- + and deployment-specific. + +9. Security Considerations + + This memo describes a Transport Model that permits SNMP to utilize + SSH security services. The security threats and how the SSH + Transport Model mitigates those threats is covered in detail + throughout this memo. + + The SSH Transport Model 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. + + SSHv2 provides perfect forward secrecy (PFS) for encryption keys. + PFS is a major design goal of SSH, and any well-designed key-exchange + algorithm will provide it. + + The security implications of using SSH are covered in [RFC4251]. + + The SSH Transport Model has no way to verify that server + authentication was performed, to learn the host's public key in + advance, or to verify that the correct key is being used. The SSH + Transport Model simply trusts that these are properly configured by + the implementer and deployer. + + SSH provides the "none" userauth method. The SSH Transport Model + MUST NOT be used with an SSH connection with the "none" userauth + method. While SSH does support turning off confidentiality and + integrity, they MUST NOT be turned off when used with the SSH + Transport Model. + + The SSH protocol is not always clear on whether the user name field + must be filled in, so for some implementations, such as those using + GSSAPI authentication, it may be necessary to use a mapping algorithm + to transform an SSH identity to a tmSecurityName or to transform a + tmSecurityName to an SSH identity. + + In other cases, the user name may not be verified by the server, so + for these implementations, it may be necessary to obtain the user + name from other credentials exchanged during the SSH exchange. + + + + + + + +Harrington, et al. Standards Track [Page 30] + +RFC 5592 Secure Shell Transport Model for SNMP June 2009 + + +9.1. 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 + Diffie-Hellman (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 SSH Transport Model. + +9.2. Notification Authorization Considerations + + SNMP Notifications are authorized to be sent to a receiver based on + the securityName used by the notification originator's SNMP engine. + This authorization is performed before the message is actually sent + and before the credentials of the remote receiver have been verified. + Thus, the credentials presented by a notification receiver MUST match + the expected value(s) for a given transport address, and ownership of + the credentials MUST be properly cryptographically verified. + +9.3. SSH User and Key Selection + + If a "user@" prefix is used within an SnmpSSHAddress value to specify + an SSH user name to use for authentication, then the key presented to + the remote entity MUST be the key expected by the server for the + "user". This may be different than a locally cached key identified + by the securityName value. + +9.4. Conceptual Differences between USM and SSHTM + + The User-based Security Model [RFC3414] employed symmetric + cryptography and user-naming conventions. SSH employs an asymmetric + cryptography and naming model. Unlike USM, cryptographic keys will + be different on both sides of the SSH connection. Both sides are + responsible for verifying that the remote entity presents the right + key. The optional "user@" prefix component of the SnmpSSHAddress + Textual Convention allows the client SNMP stack to associate the + connection with a securityName that may be different than the SSH + user name presented to the SSH server. + + + +Harrington, et al. Standards Track [Page 31] + +RFC 5592 Secure Shell Transport Model for SNMP June 2009 + + +9.5. The 'none' MAC Algorithm + + SSH provides the "none" Message Authentication Code (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 SSH Transport Model. + +9.6. Use with SNMPv1/v2c Messages + + The SNMPv1 and SNMPv2c message processing described in [RFC3584] (BCP + 74) always selects the SNMPv1 or SNMPv2c Security Models, + respectively. Both of these and the User-based Security Model + typically used with SNMPv3 derive the securityName and securityLevel + from the SNMP message received, even when the message was received + over a secure transport. Access control decisions are therefore made + based on the contents of the SNMP message, rather than using the + authenticated identity and securityLevel provided by the SSH + Transport Model. + +9.7. MIB Module Security + + 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 The information in the snmpSshtmSession group is generated locally + when a client session is being opened or closed. This information + can reflect the configured capabilities of a remote SSH server, + which could be helpful to an attacker for focusing an attack. + + + + + + + + +Harrington, et al. Standards Track [Page 32] + +RFC 5592 Secure Shell Transport Model for SNMP June 2009 + + + 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 cryptographic mechanisms for + authentication and privacy, such as those found in the User-based + Security Model [RFC3414], the Transport Security Model [RFC5591], and + the SSH Transport Model described in this document. + + 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. + +10. IANA Considerations + + IANA has assigned: + + 1. Two TCP port numbers in the Port Numbers registry that will be + the default ports for the SNMP-over-SSH Transport Model as + defined in this document, and the SNMP-over-SSH Transport Model + for notifications as defined in this document. The assigned + keywords and port numbers are "snmpssh" (5161) and "snmpssh-trap" + (5162). + + 2. An SMI number (189) under mib-2, for the MIB module in this + document. + + 3. An SMI number (7) under snmpDomains, for the snmpSSHDomain. + + 4. "ssh" as the corresponding prefix for the snmpSSHDomain in the + SNMP Transport Domains registry; defined in [RFC5590]. + + 5. "snmp" as a Connection Protocol Subsystem Name in the SSH + Protocol Parameters registry. + +11. Acknowledgments + + The editors would like to thank Jeffrey Hutzelman for sharing his SSH + insights, and Dave Shield for an outstanding job wordsmithing the + existing document to improve organization and clarity. + + + +Harrington, et al. Standards Track [Page 33] + +RFC 5592 Secure Shell Transport Model for SNMP June 2009 + + + Additionally, helpful document reviews were received from Juergen + Schoenwaelder. + +12. References + +12.1. Normative References + + [RFC1033] Lottor, M., "Domain administrators operations guide", + RFC 1033, November 1987. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Structure of Management Information + Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. + + [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Textual Conventions for SMIv2", + STD 58, RFC 2579, April 1999. + + [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, + "Conformance Statements for SMIv2", STD 58, RFC 2580, + April 1999. + + [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An + Architecture for Describing Simple Network Management + Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, + December 2002. + + [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. + + [RFC3418] Presuhn, R., "Management Information Base (MIB) for the + Simple Network Management Protocol (SNMP)", STD 62, + RFC 3418, December 2002. + + [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, + "Internationalizing Domain Names in Applications (IDNA)", + RFC 3490, March 2003. + + + + + + +Harrington, et al. Standards Track [Page 34] + +RFC 5592 Secure Shell Transport Model for SNMP June 2009 + + + [RFC3584] Frye, R., Levi, D., Routhier, S., and B. Wijnen, + "Coexistence between Version 1, Version 2, and Version 3 + of the Internet-standard Network Management Framework", + BCP 74, RFC 3584, August 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. + + [RFC5590] Harrington, D. and J. Schoenwaelder, "Transport Subsystem + for the Simple Network Management Protocol (SNMP)", + RFC 5590, June 2009. + +12.2. Informative References + + [RFC1994] Simpson, W., "PPP Challenge Handshake Authentication + Protocol (CHAP)", RFC 1994, August 1996. + + [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, + "Remote Authentication Dial In User Service (RADIUS)", + RFC 2865, June 2000. + + [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. + + [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform + Resource Identifier (URI): Generic Syntax", STD 66, + RFC 3986, January 2005. + + [RFC4256] Cusack, F. and M. Forssen, "Generic Message Exchange + Authentication for the Secure Shell Protocol (SSH)", + RFC 4256, January 2006. + + + + + + + +Harrington, et al. Standards Track [Page 35] + +RFC 5592 Secure Shell Transport Model for SNMP June 2009 + + + [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. + + [RFC4742] Wasserman, M. and T. Goddard, "Using the NETCONF + Configuration Protocol over Secure SHell (SSH)", RFC 4742, + December 2006. + + [RFC5090] Sterman, B., Sadolevsky, D., Schwartz, D., Williams, D., + and W. Beck, "RADIUS Extension for Digest Authentication", + RFC 5090, February 2008. + + [RFC5591] Harrington, D. and W. Hardaker, "Transport Security Model + for the Simple Network Management Protocol (SNMP)", + RFC 5591, June 2009. + +Authors' Addresses + + David Harrington + Huawei Technologies (USA) + 1700 Alma Dr. Suite 100 + Plano, TX 75075 + USA + + Phone: +1 603 436 8634 + EMail: ietfdbh@comcast.net + + + Joseph Salowey + Cisco Systems + 2901 3rd Ave + Seattle, WA 98121 + USA + + EMail: jsalowey@cisco.com + + + Wes Hardaker + Cobham Analytic Solutions + P.O. Box 382 + Davis, CA 95617 + US + + Phone: +1 530 792 1913 + EMail: ietf@hardakers.net + + + + + +Harrington, et al. Standards Track [Page 36] + |