Secure Shell Transport Model for SNMP

By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79.

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

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

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.

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. Privacy Protocol Support
        3.1.5. Protection against Message Replay, Delay and Redirection
        3.1.6. SSH Subsystem
    3.2. Security Parameter Passing
    3.3. Notifications and Proxy
4. Cached Information and References
    4.1. securityStateReference
    4.2. tmStateReference
        4.2.1. Transport information
        4.2.2. securityName
        4.2.3. securityLevel
        4.2.4. Session Information
    4.3. Secure Shell Transport Model Cached Information
        4.3.1. tmSecurityName
        4.3.2. tmSessionID
        4.3.3. session state
5. Elements of Procedure
    5.1. Procedures for an Incoming Message
    5.2. Procedures for 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. noAuthPriv
    9.2. Use with SNMPv1/v2c Messages
    9.3. Skipping Public Key Verification
    9.4. The 'none' MAC Algorithm
    9.5. MIB Module Security
10. IANA Considerations
11. Acknowledgements
12. References
    12.1. Normative References
    12.2. Informative References
Appendix A. Open Issues
Appendix B. Change Log

1. Introduction

1.1. The Internet-Standard Management Framework

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.

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.

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.

1.3. Modularity

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.

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

There are a number of challenges to be addressed to map Secure Shell authentication method parameters into the SNMP architecture so that SNMP continues to work without any surprises. These are discussed in detail below.

1.5. Constraints

The design of this SNMP Transport Model is influenced by the following constraints:

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.

3. How SSHTM Fits into the Transport Subsystem

The SSH Transport Model will establish a channel between itself and the SSH Transport Model of another SNMP engine. The sending transport model passes unencrypted messages from the dispatcher to SSH to be encrypted, and the receiving transport model accepts decrypted incoming messages from SSH and passes them to the dispatcher.

After an SSH Transport model channel is established, then SNMP messages can conceptually be sent through the channel from one SNMP message dispatcher to another SNMP message dispatcher. Multiple SNMP messages MAY be passed through the same channel.

The SSH Transport Model of an SNMP engine will perform the translation between SSH-specific security parameters and SNMP-specific, model-independent parameters.

3.1. Security Capabilities of this Model

3.1.1. Threats

3.1.2. Message Authentication

The SSH Transport Model determines from SSH the identity of the authenticated principal, and the type and address associated with an incoming message, and the SSH Transport Model 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 SSH Transport Model does not know about the algorithms or options to open SSH sessions that match different securityLevels. For interoperability of the trust assumptions between SNMP engines, 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 requested by SNMP applications and specified with a lesser securityLevel (noAuthNoPriv or authNoPriv) are sent by the SSH Transport Model as authPriv securityLevel.

3.1.3. Authentication Protocol Support

3.1.4. Privacy Protocol Support

The SSH transport model supports any privacy protocol used with SSH. [DISCUSS: The authentication support section goes into significant detail; should the same be done here?]

3.1.5. Protection against Message Replay, Delay and Redirection

SSH uses sequence numbers and integrity checks to protect against replay and reordering of messages within a connection.

SSH also provides protection against replay of entire sessions. In a properly-implemented Diffie-Hellman exchange, both sides will generate new random numbers for each exchange, which means the encryption and integrity keys will be distinct for every session.

3.1.6. SSH Subsystem

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 transportAddressType, transportAddress, securityName, and securityLevel associated with each session.

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.

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.

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.

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.

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.

4.1. securityStateReference

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.

4.2. tmStateReference

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:

4.2.1. Transport information

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.

Note that the ASIs used for processing an outgoing message all include explicit transportDomain and transportAddress parameters. These fields within the tmStateReference cache will typically not be used for outgoing messages.

4.2.2. securityName

There are actually three distinct "identities" that can be identified during the processing of an SNMP request over a secure transport:

4.2.3. securityLevel

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:

4.2.4. Session Information

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.

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.

