TOC 
Network Working GroupD. Harrington
Internet-DraftHuawei Technologies (USA)
Intended status: Standards TrackJ. Salowey
Expires: November 12, 2009Cisco Systems
 W. Hardaker
 Sparta, Inc.
 May 11, 2009


Secure Shell Transport Model for SNMP
draft-ietf-isms-secshell-18

Status of This Memo

This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. 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.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on November 12, 2009.

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.

Abstract

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.



Table of Contents

1.  Introduction
    1.1.  The Internet-Standard Management Framework
    1.2.  Conventions
    1.3.  Modularity
    1.4.  Motivation
    1.5.  Constraints
2.  The Secure Shell Protocol
3.  How SSHTM Fits into the Transport Subsystem
    3.1.  Security Capabilities of this Model
        3.1.1.  Threats
        3.1.2.  Message Authentication
        3.1.3.  Authentication Protocol Support
        3.1.4.  SSH Subsystem
    3.2.  Security Parameter Passing
    3.3.  Notifications and Proxy
4.  Cached Information and References
    4.1.  Secure Shell Transport Model Cached Information
        4.1.1.  tmSecurityName
        4.1.2.  tmSessionID
        4.1.3.  Session State
5.  Elements of Procedure
    5.1.  Procedures for an Incoming Message
    5.2.  Procedures for sending an Outgoing Message
    5.3.  Establishing a Session
    5.4.  Closing a Session
6.  MIB Module Overview
    6.1.  Structure of the MIB Module
    6.2.  Textual Conventions
    6.3.  Relationship to Other MIB Modules
        6.3.1.  MIB Modules Required for IMPORTS
7.  MIB Module Definition
8.  Operational Considerations
9.  Security Considerations
    9.1.  Skipping Public Key Verification
    9.2.  Notification Authorization Considerations
    9.3.  SSH User and Key Selection
    9.4.  Conceptual Differences Between USM and SSHTM
    9.5.  The 'none' MAC Algorithm
    9.6.  Use with SNMPv1/v2c Messages
    9.7.  MIB Module Security
10.  IANA Considerations
11.  Acknowledgements
12.  References
    12.1.  Normative References
    12.2.  Informative References




 TOC 

1.  Introduction

This memo describes a Transport Model for the Simple Network Management Protocol, using the Secure Shell protocol (SSH) [RFC4251] (Ylonen, T. and C. Lonvick, “The Secure Shell (SSH) Protocol Architecture,” January 2006.) within a transport subsystem [I‑D.ietf‑isms‑tmsm] (Harrington, D. and J. Schoenwaelder, “Transport Subsystem for the Simple Network Management Protocol (SNMP),” May 2009.). 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] (Harrington, D., Presuhn, R., and B. Wijnen, “An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks,” December 2002.) 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.



 TOC 

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] (Case, J., Mundy, R., Partain, D., and B. Stewart, “Introduction and Applicability Statements for Internet-Standard Management Framework,” December 2002.).

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] (McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., “Structure of Management Information Version 2 (SMIv2),” April 1999.), STD 58, RFC 2579 [RFC2579] (McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., “Textual Conventions for SMIv2,” April 1999.) and STD 58, RFC 2580 [RFC2580] (McCloghrie, K., Perkins, D., and J. Schoenwaelder, “Conformance Statements for SMIv2,” April 1999.).



 TOC 

1.2.  Conventions

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 [RFC3411] (Harrington, D., Presuhn, R., and B. Wijnen, “An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks,” December 2002.), 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" [RFC3413] (Levi, D., Meyer, P., and B. Stewart, “Simple Network Management Protocol (SNMP) Applications,” December 2002.) 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) [RFC3414] (Blumenthal, U. and B. Wijnen, “User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3),” December 2002.) is a mandatory-to-implement Security Model in STD 62. While SSH and USM frequently refer to a user, the terminology preferred in RFC3411 [RFC3411] (Harrington, D., Presuhn, R., and B. Wijnen, “An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks,” December 2002.) 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 [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

Non uppercased versions of the keywords should be read as in normal English. They will usually, but not always, be used in a context relating to compatibility with the RFC3411 architecture or the subsystem defined here, but which 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 RFC3411 subsystems and Abstract Service Interfaces (ASIs) (see section 3.2). Implementers are free to implement differently. Some usages of these lowercase terms are simply normal English usage.



 TOC 

