[Docs] [txt|pdf|xml|html] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-harrington-isms-secshell) 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 RFC 5592

Network Working Group                                      D. Harrington
Internet-Draft                                 Huawei Technologies (USA)
Intended status: Standards Track                              J. Salowey
Expires: October 29, 2009                                  Cisco Systems
                                                             W. Hardaker
                                                            Sparta, Inc.
                                                          April 27, 2009


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

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 October 29, 2009.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the



Harrington, et al.      Expires October 29, 2009                [Page 1]

Internet-Draft    Secure Shell Transport Model for SNMP       April 2009


   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 . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  The Internet-Standard Management Framework . . . . . . . .  4
     1.2.  Conventions  . . . . . . . . . . . . . . . . . . . . . . .  4
     1.3.  Modularity . . . . . . . . . . . . . . . . . . . . . . . .  5
     1.4.  Motivation . . . . . . . . . . . . . . . . . . . . . . . .  6
     1.5.  Constraints  . . . . . . . . . . . . . . . . . . . . . . .  7
   2.  The Secure Shell Protocol  . . . . . . . . . . . . . . . . . .  7
   3.  How SSHTM Fits into the Transport Subsystem  . . . . . . . . .  8
     3.1.  Security Capabilities of this Model  . . . . . . . . . . .  9
       3.1.1.  Threats  . . . . . . . . . . . . . . . . . . . . . . .  9
       3.1.2.  Message Authentication . . . . . . . . . . . . . . . . 10
       3.1.3.  Authentication Protocol Support  . . . . . . . . . . . 11
       3.1.4.  SSH Subsystem  . . . . . . . . . . . . . . . . . . . . 11
     3.2.  Security Parameter Passing . . . . . . . . . . . . . . . . 12
     3.3.  Notifications and Proxy  . . . . . . . . . . . . . . . . . 12
   4.  Cached Information and References  . . . . . . . . . . . . . . 13
     4.1.  Secure Shell Transport Model Cached Information  . . . . . 13
       4.1.1.  tmSecurityName . . . . . . . . . . . . . . . . . . . . 14
       4.1.2.  tmSessionID  . . . . . . . . . . . . . . . . . . . . . 14
       4.1.3.  Session State  . . . . . . . . . . . . . . . . . . . . 15
   5.  Elements of Procedure  . . . . . . . . . . . . . . . . . . . . 15
     5.1.  Procedures for an Incoming Message . . . . . . . . . . . . 15
     5.2.  Procedures for sending an Outgoing Message . . . . . . . . 17
     5.3.  Establishing a Session . . . . . . . . . . . . . . . . . . 18
     5.4.  Closing a Session  . . . . . . . . . . . . . . . . . . . . 20
   6.  MIB Module Overview  . . . . . . . . . . . . . . . . . . . . . 21
     6.1.  Structure of the MIB Module  . . . . . . . . . . . . . . . 21
     6.2.  Textual Conventions  . . . . . . . . . . . . . . . . . . . 21



Harrington, et al.      Expires October 29, 2009                [Page 2]

Internet-Draft    Secure Shell Transport Model for SNMP       April 2009


     6.3.  Relationship to Other MIB Modules  . . . . . . . . . . . . 21
       6.3.1.  MIB Modules Required for IMPORTS . . . . . . . . . . . 21
   7.  MIB Module Definition  . . . . . . . . . . . . . . . . . . . . 22
   8.  Operational Considerations . . . . . . . . . . . . . . . . . . 29
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 30
     9.1.  Skipping Public Key Verification . . . . . . . . . . . . . 30
     9.2.  Notification Authorizaton Considerations . . . . . . . . . 31
     9.3.  SSH User and Key Selection . . . . . . . . . . . . . . . . 31
     9.4.  Conceptual Differences Between USM and SSHTM . . . . . . . 31
     9.5.  The 'none' MAC Algorithm . . . . . . . . . . . . . . . . . 32
     9.6.  Use with SNMPv1/v2c Messages . . . . . . . . . . . . . . . 32
     9.7.  MIB Module Security  . . . . . . . . . . . . . . . . . . . 32
   10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 33
   11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 33
   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34
     12.1. Normative References . . . . . . . . . . . . . . . . . . . 34
     12.2. Informative References . . . . . . . . . . . . . . . . . . 36
   Appendix A.  Change Log  . . . . . . . . . . . . . . . . . . . . . 37

































Harrington, et al.      Expires October 29, 2009                [Page 3]

Internet-Draft    Secure Shell Transport Model for SNMP       April 2009