4.3. Secure Shell Transport Model Cached Information

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

4.3.1. tmSecurityName

The tmSecurityName MUST be a human-readable name (in snmpAdminString format) representing the identity that has been authenticated by the SSH layer.

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.

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.

4.3.2. tmSessionID

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.

4.3.3. session state

The per-session state that is referenced by tmStateReference may be saved across multiple messages in a Local Configuration Datastore. Additional session/connection state information might also be stored in a Local Configuration Datastore.

5. Elements of Procedure

Abstract service interfaces have been defined by RFC 3411 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. These RFC 3411-defined data flows are referred to here as public interfaces.

To simplify the elements of procedure, the release of state information is not always explicitly specified. As a general rule, if state information is available when a message gets discarded, the message-state information should also be released, and if state information is available when a session is closed, the session state information should also be released.

An error indication may return an OID and value for an incremented counter and a value for securityLevel, and values for contextEngineID and contextName for the counter, and the securityStateReference if the information is available at the point where the error is detected. ContextEngineID and contextName are not accessible to Transport Models, so contextEngineID is set to the local value of snmpEngineID, and contextName is set to the default context for error counters.

5.1. Procedures for an Incoming Message

1) The SSH Transport Model queries the SSH engine, in an implementation-dependent manner, to determine the transportAddress, the principal name authenticated by SSH, and a session identifier.

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

Then the Transport model passes the message to the Dispatcher using the following ASI:

5.2. Procedures for an Outgoing Message

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. Other implementation dependent steps may also be needed.

5.3. Establishing a Session

The Secure Shell Transport Model provides the following application 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.

1) 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 presented to the ssh server as the "user name" for authentication purposes. This may be different than the passed tmSecurityName value that should 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 are provided in an implementation-dependent manner.

If the attempt to establish a connection is unsuccessful, or server authentication fails, then sshtmSessionOpenErrors is incremented, and an openSession error indication is returned, and openSession processing stops.

2) Create an entry in the LCD containing, at a minimum, a cache of the following information:

3)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 [RFC4252] (Ylonen, T. and C. Lonvick, “The Secure Shell (SSH) Authentication Protocol,” January 2006.). The credentials used to authenticate the user 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.

5) After the ssh-connection service is established, the client will 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.

6) If successful, this will result in an SSH session. Store the session identifier in the corresponding LCD entry. Increment the sshtmSessionOpens counter.

7) Once the SSH session has been established, the client will invoke SNMP as an SSH subsystem, as indicated in the "subsystem" parameter.

In order to allow SNMP traffic to be easily identified and filtered by firewalls and other network devices, servers associated with SNMP entities using the Secure Shell Transport Model MUST default to providing access to the "SNMP" SSH subsystem if the SSH session is established using the IANA-assigned TCP port. Servers SHOULD be configurable to allow access to the SNMP SSH subsystem over other ports.

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

6. MIB Module Overview

This MIB module provides management of the Secure Shell Transport Model. It defines some needed textual conventions, and some statistics.

6.1. Structure of the MIB Module

Objects in this MIB module are arranged into subtrees. Each subtree is organized as a set of related objects. The overall structure and assignment of objects to their subtrees, and the intended purpose of each subtree, is shown below.

6.2. Textual Conventions

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

6.3. Relationship to Other MIB Modules

This MIB module is for managing SSH Transport Model information. This MIB module models a sample Local Configuration Datastore for the Transport Model (not for SSH or an associated security model).

6.3.1. MIB Modules Required for IMPORTS

7. MIB Module Definition

SSHTM-MIB DEFINITIONS ::= BEGIN

IMPORTS
    MODULE-IDENTITY, OBJECT-TYPE,
    OBJECT-IDENTITY, mib-2, snmpDomains,
    Counter32
      FROM SNMPv2-SMI
    TEXTUAL-CONVENTION
      FROM SNMPv2-TC
    MODULE-COMPLIANCE, OBJECT-GROUP
      FROM SNMPv2-CONF
    ;

