Network Working Group                                      D. Harrington
Internet-Draft                                 Huawei Technologies (USA)
Intended status: Standards Track                              J. Salowey
Expires: January 12, 2009                                  Cisco Systems
                                                           July 11, 2008


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

Status of This Memo

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

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

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

   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 January 12, 2009.

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



Harrington & Salowey    Expires January 12, 2009                [Page 1]


Internet-Draft    Secure Shell Transport Model for SNMP        July 2008


     1.1.  The Internet-Standard Management Framework . . . . . . . .  3
     1.2.  Conventions  . . . . . . . . . . . . . . . . . . . . . . .  3
     1.3.  Modularity . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.4.  Motivation . . . . . . . . . . . . . . . . . . . . . . . .  5
     1.5.  Constraints  . . . . . . . . . . . . . . . . . . . . . . .  6
   2.  The Secure Shell Protocol  . . . . . . . . . . . . . . . . . .  6
   3.  How SSHTM Fits into the Transport Subsystem  . . . . . . . . .  7
     3.1.  Security Capabilities of this Model  . . . . . . . . . . .  8
       3.1.1.  Threats  . . . . . . . . . . . . . . . . . . . . . . .  8
       3.1.2.  Message Authentication . . . . . . . . . . . . . . . .  9
       3.1.3.  Authentication Protocol Support  . . . . . . . . . . . 10
       3.1.4.  Privacy Protocol Support . . . . . . . . . . . . . . . 10
       3.1.5.  Protection against Message Replay, Delay and
               Redirection  . . . . . . . . . . . . . . . . . . . . . 10
       3.1.6.  SSH Subsystem  . . . . . . . . . . . . . . . . . . . . 11
     3.2.  Security Parameter Passing . . . . . . . . . . . . . . . . 11
     3.3.  Notifications and Proxy  . . . . . . . . . . . . . . . . . 12
   4.  Passing Security Parameters  . . . . . . . . . . . . . . . . . 12
     4.1.  tmStateReference . . . . . . . . . . . . . . . . . . . . . 12
     4.2.  tmSecurityName . . . . . . . . . . . . . . . . . . . . . . 13
     4.3.  tmSameSecurity . . . . . . . . . . . . . . . . . . . . . . 14
   5.  Elements of Procedure  . . . . . . . . . . . . . . . . . . . . 15
     5.1.  Procedures for an Incoming Message . . . . . . . . . . . . 15
     5.2.  Procedures for an Outgoing Message . . . . . . . . . . . . 16
     5.3.  Establishing a Session . . . . . . . . . . . . . . . . . . 17
     5.4.  Closing a Session  . . . . . . . . . . . . . . . . . . . . 19
   6.  MIB Module Overview  . . . . . . . . . . . . . . . . . . . . . 20
     6.1.  Structure of the MIB Module  . . . . . . . . . . . . . . . 20
     6.2.  Textual Conventions  . . . . . . . . . . . . . . . . . . . 20
     6.3.  Relationship to Other MIB Modules  . . . . . . . . . . . . 20
       6.3.1.  MIB Modules Required for IMPORTS . . . . . . . . . . . 20
   7.  MIB Module Definition  . . . . . . . . . . . . . . . . . . . . 21
   8.  Operational Considerations . . . . . . . . . . . . . . . . . . 30
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 31
     9.1.  noAuthPriv . . . . . . . . . . . . . . . . . . . . . . . . 31
     9.2.  Use with SNMPv1/v2c Messages . . . . . . . . . . . . . . . 32
     9.3.  Skipping Public Key Verification . . . . . . . . . . . . . 32
     9.4.  The 'none' MAC Algorithm . . . . . . . . . . . . . . . . . 32
     9.5.  MIB Module Security  . . . . . . . . . . . . . . . . . . . 33
   10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 33
   11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34
   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34
     12.1. Normative References . . . . . . . . . . . . . . . . . . . 34
     12.2. Informative References . . . . . . . . . . . . . . . . . . 35
   Appendix A.  Open Issues . . . . . . . . . . . . . . . . . . . . . 36
   Appendix B.  Change Log  . . . . . . . . . . . . . . . . . . . . . 37





Harrington & Salowey    Expires January 12, 2009                [Page 2]


Internet-Draft    Secure Shell Transport Model for SNMP        July 2008


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 & Salowey    Expires January 12, 2009                [Page 3]


Internet-Draft    Secure Shell Transport Model for SNMP        July 2008


   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 & Salowey    Expires January 12, 2009                [Page 4]


Internet-Draft    Secure Shell Transport Model for SNMP        July 2008


   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 & Salowey    Expires January 12, 2009                [Page 5]


Internet-Draft    Secure Shell Transport Model for SNMP        July 2008


   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 & Salowey    Expires January 12, 2009                [Page 6]


Internet-Draft    Secure Shell Transport Model for SNMP        July 2008


   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 plugs into the Transport Subsystem
   [I-D.ietf-isms-tmsm].  The SSH Transport Model thus fits between the
   underlying SSH transport layer and the message dispatcher [RFC3411].

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



Harrington & Salowey    Expires January 12, 2009                [Page 7]


