WDIFF

draft-ietf-isms-secshell-04.txt --> draft-ietf-isms-secshell-05.txt

Network Working Group D. Harrington
Internet-Draft Huawei Technologies (USA)
Intended status: Standards Track J. Salowey
Expires: December 25, 2006 April 14, 2007 Cisco Systems
June 23,
October 11, 2006

Secure Shell Security Transport Model for SNMP
draft-ietf-isms-secshell-04.txt
draft-ietf-isms-secshell-05.txt

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 December 25, 2006. April 14, 2007.

Abstract

This memo describes a Security Transport Model for the Simple Network
Management Protocol, using the Secure Shell protocol within a
Transport Mapping. protocol.

Harrington & Salowey Expires December 25, 2006 April 14, 2007 [Page 1]

Internet-Draft Secure Shell Security Transport Model for SNMP June October 2006

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. The Internet-Standard Management Framework . . . . . . . . 4
1.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Modularity . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 6 5
1.5. Constraints . . . . . . . . . . . . . . . . . . . . . . . 7
2. The Secure Shell Protocol . . . . . . . . . . . . . . . . . . 7
3. How SSHSM SSHTM Fits into the TMSM Architecture . Transport Subsystem . . . . . . . . . 8
3.1. Security Capabilities of this Model . . . . . . . . . . . 9 8
3.1.1. Threats . . . . . . . . . . . . . . . . . . . . . . . 9 8
3.1.2. SSHSM Sessions . . . . . . . . . . Data Origin Authentication Issues . . . . . . . . . . 11 9
3.1.3. Authentication Protocol . . . . . . . . . . . . . . . 11 10
3.1.4. Privacy Protocol . . . . . . . . . . . . . . . . . . . 12 11
3.1.5. Protection against Message Replay, Delay and
Redirection . . . . . . . . . . . . . . . . . . . . . 12 11
3.1.6. Security Protocol Requirements SSH Subsystem . . . . . . . . . . . . 12
3.2. Security Parameter Passing . . . . . . . . 11
3.1.7. Troubleshooting . . . . . . . . 13
3.3. Notifications and Proxy . . . . . . . . . . . 11
3.1.8. Mapping SSH to EngineID . . . . . . . . 14
4. Message Formats . . . . . . . 12
3.2. Security Parameter Passing . . . . . . . . . . . . . . . . 15
4.1. SNMPv3 Message Fields 13
3.3. Notifications and Proxy . . . . . . . . . . . . . . . . . 13
4. Passing Security Parameters . . 15
4.1.1. msgGlobalData . . . . . . . . . . . . . . . 14
4.1. tmStateReference . . . . . 17
4.1.2. msgSecurityParameters . . . . . . . . . . . . . . . . 17 14
4.2. Passing Security Parameters securityStateReference . . . . . . . . . . . . . . . 17
4.2.1. tmStateReference . . . 14
5. Elements of Procedure . . . . . . . . . . . . . . . . 17
4.2.2. securityStateReference . . . . 15
5.1. Procedures for an Incoming Message . . . . . . . . . . . . 18
5. Elements of Procedure 15
5.2. Procedures for an Outgoing Message . . . . . . . . . . . . 16
5.3. Establishing a Session . . . . . . . . 19
5.1. Generating an Outgoing SNMP Message . . . . . . . . . . 17
5.4. Closing a Session . 19
5.2. MPSP for an Outgoing Message . . . . . . . . . . . . . . . 20
5.2.1. MPSP Procedures . . . . 19
6. MIB Module Overview . . . . . . . . . . . . . . . 22
5.3. TMSP for an Outgoing Message . . . . . . 20
6.1. Structure of the MIB Module . . . . . . . . . 23
5.3.1. TMSP Procedures . . . . . . 20
6.2. Textual Conventions . . . . . . . . . . . . . 23
5.4. Processing an Incoming SNMP Message . . . . . . 20
6.3. The sshtmStats Subtree . . . . . 24
5.4.1. TMSP for an Incoming Message . . . . . . . . . . . . . 24
5.5. Prepare Data Elements from Incoming Messages 20
6.4. The sshtmUserTable . . . . . . . 25
5.6. MPSP for an Incoming Message . . . . . . . . . . . . . 20
6.5. Relationship to Other MIB Modules . . 25
5.7. Establishing a Session . . . . . . . . . . 20
6.5.1. MIB Modules Required for IMPORTS . . . . . . . . 27
5.8. Closing a Session . . . 21
7. MIB module definition . . . . . . . . . . . . . . . . . 29
6. Overview . . . 21
8. Security Considerations . . . . . . . . . . . . . . . . . . . . . . . . 29
6.1. Structure of the MIB Module . . . . . . . . . . . . . . . 30
6.2. Textual Conventions . . . . 29
8.1. noAuthPriv . . . . . . . . . . . . . . . 30
6.3. The sshsmStats Subtree . . . . . . . . . . . . . . . . . . 30
6.4. The sshsmsSession Subtree . . . . . . . . . . . . . . . 29
8.2. skipping public key verification . 30
6.5. Relationship to Other MIB Modules . . . . . . . . . . . . 30
6.5.1. Relationship to
8.3. the SNMPv2-MIB . . . 'none' MAC algorithm . . . . . . . . . 30
6.5.2. Relationship to the SNMP-FRAMEWORK-MIB . . . . . . . . 30
6.5.3. Relationship to the TMSM-MIB . . . . . . . . . . . . . 31

Harrington & Salowey Expires December 25, 2006 [Page 2]

Internet-Draft Secure Shell Security Model for SNMP June 2006

6.5.4. MIB Modules Required for IMPORTS . . . . . . . . . . . 31
7.
8.4. MIB module definition . security . . . . . . . . . . . . . . . . . . . 31
8. Security 30
9. IANA Considerations . . . . . . . . . . . . . . . . . . . 35
8.1. noAuthPriv . . . . . . . . . . . . . . . . . . . . . . . . 35
8.2. skipping public key verification . . . . . . . . . . . 31
10. Acknowledgements . . 36
8.3. the 'none' MAC algorithm . . . . . . . . . . . . . . . . . 36
8.4. MIB module security . . . . 31
11. References . . . . . . . . . . . . . . . 36
9. IANA Considerations . . . . . . . . . . . 32
11.1. Normative References . . . . . . . . . . 37
10. Acknowledgements . . . . . . . . . 32
11.2. Informative References . . . . . . . . . . . . . . 38
11. References . . . . 33

Harrington & Salowey Expires April 14, 2007 [Page 2]

Internet-Draft Secure Shell Transport Model for SNMP October 2006

Appendix A. Open Issues . . . . . . . . . . . . . . . . . . . . . 34
Appendix B. Change Log . 38
11.1. Normative References . . . . . . . . . . . . . . . . . . . 38
11.2. Informative References . . . . . . . . . . . . . . . . . . 40
Appendix A. Open Issues . . . . . . . . . . . . . . . . . . . . . 40
A.1. Closed Issues . . . . . . . . . . . . . . . . . . . . . . 40
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 45 34

Harrington & Salowey Expires December 25, 2006 April 14, 2007 [Page 3]

Internet-Draft Secure Shell Security Transport Model for SNMP June October 2006

1. Introduction

This memo describes a Security Transport Model for the Simple Network
Management Protocol, using the Secure Shell protocol within a
Transport Mapping Security Model extension
transport subsystem [I-D.ietf-isms-tmsm]. The
security transport model
specified in this memo is referred to as the Secure Shell Security Transport
Model (SSHSM). (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 Security Transport Model for SNMP.

It is important to understand the SNMP architecture and the
terminology of the architecture to understand where the Security 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

The terms "manager" and "agent" are not used in this document,
because in the RFC 3411 architecture, all SNMP entities have the
capability of acting as either manager or agent or both depending on
the SNMP applications included in the engine. Where distinction is
required, the application names of Command Generator, Command
Responder, Notification Generator, Originator, Notification Responder, 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

Harrington & Salowey Expires December 25, 2006 April 14, 2007 [Page 4]

Internet-Draft Secure Shell Security Transport Model for SNMP June October 2006

client or as server, as discussed further below.

While SSH and USM frequently refer to a user, the terminology used 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; and
combinations thereof. 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] [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.

1.3. Modularity

The reader is expected to have read and understood the description of
the SNMP architecture, as defined in [RFC3411],and [RFC3411], and the TMSM Transport
Subsystem architecture extension specified in "Transport Mapping Security Model
(TMSM) Architectural Extension Subsystem
for the Simple Network Management Protocol" [I-D.ietf-isms-tmsm], which enables the use of external
"lower layer" protocols to provide message security, tied into the
SNMP architecture through the transport mapping subsystem. One such
external protocol is the Secure Shell protocol [RFC4251]. [I-D.ietf-isms-tmsm].

This memo describes the Secure Shell Security Transport Model for SNMP, a
specific SNMP security transport model to be used within the SNMP Architecture, transport
subsystem to provide authentication, encryption, and integrity
checking of SNMP messages.

In keeping with the RFC 3411 design decisions to use self-contained
documents, this memo includes the elements of procedure plus
associated MIB objects which are needed for processing the Secure
Shell Security Transport Model for SNMP. These MIB objects SHOULD not NOT be
referenced in other documents. This allows the Secure Shell Security
Transport Model for SNMP to be designed and documented as independent
and self- contained, having no direct impact on other modules, and
allowing this module to be upgraded and supplemented as the need
arises, and to move along the standards track on different time-lines
from other modules.

This modularity of specification is not meant to be interpreted as
imposing any specific requirements on implementation.

Harrington & Salowey Expires December 25, 2006 [Page 5]

Internet-Draft Secure Shell Security Model for SNMP June 2006

1.4. Motivation

Version 3 of the Simple Network Management Protocol (SNMPv3) added
security to the previous versions of the protocol. The User Security Model (USM) [RFC3414]

Harrington & Salowey Expires April 14, 2007 [Page 5]

Internet-Draft Secure Shell Transport Model for SNMP October 2006

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 typically 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 at this point in time.

This memo describes a security transport model that will make use of the
existing and commonly deployed Secure Shell security infrastructure.
It
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 the time
until deployment is possible.

The work will address the requirement for the SSH client to
authenticate the SSH server, for the SSH server to authenticate the
SSH client, and describe how SNMP can make use of the authenticated
identities in message authentication and authorization policies for data access, in a manner
that is independent of any specific access control. control model.

The work will include the ability to use any of the client
authentication methods described in "SSH Authentication Protocol"
[RFC4252] - public key, password, and host-based. Local accounts may
be supported through the use of the public key, host-based or
password based mechanisms. The password based mechanism allows for
integration with deployed password infrastructure such as AAA servers
using the RADIUS protocol [RFC2865]. SSHSM The SSH Transport Model SHOULD
be able to take advantage of other defined authentication mechanism
such as those defined in [RFC4462] and future mechanisms such as
those that make use of X.509 certificate credentials. This will
allow SSHSM to the SSH Transport Model to utilize client authentication and
key exchange mechanisms which support different security
infrastructures and provide different security properties.

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
[I-D.ietf-netconf-ssh]. This memo describes a method for invoking
and running the SNMP protocol within a Secure Shell (SSH) session as
an SSH subsystem.

Harrington & Salowey Expires December 25, 2006 [Page 6]

Internet-Draft Secure Shell Security Model for SNMP June 2006

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.

Harrington & Salowey Expires April 14, 2007 [Page 6]

Internet-Draft Secure Shell Transport Model for SNMP October 2006

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 Security Transport Model is also influenced by the
following constraints:
1. When the requirements of effective management in times of network
stress are inconsistent with those of security, the design of
this model gives preference to effective management.
2. In times of network stress, the security 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).
3. When the network is not under stress, the security transport model and its
underlying security mechanisms MAY depend upon the ready
availability of other network services.
4. It may not be possible for the security transport model to determine when
the network is under stress.
5. A security transport model should require no changes to the SNMP
architecture.
6. A security transport model should require no changes to the underlying
security
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
components:
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.

The client sends a service request once a secure transport layer

Harrington & Salowey Expires December 25, 2006 [Page 7]