1.3.  Modularity

The reader is expected to have read and understood the description of the SNMP architecture, as defined in [RFC3411] (Harrington, D., Presuhn, R., and B. Wijnen, “An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks,” December 2002.), and the Transport Subsystem architecture extension specified in "Transport Subsystem for the Simple Network Management Protocol" [I‑D.ietf‑isms‑tmsm] (Harrington, D. and J. Schoenwaelder, “Transport Subsystem for the Simple Network Management Protocol (SNMP),” May 2009.).

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.



 TOC 

1.4.  Motivation

Version 3 of the Simple Network Management Protocol (SNMPv3) added security to the protocol. The User-based Security Model (USM) [RFC3414] (Blumenthal, U. and B. Wijnen, “User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3),” December 2002.) 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, 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" [RFC4252] (Ylonen, T. and C. Lonvick, “The Secure Shell (SSH) Authentication Protocol,” January 2006.). 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 [RFC2865] (Rigney, C., Willens, S., Rubens, A., and W. Simpson, “Remote Authentication Dial In User Service (RADIUS),” June 2000.). 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] (Wasserman, M. and T. Goddard, “Using the NETCONF Configuration Protocol over Secure SHell (SSH),” December 2006.). 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] (Ylonen, T. and C. Lonvick, “The Secure Shell (SSH) Connection Protocol,” January 2006.) over the SSH transport protocol, using SSH user-auth [RFC4252] (Ylonen, T. and C. Lonvick, “The Secure Shell (SSH) Authentication Protocol,” January 2006.) 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.



 TOC 

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).
  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.


 TOC 

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:

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.



 TOC 

3.  How SSHTM Fits into the Transport Subsystem

A transport model is a component of the Transport Subsystem [I‑D.ietf‑isms‑tmsm] (Harrington, D. and J. Schoenwaelder, “Transport Subsystem for the Simple Network Management Protocol (SNMP),” May 2009.) within the SNMP architecture. The SSH Transport Model thus fits between the underlying SSH transport layer and the message dispatcher [RFC3411] (Harrington, D., Presuhn, R., and B. Wijnen, “An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks,” December 2002.).

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.



 TOC 

3.1.  Security Capabilities of this Model



 TOC 

3.1.1.  Threats

The Secure Shell Transport Model provides protection against the threats identified by the RFC 3411 architecture [RFC3411] (Harrington, D., Presuhn, R., and B. Wijnen, “An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks,” December 2002.):

  1. 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.
  2. 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 [RFC4253] (Ylonen, T. and C. Lonvick, “The Secure Shell (SSH) Transport Layer Protocol,” January 2006.). 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] (Ylonen, T. and C. Lonvick, “The Secure Shell (SSH) Authentication Protocol,” January 2006.). 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.)
  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.


 TOC 

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] (Ylonen, T. and C. Lonvick, “The Secure Shell (SSH) Transport Layer Protocol,” January 2006.).

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] (Ylonen, T. and C. Lonvick, “The Secure Shell (SSH) Authentication Protocol,” January 2006.) and the Secure Shell Transport Layer Protocol [RFC4253] (Ylonen, T. and C. Lonvick, “The Secure Shell (SSH) Transport Layer Protocol,” January 2006.) 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.



 TOC 

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] (Ylonen, T. and C. Lonvick, “The Secure Shell (SSH) Authentication Protocol,” January 2006.) - 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 [RFC2865] (Rigney, C., Willens, S., Rubens, A., and W. Simpson, “Remote Authentication Dial In User Service (RADIUS),” June 2000.) or Diameter [RFC3588] (Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, “Diameter Base Protocol,” September 2003.) for validation. The validation could be done using the user-name and user-password attributes. It is also possible to use a different password validation protocol such as CHAP [RFC1994] (Simpson, W., “PPP Challenge Handshake Authentication Protocol (CHAP),” August 1996.) or digest authentication [RFC5090] (Sterman, B., Sadolevsky, D., Schwartz, D., Williams, D., and W. Beck, “RADIUS Extension for Digest Authentication,” February 2008.) 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.