Internet-Draft    Secure Shell Transport Model for SNMP        July 2008


   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.  Message stream modification - SSH provides for verification that
       each received message has not been modified during its
       transmission through the network.

   2.  Information modification - SSH provides for verification that the
       contents of each received message has not been modified during
       its transmission through the network, data has not been altered
       or destroyed in an unauthorized manner, nor have data sequences
       been altered to an extent greater than can occur non-maliciously.

   3.  Masquerade - SSH provides for both verification of the identity
       of the SSH server and verification of the identity of the SSH
       client.  SSH provides verification of the identity of the SSH
       server through the SSH Transport Protocol server authentication
       [RFC4253].

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

   5.  Authenticating both the SSH server and the SSH client ensures the
       authenticity of the SNMP engine that provides MIB data.
       Operators or management applications might act upon the data they
       receive (e.g., raise an alarm for an operator, modify the
       configuration of the device that sent the notification, modify



Harrington & Salowey    Expires January 12, 2009                [Page 8]


Internet-Draft    Secure Shell Transport Model for SNMP        July 2008


       the configuration of other devices in the network as the result
       of the notification, and so on), so it is important to know that
       the provider of MIB data is authentic.

   6.  Disclosure - the SSH Transport Model provides that the contents
       of each received SNMP message are protected from disclosure to
       unauthorized persons.

   7.  Replay - SSH ensures that cryptographic keys established at the
       beginning of the SSH session and stored in the SSH session state
       are fresh new session keys generated for each session.  These are
       used to authenticate and encrypt data, and to prevent replay
       across sessions.  SSH uses sequence information to prevent the
       replay and reordering of messages within a session.

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 the SSH Transport Model provides this
   information to SSH for an outgoing message.  The transport layer
   algorithms used to provide authentication, data integrity and
   encryption SHOULD NOT be exposed to the SSH Transport Model layer.
   The SNMPv3 WG deliberately avoided this and settled for an assertion
   by the security model that the requirements of securityLevel were met
   The SSH Transport Model has no mechanisms by which it can test
   whether an underlying SSH connection provides auth or priv, so the
   SSH Transport Model trusts that the underlying SSH connection has
   been properly configured to support authPriv security
   characteristics.

   The SSH Transport Model does not know about the algorithms or options
   to open SSH sessions that match different securityLevels.  For
   interoperability of the trust assumptions between SNMP engines, an
   SSH Transport Model-compliant implementation MUST use an SSH



Harrington & Salowey    Expires January 12, 2009                [Page 9]


Internet-Draft    Secure Shell Transport Model for SNMP        July 2008


   connection that provides authentication, data integrity and
   encryption that meets the highest level of SNMP security (authPriv).
   Outgoing messages requested by SNMP applications and specified with a
   lesser securityLevel (noAuthNoPriv or authNoPriv) are sent by the SSH
   Transport Model as authPriv securityLevel.

   The security protocols used in the Secure Shell Authentication
   Protocol [RFC4252] and the Secure Shell Transport Layer Protocol
   [RFC4253] are considered acceptably secure at the time of writing.
   However, the procedures allow for new authentication and privacy
   methods to be specified at a future time if the need arises.