1.  Introduction

   This memo describes a Transport Model for the Simple Network
   Management Protocol, using the Secure Shell protocol (SSH) [RFC4251]
   within a transport subsystem [I-D.ietf-isms-tmsm].  The transport
   model specified in this memo is referred to as the Secure Shell
   Transport Model (SSHTM).

   This memo also defines a portion of the Management Information Base
   (MIB) for use with network management protocols in TCP/IP based
   internets.  In particular it defines objects for monitoring and
   managing the Secure Shell Transport Model for SNMP.

   It is important to understand the SNMP architecture [RFC3411] and the
   terminology of the architecture to understand where the Transport
   Model described in this memo fits into the architecture and interacts
   with other subsystems within the architecture.

1.1.  The Internet-Standard Management Framework

   For a detailed overview of the documents that describe the current
   Internet-Standard Management Framework, please refer to section 7 of
   RFC 3410 [RFC3410].

   Managed objects are accessed via a virtual information store, termed
   the Management Information Base or MIB.  MIB objects are generally
   accessed through the Simple Network Management Protocol (SNMP).
   Objects in the MIB are defined using the mechanisms defined in the
   Structure of Management Information (SMI).  This memo specifies a MIB
   module that is compliant to the SMIv2, which is described in STD 58,
   RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580
   [RFC2580].

1.2.  Conventions

   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], all SNMP entities



Harrington, et al.      Expires October 29, 2009                [Page 4]

Internet-Draft    Secure Shell Transport Model for SNMP       April 2009


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

   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

   The reader is expected to have read and understood the description of
   the SNMP architecture, as defined in [RFC3411], and the Transport
   Subsystem architecture extension specified in "Transport Subsystem
   for the Simple Network Management Protocol" [I-D.ietf-isms-tmsm].

   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



Harrington, et al.      Expires October 29, 2009                [Page 5]

Internet-Draft    Secure Shell Transport Model for SNMP       April 2009


   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] 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].  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].  The SSH
   Transport Model SHOULD be able to take advantage of future defined



Harrington, et al.      Expires October 29, 2009                [Page 6]

Internet-Draft    Secure Shell Transport Model for SNMP       April 2009


   ssh-userauth methods, such as those that might make use of X.509
   certificate credentials.

   It is desirable to use mechanisms that could unify the approach for
   administrative security for SNMPv3 and Command Line interfaces (CLI)
   and other management interfaces.  The use of security services
   provided by Secure Shell is the approach commonly used for the CLI,
   and is the approach being adopted for use with NETCONF [RFC4742].
   This memo describes a method for invoking and running the SNMP
   protocol within a Secure Shell (SSH) session as an SSH subsystem.

   This memo describes how SNMP can be used within a Secure Shell (SSH)
   session, using the SSH connection protocol [RFC4254] over the SSH
   transport protocol, using SSH user-auth [RFC4252] for authentication.

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

1.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 require no changes to the SNMP
       architecture.

   5.  A transport model should require no changes to the underlying
       protocol.

2.  The Secure Shell Protocol

   SSH is a protocol for secure remote login and other secure network
   services over an insecure network.  It consists of three major
   protocol components, and add-on methods for user authentication:



Harrington, et al.      Expires October 29, 2009                [Page 7]

Internet-Draft    Secure Shell Transport Model for SNMP       April 2009


   o  The Transport Layer Protocol [RFC4253] provides server
      authentication, and message confidentiality and integrity.  It may
      optionally also provide compression.  The transport layer will
      typically be run over a TCP/IP connection, but might also be used
      on top of any other reliable data stream.

   o  The User Authentication Protocol [RFC4252] authenticates the
      client-side principal to the server.  It runs over the transport
      layer protocol.

   o  The Connection Protocol [RFC4254] multiplexes the encrypted tunnel
      into several logical channels.  It runs over the transport after
      successfully authenticating the principal.

   o  Generic Message Exchange Authentication [RFC4256] is a general
      purpose authentication method for the SSH protocol, suitable for
      interactive authentications where the authentication data should
      be entered via a keyboard

   o  Generic Security Service Application Program Interface (GSS-API)
      Authentication and Key Exchange for the Secure Shell (SSH)
      Protocol [RFC4462] describes methods for using the GSS-API for
      authentication and key exchange in SSH.  It defines an SSH user
      authentication method that uses a specified GSS-API mechanism to
      authenticate a user, and a family of SSH key exchange methods that
      use GSS-API to authenticate a Diffie-Hellman key exchange.

   The client sends a service request once a secure transport layer
   connection has been established.  A second service request is sent
   after client authentication is complete.  This allows new protocols
   to be defined and coexist with the protocols listed above.

   The connection protocol provides channels that can be used for a wide
   range of purposes.  Standard methods are provided for setting up
   secure interactive shell sessions and for forwarding ("tunneling")
   arbitrary TCP/IP ports and X11 connections.

