WDIFF

draft-ietf-isms-secshell-11.txt --> draft-ietf-isms-secshell-12.txt

Network Working Group D. Harrington
Internet-Draft Huawei Technologies (USA)
Intended status: Standards Track J. Salowey
Expires: January 12, April 9, 2009 Cisco Systems
July 11,
W. Hardaker
Sparta, Inc.
October 6, 2008

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

Status of This Memo

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

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

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

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

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

This Internet-Draft will expire on January 12, April 9, 2009.

Abstract

This memo describes a Transport Model for the Simple Network
Management Protocol, using the Secure Shell protocol (SSH).

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

Table of Contents

Harrington, et al. Expires April 9, 2009 [Page 1]

Internet-Draft Secure Shell Transport Model for SNMP October 2008

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3

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

Internet-Draft Secure Shell Transport Model for SNMP July 2008 4
1.1. The Internet-Standard Management Framework . . . . . . . . 3 4
1.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3 4
1.3. Modularity . . . . . . . . . . . . . . . . . . . . . . . . 4 5
1.4. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 5 6
1.5. Constraints . . . . . . . . . . . . . . . . . . . . . . . 6 7
2. The Secure Shell Protocol . . . . . . . . . . . . . . . . . . 6 7
3. How SSHTM Fits into the Transport Subsystem . . . . . . . . . 7 8
3.1. Security Capabilities of this Model . . . . . . . . . . . 8 9
3.1.1. Threats . . . . . . . . . . . . . . . . . . . . . . . 8 9
3.1.2. Message Authentication . . . . . . . . . . . . . . . . 9 10
3.1.3. Authentication Protocol Support . . . . . . . . . . . 10 11
3.1.4. Privacy Protocol Support . . . . . . . . . . . . . . . 10 11
3.1.5. Protection against Message Replay, Delay and
Redirection . . . . . . . . . . . . . . . . . . . . . 10 11
3.1.6. SSH Subsystem . . . . . . . . . . . . . . . . . . . . 11 12
3.2. Security Parameter Passing . . . . . . . . . . . . . . . . 11 12
3.3. Notifications and Proxy . . . . . . . . . . . . . . . . . 12 13
4. Passing Security Parameters Cached Information and References . . . . . . . . . . . . . . 13
4.1. securityStateReference . . . 12
4.1. . . . . . . . . . . . . . . . 14
4.2. tmStateReference . . . . . . . . . . . . . . . . . . . . . 12
4.2. tmSecurityName 14
4.2.1. Transport information . . . . . . . . . . . . . . . . 15
4.2.2. securityName . . . . . . 13 . . . . . . . . . . . . . . . 15
4.2.3. securityLevel . . . . . . . . . . . . . . . . . . . . 16
4.2.4. Session Information . . . . . . . . . . . . . . . . . 16
4.3. tmSameSecurity Secure Shell Transport Model Cached Information . . . . . 17
4.3.1. tmSecurityName . . . . . . . . . . . . . . . . . . 14 . . 17
4.3.2. tmSessionID . . . . . . . . . . . . . . . . . . . . . 17
4.3.3. session state . . . . . . . . . . . . . . . . . . . . 17
5. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 15 18
5.1. Procedures for an Incoming Message . . . . . . . . . . . . 15 18
5.2. Procedures for an Outgoing Message . . . . . . . . . . . . 16 19
5.3. Establishing a Session . . . . . . . . . . . . . . . . . . 17 20
5.4. Closing a Session . . . . . . . . . . . . . . . . . . . . 19 22
6. MIB Module Overview . . . . . . . . . . . . . . . . . . . . . 20 22
6.1. Structure of the MIB Module . . . . . . . . . . . . . . . 20 22
6.2. Textual Conventions . . . . . . . . . . . . . . . . . . . 20 23
6.3. Relationship to Other MIB Modules . . . . . . . . . . . . 20 23
6.3.1. MIB Modules Required for IMPORTS . . . . . . . . . . . 20 23
7. MIB Module Definition . . . . . . . . . . . . . . . . . . . . 21 23
8. Operational Considerations . . . . . . . . . . . . . . . . . . 30 29
9. Security Considerations . . . . . . . . . . . . . . . . . . . 31 30
9.1. noAuthPriv . . . . . . . . . . . . . . . . . . . . . . . . 31
9.2. Use with SNMPv1/v2c Messages . . . . . . . . . . . . . . . 32 31
9.3. Skipping Public Key Verification . . . . . . . . . . . . . 32 31
9.4. The 'none' MAC Algorithm . . . . . . . . . . . . . . . . . 32
9.5. MIB Module Security . . . . . . . . . . . . . . . . . . . 33 32
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
11. Acknowledgements . . . . . . . . .

Harrington, et al. Expires April 9, 2009 [Page 2]

Internet-Draft Secure Shell Transport Model for SNMP October 2008

11. Acknowledgements . . . . . . . . . . . . . . 34 . . . . . . . . . 33
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 33
12.1. Normative References . . . . . . . . . . . . . . . . . . . 34 33
12.2. Informative References . . . . . . . . . . . . . . . . . . 35 36
Appendix A. Open Issues . . . . . . . . . . . . . . . . . . . . . 36 37
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 37

Harrington & Salowey 38

Harrington, et al. Expires January 12, April 9, 2009 [Page 2] 3]

Internet-Draft Secure Shell Transport Model for SNMP July October 2008

1. Introduction

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

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

1.1. The Internet-Standard Management Framework

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

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

1.2. Conventions

For consistency with SNMP-related specifications, this document
favors terminology as defined in STD62 rather than favoring
terminology that is consistent with non-SNMP specifications. This is
consistent with the IESG decision to not require the SNMPv3
terminology be modified to match the usage of other non-SNMP
specifications when SNMPv3 was advanced to Full Standard.

Authentication in this document typically refers to the English
meaning of "serving to prove the authenticity of" the message, not
data source authentication or peer identity authentication.

The terms "manager" and "agent" are not used in this document,
because in the RFC 3411 architecture [RFC3411], all SNMP entities

Harrington & Salowey

Harrington, et al. Expires January 12, April 9, 2009 [Page 3] 4]

Internet-Draft Secure Shell Transport Model for SNMP July October 2008

have the capability of acting in either manager or agent or in both
roles depending on the SNMP application types supported in the
implementation. Where distinction is required, the application names
of Command Generator, Command Responder, Notification Originator,
Notification Receiver, and Proxy Forwarder are used. See "SNMP
Applications" [RFC3413] for further information.

Throughout this document, the terms "client" and "server" are used to
refer to the two ends of the SSH transport connection. The client
actively opens the SSH connection, and the server passively listens
for the incoming SSH connection. Either SNMP entity may act as
client or as server, as discussed further below.

The User-Based Security Model (USM) [RFC3414] is a mandatory-to-
implement Security Model in STD 62. While SSH and USM frequently
refer to a user, the terminology preferred in RFC3411 [RFC3411] and
in this memo is "principal". A principal is the "who" on whose
behalf services are provided or processing takes place. A principal
can be, among other things, an individual acting in a particular
role; a set of individuals, with each acting in a particular role; an
application or a set of applications, or a combination of these
within an administrative domain.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].

Sections requiring further editing are identified by [todo] markers
in the text. Points requiring further WG research and discussion are
identified by [discuss] markers in the text.

Note to RFC Editor - if the previous paragraph and this note have not
been removed, please send the document back to the editor to remove
this.

1.3. Modularity

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

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

In keeping with the RFC 3411 design decision to use self-contained

Harrington & Salowey