Internet-Draft Secure Shell Security Model for SNMP June 2006
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.

Harrington & Salowey Expires April 14, 2007 [Page 7]

Internet-Draft Secure Shell Transport Model for SNMP October 2006

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 SSHSM SSHTM Fits into the TMSM Architecture

SSH is a security layer which is plugged Transport Subsystem

A transport model plugs into the TMSM architecture
extension Transport Subsystem. The SSH
Transport Model thus fits between the underlying SSH transport layer
and the message dispatcher [RFC3411].

The SSHSM model SSH Transport Model will establish an encrypted tunnel between
itself and the
transport mappings SSH Transport Model of two another SNMP engines. engine. The
sending transport
mapping security model instance encrypts outgoing messages, passes unencrypted messages from the
dispatcher to SSH to be encrypyed, and the receiving transport mapping security model instance decrypts
accepts decrypted incoming messages from SSH and passes them to the
messages.
disptacher.

After the transport layer an SSH Transport model tunnel is established, then SNMP
messages can conceptually be sent through the tunnel from one SNMP
message dispatcher to another SNMP message dispatcher. Once the tunnel is
established, multiple Multiple SNMP
messages may be able to MAY be passed through the same tunnel.

Within an engine, outgoing SNMP messages are passed unencrypted from
the message dispatcher to the transport mapping, and incoming
messages are passed unencrypted from the transport mapping to the
message dispatcher.

SSHSM follows the TMSM approach, in which the security-model has two
separate areas of security processing - transport-mapping-related
security processing (TMSP) within the transport mapping section of
the dispatcher, and message processor security processing (MPSP)
which happens within the security model subsystem of the message
processor.

SSHSM security processing will be called from within the

The SSH Transport
Mapping functionality Model of an SNMP engine dispatcher to will perform the
translation of transport between SSH-specific security parameters to/from security-model-
independent parameters. Some SSHSM security processing will also be
performed within a message processing portion of the model, for
compatibility with the ASIs between the RFC 3411 Security Subsystem and the Message Processing Subsystem.

Harrington & Salowey Expires December 25, 2006 [Page 8]

Internet-Draft Secure Shell Security Model for SNMP June 2006 SNMP-
specific, model-independent parameters.

3.1. Security Capabilities of this Model

3.1.1. Threats

The security protocols used in this memo are considered acceptably
secure at the time of writing. However, the procedures allow for new
authentication and privacy methods to be specified at a future time
if the need arises.

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

1. Message stream modification - SSHSM SSH provides for verification that
each received SNMP message has not been modified during its
transmission through the network.
2. Information modification - SSHSM SSH provides for verification that the
contents of each received SNMP 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. non-maliciously.
3. Masquerade - SSHSM SSH provides for both verification of the identity
of the SSH server and verification of the identity of the SSH
client - the principal on whose behalf a received SNMP message
claims to have been generated. It is not possible to assure the
specific principal that originated a received SNMP message;
rather, it is the principal on whose behalf the message was

Harrington & Salowey Expires April 14, 2007 [Page 8]

Internet-Draft Secure Shell Transport Model for SNMP October 2006

originated that is authenticated. 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 will be used to map to an SNMP model-independent
securityName for use with SNMP access control.
5. Authenticating both the SSH server and the SSH client ensures the
authenticity of the SNMP engine that provides MIB data, whether
that engine resides on the server or client side of the
association. 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 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 - SSHSM the SSH Transport Model provides that the contents
of each received SNMP message are protected from disclosure to
unauthorized persons.

Harrington & Salowey Expires December 25, 2006 [Page 9]

Internet-Draft Secure Shell Security Model for SNMP June 2006
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.1.1.

3.1.2. Data Origin Authentication Issues

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

SSHSM extracts

The SSH Transport Model determines from SSH the identity of the
authenticated principal, and the type and address associated with an
incoming message, and
SSHSM 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 SSHSM SSH Transport Model layer.
In SNMPv3, we
The SNMPv3 WG deliberately avoided this and settled for an assertion,
using msgFlags, assertion
by the security model that auth and priv were applied according to the
rules requirements of the security model. However, SSHSM securityLevel were met
The SSH Transport Model has no mechanisms by which it can test

Harrington & Salowey Expires April 14, 2007 [Page 9]

Internet-Draft Secure Shell Transport Model for SNMP October 2006

whether an underlying SSH connection provides auth or priv to meet a desired msgFlags setting, priv, so the SSHSM
SSH Transport Model trusts that the underlying SSH connection has
been properly configured to support authPriv security characteristics at least as strong as requested in msgFlags.
characteristics.

The SSH does not understand msgFlags, and SSHSM Transport Model does not know about the algorithms or options for the SSH session
to open SSH sessions that match different securityLevels. For
interoperability of the trust assumptions between SNMP engines, an SSHSM-compliant
SSH Transport Model-compliant implementation MUST use an SSH
connection that provides authentication, data integrity and
encryption that meets the highest level of SNMP security (authPriv).
Outgoing messages requested by SNMP applications and specified with a
lesser securityLevel (noAuthNoPriv or authNoPriv) are sent by SSHSM the SSH
Transport Model as authPriv securityLevel. Other

The security models, where protocols used in the actual securityLevel applied to Secure Shell Authentication
Protocol [RFC4252] and the
connection can be determined or controlled, can be used when a lesser
level of security is desired.

Implementations SHOULD support whatever authentications are provided
by SSH. The security protocols used in [RFC4253] are Secure Shell Transport Layer Protocol
[RFC4253]are considered acceptably secure at the time of writing.
However, the procedures

Harrington & Salowey Expires December 25, 2006 [Page 10]

Internet-Draft Secure Shell Security Model for SNMP June 2006 allow for new authentication and privacy
methods to be specified at a future time if the need arises.

3.1.2. SSHSM Sessions

The Secure Shell security model will utilize TMSM sessions, with a
single combination of transportAddress, engineID, securityName,
securityModel, and securityLevel associated with each session. A
TMSM session is associated with state information that is maintained
for its lifetime. All SSHSM sessions will utilize the authPriv
securityLevel, and all incoming SSHSM messages will be treated as
having been delivered through authenticated, integrity-checked, and
encrypted connections.

SSHSM sessions are opened during the elements of procedure for an
outgoing SNMP message, never during the elements of procedure for an
incoming message. Implementations MAY choose to instantiate sessions
in anticipation of outgoing messages.

3.1.2.1. Message security versus session security

As part of session creation, the client and server entities are
authenticated and authorized access to the session. In addition, as
part of session establishment, cryptographic key material is
exchanged and is then used to control access to the session on a
message by message basis. Messages that fail the basic data origin
authenticaiton/ data integrity checks will be rejected.

3.1.3. Authentication Protocol

SSHSM

The SSH Transport Model should support any server or client
authentication mechanism supported by
SSH. This SSH.This includes the three
authentication methods described in the SSH Authentication Protocol
document [RFC4252] - publickey, password, and host-based. host-based - 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 [RFC 2617, draft-ietf-radext-digest-auth-04] to
integrate with RADIUS or Diameter. These mechanisms leave the
password in the clear on the device that is authenticating the
password which introduces threats to the authentication
infrastructure.

GSSKeyex [RFC4462] provides a framework for the addition of client

Harrington & Salowey Expires December 25, 2006 [Page 11]

Internet-Draft Secure Shell Security Model for SNMP June 2006
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.

Harrington & Salowey Expires April 14, 2007 [Page 10]

Internet-Draft Secure Shell Transport Model for SNMP October 2006

3.1.4. Privacy Protocol

The Secure Shell Security Model uses the SSH transport layer
protocol, which protocol provides strong encryption, server
authentication, and integrity protection.

3.1.5. Protection against Message Replay, Delay and Redirection

The Secure Shell Security Model uses the SSH transport layer
protocol.

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

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

3.1.6. SSH Subsystem

This would prevent capturing an document describes the use of an SSH subsystem for SNMP message and redirecting it to
another make
SNMP engine.

Message delay is not as important an issue with usage distinct from other usages.

SSH as it is with
USM. USM checks subsystems of type "snmp" are opened by the SSH Transport Model
during the timeliness elements of messages because it does not
provide procedure for an outgoing SNMP message. Since
the sender of a message initiates the creation of an SSH session protection if
needed, the SSH session will already exist for an incoming message or
the incoming message sequence ordering. The only
delay that would seem never reach the SSH Transport Model.

Implementations MAY choose to instantiate SSH sessions in
anticipation of outgoing messages. This approach might be possible would be useful to delay the
transmission of all packets from a particular point in a session
since
ensure that an SSH protects the ordering of packets.

3.1.6. Security Protocol Requirements

Modifying the Secure Shell protocol, or configuring session to a given target can be established
before it in becomes important to send a
particular manner, may change its security characteristics in ways message over the SSH session.
Of course, there is no guarantee that would impact other existing usages. If a change is necessary,
the change should pre-established session will
still be an extension that has no impact on valid when needed.

SSH sessions are uniquely identified within the existing
usages. This document will describe SSH Transport Model
by the use combination of an SSH subsystem for
SNMP to make SNMP usage distinct from other usages.

3.1.6.1. transportAddressType, transportAddress,
securityName, securityModel, and securityLevel, and engineID
associated with each session.

3.1.7. Troubleshooting

SSHSM

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, the use of USM a UDP transport
model should be considered instead of SSHSM. the SSH Transport Model.

Harrington & Salowey Expires December 25, 2006 April 14, 2007 [Page 12] 11]

Internet-Draft Secure Shell Security Transport Model for SNMP June October 2006

3.1.6.2. Coexistence

The Secure Shell security model can coexist with the USM security
model, the only other currently defined security model.

RFC3584 describes how to transfer fields between SNMPv3 and SNMPv1/
v2c messages. If necessary, the coexistence of SSHSM with v1/v2c can
be described in a different document. The translation of fields from
SNMPv3 messages will need detailed analysis, since SSHSM does not
fill the msgSecurityParameters the same way as USM.

3.1.6.3.

3.1.8. Mapping SSH to EngineID

In the RFC3411 architecture, there are three use cases for an
engineID:
snmpEngineID - RFC3411 includes the SNMP-FRAMEWORK-MIB, which
defines a snmpEngineID object. An snmpEngineID is the unique and
unambiguous identifier of an SNMP engine. Since there is a one-
to-one association between SNMP engines and SNMP entities, it also
uniquely and unambiguously identifies the SNMP entity within an
administrative domain.
contextEngineID - Management information resides at an SNMP entity
where a Command Responder Application has local access to
potentially multiple contexts. A Command Responder application
uses a contextEngineID equal to the snmpEngineID of its associated
SNMP engine, and the contextEngineID is included in a scopedPDU to
identify the engine associated with the data contained in the PDU.
securityEngineID - The securityEngineID is used by USM when
performing integrity checking and authentication, to look up
values in the USM tables, and to synchronize "clocks". The
securityEngineID is not needed by SSHSM, the SSH Transport Model, since
integrity checking and authentication are handled outside the SNMP
engine. The RFC3411 architecture defines ASIs that include a
securityEngineID;
SSHSM the SSH Transport Model should always set the
securityEngineID equal to the local value of snmpEngineID.0 to
satisfy the elements of procedure for generateRequestMsg() defined
in RFC3412. RFC3412.[RFC3412]
The SSH Transport Model needs to know the engineID of a target system
if the target system supports multiple engineIDs at the same address.
An engineID differentiates multiple engines residing at the same
transportAddress, and diferentiates the corresponding rows in the
Local Configuration Datastore.

This may occur if one SNMP engine is used to manage the host system,
and another to manage specific application functionality at the host,
such as a relational database system or a networking card.

The engineID can also be used to differentiate multiple engines
addressable at the same transport address, where messages for some
engineIDs are forwarded to different addresses using an SNMP
application, such as the SNMP proxy-forwarding application described
in RFC3413..

The engineID discovery mechanism is implementation-dependent.
[discuss: this is unacceptable because it is not interoperable. The
LCD can be implementation-dependent, but the discovery needs to be
either manual or interoperable. And given that USM addresses are not
the same as SSH addresses, we cannot even copy the info from the USM
discovery.]