3.  How SSHTM Fits into the Transport Subsystem

   A transport model is a component of the Transport Subsystem
   [I-D.ietf-isms-tmsm] within the SNMP architecture.  The SSH Transport
   Model thus fits between the underlying SSH transport layer and the
   message dispatcher [RFC3411].

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



Harrington, et al.      Expires October 29, 2009                [Page 8]

Internet-Draft    Secure Shell Transport Model for SNMP       April 2009


   decrypted incoming messages from SSH and passes them to the
   dispatcher.

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

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

3.1.  Security Capabilities of this Model

3.1.1.  Threats

   The Secure Shell Transport Model provides protection against the
   threats identified by the RFC 3411 architecture [RFC3411]:

   1.  Modification of Information - SSH provides for verification that
       the contents of each message 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].  This allows an operator or management station to
       ensure the authenticity of the SNMP engine that provides MIB
       data.

       SSH provides a number of mechanisms for verification of the
       identity of the SSH client-side principal, using the Secure Shell
       Authentication Protocol [RFC4252].  These include public key,
       password and host-based mechanisms.  This allows the SNMP access
       control subsystem to ensure that only authorized principals have
       access to potentially sensitive data.

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



Harrington, et al.      Expires October 29, 2009                [Page 9]

Internet-Draft    Secure Shell Transport Model for SNMP       April 2009


   3.  Message Stream Modification - SSH protects against malicious re-
       ordering or replaying of messages within a single SSH session by
       using sequence numbers and integrity checks.  SSH protects
       against replay of messages across SSH sessions by ensuring that
       the cryptographic keys used for encryption and integrity checks
       are generated afresh for each session.

   4.  Disclosure - SSH provides protection against the disclosure of
       information to unauthorized recipients or eavesdroppers by
       allowing for encryption of all traffic between SNMP engines.

3.1.2.  Message Authentication

   The RFC 3411 architecture recognizes three levels of security:

      - without authentication and without privacy (noAuthNoPriv)

      - with authentication but without privacy (authNoPriv)

      - with authentication and with privacy (authPriv)

   The Secure Shell protocol provides support for encryption and data
   integrity.  While it is technically possible to support no
   authentication and no encryption in SSH it is NOT RECOMMENDED by
   [RFC4253].

   The SSH Transport Model determines from SSH the identity of the
   authenticated principal, and the type and address associated with an
   incoming message, and provides this information to SSH for an
   outgoing message.  The transport layer algorithms used to provide
   authentication, data integrity and encryption SHOULD NOT be exposed
   to the SSH Transport Model layer.  The SNMPv3 WG deliberately avoided
   this and settled for an assertion by the security model that the
   requirements of securityLevel were met The SSH Transport Model has no
   mechanisms by which it can test whether an underlying SSH connection
   provides auth or priv, so the SSH Transport Model trusts that the
   underlying SSH connection has been properly configured to support
   authPriv security characteristics.

   An SSH Transport Model-compliant implementation MUST use an SSH
   connection that provides authentication, data integrity and
   encryption that meets the highest level of SNMP security (authPriv).
   Outgoing messages specified with a securityLevel of noAuthNoPriv or
   authNoPriv, are actually sent by the SSH Transport Model with
   authPriv-level protection.

   The security protocols used in the Secure Shell Authentication
   Protocol [RFC4252] and the Secure Shell Transport Layer Protocol



Harrington, et al.      Expires October 29, 2009               [Page 10]

Internet-Draft    Secure Shell Transport Model for SNMP       April 2009


   [RFC4253] are considered acceptably secure at the time of writing.
   However, the procedures allow for new authentication and privacy
   methods to be specified at a future time if the need arises.

3.1.3.  Authentication Protocol Support

   The SSH Transport Model should support any server or client
   authentication mechanism supported by SSH.  This includes the three
   authentication methods described in the SSH Authentication Protocol
   document [RFC4252] - publickey, password, and host-based - 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] or Diameter [RFC3588]
   for validation.  The validation could be done using the user-name and
   user-password attributes.  It is also possible to use a different
   password validation protocol such as CHAP [RFC1994] or digest
   authentication [RFC5090] 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] 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.

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.




Harrington, et al.      Expires October 29, 2009               [Page 11]

Internet-Draft    Secure Shell Transport Model for SNMP       April 2009


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

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



Harrington, et al.      Expires October 29, 2009               [Page 12]

Internet-Draft    Secure Shell Transport Model for SNMP       April 2009


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

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

4.1.  Secure Shell Transport Model Cached Information

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