Harrington, et al. Expires January 12, April 9, 2009 [Page 4] 5]

Internet-Draft Secure Shell Transport Model for SNMP July October 2008

documents, this document defines the elements of procedure and
associated MIB module objects which are needed for processing the
Secure Shell Transport Model for SNMP.

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

1.4. Motivation

Version 3 of the Simple Network Management Protocol (SNMPv3) added
security to the protocol. The User-based Security Model (USM)
[RFC3414] was designed to be independent of other existing security
infrastructures, to ensure it could function when third party
authentication services were not available, such as in a broken
network. As a result, USM utilizes a separate user and key
management infrastructure. Operators have reported that deploying
another user and key management infrastructure in order to use SNMPv3
is a reason for not deploying SNMPv3.

This memo describes a transport model that will make use of the
existing and commonly deployed Secure Shell security infrastructure.
This transport model is designed to meet the security and operational
needs of network administrators, maximize usability in operational
environments to achieve high deployment success and at the same time
minimize implementation and deployment costs to minimize deployment
time.

This document addresses the requirement for the SSH client to
authenticate the SSH server, for the SSH server to authenticate the
SSH client, and describes how SNMP can make use of the authenticated
identities in authorization policies for data access, in a manner
that is independent of any specific access control model.

This document addresses the requirement to utilize client
authentication and key exchange methods which support different
security infrastructures and provide different security properties.
This document describes how to use client authentication as described
in "SSH Authentication Protocol" [RFC4252]. The SSH Transport Model
should work with any of the ssh-userauth methods including the
"publickey", "password", "hostbased", "none", "keyboard-interactive",
"gssapi-with-mic", ."gssapi-keyex", "gssapi", and "external-keyx"
(see http://www.iana.org/assignments/ssh-parameters). The use of the
"none" authentication method is NOT RECOMMENDED, as described in
Security Considerations. Local accounts may be supported through the
use of the publickey, hostbased or password methods. The password
method allows for integration with deployed password infrastructure
such as AAA servers using the RADIUS protocol [RFC2865]. The SSH
Transport Model SHOULD be able to take advantage of future defined

Harrington & Salowey

Harrington, et al. Expires January 12, April 9, 2009 [Page 5] 6]

Internet-Draft Secure Shell Transport Model for SNMP July October 2008

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

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

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

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

1.5. Constraints

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

1. In times of network stress, the transport protocol and its
underlying security mechanisms SHOULD NOT depend upon the ready
availability of other network services (e.g., Network Time
Protocol (NTP) or AAA protocols).

2. When the network is not under stress, the transport model and its
underlying security mechanisms MAY depend upon the ready
availability of other network services.

3. It may not be possible for the transport model to determine when
the network is under stress.

4. A transport model should require no changes to the SNMP
architecture.

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

2. The Secure Shell Protocol

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

Harrington & Salowey

Harrington, et al. Expires January 12, April 9, 2009 [Page 6] 7]

Internet-Draft Secure Shell Transport Model for SNMP July October 2008

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

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

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

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

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

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

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

3. How SSHTM Fits into the Transport Subsystem

A transport model plugs into the Transport Subsystem
[I-D.ietf-isms-tmsm]. The SSH Transport Model thus fits between the
underlying SSH transport layer and the message dispatcher [RFC3411].

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

Harrington & Salowey

Harrington, et al. Expires January 12, April 9, 2009 [Page 7] 8]

Internet-Draft Secure Shell Transport Model for SNMP July October 2008

dispatcher.

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

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

3.1. Security Capabilities of this Model

3.1.1. Threats

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

1. Message stream modification - SSH provides for verification that
each received message has not been modified during its
transmission through the network.

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

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

4. Verification of principal identity is important for use with the
SNMP access control subsystem, to ensure that only authorized
principals have access to potentially sensitive data. The SSH
user identity is provided to the transport model, so it can be
used to map to an SNMP model-independent securityName for use
with SNMP access control and notification configuration. (The
identity may undergo various transforms before it maps to the
securityName.)

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

Harrington & Salowey

Harrington, et al. Expires January 12, April 9, 2009 [Page 8] 9]

Internet-Draft Secure Shell Transport Model for SNMP July October 2008

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

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

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

3.1.2. Message Authentication

The RFC 3411 architecture recognizes three levels of security:

- without authentication and without privacy (noAuthNoPriv)

- with authentication but without privacy (authNoPriv)

- with authentication and with privacy (authPriv)

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

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

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

Harrington & Salowey

Harrington, et al. Expires January 12, April 9, 2009 [Page 9] 10]

Internet-Draft Secure Shell Transport Model for SNMP July October 2008

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

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

3.1.3. Authentication Protocol Support

The SSH Transport Model should support any server or client
authentication mechanism supported by SSH. This includes the three
authentication methods described in the SSH Authentication Protocol
document [RFC4252] - publickey, password, and host-based - and
keyboard interactive and others.

The password authentication mechanism allows for integration with
deployed password based infrastructure. It is possible to hand a
password to a service such as RADIUS [RFC2865] or Diameter [RFC3588]
for validation. The validation could be done using the user-name and
user-password attributes. It is also possible to use a different
password validation protocol such as CHAP [RFC1994] or digest
authentication [RFC5090] to integrate with RADIUS or Diameter. At
some point in the processing, these mechanisms require the password
be made available as clear text on the device that is authenticating
the password which might introduce threats to the authentication
infrastructure. [DISCUSS: do we really need this paragraph?

GSSKeyex [RFC4462] provides a framework for the addition of client
authentication mechanisms which support different security
infrastructures and provide different security properties.
Additional authentication mechanisms, such as one that supports X.509
certificates, may be added to SSH in the future.

3.1.4. Privacy Protocol Support

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

3.1.5. Protection against Message Replay, Delay and Redirection

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

Harrington & Salowey

Harrington, et al. Expires January 12, April 9, 2009 [Page 10] 11]

Internet-Draft Secure Shell Transport Model for SNMP July October 2008

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

3.1.6. SSH Subsystem

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

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

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

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

3.2. Security Parameter Passing

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

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

Harrington & Salowey

Harrington, et al. Expires January 12, April 9, 2009 [Page 11] 12]

Internet-Draft Secure Shell Transport Model for SNMP July October 2008

3.3. Notifications and Proxy

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

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

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

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

4. Passing Security Parameters

For the SSH Transport Model, some Cached Information and References

When performing SNMP processing, there are two levels of state needs
information that may need to be maintained using
tmStateReference. RFC3411 discusses retained: the immediate state linking
a securityStateReference, which
is not accessible request-response pair, and potentially longer-term state relating
to the Transport Subsystem.

4.1. tmStateReference

Upon opening each SSH connection, the SSH Transport Model stores
model- transport and mechanism-specific information about security.

The RFC3411 architecture uses caches to maintain the connection in a
cache, referenced by tmStateReference. This connection information
might be consistent across multiple messages, short-term
message state, and might also be
stored uses references in the sshtmLCDTable.

For interoperability with Security Model designs, ASIs to pass this
information between subsystems.

This document defines the requirements for a cache to handle the
longer-term transport state
referenced by information, using a tmStateReference MUST include the following fields
(with sample values). See
parameter to pass this information between subsystems.

To simplify the Elements elements of Procedure for detailed
processing instructions on procedure, the use release of these fields by the SSH
Transport Model.

Harrington & Salowey state
information is not always explicitly specified. As a general rule,
if state information is available when a message being processed gets
discarded, the state related to that message SHOULD also be

Harrington, et al. Expires January 12, April 9, 2009 [Page 12] 13]