3.1.3.  Authentication Protocol Support

   The SSH Transport Model should support any server or client
   authentication mechanism supported by SSH.  This includes the three
   authentication methods described in the SSH Authentication Protocol
   document [RFC4252] - publickey, password, and host-based - 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.  [DISCUSS: do we really need this paragraph?

   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.  Privacy Protocol Support

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

3.1.5.  Protection against Message Replay, Delay and Redirection

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



Harrington & Salowey    Expires January 12, 2009               [Page 10]


Internet-Draft    Secure Shell Transport Model for SNMP        July 2008


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

3.1.6.  SSH Subsystem

   This document describes the use of an SSH subsystem for SNMP to make
   SNMP usage distinct from other usages.

   SSH subsystems of type "snmp" are opened by the SSH Transport Model
   during the elements of procedure for an outgoing SNMP message.  Since
   the sender of a message initiates the creation of an SSH session if
   needed, the SSH session will already exist for an incoming message or
   the incoming message would never reach the SSH Transport Model.
   [DISCUSS: If a notification originator opens a subsystem called
   "snmp" and a command generator opens a subsystem called "snmp", will
   that be confusing to SSH? ]

   Implementations MAY choose to instantiate SSH sessions in
   anticipation of outgoing messages.  This approach might be useful to
   ensure that an SSH session to a given target can be established
   before it becomes important to send a message over the SSH session.
   Of course, there is no guarantee that a pre-established session will
   still be valid when needed.

   SSH sessions are uniquely identified within the SSH Transport Model
   by the combination of transportAddressType, transportAddress,
   securityName, and securityLevel associated with each session.

3.2.  Security Parameter Passing

   For incoming messages, SSH-specific security parameters are
   translated by the transport model into security parameters
   independent of the transport and security models.  The transport
   model accepts messages from the SSH subsystem, and records the
   transport-related and SSH-security-related information, including the
   authenticated identity, in a cache referenced by tmStateReference,
   and passes the WholeMsg and the tmStateReference to the dispatcher
   using the receiveMessage() ASI (Application Service Interface).

   For outgoing messages, the transport model takes input provided by
   the dispatcher in the sendMessage() ASI.  The SSH Transport Model
   converts that information into suitable security parameters for SSH,
   establishes sessions as needed, and passes messages to the SSH
   subsystem for sending.





Harrington & Salowey    Expires January 12, 2009               [Page 11]


Internet-Draft    Secure Shell Transport Model for SNMP        July 2008


3.3.  Notifications and Proxy

   SSH connections may be initiated by command generators or by
   notification originators.  Command generators are frequently operated
   by a human, but notification originators are usually unmanned
   automated processes.  As a result, it may be necessary to provision
   authentication credentials on the SNMP engine containing the
   notification originator, or use a third party key provider such as
   Kerberos, so the engine can successfully authenticate to an engine
   containing a notification receiver.

   The targets to whom notifications should be sent is typically
   determined and configured by a network administrator.  The SNMP-
   TARGET-MIB module [RFC3413] contains objects for defining management
   targets, including transport domains and addresses and security
   parameters, for applications such as notifications and proxy.

   For the SSH Transport Model, transport type and address are
   configured in the snmpTargetAddrTable, and the securityName, and
   securityLevel parameters are configured in the snmpTargetParamsTable.
   The default approach is for an administrator to statically
   preconfigure this information to identify the targets authorized to
   receive notifications or perform proxy.

   These MIB modules may be configured using SNMP or other
   implementation-dependent mechanisms, such as CLI scripting or loading
   a configuration file.  It may be necessary to provide additional
   implementation-specific configuration of SSH parameters.

4.  Passing Security Parameters

   For the SSH Transport Model, some state needs to be maintained using
   tmStateReference.  RFC3411 discusses a securityStateReference, which
   is not accessible to the Transport Subsystem.

4.1.  tmStateReference

   Upon opening each SSH connection, the SSH Transport Model stores
   model- and mechanism-specific information about the connection in a
   cache, referenced by tmStateReference.  This connection information
   might be consistent across multiple messages, and might also be
   stored in the sshtmLCDTable.

   For interoperability with Security Model designs, the state
   referenced by tmStateReference MUST include the following fields
   (with sample values).  See the Elements of Procedure for detailed
   processing instructions on the use of these fields by the SSH
   Transport Model.



Harrington & Salowey    Expires January 12, 2009               [Page 12]


Internet-Draft    Secure Shell Transport Model for SNMP        July 2008


      tmTransport = snmpSSHDomain

      tmAddress = an snmpSSHAddress

      tmRequestedSecurityLevel = ["noAuthNoPriv" | "authNoPriv" |
      "authPriv" ]

      tmTransportSecurityLevel = "authPriv"

      tmSecurityName = the principal name [to be] authenticated by SSH.
      See the section on tmSecurityName below.

      tmSameSecurity = true or false, depending on whether the Security
      Model requires that an outgoing response be sent using the same
      security parameters as were used for the incoming request or for
      any other security-model-dependent reason.  See the section on
      tmSameSecurity below.



   The state referenced by tmStateReference for an SSH Transport Model
   should also contain an implementation-dependent identifier (e.g.,
   tmSessionID).

   The per-session state that is referenced by tmStateReference may be
   saved across multiple messages in a Local Configuration Datastore
   (sshtmLCDTable).

   The tmStateReference cache should be generated anew for each message,
   so that it can be used to determine whether the SSH session available
   for sending an outgoing message is the same SSH session as was used
   when receiving the corresponding incoming message (e.g., a response
   to a request), when tmSameSecurity is set.

   A Transport Model will maintain any mapping between transport-
   specific security parameters and tmTransportSecurityLevel and
   tmSecurityName, and will verify for outgoing messages that the
   transport-provided security is at least as strong as
   tmRequestedSecurityLevel..

   The SSH Transport Model implementation has the responsibility for
   "garbage collection" - releasing any associated tmStateReference when
   a session is closed.

4.2.  tmSecurityName

   How the SSH identity is extracted from the SSH layer is
   implementation-dependent.



Harrington & Salowey    Expires January 12, 2009               [Page 13]


Internet-Draft    Secure Shell Transport Model for SNMP        July 2008


   tmSecurityName is a human-readable name in SnmpAdminString format
   that is mapped from the identity that has been successfully
   authenticated by SSH.  By default, tmSecurityName is determined from
   the value of the user name field of the SSH_MSG_USERAUTH_REQUEST
   message for which a SSH_MSG_USERAUTH_SUCCESS has been received.

   As described in RFC4252 section 5, all authentication requests,
   regardless of authentication mechanism, MUST use the same message
   format, which includes a byte to indicate SSH_MSG_USERAUTH_REQUEST,
   and a user name field.  How the authenticated user name is made
   available to the SNMP implementation is SSH-implementation dependent.

   The SSH protocol is not always clear on whether the user name field
   must be filled in, so for some implementations, it may be necessary
   to use a non-default mapping algorithm.  How the SSH identity is
   mapped to a tmSecurityName should be administratively configurable.
   The sshtmLCDTransformPolicy object is used during the elements of
   procedure to determine whether the default transform or an
   alternative tranbsform is used.

   The tmSecurityName may ultimately be used to identify the layer 8
   principal for use in such things as logging and for access control
   policy assignment.  For example, USM provides this by pre-
   configuration of the mapping of the auth protocol and auth-specific
   credentials to a securityName, in the usmUserTable.  Transport model
   transforms SHOULD generate a predictable tmSecurityName representing
   the principal.

4.3.  tmSameSecurity

   If a Secure Shell transport session is closed between the time a
   request message is received and the corresponding response message is
   sent, then the response message MUST be discarded, even if a new SSH
   session has been established.  The SSH Transport Model does not know
   whether a message contains a request or response (at least
   architecturally, this is not available to the transport model;
   implementations may choose to make this available for simplicity.)

   Each Security Model that supports the tmStateReference cache will
   pass a tmSameSecurity parameter in the tmStateReference cache for
   outgoing messages to indicate whether the same security MUST be used
   for the outgoing message as was used for the corresponding incoming
   message (e.g., a request-response pair).  The tmStateReference for
   the Secure Shell Transport Model SHOULD also include a tmSessionID to
   indicate which SSH session should be used for the corresponding
   response.

   If the tmSameSecurity is indicated, but the session identified in the



Harrington & Salowey    Expires January 12, 2009               [Page 14]


Internet-Draft    Secure Shell Transport Model for SNMP        July 2008


   tmStateReference does not match the current established SSH session
   for the tmTransportDomain, tmTransportAddress, tmSecurityName, and
   tmSecurityLevel, then the message MUST be discarded, and the
   dispatcher should be notified that the sending of the message failed.

5.  Elements of Procedure

   Abstract service interfaces have been defined by RFC 3411 to describe
   the conceptual data flows between the various subsystems within an
   SNMP entity.  The Secure Shell Transport Model uses some of these
   conceptual data flows when communicating between subsystems.  These
   RFC 3411-defined data flows are referred to here as public
   interfaces.

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

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

5.1.  Procedures for an Incoming Message

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

   By default, the principal name is the value of the user name field of
   the SSH_MSG_USERAUTH_REQUEST message for which a
   SSH_MSG_USERAUTH_SUCCESS has been received.  How this name is
   extracted from the SSH environment is implementation-dependent.

   2) Using the sshtmLCDTransformPolicy, calculate a corresponding
   tmSecurityName value.  Determine if there is a row in the
   sshtmLCDTable with the transport address and an
   sshtmLCDTmSecurityName that matches the calculated tmSecurityName
   value.

   3) If one does not exist, create an entry in the sshtmLCDTable:



Harrington & Salowey    Expires January 12, 2009               [Page 15]


Internet-Draft    Secure Shell Transport Model for SNMP        July 2008


      sshtmTransportAddress = transport address

      sshtmLCDTmSecurityName = calculated tmSecurityName

      sshtmLCDPrincipal=the SSH principal

      sshtmLCDSessionID=the SSH session identifier

      sshtmStorageType=volatile

      sshtmRowStatus=createAndGo

   4) Create a tmStateReference cache for subsequent reference to the
   information.

      tmTransportDomain = snmpSSHDomain

      tmTransportAddress = sshtmLCDTransportAddress

      tmSecurityLevel = "authPriv"

      tmSecurityName = sshtmLCDTmSecurityName

      tmSessionID = an implementation-dependent value that can be used
      to detect when a session has closed and been replaced by another
      session.  The value in tmStateReference should identify the
      session over which the message was received.

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

   statusInformation =
   receiveMessage(
   IN   transportDomain       -- snmpSSHDomain
   IN   transportAddress      -- address for the received 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 an Outgoing Message

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







Harrington & Salowey    Expires January 12, 2009               [Page 16]


Internet-Draft    Secure Shell Transport Model for SNMP        July 2008


   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) Extract the tmTransportAddress, tmSecurityName, tmSameSecurity,
      and tmSessionID from the tmStateReference.  (SSHTM ignores the
      provided tmTransportDomain and tmRequestedSecurityLevel.)

      2) Using tmTransportAddress and tmSecurityName, determine if a
      corresponding row exists in the sshtmLCDTable.

      3) If there is a corresponding row, and tmSameSecurity is true,
      and tmSessionID does not match sshtmLCDSessionID, then increment
      the sshtmSessionNoAvailableSessions counter, discard the message
      and return the error indication in the statusInformation.
      Processing of this message stops.

      4) If there is no corresponding row, then call openSession() with
      the tmTransportAddress and tmSecurityName as parameters.

      4b) If an error is returned from OpenSession(), then discard the
      message, and return the error indication returned by OpenSession()
      in the statusInformation.

      5) Determine any SSH-implementation-specific parameters from the
      sshtmLCDTable

      6) Pass the wholeMessage to SSH for encapsulation as data in an
      SSH message.

5.3.  Establishing a Session

   The Secure Shell Transport Model provides the following application
   service interface (ASI) to describe the data passed between the SSH
   Transport Model and the SSH service.  It is an implementation
   decision how such data is passed.








Harrington & Salowey    Expires January 12, 2009               [Page 17]


Internet-Draft    Secure Shell Transport Model for SNMP        July 2008


   statusInformation =
   openSession(
   IN   destTransportAddress     -- transport address to be used
   IN   tmSecurityName             -- on behalf of this principal
   IN   maxMessageSize           -- of the sending SNMP entity
    )


   The following describes the procedure to follow to establish a
   session between a client and server to run SNMP over SSH.  This
   process is used by any SNMP engine establishing a session for
   subsequent use.

   This will be done automatically for an SNMP application that
   initiates a transaction, such as a Command Generator or a
   Notification Originator or a Proxy Forwarder.

   1) Using destTransportAddress, the client will establish an SSH
   transport connection using the SSH transport protocol, authenticate
   the server, and exchange keys for message integrity and encryption.
   The parameters of the transport connection and the credentials used
   to authenticate are provided in an implementation-dependent manner.

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

   2) Create an entry in the sshtmLCDTable:

      sshtmLCDTransportAddress = tmTransportAddress

      sshtmLCDTmSecurityName = tmSecurityName

      Using the sshtmLCDTransformPolicy, calculate the corresponding
      sshtmLCDPrincipal value.

   3)In an implementation-specific manner, pass the sshtmLCDPrincipal to
   the SSH layer.  The client will then invoke an SSH authentications
   service to authenticate the principal, such as that described in the
   SSH authentication protocol [RFC4252].  The credentials used to
   authenticate sshtmLCDPrincipal are determined in an implementation-
   dependent manner.

   If the authentication is unsuccessful, then the transport connection
   is closed, tmStateReference is released, the message is discarded,
   the sshtmSessionUserAuthFailures counter is incremented, an error
   indication is returned to the calling module, and processing stops



Harrington & Salowey    Expires January 12, 2009               [Page 18]


Internet-Draft    Secure Shell Transport Model for SNMP        July 2008


   for this message.

   4) Once the principal has been successfully authenticated, the client
   will invoke the "ssh- connection" service, also known as the SSH
   connection protocol [RFC4254].

   5) After the ssh-connection service is established, the client will
   request a channel of type "session" in an implementation-dependent
   manner.  If unsuccessful, the transport connection is closed,
   tmStateReference is released, the message is discarded, the
   sshtmSessionChannelOpenFailures counter is incremented, an error
   indication is returned to the calling module, and processing stops
   for this message.

   6) If successful, this will result in an SSH session.  Set the
   sshtmLCDSessionID in the corresponding entry.  Increment the
   sshtmSessionOpens counter.

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

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

5.4.  Closing a Session

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

   statusInformation =
   closeSession(
   IN   tmTransportAddress     -- transport address to be used
   IN   tmSecurityName             -- on behalf of this principal
    )



   The following describes the procedure to follow to close a session
   between a client and sever .  This process is followed by any SNMP
   engine to close an SSH session.  It is implementation-dependent when
   a session should be closed.





Harrington & Salowey    Expires January 12, 2009               [Page 19]


Internet-Draft    Secure Shell Transport Model for SNMP        July 2008


      1) Lookup the session in the sshtmLCDTable using the
      tmTransportAddress and tmSecurityName.

      3) If there is no entry, then closeSession processing is
      completed.

      4) Extract sshtmLCDPrincipal and sshtmLCDSessionID.  Have SSH
      close the session.  Increment the sshtmSessionCloses counter.