Harrington, et al.      Expires October 29, 2009               [Page 13]

Internet-Draft    Secure Shell Transport Model for SNMP       April 2009


   tmStateReference fields by the SSH Transport Model.

4.1.1.  tmSecurityName

   The tmSecurityName MUST be a human-readable name (in snmpAdminString
   format) representing the identity that has been set according to the
   procedures in Section 5.  The tmSecurityName MUST be constant for all
   traffic passing through an SSHTM session.  Messages MUST NOT be sent
   through an existing SSH session that was established using a
   different tmSecurityName.

   On the SSH server side of a connection:

      The tmSecurityName SHOULD be the SSH user name.  How the SSH user
      name is extracted from the SSH layer is implementation-dependent.

      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.  Transport models SHOULD generate a predictable
   tmSecurityName.

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






Harrington, et al.      Expires October 29, 2009               [Page 14]

Internet-Draft    Secure Shell Transport Model for SNMP       April 2009


4.1.3.  Session State

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

5.  Elements of Procedure

   Abstract service interfaces have been defined by [RFC3411] and
   further augmented by [I-D.ietf-isms-tmsm] 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.

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



Harrington, et al.      Expires October 29, 2009               [Page 15]

Internet-Draft    Secure Shell Transport Model for SNMP       April 2009


           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 (e.g. 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 (e.g. 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
          3.

          tmSecurityName = The derived tmSecurityName from step 2.

          tmTransportSecurityLevel = "authPriv" (authentication and
          confidentiality MUST be used to comply with this transport
          model.)





Harrington, et al.      Expires October 29, 2009               [Page 16]

Internet-Draft    Secure Shell Transport Model for SNMP       April 2009


          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
    )

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.





Harrington, et al.      Expires October 29, 2009               [Page 17]

Internet-Draft    Secure Shell Transport Model for SNMP       April 2009


   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.

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
    )




Harrington, et al.      Expires October 29, 2009               [Page 18]

Internet-Draft    Secure Shell Transport Model for SNMP       April 2009


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

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

       1.  If the tmTransportAddress field contains a user-name followed
           by an '@' character (ASCII 0x40), that user-name string that
           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.



Harrington, et al.      Expires October 29, 2009               [Page 19]

Internet-Draft    Secure Shell Transport Model for SNMP       April 2009


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

5.4.  Closing a Session

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

   statusInformation =
   closeSession(
   IN   tmSessionID     -- transport address to be used
   )



   The following describes the procedure to follow to close a session



Harrington, et al.      Expires October 29, 2009               [Page 20]

Internet-Draft    Secure Shell Transport Model for SNMP       April 2009


   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.

6.  MIB Module Overview

   This MIB module provides management of the Secure Shell Transport
   Model.  It defines an OID to identify the SNMP-over-SSH transport
   domain, a textual convention for SSH Addresses and several statistics
   counters.

6.1.  Structure of the MIB Module

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

6.2.  Textual Conventions

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

6.3.  Relationship to Other MIB Modules

   Some management objects defined in other MIB modules are applicable
   to an entity implementing the SSH Transport Model.  In particular, it
   is assumed that an entity implementing the SNMP-SSH-TM-MIB will
   implement the SNMPv2-MIB [RFC3418], and the SNMP-FRAMEWORK-MIB
   [RFC3411].  It is expected that an entity implementing this MIB will
   also support the Transport Security Model
   [I-D.ietf-isms-transport-security-model], and therefore implement the
   SNMP-TSM-MIB.

   This MIB module is for monitoring SSH Transport Model information.

6.3.1.  MIB Modules Required for IMPORTS

   The following MIB module imports items from [RFC2578], [RFC2579],
   [RFC2580].



Harrington, et al.      Expires October 29, 2009               [Page 21]

Internet-Draft    Secure Shell Transport Model for SNMP       April 2009


   This MIB module also references [RFC3490] and [RFC3986]

   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.

7.  MIB Module Definition


SNMP-SSH-TM-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
    ;

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@iu-bremen.de

                  Co-editors:
                     David Harrington



Harrington, et al.      Expires October 29, 2009               [Page 22]

Internet-Draft    Secure Shell Transport Model for SNMP       April 2009


                     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



Harrington, et al.      Expires October 29, 2009               [Page 23]

Internet-Draft    Secure Shell Transport Model for SNMP       April 2009


    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



Harrington, et al.      Expires October 29, 2009               [Page 24]

Internet-Draft    Secure Shell Transport Model for SNMP       April 2009


         models or other components to identify what secure transport
         infrastructure authenticated a securityName."
    ::= { snmpDomains yy }