GSSKeyex [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,” May 2006.) 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.



 TOC 

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 or 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 a 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 [RFC4252] (Ylonen, T. and C. Lonvick, “The Secure Shell (SSH) Authentication Protocol,” January 2006.)). 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.

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.



 TOC 

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



 TOC 

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 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] (Levi, D., Meyer, P., and B. Stewart, “Simple Network Management Protocol (SNMP) Applications,” December 2002.) 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 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.



 TOC 

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 potentially longer-term state relating to transport and security. "Transport Subsystem for the Simple Network Management Protocol" (Harrington, D. and J. Schoenwaelder, “Transport Subsystem for the Simple Network Management Protocol (SNMP),” May 2009.) [I‑D.ietf‑isms‑tmsm] defines general requirements for caches and references.

This document defines additional cache requirements related to the Secure Shell Transport Model.



 TOC 

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 (Elements of Procedure) for detailed processing instructions on the use of the tmStateReference fields by the SSH Transport Model.



 TOC 

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 (Elements of Procedure). 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.

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.



 TOC 

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).



 TOC 

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.



 TOC 

5.  Elements of Procedure

Abstract service interfaces have been defined by [RFC3411] (Harrington, D., Presuhn, R., and B. Wijnen, “An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks,” December 2002.) and further augmented by [I‑D.ietf‑isms‑tmsm] (Harrington, D. and J. Schoenwaelder, “Transport Subsystem for the Simple Network Management Protocol (SNMP),” May 2009.) 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.



 TOC 

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).
  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:

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
 )


 TOC 

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 to send the messages over:
    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.
    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 stops for this message.
    • 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.



 TOC 

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 or a Notification Originator or a Proxy Forwarder.

  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 Section 5.1 (Procedures for an Incoming Message)).
    1. To authenticate the server, the client usually stores (tmTransportAddress, server host public key) pairs 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 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] (Ylonen, T. and C. Lonvick, “The Secure Shell (SSH) Authentication Protocol,” January 2006.).
    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.
  4. The client should invoke the "ssh-connection" service (also known as the SSH connection protocol [RFC4254] (Ylonen, T. and C. Lonvick, “The Secure Shell (SSH) Connection Protocol,” January 2006.)), 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 (YYY and ZZZ). 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.


 TOC 

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.

  1. Increment the snmpSshtmSessionCloses counter.
  2. If there is no session corresponding to tmSessionID, then closeSession processing is completed.
  3. Have SSH close the session associated with tmSessionID.


 TOC 

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.



 TOC 

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.



 TOC 

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



 TOC 

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] (Presuhn, R., “Management Information Base (MIB) for the Simple Network Management Protocol (SNMP),” December 2002.), and the SNMP-FRAMEWORK-MIB [RFC3411] (Harrington, D., Presuhn, R., and B. Wijnen, “An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks,” December 2002.). It is expected that an entity implementing this MIB will also support the Transport Security Model [I‑D.ietf‑isms‑transport‑security‑model] (Harrington, D. and W. Hardaker, “Transport Security Model for SNMP,” May 2009.), and therefore implement the SNMP-TSM-MIB.

This MIB module is for monitoring SSH Transport Model information.



 TOC 

6.3.1.  MIB Modules Required for IMPORTS

The following MIB module imports items from [RFC2578] (McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., “Structure of Management Information Version 2 (SMIv2),” April 1999.), [RFC2579] (McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., “Textual Conventions for SMIv2,” April 1999.), [RFC2580] (McCloghrie, K., Perkins, D., and J. Schoenwaelder, “Conformance Statements for SMIv2,” April 1999.).

This MIB module also references [RFC1033] (Lottor, M., “Domain administrators operations guide,” November 1987.), , (Ylonen, T. and C. Lonvick, “The Secure Shell (SSH) Authentication Protocol,” January 2006.) [RFC4252][RFC3490] (Faltstrom, P., Hoffman, P., and A. Costello, “Internationalizing Domain Names in Applications (IDNA),” March 2003.) and [RFC3986] (Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” January 2005.)

This document uses TDomain textual conventions for the SNMP-internal MIB modules defined here for compatibility with the RFC3413 MIB modules and the RFC3411 Abstract Service Interfaces.



 TOC 

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 "200903090000Z"
    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
                     USA
                     +1 603-436-8634
                     ietfdbh@comcast.net

                     Joseph Salowey
                     Cisco Systems
                     2901 3rd Ave
                     Seattle, WA 98121
                     USA
                     jsalowey@cisco.com

	             Wes Hardaker
	             Sparta, Inc.
	             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 MIB module. 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,
    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 XXXX;
    see the RFC itself for full legal notices.