6.  MIB Module Overview

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

6.1.  Structure of the MIB Module

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

6.2.  Textual Conventions

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

6.3.  Relationship to Other MIB Modules

   Some management objects defined in other MIB modules are applicable
   to an entity implementing the SSH Transport Model.  In particular, it
   is assumed that an entity implementing the SSHTM-MIB will implement
   the SNMPv2-MIB [RFC3418], the SNMP-FRAMEWORK-MIB [RFC3411] and the
   SNMP-TRANSPORT-MIB [I-D.ietf-isms-tmsm].

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

6.3.1.  MIB Modules Required for IMPORTS

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

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






Harrington & Salowey    Expires January 12, 2009               [Page 20]


Internet-Draft    Secure Shell Transport Model for SNMP        July 2008


7.  MIB Module Definition


SSHTM-MIB DEFINITIONS ::= BEGIN

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

sshtmMIB MODULE-IDENTITY
    LAST-UPDATED "200710140000Z"
    ORGANIZATION "ISMS Working Group"
    CONTACT-INFO "WG-EMail:   isms@lists.ietf.org
                  Subscribe:  isms-request@lists.ietf.org

               Chairs:
                 Juergen Quittek
                 NEC Europe Ltd.
                 Network Laboratories
                 Kurfuersten-Anlage 36
                 69115 Heidelberg
                 Germany
                 +49 6221 90511-15
                  quittek@netlab.nec.de

                  Juergen Schoenwaelder
                  Jacobs University Bremen
                  Campus Ring 1
                  28725 Bremen
                  Germany
                  +49 421 200-3587
                  j.schoenwaelder@iu-bremen.de

               Co-editors:
                  David Harrington
                  Huawei Technologies USA
                  1700 Alma Drive
                  Plano Texas 75075
                  USA
                  +1 603-436-8634
                  ietfdbh@comcast.net



Harrington & Salowey    Expires January 12, 2009               [Page 21]


Internet-Draft    Secure Shell Transport Model for SNMP        July 2008


                  Joseph Salowey
                  Cisco Systems


                  2901 3rd Ave
                  Seattle, WA 98121
                  USA
                  jsalowey@cisco.com
                    "
       DESCRIPTION  "The Secure Shell Transport Model MIB

                     Copyright (C) The IETF Trust (2007). This
                     version of this MIB module is part of RFC XXXX;
                     see the RFC itself for full legal notices.
-- NOTE to RFC editor: replace XXXX with actual RFC number
--                     for this document and remove this note
                    "

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

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

-- ---------------------------------------------------------- --
-- subtrees in the SNMP-SSH-TM-MIB
-- ---------------------------------------------------------- --

sshtmNotifications OBJECT IDENTIFIER ::= { sshtmMIB 0 }
sshtmObjects    OBJECT IDENTIFIER ::= { sshtmMIB 1 }
sshtmConformance   OBJECT IDENTIFIER ::= { sshtmMIB 2 }

-- -------------------------------------------------------------
-- Objects
-- -------------------------------------------------------------

snmpSSHDomain OBJECT-IDENTITY
    STATUS      current
    DESCRIPTION
        "The SNMP over SSH transport domain. The corresponding transport
        address is of type SnmpSSHAddress.

        When an SNMP entity uses the snmpSSHDomain transport
        model, it must be capable of accepting messages up to



Harrington & Salowey    Expires January 12, 2009               [Page 22]


Internet-Draft    Secure Shell Transport Model for SNMP        July 2008


        and including 8192 octets in size.  Implementation of
        larger values is encouraged whenever possible."
    ::= { snmpDomains yy }


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

SnmpSSHAddress ::= TEXTUAL-CONVENTION
    DISPLAY-HINT "1a"
    STATUS      current
    DESCRIPTION
        "Represents either a hostname with a port number or an IP
         address with a port number.

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

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

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

         Values of this textual convention may not be directly useable
         as transport-layer addressing information, and may require
         runtime resolution. As such, applications that write them
         must be prepared for handling errors if such values are
         not supported, or cannot be resolved (if resolution occurs
         at the time of the management operation).

         The DESCRIPTION clause of TransportAddress objects that may
         have snmpSSHAddress values must fully describe how (and
         when) such names are to be resolved to IP addresses and vice
         versa.

         This textual convention SHOULD NOT be used directly in
         object definitions since it restricts addresses to a
         specific format. However, if it is used, it MAY be used
         either on its own or in conjunction with
         TransportAddressType or TransportDomain as a pair.

         When this textual convention is used as a syntax of an



Harrington & Salowey    Expires January 12, 2009               [Page 23]


Internet-Draft    Secure Shell Transport Model for SNMP        July 2008


         index object, there may be issues with the limit of 128
         sub-identifiers specified in SMIv2, STD 58. It is
         RECOMMENDED that all MIB documents using this textual
         convention make explicit any limitations on index
         component lengths that management software must observe.
         This may be done either by including SIZE constraints on
         the index components or by specifying applicable
         constraints in the conceptual row DESCRIPTION clause or
         in the surrounding documentation.
"
    REFERENCE
    "RFC3896, Uniform Resource Identifier (URI): Generic Syntax"
    SYNTAX      OCTET STRING (SIZE (1..255))


-- The sshtmSession Group

sshtmSession          OBJECT IDENTIFIER ::= { sshtmObjects 1 }
sshtmLCD                OBJECT IDENTIFIER ::= { sshtmObjects 2 }

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

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

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

sshtmSessionUserAuthFailures  OBJECT-TYPE



Harrington & Salowey    Expires January 12, 2009               [Page 24]


Internet-Draft    Secure Shell Transport Model for SNMP        July 2008


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

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