Harrington & Salowey Expires April 14, 2007 [Page 12]

Internet-Draft Secure Shell Transport Model for SNMP October 2006

3.2. Security Parameter Passing

Security-model-specific parameters for an

For incoming message messages, SSH-specific security parameters are
determined from the SSH layer
translated by the transport mapping model into security
processor (TMSP), before parameters
independent of the message processing begins. transport and security models. The TMSP transport
model accepts (decrypted) messages from the SSH subsystem, and records the
transport-related information and the security-related SSH-security-related information, including the
authenticated identity, in a cache referenced by
tmSessionReference, tmStateReference,
and passes the WholeMsg and the
tmSessionReference tmStateReference to the MPSP (via dispatcher
using the dispatcher).

Harrington & Salowey Expires December 25, 2006 [Page 13]

Internet-Draft Secure Shell Security Model for SNMP June 2006 recvMessage() ASI.

For outgoing messages, the security-model-specific parameters are
gathered by the messaging-security-processor (MPSP) and passed with
the outgoing message to the transport mapping. The MPSP portion of
the security model creates the WholeMsg from its component parts. In
the SSHSM model, an SNMPv3 message is built without any content in
the SecurityParameters field of the message, and the WholeMsg is
passed unencrypted back to the Message Processing Model for
forwarding to the Transport Mapping. The MPSP takes input provided by
the SNMP application, dispatcher in the sendMessage() ASI. The SSH Transport Model
converts that information into suitable security parameters for SSHSM, and passes these in a cache referenced
by tmSessionReference to the TMSP (via the dispatcher). The TMSP SSH,
establishes sessions as needed needed, and passes messages to the SSH
subsystem for processing.

The cache reference is an additional parameter in the ASIs between
the transport mapping and the messaging security model.

This approach does create dependencies between a model-specific TMSP
and a corresponding specific MPSP. Passing a model-independent cache
reference as a parameter in an ASI is consistent with the
securityStateReference cache already being passed around in the ASI. sending.

3.3. Notifications and Proxy

SSH connections may be initiated by command generators or by
notification originators. Command generators are frequently operated
by a human, but notification originators frequently are usually unmanned
automated processes. As a result, it usually will 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 SNMP-TARGET-MIB 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 SSHSM, the SSH Transport Model, transport type and address are
configured in the snmpTargetAddrTable, and the securityModel,
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.

Harrington & Salowey Expires December 25, 2006 April 14, 2007 [Page 14] 13]

Internet-Draft Secure Shell Security Transport Model for SNMP June October 2006

4. Message Formats

The syntax of an SNMP message using this Passing Security Model adheres Parameters

For the SSH Transport Model, there are two levels of state that need
to be maintained: the session state, and the message format defined in state.

4.1. tmStateReference

For each connection, the version-specific Message Processing SSH Transport Model document (for example [RFC3412]). At stores information about
the time connection in the Local Configuration Datastore, supplemented
with a cache to store model- and mechanism-specific parameters.

Upon opening an SSH connection, the SSH Transport Model will store
the transport parameters in the LCD. For ease of understanding, this writing,
there are three defined message formats - SNMPv1, SNMPv2c, and
SNMPv3. SNMPv1 and SNMPv2c have been declared Historic, so
document represents the LCD as an SSHTM-MIB module.
tmsLCDTransport = transportDomainSSH
tmsLCDAddress = a TransportAddressSSH
tmsLCDSecurityLevel = "authPriv"
tmsLCDSecurityName = the principal name authenticated by SSH. How
this memo
only deals with SNMPv3 messages.

The processing data is compatible with extracted from the RFC 3412 primitives,
generateRequestMsg() SSH environment and processIncomingMsg(), how it is
translated into a securityName is implementation-dependent. By
default, the tmSecurityName is the name that show has been successfully
authenticated by SSH, from the data
flow between user name field of the Message Processor and
SSH_MSG_USERAUTH_REQUEST message.
tmsLCDEngineID = if known, the MPSP.

4.1. SNMPv3 Message Fields value of the remote engine's
snmpEngineID.
tmsLCDSecurityModel = a security model. The SNMPv3Message SEQUENCE SSH Transport Model
is defined in [RFC3412] and [RFC3416].

Harrington & Salowey Expires December 25, 2006 [Page 15]

Internet-Draft Secure Shell designed to work with multiple security models. the default is
the Transport Security Model for SNMP June 2006

SNMPv3MessageSyntax DEFINITIONS IMPLICIT TAGS ::= BEGIN

SNMPv3Message ::= SEQUENCE {
-- identify Model.

How the layout of SSH identity is extracted from the SNMPv3Message
-- this element SSH layer, and how the SSH
identity is mapped to a securityName for storage in same position the LCD is
implementation-dependent. Additional information may be stored in a
local datastore (such as a preconfigured mapping table) or in SNMPv1
-- and SNMPv2c, allowing recognition
-- a
cache, such as the value 3 of an SSH session identifier (as distinct
from an SNMP session).

The tmStateReference is used to pass references containing the
appropriate SSH session information from the transport model for snmpv3
msgVersion INTEGER ( 0 .. 2147483647 ),
-- administrative parameters
msgGlobalData HeaderData,
-- security model-specific parameters
-- format defined by Security
subsequent processing.

The SSH Transport Model
msgSecurityParameters OCTET STRING,
msgData ScopedPduData
}

HeaderData ::= SEQUENCE {
msgID INTEGER (0..2147483647),
msgMaxSize INTEGER (484..2147483647),

msgFlags OCTET STRING (SIZE(1)),
-- .... ...1 authFlag
-- .... ..1. privFlag
-- .... .1.. reportableFlag
-- Please observe:
-- .... ..00 is OK, means noAuthNoPriv
-- .... ..01 is OK, means authNoPriv
-- .... ..10 reserved, MUST NOT be used.
-- .... ..11 has the responsibility for explicitly
releasing the complete tmStateReference and deleting the associated
information from the LCD when the session is OK, means authPriv

msgSecurityModel INTEGER (1..2147483647)
}

ScopedPduData ::= CHOICE {
plaintext ScopedPDU,
encryptedPDU OCTET STRING -- encrypted scopedPDU value
}

ScopedPDU ::= SEQUENCE {
contextEngineID OCTET STRING,
contextName OCTET STRING,
data ANY -- e.g., PDUs as defined in [RFC3416]
}
END

The following describes how SSHSM treats certain fields in destroyed.

4.2. securityStateReference

For each message received, the
message: SSH Transport Model caches message-
specific SSH security information such that a Response message can be

Harrington & Salowey Expires December 25, 2006 April 14, 2007 [Page 16] 14]

Internet-Draft Secure Shell Security Transport Model for SNMP June October 2006

4.1.1. msgGlobalData

msgGlobalData is opaque to SSHSM. The values are set by the Message
Processing model (e.g., SNMPv3 Message Processing), and are not
modified by SSHSM.

msgMaxSize is determined by the implementation.

To avoid

generated using the need to mess with same security information, even if the ASN.1 encoding, msgGlobalData
contains Local
Configuration Datastore is altered between the value time of msgFlags set by the Message Processing model
(e.g., SNMPv3 Message Processing), not incoming
request and the actual (authPriv)
securityLevel applied outgoing response. The securityStateReference is
used to preserve the data needed to generate a Response message by SSHSM.

msgSecurityModel is set by with
the same security information. This information includes the model-
independent parameters (securityName, securityLevel, securityModel,
transport address, transport type, and engineID). The Message
Processing model (e.g.,
SNMPv3) to Model has the IANA-assigned value responsibility for explicitly releasing the Secure Shell Security
Model. See http://www.iana.org/assignments/snmp-number-spaces.

4.1.2. msgSecurityParameters

Since message security is provided by a "lower layer", and the
securityName parameter
securityStateReference when such data is always determined from the SSH
authentication method, the SNMP message does not need to carry
message security parameters within the msgSecurityParameters field. no longer needed. The field msgSecurityParameters in SNMPv3 messages has a
securityStateReference cached data type of
OCTET STRING. To prevent its being used in a manner that could be
damaging, such as for carrying a virus or worm, when used with SSHSM
its value MUST may be implicitly released via the BER serialization
generation of a zero-length OCTET
STRING.

SSHSMSecurityParametersSyntax DEFINITIONS IMPLICIT TAGS ::= BEGIN

SSHsmSecurityParameters ::=
SEQUENCE {
OCTET STRING
}
END

4.2. Passing Security Parameters

For SSHSM, there are two levels of state response, or explicitly released by using the
stateRelease primitive, as described in RFC 3411 section 4.5.1."

The SSH standard does not require that need to an SSH session be maintained: maintained
nor that it be closed when the session state, and keys associated with the message state.

4.2.1. tmStateReference

For each session, SSHSM stores information about host or
client associated with the session in are changed. Some SSH
implementations might close an existing session if the
Local Configuration Datastore, supplemented keys
associated with a cache to store
model- and mechanism-specific parameters.

Harrington & Salowey Expires December 25, 2006 [Page 17]

Internet-Draft Secure Shell Security Model for SNMP June 2006

Upon opening an SSH connection, the TMSP will store session change. For the transport
parameters in SSH Transport Model, if
the tmSessionTable of session is closed between the TMSM-MIB [I-D.ietf-isms-tmsm]
for subsequent usage.

tmsmSessionID = a unique local identifier
tmsmTransport = transportDomainSSH
tmsmSessionAddress = time a TransportAddressSSH
tmsmSessionSecurityModel - SSHSM
tmsmSessionSecurityLevel = "authPriv"
tmsmSessionSecurityName = the principal name authenticated by SSH.
How this data Request is extracted from the SSH environment received and how it is
translated into a securityName is implementation-dependent. By
default, the tmSecurityName
Response message is being prepared, then the name that has been successfully
authenticated by SSH, from the user name field Response should be
discarded.

5. Elements of Procedure

Abstract service interfaces have been defined by RFC 3411 to describe
the
SSH_MSG_USERAUTH_REQUEST message.
tmsmSessionEngineID = if known, conceptual data flows between the value 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 remote engine's
snmpEngineID.

How the SSH identity is extracted from the SSH layer, and how elements of procedure, the SSH
identity release of state
information is mapped to not always explicitly specified. As a securityName for storage in tmsmSessionTable general rule,
if state information is implementation-dependent. Additional available when a message gets discarded, the
message-state information may should also be stored in
a local datastore (such as a preconfigured mapping table) or in released, and if state
information is available when a
cache, such as the value of an SSH session identifier (as distinct
from the tmsmSessionID).

The tmSessionReference is used to pass references to closed, the appropriate session state
information between the TMSP should also be released.

An error indication may return an OID and MPSP through the ASIs.

The SSHSM has the responsibility value for explicitly releasing the
complete tmSessionReference an incremented
counter and deleting the associated
tmsmSessionEntry in a value for securityLevel, and values for contextEngineID
and contextName for the tmsmSessionTable when counter, and the session is
destroyed.

4.2.2. securityStateReference

For each message received, SSHSM caches message-specific security
information such that a Response message can be generated using the
same security information, even if
the Configuration Datastore information is
altered between the time of available at the incoming request and point where the outgoing
response. The securityStateReference error is used to preserve the data
needed to generate a Response message with the same security
information. This information includes the model-independent
parameters (securityName, securityLevel, transport address, and
transport type). The Message Processing Model has the responsibility
detected.

5.1. Procedures for explicitly releasing an Incoming Message

For an incoming message, the securityStateReference when such data is
no longer needed. The securityStateReference cached data may be
implicitly released via SSH Transport Model will put information
from the generation of SSH layer into a response, or explicitly
released Local Configuration Datastore referenced by using the stateRelease primitive, as described in RFC

Harrington & Salowey Expires December 25, 2006 April 14, 2007 [Page 18] 15]

Internet-Draft Secure Shell Security Transport Model for SNMP June October 2006

3411 section 4.5.1."

tmStateReference.

1) The SSH standard does not require that a session be maintained nor
that it be closed when the keys associated with Transport Model queries the host or client associated with the session are changed. Some SSH implementations
might close engine, in
an existing session if implementation-dependent manner, to determine the keys associated with transport and
security parameters for the
session change. For SSHSM, if received message.