-- NOTE to RFC editor: replace XXXX with actual RFC number
--                     for this document and remove this note
                 "

    REVISION     "200903090000Z"
    DESCRIPTION  "The initial version, published in RFC XXXX.
-- NOTE to RFC editor: replace XXXX with actual RFC number
--                     for this document and remove this note
                 "

    ::= { mib-2 xxxx }
-- RFC Ed.: replace xxxx with IANA-assigned number and
--          remove this note

-- ---------------------------------------------------------- --
-- subtrees in the 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 yy }

-- RFC Ed.: replace yy with IANA-assigned number and
--          remove this note

-- RFC Ed.: replace 'ssh' with the actual IANA assigned prefix string
--          if 'ssh' is not assigned to this document.

SnmpSSHAddress ::= TEXTUAL-CONVENTION
    DISPLAY-HINT "1a"
    STATUS      current
    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 1033),
         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 useable
         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.

         When this textual convention is used as a syntax of an
         index object, there may be issues with the limit of 128
         sub-identifiers specified in SMIv2, STD 58. 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
    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 a 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 a 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 a 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
    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 which implements the
                 SNMP Secure Shell Transport Model.
                "


    ::= { snmpSshtmGroups 2 }


END



 TOC 

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 [I‑D.ietf‑isms‑transport‑security‑model] (Harrington, D. and W. Hardaker, “Transport Security Model for SNMP,” May 2009.).

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.



 TOC 

9.  Security Considerations

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 [RFC4251] (Ylonen, T. and C. Lonvick, “The Secure Shell (SSH) Protocol Architecture,” January 2006.).

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.

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.



 TOC 

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 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.



 TOC 

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. It is thus critical that the credentials presented by a notification receiver MUST match the expected value(s) for a given transport address and that ownership of the credentials MUST be properly cryptographically verified.



 TOC 

9.3.  SSH User and Key Selection

If a "user@" prefix is used within a SnmpSSHAddress value to specify a 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.



 TOC 

9.4.  Conceptual Differences Between USM and SSHTM

The User Based Security Model [RFC3414] (Blumenthal, U. and B. Wijnen, “User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3),” December 2002.) employed symmetric cryptography and user naming conventions. SSH employs an asymmetric cryptographic 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.



 TOC 

9.5.  The 'none' MAC Algorithm

SSH provides the "none" MAC algorithm, which would allow you to turn off data integrity while maintaining confidentiality. However, if you do this, then an attacker may be able to modify the data in flight, which means you effectively have no authentication.

SSH MUST NOT be configured using the "none" MAC algorithm for use with the SSH Transport Model.



 TOC 

9.6.  Use with SNMPv1/v2c Messages

The SNMPv1 and SNMPv2c message processing described in RFC3584 (BCP 74) [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,” August 2003.) 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.



 TOC 

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:

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] (Case, J., Mundy, R., Partain, D., and B. Stewart, “Introduction and Applicability Statements for Internet-Standard Management Framework,” December 2002.) section 8), including full support for cryptographic mechanisms for authentication and privacy, such as those found in the User-based Security Model [RFC3414] (Blumenthal, U. and B. Wijnen, “User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3),” December 2002.), the Transport Security Model [I‑D.ietf‑isms‑transport‑security‑model] (Harrington, D. and W. Hardaker, “Transport Security Model for SNMP,” May 2009.) 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.



 TOC 

10.  IANA Considerations

IANA is requested to assign:

  1. two TCP registered port numbers in the http://www.iana.org/assignments/port-numbers registry which will be the default ports for SNMP over an SSH Transport Model as defined in this document, and SNMP over an SSH Transport Model for notifications as defined in this document. It would be good if the assigned keywords were "snmpssh" and "snmpssh-trap" and the port numbers were x161 and x162 (where x represents a number, such as '5' or '6', so that we end up with ports 5161 and 5162, or 6161 and 6162).
  2. an SMI number under mib-2, for the MIB module in this document,
  3. an SMI number under snmpDomains, for the snmpSSHDomain,
  4. "ssh" as the corresponding prefix for the snmpSSHDomain in the SNMP Transport Model registry; defined in [I‑D.ietf‑isms‑tmsm] (Harrington, D. and J. Schoenwaelder, “Transport Subsystem for the Simple Network Management Protocol (SNMP),” May 2009.)
  5. "snmp" as an SSH Subsystem Name in the http://www.iana.org/assignments/ssh-parameters registry.