sshtmSessionNoAvailableSessions  OBJECT-TYPE
    SYNTAX       Counter32
    MAX-ACCESS   read-only
    STATUS       current
    DESCRIPTION "The number of times an outgoing message
               was dropped because the same
               session was no longer available.
                "
    ::= { sshtmSession 6 }

-- The table of users for the Transport Security Model
-- This table can support users of multiple transport models

sshtmLCDSpinLock  OBJECT-TYPE
    SYNTAX       TestAndIncr
    MAX-ACCESS   read-write
    STATUS       current
    DESCRIPTION "An advisory lock used to allow several cooperating
                 Command Generator Applications to coordinate their
                 use of facilities to alter the sshtmLCDTable.
                "
    ::= { sshtmLCD 1 }

-- The transform policy for the SSH Transport Model

sshtmLCDTransformPolicy OBJECT-TYPE
    SYNTAX       INTEGER { default(1),
                           private(2)
                         }

       MAX-ACCESS  read-write



Harrington & Salowey    Expires January 12, 2009               [Page 25]


Internet-Draft    Secure Shell Transport Model for SNMP        July 2008


       STATUS      current
       DESCRIPTION
           "The policy that should be used to perform transforms
           between the SSH identity and tmSecurityName, and vice-versa.

           default (1) - for incoming messages, the value passed in
           the user name field of SSH user_auth is assigned
           to both sshtmLCDTmSecurityName and sshtmLCDPrincipal.
           For outgoing messages, the value passed in tmSecurityName
           is assigned to both sshtmLCDTmSecurityName and
           sshtmLCDPrincipal.

            private (2) - use an implementation-specific mapping
            algorithm for the transform. If the algorithm does not yield
            a mapping, no entry should be created for the identity in
            the sshtmLCDTable. It is implementation-dependent
            whether a private algorithm is supported.
            "
        DEFVAL  { default }
       ::= { sshtmLCD 2 }

sshtmLCDTable     OBJECT-TYPE
    SYNTAX       SEQUENCE OF sshtmLCDEntry
    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION "The table of users configured in the SSH
                 Transport Model Local Configuration Datastore (LCD).

                 Rows in this table can be instantiated when an
                 authenticated identity is passed to the transport model
                 from SSH, and they can be instantiated by a command
                 generator.

                 To instantiate a new row in this table, the
                 sshtmLCDSpinLock should be used to prevent conflicts.

                   1)  GET(sshtmLCDSpinLock.0) and save in sValue.

                   2)  SET(sshtmLCDSpinLock.0=sValue,
                           sshtmLCDTransportAddress=(desired value),
                           sshtmLCDTmSecurityName=(desired value),
                           sshtmLCDPrincipal=(desired value),
                           sshtmLCDSessionID=sValue,
                           sshtmLCDStorageType=(desired value),
                           sshtmLCDStatus=createAndGo)
                "
    ::= { sshtmLCD 3 }




Harrington & Salowey    Expires January 12, 2009               [Page 26]


Internet-Draft    Secure Shell Transport Model for SNMP        July 2008


sshtmLCDEntry     OBJECT-TYPE
    SYNTAX       sshtmLCDEntry
    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION "A user configured in the Local
                 Configuration Datastore (LCD) for the SSH
                 Transport Model.

                 To maintain modularity of design, and to avoid
                 side-effects, only the SSH Transport Model
                 (or a SET operation) should modify this table.

                 For all entries in this table, the transportDomain
                 is snmpSSHTransportDomain, and the security level
                 is authpriv.
                "
    INDEX       { sshtmLCDTransportAddress,
                          sshtmLCDTmSecurityName
                }
    ::= { sshtmLCDTable 1 }

sshtmLCDEntry ::= SEQUENCE
    {
        sshtmLCDTransportAddress TransportAddress,
        sshtmLCDTmSecurityName     SnmpAdminString,
        sshtmLCDPrincipal             SnmpAdminString,
        sshtmLCDSessionID           Integer32
        sshtmLCDStorageType      StorageType,
        sshtmLCDRowStatus           RowStatus
    }

sshtmLCDTransportAddress OBJECT-TYPE
       SYNTAX      TransportAddress
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "This object contains a transport address.
           "
       ::= { sshtmLCDEntry 2 }

sshtmLCDTmSecurityName      OBJECT-TYPE
    SYNTAX       SnmpAdminString (SIZE(1..32))
    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION "A human readable string representing the user.
                 This value is passed in tmSecurityName.

                 The default transformation of the SSH user name to



Harrington & Salowey    Expires January 12, 2009               [Page 27]


Internet-Draft    Secure Shell Transport Model for SNMP        July 2008


                 tmSecurityName and vice versa is the identity function
                 so the sshtmLCDTmSecurityName is usually the same as
                 the sshtmLCDPrincipal.
                "
    ::= { sshtmLCDEntry 3 }

sshtmLCDPrincipal      OBJECT-TYPE
    SYNTAX       SnmpAdminString (SIZE(1..32))
    MAX-ACCESS   read-create
    STATUS       current
    DESCRIPTION "A human readable string used to determine, in an
                  implementation-dependent manner, which SSH
                  credentials are used during authentication of the
                  prinicipal.

                 By default, this is the SSH user name.
                "
    ::= { sshtmLCDEntry 5 }

sshtmLCDStorageType OBJECT-TYPE
    SYNTAX       StorageType
    MAX-ACCESS   read-create
    STATUS       current
    DESCRIPTION "The storage type for this conceptual row.

                 Conceptual rows having the value readOnly, permanent,
                 or nonVolatile must persist across reinitializations of
                 the management subsystem.

                 Conceptual rows having the value 'volatile' must not
                 persist across reinitializations of the management
                 subsystem.

                 It is an implementation issue to decide if a SET for
                 a readOnly or permanent row is accepted at all. In
                 some contexts this may make sense, in others it may
                 not. If a SET for a readOnly or permanent row is not
                 accepted at all, then a 'wrongValue' error must be
                 returned.
                "
    DEFVAL      { volatile }
    ::= { sshtmLCDEntry 6 }