transportDomain = transportDomainSSH
transportAddress = a TransportAddressSSH
tmsTransportModel - SSH Transport Model
tmsSecurityLevel = "authPriv"
tmsSecurityName = the session principal name authenticated by SSH. How
this data is closed between extracted from the time
a Request is received SSH environment and how it is
translated into a Response message securityName is being prepared, then implementation-dependent. By
default, the Response should be discarded.

The parameters associated with an incoming request message to be
applied to tmSecurityName is the outgoing response.
messageProcessingModel = SNMPv3
securityModel = SSHSM
sessionID = tmSessionID

5. Elements of Procedure

Abstract service interfaces have name that has been defined
successfully authenticated by RFC 3411 to describe
the conceptual data flows between the various subsystems within an
SNMP entity. The Secure Shell Security Model uses some of these
conceptual data flows when communicating between subsystems, such as
the dispatcher and the Message Processing Subsystem. These RFC 3411-
defined data flows are referred to here as public interfaces.

To simplify SSH, from the elements user name field of procedure,
the release of state
information is SSH_MSG_USERAUTH_REQUEST message.
2) If one does not always explicitly specified. As a general rule,
if state information is available when a message gets discarded, exist, the
message-state information should also be released, and if state
information is available when SSH Transport Model creates an entry
in a session is closed, Local Configuration Datastore, in an implementation-dependent
format, containing the session state information should also be released.

An error indication may return an OID and value for an incremented
counter any implementation-specific
parameters desired, and creates a value for securityLevel, and values for contextEngineID
and contextName tmStateReference for subsequent
reference to the counter, and the securityStateReference if information.

Then the information is available at Transport model passes the point where message to the error is
detected.

5.1. Generating an Outgoing SNMP Message

This section describes Dispatcher using
the procedure followed by an RFC3411-
compatible system whenever it generates a message containing a
management operation (such as a request, a response, a notification,
or a report) on behalf of a user.

Harrington & Salowey Expires December 25, 2006 [Page 19]

Internet-Draft Secure Shell Security Model for SNMP June 2006 following primitive:
statusInformation = -- success or errorIndication
prepareOutgoingMessage(
IN
recvMessage(
OUT transportDomain -- transport domain to be used
IN for the received message
OUT transportAddress -- transport address to be used
IN messageProcessingModel -- typically, SNMP version
IN securityModel -- Security Model to use
IN securityName -- on behalf of this principal
IN securityLevel -- Level of Security requested
IN contextEngineID -- data from/at this entity
IN contextName for the received message
OUT wholeMessage -- data from/in this context
IN pduVersion the whole SNMP message from SSH
OUT wholeMessageLength -- the version length of the PDU
IN PDU -- SNMP Protocol Data Unit
IN expectResponse -- TRUE or FALSE
IN sendPduHandle -- the handle for matching
incoming responses message
OUT tmStateReference
)

5.2. Procedures for an Outgoing Message

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

statusInformation =
sendMessage(
IN destTransportDomain -- destination transport domain
OUT to be used
IN destTransportAddress -- destination transport address
OUT to be used
IN outgoingMessage -- the message to send
OUT
IN outgoingMessageLength -- its length
IN tmStateReference
)

Harrington & Salowey Expires April 14, 2007 [Page 16]

Internet-Draft Secure Shell Transport Model for SNMP October 2006

The IN parameters of the prepareOutgoingMessage() ASI are used to
pass information from SSH Transport Model performs the dispatcher (for following tasks:

1) Determine the application subsystem)
to target 5-tuple index by extracting the message processing subsystem.

The abstract service primitive
transportDomain, transportAddress, securityName, securityLevel,
and securityModel from a Message Processing Model to a
Security Model to generate the components of a Request message is
generateRequestMsg(), as described in Section 5.2.

The abstract service primitive from a Message Processing Model to a
Security Model to generate tmStateReference.
2) Lookup the components of a Response message is
generateResponseMsg(), as described session in Section 5.2.:

Upon completion of the MPSP processing, Local Configuration Datastore using
the SSH Security module
returns statusInformation. target index
3) If the process was successful, the
completed message there is returned, without the privacy and authentication
applied yet. If no session open associated with the process was not successful, target index,
then call openSession().
3a) If an
errorIndication error is returned.

The OUT parameters are used to pass information returned from OpenSession(), then discard the
message
processing subsystem to the dispatcher and on to return the transport
mapping:

5.2. MPSP for an Outgoing Message

This section describes error indication in the procedure followed by statusInformation.
3b) If openSession() is successful, then store any implementation-
specific information in the Secure Shell
Security Model.

Harrington & Salowey Expires December 25, 2006 [Page 20]

Internet-Draft Secure Shell Security Model LCD for SNMP June 2006

The subsequent use.
4) Extract any implementation-specific parameters needed for generating a message are supplied to from the
MPSP by LCD
5) Pass the Message Processing wholeMessage to SSH for encapsulation in an
SSH_MSG_CHANNEL_DATA message.

5.3. Establishing a Session

The Secure Shell Transport Model via provides the generateRequestMsg() or following primitive to
describe the generateResponseMsg() ASI. The TMSM architectural extension has
added data passed between the transportDomain, transportAddress, Transport Model and tmSessionReference
parameters to the original RFC3411 ASIs. SSH
service. It is an implementation decision how such data is passed.

statusInformation = -- success or errorIndication
generateRequestMsg(
IN messageProcessingModel -- typically, SNMP version
IN globalData -- message header, admin data
IN maxMessageSize -- of the sending SNMP entity
openSession(
IN transportDomain destTransportDomain -- as specified by application transport domain to be used
IN transportAddress destTransportAddress -- as specified by application transport address to be used
IN securityModel -- for the outgoing message
IN securityEngineID -- authoritative SNMP entity Security Model to use
IN securityName -- on behalf of this principal
IN securityLevel -- Level of Security requested
IN scopedPDU -- message (plaintext) payload
OUT securityParameters -- filled in by Security Module
OUT wholeMsg -- complete generated message
OUT wholeMsgLength -- length of generated message
OUT tmSessionReference -- reference to session info
)

statusInformation = -- success or errorIndication
generateResponseMsg(
IN messageProcessingModel -- typically, SNMP version
IN globalData -- message header, admin data
IN maxMessageSize -- of the sending SNMP entity
IN transportDomain -- as specified by application
IN transportAddress -- as specified by application
IN securityModel -- for
OUT tmStateReference
)

The following describes the outgoing message
IN securityEngineID -- authoritative SNMP entity
IN securityName -- on behalf of this principal
IN securityLevel -- Level of Security requested
IN scopedPDU -- message (plaintext) payload
IN securityStateReference -- reference procedure to security state
-- information from original
-- request
OUT securityParameters -- filled in follow to establish a
session between a client and server to run SNMP over SSH. This
process is followed by Security Module
OUT wholeMsg -- complete generated message
OUT wholeMsgLength -- length of generated message
OUT tmSessionReference -- reference 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.

The need to establish a session info
) is never triggered by an application
sending a response message, such as a Command Responder or
Notification Receiver, because securityStateReference will always
have the information for an existing session, identifiable via

Harrington & Salowey Expires December 25, 2006 April 14, 2007 [Page 21] 17]

Internet-Draft Secure Shell Security Transport Model for SNMP June October 2006

o statusInformation - An indication of whether the construction of

tmStateReference. [todo: where in the message was successful. If not it contains an indication of EoP is this put into the problem.
o messageProcessingModel -
dataflow? The SNMP version number for the message transport model should only see a wholemessage, so it
doesn't know if this is a response; that has to be generated.
o globalData - The message header (i.e., its administrative
information). This data is opaque done by the
messaging model. Do we have to SSHSM.
o maxMessageSize - The maximum message size as included in worry about a session being shutdown
while the
message. This data request is not used by SSHSM.
o transportDomain - as specified by the application.
o transportAddress - as specified by the application.
o securityModel - The securityModel in use. In this case, between messaging and transport?]

1) Using destTransportDomain and destTransportAddress, the client
will establish an SSH
Security Model.
o securityEngineID - SSHSM always sets this to transport connection using the snmpEngineID of SSH transport
protocol, authenticate the sending SNMP engine.
o securityName - identifies a principal to be used server, and exchange keys for securing an
outgoing message. message
integrity and encryption. The securityName has a format that is
independent parameters of the Security Model. In case of a response this
parameter is ignored transport connection
and the value from credentials used to authenticate are provided in an
implementation-dependent manner.

If the securityStateReference
cache attempt to establish a connection is used.
o securityLevel - Ignored by SSHSM, which always uses unsuccessful, or server
authentication fails, then an authPriv
securityLevel.
o scopedPDU - The message payload. The scopedPDU is opaque to
SSHSM.
o securityStateReference - A handle/reference to cachedSecurityData
that error indication is returned, and
openSession processing stops.

2) The provided transport domain, transport address, securityModel,
securityName and securityLevel are used when sending to lookup an outgoing Response message. This is associated entry
in the exact same securityStateReference as was generated by Local Configuration Datastore (LCD). Any model-specific
information concerning the SSH
Security module when processing principal at the incoming Request message to
which this destination is the Response message.
o securityParameters - Always set extracted.
This step allows preconfiguration of model-specific principals mapped
to empty by SSHSM.
o wholeMsg - The fully encoded SNMP message ready the transport/name/level, for example, for sending on notifications.
Set the
wire.
o wholeMsgLength - The length of username in the encoded SNMP message
(wholeMsg).
o tmSessionReference - a handle/reference SSH_MSG_USERAUTH_REQUEST to the session username
extracted from the LCD.

If information
to be passed to about the TMSP portion of principal is absent from the SSH Security Model.
Note that SSHSM adds transportDomain, transportAddress, LCD, then set
the username in the SSH_MSG_USERAUTH_REQUEST to the value of
securityName. This allows a deployment without preconfigured
mappings between model-specific and
tmSessionReference have been added model-independent names, but the
securityName will need to these ASIs.

5.2.1. MPSP Procedures

1) verify that securityModel is sshsmSecurityModel. contain a username recognized by the
authentication mechanism.

3)The client will then invoke the "ssh-userauth" service to
authenticate the user, as described in the SSH authentication
protocol [RFC4252]. [todo: does the client invoke this, or the
server?]

If not, the authentication is unsuccessful, then the transport connection
is closed, tmStateReference is released, the message is discarded, an
error indication (unknownSecurityName) is returned to the calling message model,
module, and
MPSP processing stops for this message.
2) If there is a securityStateReference, then extract

4) Once the
tmSessionReference from principal has been successfully authenticated, the cachedSecurityData. At this point, client
will invoke the SecurityDataCache can now be released. "ssh- connection" service, also known as the SSH
connection protocol [RFC4254].

5) After the ssh-connection service is established, the client will

Harrington & Salowey Expires December 25, 2006 April 14, 2007 [Page 22] 18]

Internet-Draft Secure Shell Security Transport Model for SNMP June October 2006

2b)

use an SSH_MSG_CHANNEL_OPEN message to open a channel of type
"session", providing a selected sender channel number, and a maximum
packet size calculated from the SNMP maxMessageSize.

6) If successful, this will result in an SSH session. The
destTransportDomain and the session referenced by securityStateReference does not
still exist (i.e., destTransportAddress, plus the session used to receive "recipient
channel" and "sender channel" and other relevant data from the request is no
longer available
SSH_MSG_CHANNEL_OPEN_CONFIRMATION should be retained so they can be
added to send the corresponding response) then the
tmsmSessionNoAvailableSessions counter is incremented, an error
indication is returned to LCD for subsequent use.

7) Once the calling module, SSH session has been established, the message is
discarded, 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 MPSP processing stops for this message.
3) If there 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 no securityStateReference, then find or create
established using the IANA-assigned TCP port (TBD by IANA). Servers
SHOULD be configurable to allow access to the SNMP SSH subsystem over
other ports.

8) Create an entry in a Local Configuration Datastore containing the
provided transportDomain, transportAddress, securityName,
securityLevel, and securityModel, and SSH-speciifc parameters and
create a tmSessionReference tmStateReference to reference the entry.
4) fill in the securityParameters with the serialization