-- RFC Ed.: Please replace the I-D reference with a proper one once it
-- has been published.

-- 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 or IP address.

         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 in dotted decimal format followed
         by a colon ':' (ASCII character 0x3A) and a decimal port
         number in ASCII.

         An IPv6 address must be in colon separated format, surrounded
         by square 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 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).



Harrington, et al.      Expires October 29, 2009               [Page 25]

Internet-Draft    Secure Shell Transport Model for SNMP       April 2009


         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
      "RFC3986, Uniform Resource Identifier (URI): Generic Syntax"
    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.



Harrington, et al.      Expires October 29, 2009               [Page 26]

Internet-Draft    Secure Shell Transport Model for SNMP       April 2009


                "
    ::= { 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



Harrington, et al.      Expires October 29, 2009               [Page 27]

Internet-Draft    Secure Shell Transport Model for SNMP       April 2009


                 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



Harrington, et al.      Expires October 29, 2009               [Page 28]

Internet-Draft    Secure Shell Transport Model for SNMP       April 2009


    }
    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


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.

   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



Harrington, et al.      Expires October 29, 2009               [Page 29]

Internet-Draft    Secure Shell Transport Model for SNMP       April 2009


   client.  How this credential configuration is done is implementation
   and deployment specific.

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

   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.

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



Harrington, et al.      Expires October 29, 2009               [Page 30]

Internet-Draft    Secure Shell Transport Model for SNMP       April 2009


   public key a priori and to verify that the correct key is being used.
   If this step is skipped, then authentication of the SSH server to the
   SSH client is not done.  Data confidentiality and data integrity
   protection to the server still exist, but these are of dubious value
   when an attacker can insert himself between the client and the real
   SSH server.  Note that some userauth methods may defend against this
   situation, but many of the common ones (including password and
   keyboard-interactive) do not, and in fact depend on the fact that the
   server's identity has been verified (so passwords are not disclosed
   to an attacker).

   SSH MUST NOT be configured to skip public key verification for use
   with the SSH Transport Model.

9.2.  Notification Authorizaton 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.

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.

9.4.  Conceptual Differences Between USM and SSHTM

   The User Based Security Model [RFC3414] employed symmetric
   cryptography and user naming conventions.  SSH employs an asymmetric
   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.







Harrington, et al.      Expires October 29, 2009               [Page 31]

Internet-Draft    Secure Shell Transport Model for SNMP       April 2009


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.

9.6.  Use with SNMPv1/v2c Messages

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

9.7.  MIB Module Security

   There are no management objects defined in this MIB module that have
   a MAX-ACCESS clause of read-write and/or read-create.  So, if this
   MIB module is implemented correctly, then there is no risk that an
   intruder can alter or create any management objects of this MIB
   module via direct SNMP SET operations.

   Some of the readable objects in this MIB module (i.e., objects with a
   MAX-ACCESS other than not-accessible) may be considered sensitive or
   vulnerable in some network environments.  It is thus important to
   control even GET and/or NOTIFY access to these objects and possibly
   to even encrypt the values of these objects when sending them over
   the network via SNMP.  These are the tables and objects and their
   sensitivity/vulnerability:

   o  The readable objects in this MIB module are not sensitive.

   SNMP versions prior to SNMPv3 did not include adequate security.
   Even if the network itself is secure (for example by using IPSec or
   SSH), even then, there is no control as to who on the secure network
   is allowed to access and GET/SET (read/change/create/delete) the
   objects in this MIB module.

   It is RECOMMENDED that implementers consider the security features as
   provided by the SNMPv3 framework (see [RFC3410] section 8), including



Harrington, et al.      Expires October 29, 2009               [Page 32]

Internet-Draft    Secure Shell Transport Model for SNMP       April 2009


   full support for the USM and the SSH Transport Model cryptographic
   mechanisms (for authentication and privacy).

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

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.

   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]

   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.

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.

12.  References





Harrington, et al.      Expires October 29, 2009               [Page 33]

Internet-Draft    Secure Shell Transport Model for SNMP       April 2009