sshtmLCDRowStatus    OBJECT-TYPE
    SYNTAX       RowStatus
    MAX-ACCESS   read-create
    STATUS       current
    DESCRIPTION "The status of this conceptual row.



Harrington & Salowey    Expires January 12, 2009               [Page 28]


Internet-Draft    Secure Shell Transport Model for SNMP        July 2008


                 Until instances of all corresponding columns are
                 appropriately configured, the value of the
                 corresponding instance of sshtmLCDStatus
                 is 'notReady'.

                 The sshtmLCDPrincipal value should only be
                 changed when the value of this object
                 is 'active'.
                "
    ::= { sshtmLCDEntry 7 }

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

sshtmCompliances OBJECT IDENTIFIER ::= { sshtmConformance 1 }

sshtmGroups OBJECT IDENTIFIER ::= { sshtmConformance 2 }

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

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

-- ************************************************
-- Units of conformance
-- ************************************************
sshtmGroup OBJECT-GROUP
    OBJECTS {
      sshtmSessionOpens,
      sshtmSessionCloses,
      sshtmSessionOpenErrors,
      sshtmSessionUserAuthFailures,
      sshtmSessionChannelOpenFailures,
      sshtmSessionNoAvailableSessions,
      sshtmLCDSpinLock,
      sshtmLCDTransportAddress,
      sshtmLCDTmSecurityName,
      sshtmLCDPrincipal,
      sshtmLCDStorageType,



Harrington & Salowey    Expires January 12, 2009               [Page 29]


Internet-Draft    Secure Shell Transport Model for SNMP        July 2008


      sshtmLCDRowStatus
    }
    STATUS      current
    DESCRIPTION "A collection of objects for maintaining
                 information of an SNMP engine which implements the
                 SNMP Secure Shell Transport Model.
                "


    ::= { sshtmGroups 2 }


END


8.  Operational Considerations

   The SSH Transport Model will likely not work in conditions where
   access to the CLI has stopped working.  In situations where SNMP
   access has to work when the CLI has stopped working, a UDP transport
   model should be considered instead of the SSH Transport Model.

   The SSH Transport Model defines two well-known default ports, one for
   request/response traffic, and one port that listens for
   notifications.

   If the SSH Transport Model is configured to utilize AAA services,
   operators should consider configuring support for a local
   authentication mechanisms, such as local passwords, so SNMP can
   continue operating during times of network stress.

   The SSH protocol has its own windowing mechanism.  RFC 4254 says: The
   window size specifies how many bytes the other party can send before
   it must wait for the window to be adjusted.  Both parties use the
   following message to adjust the window.  The SSH specifications leave
   it open when such window adjustment messages are created.  Some
   implementations have been found to send window adjustment messages
   whenever received data has been passed to the application.  Since
   window adjustment messages are padded, encrypted, hmac'ed, and
   wrapped, this results in noticeable bandwidth and processing
   overhead, which can be avoided by sending window adjustment messages
   less frequently.

   The SSH protocol requires the execution of CPU intensive calculations
   to establish a session key during session establishment.  This means
   that short lived sessions become computationally expensive compared
   to USM, which does not have a notion of a session key.  Other
   transport security protocols such as TLS support a session resumption



Harrington & Salowey    Expires January 12, 2009               [Page 30]


Internet-Draft    Secure Shell Transport Model for SNMP        July 2008


   feature that allows reusing a cached session key.  Such a mechanism
   does not exist for SSH and thus SNMP applications should keep SSH
   sessions for longer time periods.

   To initiate SSH connections, an entity must be configured with SSH
   client credentials and information to authenticate the server.  While
   hosts are often configured to be SSH clients, most internetworking
   devices are not.  To send notifications over SSHTM, the
   internetworking device will need to be configured to be SSH clients.
   How this credential configuration is done is implementation and
   deployment specific.  A scalable IETF standard protocol for
   configuration or key management is RECOMMENDED.

9.  Security Considerations

   This document describes a transport model that permits SNMP to
   utilize SSH security services.  The security threats and how the SSH
   Transport Model mitigates those threats is covered in detail
   throughout this memo.

   The SSH Transport Model relies on SSH mutual authentication, binding
   of keys, confidentiality and integrity.  Any authentication method
   that meets the requirements of the SSH architecture will provide the
   properties of mutual authentication and binding of keys.  While SSH
   does support turning off confidentiality and integrity, they SHOULD
   NOT be turned off when used with the SSH Transport Model.

   SSHv2 provides Perfect Forward Security (PFS) for encryption keys.
   PFS is a major design goal of SSH, and any well-designed keyex
   algorithm will provide it.

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

9.1.  noAuthPriv

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



Harrington & Salowey    Expires January 12, 2009               [Page 31]


Internet-Draft    Secure Shell Transport Model for SNMP        July 2008


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

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

9.2.  Use with SNMPv1/v2c Messages

   The SNMPv1 and SNMPv2c message processing described in RFC3584 (BCP
   74) [RFC3584] always selects the SNMPv1(1) Security Model for an
   SNMPv1 message, or the SNMPv2c(2) Security Model for an SNMPv2c
   message.  When running SNMPv1/SNMPv2c over a secure transport like
   the SSH Transport Model, the securityName and securityLevel used for
   access control decisions are then derived from the community string,
   not the authenticated identity and securityLevel provided by the SSH
   Transport Model.

9.3.  Skipping Public Key Verification

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

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

9.4.  The 'none' MAC Algorithm

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



Harrington & Salowey    Expires January 12, 2009               [Page 32]


Internet-Draft    Secure Shell Transport Model for SNMP        July 2008


   flight, which means you effectively have no authentication.

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

9.5.  MIB Module Security

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

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

   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
   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.  a TCP port number in the range 1..1023 in the
       http://www.iana.org/assignments/port-numbers registry which will