9) At this point an implementation MAY perform some type of engineID
discovery to determine a
zero-length OCTET STRING.
5) Combine mapping between the message parts into a wholeMsg remote transport
address, the SSH session, and calculate
wholeMsgLength.
6) a contextEngineID.

The completed message (wholeMsg) with its length
(wholeMsgLength) and securityParameters (a zero-length octet
string) and tmSessionReference is returned contextEngineID of a remote engine needs to be "discovered" for
use in request messages. USM, the calling module
with mandatory-to-implement security
model, can perform discovery of the statusInformation set to success.

The Message Processing Model then passes information to snmpEngineIDs of adjacent engines
using Reports (see [RFC3414] section 3.2 3b). Then the
disptacher discovered
snmpEngineID for forwarding to the remote engine can be used as the contextEngineID
in requests passed using the SSH Transport Mapping.

5.3. TMSP for an Outgoing Message Model.

5.4. Closing a Session

The Dispatcher passes Secure Shell Transport Model provides the information following primitive to
pass data back and forth between the Transport Mapping using
the ASI defined in Model and the TMSM extension:

statusInformation SSH
service:

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
closeSession(
IN tmSessionReference tmStateReference
)

Harrington & Salowey Expires April 14, 2007 [Page 19]

Internet-Draft Secure Shell Transport Model for SNMP October 2006

The TMSP portion of the SSHSM performs the following tasks:

5.3.1. TMSP Procedures

7) Lookup describes the procedure to follow to close a session in
between a client and sever . This process is followed by any SNMP
engine closing the Local Configuration Datastore using corresponding SNMP session.

1) Determine the target 5-tuple index by extracting the
transportDomain, transportAddress, securityName, securityLevel,
and securityModel from the tmSessionReference.
Extract any implementation-specific parameters from tmStateReference.
2) Lookup the LCD.

Harrington & Salowey Expires December 25, 2006 [Page 23]

Internet-Draft Secure Shell Security Model for SNMP June 2006

8) session in the Local Configuration Datastore using
the target index
3) If there is no session open associated with the
transportDomain, transportAddress, securityName, securityLevel,
and securityModel, target index,
then call openSession(). If an error closeSession processing is
returned from OpenSession(), then discard the message and return
the error indication in the statusInformation.
9) Store completed..
4) Extract any implementation-specific information in parameters from the LCD for
subsequent use.
10) Pass the wholeMessage to
5) Have SSH for encapsulation in an
SSH_MSG_CHANNEL_DATA message.

5.4. Processing an Incoming SNMP Message

5.4.1. TMSP for an Incoming Message

For an incoming message, close the TMSP will need to put information from specified session.

6. MIB Module Overview

This MIB module provides management of the SSH layer into a Local Configuration Datastore referenced by
tmSessionReference.

1) The SSHSM queries Secure Shell Transport
Model. It defines some needed textual conventions, and some
statistics.

6.1. Structure of the associated SSH engine, MIB Module

Objects in an
implementation-dependent manner, to determine the transport and
security parameters for the received message.

transportDomain = transportDomainSSH
transportAddress = a TransportAddressSSH
tmsmSecurityModel - SSHSM
tmsmSecurityLevel = "authPriv"
tmsmSecurityName = the principal name authenticated by SSH.
How this data is extracted from the SSH environment and how it
is translated MIB module are arranged into a securityName is implementation-dependent.
By default, the tmSecurityName subtrees. Each subtree
is the name that has been
successfully authenticated by SSH, from the user name field organized as a set of related objects. The overall structure and
assignment of objects to their subtrees, and the SSH_MSG_USERAUTH_REQUEST message.
2) If one does not exist, the TMSP creates an entry in a Local
Configuration Datastore, intended purpose of
each subtree, is shown below.

6.2. Textual Conventions

Generic and Common Textual Conventions used in an implementation-dependent format,
containing the this document can be
found summarized at http://www.ops.ietf.org/mib-common-tcs.html

6.3. The sshtmStats Subtree

This subtree contains SSH transport-model-dependent counters.

This subtree provides information and any implementation-specific
parameters desired, and creates a tmSessionReference for
subsequent reference to the information.

Then the identifying fault conditions
and performance degradation.

6.4. The sshtmUserTable

This table contains SSH Transport mapping passes the message Model information about SSH
principals.

6.5. Relationship to Other MIB Modules

Some management objects defined in other MIB modules are applicable
to an entity implementing the Dispatcher using
the following primitive:
statusInformation =
recvMessage(
OUT transportDomain -- domain for the received message
OUT transportAddress -- address for the received message
OUT wholeMessage -- the whole SNMP message from SSH
OUT wholeMessageLength -- the length of the SNMP message
OUT tmSessionReference
) Transport Model. In particular, it

Harrington & Salowey Expires December 25, 2006 April 14, 2007 [Page 24] 20]

Internet-Draft Secure Shell Security Transport Model for SNMP June October 2006

5.5. Prepare Data Elements from Incoming Messages

The abstract service primitive from the Dispatcher to a Message
Processing Model for a received message is:

result = -- SUCCESS or errorIndication
prepareDataElements(
IN transportDomain -- origin transport domain
IN transportAddress -- origin transport address
IN wholeMsg -- as received from the network
IN wholeMsgLength -- as received from the network
IN tmSessionReference -- from the transport mapping
OUT messageProcessingModel -- typically, SNMP version
OUT securityModel -- Security Model to use
OUT securityName -- on behalf of this principal
OUT securityLevel -- Level of Security requested
OUT contextEngineID -- data from/at this entity
OUT contextName -- data from/in this context
OUT pduVersion -- the version of the PDU
OUT PDU -- SNMP Protocol Data Unit
OUT pduType -- SNMP PDU type
OUT sendPduHandle -- handle for matched request
OUT maxSizeResponseScopedPDU -- maximum size sender can accept
OUT statusInformation -- success or errorIndication
-- error counter OID/value if error
OUT stateReference -- reference to state information
-- to be used for possible Response
)

Note

is assumed that tmSessionReference has been added to this ASI.

5.6. MPSP for an Incoming Message

This section describes entity implementing the procedure followed by SSHTM-MIB will implement
the MPSP whenever it
receives an incoming message containing a management operation on
behalf of a user from a Message Processing model.

The Message Processing Model extracts some information from SNMPv2-MIB [RFC3418], the
wholeMsg. The abstract service primitive from a Message Processing
Model to SNMP-FRAMEWORK-MIB [RFC3411] and the Security Subsystem
Transport-Subsystem-MIB [I-D.ietf-isms-tmsm].

This MIB module is for a received message is::

Harrington & Salowey Expires December 25, 2006 [Page 25]

Internet-Draft Secure Shell Security managing SSH Transport Model information.
This MIB module models a sample Local Configuration Datastore.

6.5.1. MIB Modules Required for IMPORTS

The following MIB module imports items from [RFC2578], [RFC2579],
[RFC2580], [RFC3411], [RFC3419], and [I-D.ietf-isms-tmsm]

This MIB module also references [RFC3490]

7. MIB module definition

SSHTM-MIB DEFINITIONS ::= BEGIN

IMPORTS
MODULE-IDENTITY, OBJECT-TYPE,
OBJECT-IDENTITY, mib-2, snmpDomains
FROM SNMPv2-SMI
TestAndIncr, TEXTUAL-CONVENTION,
StorageType, RowStatus
FROM SNMPv2-TC
MODULE-COMPLIANCE, OBJECT-GROUP
FROM SNMPv2-CONF
SnmpAdminString
FROM SNMP-FRAMEWORK-MIB
TransportAddress, TransportAddressType
FROM TRANSPORT-ADDRESS-MIB
;

sshtmMIB MODULE-IDENTITY
LAST-UPDATED "200610050000Z"
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

Harrington & Salowey Expires April 14, 2007 [Page 21]

Internet-Draft Secure Shell Transport Model for SNMP June 2006

statusInformation = -- errorIndication or success
-- error counter OID/value if error
processIncomingMsg(
IN messageProcessingModel -- typically, SNMP October 2006

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

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

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

Copyright (C) The Internet Society (2006). This
version
IN maxMessageSize -- of this MIB module is part of RFC XXXX;
see the sending SNMP entity
IN securityParameters -- RFC itself for the received message
IN securityModel full legal notices.
-- NOTE to RFC editor: replace XXXX with actual RFC number
-- for the received message
IN securityLevel this document and remove this note
"

REVISION "200610050000Z" -- Level of Security
IN wholeMsg 02 September 2005
DESCRIPTION "The initial version, published in RFC XXXX.
-- as received on the wire
IN wholeMsgLength NOTE to RFC editor: replace XXXX with actual RFC number
-- length as received on the wire
IN tmSessionReference for this document and remove this note
"

::= { mib-2 xxxx }
-- from the transport mapping
OUT securityEngineID -- authoritative SNMP entity
OUT securityName -- identification of the principal
OUT scopedPDU, RFC Ed.: replace xxxx with IANA-assigned number and
-- message (plaintext) payload
OUT maxSizeResponseScopedPDU remove this note

-- maximum size sender can handle
OUT securityStateReference ---------------------------------------------------------- -- reference to security state
)
-- information, needed for response

1) The securityEngineID is set to the local snmpEngineID, to satisfy
the SNMPv3 message processing model in RFC 3412 section 7.2 13a).

2) Extract the value of securityName from the Local Configuration
Datastore entry referenced by tmSessionReference.

3) The scopedPDU component is extracted from the wholeMsg.

4) The maxSizeResponseScopedPDU is calculated. This is the maximum
size allowed for a scopedPDU for a possible Response message.

5)The security data is cached as cachedSecurityData, so that a
possible response to this message can and will use the same security
parameters. Then securityStateReference is set for subsequent
reference to this cached data. For SSHSM, the securityStateReference
should include a reference to the tmSessionReference.

3) If the received securityParameters is not the serialization of an
OCTET STRING formatted according to the SSHsmSecurityParameters, and
the contained OCTET STRING is not empty, then the snmpInASNParseErrs
counter [RFC3418] is incremented, and an error indication
(parseError) is returned to the calling module.

4) The statusInformation is set to success and a return is made to
the calling module passing back the OUT parameters as specified subtrees in the processIncomingMsg primitive. SSHTM-MIB
-- ---------------------------------------------------------- --

sshtmNotifications OBJECT IDENTIFIER ::= { sshtmMIB 0 }

Harrington & Salowey Expires December 25, 2006 April 14, 2007 [Page 26] 22]

Internet-Draft Secure Shell Security Transport Model for SNMP June October 2006

5.7. Establishing

sshtmMIBObjects OBJECT IDENTIFIER ::= { sshtmMIB 1 }
sshtmConformance OBJECT IDENTIFIER ::= { sshtmMIB 2 }

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

TransportAddressSSH ::= TEXTUAL-CONVENTION
DISPLAY-HINT "1a"
STATUS current
DESCRIPTION
"Represents either a Session

The Secure Shell Security Model provides hostname encoded in ASCII
using the following primitive to
pass data back IDNA protocol, as specified in RFC3490, followed by
a colon ':' (ASCII character 0x3A) and forth between the Transport Mapping portion a decimal port number
in ASCII, or an IP address followed by a colon ':'
(ASCII character 0x3A) and a decimal port number in ASCII.
The name SHOULD be fully qualified whenever possible.

Values of the
Security Model this textual convention are not directly useable
as transport-layer addressing information, and 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 SSH service:

statusInformation =
openSession(
IN destTransportDomain -- transport domain time of the management operation).

The DESCRIPTION clause of TransportAddress objects that may
have TransportAddressSSH 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
IN destTransportAddress -- transport address directly in
object definitions since it restricts addresses to a
specific format. However, if it is used, it MAY be used
IN maxMessageSize --
either on its own or in conjunction with
TransportAddressType or TransportDomain as a pair.

When this textual convention is used as a syntax of an
index object, there may be issues with the sending SNMP entity
IN securityModel -- Security Model to use
IN securityName -- on behalf limit of 128
sub-identifiers specified in SMIv2, STD 58. In this principal
IN securityLevel -- Level of Security requested
OUT tmSessionReference
)

