]> Huawei Technologies (USA)

1700 Alma Dr. Suite 100 Plano, TX 75075 USA +1 603 436 8634 dharrington@huawei.com

Cisco Systems

2901 3rd Ave Seattle, WA 98121 USA jsalowey@cisco.com

Sparta, Inc.

P.O. Box 382 Davis CA 95617 US +1 530 792 1913 ietf@hardakers.net

Operations and Management Network Management Simple Network Management Protocol SNMP Secure Shell SSH This memo describes a Transport Model for the Simple Network Management Protocol, using the Secure Shell protocol (SSH). 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.

This memo describes a Transport Model for the Simple Network Management Protocol, using the Secure Shell protocol (SSH) within a transport subsystem . 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 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.

For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 . 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 , STD 58, RFC 2579 and STD 58, RFC 2580 .

For consistency with SNMP-related specifications, this document favors terminology as defined in STD62 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 in either manager or agent or in both roles 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" 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. The User-Based Security Model (USM) is a mandatory-to-implement Security Model in STD 62. While SSH and USM 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, with each acting in a particular role; an application or a set of applications, or a combination of these within an administrative domain. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in . 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. Note to RFC Editor - if the previous paragraph and this note have not been removed, please send the document back to the editor to remove this.

The reader is expected to have read and understood the description of the SNMP architecture, as defined in , and the Transport Subsystem architecture extension specified in "Transport Subsystem for the Simple Network Management Protocol" . 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 which 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.

Version 3 of the Simple Network Management Protocol (SNMPv3) added security to the protocol. The User-based Security Model (USM) 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 deploying 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, 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. This document addresses the requirement to utilize client authentication and key exchange methods which support different security infrastructures and provide different security properties. This document describes how to use client authentication as described in "SSH Authentication Protocol" . 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 http://www.iana.org/assignments/ssh-parameters). The use of the "none" authentication method is NOT RECOMMENDED, as described in Security Considerations. Local accounts may be supported through the use of the publickey, hostbased or password methods. The password method allows for integration with deployed password infrastructure such as AAA servers using the RADIUS protocol . 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 . 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 over the SSH transport protocol, using SSH user-auth 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.

The design of this SNMP Transport Model is influenced by the following constraints: 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). 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. It may not be possible for the transport model to determine when the network is under stress. A transport model should require no changes to the SNMP architecture. A transport model should require no changes to the underlying 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: The Transport Layer Protocol 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. The User Authentication Protocol authenticates the client-side principal to the server. It runs over the transport layer protocol. The Connection Protocol multiplexes the encrypted tunnel into several logical channels. It runs over the transport after successfully authenticating the principal. Generic Message Exchange Authentication is a general purpose authentication method for the SSH protocol, suitable for interactive authentications where the authentication data should be entered via a keyboard Generic Security Service Application Program Interface (GSS-API) Authentication and Key Exchange for the Secure Shell (SSH) Protocol 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, and a family of SSH key exchange methods that use GSS-API to authenticate a Diffie-Hellman key exchange. 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.

A transport model is a component of the Transport Subsystem within the SNMP architecture. The SSH Transport Model thus fits between the underlying SSH transport layer and the message dispatcher . 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.