Harrington & Salowey    Expires January 12, 2009               [Page 33]


Internet-Draft    Secure Shell Transport Model for SNMP        July 2008


       be the default port for SNMP over an SSH Transport Model as
       defined in this document,

   2.  an SMI number under mib-2, for the MIB module in this document,

   3.  an SMI number under snmpDomains, for the snmpSSHDomain,

   4.  "snmp" as an SSH Service Name in the
       http://www.iana.org/assignments/ssh-parameters registry.

11.  Acknowledgements

   The editors would like to thank Jeffrey Hutzelman for sharing his SSH
   insights.

12.  References

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 & Salowey    Expires January 12, 2009               [Page 34]


Internet-Draft    Secure Shell Transport Model for SNMP        July 2008


   [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, "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-12 (work
                         in progress), February 2008.

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



Harrington & Salowey    Expires January 12, 2009               [Page 35]


Internet-Draft    Secure Shell Transport Model for SNMP        July 2008


                         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.

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

Appendix A.  Open Issues

   We need to reach consensus on some issues.

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

   o  Issue #2: In USM, there is a mapping table that permits one user
      to have multiple methods for authentication, that map to a common
      securityName.  Since SSH supports multiple authentication
      mechanisms, do we need to specify how these mechanism-specific
      identities map to a common securityName?  This is important to
      permit admins to configure the TARGET-MIB, for example, with one
      common identity rather than mechanism-specific identities.

   o  Issue #3: Mapping from the sshtmLCDTable identity to an SSH
      mechanisms-specific identity.  This may just be the opposite
      transform of Issue #2.



Harrington & Salowey    Expires January 12, 2009               [Page 36]


Internet-Draft    Secure Shell Transport Model for SNMP        July 2008


   o  Issue #5: what are the elements of procedure if you run for
      example SNMPv3/USM over SSHTM?  The ASIs do not have parameters to
      identify two methods of authentication, and it is unclear how an
      outgoing message request would specify both SNMPv3/USM and SSHTM
      should be used, and which securityName/Level should be used for
      each.

   o  Issue #6: We have not resolved whether the principal associated
      with a notification receiver must be a principal (aka user) or
      whether a hostname is adequate.  In SNMPv3, the access controls
      are symmetrical - it is a user-level principal that access
      controls apply to, whether for R/R or notify applications.  Is it
      acceptable to have user-level for R/R and host-level for notify
      functionality?  A user that is not allowed to GET an object might
      be able to have the value of the object reported in a
      notification, or vice-versa.  This is not much different that a
      principal having two different identities, one for R/R and another
      for notifications, or an admin configuring systems to send
      notifications to a different principal than those who do R/R
      processing.  The WG needs to discuss this and reach some consensus
      on whether this is an issue or not, and how we want to proceed.

   TODO:

      finalize error processing in EOP

Appendix B.  Change Log

   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.




Harrington & Salowey    Expires January 12, 2009               [Page 37]


Internet-Draft    Secure Shell Transport Model for SNMP        July 2008


      Modified EOP to use sshtmLCDTable

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

   From -09- to -10

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

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

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

   From -08- to -09

      Updated MIB assignment to by rfc4181 compatible

      update MIB security considerations with coexistence issues

      update sameSession and tmSessionID support

      Fixed note about terminology, for consistency with SNMPv3.



   From -07- to -08

      Updated MIB

      update MIB security considerations

      develop sameSession and tmSessionID support

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

      Removed reference to mappings other than the identity function.

   From -06- to -07




Harrington & Salowey    Expires January 12, 2009               [Page 38]


Internet-Draft    Secure Shell Transport Model for SNMP        July 2008


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

      removed references to engineIDs and discovery

      removed references to securityModel.

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

      added keyboard interactive discussion

      noted some implementation-dependent points

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

      cleaned up ASIs

      modified MIB to be under snmpModules

      changed transportAddressSSH to snmpSSHDomain style addressing

   From -05- to -06

      replaced transportDomainSSH with RFC3417-style snmpSSHDomain

      replaced transportAddressSSH with RFC3417-style snmpSSHAddress

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

   From -04- to -05

      added sshtmUserTable

      moved session tabel 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.




Harrington & Salowey    Expires January 12, 2009               [Page 39]


Internet-Draft    Secure Shell Transport Model for SNMP        July 2008


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

      changed tmSessionReference back to tmStateReference

   "From -03- to -04-"

      changed tmStateReference to tmSessionReference



   "From -02- to -03-"

      rewrote almost all sections

      merged ASI section and Elements of Procedure sections

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

      updated references

      creayted 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 secrtions 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"




Harrington & Salowey    Expires January 12, 2009               [Page 40]


Internet-Draft    Secure Shell Transport Model for SNMP        July 2008


      Removed unnecessary MIB module objects

      updated references

      improved consistency of references to TMSM as architectural
      extension

      updated conventions

      updated threats to be more consistent with RFC3552

      discussion of specific SSH mechanism configurations moved to
      security considerations

      modified session discussions to reference TMSM sessions

      expanded discussion of engineIDs

      wrote text to clarify the roles of MPSP and TMSP

      clarified how snmpv3 message parts are ised by SSHSM

      modified nesting of subsections as needed

      securityLevel used by the SSH Transport Model always equals
      authpriv

      removed discussion of using SSHSM with SNMPv1/v2c

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

      updated MIB module relationship to other MIB modules

   "From -00- to -01-"

      -00- initial draft as ISMS work product:

      updated references to SecSH 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





Harrington & Salowey    Expires January 12, 2009               [Page 41]


Internet-Draft    Secure Shell Transport Model for SNMP        July 2008


      ran the mib module through smilint

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






























Harrington & Salowey    Expires January 12, 2009               [Page 42]


Internet-Draft    Secure Shell Transport Model for SNMP        July 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

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

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

Intellectual Property

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

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

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












Harrington & Salowey    Expires January 12, 2009               [Page 43]