Internet-Draft Secure Shell Transport Model for SNMP July October 2008

tmTransport = snmpSSHDomain

tmAddress = an snmpSSHAddress

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

tmTransportSecurityLevel = "authPriv"

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

discarded. If state information is available when a relationship
between engines is severed, such as the section on tmSecurityName below.

tmSameSecurity = true or false, depending on whether closing of a transport
session, the Security
Model requires state information for that an outgoing response relationship SHOULD also be sent using
discarded.

Since the same
security parameters as were used for contents of a cache are meaningful only within an
implementation, and not on-the-wire, the incoming request or for
any other security-model-dependent reason. See format of the section on
tmSameSecurity below. cache and the
LCD are implementation-specific.

4.1. securityStateReference

The state referenced by tmStateReference for an SSH securityStateReference parameter is defined in RFC3411. Its
primary purpose is to provide a mapping between a request and the
corresponding response. This cache is not accessible to Transport Model
should also contain
Models, and an implementation-dependent identifier (e.g.,
tmSessionID).

The per-session state that entry is referenced by typically only retained for the lifetime of a
request-response pair of messages.

4.2. tmStateReference may be
saved across multiple messages

For each transport session, information about the transport security
is stored in a Local Configuration Datastore
(sshtmLCDTable). cache. The tmStateReference cache should be generated anew for each message,
so that it can be parameter is used to determine whether pass
model-specific and mechanism-specific parameters between the SSH session available
Transport subsystem and transport-aware Security Models.

The tmStateReference cache will typically remain valid for sending an outgoing message is the same SSH session as was used
when receiving
duration of the corresponding incoming message (e.g., a response
to a request), when tmSameSecurity is set.

A Transport Model will maintain any mapping between transport-
specific security parameters transport session, and tmTransportSecurityLevel hence may be used for several
messages.

Since this cache is only used within an implementation, and
tmSecurityName, not on-
the-wire, the precise contents and will verify format are implementation-
dependent. However, for outgoing messages that the
transport-provided security is interoperability between Transport Models
and transport-aware Security Models, entries in this cache must
include at least as strong as
tmRequestedSecurityLevel..

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

4.2. following fields:

transportDomain

transportAddress

tmSecurityName

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

Harrington & Salowey

tmRequestedSecurityLevel

tmTransportSecurityLevel

tmSameSecurity

tmSessionID

Harrington, et al. Expires January 12, April 9, 2009 [Page 13] 14]

Internet-Draft Secure Shell Transport Model for SNMP July October 2008

tmSecurityName is a human-readable name in SnmpAdminString format
that is mapped from

4.2.1. Transport information

Information about the identity that has been successfully
authenticated by SSH. By default, tmSecurityName source of an incoming SNMP message is determined passed up
from the value of the user name field of Transport subsystem as far as the SSH_MSG_USERAUTH_REQUEST
message for which a SSH_MSG_USERAUTH_SUCCESS has been received.

As described Message Processing
subsystem. However these parameters are not included in RFC4252 section 5, all authentication requests,
regardless of authentication mechanism, MUST use the same message
format, which includes a byte to indicate SSH_MSG_USERAUTH_REQUEST,
processIncomingMsg ASI defined in RFC3411, and a user name field. How the authenticated user name hence this information
is made not directly available to the SNMP implementation is SSH-implementation dependent.

The SSH Security Model.

A transport-aware Security Model might wish to take account of the
transport protocol is not always clear on whether and originating address when authenticating the user name field
must be filled in, so for some implementations, it may be
request, and setting up the authorization parameters. It is
therefore necessary for the Transport Model to use a non-default mapping algorithm. How include this
information in the SSH identity tmStateReference cache, so that it is
mapped accessible
to a tmSecurityName should be administratively configurable.
The sshtmLCDTransformPolicy object is used during the elements of
procedure to determine whether Security Model.

o transportDomain: the default transform or an
alternative tranbsform is used.

The tmSecurityName may ultimately be transport protocol (and hence the Transport
Model) used to identify receive the layer 8
principal incoming message

o transportAddress: the source of the incoming message.

Note that the ASIs used for use in such things as logging processing an outgoing message all
include explicit transportDomain and transportAddress parameters.
These fields within the tmStateReference cache will typically not be
used for access control
policy assignment. For example, USM provides this by pre-
configuration of outgoing messages.

4.2.2. securityName

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

o transport principal: the auth protocol transport-authenticated identity, on
whose behalf the secure transport connection was (or should be)
established. This value is transport-, mechanism- and auth-specific
credentials to
implementation- specific, and is only used within a securityName, in the usmUserTable. given
Transport model
transforms SHOULD generate Model.

o tmSecurityName: a predictable tmSecurityName human-readable name (in snmpAdminString format)
representing
the principal.

4.3. tmSameSecurity

If a Secure Shell this transport session is closed between the time a
request message identity. This value is received transport-
and implementation-specific, and the corresponding response message is
sent, then only used (directly) by the response message MUST be discarded, even if a new SSH
session has been established. The SSH
Transport Model does not know
whether and Security Models.

o securityName: a message contains human-readable name (in snmpAdminString format)
representing the SNMP principal in a request or response (at least
architecturally, this is not available to model-independent manner.

o Note that the transport model;
implementations principal may choose to make this available for simplicity.)

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

If the tmSameSecurity is indicated, but same as the session identified in securityName as seen by the

Harrington & Salowey Application and
Access Control subsystems. In particular, a non-transport-aware

Harrington, et al. Expires January 12, April 9, 2009 [Page 14] 15]

Internet-Draft Secure Shell Transport Model for SNMP July October 2008

tmStateReference does not match

Security Model will ignore tmSecurityName completely when
determining the current established SSH session
for SNMP securityName.

o However it is important that the tmTransportDomain, tmTransportAddress, tmSecurityName, and
tmSecurityLevel, then mapping between the message MUST be discarded, transport
principal and the
dispatcher should be notified that the sending SNMP securityName (for transport-aware Security
Models) is consistent and predictable, to allow configuration of
suitable access control and the message failed.

5. Elements establishment of Procedure

Abstract service interfaces have been defined by RFC 3411 transport
connections.

4.2.3. securityLevel

There are two distinct issues relating to describe
the conceptual data flows between security level as applied
to secure transports. For clarity, these are handled by separate
fields in the various subsystems within tmStateReference cache:

o tmTransportSecurityLevel: an
SNMP entity. The Secure Shell indication from the Transport Model uses some of these
conceptual data flows when communicating between subsystems. These
RFC 3411-defined data flows are referred to here as public
interfaces.

To simplify the elements
of procedure, the release level of state
information is security offered by this session. The Security
Model can use this to ensure that incoming messages were suitably
protected before acting on them.

o tmRequestedSecurityLevel: an indication from the Security Model of
the level of security required to be provided by the transport
protocol. The Transport Model can use this to ensure that
outgoing messages will not always explicitly specified. As a general rule, be sent over an insufficiently secure
session.

4.2.4. Session Information

For security reasons, if state information a secure transport session is available when closed between
the time a request message gets discarded, is received and the
message-state information should also corresponding response
message is sent, then the response message SHOULD be released, and discarded, even
if state
information is available when a new session is closed, the session state
information has been established. The SNMPv3 WG decided that
this should also be released.

An error indication may return an OID and value for an incremented
counter and a value for securityLevel, and values for contextEngineID
and contextName for the counter, SHOULD architecturally, and the securityStateReference it is a security-model-
specific decision whether to REQUIRE this.