12.1.  Normative References

   [RFC2119]                                 Bradner, S., "Key words for
                                             use in RFCs to Indicate
                                             Requirement Levels",
                                             BCP 14, RFC 2119,
                                             March 1997.

   [RFC2578]                                 McCloghrie, K., Ed.,
                                             Perkins, D., Ed., and J.
                                             Schoenwaelder, Ed.,
                                             "Structure of Management
                                             Information Version 2
                                             (SMIv2)", STD 58, RFC 2578,
                                             April 1999.

   [RFC2579]                                 McCloghrie, K., Ed.,
                                             Perkins, D., Ed., and J.
                                             Schoenwaelder, Ed.,
                                             "Textual Conventions for
                                             SMIv2", STD 58, RFC 2579,
                                             April 1999.

   [RFC2580]                                 McCloghrie, K., Perkins,
                                             D., and J. Schoenwaelder,
                                             "Conformance Statements for
                                             SMIv2", STD 58, RFC 2580,
                                             April 1999.

   [RFC2865]                                 Rigney, C., Willens, S.,
                                             Rubens, A., and W. Simpson,
                                             "Remote Authentication Dial
                                             In User Service (RADIUS)",
                                             RFC 2865, June 2000.

   [RFC3411]                                 Harrington, D., Presuhn,
                                             R., and B. Wijnen, "An
                                             Architecture for Describing
                                             Simple Network Management
                                             Protocol (SNMP) Management
                                             Frameworks", STD 62,
                                             RFC 3411, December 2002.

   [RFC3413]                                 Levi, D., Meyer, P., and B.
                                             Stewart, "Simple Network
                                             Management Protocol (SNMP)
                                             Applications", STD 62,
                                             RFC 3413, December 2002.



Harrington, et al.      Expires October 29, 2009               [Page 34]

Internet-Draft    Secure Shell Transport Model for SNMP       April 2009


   [RFC3414]                                 Blumenthal, U. and B.
                                             Wijnen, "User-based
                                             Security Model (USM) for
                                             version 3 of the Simple
                                             Network Management Protocol
                                             (SNMPv3)", STD 62,
                                             RFC 3414, December 2002.

   [RFC3418]                                 Presuhn, R., "Management
                                             Information Base (MIB) for
                                             the Simple Network
                                             Management Protocol
                                             (SNMP)", STD 62, RFC 3418,
                                             December 2002.

   [RFC3490]                                 Faltstrom, P., Hoffman, P.,
                                             and A. Costello,
                                             "Internationalizing Domain
                                             Names in Applications
                                             (IDNA)", RFC 3490,
                                             March 2003.

   [RFC3584]                                 Frye, R., Levi, D.,
                                             Routhier, S., and B.
                                             Wijnen, "Coexistence
                                             between Version 1, Version
                                             2, and Version 3 of the
                                             Internet-standard Network
                                             Management Framework",
                                             BCP 74, RFC 3584,
                                             August 2003.

   [RFC4251]                                 Ylonen, T. and C. Lonvick,
                                             "The Secure Shell (SSH)
                                             Protocol Architecture",
                                             RFC 4251, January 2006.

   [RFC4252]                                 Ylonen, T. and C. Lonvick,
                                             "The Secure Shell (SSH)
                                             Authentication Protocol",
                                             RFC 4252, January 2006.

   [RFC4253]                                 Ylonen, T. and C. Lonvick,
                                             "The Secure Shell (SSH)
                                             Transport Layer Protocol",
                                             RFC 4253, January 2006.

   [RFC4254]                                 Ylonen, T. and C. Lonvick,



Harrington, et al.      Expires October 29, 2009               [Page 35]

Internet-Draft    Secure Shell Transport Model for SNMP       April 2009


                                             "The Secure Shell (SSH)
                                             Connection Protocol",
                                             RFC 4254, January 2006.

   [I-D.ietf-isms-tmsm]                      Harrington, D. and J.
                                             Schoenwaelder, "Transport
                                             Subsystem for the Simple
                                             Network Management Protocol
                                             (SNMP)",
                                             draft-ietf-isms-tmsm-16
                                             (work in progress),
                                             February 2009.

12.2.  Informative References

   [RFC1994]                                 Simpson, W., "PPP Challenge
                                             Handshake Authentication
                                             Protocol (CHAP)", RFC 1994,
                                             August 1996.

   [RFC3410]                                 Case, J., Mundy, R.,
                                             Partain, D., and B.
                                             Stewart, "Introduction and
                                             Applicability Statements
                                             for Internet-Standard
                                             Management Framework",
                                             RFC 3410, December 2002.

   [RFC3588]                                 Calhoun, P., Loughney, J.,
                                             Guttman, E., Zorn, G., and
                                             J. Arkko, "Diameter Base
                                             Protocol", RFC 3588,
                                             September 2003.

   [RFC3986]                                 Berners-Lee, T., Fielding,
                                             R., and L. Masinter,
                                             "Uniform Resource
                                             Identifier (URI): Generic
                                             Syntax", STD 66, RFC 3986,
                                             January 2005.

   [RFC4256]                                 Cusack, F. and M. Forssen,
                                             "Generic Message Exchange
                                             Authentication for the
                                             Secure Shell Protocol
                                             (SSH)", RFC 4256,
                                             January 2006.




