Network Working Group D. Harrington
Internet-Draft Huawei Technologies (USA)
Intended status: Standards Track J. Salowey
Expires: April 14, 2007 Cisco Systems
October 11, 2006
Secure Shell Transport Model for SNMP
draft-ietf-isms-secshell-05.txt
Status of This Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 14, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This memo describes a Transport Model for the Simple Network
Management Protocol, using the Secure Shell protocol.
Harrington & Salowey Expires April 14, 2007 [Page 1]
Internet-Draft Secure Shell Transport Model for SNMP October 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. The Internet-Standard Management Framework . . . . . . . . 4
1.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Modularity . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 5
1.5. Constraints . . . . . . . . . . . . . . . . . . . . . . . 7
2. The Secure Shell Protocol . . . . . . . . . . . . . . . . . . 7
3. How SSHTM Fits into the Transport Subsystem . . . . . . . . . 8
3.1. Security Capabilities of this Model . . . . . . . . . . . 8
3.1.1. Threats . . . . . . . . . . . . . . . . . . . . . . . 8
3.1.2. Data Origin Authentication Issues . . . . . . . . . . 9
3.1.3. Authentication Protocol . . . . . . . . . . . . . . . 10
3.1.4. Privacy Protocol . . . . . . . . . . . . . . . . . . . 11
3.1.5. Protection against Message Replay, Delay and
Redirection . . . . . . . . . . . . . . . . . . . . . 11
3.1.6. SSH Subsystem . . . . . . . . . . . . . . . . . . . . 11
3.1.7. Troubleshooting . . . . . . . . . . . . . . . . . . . 11
3.1.8. Mapping SSH to EngineID . . . . . . . . . . . . . . . 12
3.2. Security Parameter Passing . . . . . . . . . . . . . . . . 13
3.3. Notifications and Proxy . . . . . . . . . . . . . . . . . 13
4. Passing Security Parameters . . . . . . . . . . . . . . . . . 14
4.1. tmStateReference . . . . . . . . . . . . . . . . . . . . . 14
4.2. securityStateReference . . . . . . . . . . . . . . . . . . 14
5. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 15
5.1. Procedures for an Incoming Message . . . . . . . . . . . . 15
5.2. Procedures for an Outgoing Message . . . . . . . . . . . . 16
5.3. Establishing a Session . . . . . . . . . . . . . . . . . . 17
5.4. Closing a Session . . . . . . . . . . . . . . . . . . . . 19
6. MIB Module Overview . . . . . . . . . . . . . . . . . . . . . 20
6.1. Structure of the MIB Module . . . . . . . . . . . . . . . 20
6.2. Textual Conventions . . . . . . . . . . . . . . . . . . . 20
6.3. The sshtmStats Subtree . . . . . . . . . . . . . . . . . . 20
6.4. The sshtmUserTable . . . . . . . . . . . . . . . . . . . . 20
6.5. Relationship to Other MIB Modules . . . . . . . . . . . . 20
6.5.1. MIB Modules Required for IMPORTS . . . . . . . . . . . 21
7. MIB module definition . . . . . . . . . . . . . . . . . . . . 21
8. Security Considerations . . . . . . . . . . . . . . . . . . . 29
8.1. noAuthPriv . . . . . . . . . . . . . . . . . . . . . . . . 29
8.2. skipping public key verification . . . . . . . . . . . . . 30
8.3. the 'none' MAC algorithm . . . . . . . . . . . . . . . . . 30
8.4. MIB module security . . . . . . . . . . . . . . . . . . . 30
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
11.1. Normative References . . . . . . . . . . . . . . . . . . . 32
11.2. Informative References . . . . . . . . . . . . . . . . . . 33
Harrington & Salowey Expires April 14, 2007 [Page 2]
Internet-Draft Secure Shell Transport Model for SNMP October 2006
Appendix A. Open Issues . . . . . . . . . . . . . . . . . . . . . 34
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 34
Harrington & Salowey Expires April 14, 2007 [Page 3]
Internet-Draft Secure Shell Transport Model for SNMP October 2006
1. Introduction
This memo describes a Transport Model for the Simple Network
Management Protocol, using the Secure Shell protocol within a
transport subsystem [I-D.ietf-isms-tmsm]. The transport model
specified in this memo is referred to as the Secure Shell Transport
Model (SSHTM).
This memo also defines a portion of the Management Information Base
(MIB) for use with network management protocols in TCP/IP based
internets. In particular it defines objects for monitoring and
managing the Secure Shell Transport Model for SNMP.
It is important to understand the SNMP architecture 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
The terms "manager" and "agent" are not used in this document,
because in the RFC 3411 architecture, all SNMP entities have the
capability of acting as either manager or agent or both depending on
the SNMP applications included in the engine. Where distinction is
required, the application names of Command Generator, Command
Responder, Notification 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
Harrington & Salowey Expires April 14, 2007 [Page 4]
Internet-Draft Secure Shell Transport Model for SNMP October 2006
client or as server, as discussed further below.
While SSH and USM frequently refer to a user, the terminology used in
RFC3411 [RFC3411] and in this memo is "principal". A principal is
the "who" on whose behalf services are provided or processing takes
place. A principal can be, among other things, an individual acting
in a particular role; a set of individuals, with each acting in a
particular role; an application or a set of applications, 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.
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 decisions to use self-contained
documents, this memo includes the elements of procedure plus
associated MIB objects which are needed for processing the Secure
Shell Transport Model for SNMP. These MIB objects SHOULD NOT be
referenced in other documents. This allows the Secure Shell
Transport Model for SNMP to be designed and documented as independent
and self- contained, having no direct impact on other modules, and
allowing this module to be upgraded and supplemented as the need
arises, and to move along the standards track on different time-lines
from other modules.
This modularity of specification is not meant to be interpreted as
imposing any specific requirements on implementation.
1.4. Motivation
Version 3 of the Simple Network Management Protocol (SNMPv3) added
security to the protocol. The User Security Model (USM) [RFC3414]
Harrington & Salowey Expires April 14, 2007 [Page 5]
Internet-Draft Secure Shell Transport Model for SNMP October 2006
was designed to be independent of other existing security
infrastructures, to ensure it could function when third party
authentication services were not available, such as in a broken
network. As a result, USM typically utilizes a separate user and key
management infrastructure. Operators have reported that deploying
another user and key management infrastructure in order to use SNMPv3
is a reason for not deploying SNMPv3 at this point in time.
This memo describes a 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 the time
until deployment is possible.
The work will address the requirement for the SSH client to
authenticate the SSH server, for the SSH server to authenticate the
SSH client, and describe how SNMP can make use of the authenticated
identities in authorization policies for data access, in a manner
that is independent of any specific access control model.
The work will include the ability to use any of the client
authentication methods described in "SSH Authentication Protocol"
[RFC4252] - public key, password, and host-based. Local accounts may
be supported through the use of the public key, host-based or
password based mechanisms. The password based mechanism allows for
integration with deployed password infrastructure such as AAA servers
using the RADIUS protocol [RFC2865]. The SSH Transport Model SHOULD
be able to take advantage of other defined authentication mechanism
such as those defined in [RFC4462] and future mechanisms such as
those that make use of X.509 certificate credentials. This will
allow the SSH Transport Model to utilize client authentication and
key exchange mechanisms which support different security
infrastructures and provide different security properties.
It is desirable to use mechanisms that could unify the approach for
administrative security for SNMPv3 and Command Line interfaces (CLI)
and other management interfaces. The use of security services
provided by Secure Shell is the approach commonly used for the CLI,
and is the approach being adopted for use with NETCONF
[I-D.ietf-netconf-ssh]. This memo describes a method for invoking
and running the SNMP protocol within a Secure Shell (SSH) session as
an SSH subsystem.
This memo describes how SNMP can be used within a Secure Shell (SSH)
session, using the SSH connection protocol [RFC4254] over the SSH
transport protocol, using SSH user-auth [RFC4252] for authentication.
Harrington & Salowey Expires April 14, 2007 [Page 6]
Internet-Draft Secure Shell Transport Model for SNMP October 2006
There are a number of challenges to be addressed to map Secure Shell
authentication method parameters into the SNMP architecture so that
SNMP continues to work without any surprises. These are discussed in
detail below.
1.5. Constraints
The design of this SNMP Transport Model is influenced by the
following constraints:
1. When the requirements of effective management in times of network
stress are inconsistent with those of security, the design of
this model gives preference to effective management.
2. In times of network stress, the transport protocol and its
underlying security mechanisms SHOULD NOT depend upon the ready
availability of other network services (e.g., Network Time
Protocol (NTP) or AAA protocols).
3. When the network is not under stress, the transport model and its
underlying security mechanisms MAY depend upon the ready
availability of other network services.
4. It may not be possible for the transport model to determine when
the network is under stress.
5. A transport model should require no changes to the SNMP
architecture.
6. 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
components:
o The Transport Layer Protocol [RFC4253] provides server
authentication, and message confidentiality and integrity. It may
optionally also provide compression. The transport layer will
typically be run over a TCP/IP connection, but might also be used
on top of any other reliable data stream.
o The User Authentication Protocol [RFC4252] authenticates the
client-side principal to the server. It runs over the transport
layer protocol.
o The Connection Protocol [RFC4254] multiplexes the encrypted tunnel
into several logical channels. It runs over the transport after
successfully authenticating the principal.
The client sends a service request once a secure transport layer
connection has been established. A second service request is sent
after client authentication is complete. This allows new protocols
to be defined and coexist with the protocols listed above.
Harrington & Salowey Expires April 14, 2007 [Page 7]
Internet-Draft Secure Shell Transport Model for SNMP October 2006
The connection protocol provides channels that can be used for a wide
range of purposes. Standard methods are provided for setting up
secure interactive shell sessions and for forwarding ("tunneling")
arbitrary TCP/IP ports and X11 connections.
3. How SSHTM Fits into the Transport Subsystem
A transport model plugs into the Transport Subsystem. The SSH
Transport Model thus fits between the underlying SSH transport layer
and the message dispatcher [RFC3411].
The SSH Transport Model will establish an encrypted tunnel 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 encrypyed, and the receiving transport model
accepts decrypted incoming messages from SSH and passes them to the
disptacher.
After an SSH Transport model tunnel is established, then SNMP
messages can conceptually be sent through the tunnel from one SNMP
message dispatcher to another SNMP message dispatcher. Multiple SNMP
messages MAY be passed through the same tunnel.
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 - the principal on whose behalf a received SNMP message
claims to have been generated. It is not possible to assure the
specific principal that originated a received SNMP message;
rather, it is the principal on whose behalf the message was
Harrington & Salowey Expires April 14, 2007 [Page 8]
Internet-Draft Secure Shell Transport Model for SNMP October 2006
originated that is authenticated. SSH provides verification of
the identity of the SSH server through the SSH Transport Protocol
server authentication [RFC4253]
4. Verification of principal identity is important for use with the
SNMP access control subsystem, to ensure that only authorized
principals have access to potentially sensitive data. The SSH
user identity will be used to map to an SNMP model-independent
securityName for use with SNMP access control.
5. Authenticating both the SSH server and the SSH client ensures the
authenticity of the SNMP engine that provides MIB data, whether
that engine resides on the server or client side of the
association. Operators or management applications might act upon
the data they receive (e.g., raise an alarm for an operator,
modify the configuration of the device that sent the
notification, modify the configuration of other devices in the
network as the result of the notification, and so on), so it is
important to know that the provider of MIB data is authentic.
6. Disclosure - 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. Data Origin Authentication Issues
The RFC 3411 architecture recognizes three levels of security:
- without authentication and without privacy (noAuthNoPriv)
- with authentication but without privacy (authNoPriv)
- with authentication and with privacy (authPriv)
The Secure Shell protocol provides support for encryption and data
integrity. While it is technically possible to support no
authentication and no encryption in SSH it is NOT RECOMMENDED by
[RFC4253].
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
Harrington & Salowey Expires April 14, 2007 [Page 9]
Internet-Draft Secure Shell Transport Model for SNMP October 2006
whether an underlying SSH connection provides auth or priv, so the
SSH Transport Model trusts that the underlying SSH connection has
been properly configured to support authPriv security
characteristics.
The SSH Transport Model does not know about the algorithms or options
to open SSH sessions that match different securityLevels. For
interoperability of the trust assumptions between SNMP engines, an
SSH Transport Model-compliant implementation MUST use an SSH
connection that provides authentication, data integrity and
encryption that meets the highest level of SNMP security (authPriv).
Outgoing messages requested by SNMP applications and specified with a
lesser securityLevel (noAuthNoPriv or authNoPriv) are sent by the SSH
Transport Model as authPriv securityLevel.
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
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
others.
The password authentication mechanism allows for integration with
deployed password based infrastructure. It is possible to hand a
password to a service such as RADIUS [RFC2865] or Diameter [RFC3588]
for validation. The validation could be done using the user-name and
user-password attributes. It is also possible to use a different
password validation protocol such as CHAP [RFC1994] or digest
authentication [RFC 2617, draft-ietf-radext-digest-auth-04] to
integrate with RADIUS or Diameter. These mechanisms leave the
password in the clear on the device that is authenticating the
password which introduces threats to the authentication
infrastructure.
GSSKeyex [RFC4462] provides a framework for the addition of client
authentication mechanisms which support different security
infrastructures and provide different security properties.
Additional authentication mechanisms, such as one that supports X.509
certificates, may be added to SSH in the future.
Harrington & Salowey Expires April 14, 2007 [Page 10]
Internet-Draft Secure Shell Transport Model for SNMP October 2006
3.1.4. Privacy Protocol
The SSH transport layer protocol provides strong encryption, server
authentication, and integrity protection.
3.1.5. Protection against Message Replay, Delay and Redirection
SSH uses sequence numbers and integrity checks to protect against
replay and reordering of messages within a connection.
SSH also provides protection against replay of entire sessions. In a
properly-implemented DH exchange, both sides will generate new random
numbers for each exchange, which means the exchange hash and thus the
encryption and integrity keys will be distinct for every session.
3.1.6. SSH Subsystem
This 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.
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, securityModel, and securityLevel, and engineID
associated with each session.
3.1.7. Troubleshooting
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.
Harrington & Salowey Expires April 14, 2007 [Page 11]
Internet-Draft Secure Shell Transport Model for SNMP October 2006
3.1.8. Mapping SSH to EngineID
In the RFC3411 architecture, there are three use cases for an
engineID:
snmpEngineID - RFC3411 includes the SNMP-FRAMEWORK-MIB, which
defines a snmpEngineID object. An snmpEngineID is the unique and
unambiguous identifier of an SNMP engine. Since there is a one-
to-one association between SNMP engines and SNMP entities, it also
uniquely and unambiguously identifies the SNMP entity within an
administrative domain.
contextEngineID - Management information resides at an SNMP entity
where a Command Responder Application has local access to
potentially multiple contexts. A Command Responder application
uses a contextEngineID equal to the snmpEngineID of its associated
SNMP engine, and the contextEngineID is included in a scopedPDU to
identify the engine associated with the data contained in the PDU.
securityEngineID - The securityEngineID is used by USM when
performing integrity checking and authentication, to look up
values in the USM tables, and to synchronize "clocks". The
securityEngineID is not needed by the SSH Transport Model, since
integrity checking and authentication are handled outside the SNMP
engine. The RFC3411 architecture defines ASIs that include a
securityEngineID; the SSH Transport Model should always set the
securityEngineID equal to the local value of snmpEngineID.0 to
satisfy the elements of procedure for generateRequestMsg() defined
in RFC3412.[RFC3412]
The SSH Transport Model needs to know the engineID of a target system
if the target system supports multiple engineIDs at the same address.
An engineID differentiates multiple engines residing at the same
transportAddress, and diferentiates the corresponding rows in the
Local Configuration Datastore.
This may occur if one SNMP engine is used to manage the host system,
and another to manage specific application functionality at the host,
such as a relational database system or a networking card.
The engineID can also be used to differentiate multiple engines
addressable at the same transport address, where messages for some
engineIDs are forwarded to different addresses using an SNMP
application, such as the SNMP proxy-forwarding application described
in RFC3413..
The engineID discovery mechanism is implementation-dependent.
[discuss: this is unacceptable because it is not interoperable. The
LCD can be implementation-dependent, but the discovery needs to be
either manual or interoperable. And given that USM addresses are not
the same as SSH addresses, we cannot even copy the info from the USM
discovery.]
Harrington & Salowey Expires April 14, 2007 [Page 12]
Internet-Draft Secure Shell Transport Model for SNMP October 2006
3.2. Security Parameter Passing
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 recvMessage() ASI.
For outgoing messages, the transport model takes input provided by
the dispatcher in the sendMessage() ASI. The SSH Transport Model
converts that information into suitable security parameters for SSH,
establishes sessions as needed, and passes messages to the SSH
subsystem for sending.
3.3. Notifications and Proxy
SSH connections may be initiated by command generators or by
notification originators. Command generators are frequently operated
by a human, but notification originators are usually unmanned
automated processes. As a result, it may be necessary to provision
authentication credentials on the SNMP engine containing the
notification originator, or use a third party key provider such as
Kerberos, so the engine can successfully authenticate to an engine
containing a notification receiver.
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 securityModel,
securityName, and securityLevel parameters are configured in the
snmpTargetParamsTable. The default approach is for an administrator
to statically preconfigure this information to identify the targets
authorized to receive notifications or perform proxy.
These MIB modules may be configured using SNMP or other
implementation-dependent mechanisms, such as CLI scripting or loading
a configuration file.
Harrington & Salowey Expires April 14, 2007 [Page 13]
Internet-Draft Secure Shell Transport Model for SNMP October 2006
4. Passing Security Parameters
For the SSH Transport Model, there are two levels of state that need
to be maintained: the session state, and the message state.
4.1. tmStateReference
For each connection, the SSH Transport Model stores information about
the connection in the Local Configuration Datastore, supplemented
with a cache to store model- and mechanism-specific parameters.
Upon opening an SSH connection, the SSH Transport Model will store
the transport parameters in the LCD. For ease of understanding, this
document represents the LCD as an SSHTM-MIB module.
tmsLCDTransport = transportDomainSSH
tmsLCDAddress = a TransportAddressSSH
tmsLCDSecurityLevel = "authPriv"
tmsLCDSecurityName = the principal name authenticated by SSH. How
this data is extracted from the SSH environment and how it is
translated into a securityName is implementation-dependent. By
default, the tmSecurityName is the name that has been successfully
authenticated by SSH, from the user name field of the
SSH_MSG_USERAUTH_REQUEST message.
tmsLCDEngineID = if known, the value of the remote engine's
snmpEngineID.
tmsLCDSecurityModel = a security model. The SSH Transport Model
is designed to work with multiple security models. the default is
the Transport Security Model.
How the SSH identity is extracted from the SSH layer, and how the SSH
identity is mapped to a securityName for storage in the LCD is
implementation-dependent. Additional information may be stored in a
local datastore (such as a preconfigured mapping table) or in a
cache, such as the value of an SSH session identifier (as distinct
from an SNMP session).
The tmStateReference is used to pass references containing the
appropriate SSH session information from the transport model for
subsequent processing.
The SSH Transport Model has the responsibility for explicitly
releasing the complete tmStateReference and deleting the associated
information from the LCD when the session is destroyed.
4.2. securityStateReference
For each message received, the SSH Transport Model caches message-
specific SSH security information such that a Response message can be
Harrington & Salowey Expires April 14, 2007 [Page 14]
Internet-Draft Secure Shell Transport Model for SNMP October 2006
generated using the same security information, even if the Local
Configuration Datastore is altered between the time of the incoming
request and the outgoing response. The securityStateReference is
used to preserve the data needed to generate a Response message with
the same security information. This information includes the model-
independent parameters (securityName, securityLevel, securityModel,
transport address, transport type, and engineID). The Message
Processing Model has the responsibility for explicitly releasing the
securityStateReference when such data is no longer needed. The
securityStateReference cached data may be implicitly released via the
generation of a response, or explicitly released by using the
stateRelease primitive, as described in RFC 3411 section 4.5.1."
The SSH standard does not require that an SSH session be maintained
nor that it be closed when the keys associated with the host or
client associated with the session are changed. Some SSH
implementations might close an existing session if the keys
associated with the session change. For the SSH Transport Model, if
the session is closed between the time a Request is received and a
Response message is being prepared, then the Response should be
discarded.
5. Elements of Procedure
Abstract service interfaces have been defined by RFC 3411 to describe
the conceptual data flows between the various subsystems within an
SNMP entity. The Secure Shell Transport Model uses some of these
conceptual data flows when communicating between subsystems. These
RFC 3411-defined data flows are referred to here as public
interfaces.
To simplify the elements of procedure, the release of state
information is not always explicitly specified. As a general rule,
if state information is available when a message gets discarded, the
message-state information should also be released, and if state
information is available when a session is closed, the session state
information should also be released.
An error indication may return an OID and value for an incremented
counter and a value for securityLevel, and values for contextEngineID
and contextName for the counter, and the securityStateReference if
the information is available at the point where the error is
detected.
5.1. Procedures for an Incoming Message
For an incoming message, the SSH Transport Model will put information
from the SSH layer into a Local Configuration Datastore referenced by
Harrington & Salowey Expires April 14, 2007 [Page 15]
Internet-Draft Secure Shell Transport Model for SNMP October 2006
tmStateReference.
1) The SSH Transport Model queries the associated SSH engine, in
an implementation-dependent manner, to determine the transport and
security parameters for the received message.
transportDomain = transportDomainSSH
transportAddress = a TransportAddressSSH
tmsTransportModel - SSH Transport Model
tmsSecurityLevel = "authPriv"
tmsSecurityName = the principal name authenticated by SSH. How
this data is extracted from the SSH environment and how it is
translated into a securityName is implementation-dependent. By
default, the tmSecurityName is the name that has been
successfully authenticated by SSH, from the user name field of
the SSH_MSG_USERAUTH_REQUEST message.
2) If one does not exist, the SSH Transport Model creates an entry
in a Local Configuration Datastore, in an implementation-dependent
format, containing the information and any implementation-specific
parameters desired, and creates a tmStateReference for subsequent
reference to the information.
Then the Transport model passes the message to the Dispatcher using
the following primitive:
statusInformation =
recvMessage(
OUT transportDomain -- domain for the received message
OUT transportAddress -- address for the received message
OUT wholeMessage -- the whole SNMP message from SSH
OUT wholeMessageLength -- the length of the SNMP message
OUT tmStateReference
)
5.2. Procedures for an Outgoing Message
The Dispatcher passes the information to the Transport Model using
the ASI defined in the transport subsystem:
statusInformation =
sendMessage(
IN destTransportDomain -- transport domain to be used
IN destTransportAddress -- transport address to be used
IN outgoingMessage -- the message to send
IN outgoingMessageLength -- its length
IN tmStateReference
)
Harrington & Salowey Expires April 14, 2007 [Page 16]
Internet-Draft Secure Shell Transport Model for SNMP October 2006
The SSH Transport Model performs the following tasks:
1) Determine the target 5-tuple index by extracting the
transportDomain, transportAddress, securityName, securityLevel,
and securityModel from the tmStateReference.
2) Lookup the session in the Local Configuration Datastore using
the target index
3) If there is no session open associated with the target index,
then call openSession().
3a) If an error is returned from OpenSession(), then discard the
message and return the error indication in the statusInformation.
3b) If openSession() is successful, then store any implementation-
specific information in the LCD for subsequent use.
4) Extract any implementation-specific parameters from the LCD
5) Pass the wholeMessage to SSH for encapsulation in an
SSH_MSG_CHANNEL_DATA message.
5.3. Establishing a Session
The Secure Shell Transport Model provides the following primitive to
describe the data passed between the Transport Model and the SSH
service. It is an implementation decision how such data is passed.
statusInformation =
openSession(
IN destTransportDomain -- transport domain to be used
IN destTransportAddress -- transport address to be used
IN securityModel -- Security Model to use
IN securityName -- on behalf of this principal
IN securityLevel -- Level of Security requested
IN maxMessageSize -- of the sending SNMP entity
OUT tmStateReference
)
The following describes the procedure to follow to establish a
session between a client and server to run SNMP over SSH. This
process is followed by any SNMP engine establishing a session for
subsequent use.
This will be done automatically for an SNMP application that
initiates a transaction, such as a Command Generator or a
Notification Originator or a Proxy Forwarder.
The need to establish a session is never triggered by an application
sending a response message, such as a Command Responder or
Notification Receiver, because securityStateReference will always
have the information for an existing session, identifiable via
Harrington & Salowey Expires April 14, 2007 [Page 17]
Internet-Draft Secure Shell Transport Model for SNMP October 2006
tmStateReference. [todo: where in the EoP is this put into the
dataflow? The transport model should only see a wholemessage, so it
doesn't know if this is a response; that has to be done by the
messaging model. Do we have to worry about a session being shutdown
while the request is between messaging and transport?]
1) Using destTransportDomain and destTransportAddress, the client
will establish an SSH transport connection using the SSH transport
protocol, authenticate the server, and exchange keys for message
integrity and encryption. The parameters of the transport connection
and the credentials used to authenticate are provided in an
implementation-dependent manner.
If the attempt to establish a connection is unsuccessful, or server
authentication fails, then an error indication is returned, and
openSession processing stops.
2) The provided transport domain, transport address, securityModel,
securityName and securityLevel are used to lookup an associated entry
in the Local Configuration Datastore (LCD). Any model-specific
information concerning the principal at the destination is extracted.
This step allows preconfiguration of model-specific principals mapped
to the transport/name/level, for example, for sending notifications.
Set the username in the SSH_MSG_USERAUTH_REQUEST to the username
extracted from the LCD.
If information about the principal is absent from the LCD, then set
the username in the SSH_MSG_USERAUTH_REQUEST to the value of
securityName. This allows a deployment without preconfigured
mappings between model-specific and model-independent names, but the
securityName will need to contain a username recognized by the
authentication mechanism.
3)The client will then invoke the "ssh-userauth" service to
authenticate the user, as described in the SSH authentication
protocol [RFC4252]. [todo: does the client invoke this, or the
server?]
If the authentication is unsuccessful, then the transport connection
is closed, tmStateReference is released, the message is discarded, an
error indication (unknownSecurityName) is returned to the calling
module, and processing stops for this message.
4) Once the principal has been successfully authenticated, the client
will invoke the "ssh- connection" service, also known as the SSH
connection protocol [RFC4254].
5) After the ssh-connection service is established, the client will
Harrington & Salowey Expires April 14, 2007 [Page 18]
Internet-Draft Secure Shell Transport Model for SNMP October 2006
use an SSH_MSG_CHANNEL_OPEN message to open a channel of type
"session", providing a selected sender channel number, and a maximum
packet size calculated from the SNMP maxMessageSize.
6) If successful, this will result in an SSH session. The
destTransportDomain and the destTransportAddress, plus the "recipient
channel" and "sender channel" and other relevant data from the
SSH_MSG_CHANNEL_OPEN_CONFIRMATION should be retained so they can be
added to the LCD for subsequent use.
7) Once the SSH session has been established, the client will invoke
SNMP as an SSH subsystem, as indicated in the "subsystem" parameter.
In order to allow SNMP traffic to be easily identified and filtered
by firewalls and other network devices, servers associated with SNMP
entities using the Secure Shell Transport Model MUST default to
providing access to the "SNMP" SSH subsystem if the SSH session is
established using the IANA-assigned TCP port (TBD by IANA). Servers
SHOULD be configurable to allow access to the SNMP SSH subsystem over
other ports.
8) Create an entry in a Local Configuration Datastore containing the
provided transportDomain, transportAddress, securityName,
securityLevel, and securityModel, and SSH-speciifc parameters and
create a tmStateReference to reference the entry.
9) At this point an implementation MAY perform some type of engineID
discovery to determine a mapping between the remote transport
address, the SSH session, and a contextEngineID.
The contextEngineID of a remote engine needs to be "discovered" for
use in request messages. USM, the mandatory-to-implement security
model, can perform discovery of the snmpEngineIDs of adjacent engines
using Reports (see [RFC3414] section 3.2 3b). Then the discovered
snmpEngineID for the remote engine can be used as the contextEngineID
in requests passed using the SSH Transport Model.
5.4. Closing a Session
The Secure Shell Transport Model provides the following primitive to
pass data back and forth between the Transport Model and the SSH
service:
statusInformation =
closeSession(
IN tmStateReference
)
Harrington & Salowey Expires April 14, 2007 [Page 19]
Internet-Draft Secure Shell Transport Model for SNMP October 2006
The following describes the procedure to follow to close a session
between a client and sever . This process is followed by any SNMP
engine closing the corresponding SNMP session.
1) Determine the target 5-tuple index by extracting the
transportDomain, transportAddress, securityName, securityLevel,
and securityModel from the tmStateReference.
2) Lookup the session in the Local Configuration Datastore using
the target index
3) If there is no session open associated with the target index,
then closeSession processing is completed..
4) Extract any implementation-specific parameters from the LCD
5) Have SSH close the specified session.
6. MIB Module Overview
This MIB module provides management of the Secure Shell Transport
Model. It defines some needed textual conventions, and some
statistics.
6.1. Structure of the MIB Module
Objects in this MIB module are arranged into subtrees. Each subtree
is organized as a set of related objects. The overall structure and
assignment of objects to their subtrees, and the intended purpose of
each subtree, is shown below.
6.2. Textual Conventions
Generic and Common Textual Conventions used in this document can be
found summarized at http://www.ops.ietf.org/mib-common-tcs.html
6.3. The sshtmStats Subtree
This subtree contains SSH transport-model-dependent counters.
This subtree provides information for identifying fault conditions
and performance degradation.
6.4. The sshtmUserTable
This table contains SSH Transport Model information about SSH
principals.
6.5. Relationship to Other MIB Modules
Some management objects defined in other MIB modules are applicable
to an entity implementing the SSH Transport Model. In particular, it
Harrington & Salowey Expires April 14, 2007 [Page 20]
Internet-Draft Secure Shell Transport Model for SNMP October 2006
is assumed that an entity implementing the SSHTM-MIB will implement
the SNMPv2-MIB [RFC3418], the SNMP-FRAMEWORK-MIB [RFC3411] and the
Transport-Subsystem-MIB [I-D.ietf-isms-tmsm].
This MIB module is for managing SSH Transport Model information.
This MIB module models a sample Local Configuration Datastore.
6.5.1. MIB Modules Required for IMPORTS
The following MIB module imports items from [RFC2578], [RFC2579],
[RFC2580], [RFC3411], [RFC3419], and [I-D.ietf-isms-tmsm]
This MIB module also references [RFC3490]
7. MIB module definition
SSHTM-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE,
OBJECT-IDENTITY, mib-2, snmpDomains
FROM SNMPv2-SMI
TestAndIncr, TEXTUAL-CONVENTION,
StorageType, RowStatus
FROM SNMPv2-TC
MODULE-COMPLIANCE, OBJECT-GROUP
FROM SNMPv2-CONF
SnmpAdminString
FROM SNMP-FRAMEWORK-MIB
TransportAddress, TransportAddressType
FROM TRANSPORT-ADDRESS-MIB
;
sshtmMIB MODULE-IDENTITY
LAST-UPDATED "200610050000Z"
ORGANIZATION "ISMS Working Group"
CONTACT-INFO "WG-EMail: isms@lists.ietf.org
Subscribe: isms-request@lists.ietf.org
Chairs:
Juergen Quittek
NEC Europe Ltd.
Network Laboratories
Kurfuersten-Anlage 36
69115 Heidelberg
Germany
+49 6221 90511-15
quittek@netlab.nec.de
Harrington & Salowey Expires April 14, 2007 [Page 21]
Internet-Draft Secure Shell Transport Model for SNMP October 2006
Juergen Schoenwaelder
International University Bremen
Campus Ring 1
28725 Bremen
Germany
+49 421 200-3587
j.schoenwaelder@iu-bremen.de
Co-editors:
David Harrington
Huawei Technologies USA
1700 Alma Drive
Plano Texas 75075
USA
+1 603-436-8634
ietfdbh@comcast.net
Joseph Salowey
Cisco Systems
2901 3rd Ave
Seattle, WA 98121
USA
jsalowey@cisco.com
"
DESCRIPTION "The Secure Shell Transport Model MIB
Copyright (C) The Internet Society (2006). This
version of this MIB module is part of RFC XXXX;
see the RFC itself for full legal notices.
-- NOTE to RFC editor: replace XXXX with actual RFC number
-- for this document and remove this note
"
REVISION "200610050000Z" -- 02 September 2005
DESCRIPTION "The initial version, published in RFC XXXX.
-- NOTE to RFC editor: replace XXXX with actual RFC number
-- for this document and remove this note
"
::= { mib-2 xxxx }
-- RFC Ed.: replace xxxx with IANA-assigned number and
-- remove this note
-- ---------------------------------------------------------- --
-- subtrees in the SSHTM-MIB
-- ---------------------------------------------------------- --
sshtmNotifications OBJECT IDENTIFIER ::= { sshtmMIB 0 }
Harrington & Salowey Expires April 14, 2007 [Page 22]
Internet-Draft Secure Shell Transport Model for SNMP October 2006
sshtmMIBObjects OBJECT IDENTIFIER ::= { sshtmMIB 1 }
sshtmConformance OBJECT IDENTIFIER ::= { sshtmMIB 2 }
-- -------------------------------------------------------------
-- Objects
-- -------------------------------------------------------------
TransportAddressSSH ::= TEXTUAL-CONVENTION
DISPLAY-HINT "1a"
STATUS current
DESCRIPTION
"Represents either a hostname encoded in ASCII
using the IDNA protocol, as specified in RFC3490, followed by
a colon ':' (ASCII character 0x3A) and a decimal port number
in ASCII, or an IP address followed by a colon ':'
(ASCII character 0x3A) and a decimal port number in ASCII.
The name SHOULD be fully qualified whenever possible.
Values of this textual convention are not directly useable
as transport-layer addressing information, and require
runtime resolution. As such, applications that write them
must be prepared for handling errors if such values are
not supported, or cannot be resolved (if resolution occurs
at the time of the management operation).
The DESCRIPTION clause of TransportAddress objects that may
have TransportAddressSSH values must fully describe how (and
when) such names are to be resolved to IP addresses and vice
versa.
This textual convention SHOULD NOT be used directly in
object definitions since it restricts addresses to a
specific format. However, if it is used, it MAY be used
either on its own or in conjunction with
TransportAddressType or TransportDomain as a pair.
When this textual convention is used as a syntax of an
index object, there may be issues with the limit of 128
sub-identifiers specified in SMIv2, STD 58. In this case,
the OBJECT-TYPE declaration MUST include a 'SIZE' clause
to limit the number of potential instance sub-identifiers."
SYNTAX OCTET STRING (SIZE (1..255))
transportDomainSSH OBJECT-IDENTITY
STATUS current
DESCRIPTION
"The SSH transport domain. The corresponding transport
Harrington & Salowey Expires April 14, 2007 [Page 23]
Internet-Draft Secure Shell Transport Model for SNMP October 2006
address is of type TransportAddressSSH.
When an SNMP entity uses the transportDomainSSH transport
model, it must be capable of accepting messages up to
and including 8192 octets in size. Implementation of
larger values is encouraged whenever possible."
::= { snmpDomains yy }
-- RFC Ed.: replace yy with IANA-assigned number and
-- remove this note
-- The sshtmSession Group
sshtmSession OBJECT IDENTIFIER ::= { sshtmMIBObjects 1 }
sshtmSessionCurrent OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The current number of open sessions.
"
::= { sshtmSession 1 }
sshtmSessionMaxSupported OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The maximum number of open sessions supported.
The value zero indicates the maximum is dynamic.
"
::= { sshtmSession 2 }
sshtmSessionOpenErrors OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The number of times an openSession() request
failed to open a Session.
"
::= { sshtmSession 3 }
sshtmSessionSecurityLevelNotAvailableErrors OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The number of times an outgoing message was
discarded because a requested securityLevel could not
provided.
Harrington & Salowey Expires April 14, 2007 [Page 24]
Internet-Draft Secure Shell Transport Model for SNMP October 2006
"
::= { sshtmSession 4 }
sshtmSessionNoAvailableSessions OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The number of times a Response message
was dropped because the corresponding
session was no longer available.
"
::= { sshtmSession 5 }
-- The sshtmUser Group ********************************************
sshtmUser OBJECT IDENTIFIER ::= { sshtmMIBObjects 2 }
sshtmUserSpinLock OBJECT-TYPE
SYNTAX TestAndIncr
MAX-ACCESS read-write
STATUS current
DESCRIPTION "An advisory lock used to allow several cooperating
Command Generator Applications to coordinate their
use of facilities to alter the sshtmUserTable.
"
::= { sshtmUser 1 }
-- The table of valid users for the SSH Transport Model ********
sshtmUserTable OBJECT-TYPE
SYNTAX SEQUENCE OF SshtmUserEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "The table of users configured in the SNMP engine's
Local Configuration Datastore (LCD).
Most configuration of this table is expected to be
done by an agent dynamically. It is possible for an
SNMP management application to pre-configure the
table with static information useful for translating
from an SSH-specific user to a model-independent
securityName, or for statically configuring the only
entities authorized to receive notifications.
To create a new user (i.e., to instantiate a new
conceptual row in this table), it is recommended to
follow this procedure:
Harrington & Salowey Expires April 14, 2007 [Page 25]
Internet-Draft Secure Shell Transport Model for SNMP October 2006
1) GET(sshtmUserSpinLock.0) and save in sValue.
2) SET(sshtmUserSpinLock.0=sValue,
sshtmUserStatus=createAndWait)
3) configure the entry
4) SET(sshtmUserStatus=active)
The new user should now be available and ready to be
used for SNMPv3 communication.
The use of sshtmUserSpinlock is to avoid conflicts
with another SNMP command generator application which
may also be acting on the sshtmUserTable.
"
::= { sshtmUser 2 }
sshtmUserEntry OBJECT-TYPE
SYNTAX SshtmUserEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "A user configured in the SNMP engine's Local
Configuration Datastore (LCD) for the SSH
Transport Model.
"
INDEX { sshtmUserAddress,
sshtmUserName
}
::= { sshtmUserTable 1 }
SshtmUserEntry ::= SEQUENCE
{
sshtmUserAddress TransportAddressSSH,
sshtmUserSecurityName SnmpAdminString,
sshtmUserName SnmpAdminString,
sshtmUserStorageType StorageType,
sshtmUserStatus RowStatus
}
sshtmUserAddress OBJECT-TYPE
SYNTAX TransportAddressSSH
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "A remote SNMP engine's SSH address.
"
::= { sshtmUserEntry 1 }
sshtmUserSecurityName OBJECT-TYPE
SYNTAX SnmpAdminString
Harrington & Salowey Expires April 14, 2007 [Page 26]
Internet-Draft Secure Shell Transport Model for SNMP October 2006
MAX-ACCESS read-only
STATUS current
DESCRIPTION "A human readable string representing the user in
Transport Model independent format.
The default transformation of the sshtmUserName to
the sshtmUserSecurityName and vice versa is the
identity function so that the sshtmUserSecurityName
is usually the same as the sshtmUserName.
"
::= { sshtmUserEntry 2 }
sshtmUserName OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE(1..32))
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "This is the user name used in the
SSH_MSG_USERAUTH_REQUEST to authenticate the client.
"
::= { sshtmUserEntry 3 }
sshtmUserStorageType OBJECT-TYPE
SYNTAX StorageType
MAX-ACCESS read-create
STATUS current
DESCRIPTION "The storage type for this conceptual row.
It is an implementation issue to decide if a SET for
a readOnly or permanent row is accepted at all. In some
contexts this may make sense, in others it may not. If
a SET for a readOnly or permanent row is not accepted
at all, then a 'wrongValue' error must be returned.
"
DEFVAL { nonVolatile }
::= { sshtmUserEntry 4 }
sshtmUserStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION "The status of this conceptual row.
Until instances of all corresponding columns are
appropriately configured, the value of the
corresponding instance of the sshtmUserStatus column
is 'notReady'.
The value of this object has no effect on whether
Harrington & Salowey Expires April 14, 2007 [Page 27]
Internet-Draft Secure Shell Transport Model for SNMP October 2006
other objects in this conceptual row can be modified.
"
::= { sshtmUserEntry 5 }
-- ************************************************
-- sshtmMIB - Conformance Information
-- ************************************************
sshtmGroups OBJECT IDENTIFIER ::= { sshtmConformance 1 }
sshtmCompliances OBJECT IDENTIFIER ::= { sshtmConformance 2 }
-- ************************************************
-- Units of conformance
-- ************************************************
sshtmGroup OBJECT-GROUP
OBJECTS {
sshtmUserSpinLock,
sshtmUserSecurityName,
sshtmUserStorageType,
sshtmUserStatus
}
STATUS current
DESCRIPTION "A collection of objects for maintaining
information of an SNMP engine which implements the
SNMP Secure Shell Transport Model.
"
::= { sshtmGroups 2 }
-- ************************************************
-- Compliance statements
-- ************************************************
sshtmCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for SNMP engines that support the
SSHTM-MIB"
MODULE
MANDATORY-GROUPS { sshtmGroup }
::= { sshtmCompliances 1 }
END
Harrington & Salowey Expires April 14, 2007 [Page 28]
Internet-Draft Secure Shell Transport Model for SNMP October 2006
8. Security Considerations
This document describes a 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.
8.1. noAuthPriv
SSH provides the "none" userauth method, which is normally rejected
by servers and used only to find out what userauth methods are
supported. However, it is legal for a server to accept this method,
which has the effect of not authenticating the SSH client to the SSH
server. Doing this does not compromise authentication of the SSH
server to the SSH client, nor does it compromise data confidentiality
or data integrity.
SSH supports anonymous access. If the SSH Transport Model can
extract from SSH an authenticated principal to map to securityName,
then anonymous access SHOULD be supported. It is possible for SSH to
skip entity authentication of the client through the "none"
authentication method to support anonymous clients, however in this
case an implementation MUST still support data integrity within the
SSH transport protocol and provide an authenticated principal for
mapping to securityName for access control purposes.
The RFC 3411 architecture does not permit noAuthPriv. The SSH
Transport Model SHOULD NOT be used with an SSH connection with the
"none" userauth method.
Harrington & Salowey Expires April 14, 2007 [Page 29]
Internet-Draft Secure Shell Transport Model for SNMP October 2006
[discuss: are we being inconsistent? ]
8.2. skipping public key verification
Most key exchange algorithms are able to authenticate the SSH
server's identity to the client. However, for the common case of DH
signed by public keys, this requires the client to know the host's
public key a priori and to verify that the correct key is being used.
If this step is skipped, then authentication of the SSH server to the
SSH client is not done. Data confidentiality and data integrity
protection to the server still exist, but these are of dubious value
when an attacker can insert himself between the client and the real
SSH server. Note that some userauth methods may defend against this
situation, but many of the common ones (including password and
keyboard-interactive) do not, and in fact depend on the fact that the
server's identity has been verified (so passwords are not disclosed
to an attacker).
SSH MUST NOT be configured to skip public key verification for use
with the SSH Transport Model.
8.3. the 'none' MAC algorithm
SSH provides the "none" MAC algorithm, which would allow you to turn
off data integrity while maintaining confidentiality. However, if
you do this, then an attacker may be able to modify the data in
flight, which means you effectively have no authentication.
SSH MUST NOT be configured using the "none" MAC algorithm for use
with the SSH Transport Model.
8.4. MIB module security
There are a number of management objects defined in this MIB module
with a MAX-ACCESS clause of read-write and/or read-create. Such
objects may be considered sensitive or vulnerable in some network
environments. The support for SET operations in a non-secure
environment without proper protection can have a negative effect on
network operations. These are the tables and objects and their
sensitivity/vulnerability:
o [todo]
There are no management objects defined in this MIB module that have
a MAX-ACCESS clause of read-write and/or read-create. So, if this
MIB module is implemented correctly, then there is no risk that an
intruder can alter or create any management objects of this MIB
module via direct SNMP SET operations.
Harrington & Salowey Expires April 14, 2007 [Page 30]
Internet-Draft Secure Shell Transport Model for SNMP October 2006
Some of the readable objects in this MIB module (i.e., objects with a
MAX-ACCESS other than not-accessible) may be considered sensitive or
vulnerable in some network environments. It is thus important to
control even GET and/or NOTIFY access to these objects and possibly
to even encrypt the values of these objects when sending them over
the network via SNMP. These are the tables and objects and their
sensitivity/vulnerability:
o [todo]
SNMP versions prior to SNMPv3 did not include adequate security.
Even if the network itself is secure (for example by using IPSec or
SSH), even then, there is no control as to who on the secure network
is allowed to access and GET/SET (read/change/create/delete) the
objects in this MIB module.
It is RECOMMENDED that implementers consider the security features as
provided by the SNMPv3 framework (see [RFC3410] section 8), including
full support for the USM and the SSH Transport Model cryptographic
mechanisms (for authentication and privacy).
Further, deployment of SNMP versions prior to SNMPv3 is NOT
RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to
enable cryptographic security. It is then a customer/operator
responsibility to ensure that the SNMP entity giving access to an
instance of this MIB module is properly configured to give access to
the objects only to those principals (users) that have legitimate
rights to indeed GET or SET (change/create/delete) them.
9. IANA Considerations
IANA is requested to assign:
1. a TCP port number in the range 1..1023 in the
http://www.iana.org/assignments/port-numbers registry which will
be the default port for SNMP over an SSH Transport Model as
defined in this document,
2. an SMI number under mib-2, for the MIB module in this document,
3. the creation of a registry for SNMP Transport Models
4. an SnmpTransportModel for the Secure Shell Transport Model, in
the Simple Network Management Protocol (SNMP) Number Spaces. The
SnmpTransportModel registry is defined in [I-D.ietf-isms-tmsm]
5. "snmp" as an SSH Service Name in the
http://www.iana.org/assignments/ssh-parameters registry.
10. Acknowledgements
The editors would like to thank Jeffrey Hutzelman for sharing his SSH
insights.
Harrington & Salowey Expires April 14, 2007 [Page 31]
Internet-Draft Secure Shell Transport Model for SNMP October 2006
11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to
Indicate Requirement Levels", BCP 14, RFC 2119,
March 1997.
[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J.
Schoenwaelder, Ed., "Structure of Management
Information Version 2 (SMIv2)", STD 58,
RFC 2578, April 1999.
[RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J.
Schoenwaelder, Ed., "Textual Conventions for
SMIv2", STD 58, RFC 2579, April 1999.
[RFC2580] McCloghrie, K., Perkins, D., and J.
Schoenwaelder, "Conformance Statements for
SMIv2", STD 58, RFC 2580, April 1999.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W.
Simpson, "Remote Authentication Dial In User
Service (RADIUS)", RFC 2865, June 2000.
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An
Architecture for Describing Simple Network
Management Protocol (SNMP) Management
Frameworks", STD 62, RFC 3411, December 2002.
[RFC3412] Case, J., Harrington, D., Presuhn, R., and B.
Wijnen, "Message Processing and Dispatching for
the Simple Network Management Protocol (SNMP)",
STD 62, RFC 3412, December 2002.
[RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple
Network Management Protocol (SNMP)
Applications", STD 62, RFC 3413, December 2002.
[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.
Harrington & Salowey Expires April 14, 2007 [Page 32]
Internet-Draft Secure Shell Transport Model for SNMP October 2006
[RFC3419] Daniele, M. and J. Schoenwaelder, "Textual
Conventions for Transport Addresses", RFC 3419,
December 2002.
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
"Internationalizing Domain Names in
Applications (IDNA)", RFC 3490, March 2003.
[RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell
(SSH) Protocol Architecture", RFC 4251,
January 2006.
[RFC4252] Ylonen, T. and C. Lonvick, "The Secure Shell
(SSH) Authentication Protocol", RFC 4252,
January 2006.
[RFC4253] Ylonen, T. and C. Lonvick, "The Secure Shell
(SSH) Transport Layer Protocol", RFC 4253,
January 2006.
[RFC4254] Ylonen, T. and C. Lonvick, "The Secure Shell
(SSH) Connection Protocol", RFC 4254,
January 2006.
[I-D.ietf-isms-tmsm] Harrington, D. and J. Schoenwaelder, "Transport
Mapping Security Model (TMSM) Architectural
Extension for the Simple Network Management
Protocol (SNMP)", draft-ietf-isms-tmsm-03 (work
in progress), June 2006.
11.2. Informative References
[RFC1994] Simpson, W., "PPP Challenge Handshake
Authentication Protocol (CHAP)", RFC 1994,
August 1996.
[RFC3410] Case, J., Mundy, R., Partain, D., and B.
Stewart, "Introduction and Applicability
Statements for Internet-Standard Management
Framework", RFC 3410, December 2002.
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn,
G., and J. Arkko, "Diameter Base Protocol",
RFC 3588, September 2003.
[RFC4462] Hutzelman, J., Salowey, J., Galbraith, J.,
and V. Welch, "Generic Security Service
Application Program Interface (GSS-API)
Harrington & Salowey Expires April 14, 2007 [Page 33]
Internet-Draft Secure Shell Transport Model for SNMP October 2006
Authentication and Key Exchange for the
Secure Shell (SSH) Protocol", RFC 4462,
May 2006.
[I-D.ietf-netconf-ssh] Wasserman, M. and T. Goddard, "Using the
NETCONF Configuration Protocol over Secure
Shell (SSH)", draft-ietf-netconf-ssh-06 (work
in progress), March 2006.
Appendix A. Open Issues
We need to reach consensus on some issues.
Here is the current list of issues from the SSH Transport Model
document where we need to reach consensus.
o The MIB module needs to be defined.
o Consistency with TMS needs to be done (TMS needs some changes due
to changes in the SSH Transport Model)
o SSH transport domain and transport address definitions -
consistency across WGs
o configuring notification originators
Appendix B. Change Log
From -04- to -05
added sshtmUserTable
moved session tabel into the transport model MIB from the
transport subsystem MIB
added and then removed Appendix A - Notification Tables
Configuration (see Transport Security Model)
made this document a specification of a transport model, rather
than a security model in two parts. Eliminated TMSP and MPSP and
replaced them with "transport model" and "security model".
Removed security-model-specific processing from this document.
Removed discussion of snmpv3/v1/v2c message format co-existence
changed tmSessionRefernce back to tmStateReference
"From -03- to -04-"
changed tmStateReference to tmSessionReference
"From -02- to -03-"
Harrington & Salowey Expires April 14, 2007 [Page 34]
Internet-Draft Secure Shell Transport Model for SNMP October 2006
rewrote almost all sections
merged ASI section and Elements of Procedure sections
removed references to the SSH user, in preference to SSH client
updated references
creayted a conventions section to identify common terminology.
rewrote sections on how SSH addresses threats
rewrote mapping SSH to engineID
eliminated discovery section
detailed the Elements of Procedure
eliminated secrtions on msgFlags, transport parameters
resolved issues of opening notifications
eliminated sessionID (TMSM needs to be updated to match)
eliminated use of tmsSessiontable except as an example
updated Security Considerations
"From -01- to -02-"
Added TransportDomainSSH and Address
Removed implementation considerations
Changed all "user auth" to "client auth"
Removed unnecessary MIB module objects
updated references
improved consistency of references to TMSM as architectural
extension
updated conventions
updated threats to be more consistent with RFC3552
discussion of specific SSH mechanism configurations moved to
security considerations
modified session discussions to reference TMSM sessions
expanded discussion of engineIDs
wrote text to clarify the roles of MPSP and TMSP
clarified how snmpv3 message parts are ised by SSHSM
modified nesting of subsections as needed
securityLevel used by the SSH Transport Model always equals
authpriv
removed discussion of using SSHSM with SNMPv1/v2c
started updating Elements of Procedure, but realized missing info
needs discussion.
updated MIB module relationship to other MIB modules
"From -00- to -01-"
-00- initial draft as ISMS work product:
updated references to SecSH RFCs
Modified text related to issues# 1, 2, 8, 11, 13, 14, 16, 18, 19,
20, 29, 30, and 32.
updated security considerations
removed Juergen Schoenwaelder from authors, at his request
Harrington & Salowey Expires April 14, 2007 [Page 35]
Internet-Draft Secure Shell Transport Model for SNMP October 2006
ran the mib module through smilint
Authors' Addresses
David Harrington
Huawei Technologies (USA)
1700 Alma Dr. Suite 100
Plano, TX 75075
USA
Phone: +1 603 436 8634
EMail: dharrington@huawei.com
Joseph Salowey
Cisco Systems
2901 3rd Ave
Seattle, WA 98121
USA
EMail: jsalowey@cisco.com
Harrington & Salowey Expires April 14, 2007 [Page 36]
Internet-Draft Secure Shell Transport Model for SNMP October 2006
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Harrington & Salowey Expires April 14, 2007 [Page 37]