When processing an outgoing message, if
the information tmSameSecurity is available at true, then
the point where tmSessionID MUST match the error is
detected. ContextEngineID and contextName are not accessible to
Transport Models, so contextEngineID is set to current transport session, otherwise
the local value of
snmpEngineID, message MUST be discarded, and contextName the dispatcher notified that
sending the message failed.

o tmSameSecurity: this flag is set used by a transport-aware Security
Model to indicate whether the default context for error
counters.

5.1. Procedures for an Incoming Message

1) The SSH Transport Model queries the SSH engine, MUST enforce this
restriction.

o tmSessionID: in an
implementation-dependent manner, order to determine verify whether the transportAddress, session has changed,
the principal name authenticated by SSH, and a Transport Model must be able to compare the session used to
receive the original request with the one to be used to send the
response. This typically requires some form of session

Harrington, et al. Expires April 9, 2009 [Page 16]

Internet-Draft Secure Shell Transport Model for SNMP October 2008

identifier.

By default, This value is only ever used by the principal Transport Model,
so the format and interpretation of this field are model-specific
and implementation-dependent.

4.3. Secure Shell Transport Model Cached Information

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

4.3.1. tmSecurityName

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

The identity SHOULD be the value of the user name field of the
SSH_MSG_USERAUTH_REQUEST message for which a SSH_MSG_USERAUTH_SUCCESS
has been received. How this the SSH user name is extracted from the SSH environment
layer is implementation-dependent.

2) Using the sshtmLCDTransformPolicy, calculate a corresponding
tmSecurityName value. Determine if there

The SSH protocol is a row in the
sshtmLCDTable with the transport address and an
sshtmLCDTmSecurityName that matches the calculated tmSecurityName
value.

3) If one does not exist, create an entry in always clear on whether the sshtmLCDTable:

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

Internet-Draft Secure Shell Transport Model user name field
must be filled in, so for SNMP July 2008

sshtmTransportAddress = transport address

sshtmLCDTmSecurityName = calculated tmSecurityName

sshtmLCDPrincipal=the SSH principal

sshtmLCDSessionID=the SSH session identifier

sshtmStorageType=volatile

sshtmRowStatus=createAndGo

4) Create some implementations, such as those using
GSSAPI authentication, it may be necessary to use a tmStateReference cache for subsequent reference mapping algorithm
to transform a user name to a SSH identity compatible with the
parameters required by this transport. How a compatible SSH identity
is determined should be administratively configurable if such a
mapping is needed.

The securityName derived from the
information.

tmTransportDomain = snmpSSHDomain

tmTransportAddress = sshtmLCDTransportAddress

tmSecurityLevel = "authPriv" tmSecurityName = sshtmLCDTmSecurityName by a security model
is used to configure notifications and access controls. Non-default
transport model transforms SHOULD generate a predictable identity
representing the principal.

4.3.2. tmSessionID = an implementation-dependent value

The tmSessionID must be refreshed upon each received message, so that
it can be used to detect when a session has closed and been replaced by another
session. The value in tmStateReference should identify determine whether the SSH session over which the message was received.

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

statusInformation =
receiveMessage(
IN transportDomain -- snmpSSHDomain
IN transportAddress -- address available for the received
sending an outgoing message
IN wholeMessage -- is the whole SNMP message from same SSH
IN wholeMessageLength -- the length of session as was used when
receiving the SNMP corresponding incoming message
IN tmStateReference -- (NEW) transport info
)

5.2. Procedures for an Outgoing Message

The Dispatcher passes the information (e.g., a response to the Transport Model using
the ASI defined a
request), when tmSameSecurity is set.

4.3.3. session state

The per-session state that is referenced by tmStateReference may be
saved across multiple messages in the transport subsystem:

Harrington & Salowey a Local Configuration Datastore.
Additional session/connection state information might also be stored

Harrington, et al. Expires January 12, April 9, 2009 [Page 16] 17]

Internet-Draft Secure Shell Transport Model for SNMP July October 2008

statusInformation =
sendMessage(
IN destTransportDomain -- transport domain to be used
IN destTransportAddress -- transport address

in a Local Configuration Datastore.

5. Elements of Procedure

Abstract service interfaces have been defined by RFC 3411 to be used
IN outgoingMessage -- describe
the message to send
IN outgoingMessageLength -- its length
IN tmStateReference -- (NEW) transport info
) conceptual data flows between the various subsystems within an
SNMP entity. The SSH Secure Shell Transport Model performs the following tasks:

1) Extract 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 tmTransportAddress, tmSecurityName, tmSameSecurity,
and tmSessionID from elements of procedure, the tmStateReference. (SSHTM ignores release of state
information is not always explicitly specified. As a general rule,
if state information is available when a message gets discarded, the
provided tmTransportDomain and tmRequestedSecurityLevel.)

2) Using tmTransportAddress
message-state information should also be released, and tmSecurityName, determine if state
information is available when a
corresponding row exists in the sshtmLCDTable.

3) If there session is closed, the session state
information should also be released.

An error indication may return an OID and value for an incremented
counter and a corresponding row, value for securityLevel, and tmSameSecurity is true, values for contextEngineID
and tmSessionID does not match sshtmLCDSessionID, then increment contextName for the sshtmSessionNoAvailableSessions counter, discard the message and return the error indication in securityStateReference if
the statusInformation.
Processing of this message stops.

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

4b) If an error is returned from OpenSession(), then discard
detected. ContextEngineID and contextName are not accessible to
Transport Models, so contextEngineID is set to the
message, local value of
snmpEngineID, and return contextName is set to the default context for error indication returned by OpenSession()
in the statusInformation.

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

6) Pass the wholeMessage to SSH
counters.

5.1. Procedures for encapsulation as data in an
SSH message.

5.3. Establishing a Session Incoming Message

1) The Secure Shell SSH Transport Model provides queries the following application
service interface (ASI) SSH engine, in an
implementation-dependent manner, to describe determine the data passed between transportAddress,
the SSH
Transport Model principal name authenticated by SSH, and a session identifier.

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

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

tmTransportDomain = snmpSSHDomain

tmTransportAddress = the address the message originated from,
determined in an implementation
decision how such data is passed.

Harrington & Salowey implementation-dependent way

tmSecurityLevel = "authPriv"

Harrington, et al. Expires January 12, April 9, 2009 [Page 17] 18]

Internet-Draft Secure Shell Transport Model for SNMP July October 2008

tmSecurityName = the ssh principal name

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

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

statusInformation =
openSession(
receiveMessage(
IN destTransportAddress transportDomain -- snmpSSHDomain
IN transportAddress -- transport address to be used for the received message
IN tmSecurityName wholeMessage -- on behalf of this principal the whole SNMP message from SSH
IN maxMessageSize wholeMessageLength -- the length of the sending SNMP entity message
IN tmStateReference -- (NEW) transport info
)

5.2. Procedures for an Outgoing Message

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

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

1) Using destTransportAddress, the client will establish an SSH
transport connection Transport Model using
the SSH ASI defined in the transport protocol, authenticate subsystem:

statusInformation =
sendMessage(
IN destTransportDomain -- transport domain to be used
IN destTransportAddress -- transport address to be used
IN outgoingMessage -- the server, and exchange keys for message integrity and encryption. to send
IN outgoingMessageLength -- its length
IN tmStateReference -- (NEW) transport info
)

The parameters of SSH Transport Model performs the transport connection following tasks. Other
implementation dependent steps may also be needed.

1) Extract the tmTransportAddress, tmSecurityName, tmSameSecurity,
and tmSessionID from the tmStateReference. (SSHTM ignores the credentials used
to authenticate are
provided tmTransportDomain and tmRequestedSecurityLevel.)