Harrington, et al.      Expires October 29, 2009               [Page 36]

Internet-Draft    Secure Shell Transport Model for SNMP       April 2009


   [RFC4462]                                 Hutzelman, J., Salowey, J.,
                                             Galbraith, J., and V.
                                             Welch, "Generic Security
                                             Service Application Program
                                             Interface (GSS-API)
                                             Authentication and Key
                                             Exchange for the Secure
                                             Shell (SSH) Protocol",
                                             RFC 4462, May 2006.

   [RFC5090]                                 Sterman, B., Sadolevsky,
                                             D., Schwartz, D., Williams,
                                             D., and W. Beck, "RADIUS
                                             Extension for Digest
                                             Authentication", RFC 5090,
                                             February 2008.

   [RFC4742]                                 Wasserman, M. and T.
                                             Goddard, "Using the NETCONF
                                             Configuration Protocol over
                                             Secure SHell (SSH)",
                                             RFC 4742, December 2006.

   [I-D.ietf-isms-transport-security-model]  Harrington, D. and W.
                                             Hardaker, "Transport
                                             Security Model for SNMP", d
                                             raft-ietf-isms-transport-
                                             security-model-12 (work in
                                             progress), March 2009.

Appendix A.  Change Log

   Changes from -15- to -16-

   o  updated MIB copyright

   o  renamed SSHTM-MIB to SNMP-SSH-TM-MIB, which required:

      *  renaming the module identity from sshtmMIB to snmpSshtmMIB

      *  renaming the prefixes for all objects from sshtmXXXX to
         snmpSshtmXXXX

   From -14 to -15

      Updated the elements of procedure to better reflect the working
      group consensus that a given session must always have identical
      sessionIDs, addresses and names to match the ASI parameters.



Harrington, et al.      Expires October 29, 2009               [Page 37]

Internet-Draft    Secure Shell Transport Model for SNMP       April 2009


      Discuss that the tmSessionID, tmSecurityName and
      tmTransportAddress need to be constant for the life of the
      session.

      Minor wording edits

      Added earlier text to introduce the concept of the user@ portion
      of the SSH transport address convention.

      Discussed notification authorization more extensively in the
      security considerations.

      Changed "ssh principal" to "ssh user name" where appropriate.

      Removed the sshtmSessionInvalidCaches object from the MIB
      conformance section.

   From -13 to -14

      Removed duplicated text on Caches and References, and reference
      tmsm document

      Simplified securityStateReference

      Simplified EOP to use tmStateReference rather than ASI parameters

      Simplified openSession and closeSession

      Seperated steps in openSession

      Clarified conditions in the openSession error counter descriptions

      Reworded text to clarify short versus long term information

      Added more warnings about the unreliability of SSH user name

      removed any references to LCD

   From -12 to -13

      Removed redundant sections 3.1.4 and 3.1.5 on privacy and replay/
      delay/etc protection.

   From -11- to -12

      Updated "Cached Information and References" to match other ISMS
      documents.




Harrington, et al.      Expires October 29, 2009               [Page 38]

Internet-Draft    Secure Shell Transport Model for SNMP       April 2009


      Added separate subsection on Secure Shell Transport Model Cached
      Information.

      Added IANA considerations to add snmpSSHDomain and "ssh" to a
      registry for domains and corresponding prefixes, defined in TMSM.

      Added support for user@ prefixing in the SSH Transport Address
      definition and EOP.

      Added support for the "ssh" prefix to the transport address
      definition and IANA considerations section.

      Removed the LCD tables and related configuration since the user@
      transport address prefixing and the TSM user prefix changes change
      makes it no longer needed.

   From -10- to -11

      Changed LCD to sshtmLCDTable so it would not be confused with the
      snmpTsmLCD.

      Removed the text that said the format and content of the LCD is
      implementation-specific, since we now have a MIB module to
      standardize the format and content.

      Designed sshtmLCDTable to reflect there is only one
      transportDomain and one securityLevel supported by this transport
      model.

      Used sshtmLCDTmSecurityName to reflect that the values in this
      table and the values in the tmStateReference are usually the same
      for some fields.

      Added operational considerations about SSH client credential
      distribution.

      Modified EOP to use sshtmLCDTable

      Resolved Issue #8: Should we allow transport models to select the
      corresponding security model by providing an additional parameter
      - the securityModel parameter - to tmStateReference, which would
      override the securityModel parameter extracted from a message
      header?  Doing this would resolve Issue #5, and would allow the
      transport security model to be used with all SNMP message
      versions. - The consensus is that we will not allow the transport
      model to specify the security model.

   From -09- to -10