sshtmMIB MODULE-IDENTITY
    LAST-UPDATED "200710140000Z"
    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@iu-bremen.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) The IETF Trust (2007). 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     "200710140000Z"
    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
-- ---------------------------------------------------------- --

sshtmNotifications    OBJECT IDENTIFIER ::= { sshtmMIB 0 }
sshtmObjects          OBJECT IDENTIFIER ::= { sshtmMIB 1 }
sshtmConformance      OBJECT IDENTIFIER ::= { sshtmMIB 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 what secure transport
         infrastructure authenticated a securityName. For further
         details on the usage of this prefix, see the
         [I-D.ietf-isms-tmsm-transport-security-model]
         document and the snmpTsmConfigurationUsePrefix in the
         SNMP-TSM-MIB."
    ::= { snmpDomains yy }

-- RFC Ed.: Please replace the I-D reference with a proper one once it
-- has been published. Note: xml2rfc doesn't handle refs within artwork

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

         The beginning of the address specification may contain a
         username followed by an '@' (ASCII character 0x40). This
         portion of the address will indicate the user name that should
         be used when authenticating to an SSH server. If missing, the
         SNMP securityName should be used. After the optional user name
         field and '@' character comes the hostname.

         The hostname must be encoded in ASCII, as specified in
         RFC3490 (Internationalizing Domain Names in Applications)
         followed by a colon ':' (ASCII character 0x3A) and a
         decimal port number in ASCII. The name SHOULD be fully
         qualified whenever possible.

         An IPv4 address must be a dotted decimal format followed
         by a colon ':' (ASCII character 0x3A) and a decimal port
         number in ASCII.

         An IPv6 address must be a colon separated format, surrounded by
         brackets ('[' ASCII character 0x5B and ']' ASCII character
         0x5D), followed by a colon ':' (ASCII character 0x3A) and a
         decimal port number in ASCII.

         Values of this textual convention may 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
      "RFC3896, Uniform Resource Identifier (URI): Generic Syntax"
    SYNTAX      OCTET STRING (SIZE (1..255))


-- The sshtmSession Group

sshtmSession          OBJECT IDENTIFIER ::= { sshtmObjects 1 }

sshtmSessionOpens  OBJECT-TYPE
    SYNTAX       Counter32
    MAX-ACCESS   read-only
    STATUS       current
    DESCRIPTION "The number of times an openSession() request has been
                 executed, whether it succeeded or failed.
                "
    ::= { sshtmSession 1 }

sshtmSessionCloses  OBJECT-TYPE
    SYNTAX       Counter32
    MAX-ACCESS   read-only
    STATUS       current
    DESCRIPTION "The number of times a closeSession() request has been
                 executed, whether it succeeded or failed.
                "
    ::= { sshtmSession 2 }

sshtmSessionOpenErrors  OBJECT-TYPE
    SYNTAX       Counter32
    MAX-ACCESS   read-only
    STATUS       current
    DESCRIPTION "The number of times an openSession() request
                 failed to open a Session, for any reason.
                "
    ::= { sshtmSession 3 }

sshtmSessionUserAuthFailures  OBJECT-TYPE
    SYNTAX       Counter32
    MAX-ACCESS   read-only
    STATUS       current
    DESCRIPTION "The number of times an openSession() request
                 failed due to user authentication failures.
                "
    ::= { sshtmSession 4 }

sshtmSessionChannelOpenFailures  OBJECT-TYPE
    SYNTAX       Counter32
    MAX-ACCESS   read-only
    STATUS       current
    DESCRIPTION "The number of times an openSession() request
                 failed due to channel open failures.
                "
    ::= { sshtmSession 5 }

sshtmSessionNoAvailableSessions  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.
                "
    ::= { sshtmSession 6 }

-- ************************************************
-- sshtmMIB - Conformance Information
-- ************************************************

sshtmCompliances OBJECT IDENTIFIER ::= { sshtmConformance 1 }

sshtmGroups      OBJECT IDENTIFIER ::= { sshtmConformance 2 }

-- ************************************************
-- Compliance statements
-- ************************************************

sshtmCompliance MODULE-COMPLIANCE
    STATUS      current

    DESCRIPTION "The compliance statement for SNMP engines that
                 support the SNMP-SSH-TM-MIB"
    MODULE
        MANDATORY-GROUPS { sshtmGroup }
    ::= { sshtmCompliances 1 }

-- ************************************************
-- Units of conformance
-- ************************************************
sshtmGroup OBJECT-GROUP
    OBJECTS {
      sshtmSessionOpens,
      sshtmSessionCloses,
      sshtmSessionOpenErrors,
      sshtmSessionUserAuthFailures,
      sshtmSessionChannelOpenFailures,
      sshtmSessionNoAvailableSessions
    }
    STATUS      current
    DESCRIPTION "A collection of objects for maintaining
                 information of an SNMP engine which implements the
                 SNMP Secure Shell Transport Model.
                "


    ::= { sshtmGroups 2 }


END

8. Operational Considerations

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 a local authentication mechanisms, such as local passwords, so SNMP can continue operating during times of network stress.

The SSH protocol has its own windowing mechanism. RFC 4254 says: The window size specifies how many bytes the other party can send before it must wait for the window to be adjusted. Both parties use the following message to adjust the window. The SSH specifications leave it open when such window adjustment messages are created. Some implementations have been found to send window adjustment messages whenever received data has been passed to the application. Since window adjustment messages are padded, encrypted, hmac'ed, and wrapped, this results in noticeable bandwidth and processing overhead, which can be avoided by sending window adjustment messages 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 and 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 to be SSH clients. How this credential configuration is done is implementation and deployment specific. A scalable IETF standard protocol for configuration or key management is RECOMMENDED.

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. While SSH does support turning off confidentiality and integrity, they SHOULD NOT be turned off when used with the SSH Transport Model.

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

9.1. noAuthPriv

SSH provides the "none" userauth method, which is normally rejected by servers and used only to find out what userauth methods are supported. However, it is legal for a server to accept this method, which has the effect of not authenticating the SSH client to the SSH server. Doing this does not compromise authentication of the SSH server to the SSH client, nor does it compromise data confidentiality or data integrity.

SSH supports anonymous access. If the SSH Transport Model can extract from SSH an authenticated principal to map to securityName, then anonymous access SHOULD be supported. It is possible for SSH to skip entity authentication of the client through the "none" authentication method to support anonymous clients, however in this case an implementation MUST still support data integrity within the SSH transport protocol and provide an authenticated principal for mapping to securityName for access control purposes.

The RFC 3411 architecture does not permit noAuthPriv. The SSH Transport Model SHOULD NOT be used with an SSH connection with the "none" userauth method.

9.2. Use with SNMPv1/v2c Messages

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

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

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

Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them.

10. IANA Considerations

11. Acknowledgements

The editors would like to thank Jeffrey Hutzelman for sharing his SSH insights, and Dave Shields for an outstanding job wordsmithing the existing document to improve organization and clarity.

12. References

12.1. Normative References

12.2. Informative References

Appendix A. Open Issues

Here is the current list of issues from the SSH Transport Model document where we need to reach consensus.

Appendix B. Change Log

Authors' Addresses

Full Copyright Statement

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

[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).
[RFC2865]	Rigney, C., Willens, S., Rubens, A., and W. Simpson, “Remote Authentication Dial In User Service (RADIUS),” RFC 2865, June 2000 (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).

[RFC1994]	Simpson, W., “PPP Challenge Handshake Authentication Protocol (CHAP),” RFC 1994, August 1996 (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).

	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

Secure Shell Transport Model for SNMPdraft-ietf-isms-secshell-12

Status of This Memo