2) Using tmTransportAddress and tmSecurityName or some other
implementation dependent way, determine if a corresponding entry
in an implementation-dependent manner.

If the attempt to establish a connection is unsuccessful, or server
authentication fails, then sshtmSessionOpenErrors LCD exists.

3) If there is incremented, a corresponding entry, and
an openSession error indication tmSameSecurity is returned, true,
and openSession
processing stops.

2) Create an entry in the sshtmLCDTable:

sshtmLCDTransportAddress = tmTransportAddress

sshtmLCDTmSecurityName = tmSecurityName

Using tmSessionID does not match the sshtmLCDTransformPolicy, calculate session id stored in the corresponding
sshtmLCDPrincipal value.

3)In an implementation-specific manner, pass LCD,
then increment the sshtmLCDPrincipal to sshtmSessionNoAvailableSessions counter,

Harrington, et al. Expires April 9, 2009 [Page 19]

Internet-Draft Secure Shell Transport Model for SNMP October 2008

discard the SSH layer. The client will then invoke an SSH authentications
service to authenticate message and return the principal, such as that described error indication in the
SSH authentication protocol [RFC4252]. The credentials used to
authenticate sshtmLCDPrincipal are determined in an implementation-
dependent manner.
statusInformation. Processing of this message stops.

4) If the authentication there is unsuccessful, no corresponding LCD entry, then call openSession()
with the transport connection
is closed, tmStateReference is released, the message is discarded,
the sshtmSessionUserAuthFailures counter is incremented, an error
indication is returned to the calling module, tmTransportAddress and processing stops

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

Internet-Draft Secure Shell Transport Model for SNMP July 2008

for this message.

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

5) After the ssh-connection service is established, the client will
request a channel of type "session" in an implementation-dependent
manner. parameters.

4b) If unsuccessful, the transport connection is closed,
tmStateReference is released, the message is discarded, the
sshtmSessionChannelOpenFailures counter is incremented, an error
indication is returned to from OpenSession(), then discard the calling module,
message, and processing stops
for this message.

6) If successful, this will result in an SSH session. Set return the
sshtmLCDSessionID error indication returned by OpenSession()
in the corresponding entry. Increment the
sshtmSessionOpens counter.

7) Once statusInformation.

5) Pass the wholeMessage to SSH session has been established, the client will invoke
SNMP for encapsulation as data in 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 message.

5.3. Establishing a Session

The Secure Shell Transport Model MUST default to
providing access provides the following application
service interface (ASI) to describe the data passed between the "SNMP" SSH subsystem if the SSH session is
established using the IANA-assigned TCP port. Servers SHOULD be
configurable to allow access to the SNMP SSH subsystem over other
ports.

5.4. Closing a Session

The Secure Shell
Transport Model provides and the following ASI to close
a session: SSH service. It is an implementation
decision how such data is passed.

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

The following describes the procedure to follow to close establish a
session between a client and sever . server to run SNMP over SSH. This
process is followed used by any SNMP engine to close an SSH session. It is implementation-dependent when establishing a session should for
subsequent use.

This will be closed.

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

Internet-Draft Secure Shell Transport Model done automatically for an SNMP July 2008 application that
initiates a transaction, such as a Command Generator or a
Notification Originator or a Proxy Forwarder.

1) Lookup the session in Using destTransportAddress, the sshtmLCDTable client will establish an SSH
transport connection using the
tmTransportAddress SSH transport protocol, authenticate
the server, and tmSecurityName.

3) exchange keys for message integrity and encryption.
The destTransportAddress field may contain a user-name followed by an
'@' character (ASCII 0x40) that will indicate a specific user-name
string that should presented to the ssh server as the "user name" for
authentication purposes. This may be different than the passed
tmSecurityName value that should be used in the remaining steps
below. If there is no entry, specified user-name in the
destTransportAddress then closeSession processing is
completed.

4) Extract sshtmLCDPrincipal and sshtmLCDSessionID. Have SSH
close the session. Increment tmSecurtityName should be used as the sshtmSessionCloses counter.

6. MIB Module Overview

This MIB module provides management
user-name. The other parameters of the transport connection and the

Harrington, et al. Expires April 9, 2009 [Page 20]

Internet-Draft Secure Shell Transport
Model. It defines some needed textual conventions, and some
statistics.

6.1. Structure of the MIB Module

Objects in this MIB module Model for SNMP October 2008

credentials used to authenticate are arranged into subtrees. Each subtree
is organized as a set of related objects. The overall structure and
assignment of objects provided in an implementation-
dependent manner.

If the attempt to their subtrees, establish a connection is unsuccessful, or server
authentication fails, then sshtmSessionOpenErrors is incremented, and the intended purpose of
each subtree,
an openSession error indication is shown below.

6.2. Textual Conventions

Generic returned, and Common Textual Conventions used openSession
processing stops.

2) Create an entry in this document can be
found summarized the LCD containing, at http://www.ops.ietf.org/mib-common-tcs.html

6.3. Relationship to Other MIB Modules

Some management objects defined in other MIB modules are applicable
to a minimum, a cache of
the following information:

tmTransportAddress

tmSecurityName

3)In an entity implementing implementation-specific manner, pass the calculated user-name
from step 1) to the SSH Transport Model. In particular, it
is assumed layer. The client will then invoke an SSH
authentications service to authenticate the principal, such as that
described in the SSH authentication protocol [RFC4252]. The
credentials used to authenticate the user are determined in an entity implementing
implementation-dependent manner.

If the SSHTM-MIB will implement authentication is unsuccessful, then the SNMPv2-MIB [RFC3418], transport connection
is closed, tmStateReference is released, the SNMP-FRAMEWORK-MIB [RFC3411] and message is discarded,
the
SNMP-TRANSPORT-MIB [I-D.ietf-isms-tmsm].

This MIB module sshtmSessionUserAuthFailures counter is for managing SSH Transport Model information.
This MIB module models a sample Local Configuration Datastore for incremented, an error
indication is returned to the
Transport Model (not calling module, and processing stops
for SSH or an associated security model).

6.3.1. MIB Modules Required for IMPORTS

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

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

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

Internet-Draft Secure Shell Transport Model for SNMP July 2008

7. MIB Module Definition

SSHTM-MIB DEFINITIONS ::= BEGIN

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

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

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

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

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

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

Internet-Draft Secure Shell Transport Model for SNMP July 2008

Joseph Salowey
Cisco Systems

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

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

5) After the ssh-connection service is part of RFC XXXX;
see established, the RFC itself for full legal notices.
-- NOTE to RFC editor: replace XXXX with actual RFC number
-- for this document and remove this note
"

REVISION "200710140000Z"
DESCRIPTION "The initial version, published client will
request a channel of type "session" in RFC XXXX.
-- NOTE an implementation-dependent
manner. If unsuccessful, the transport connection is closed,
tmStateReference is released, the message is discarded, the
sshtmSessionChannelOpenFailures counter is incremented, an error
indication is returned to RFC editor: replace XXXX with actual RFC number
-- for this document the calling module, and remove processing stops
for this note
"

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

6) If successful, this note

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

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

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

snmpSSHDomain OBJECT-IDENTITY
STATUS current
DESCRIPTION
"The SNMP over an SSH transport domain. The session. Store the
session identifier in the corresponding transport
address is of type SnmpSSHAddress.

When an LCD entry. Increment the
sshtmSessionOpens counter.

7) Once the SSH session has been established, the client will invoke
SNMP entity uses as an SSH subsystem, as indicated in the snmpSSHDomain transport
model, it must be capable of accepting messages up "subsystem" parameter.