Harrington, et al.      Expires October 29, 2009               [Page 39]

Internet-Draft    Secure Shell Transport Model for SNMP       April 2009


      Issue #1: Made release of cached session info an implementation
      requirement on session close.

      Issue #4: UTF-8 syntax of userauth user name matches syntax of
      SnmpAdminString.

      Issue #7: Resolved to not describe how an SSH session is closed.

   From -08- to -09

      Updated MIB assignment to by rfc4181 compatible

      update MIB security considerations with coexistence issues

      update sameSession and tmSessionID support

      Fixed note about terminology, for consistency with SNMPv3.

   From -07- to -08

      Updated MIB

      update MIB security considerations

      develop sameSession and tmSessionID support

      Added a note about terminology, for consistency with SNMPv3 rather
      than with RFC2828.

      Removed reference to mappings other than the identity function.

   From -06- to -07

      removed section on SSH to EngineID mappings, since engineIDs are
      not exposed to the transport model

      removed references to engineIDs and discovery

      removed references to securityModel.

      added security considerations warning about using with SNMPv1/v2c
      messages.

      added keyboard interactive discussion

      noted some implementation-dependent points





Harrington, et al.      Expires October 29, 2009               [Page 40]

Internet-Draft    Secure Shell Transport Model for SNMP       April 2009


      removed references to transportModel; we use the transport domain
      as a model identifier.

      cleaned up ASIs

      modified MIB to be under snmpModules

      changed transportAddressSSH to snmpSSHDomain style addressing

   From -05- to -06

      replaced transportDomainSSH with RFC3417-style snmpSSHDomain

      replaced transportAddressSSH with RFC3417-style snmpSSHAddress

      Changed recvMessage to receiveMessage, and modified OUT to IN to
      match TMSM.

   From -04- to -05

      added sshtmUserTable

      moved session table into the transport model MIB from the
      transport subsystem MIB

      added and then removed Appendix A - Notification Tables
      Configuration (see Transport Security Model)

      made this document a specification of a transport model, rather
      than a security model in two parts.  Eliminated TMSP and MPSP and
      replaced them with "transport model" and "security model".

      Removed security-model-specific processing from this document.

      Removed discussion of snmpv3/v1/v2c message format co-existence

      changed tmSessionReference back to tmStateReference

   "From -03- to -04-"

      changed tmStateReference to tmSessionReference



   "From -02- to -03-"






Harrington, et al.      Expires October 29, 2009               [Page 41]

Internet-Draft    Secure Shell Transport Model for SNMP       April 2009


      rewrote almost all sections

      merged ASI section and Elements of Procedure sections

      removed references to the SSH user, in preference to SSH client

      updated references

      created a conventions section to identify common terminology.

      rewrote sections on how SSH addresses threats

      rewrote mapping SSH to engineID

      eliminated discovery section

      detailed the Elements of Procedure

      eliminated sections on msgFlags, transport parameters

      resolved issues of opening notifications

      eliminated sessionID (TMSM needs to be updated to match)

      eliminated use of tmsSessiontable except as an example

      updated Security Considerations

   "From -01- to -02-"

      Added TransportDomainSSH and Address

      Removed implementation considerations

      Changed all "user auth" to "client auth"

      Removed unnecessary MIB module objects

      updated references

      improved consistency of references to TMSM as architectural
      extension

      updated conventions

      updated threats to be more consistent with RFC3552





Harrington, et al.      Expires October 29, 2009               [Page 42]

Internet-Draft    Secure Shell Transport Model for SNMP       April 2009


      discussion of specific SSH mechanism configurations moved to
      security considerations

      modified session discussions to reference TMSM sessions

      expanded discussion of engineIDs

      wrote text to clarify the roles of MPSP and TMSP

      clarified how snmpv3 message parts are ised by SSHSM

      modified nesting of subsections as needed

      securityLevel used by the SSH Transport Model always equals
      authPriv

      removed discussion of using SSHSM with SNMPv1/v2c

      started updating Elements of Procedure, but realized missing info
      needs discussion.

      updated MIB module relationship to other MIB modules

   "From -00- to -01-"

      -00- initial draft as ISMS work product:

      updated references to secshell RFCs

      Modified text related to issues# 1, 2, 8, 11, 13, 14, 16, 18, 19,
      20, 29, 30, and 32.

      updated security considerations

      removed Juergen Schoenwaelder from authors, at his request

      ran the mib module through smilint














Harrington, et al.      Expires October 29, 2009               [Page 43]

Internet-Draft    Secure Shell Transport Model for SNMP       April 2009


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






















Harrington, et al.      Expires October 29, 2009               [Page 44]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/