-- note to RFC editor -- Please replace YYY and ZZZ in this document with the assigned port numbers and remove this note.



 TOC 

11.  Acknowledgements

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.



 TOC 

12.  References



 TOC 

12.1. Normative References

[RFC1033] Lottor, M., “Domain administrators operations guide,” RFC 1033, November 1987 (TXT).
[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).
[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., “Structure of Management Information Version 2 (SMIv2),” STD 58, RFC 2578, April 1999 (TXT).
[RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., “Textual Conventions for SMIv2,” STD 58, RFC 2579, April 1999 (TXT).
[RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, “Conformance Statements for SMIv2,” STD 58, RFC 2580, April 1999 (TXT).
[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 (TXT).
[RFC3413] Levi, D., Meyer, P., and B. Stewart, “Simple Network Management Protocol (SNMP) Applications,” STD 62, RFC 3413, December 2002 (TXT).
[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 (TXT).
[RFC3418] Presuhn, R., “Management Information Base (MIB) for the Simple Network Management Protocol (SNMP),” STD 62, RFC 3418, December 2002 (TXT).
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, “Internationalizing Domain Names in Applications (IDNA),” RFC 3490, March 2003 (TXT).
[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 (TXT).
[RFC4251] Ylonen, T. and C. Lonvick, “The Secure Shell (SSH) Protocol Architecture,” RFC 4251, January 2006 (TXT).
[RFC4252] Ylonen, T. and C. Lonvick, “The Secure Shell (SSH) Authentication Protocol,” RFC 4252, January 2006 (TXT).
[RFC4253] Ylonen, T. and C. Lonvick, “The Secure Shell (SSH) Transport Layer Protocol,” RFC 4253, January 2006 (TXT).
[RFC4254] Ylonen, T. and C. Lonvick, “The Secure Shell (SSH) Connection Protocol,” RFC 4254, January 2006 (TXT).
[I-D.ietf-isms-tmsm] Harrington, D. and J. Schoenwaelder, “Transport Subsystem for the Simple Network Management Protocol (SNMP),” draft-ietf-isms-tmsm-18 (work in progress), May 2009 (TXT).


 TOC 

12.2. Informative References

[RFC1994] Simpson, W., “PPP Challenge Handshake Authentication Protocol (CHAP),” RFC 1994, August 1996 (TXT).
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, “Remote Authentication Dial In User Service (RADIUS),” RFC 2865, June 2000 (TXT).
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, “Introduction and Applicability Statements for Internet-Standard Management Framework,” RFC 3410, December 2002 (TXT).
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, “Diameter Base Protocol,” RFC 3588, September 2003 (TXT).
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” STD 66, RFC 3986, January 2005 (TXT, HTML, XML).
[RFC4256] Cusack, F. and M. Forssen, “Generic Message Exchange Authentication for the Secure Shell Protocol (SSH),” RFC 4256, January 2006 (TXT).
[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 (TXT).
[RFC5090] Sterman, B., Sadolevsky, D., Schwartz, D., Williams, D., and W. Beck, “RADIUS Extension for Digest Authentication,” RFC 5090, February 2008 (TXT).
[RFC4742] Wasserman, M. and T. Goddard, “Using the NETCONF Configuration Protocol over Secure SHell (SSH),” RFC 4742, December 2006 (TXT).
[I-D.ietf-isms-transport-security-model] Harrington, D. and W. Hardaker, “Transport Security Model for SNMP,” draft-ietf-isms-transport-security-model-14 (work in progress), May 2009 (TXT).


 TOC 

Authors' Addresses

  David Harrington
  Huawei Technologies (USA)
  1700 Alma Dr. Suite 100
  Plano, TX 75075
  USA
Phone:  +1 603 436 8634
EMail:  dharrington@huawei.com
  
  Joseph Salowey
  Cisco Systems
  2901 3rd Ave
  Seattle, WA 98121
  USA
EMail:  jsalowey@cisco.com
  
  Wes Hardaker
  Sparta, Inc.
  P.O. Box 382
  Davis, CA 95617
  US
Phone:  +1 530 792 1913
EMail:  ietf@hardakers.net