In order to

Harrington & Salowey allow SNMP traffic to be easily identified and filtered

Harrington, et al. Expires January 12, April 9, 2009 [Page 22] 21]

Internet-Draft Secure Shell Transport Model for SNMP July 2008

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

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

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

The hostname must be encoded in ASCII, as specified in
RFC3490 (Internationalizing Domain Names in Applications)
followed by a colon ':' (ASCII character 0x3A) SNMP October 2008

by firewalls and a
decimal port number in ASCII. The name other network devices, servers associated with SNMP
entities using the Secure Shell Transport Model MUST default to
providing access to the "SNMP" SSH subsystem if the SSH session is
established using the IANA-assigned TCP port. Servers SHOULD be fully
qualified whenever possible.

An IPv4 address must be a dotted decimal format followed
by
configurable to allow access to the SNMP SSH subsystem over other
ports.

5.4. Closing a colon ':' (ASCII character 0x3A) and Session

The Secure Shell Transport Model provides the following ASI to close
a decimal port
number in ASCII.

An IPv6 session:

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

The following describes the procedure to follow to close a colon separated format,
surrounded by brackets, followed by session
between a colon ':' (ASCII
character 0x3A) client and sever . This process is followed by any SNMP
engine to close an SSH session. It is implementation-dependent when
a decimal port number in ASCII.

Values of this textual convention may not session should be directly useable
as transport-layer addressing information, closed.

1) Look up the session information in the LCD using the
tmTransportAddress and may require
runtime resolution. As such, applications that write them
must be prepared for handling errors if such values are
not supported, tmSecurityName or cannot be resolved (if resolution occurs
at other implementation-
dependent mechanism.

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

3) Extract the session identifier from the LCD entry. Have SSH
close the session. Increment the time sshtmSessionCloses counter.

6. MIB Module Overview

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

6.1. Structure of the MIB Module

Objects in this MIB module are arranged into subtrees. Each subtree
is organized as a set of related objects. The DESCRIPTION clause overall structure and
assignment of TransportAddress objects that may
have snmpSSHAddress values must fully describe how (and
when) such names are to be resolved to IP addresses their subtrees, and vice
versa.

This textual convention SHOULD NOT be the intended purpose of
each subtree, is shown below.

Harrington, et al. Expires April 9, 2009 [Page 22]

Internet-Draft Secure Shell Transport Model for SNMP October 2008

6.2. Textual Conventions

Generic and Common Textual Conventions used directly in
object definitions since it restricts addresses this document can be
found summarized at http://www.ops.ietf.org/mib-common-tcs.html

6.3. Relationship to a
specific format. However, if Other MIB Modules

Some management objects defined in other MIB modules are applicable
to an entity implementing the SSH Transport Model. In particular, it
is used, it MAY be used
either on its own or in conjunction with
TransportAddressType or TransportDomain as a pair.

When this textual convention assumed that an entity implementing the SSHTM-MIB will implement
the SNMPv2-MIB [RFC3418], the SNMP-FRAMEWORK-MIB [RFC3411] and the
SNMP-TRANSPORT-MIB [I-D.ietf-isms-tmsm].

This MIB module is used as for managing SSH Transport Model information.
This MIB module models a syntax of sample Local Configuration Datastore for the
Transport Model (not for SSH or an

Harrington & Salowey associated security model).

6.3.1. MIB Modules Required for IMPORTS

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

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

7. MIB Module Definition

SSHTM-MIB DEFINITIONS ::= BEGIN

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

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

Chairs:
Juergen Quittek

Harrington, et al. Expires January 12, April 9, 2009 [Page 23]

Internet-Draft Secure Shell Transport Model for SNMP July October 2008

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

-- The sshtmSession Group

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

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

Juergen Schoenwaelder
Jacobs University Bremen
Campus Ring 1 }

sshtmSessionCloses OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The number of times a closeSession() request has been
executed, whether it succeeded or failed.
28725 Bremen
Germany
+49 421 200-3587
j.schoenwaelder@iu-bremen.de

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

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

Wes Hardaker
Sparta, Inc.
P.O. Box 382
Davis, CA 95617
USA
+1 530 792 1913
ietf@hardakers.net
"
::= { sshtmSession 2 }

sshtmSessionOpenErrors OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The number Secure Shell Transport Model MIB

Copyright (C) The IETF Trust (2007). This
version of times an openSession() request
failed this MIB module is part of RFC XXXX;
see the RFC itself for full legal notices.
-- NOTE to open a Session, RFC editor: replace XXXX with actual RFC number
-- for any reason. this document and remove this note
"
::= { sshtmSession 3 }

sshtmSessionUserAuthFailures OBJECT-TYPE

Harrington & Salowey

Harrington, et al. Expires January 12, April 9, 2009 [Page 24]

Internet-Draft Secure Shell Transport Model for SNMP July October 2008

SYNTAX Counter32
MAX-ACCESS read-only
STATUS current

REVISION "200710140000Z"
DESCRIPTION "The number of times an openSession() request
failed due initial version, published in RFC XXXX.
-- NOTE to user authentication failures. RFC editor: replace XXXX with actual RFC number
-- for this document and remove this note
"

::= { sshtmSession 4 mib-2 xxxx }

sshtmSessionChannelOpenFailures OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The
-- RFC Ed.: replace xxxx with IANA-assigned number of times an openSession() request
failed due to channel open failures.
" and
-- remove this note

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

sshtmNotifications OBJECT IDENTIFIER ::= { sshtmSession 5 sshtmMIB 0 }

sshtmSessionNoAvailableSessions OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
sshtmObjects OBJECT IDENTIFIER ::= { sshtmMIB 1 }
sshtmConformance OBJECT IDENTIFIER ::= { sshtmMIB 2 }

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

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

When an SNMP entity uses the snmpSSHDomain transport
model, it must be capable of accepting messages up to
and including 8192 octets in size. Implementation of times an outgoing message
was dropped because the same
session was no longer available.
"
::= { sshtmSession 6 }

--
larger values is encouraged whenever possible.

The table of users for securityName prefix to be associated with the Transport Security Model
--
snmpSSHDomain is 'ssh'. This table can support users of multiple transport models

sshtmLCDSpinLock OBJECT-TYPE
SYNTAX TestAndIncr
MAX-ACCESS read-write
STATUS current
DESCRIPTION "An advisory lock prefix may be used by security
models or other components to allow several cooperating
Command Generator Applications to coordinate their
use identify what secure transport
infrastructure authenticated a securityName. For further
details on the usage of facilities to alter this prefix, see the sshtmLCDTable.
"
[I-D.ietf-isms-tmsm-transport-security-model]
document and the snmpTsmConfigurationUsePrefix in the
SNMP-TSM-MIB."
::= { sshtmLCD 1 snmpDomains yy }

-- The transform policy for RFC Ed.: Please replace the SSH Transport Model

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

MAX-ACCESS read-write

Harrington & Salowey I-D reference with a proper one once it
-- has been published. Note: xml2rfc doesn't handle refs within artwork

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

Harrington, et al. Expires January 12, April 9, 2009 [Page 25]

Internet-Draft Secure Shell Transport Model for SNMP July October 2008

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

SnmpSSHAddress ::= TEXTUAL-CONVENTION
DISPLAY-HINT "1a"
STATUS current
DESCRIPTION
"The policy
"Represents either a hostname or IP address, along with a port
number and an optional username.

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

The hostname must be encoded in ASCII, as specified in
RFC3490 (Internationalizing Domain Names in Applications)
followed by a colon ':' (ASCII character 0x3A) and vice-versa.