The following describes case,
the procedure to follow to establish OBJECT-TYPE declaration MUST include a
session between a client and server 'SIZE' clause
to run SNMP over SSH. This
process is followed 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. It is never triggered
by an application preparing a response message, such as a Command
Responder or Notification Receiver, because securityStateReference
will always have the session information for a response message

1) Using destTransportDomain and destTransportAddress, the client
will establish an SSH transport connection using the SSH transport
protocol, authenticate limit the server, and exchange keys for message
integrity and encryption. The parameters number of the potential instance sub-identifiers."
SYNTAX OCTET STRING (SIZE (1..255))

transportDomainSSH OBJECT-IDENTITY
STATUS current
DESCRIPTION
"The SSH 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 an error indication is returned, and
openSession processing stops.

2) domain. The provided transport domain, corresponding transport address, securityModel,
securityName and securityLevel are used to lookup an associated entry
in the Local Configuration Datastore (LCD). Any model-specific
information concerning the principal at the destination is extracted.
This step allows preconfiguration of model-specific principals mapped
to the transport/name/level, for example, for sending notifications.
Set the username in the SSH_MSG_USERAUTH_REQUEST to the username

Harrington & Salowey Expires December 25, 2006 April 14, 2007 [Page 27] 23]

Internet-Draft Secure Shell Security Transport Model for SNMP June October 2006

extracted from the LCD.

If information about the principal

address is absent from of type TransportAddressSSH.

When an SNMP entity uses the LCD, then set
the username in the SSH_MSG_USERAUTH_REQUEST to the value transportDomainSSH transport
model, it must be capable of
securityName. This allows a deployment without preconfigured
mappings between model-specific and model-independent names, but the
securityName will need to contain a username recognized by the
authentication mechanism.

3)The client will then invoke the "ssh-userauth" service accepting messages up to
authenticate the user, as described
and including 8192 octets in the SSH authentication
protocol [RFC4252].

If the authentication is unsuccessful, then the transport connection
is closed, tmSessionReference is released, the message is discarded,
an error indication (unknownSecurityName) size. Implementation of
larger values is returned to the calling
module, encouraged whenever possible."
::= { snmpDomains yy }
-- RFC Ed.: replace yy with IANA-assigned number and processing stops for
-- remove 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 note

-- The sshtmSession Group

sshtmSession OBJECT IDENTIFIER ::= { sshtmMIBObjects 1 }

sshtmSessionCurrent OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The current number of open sessions.
"
::= { sshtmSession 1 }

sshtmSessionMaxSupported OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The maximum number of open sessions supported.
The value zero indicates the ssh-connection service maximum is established, the client will
use dynamic.
"
::= { sshtmSession 2 }

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

sshtmSessionSecurityLevelNotAvailableErrors OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The number of type
"session", providing a selected sender channel number, and a maximum
packet size calculated from the SNMP maxMessageSize.

6) If successful, this will result in times an SSH session. The
destTransportDomain and the destTransportAddress, plus the "recipient
channel" and "sender channel" and other relevant data from the
SSH_MSG_CHANNEL_OPEN_CONFIRMATION should be retained so they can be
added to the LCD for subsequent use.

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 Security Model MUST default to
providing access to the "SNMP" SSH subsystem only when the SSH
session is established using the IANA-assigned TCP port (TBD by
IANA). Servers SHOULD be configurable to allow access to the SNMP
SSH subsystem over other ports.

8) Create an entry in a Local Configuration Datastore containing the
provided transportDomain, transportAddress, securityName,
securityLevel, and securityModel, and SSH-speciifc parameters and
create outgoing message was
discarded because a tmSessionReference to reference the entry. requested securityLevel could not
provided.

Harrington & Salowey Expires December 25, 2006 April 14, 2007 [Page 28] 24]

Internet-Draft Secure Shell Security Transport Model for SNMP June October 2006

9) At this point an implementation MAY perform some type

"
::= { sshtmSession 4 }

sshtmSessionNoAvailableSessions OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The number of engineID
discovery to determine times a mapping between Response message
was dropped because the remote transport
address, SSH session, TMSM session, and a contextEngineID. corresponding
session was no longer available.
"
::= { sshtmSession 5 }

-- The contextEngineID of a remote engine needs sshtmUser Group ********************************************

sshtmUser OBJECT IDENTIFIER ::= { sshtmMIBObjects 2 }

sshtmUserSpinLock OBJECT-TYPE
SYNTAX TestAndIncr
MAX-ACCESS read-write
STATUS current
DESCRIPTION "An advisory lock used to be "discovered" for allow several cooperating
Command Generator Applications to coordinate their
use in request messages. USM, the mandatory-to-implement security
model, can perform discovery of facilities to alter the snmpEngineIDs sshtmUserTable.
"
::= { sshtmUser 1 }

-- The table of adjacent engines
using Reports (see [RFC3414] section 3.2 3b). Then the discovered
snmpEngineID valid users for the remote engine can be used as the contextEngineID SSH Transport Model ********

sshtmUserTable OBJECT-TYPE
SYNTAX SEQUENCE OF SshtmUserEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "The table of users configured in requests passed using the SSH security model.

10) The SNMP engine's
Local Configuration Datastore may also record implement-
specific information, such as recording the following information:
the remote engine's snmpEngineID
the recipient and sender channels from the
SSH_MSG_CHANNEL_OPEN_CONFIRMATION message
the IP address corresponding (LCD).

Most configuration of this table is expected to the hostname
The SSH subsystem that was opened be
done by an agent dynamically. It is possible for this session an
SNMP management application to pre-configure the
table with static information useful for Request/
Responses ("SNMP"), translating
from an SSH-specific user to a model-independent
securityName, or for Notifications ("SNMPNotification").

Return statically configuring the tmSessionReference only
entities authorized to the calling module.

5.8. Closing receive notifications.

To create a Session

The new user (i.e., to instantiate a new
conceptual row in this table), it is recommended to
follow this procedure:

Harrington & Salowey Expires April 14, 2007 [Page 25]

Internet-Draft Secure Shell Security Model provides the following primitive to
pass data back and forth between the Security Transport Model for SNMP October 2006

1) GET(sshtmUserSpinLock.0) and save in sValue.
2) SET(sshtmUserSpinLock.0=sValue,
sshtmUserStatus=createAndWait)
3) configure the SSH
service:

statusInformation =
closeSession(
IN tmSessionReference
) entry
4) SET(sshtmUserStatus=active)

The following describes the procedure to follow to close a session
between a client new user should now be available and sever ready to run SNMP over SSH. This process be
used for SNMPv3 communication.

The use of sshtmUserSpinlock is
followed by any SNMP engine closing the corresponding to avoid conflicts
with another SNMP session.

The Secure Shell Security Model identifies command generator application which session should
may also be
closed to acting on the SSH client code, using sshtmUserTable.
"
::= { sshtmUser 2 }

sshtmUserEntry OBJECT-TYPE
SYNTAX SshtmUserEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "A user configured in the closeSession() ASI.

6. Overview

This MIB module provides management of SNMP engine's Local
Configuration Datastore (LCD) for the Secure Shell Security SSH
Transport Model. It defines some needed textual conventions, and some
statistics.
"
INDEX { sshtmUserAddress,
sshtmUserName
}
::= { sshtmUserTable 1 }

SshtmUserEntry ::= SEQUENCE
{
sshtmUserAddress TransportAddressSSH,
sshtmUserSecurityName SnmpAdminString,
sshtmUserName SnmpAdminString,
sshtmUserStorageType StorageType,
sshtmUserStatus RowStatus
}

sshtmUserAddress OBJECT-TYPE
SYNTAX TransportAddressSSH
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "A remote SNMP engine's SSH address.
"
::= { sshtmUserEntry 1 }

sshtmUserSecurityName OBJECT-TYPE
SYNTAX SnmpAdminString

Harrington & Salowey Expires December 25, 2006 April 14, 2007 [Page 29] 26]

Internet-Draft Secure Shell Security Transport Model for SNMP June October 2006

6.1. Structure of

MAX-ACCESS read-only
STATUS current
DESCRIPTION "A human readable string representing the MIB Module

Objects user in this MIB module are arranged into subtrees. Each subtree
is organized as a set of related objects.
Transport Model independent format.

The overall structure and
assignment default transformation of objects the sshtmUserName to their subtrees,
the sshtmUserSecurityName and vice versa is the intended purpose of
each subtree,
identity function so that the sshtmUserSecurityName
is shown below.

6.2. Textual Conventions

Generic and Common Textual Conventions usually the same as the sshtmUserName.
"
::= { sshtmUserEntry 2 }

sshtmUserName OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE(1..32))
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "This is the user name used in the
SSH_MSG_USERAUTH_REQUEST to authenticate the client.
"
::= { sshtmUserEntry 3 }

sshtmUserStorageType OBJECT-TYPE
SYNTAX StorageType
MAX-ACCESS read-create
STATUS current
DESCRIPTION "The storage type for this document can be
found summarized conceptual row.

It is an implementation issue to decide if a SET for
a readOnly or permanent row is accepted at http://www.ops.ietf.org/mib-common-tcs.html

6.3. The sshsmStats Subtree

This subtree contains SSHSM security-model-dependent counters.

This subtree provides information all. In some
contexts this may make sense, in others it may not. If
a SET for identifying fault conditions
and performance degradation.

6.4. The sshsmsSession Subtree

This subtree contains SSHSM security-model-dependent information
about sessions.

6.5. Relationship to Other MIB Modules

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

This MIB module is for managing SSHSM-specific information.

6.5.1. Relationship to the SNMPv2-MIB

The 'system' group in the SNMPv2-MIB [RFC3418] a readOnly or permanent row is defined as being
mandatory for not accepted
at all, then a 'wrongValue' error must be returned.
"
DEFVAL { nonVolatile }
::= { sshtmUserEntry 4 }

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

Until instances of all systems, and corresponding columns are
appropriately configured, the objects apply to value of the entity as a
whole. The 'system' group provides identification
corresponding instance of the management
entity and certain other system-wide data. sshtmUserStatus column
is 'notReady'.

The SSHSM-MIB does not
duplicate those objects.

6.5.2. Relationship to the SNMP-FRAMEWORK-MIB

[todo] if the SSHSM-MIB does not actually have dependencies on SNMP-
FRAMEWORK-MIB other than imports, then remove value of this paragraph. object has no effect on whether

Harrington & Salowey Expires December 25, 2006 April 14, 2007 [Page 30] 27]

Internet-Draft Secure Shell Security Transport Model for SNMP June October 2006

6.5.3. Relationship to the TMSM-MIB

The 'tmsmSession' group in the TMSM-MIB [I-D.ietf-isms-tmsm] is
defined as being applicable to all Transport-Mapping Security Models
that use sessions. [todo] if the SSHSM-MIB does not actually have
dependencies on TMSM-MIB

other than imports, then remove this
paragraph.

6.5.4. MIB Modules Required for IMPORTS

The following MIB module imports items from [RFC2578], [RFC2579],
[RFC2580], [RFC3411], [RFC3419], and [I-D.ietf-isms-tmsm]

This MIB module also references [RFC3490]

7. MIB module definition

** Is AES the only officially required to support SSH encryption **
mechanisms? It seems RFC 4344 has much more to offer. BTW, is it **
useful to export all this information objects in an SSHSM MIB module? Some
** of the stuff seems generic SSH...

SSHSM-MIB DEFINITIONS ::= BEGIN

IMPORTS
MODULE-IDENTITY, OBJECT-TYPE,
OBJECT-IDENTITY, mib-2, Counter32, Integer32
FROM SNMPv2-SMI
TestAndIncr, AutonomousType
FROM SNMPv2-TC
MODULE-COMPLIANCE, OBJECT-GROUP
FROM SNMPv2-CONF
SnmpAdminString, SnmpSecurityLevel, SnmpEngineID
FROM SNMP-FRAMEWORK-MIB
TransportAddress, TransportAddressType
FROM TRANSPORT-ADDRESS-MIB
;