The Secure Shell Transport Model provides protection against the threats identified by the RFC 3411 architecture : Modification of Information - SSH provides for verification that the contents of each message has not been modified during its transmission through the network, by digitally signing each SSH packet. Masquerade - SSH provides for verification of the identity of the SSH server and the identity of the SSH client. SSH provides for verification of the identity of the SSH server through the SSH Transport Protocol server authentication (). 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 (). 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 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.) 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. Disclosure - SSH provides protection against the disclosure of information to unauthorized recipients or eavesdroppers by allowing for encryption of all traffic between SNMP engines.

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 . 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 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. The transport layer algorithms used to provide authentication, data integrity and encryption SHOULD NOT be exposed to the SSH Transport Model layer. 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 and the Secure Shell Transport Layer Protocol 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 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 - publickey, password, and host-based - and 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 or Diameter 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 or digest authentication to integrate with RADIUS or Diameter. At some point in the processing, these mechanisms require the password be made available as clear text on the device that is authenticating the password which might introduce threats to the authentication infrastructure. [DISCUSS: do we really need this paragraph? GSSKeyex provides a framework for the addition of client 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.

This document describes the use of an SSH subsystem for SNMP to make SNMP usage distinct from other usages. SSH subsystems of type "snmp" are 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 or the incoming message would never reach the SSH Transport Model. [DISCUSS: If a notification originator opens a subsystem called "snmp" and a command generator opens a subsystem called "snmp", will that be confusing to SSH? ] 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 transportDomain, transportAddress, securityName, and securityLevel associated with each session.

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, and 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 (Application 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.

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 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-TARGET-MIB module contains objects for defining 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 perform proxy. These 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.

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 potentially longer-term state relating to transport and security. The RFC3411 architecture uses caches to maintain the short-term message state, and uses references in the ASIs to pass this information between subsystems. This document defines the requirements for a cache to handle the longer-term transport state information, using a tmStateReference parameter to pass this information between subsystems. To simplify the elements of procedure, the release of state information is not always explicitly specified. As a general rule, if state information is available when a message being processed gets discarded, the state related to that message SHOULD also be discarded. If state information is available when a relationship between engines is severed, such as the closing of a transport session, the state information for that relationship SHOULD also be discarded. Since the contents of a cache are meaningful only within an implementation, and not on-the-wire, the format of the cache and the LCD are implementation-specific.

The securityStateReference parameter is defined in RFC3411. Its primary purpose is to provide a mapping between a request and the corresponding response. This cache is not accessible to Transport Models, and an entry is typically only retained for the lifetime of a request-response pair of messages.

For each transport session, information about the transport security is stored in a cache. The tmStateReference parameter is used to pass model-specific and mechanism-specific parameters between the Transport subsystem and transport-aware Security Models. The tmStateReference cache will typically remain valid for the duration of the transport session, and hence may be used for several messages. Since this cache is only used within an implementation, and not on-the-wire, the precise contents and format are implementation- dependent. However, for interoperability between Transport Models and transport-aware Security Models, entries in this cache must include at least the following fields: transportDomain transportAddress tmSecurityName tmRequestedSecurityLevel tmTransportSecurityLevel tmSameSecurity tmSessionID

Information about the source of an incoming SNMP message is passed up from the Transport subsystem as far as the Message Processing subsystem. However these parameters are not included in the processIncomingMsg ASI defined in RFC3411, and hence this information is not directly available to the Security Model. A transport-aware Security Model might wish to take account of the transport protocol and originating address when authenticating the request, and setting up the authorization parameters. It is therefore necessary for the Transport Model to include this information in the tmStateReference cache, so that it is accessible to the Security Model. transportDomain: the transport protocol (and hence the Transport Model) used to receive the incoming message transportAddress: the source of the incoming message. The ASIs used for processing an outgoing message all include explicit transportDomain and transportAddress parameters. The values within the securityStateReference cache might override these parameters for outgoing messages.

There are actually three distinct "identities" that can be identified during the processing of an SNMP request over a secure transport: transport principal: the transport-authenticated identity, on whose behalf the secure transport connection was (or should be) established. This value is transport-, mechanism- and implementation- specific, and is only used within a given Transport Model. tmSecurityName: a human-readable name (in snmpAdminString format) representing this transport identity. This value is transport- and implementation-specific, and is only used (directly) by the Transport and Security Models. securityName: a human-readable name (in snmpAdminString format) representing the SNMP principal in a model-independent manner. The transport principal may or may not be the same as the tmSecurityName. Similarly, the tmSecurityName may or may not be the same as the securityName as seen by the Application and Access Control subsystems. In particular, a non-transport-aware Security Model will ignore tmSecurityName completely when determining the SNMP securityName. However it is important that the mapping between the transport principal and the SNMP securityName (for transport-aware Security Models) is consistent and predictable, to allow configuration of suitable access control and the establishment of transport connections.

There are two distinct issues relating to security level as applied to secure transports. For clarity, these are handled by separate fields in the tmStateReference cache: tmTransportSecurityLevel: an indication from the Transport Model of the level of security offered by this session. The Security Model can use this to ensure that incoming messages were suitably protected before acting on them. tmRequestedSecurityLevel: an indication from the Security Model of the level of security required to be provided by the transport protocol. The Transport Model can use this to ensure that outgoing messages will not be sent over an insufficiently secure session.

For security reasons, if a secure transport session is closed between the time a request message is received and the corresponding response message is sent, then the response message SHOULD be discarded, even if a new session has been established. The SNMPv3 WG decided that this should be a SHOULD architecturally, and it is a security-model-specific decision whether to REQUIRE this. tmSameSecurity: this flag is used by a transport-aware Security Model to indicate whether the Transport Model MUST enforce this restriction. tmSessionID: in order to verify whether the session has changed, the Transport Model must be able to compare the session used to receive the original request with the one to be used to send the response. This typically requires some form of session identifier. This value is only ever used by the Transport Model, so the format and interpretation of this field are model-specific and implementation-dependent. When processing an outgoing message, if tmSameSecurity is true, then the tmSessionID MUST match the current transport session, otherwise the message MUST be discarded, and the dispatcher notified that sending the message failed.

The Secure Shell Transport Model has specific responsibilities regarding the cached information. See the Elements of Procedure in for detailed processing instructions on the use of the tmStateReference fields by the SSH Transport Model.

The tmSecurityName MUST be a human-readable name (in snmpAdminString format) representing the identity that has been set according to the procedures in . On the SSH server side of a connection: The identity SHOULD be the value of the user name field of the SSH_MSG_USERAUTH_REQUEST message for which a SSH_MSG_USERAUTH_SUCCESS has been received. How the SSH user name is extracted from the SSH layer is implementation-dependent. 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 a user name to a SSH identity compatible with the parameters required by this transport. How a compatible SSH identity is determined should be administratively configurable if such a mapping is needed. 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 derived from the tmSecurityName by a security model is used to configure notifications and access controls. Non-default transport model transforms SHOULD generate a predictable identity representing the principal.

The tmSessionID must be refreshed upon each received message, so that it can be used to determine whether the SSH session available for sending an outgoing message is the same SSH session as was used when receiving the corresponding incoming message (e.g., a response to a request), when tmSameSecurity is set.

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.

Abstract service interfaces have been defined by and further augmented by 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. 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 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.

The SSH Transport Model queries the SSH engine, in an implementation-dependent manner, to determine the transportAddress, the principal name authenticated by SSH, and a session identifier. By default on the server side of a SSH connection, the principal name is the value of the user name field of the SSH_MSG_USERAUTH_REQUEST message for which a SSH_MSG_USERAUTH_SUCCESS has been received. How this name is extracted from the SSH environment is implementation-dependent. Create a tmStateReference cache for subsequent reference to the information. tmTransportDomain = snmpSSHDomain tmTransportAddress = the address the message originated from, determined in an implementation-dependent way tmSecurityLevel = "authPriv" tmSecurityName = the ssh principal name received by the SSH server or sent from a SSH client. 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 should identify the session over which the message was received. Then the Transport model passes the message to the Dispatcher using the following ASI:

The Dispatcher passes the information to the Transport Model using the ASI defined in the transport subsystem:

The SSH Transport Model performs the following tasks. Extract the tmSecurityName, tmSameSecurity, and tmSessionID from the tmStateReference. (SSHTM ignores the provided tmTransportDomain tmTransportAddress and tmRequestedSecurityLevel.) Using destTransportAddress and tmSecurityName determine if a corresponding entry in the LCD exists. If there is a corresponding entry, and tmSameSecurity is true then compare the tmSessionID to the session ID stored in the LCD. If they do not match then increment the sshtmSessionNoAvailableSessions counter, discard the message and return the error indication in the statusInformation. Processing of this message stops. If there is no corresponding LCD entry, then call openSession() with the destTransportAddress and tmSecurityName as parameters. If OpenSession fails, then discard the message, release tmStateReference and pass the error indication returned by OpenSession back to the calling module. Processing stops for this message. Pass the wholeMessage to SSH for encapsulation as data in an SSH message over the specified SSH session (returned from OpenSession or identified by tmSessionID). Any necessary additional SSH-specific parameters should be provided in an implementation-dependent manner.

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.

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 or a Notification Originator or a Proxy Forwarder. Using 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 destTransportAddress field may contain a user-name followed by an '@' character (ASCII 0x40) that will indicate a specific user-name string that should be presented to the ssh server as the "user name" for authentication purposes. This MAY be different than the passed tmSecurityName value that will be used in the remaining steps below. If there is no specified user-name in the destTransportAddress then the tmSecurtityName should be used as the user-name. The other parameters of the transport connection and the credentials used to authenticate the server are provided in an implementation-dependent manner. If the attempt to establish a connection is unsuccessful, or server authentication fails, then sshtmSessionOpenErrors is incremented, an openSession error indication is returned, and openSession processing stops. In an implementation-specific manner, pass the calculated user-name from step 1. to the SSH layer. The client will then invoke an SSH authentications service to authenticate the principal, such as that described in the SSH authentication protocol . The credentials used to authenticate the SSH principal are determined in an implementation-dependent manner. If the authentication is unsuccessful, then the transport connection is closed, tmStateReference is released, the message is discarded, the sshtmSessionUserAuthFailures counter is incremented, an error indication is returned to the calling module, and processing stops for this message. Once the principal has been successfully authenticated, the client should invoke the "ssh-connection" service (also known as the SSH connection protocol ), request a channel of type "session" in an implementation-dependent manner. If unsuccessful, the transport connection is closed, tmStateReference is released, the message is discarded, the sshtmSessionChannelOpenFailures counter is incremented, an error indication is returned to the calling module, and processing stops for this message. Once the SSH session has been established, the client will invoke "SNMP" as an SSH subsystem, as indicated in the "subsystem" parameter. If unsuccessful, the transport connection is closed, tmStateReference is released, the message is discarded, the sshtmSessionUnavaliableSubsystems 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 port (PPP). Servers SHOULD be configurable to allow access to the SNMP SSH subsystem over other ports. -- note to RFC editor -- Please replace PPP in this document with the assigned port number and remove this note. If successful, this will result in an SSH session. Increment the sshtmSessionOpens counter and create an LCD entry indexed by destTransportAddress and tmStateReference and containing (at a minimum) a cache of the following information: tmTransportAddress tmSecurityName tmSessionID

The Secure Shell Transport Model provides the following ASI to close a session:

The following describes the procedure to follow to close a session between a client and sever . This process is followed by any SNMP engine to close an SSH session. It is implementation-dependent when a session should be closed. Look up the session information in the LCD using the tmTransportAddress and tmSecurityName or other implementation-dependent mechanism. If there is no entry, then closeSession processing is completed. Extract the session identifier from the LCD entry. Have SSH close the session. Increment the sshtmSessionCloses counter.

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.

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.

Generic and Common Textual Conventions used in this document can be found summarized at http://www.ops.ietf.org/mib-common-tcs.html

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 SSHTM-MIB will implement the SNMPv2-MIB , and the SNMP-FRAMEWORK-MIB . It is expected that an entity implementing this MIB will also support the Transport Security Model , and therefore implement the SNMP-TSM-MIB. This MIB module is for monitoring SSH Transport Model information.

The following MIB module imports items from , , . This MIB module also references and

The SSH Transport Model 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, a UDP transport model should be considered instead of the SSH Transport Model. The SSH Transport Model defines two well-known default ports, one for request/response traffic, and one port that listens for notifications. 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 adjustments 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 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. A scalable IETF standard protocol for configuration or key management is RECOMMENDED.

This document 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 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 . The SSH Transport Model 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. 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.

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 SSH Transport Model.

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 SSH Transport Model.

The SNMPv1 and SNMPv2c message processing described in RFC3584 (BCP 74) always select 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.

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: The readable objects in this MIB module are not sensitive. 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 section 8), including full support for the USM and the SSH Transport Model 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.

IANA is requested to assign: 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 an SSH Transport Model as defined in this document, an SMI number under mib-2, for the MIB module in this document, an SMI number under snmpDomains, for the snmpSSHDomain, "ssh" as the corresponding prefix for the snmpSSHDomain in the SNMP Transport Model registry; defined in "snmp" as an SSH Service Name in the http://www.iana.org/assignments/ssh-parameters registry.

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. Additionally, helpful document reviews were received from: Juergen Schoenwaelder.

&rfc2119; &rfc2578; &rfc2579; &rfc2580; &rfc2865; &rfc3411; &rfc3413; &rfc3414; &rfc3418; &rfc3490; &rfc3584; &rfc4251; &rfc4252; &rfc4253; &rfc4254; &I-D.ietf-isms-tmsm; &rfc1994; &rfc3410; &rfc3588; &rfc3986; &rfc4256; &rfc4462; &rfc5090; &rfc4742; &I-D.ietf-isms-transport-security-model;

We need to reach consensus on some issues. Here is the current list of issues from the SSH Transport Model document where we need to reach consensus. Issue #2: In USM, there is a mapping table that permits one user to have multiple methods for authentication, that map to a common securityName. Since SSH supports multiple authentication mechanisms, do we need to specify how these mechanism-specific identities map to a common securityName? This is important to permit admins to configure the TARGET-MIB, for example, with one common identity rather than mechanism-specific identities. Issue #3: Mapping from the sshtmLCDTable identity to an SSH mechanisms-specific identity. This may just be the opposite transform of Issue #2. Issue #5: what are the elements of procedure if you run for example SNMPv3/USM over SSHTM? The ASIs do not have parameters to identify two methods of authentication, and it is unclear how an outgoing message request would specify both SNMPv3/USM and SSHTM should be used, and which securityName/Level should be used for each. Issue #6: We have not resolved whether the principal associated with a notification receiver must be a principal (aka user) or whether a hostname is adequate. In SNMPv3, the access controls are symmetrical - it is a user-level principal that access controls apply to, whether for R/R or notify applications. Is it acceptable to have user-level for R/R and host-level for notify functionality? A user that is not allowed to GET an object might be able to have the value of the object reported in a notification, or vice-versa. This is not much different that a principal having two different identities, one for R/R and another for notifications, or an admin configuring systems to send notifications to a different principal than those who do R/R processing. The WG needs to discuss this and reach some consensus on whether this is an issue or not, and how we want to proceed. TODO: finalize error processing in EOP

From -12 to -13 Removed redundant sections 3.1.4 and 3.1.5 on privacy and replay/delay/etc protection. From -11- to -12 Updated "Cached Information and References" to match other ISMS documents. Added separate subsection on Secure Shell Transport Model Cached Information. Added IANA considerations to add snmpSSHDomain and "ssh" to a registry for domains and corresponding prefixes, defined in TMSM. Added support for user@ prefixing in the SSH Transport Address definition and EOP. Added support for the "ssh" prefix to the transport address definition and IANA considerations section. Removed the LCD tables and related configuration since the user@ transport address prefixing and the TSM user prefix changes change makes it no longer needed. From -10- to -11 Changed LCD to sshtmLCDTable so it would not be confused with the snmpTsmLCD. Removed the text that said the format and content of the LCD is implementation-specific, since we now have a MIB module to standardize the format and content. Designed sshtmLCDTable to reflect there is only one transportDomain and one securityLevel supported by this transport model. Used sshtmLCDTmSecurityName to reflect that the values in this table and the values in the tmStateReference are usually the same for some fields. Added operational considerations about SSH client credential distribution. Modified EOP to use sshtmLCDTable Resolved Issue #8: Should we allow transport models to select the corresponding security model by providing an additional parameter - the securityModel parameter - to tmStateReference, which would override the securityModel parameter extracted from a message header? Doing this would resolve Issue #5, and would allow the transport security model to be used with all SNMP message versions. - The consensus is that we will not allow the transport model to specify the security model. From -09- to -10 Issue #1: Made release of cached session info an implementation requirement on session close. Issue #4: UTF-8 syntax of userauth user name matches syntax of SnmpAdminString. Issue #7: Resolved to not describe how an SSH session is closed. From -08- to -09 Updated MIB assignment to by rfc4181 compatible update MIB security considerations with coexistence issues update sameSession and tmSessionID support Fixed note about terminology, for consistency with SNMPv3. From -07- to -08 Updated MIB update MIB security considerations develop sameSession and tmSessionID support Added a note about terminology, for consistency with SNMPv3 rather than with RFC2828. Removed reference to mappings other than the identity function. From -06- to -07 removed section on SSH to EngineID mappings, since engineIDs are not exposed to the transport model removed references to engineIDs and discovery removed references to securityModel. added security considerations warning about using with SNMPv1/v2c messages. added keyboard interactive discussion noted some implementation-dependent points removed references to transportModel; we use the transport domain as a model identifier. cleaned up ASIs modified MIB to be under snmpModules changed transportAddressSSH to snmpSSHDomain style addressing From -05- to -06 replaced transportDomainSSH with RFC3417-style snmpSSHDomain replaced transportAddressSSH with RFC3417-style snmpSSHAddress Changed recvMessage to receiveMessage, and modified OUT to IN to match TMSM. From -04- to -05 added sshtmUserTable moved session table into the transport model MIB from the transport subsystem MIB added and then removed Appendix A - Notification Tables Configuration (see Transport Security Model) made this document a specification of a transport model, rather than a security model in two parts. Eliminated TMSP and MPSP and replaced them with "transport model" and "security model". Removed security-model-specific processing from this document. Removed discussion of snmpv3/v1/v2c message format co-existence changed tmSessionReference back to tmStateReference "From -03- to -04-" changed tmStateReference to tmSessionReference "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 created 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 sections on msgFlags, transport parameters resolved issues of opening notifications eliminated sessionID (TMSM needs to be updated to match) eliminated use of tmsSessiontable 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 architectural extension updated conventions 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 the SSH Transport Model 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 secshell 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