default (1) - for incoming messages, the value passed a
decimal port number in
the user ASCII. The name field of SSH user_auth is assigned
to both sshtmLCDTmSecurityName SHOULD be fully
qualified whenever possible.

An IPv4 address must be a dotted decimal format followed
by a colon ':' (ASCII character 0x3A) and sshtmLCDPrincipal.
For outgoing messages, the value passed a decimal port
number in tmSecurityName
is assigned to both sshtmLCDTmSecurityName ASCII.

An IPv6 address must be a colon separated format, surrounded by
brackets ('[' ASCII character 0x5B and
sshtmLCDPrincipal.

private (2) - use an implementation-specific mapping
algorithm for the transform. If the algorithm does not yield ']' ASCII character
0x5D), followed by a mapping, no entry should colon ':' (ASCII character 0x3A) and a
decimal port number in ASCII.

Values of this textual convention may not be created directly useable
as transport-layer addressing information, and may require
runtime resolution. As such, applications that write them
must be prepared for handling errors if such values are
not supported, or cannot be resolved (if resolution occurs
at the identity in time of the sshtmLCDTable. It is implementation-dependent
whether a private algorithm is supported.
"
DEFVAL { default }
::= { sshtmLCD 2 }

sshtmLCDTable OBJECT-TYPE
SYNTAX SEQUENCE OF sshtmLCDEntry
MAX-ACCESS not-accessible
STATUS current management operation).

The DESCRIPTION "The table clause of users configured in the SSH
Transport Model Local Configuration Datastore (LCD).

Rows in this table can TransportAddress objects that may
have snmpSSHAddress values must fully describe how (and
when) such names are to be instantiated when an
authenticated identity is passed resolved to the transport model
from SSH, IP addresses and they can vice
versa.

This textual convention SHOULD NOT be instantiated by a command
generator.

To instantiate used directly in
object definitions since it restricts addresses to a new row in this table, the
sshtmLCDSpinLock should
specific format. However, if it is used, it MAY be used to prevent conflicts.

1) GET(sshtmLCDSpinLock.0) and save
either on its own or in sValue.

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

Harrington & Salowey conjunction with

Harrington, et al. Expires January 12, April 9, 2009 [Page 26]

Internet-Draft Secure Shell Transport Model for SNMP July October 2008

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

To maintain modularity of design, and to avoid
side-effects, only the SSH Transport Model
(or

TransportAddressType or TransportDomain as a SET operation) should modify pair.

When this table.

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

-- The sshtmSession Group

sshtmSession OBJECT IDENTIFIER ::= { sshtmLCDTable sshtmObjects 1 }

sshtmLCDEntry

sshtmSessionOpens OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The number of times an openSession() request has been
executed, whether it succeeded or failed.
"
::= SEQUENCE {
sshtmLCDTransportAddress TransportAddress,
sshtmLCDTmSecurityName SnmpAdminString,
sshtmLCDPrincipal SnmpAdminString,
sshtmLCDSessionID Integer32
sshtmLCDStorageType StorageType,
sshtmLCDRowStatus RowStatus sshtmSession 1 }

sshtmLCDTransportAddress

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

sshtmLCDTmSecurityName

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

The default transformation "The number of the SSH user name times an openSession() request
failed to

Harrington & Salowey open a Session, for any reason.
"
::= { sshtmSession 3 }

Harrington, et al. Expires January 12, April 9, 2009 [Page 27]

Internet-Draft Secure Shell Transport Model for SNMP July October 2008

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

sshtmLCDPrincipal

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

By default, this is the SSH times an openSession() request
failed due to user name. authentication failures.
"
::= { sshtmLCDEntry 5 sshtmSession 4 }

sshtmLCDStorageType

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

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

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

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

sshtmLCDRowStatus

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

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

Internet-Draft Secure Shell Transport Model for SNMP July 2008

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

The sshtmLCDPrincipal value should only be
changed when times an outgoing message
was dropped because the value of this object
is 'active'. same
session was no longer available.
"
::= { sshtmLCDEntry 7 sshtmSession 6 }

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

sshtmCompliances OBJECT IDENTIFIER ::= { sshtmConformance 1 }

sshtmGroups OBJECT IDENTIFIER ::= { sshtmConformance 2 }

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

sshtmCompliance MODULE-COMPLIANCE
STATUS current

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

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

Harrington & Salowey

Harrington, et al. Expires January 12, April 9, 2009 [Page 29] 28]

Internet-Draft Secure Shell Transport Model for SNMP July October 2008

sshtmLCDRowStatus

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

::= { sshtmGroups 2 }

END

8. Operational Considerations

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

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

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

The SSH protocol has its own windowing mechanism. RFC 4254 says: The
window size specifies how many bytes the other party can send before
it must wait for the window to be adjusted. Both parties use the
following message to adjust the window. The SSH specifications leave
it open when such window adjustment messages are created. Some
implementations have been found to send window adjustment messages
whenever received data has been passed to the application. Since

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

Internet-Draft Secure Shell Transport Model for SNMP October 2008

window adjustment messages are padded, encrypted, hmac'ed, and
wrapped, this results in noticeable bandwidth and processing
overhead, which can be avoided by sending window adjustment messages
less frequently.

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

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

Internet-Draft Secure Shell Transport Model for SNMP July 2008
feature that allows reusing a cached session key. Such a mechanism
does not exist for SSH and thus SNMP applications should keep SSH
sessions for longer time periods.

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

9. Security Considerations

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

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

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

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

The SSH Transport Model has no way to verify that server
authentication was performed, to learn the host's public key in
advance, or verify that the correct key is being used. The SSH
Transport Model simply trusts that these are properly configured by
the implementer and deployer.

Harrington, et al. Expires April 9, 2009 [Page 30]

Internet-Draft Secure Shell Transport Model for SNMP October 2008

9.1. noAuthPriv

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

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

Internet-Draft Secure Shell Transport Model for SNMP July 2008

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

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

9.2. Use with SNMPv1/v2c Messages

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

9.3. Skipping Public Key Verification

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

Harrington, et al. Expires April 9, 2009 [Page 31]

Internet-Draft Secure Shell Transport Model for SNMP October 2008

to an attacker).

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

9.4. The 'none' MAC Algorithm

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

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

Internet-Draft Secure Shell Transport Model for SNMP July 2008
flight, which means you effectively have no authentication.

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

9.5. MIB Module Security

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

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

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

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

It is RECOMMENDED that implementers consider the security features as
provided by the SNMPv3 framework (see [RFC3410] section 8), including
full support for the USM and the SSH Transport Model cryptographic
mechanisms (for authentication and privacy).

Further, deployment of SNMP versions prior to SNMPv3 is NOT
RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to
enable cryptographic security. It is then a customer/operator
responsibility to ensure that the SNMP entity giving access to an

Harrington, et al. Expires April 9, 2009 [Page 32]

Internet-Draft Secure Shell Transport Model for SNMP October 2008

instance of this MIB module is properly configured to give access to
the objects only to those principals (users) that have legitimate
rights to indeed GET or SET (change/create/delete) them.

10. IANA Considerations

IANA is requested to assign:

1. a TCP port number in the range 1..1023 in the
http://www.iana.org/assignments/port-numbers registry which will

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

Internet-Draft Secure Shell Transport Model for SNMP July 2008
be the default port for SNMP over an SSH Transport Model as
defined in this document,

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

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

4. "ssh" as the corresponding prefix for the snmpSSHDomain in the
SNMP Transport Model registry;

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