sshsmMIB MODULE-IDENTITY
LAST-UPDATED "200509020000Z"
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

Harrington & Salowey Expires December 25, 2006 [Page 31]

Internet-Draft Secure Shell Security Model for SNMP June 2006

Kurfuersten-Anlage 36
69115 Heidelberg
Germany
+49 6221 90511-15
quittek@netlab.nec.de

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

Co-editors:
David Harrington
Effective Software
50 Harding Rd
Portsmouth, New Hampshire 03801
USA
+1 603-436-8634
ietfdbh@comcast.net

Joseph Salowey
Cisco Systems
2901 3rd Ave
Seattle, WA 98121
USA
jsalowey@cisco.com
"
DESCRIPTION "The Secure Shell Security Model MIB

Copyright (C) The Internet Society (2006). 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 "200509020000Z" -- 02 September 2005
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
" this conceptual row can be modified.
"
::= { mib-2 xxxx sshtmUserEntry 5 }

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

Harrington & Salowey Expires December 25, 2006 [Page 32]

Internet-Draft Secure Shell Security Model for SNMP June 2006

-- ---------------------------------------------------------- --
-- subtrees in the SSHSM-MIB ************************************************
-- ---------------------------------------------------------- sshtmMIB - Conformance Information
--

sshsmNotifications OBJECT IDENTIFIER ::= { sshsmMIB 0 }
sshsmObjects ************************************************

sshtmGroups OBJECT IDENTIFIER ::= { sshsmMIB sshtmConformance 1 }
sshsmConformance

sshtmCompliances OBJECT IDENTIFIER ::= { sshsmMIB sshtmConformance 2 }

-- ------------------------------------------------------------- ************************************************
-- Objects Units of conformance
-- -------------------------------------------------------------

TransportAddressSSH ::= TEXTUAL-CONVENTION
DISPLAY-HINT "1a" ************************************************
sshtmGroup OBJECT-GROUP
OBJECTS {
sshtmUserSpinLock,
sshtmUserSecurityName,
sshtmUserStorageType,
sshtmUserStatus
}
STATUS current
DESCRIPTION
"Represents either a hostname encoded in ASCII
using the IDNA protocol, as specified in RFC3490, followed by
a colon ':' (ASCII character 0x3A) and a decimal port number
in ASCII, or "A collection of objects for maintaining
information of an IP address followed by SNMP engine which implements the
SNMP Secure Shell Transport Model.
"

::= { sshtmGroups 2 }

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

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

END

Harrington & Salowey Expires April 14, 2007 [Page 28]

Internet-Draft Secure Shell Transport Model for SNMP October 2006

8. Security Considerations

This document describes a colon ':'
(ASCII character 0x3A) transport model that permits SNMP to
utilize SSH security services. The security threats and a decimal port number how the SSH
Transport Model mitigates those threats is covered in ASCII. detail
throughout this memo.

The name SHOULD be fully qualified whenever possible.

Values SSH Transport Model relies on SSH mutual authentication, binding
of this textual convention are not directly useable
as transport-layer addressing information, keys, confidentiality and require
runtime resolution. As such, applications integrity. Any authentication method
that write them
must be prepared for handling errors if such values are
not supported, or cannot be resolved (if resolution occurs
at meets the time requirements of the management operation).

The DESCRIPTION clause SSH architecture will provide the
properties of TransportAddress objects that may
have TransportAddressSSH values must fully describe how (and
when) such names are to be resolved to IP addresses mutual authentication and vice
versa.

This textual convention binding of keys. While SSH
does support turning off confidentiality and integrity, they SHOULD
NOT be turned off when 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 the SSH Transport Model.

SSHv2 provides Perfect Forward Security (PFS) for encryption keys.
PFS is used as a syntax major design goal of an
index object, there may be issues with the limit SSH, and any well-designed keyex
algorithm will provide it.

The security implications of 128
sub-identifiers specified using SSH are covered in SMIv2, STD 58. In this case,
the OBJECT-TYPE declaration MUST include a 'SIZE' clause [RFC4251].

The SSH Transport Model has no way to limit verify that server
authentication was performed, to learn the number of potential instance sub-identifiers."
SYNTAX OCTET STRING (SIZE (1..255))

Harrington & Salowey Expires December 25, 2006 [Page 33]

Internet-Draft Secure Shell Security host's public key in
advance, or verify that the correct key is being used. the SSH
Transport Model for SNMP June 2006

transportDomainSSH OBJECT-IDENTITY
STATUS current
DESCRIPTION
"The simply trusts that these are properly configured by
the implementer and deployer.

8.1. noAuthPriv

SSH transport domain. The corresponding transport
address 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 type TransportAddressSSH.

When an SNMP entity uses not authenticating the transportDomainSSH transport
mapping, it must be capable SSH client to the SSH
server. Doing this does not compromise authentication of accepting messages up the SSH
server to
and including 8192 octets in size. Implementation of
larger values is encouraged whenever possible."
::= { snmpDomains xxxx }
-- RFC Ed.: replace xxxx with IANA-assigned number and
-- remove this note

-- Statistics for the Secure Shell Security SSH client, nor does it compromise data confidentiality
or data integrity.

SSH supports anonymous access. If the SSH Transport Model

sshsmStats OBJECT IDENTIFIER ::= { sshsmObjects 1 }

-- [todo] do we need any stats?

-- -------------------------------------------------------------
-- sshsmMIB - Conformance Information
-- -------------------------------------------------------------

sshsmGroups OBJECT IDENTIFIER ::= { sshsmConformance 1 }

sshsmCompliances OBJECT IDENTIFIER ::= { sshsmConformance 2 }

-- -------------------------------------------------------------
-- Units of conformance
-- -------------------------------------------------------------
sshsmGroup OBJECT-GROUP
OBJECTS {

}
STATUS current
DESCRIPTION "A collection of objects can
extract from SSH an authenticated principal to map to securityName,
then anonymous access SHOULD be supported. It is possible for maintaining
information SSH to
skip entity authentication of the client through the "none"
authentication method to support anonymous clients, however in this
case an SNMP engine which implements implementation MUST still support data integrity within the
SNMP Secure Shell Security Model.
"

::= { sshsmGroups 2 }

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

Harrington & Salowey Expires December 25, 2006 April 14, 2007 [Page 34] 29]

Internet-Draft Secure Shell Security Transport Model for SNMP June October 2006

-- Compliance statements
-- -------------------------------------------------------------

sshsmCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for SNMP engines that support the
SSHSM-MIB"
MODULE
MANDATORY-GROUPS { sshsmGroup }
::= { sshsmCompliances 1 }

END

8. Security Considerations

This document describes a security model that would permit SNMP to
utilize SSH security services. The security threats and how SSHSM
mitigates those threats is covered in detail throughout this memo.

SSHSM relies on SSH mutual authentication, binding of keys,
confidentiality and integrity. Any authentication method that meets
the requirements of

[discuss: are we being inconsistent? ]

8.2. skipping public key verification

Most key exchange algorithms are able to authenticate the SSH architecture will provide
server's identity to 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 SSHSM.

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

The security implications the common case of using SSH are covered in [RFC4251].

SSHSM has no way to verify that server authentication was performed, DH
signed by public keys, this requires the client to learn know the host's
public key in advance, or a priori and to verify that the correct key is being used. SSHSM simply trusts that these are properly
cvonfigured by
If this step is skipped, then authentication of the implementer and deployer.

8.1. noAuthPriv SSH provides server to the "none" userauth method, which
SSH client is normally rejected
by servers not done. Data confidentiality and used only to find out what userauth methods are
supported. However, it is legal for a server data integrity
protection to accept this method,
which has the effect server still exist, but these are of not authenticating dubious value
when an attacker can insert himself between the ssh client to and the ssh real
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 December 25, 2006 [Page 35]

Internet-Draft Secure Shell Security Model for SNMP June 2006

SSH supports anonymous access. If SSHSM 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. SSHSM should
not be used with an SSH connection with the "none" userauth method.

8.2. 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 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 SSHSM security model. SSH Transport Model.

8.3. the 'none' MAC algorithm

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

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

8.4. MIB module security

There are a number of management objects defined in this MIB module
with a MAX-ACCESS clause of read-write and/or read-create. Such
objects may be considered sensitive or vulnerable in some network
environments. The support for SET operations in a non-secure
environment without proper protection can have a negative effect on

Harrington & Salowey Expires December 25, 2006 [Page 36]

Internet-Draft Secure Shell Security Model for SNMP June 2006
network operations. These are the tables and objects and their
sensitivity/vulnerability:
o [todo]

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.

Harrington & Salowey Expires April 14, 2007 [Page 30]

Internet-Draft Secure Shell Transport Model for SNMP October 2006

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 [todo]

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

9. 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
be the default port for SNMP over an SSH sessions Transport Model as
defined in this document,
2. an SMI number under mib-2, for the MIB module in this document,

Harrington & Salowey Expires December 25, 2006 [Page 37]

Internet-Draft Secure Shell Security Model
3. the creation of a registry for SNMP June 2006

3. Transport Models
4. an SnmpSecurityModel SnmpTransportModel for the Secure Shell Security Transport Model, as
documented in
the MIB module Simple Network Management Protocol (SNMP) Number Spaces. The
SnmpTransportModel registry is defined in this document,
4. [I-D.ietf-isms-tmsm]
5. "snmp" as an SSH Service Name in the
http://www.iana.org/assignments/ssh-parameters registry.

10. Acknowledgements

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

Harrington & Salowey Expires April 14, 2007 [Page 31]

Internet-Draft Secure Shell Transport Model for SNMP October 2006

11. References

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

[RFC3412] Case, J., Harrington, D., Presuhn, R., and B.
Wijnen, "Message Processing and Dispatching for
the Simple Network Management Protocol (SNMP)",
STD 62, RFC 3412, 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 December 25, 2006 [Page 38]

Internet-Draft Secure Shell Security Model for SNMP June 2006

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

[RFC3416] Presuhn, R., "Version 2 of the Protocol
Operations for the Simple Network Management
Protocol (SNMP)", STD 62, RFC 3416,
December 2002.

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

Harrington & Salowey Expires April 14, 2007 [Page 32]

Internet-Draft Secure Shell Transport Model for SNMP October 2006

[RFC3419] Daniele, M. and J. Schoenwaelder, "Textual
Conventions for Transport Addresses", RFC 3419,
December 2002.

[RFC3430] Schoenwaelder, J., "Simple Network Management
Protocol Over Transmission Control Protocol
Transport Mapping", RFC 3430, December 2002.

[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
"Internationalizing Domain Names in
Applications (IDNA)", RFC 3490, March 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
Mapping Security Model (TMSM) Architectural
Extension for the Simple Network Management
Protocol (SNMP)", draft-ietf-isms-tmsm-02 (work
in progress), May 2006.

Harrington & Salowey Expires December 25, 2006 [Page 39]

Internet-Draft Secure Shell Security Model for SNMP June 2006

11.2. Informative References

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

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

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

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

[I-D.ietf-netconf-ssh] Wasserman, M. and T. Goddard, "Using the
NETCONF Configuration Protocol over Secure
Shell (SSH)", draft-ietf-netconf-ssh-06 (work
in progress), March 2006.

Appendix A. Open Issues

We need to reach consensus on some issues.

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

o The MIB module needs to be defined.
o Consistency with TMSM needs to be done (TMSM needs some changes
due to changes in SSHSM)
o ssh transport domain and transport address definitions -
consistency across WGs
o

A.1. Closed Issues

#1: is it important to support anonymous user access to SNMP?
Resolution: We should support whatever authorizations are provided by
SSH; if SSH supports anonymous access, and SSHSM can extract a
username, then it should be supported.

Harrington & Salowey Expires December 25, 2006 [Page 40]

Internet-Draft Secure Shell Security Model for SNMP June 2006

#2: a) is server authentication a requirement that SNMP will require
of the client? yes. b) how can we verify that server authentication
was performed, or do we take simply trust the SSH client layer to
perform such authentication? we trust the SSH layer to provide such
auithentication. c) for the common case of DH signed by public keys,
how does the client learn the host's public key in advance, and
verify that the correct key is being used? this is out of scope for
this document

#3: we need some text contributed to discuss the implications of
sessions on SNMP. See TMSM.

#4: Should the SSHSM document include a discussion of the operational
expectations of this model for use in troubleshooting a broken
network, or can this be covered in the TMSM document? (Either way,
we could use some contributed text on the topic). See TMSM.

#5: Should the SSHSM document include a discussion of ways SNMP could
be extended to better support management/monitoring needs when a
network is running just fine, or can this be covered in the TMSM
document, or in an applicability document? Out of scope for this
document.

#6: Are there are any wrinkles to coexistence with SNMPv1/v2c/USM?

#7: is there still a need for an "authoritative SNMP engine"? No.

#8: Do we need a mapping between the SSH key (or other SSH engine
identifier) and SNMP engineID? No. What happens if an agent
"spoofs" another engineID, and an NMS perfoms a SET of sensitive
parameters to the agent? Resolution: we do not need to address this
for local SSH and local snmpEngineID, unless smebody can show a use
case requirement. There is likely to be a need to map, in an
implementation-dependent manner, the remote engineIDs with the
associated SSH host (mapping of engineID/transport address/host key).

#9: Can an existing R/R session be reused for notifications? Yes.

#10: a) which securityparameters must be supported for the SSHSM
model? b) Which services provided in USM are needed in TMSM/SSHSM?
C) How does the Message Processing model provide this information to
the security model via generateRequestMsg() and processIncomingMsg()
primitives?

#11: If we eliminate all msgSecurityParameters, should the
msgSecurityParameters field in the SNMPv3 message simply be a zero-
length OCTET STRING, or should it be an ASN.1 NULL? It MUST be a
BER-encoded OCTET STRING

Harrington & Salowey Expires December 25, 2006 [Page 41]

Internet-Draft Secure Shell Security Model for SNMP June 2006

#12: a) how does SSHSM determine whether SSH can provide the security
services requested in msgFlags? It doesn't. B) There were
discussions about whether it was acceptable for a transport-mapping-
model to provide stronger security than requested. Does this need to
be discussed in the SSHSM document, or should we discuss this in the
TMSM document? Both. c) when sending a message into an environment
where encryption is not legal, how do we ensure that encryption is
not provided? The Danvers Doctrine seems to indicate this in not
necessary to discuss.

#13: will SSHSM be impacted by keychanges to the SSH local datastore?
Resolution: if the session is closed while the Response is being
prepared, discard the Response.

#14: MUST the SSHSM model provide mutual authentication of the client
and server, and MUST it authenticate, integrity-check, and encrypt
the messages? Resolution: yes.

#15: What data needs to be stored in the tmSessionReference, and how
does SSHSM get the information from SSH, for the various
authentication and transport options?

#16: The SSH server doesn't necessarily authorize the name carried in
the SSH_MSG_USERAUTH_REQUEST message, but may return a different name
or list of names that are authorized to be used given the
authentication of the provided username. Resolution: this is
mistaken; the username from the SSH_MSG_USERAUTH_REQUEST SHOULD be
used. A) What should be the source of the SSHSM mechanism-specific
username for mapping to securityname? Resolution: the username from
the SSH_MSG_USERAUTH_REQUEST SHOULD be used.

#16 B) passing a securityName might be useful for passing as a hint
to RADIUS or other authorization mechanism to indicate which identity
we want to use when doing access control, and RADIUS,etc. can tell us
whether the username being authenticated is allowed to be mapped to
that authorization/accounting identity. Should we provide
securityName when establishing a session, so the authentication
machanisms can use it as a hint? SSHSM provides securityName/Model/
Level and tranport; whether SSH passes this to RADIUS is out of scope
for this document.

#17: I believe somebody suggested we require mutual authentication.
I'm not sure I understand the edits. Done.

#18: I currently have multiple sections, one for each known auth
mechanism. We need to discuss the parameters that need to be cached
for each, and determine whether we can collapse this into one
section. a) Using Passwords to Authenticate SNMP Principals B) Using

Harrington & Salowey Expires December 25, 2006 [Page 42]

Internet-Draft Secure Shell Security Model for SNMP June 2006

Public keys to Authenticate SNMP Principals C) Using Host-based
Authentication of SNMP Principals Resolution: I will collapse this
later, after we have verified we have considered all current/likely
scenarios. Done.

#19: RADIUS is just an instance of the password authentication
protocol. The details of RADIUS are within the SSH layer. I don't
think it is a good idea to expose this outside of SSH. Resolution:
If possible, the details of RADIUS should not be exposed in SSHSM.
There may be an issue with receiving authorization without exposing
the details.

#20: How do we get the mapping from model-specific identity to a
model independent securityName?. Resolution: Implementation-
dependent, both in the case of extracting tmSecurityname from SSH for
an incoming message, and for providing an LCD mapping.

#21: we need to determine what data should be persistent and stored
in the LCD for notification purposes.

#22: Joe: There are a significant number of security problems
associated with mapping to a transport address which may need to be
discussed in the security considerations section. Resolution: add a
transporttype for hostname.

#23: We need to discuss the circumstances under which a session
should be closed, and how an SNMP engine should determine if, and
respond if the SSH session is closed by other means, See TMSM, and
implementation-dependent.

#24: How should we enable auto-discovery?

#25: Where is the best place to call openSession()? Note that the
whole message is completely put together within the message-
processing portion of the security model, in the hopes that a session
will be able to be established when the message gets to the transport
mapping portion of the architecture. It is done this way because the
RFC3411 arcitecture doesn't pass the transport addressing info into
the security model via messaging model. It would seem a much more
efficient approach to verify that the session can be established,
while still in the security model portion of the messaging model. If
we don't establish the session until we get to the transport mapping,
we've done a lot of work for nothing. And thus far, there is no
place to record failed attempts to establish a session, so an engine
doesn't learn to not try to open a session. In an environment where
the SNMP engine might be a daemon used by multiple applications, an
attacker could use this to cause a denial of service attack at the
NMS. This would likely occur on the NMS side. I don't know if

Harrington & Salowey Expires December 25, 2006 [Page 43]

Internet-Draft Secure Shell Security Model for SNMP June 2006

there's any way to cause it to happen on the agent side. I suppose a
rogue agent with callhome functionality might be able to cause a
denial of service for an NMS by repeatedly requesting callhome and
then refusing the connections. Resolution: called from TMSP.

#26: According to RFC 3411, section 4.1.1, the application provides
the transportDomain and transportAddress to the PDU dispatcher via
the sendPDU() primitive. If we permit multiple sessions per
transportAddress, then we would need to define how session
identifiers get passed from the application to the PDU dispatcher
(and then to the MP model).Resolution: applications do not know about
sessions.

#27: The SNMP over TCP Transport Mapping document [RFC3430] says that
TCP connections can be recreated dynamically or kept for future use
and actually leaves all that to the transport mapping. Do we need to
discuss these issues? Where? in the security considerations? See
TMSM.

#28: For notification tables, how do we predefine the dynamic session
identifiers? We might have a MIB module that records the session
information for subsequent use by the applications and other
subsytems, or it might be passed in the tmSessionReference cache.
For notifications, I assume the SNMPv3 notification tables would be a
place to find the address, but I'm not sure how to identify the
presumably-dynamic session identifiers. The MIB module could
identify whether the session was initiated by the remote engine or
initiated by the current engine, and possibly assigned a purpose
(incoming request/response or outgoing notifications).. Resolution:
applications do not know about sessions, only transport and
securityN/M/L; if separate sessions are desired, then they can be
differentiated by transport and securityN/M/L parameters.

#29: do we need to support reports? For what purpose? Yes, reports
are used from application processing 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
Mapping Security Model (TMSM) Architectural
Extension for contextEngine discovery.

#30: If we actually do not extract anything from securityParameters,
do we need to check whether this field parses correctly? It
apparently parsed well enough to pass the parse test Simple Network Management
Protocol (SNMP)", draft-ietf-isms-tmsm-03 (work
in the messaging
model. Could we simply ignore the securityParameters being passed
in? The only argument I see for checking to ensure this is empty is
to ensure somebody isn't using the filed progress), June 2006.

11.2. Informative References

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

[RFC3410] Case, J., Mundy, R., Partain, D., and B.
Stewart, "Introduction and Applicability
Statements for non-standard purposes,
such as passing a virus in the field. If we do check it, do we need
to report it through Reports? Resolution: yes; it won't hurt to
check it.

#32: For an incoming message (Processing an Incoming Message section
10), is using a default securityName mapping the right thing to do? 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.

[RFC4462] Hutzelman, J., Salowey, J., Galbraith, J.,
and V. Welch, "Generic Security Service
Application Program Interface (GSS-API)

Harrington & Salowey Expires December 25, 2006 April 14, 2007 [Page 44] 33]

Internet-Draft Secure Shell Security Transport Model for SNMP June October 2006

Resolution: Yes, it is the right thing to do.

#31: Is maxSizeResponseScopedPDU relevant? Can it be calculated once

Authentication and Key Exchange for the session? Do we
Secure Shell (SSH) Protocol", RFC 4462,
May 2006.

[I-D.ietf-netconf-ssh] Wasserman, M. and T. Goddard, "Using the
NETCONF Configuration Protocol over Secure
Shell (SSH)", draft-ietf-netconf-ssh-06 (work
in progress), March 2006.

Appendix A. Open Issues

We need to take into consideration reach consensus on some issues.

Here is the SSH
window size? Resolution: It can probably be calculated once per
session.

#33: does current list of issues from the mib SSH Transport Model
document where we need to reach consensus.

o The MIB module needs to be writable, so sessions can be
preconfigured, such as for callhome, or would it defined.
o Consistency with TMS needs to be populated at
creation time by done (TMS needs some changes due
to changes in the underlying instrumentation, SSH Transport Model)
o SSH transport domain and not writable by
SNMP? This is about the session table, which has been moved to TMSM.

[discuss] #34 transport address definitions - how do we determine whether a PDU contains a Request
/Response or a Notification? By
consistency across WGs
o configuring notification originators

Appendix B. Change Log

From -04- to -05

added sshtmUserTable
moved session tabel into the securityName or transport model MIB from the
transport parameters.

[discuss] #35 - which subsystem is used for Reports? ** Reports are MIB
added and then removed Appendix A - Notification Tables
Configuration (see Transport Security Model)
made this document a
reaction to specification of a previously received message transport model, rather
than a security model in two parts. Eliminated TMSP and thus they go wherever
the previous MPSP and
replaced them with "transport model" and "security model".
Removed security-model-specific processing from this document.
Removed discussion of snmpv3/v1/v2c message triggering the report came from.

Appendix B. Change Log format co-existence
changed tmSessionRefernce back to tmStateReference

"From -03- to -04-"

changed tmStateReference to tmSessionReference
o

"From -02- to -03-"

Harrington & Salowey Expires April 14, 2007 [Page 34]

Internet-Draft Secure Shell Transport Model for SNMP October 2006

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 tmsmSessiontable tmsSessiontable except as an example
updated Security Considerations

"From -01- to -02-"
Added TransportDomainSSH and Address

Harrington & Salowey Expires December 25, 2006 [Page 45]

Internet-Draft Secure Shell Security Model for SNMP June 2006
Removed implementation considerations
Changed all "user auth" to "client auth"
Removed unnecessary MIB module objects
updated references
improved consistency of references to TMSM as architecural 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 SSHSM 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 April 14, 2007 [Page 35]

Internet-Draft Secure Shell Transport Model for SNMP October 2006

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

Harrington & Salowey Expires December 25, 2006 [Page 46]

Internet-Draft Secure Shell Security Model for SNMP June 2006

Joseph Salowey
Cisco Systems
2901 3rd Ave
Seattle, WA 98121
USA

EMail: jsalowey@cisco.com

Harrington & Salowey Expires December 25, 2006 April 14, 2007 [Page 47] 36]

Internet-Draft Secure Shell Security Transport Model for SNMP June October 2006

Full Copyright Statement

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

This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY 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.

Acknowledgement

Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).

Harrington & Salowey Expires December 25, 2006 April 14, 2007 [Page 48] 37]

----