11. Acknowledgements

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

12. References

12.1. Normative References

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

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

[RFC2579] McCloghrie, K., Ed.,

Harrington, et al. Expires April 9, 2009 [Page 33]

Internet-Draft Secure Shell Transport Model for SNMP October 2008

Perkins, D., Ed., and J.
Schoenwaelder, Ed.,
"Textual Conventions for
SMIv2", STD 58, RFC 2579,
April 1999.

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

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

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

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

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

Internet-Draft Secure Shell Transport Model for SNMP July 2008

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

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

[RFC3490] Faltstrom, P., Hoffman, P.,

Harrington, et al. Expires April 9, 2009 [Page 34]

Internet-Draft Secure Shell Transport Model for SNMP October 2008

and A. Costello,
"Internationalizing Domain
Names in Applications
(IDNA)", RFC 3490,
March 2003.

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

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

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

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

[RFC4254] Ylonen, T. and C. Lonvick,
"The Secure Shell (SSH)
Connection Protocol",
RFC 4254, January 2006.

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

Harrington, et al. Expires April 9, 2009 [Page 35]

Internet-Draft Secure Shell Transport Model for SNMP October 2008

12.2. Informative References

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

[RFC3410] Case, J., Mundy, R.,
Partain, D., and B.
Stewart, "Introduction and
Applicability

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

Internet-Draft Secure Shell Transport Model for SNMP July 2008 Statements
for Internet-Standard
Management Framework",
RFC 3410, December 2002.

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

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

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

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

[RFC5090] Sterman, B., Sadolevsky,
D., Schwartz, D., Williams,
D., and W. Beck, "RADIUS

Harrington, et al. Expires April 9, 2009 [Page 36]

Internet-Draft Secure Shell Transport Model for SNMP October 2008

Extension for Digest
Authentication", RFC 5090,
February 2008.

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

[I-D.ietf-isms-transport-security-model] Harrington, D., "Transport
Security Model for SNMP", d
raft-ietf-isms-transport-
security-model-08 (work in
progress), July 2008.

Appendix A. Open Issues

We need to reach consensus on some issues.

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

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

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

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

Internet-Draft Secure Shell Transport Model for SNMP July 2008

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

o Issue #6: We have not resolved whether the principal associated
with a notification receiver must be a principal (aka user) or
whether a hostname is adequate. In SNMPv3, the access controls
are symmetrical - it is a user-level principal that access
controls apply to, whether for R/R or notify applications. Is it
acceptable to have user-level for R/R and host-level for notify

Harrington, et al. Expires April 9, 2009 [Page 37]

Internet-Draft Secure Shell Transport Model for SNMP October 2008

functionality? A user that is not allowed to GET an object might
be able to have the value of the object reported in a
notification, or vice-versa. This is not much different that a
principal having two different identities, one for R/R and another
for notifications, or an admin configuring systems to send
notifications to a different principal than those who do R/R
processing. The WG needs to discuss this and reach some consensus
on whether this is an issue or not, and how we want to proceed.

TODO:

finalize error processing in EOP

Appendix B. Change Log

From -11- to -12

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

Added separate subsection on Secure Shell Transport Model Cached
Information.

Added IANA considerations to establish a registry for domains and
corresponding prefixes.

From -10- to -11

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

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

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

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

Added operational considerations about SSH client credential
distribution.

Harrington & Salowey

Modified EOP to use sshtmLCDTable

Harrington, et al. Expires January 12, April 9, 2009 [Page 37] 38]

Internet-Draft Secure Shell Transport Model for SNMP July October 2008

Modified EOP to use sshtmLCDTable

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

From -09- to -10

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

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

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

From -08- to -09

Updated MIB assignment to by rfc4181 compatible

update MIB security considerations with coexistence issues

update sameSession and tmSessionID support

Fixed note about terminology, for consistency with SNMPv3.

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

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

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

From -07- to -08

Updated MIB

update MIB security considerations

develop sameSession and tmSessionID support

Harrington, et al. Expires April 9, 2009 [Page 39]

Internet-Draft Secure Shell Transport Model for SNMP October 2008

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

Removed reference to mappings other than the identity function.

From -06- to -07

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

Internet-Draft Secure Shell Transport Model for SNMP July 2008

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

removed references to engineIDs and discovery

removed references to securityModel.

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

added keyboard interactive discussion

noted some implementation-dependent points

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

cleaned up ASIs

modified MIB to be under snmpModules

changed transportAddressSSH to snmpSSHDomain style addressing

From -05- to -06

replaced transportDomainSSH with RFC3417-style snmpSSHDomain

replaced transportAddressSSH with RFC3417-style snmpSSHAddress

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

From -04- to -05

added sshtmUserTable

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

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

Harrington, et al. Expires April 9, 2009 [Page 40]

Internet-Draft Secure Shell Transport Model for SNMP October 2008

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

Removed security-model-specific processing from this document.

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

Internet-Draft Secure Shell Transport Model for SNMP July 2008

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

changed tmSessionReference back to tmStateReference

"From -03- to -04-"

changed tmStateReference to tmSessionReference

"From -02- to -03-"

rewrote almost all sections

merged ASI section and Elements of Procedure sections

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

updated references

creayted

created a conventions section to identify common terminology.

rewrote sections on how SSH addresses threats

rewrote mapping SSH to engineID

eliminated discovery section

detailed the Elements of Procedure

eliminated secrtions sections on msgFlags, transport parameters

resolved issues of opening notifications

eliminated sessionID (TMSM needs to be updated to match)

eliminated use of tmsSessiontable except as an example

updated Security Considerations

"From -01- to -02-"

Harrington, et al. Expires April 9, 2009 [Page 41]

Internet-Draft Secure Shell Transport Model for SNMP October 2008

Added TransportDomainSSH and Address

Removed implementation considerations

Changed all "user auth" to "client auth"

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

Internet-Draft Secure Shell Transport Model for SNMP July 2008

Removed unnecessary MIB module objects

updated references

improved consistency of references to TMSM as architectural
extension

updated conventions

updated threats to be more consistent with RFC3552

discussion of specific SSH mechanism configurations moved to
security considerations

modified session discussions to reference TMSM sessions

expanded discussion of engineIDs

wrote text to clarify the roles of MPSP and TMSP

clarified how snmpv3 message parts are ised by SSHSM

modified nesting of subsections as needed

securityLevel used by the SSH Transport Model always equals
authpriv
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 secshell RFCs

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

updated security considerations

removed Juergen Schoenwaelder from authors, at his request

Harrington & Salowey

Harrington, et al. Expires January 12, April 9, 2009 [Page 41] 42]

Internet-Draft Secure Shell Transport Model for SNMP July October 2008

updated security considerations

removed Juergen Schoenwaelder from authors, at his request

ran the mib module through smilint

Authors' Addresses

David Harrington
Huawei Technologies (USA)
1700 Alma Dr. Suite 100
Plano, TX 75075
USA

Phone: +1 603 436 8634
EMail: dharrington@huawei.com

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

EMail: jsalowey@cisco.com

Harrington & Salowey

Wes Hardaker
Sparta, Inc.
P.O. Box 382
Davis, CA 95617
US

Phone: +1 530 792 1913
EMail: ietf@hardakers.net

Harrington, et al. Expires January 12, April 9, 2009 [Page 42] 43]

Internet-Draft Secure Shell Transport Model for SNMP July October 2008

Full Copyright Statement

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

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

Intellectual Property

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

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

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

Harrington & Salowey

Harrington, et al. Expires January 12, April 9, 2009 [Page 43] 44]

----