WDIFF

draft-ietf-isms-secshell-02.txt --> draft-ietf-isms-secshell-03.txt

Network Working Group D. Harrington
Internet-Draft Futurewei Huawei Technologies (USA)
Expires: September 5, December 10, 2006 J. Salowey
Cisco Systems
March 4,
June 8, 2006

Secure Shell Security Model for SNMP
draft-ietf-isms-secshell-02.txt
draft-ietf-isms-secshell-03.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 September 5, December 10, 2006.

Abstract

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

Harrington & Salowey Expires September 5, December 10, 2006 [Page 1]

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

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. The Internet-Standard Management Framework . . . . . . . . 4
1.2. Modularity . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4. The Secure Shell Protocol Conventions . . . . . . . . . . . . . . . . 6
1.5. Constraints . . . . . . . 6
1.5. The Secure Shell Protocol . . . . . . . . . . . . . . . . 7
1.6. Conventions Constraints . . . . . . . . . . . . . . . . . . . . . . . 7
2. How SSHSM Fits into the TMSM Architecture . . . . . . . . . . 8
2.1. Security Capabilities of this Model . . . . . . . . . . . 8 9
2.1.1. Threats . . . . . . . . . . . . . . . . . . . . . . . 8 9
2.1.2. SSHSM Sessions . . . . . . . . . . . . . . . . . . . . 11
2.1.3. Authentication Protocol . . . . . . . . . . . . . . . 12 11
2.1.4. Privacy Protocol . . . . . . . . . . . . . . . . . . . 13 12
2.1.5. Protection against Message Replay, Delay and
Redirection . . . . . . . . . . . . . . . . . . . . . 13 12
2.1.6. Security Protocol Requirements . . . . . . . . . . . . 13 12
2.2. Security Parameter Passing Requirement . . . . . . . . . . 15
2.3. Requirements for Notifications . . . . . . 13
2.3. Notifications and Proxy . . . . . . . . 15
3. RFC 3411 Abstract Service Interfaces . . . . . . . . . 14
3. Message Formats . . . . 16
3.1. Public Abstract Service Interfaces . . . . . . . . . . . . 16
3.1.1. Public ASIs for Outgoing Messages . . . . . . . 15
3.1. SNMPv3 Message Fields . . . 16
3.1.2. Public ASIs for Incoming Messages . . . . . . . . . . 18
3.2. SNMP Messages Using this Security Model . . . . . 15
3.1.1. msgGlobalData . . . . 20
3.2.1. SNMPv1 and SNMPv2c Messages Using this Security
Model . . . . . . . . . . . . . . . . 17
3.1.2. msgSecurityParameters . . . . . . . . 20
3.2.2. SNMPv3 Messages Using this Security Model . . . . . . 20
3.2.3. . . 17
3.2. Passing Security Parameters . . . . . . . . . . . . . 23
3.2.4. MIB Module for SSH Security Model . . 17
3.2.1. tmStateReference . . . . . . . . 25
3.2.5. [todo] Notifications . . . . . . . . . . . 17
3.2.2. securityStateReference . . . . . . 26
3.3. Elements of Procedure . . . . . . . . . . 18
4. Elements of Procedure . . . . . . . . 26
3.3.1. Establishing a Session . . . . . . . . . . . . 19
4.1. Generating an Outgoing SNMP Message . . . . 26
3.3.2. Closing a Session . . . . . . . 19
4.2. MPSP for an Outgoing Message . . . . . . . . . . . 29
3.3.3. Discovery . . . . 20
4.2.1. MPSP Procedures . . . . . . . . . . . . . . . . . . 29
3.3.4. Generating . 22
4.3. TMSP for an Outgoing SNMP Message . . . . . . . . . 30
3.3.5. Sending an Outgoing SNMP Message to the Network . . . 32
3.3.6. [todo] Prepare Data Elements from an Incoming SNMP
Message . . . . 23
4.3.1. TMSP Procedures . . . . . . . . . . . . . . . . . . . 33
3.3.7. 23
4.4. Processing an Incoming SNMP Message . . . . . . . . . 33
3.4. Overview . . 24
4.4.1. TMSP for an Incoming Message . . . . . . . . . . . . . 24
4.5. Prepare Data Elements from Incoming Messages . . . . . . . 25
4.6. MPSP for an Incoming Message . . . . . . . . 35
3.5. Structure of the MIB Module . . . . . . . 25
4.7. Establishing a Session . . . . . . . . 35
3.5.1. Textual Conventions . . . . . . . . . . 27
4.8. Closing a Session . . . . . . . 36
3.5.2. The sshsmStats Subtree . . . . . . . . . . . . . 29
5. Overview . . . 36
3.5.3. The sshsmsSession Subtree . . . . . . . . . . . . . . 36
3.5.4. Relationship to Other MIB Modules . . . . . . . . . . 36
3.6. 29
5.1. Structure of the MIB module definition Module . . . . . . . . . . . . . . . 30
5.2. Textual Conventions . . . 37
3.7. Implementation Considerations . . . . . . . . . . . . . . 45

Harrington & Salowey Expires September 5, . . 30
5.3. The sshsmStats Subtree . . . . . . . . . . . . . . . . . . 30
5.4. The sshsmsSession Subtree . . . . . . . . . . . . . . . . 30
5.5. Relationship to Other MIB Modules . . . . . . . . . . . . 30
5.5.1. Relationship to the SNMPv2-MIB . . . . . . . . . . . . 30
5.5.2. Relationship to the SNMP-FRAMEWORK-MIB . . . . . . . . 30
5.5.3. Relationship to the TMSM-MIB . . . . . . . . . . . . . 31

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

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

3.8.

5.5.4. MIB Modules Required for IMPORTS . . . . . . . . . . . 31
6. MIB module definition . . . . . . . . . . . . . . . . . . . . 31
7. Security Considerations . . . . . . . . . . . . . . . . . 45
3.9. IANA Considerations . . 35
7.1. noAuthPriv . . . . . . . . . . . . . . . . . 47
3.10. Acknowledgements . . . . . . . 35
7.2. skipping public key verification . . . . . . . . . . . . . 36
7.3. the 'none' MAC algorithm . 47
4. References . . . . . . . . . . . . . . . . 36
7.4. MIB module security . . . . . . . . . . 47
4.1. Normative References . . . . . . . . . 37
8. IANA Considerations . . . . . . . . . . 47
4.2. Informative References . . . . . . . . . . . 38
9. Acknowledgements . . . . . . . 48
Appendix A. Open Issues . . . . . . . . . . . . . . . . 38
10. References . . . . . 49
A.1. Issues with Resolutions nearing Consensus . . . . . . . . 51
A.2. Closed Issues . . . . . . . . . . . . . 38
10.1. Normative References . . . . . . . . . . . . . . . . . . . 38
10.2. Informative References . . . . . . . . . . . . . . . . . 51 . 40
Appendix B. Change Log A. Open Issues . . . . . . . . . . . . . . . . . . . . . 53
Authors' Addresses 40
A.1. Closed Issues . . . . . . . . . . . . . . . . . . . . . . 40
Appendix B. Change Log . . 53
Intellectual Property and Copyright Statements . . . . . . . . . . 53

Harrington & Salowey . . . . . . . . . 45
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 46
Intellectual Property and Copyright Statements . . . . . . . . . . 46

Harrington & Salowey Expires September 5, December 10, 2006 [Page 3]

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

1. Introduction

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

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

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

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

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

Harrington & Salowey Expires September 5, December 10, 2006 [Page 4]

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

In keeping with the RFC 3411 design decisions to use self-contained
documents, this memo includes the elements of procedure plus
associated MIB objects which are needed for processing the Secure
Shell Security Model for SNMP. These MIB objects SHOULD not be
referenced in other documents. This allows the Secure Shell Security
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.3. Motivation

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

This memo describes a security model that will make use of the
existing and commonly deployed Secure Shell security infrastructure.
It is designed to meet the security and operational needs of network
administrators, maximize useability 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 (the user), client, and how SNMP can make use of the authenticated identities
in message authentication and auditing. . access control.

The work will include the ability to use any of the user 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]. It should SSHSM SHOULD be able to take
advantage of other defined authentication mechanism such as those

Harrington & Salowey Expires September 5, December 10, 2006 [Page 5]

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

defined in [I-D.ietf-secsh-gsskeyex] [RFC4462] and future mechanism mechanisms such as those that make
use of X.509 certificate credentials. This will allow SSHSM to
utilize user 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 intrfaces 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-prot]. Similar to NETCONF over SSH [I-D.ietf-netconf-ssh],
this
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 defines describes how SNMP can be used within a Secure Shell (SSH)
session, using the SSH connection protocol [RFC4254] over the SSH
transport protocol [RFC4253], protocol, using SSH user-auth [RFC4252]for [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. Sections requiring further editing

1.4. Conventions

The terms "manager" and "agent" are identified by
[todo] markers not used in this document,
because in the text. Points requiring further WG research and
discussion are identified by [discuss] markers 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 text.

1.4. The Secure Shell Protocol

SSH engine. Where distinction is a protocol
required, the application names of Command Generator, Command
Responder, Notification Generator, Notification Responder, and Proxy
Forwarder are used. See "SNMP Applications" [RFC3413] for secure remote login further
information.

Throughout this document, the terms "client" and other secure network
services over an insecure network. It consists "server" are used to
refer to the two ends of three major
components:
o the SSH transport connection. The Transport Layer Protocol [[RFC4253] provides server
authentication, confidentiality, and integrity. 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.

While SSH and USM frequently refer to a user, the terminology used in
RFC3411 [RFC3411] and in this memo is "principal". A principal is
the "who" on whose behalf services are provided or processing takes
place. A principal can be, among other things, an individual acting
in a particular role; a set of individuals, with each acting in a
particular role; an application or a set of applications; and
combinations thereof.

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

Internet-Draft Secure Shell Security Model for SNMP June 2006

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.5. 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 user 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
succesfully
successfully authenticating the user. principal.

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

Harrington & Salowey Expires September 5, 2006 [Page 6]

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

1.5.

1.6. Constraints

The design of this SNMP Security Model is also influenced by the
following constraints:
1. When the requirements of effective management in times of network
stress are inconsistent with those of security, the design of
this model gives preference to the former. effective management.
2. In times of network stress, the security 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).

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

Internet-Draft Secure Shell Security Model for SNMP June 2006

3. When the network is not under stress, the security model and its
underlying security mechanisms MAY depend upon the ready
availability of other network services.
4. It may not be possible for the security model to determine when
the network is under stress.
5. A security mechanism model should entail require no changes to the basic SNMP
network management philosophy.

1.6. Conventions

The terms "manager" and "agent" are not used in this document,
because in the RFC 3411 architecture, all SNMP entities have the
capability of acting as either manager or agent or both depending on
the SNMP applications included in the engine. Where distinction is
required, the application names of Command Generator, Command
Responder, Notification Generator, Notification Responder, and Proxy
Forwarder are used. See "SNMP Applications" [RFC3413] for further
information.

Throughout this document, the terms "client" and "server" are used to
refer
architecture.
6. A security model should require no changes 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 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].

Harrington & Salowey Expires September 5, 2006 [Page 7]

Internet-Draft Secure Shell Security Model for SNMP March 2006 underlying
security protocol.

2. How SSHSM Fits into the TMSM Architecture

SSH is a security layer which is plugged into the TMSM architecture
extension between the underlying transport layer and the message dispatcher.
dispatcher [RFC3411].

The SSHSM model will establish an encrypted tunnel between the
transport mappings of two SNMP engines. The sending transport
mapping security model instance encrypts outgoing messages, and the
receiving transport mapping security model instance decrypts the
messages.

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

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

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

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

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

Internet-Draft Secure Shell Security Model for SNMP June 2006

2.1. Security Capabilities of this Model

2.1.1. Threats

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

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

Harrington & Salowey Expires September 5, 2006 [Page 8]

Internet-Draft Secure Shell Security Model for SNMP March 2006

1. Message stream modification - Provide SSHSM provides for verification
that each received SNMP message has not been modified during its
transmission through the network. .
2. Information modification - Provide SSHSM provides for verification that
the contents of each received SNMP message has not been modified
during its transmission through the network. Data 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
maliciously.
3. Masquerade - Provide SSHSM provides for both verification of the identity
of the
user on whose behalf a received SNMP message claims to have been
generated, and the SSH server and verification of the identity of the MIB owner.
For SSH
client - the protocols specified in this memo, it principal on whose behalf a received SNMP message
claims to have been generated. It is not possible to assure the
specific user principal that originated a received SNMP message;
rather, it is the user principal on whose behalf the message was
originated that is authenticated. SSH provides verification of
the identity of the MIB owner SSH server through the SSH Transport Protocol
server authentication [RFC4253]
4. Verification of user principal identity is important for use with the
SNMP access control subsystem, to ensure that only authorized users
principals have access to potentially sensitive data. The SSH
user identity will be used to map to an SNMP model-independent securityname
securityName for use with SNMP access control.
5. Authenticating both the SSH server and the SSH client ensures the
authenticity of the SSH
server that is associated with the SNMP engine that provides MIB
data. data, whether
that engine resides on the server or client side of the
association. Operators or management applications could might act upon
the data they receive (e.g. (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. SSH allows for authentication
of the SSH server using the SSH public key credentials described
in [RFC4253] and mechanisms such as those described in [I-D.ietf-
secsh-gsskeyex].
6. Disclosure - Provide, when necessary, SSHSM provides that the contents of each received
SNMP message are protected from disclosure to unauthorized
persons.

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

Internet-Draft Secure Shell Security Model for SNMP June 2006

7. Replay - Provide for detection of received SNMP messages, which
request or contain management information, whose time of
generation was not recent. A message whose generation time is
outside of a time window is not accepted. Note SSH ensures that message
reordering is not dealt with cryptographic keys established at the
beginning of the SSH session and can occur stored in normal conditions 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.

2.1.1.1. Data Origin Authentication Issues

The RFC 3411 architecture recognizes three levels of security:

Harrington & Salowey Expires September 5, 2006 [Page 9]

Internet-Draft Secure Shell Security Model for SNMP March 2006
- without authentication and without privacy (noAuthNoPriv)
- with authentication but without privacy (authNoPriv)
- with authentication and with privacy (authPriv)

SSH

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

SSHSM extracts from SSH connection
SHOULD provide authPriv, which is the highest level identity of security
defined in RFC 3411. It is possible for SSH to skip entity
authenticaiton 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.
The security protocols used in [RFC4253] are considered acceptably
secure at the time of writing. However, the procedures allow for new
authentication authenticated principal,
and privacy methods to be specified at a future time
if the need arises.

Implementations SHOULD support whatever authentications are provided
by SSH. This includes anonymous access; if SSH supports anonymous
access, type and address associated with an incoming message, and
SSHSM can extract a username, then anonymous access
SHOULD be supported.

The authNoPriv security level may be important provides this information to accommodate
governmental regulation (e.g. export laws) regarding encryption
technologies. SSH for an outgoing message. The
transport layer algorithms used to provide authentication, data
integrity and encryption SHOULD NOT be exposed to the SSHSM layer.
In SNMP, SNMPv3, we deliberately avoided this, this and settled for an assertion,
using msgFlags, that auth and priv were applied according to the
rules of the security model. However, there should probably be SSHSM has no mechanisms by
which it can test whether an SSH-MIB, underlying SSH connection provides auth
or priv to meet a desired msgFlags setting, so the algorithms used
to achieve SSHSM trusts that
the security level should be accessible underlying SSH connection has been properly configured to authorized
administrators via a management interface. support
security characteristics at least as strong as requested in msgFlags.

SSH should provide the identity of does not understand msgFlags, and SSHSM does not know about the authenticated principal. From
this information it should be possible
algorithms or options for the SNMP subsystem to
determine if the SSH session is allowed access to open SSH sessions that
match different securityLevels. For interoperability of the subsystem.

2.1.1.1.1. noAuthPriv trust
assumptions between SNMP engines, an SSHSM-compliant implementation
MUST use an SSH connection that provides the "none" userauth method, which is normally rejected
by servers authentication, data
integrity and used only to find out what userauth methods are
supported. However, it is legal for a server to accept this method,
which has encryption that meets the effect highest level of not authenticating SNMP
security (authPriv). Outgoing messages requested by SNMP
applications and specified with a lesser securityLevel (noAuthNoPriv
or authNoPriv) are sent by SSHSM as authPriv securityLevel. Other
security models, where the ssh client actual securityLevel applied to the ssh
server. Doing this does not compromise authentication
connection can be determined or controlled, can be used when a lesser
level of security is desired.

Implementations SHOULD support whatever authentications are provided
by SSH. The security protocols used in [RFC4253] are considered
acceptably secure at the ssh
server to time of writing. However, the ssh client, nor does it compromise data confidentiality procedures

Harrington & Salowey Expires September 5, December 10, 2006 [Page 10]

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

or data integrity.

The RFC 3411 architecture does not permit noAuthPriv. SSHSM should
refuse a noAuthPriv session.

2.1.1.1.2. skipping public key verification

Most key exchange algorithms are able to authenticate the SSH
server's identity to the client. However,

allow for the common case of DH
signed by public keys, this requires the client new authentication and privacy methods to know be specified at a
future time if the host's
public key need arises.

2.1.2. SSHSM Sessions

The Secure Shell security model will utilize TMSM sessions, with a priori
single combination of transportAddress, engineID, securityName,
securityModel, and to verify that the correct key securityLevel associated with each session. A
TMSM session is being used.
If this step associated with state information that is skipped, then authentication of the ssh server to maintained
for its lifetime. All SSHSM sessions will utilize 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).

2.1.1.1.3. the 'none' MAC algorithm

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

SSH must not be configured using the "none" MAC algorithm for use
with the SSHSM security model.

2.1.2. SSHSM Sessions

The Secure Shell security model will utilize sessions, with a single
user and security level associated with each session. All SSHSM
sessions will utilize authPriv securityLevels,
securityLevel, and all SNMP incoming SSHSM messages will be authenticated treated as
having been delivered through authenticated, integrity-checked, and encrypted.
encrypted connections.

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

[todo] Say more about how sessions are initiated, how

2.1.2.1. Message security versus session state
is made visible security

As part of session creation, the client and so on.

An SSHSM server entities are
authenticated and authorized access to the session. In addition, as
part of session establishment, cryptographic key material is associated with state information that
exchanged and is
maintained for its lifetime. SSH ensures that cryptographic keys

Harrington & Salowey Expires September 5, 2006 [Page 11]

Internet-Draft Secure Shell Security Model for SNMP March 2006

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

2.1.2.1. Message security versus session security

As part of session creation, the client and server entities are
typically authenticated and authorized access to the session. In
addition, as part of session establishment, cryptographic key
material is exchanged and is then used to control access to the
session on a message by message basis. Messages then used to control access to the session on a
message by message basis. Messages that fail the basic data origin
authenticaiton/ data integrity checks will be rejected.
Entities receiving the messages that do not have the correct
encryption keys established during session creation will not be able
to read the messages. In order for an entity to process messages, it
must maintain certain state associated with the session. This
includes, but is not limited to, cryptographic encryption and data
integrity keys, entity identities and authorization information
associated with the authenticated identites. After a message is
received and passes integrity and authentication checks, the state
stored in the session is used to provide further authorization for
the message.

2.1.3. Authentication Protocol

SSHSM should support any user 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. host-based.

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 protcol protocol such as CHAP [RFC1994] or digest
authentication [RFC 2617, draft-ietf-radext-digest-auth-04] to
integrate with RADIUS or Diameter. Any of these mechanism These mechanisms leave the
password in the clear on the device that is authenticating the
password which introduces threats on to the authentication
infrastructure which is less than ideal.
infrastructure.

GSSKeyex [I-D.ietf-secsh-gsskeyex] [RFC4462] provides a framework for the addition of user client

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

Internet-Draft Secure Shell Security Model for SNMP June 2006

authentication mechanisms which support different security
infrastructures and provide different security properties.
Additional authentication mechanisms, such as one that supports X.509

Harrington & Salowey Expires September 5, 2006 [Page 12]

Internet-Draft Secure Shell Security Model for SNMP March 2006
certificates, may be added to SSH in the future.

2.1.4. Privacy Protocol

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

2.1.5. Protection against Message Replay, Delay and Redirection

The Secure Shell Security Model uses the SSH transport layer
protocol. SSH uses sequence numbers and integrity checks to protect
against replay and reordering of messages within a connection.

SSH also provides protection against replay of entire sessions. In a
properly-implemented DH exchange, both sides will generate new random
numbers for each exchange, which means the exchange hash and thus the
encryption and integrity keys will be distinct for every session.
This would prevent capturing an SNMP message and redirecting it to
another SNMP engine.

Message delay is not as important an issue with SSH as it is with
USM. USM checks the timeliness of messages because it does not
provide session protection or message sequence ordering. The only
delay that would seem to be possible would be to delay the
transmission of all packets from a particular point in a session
since SSH protects the ordering of packets.

2.1.6. Security Protocol Requirements

Modifying the Secure Shell protocol, or configuring it in a
particular manner, may change its security characteristics in ways
that would impact other existing usages. If a change is necessary,
the change should be an extension that has no impact on the existing
usages. This document will describe the use of an SSH subsytem subsystem for
SNMP.
SNMP to make SNMP usage distinct from other usages.

2.1.6.1. Troubleshooting

SSHSM will likely not work in conditions where access to the CLI has
stopped working and, in working. In situations where SNMP access has to work when
the CLI has stopped working, the use of USM should be considered
instead of SSHSM. [todo] establish a mechanism to determine when
session establishment is repeatedly failing, and how to determine
whether to fallback to USM.

Harrington & Salowey Expires September 5, December 10, 2006 [Page 13] 12]

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

2.1.6.2. Coexistence

The Secure Shell security model can coexist with the USM security
model, the only other currently defined security model. [discuss] #6:
Are there are any wrinkles to coexistence with SNMPv1/v2c/USM?

Note that

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

2.1.6.3. 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. This A Command Responder application
uses a contextEngineID equal to the snmpEngineID of its associated
SNMP
engine.
securityEngineID - The RFC3411 architecture defines ASIs that
include a securityEngineID - engine, and the authoritative SNMP entity - which contextEngineID is either the local snmpEngineID or the target snmpEngineID,
depending on the type of operation. Since included in a security model might
utilize shared credentials and integrity-checking parameters, and
the datastores of scopedPDU to
identify the two endpoints could get out of sync, engine associated with the
"authoritative" engineID indicates which end has data contained in the values to be
used. PDU.
securityEngineID - The securityEngineID is used by USM when
performing integrity checking and authentication, to look up
values in the USM tables, and to synchronize "clocks". The
securityEngineID is not needed by SSHSM, since integrity checking
and authentication are handled outside the SNMP engine.

[discuss] #7: is there still a need for an "authoritative SNMP
engine"? Does authoritative have any meaning in The
RFC3411 architecture defines ASIs that include a TMSM/SSHSM
environment? In SNMPv3, the authoritative engine is usually securityEngineID;
SSHSM should always set the
engine with securityEngineID equal to the command responder, i.e. local
value of snmpEngineID.0 to satisfy the agent; in non-proxy
situations, securityEngineID equals contextEngineID. elements of procedure for
generateRequestMsg() defined in client-server
terms, RFC3412.

2.2. Security Parameter Passing

Security-model-specific parameters for an incoming message are
determined from the authoritative engine is usually SSH layer by the server. So, should transport mapping security
processor (TMSP), before the SNMP engine associated with message processing begins. The TMSP
accepts (decrypted) messages from the SSH server be authoritative?
Would Infoms change that? Would bidirectional messaging change that?
Would call-home change that? Do we need subsystem, and records the
transport-related information and the security-related information,
including authenticated identity, in a cache referenced by
tmStateReference, and passes the WholeMsg and the tmStateReference to set
the securityEngineID MPSP (via the dispatcher).

Harrington & Salowey Expires September 5, December 10, 2006 [Page 14] 13]

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

to indicate which side is the SSH server?

2.2. Security Parameter Passing Requirement

Specific parameters for an incoming message can be determined from
the transport layer by the transport mapping security processing
(TMSP), before the message processing begins, and for

For outgoing messages, the security-model-specific parameters are
gathered by the
messaging-security-processing messaging-security-processor (MPSP) and passed with
the outgoing message to the transport mapping.

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

For incoming messages, the TMSP accepts (decrypted) messages from the
SSH subsystem, and records the transport-related information and the
security-related information, including authenticated identity, in a
cache referenced by tmStateReference, and passes the WholeMsg and the
tmStateReference to the MPSP (via the dispatcher).

The cache reference could be thought of as is an additional parameter in the ASIs between
the transport mapping and the messaging security model.

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

2.3. Requirements for Notifications and Proxy

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

[discuss] #9: Can an existing R/R session be reused

The SNMP-TARGET-MIB module [RFC3413] contains objects for defining
management targets, including transport domains and addresses and
security parameters, for applications such as notifications and
proxy.

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

Harrington & Salowey Expires September 5, December 10, 2006 [Page 15] 14]

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

notifications?

There is some text in Appendix A in RFC 3430 [RFC3430]which captured
some of these discussions when RFC 3430 was written.

3. RFC 3411 Abstract Service Interfaces

Abstract service interfaces have been defined by RFC 3411 to describe
the conceptual data flows between the various subsystems within Message Formats

The syntax of an SNMP entity. The Secure Shell message using this Security Model uses some of these
conceptual data flows when communicating with other subsystems, such
as adheres to
the message format defined in the version-specific Message Processing Subsystem. These RFC 3411-defined data
flows are referred to here as public interfaces.

3.1. Public Abstract Service Interfaces

3.1.1. Public ASIs for Outgoing Messages

The IN parameters of
Model document (for example [RFC3412]). At the prepareOutgoingMessage() ASI time of this writing,
there are used to
pass information from the dispatcher (application subsystem) to the three defined message processing subsystem. formats - SNMPv1, SNMPv2c, and
SNMPv3. SNMPv1 and SNMPv2c have been declared Historic, so this memo
only deals with SNMPv3 messages.

The OUT parameters are used to pass
information from the message processing subsystem to is compatible with the dispatcher RFC 3412 primitives,
generateRequestMsg() and on to processIncomingMsg(), that show the transport mapping:

statusInformation = -- success or errorIndication
prepareOutgoingMessage(
IN transportDomain -- transport domain to be used
IN transportAddress -- transport address to be used
IN messageProcessingModel -- typically, SNMP version
IN securityModel -- data
flow between the Message Processor and the MPSP.

3.1. SNMPv3 Message Fields

The SNMPv3Message SEQUENCE is defined in [RFC3412] and [RFC3416].

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

Internet-Draft Secure Shell Security Model to use
IN securityName -- on behalf of this principal
IN securityLevel for SNMP June 2006

SNMPv3MessageSyntax DEFINITIONS IMPLICIT TAGS ::= BEGIN

SNMPv3Message ::= SEQUENCE {
-- Level identify the layout of Security requested
IN contextEngineID the SNMPv3Message
-- data from/at this entity
IN contextName element is in same position as in SNMPv1
-- data from/in this context
IN pduVersion and SNMPv2c, allowing recognition
-- the version of the PDU
IN PDU value 3 is used for snmpv3
msgVersion INTEGER ( 0 .. 2147483647 ),
-- SNMP Protocol Data Unit
IN expectResponse administrative parameters
msgGlobalData HeaderData,
-- TRUE or FALSE
IN sendPduHandle security model-specific parameters
-- the handle for matching format defined by Security Model
msgSecurityParameters OCTET STRING,
msgData ScopedPduData
}

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

msgFlags OCTET STRING (SIZE(1)),
-- incoming responses
OUT destTransportDomain .... ...1 authFlag
-- destination transport domain
OUT destTransportAddress .... ..1. privFlag
-- destination transport address
OUT outgoingMessage .... .1.. reportableFlag
-- the message to send
OUT outgoingMessageLength Please observe:
-- its length
) .... ..00 is OK, means noAuthNoPriv
-- .... ..01 is OK, means authNoPriv
-- .... ..10 reserved, MUST NOT be used.
-- .... ..11 is OK, means authPriv

msgSecurityModel INTEGER (1..2147483647)
}

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

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

The abstract service primitive from a Message Processing Model to a
Security Model to generate following describes how SSHSM treats certain fields in the components of a Request message is:
message:

Harrington & Salowey Expires September 5, December 10, 2006 [Page 16]

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

statusInformation = -- success or errorIndication
generateRequestMsg(
IN messageProcessingModel -- typically, SNMP version
IN globalData -- message header, admin data
IN maxMessageSize -- of

3.1.1. msgGlobalData

msgGlobalData is opaque to SSHSM. The values are set by the sending SNMP entity
IN securityModel -- for Message
Processing model (e.g., SNMPv3 Message Processing), and are not
modified by SSHSM.

msgMaxSize is determined by the outgoing message
IN securityEngineID -- authoritative SNMP entity
IN securityName -- on behalf of this principal
IN securityLevel -- Level implementation.

To avoid the need to mess with the ASN.1 encoding, msgGlobalData
contains the value of Security requested
IN scopedPDU -- message (plaintext) payload
OUT securityParameters -- filled in msgFlags set by Security Module
OUT wholeMsg -- complete generated message
OUT wholeMsgLength -- length of generated message
)

The abstract service primitive from a the Message Processing Model to a
Security Model model
(e.g., SNMPv3 Message Processing), not the actual (authPriv)
securityLevel applied to generate the components of a Response message is:

msgSecurityModel is set by the sending SNMP entity
IN securityModel -- Message Processing model (e.g.,
SNMPv3) to the IANA-assigned value for the outgoing message
IN securityEngineID -- authoritative SNMP entity
IN securityName -- on behalf of this principal
IN securityLevel -- Level of Secure Shell Security requested
IN scopedPDU --
Model. See http://www.iana.org/assignments/snmp-number-spaces.

3.1.2. msgSecurityParameters

Since message (plaintext) payload
IN securityStateReference -- reference to security state
-- information from original
-- request
OUT securityParameters -- filled in is provided by Security Module
OUT wholeMsg -- complete generated message
OUT wholeMsgLength -- length of generated message
)

The abstract data elements passed as parameters in a "lower layer", and the abstract
service primitives are as follows: [todo] check each
securityName parameter and
determine if it is necessary for SSHSM and whether the description is
accurate
o statusInformation - An indication of whether always determined from the encoding and
securing of SSH
authentication method, the SNMP message was successful. If does not it is an
indication of need to carry
message security parameters within the problem.
o messageProcessingModel - msgSecurityParameters field.

The SNMP version number field msgSecurityParameters in SNMPv3 messages has a data type of
OCTET STRING. To prevent its being used in a manner that could be
damaging, such as for carrying a virus or worm, when used with SSHSM
its value MUST be the message BER serialization of a zero-length OCTET
STRING.

SSHSMSecurityParametersSyntax DEFINITIONS IMPLICIT TAGS ::= BEGIN

SSHsmSecurityParameters ::=
SEQUENCE {
OCTET STRING
}
END

3.2. Passing Security Parameters

For SSHSM, there are two levels of state that need to be generated. This data is not used by maintained:
the User-based Security
module. session state, and the message state.

3.2.1. tmStateReference

For each session, SSHSM stores information about the session in the
Local Configuration Datastore, supplemented with a cache to store
model- and mechanism-specific parameters.

Harrington & Salowey Expires September 5, December 10, 2006 [Page 17]

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

o globalData - The message header (i.e., its administrative
information). This data is not used by

Upon opening an SSH connection, the User-based Security
module.
o maxMessageSize - The maximum message size as included TMSP will store the transport
parameters in the
message. This data is not used by tmSessionTable of the User-based Security module.
o securityParameters TMSM-MIB [I-D.ietf-isms-tmsm]
for subsequent usage.

tmsmSessionID = a unique local identifier
tmsmTransport = transportDomainSSH
tmsmSessionAddress = a TransportAddressSSH
tmsmSessionSecurityModel - These are SSHSM
tmsmSessionSecurityLevel = "authPriv"
tmsmSessionSecurityName = the security parameters. They will
be filled in principal name authenticated by SSH.
How this data is extracted from the SSH Security module.
o securityModel - The securityModel in use. Should be SSH Security
Model.
o securityName - identifies environment and how it is
translated into a principal to be used for securing an
outgoing message. The securityName has a format that is
independent of implementation-dependent. By
default, the Security Model. In case of a response this
parameter tmSecurityName is ignored and the value name that has been successfully
authenticated by SSH, from the cache is used.
o securityLevel - The Level user name field of Security from which the SSH Security
module determines
SSH_MSG_USERAUTH_REQUEST message.
tmsmSessionEngineID = if known, the message needs to be protected value of the remote engine's
snmpEngineID.

How the SSH identity is extracted from
disclosure and if the message needs to be authenticated.
o securityEngineID - The snmpEngineID of SSH layer, and how the authoritatvie SNMP
engine to which a dateRequest message SSH
identity is mapped to be sent. In case of a
response it securityName for storage in tmsmSessionTable
is implied to implementation-dependent. Additional information may be the processing SNMP engine's
snmpEngineID and so if it is specified, then it is ignored.
o scopedPDU - The message payload. The data is opaque stored in
a local datastore (such as far a preconfigured mapping table) or in a
cache, such as the value of an SSH Security Model session identifier (as distinct
from the tmsmSessionID).

The tmStateReference is concerned.
o securityStateReference - A handle/reference used to cachedSecurityData pass references to be used when securing an outgoing Response message. This is the exact same hsecurityStateReference as was generated by the SSH
Security module when processing appropriate
session information between the incoming Request message to
which this is TMSP and MPSP through the Response message.
o wholeMsg - ASIs.

The fully encoded SNMP message ready SSHSM has the responsibility for sending on explicitly releasing the
wire.
o wholeMsgLength - The length of
complete tmStateReference and deleting the encoded SNMP message
(wholeMsg).

Upon completion of associated
tmsmSessionEntry in the process, tmsmSessionTable when the SSH Security module returns
statusInformation. If session is
destroyed.

3.2.2. securityStateReference

For each message received, SSHSM caches message-specific security
information such that a Response message can be generated using the process was successful,
same security information, even if the completed
message Configuration Datastore is returned, without
altered between the privacy time of the incoming request and authentication applied
yet. If the process was not successful, then an errorIndication is
returned.

3.1.2. Public ASIs for Incoming Messages outgoing
response. The abstract service primitive from a Transport Mapping (in securityStateReference is used to preserve the
dispatcher) data
needed to generate a Response message with the same security
information. This information includes the model-independent
parameters (securityName, securityLevel, transport address, and
transport type). The Message Processing Model has the responsibility
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 received message is:: response, or explicitly
released by using the stateRelease primitive, as described in RFC

Harrington & Salowey Expires September 5, December 10, 2006 [Page 18]

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

result = -- SUCCESS

3411 section 4.5.1."

The SSH standard does not require that a session be maintained nor
that it be closed when the keys associated with the host or errorIndication
prepareDataElements(
IN transportDomain -- origin transport domain
IN transportAddress -- origin transport address
IN wholeMsg -- as received from client
associated with the network
IN wholeMsgLength -- as received from session are changed. Some SSH implementations
might close an existing session if the network
OUT messageProcessingModel -- typically, SNMP version
OUT securityModel -- Security Model to use
OUT securityName -- on behalf of this principal
OUT securityLevel -- Level of Security requested
OUT contextEngineID -- data from/at this entity
OUT contextName -- data from/in this context
OUT pduVersion -- keys associated with the version of
session change. For SSHSM, if the PDU
OUT PDU -- SNMP Protocol Data Unit
OUT pduType -- SNMP PDU type
OUT sendPduHandle -- handle for matched session is closed between the time
a Request is received and a Response message is being prepared, then
the Response should be discarded.

The parameters associated with an incoming request
OUT maxSizeResponseScopedPDU -- maximum size sender can accept
OUT statusInformation -- success or errorIndication
-- error counter OID/value if error
OUT stateReference -- reference to state information
-- message to be used for possible Response
)

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

statusInformation = -- errorIndication or success
-- error counter OID/value if error
processIncomingMsg(
IN outgoing response.
messageProcessingModel -- typically, SNMP version
IN maxMessageSize -- = SNMPv3
securityModel = SSHSM
sessionID = tmSessionID

4. Elements of Procedure

Abstract service interfaces have been defined by RFC 3411 to describe
the sending SNMP entity
IN securityParameters -- for the received message
IN securityModel -- for conceptual data flows between the received message
IN securityLevel -- Level of various subsystems within an
SNMP entity. The Secure Shell Security
IN wholeMsg -- Model uses some of these
conceptual data flows when communicating between subsystems, such as received on
the wire
IN wholeMsgLength -- length dispatcher and the Message Processing Subsystem. These RFC 3411-
defined data flows are referred to here as received on public interfaces.

To simplify the wire
OUT securityEngineID -- authoritative SNMP entity
OUT securityName -- identification elements of procedure, the principal
OUT scopedPDU, -- release of state
information is not always explicitly specified. As a general rule,
if state information is available when a message (plaintext) payload
OUT maxSizeResponseScopedPDU -- maximum size sender can handle
OUT securityStateReference -- reference to security gets discarded, the
message-state information should also be released, and if state
) -- information, needed
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 response 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.

4.1. Generating an Outgoing SNMP Message

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

Harrington & Salowey Expires September 5, December 10, 2006 [Page 19]

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

3.2.

statusInformation = -- success or errorIndication
prepareOutgoingMessage(
IN transportDomain -- transport domain to be used
IN transportAddress -- transport address to be used
IN messageProcessingModel -- typically, SNMP Messages Using this version
IN securityModel -- Security Model

The syntax to use
IN securityName -- on behalf of an SNMP message using this principal
IN securityLevel -- Level of Security Model adheres to requested
IN contextEngineID -- data from/at this entity
IN contextName -- data from/in this context
IN pduVersion -- the message format defined in version of the version-specific Message Processing
Model document (for example [RFC3412]). At PDU
IN PDU -- SNMP Protocol Data Unit
IN expectResponse -- TRUE or FALSE
IN sendPduHandle -- the time of this writing,
there are three defined message formats - SNMPv1, SNMPv2c, and
SNMPv3.

3.2.1. SNMPv1 and SNMPv2c Messages Using this Security Model

Since message security is provided by a "lower layer", handle for matching
incoming responses
OUT destTransportDomain -- destination transport domain
OUT destTransportAddress -- destination transport address
OUT outgoingMessage -- the message
does not need to carry message security parameters. send
OUT outgoingMessageLength -- its length
)

The securityModel and securityName IN parameters of the prepareOutgoingMessage() ASI are determined by used to
pass information from the
Secure Shell dispatcher (for the application subsystem)
to the message processing subsystem.

The abstract service primitive from a Message Processing Model to a
Security Model from to generate the SSH service. SSHSM requires
that transport always be authenticated and integrity-checked and
encrypted, so all SSHSM messages are authPriv. Since an incoming
SNMPv1 or SNMPv2c components of a Request message lacks is
generateRequestMsg(), as described in Section 4.2.

The abstract service primitive from a msgFlags field, Message Processing Model to a
Security Model to generate the msgFlags components of a Response message is
always treated
generateResponseMsg(), as authPriv.

The community string described in Section 4.2.:

Upon completion of the MPSP processing, the SSH Security module
returns statusInformation. If the process was successful, the
completed message is returned, without the privacy and authentication
applied yet. If the process was not used as successful, then an authentication mechansism,
since user authentication
errorIndication is provided by SSH userauth. returned.

The community
string is still OUT parameters are used to provide context information. To be clear, pass information from the message
processing subsystem to the community strin gi snot touched, dispatcher and just shipped opaquely, so
people who use on to the community string in proprietary ways to identify
contexts should not be impacted.

The SNMPv1 and SNMPv2c message formats do not contain a
contextEngineID, but do contain an IP Address field that can be used
to perform proxy, and where implemented by the agent, the
snmpEngineID at the IP address can be learned by querying the device
with a GET request.

3.2.2. SNMPv3 Messages Using this Security Model

RFC 3412 defines two primitives, generateRequestMsg() and
processIncomingMsg() which require the specification of an
authoritative SNMP entity. [discuss] #10: which securityparameters
must be supported transport
mapping:

4.2. MPSP for the SSHSM model, and why? Which services
provided in USM are needed in TMSM/SSHSM? How does the an Outgoing Message
Processing model provides this information to

This section describes the security model via
generateRequestMsg() and processIncomingMsg() primitives?

The SNMPv3Message SEQUENCE is defined in [RFC3412]. The following
fields are specific to procedure followed by the Secure Shell
Security Model: Model.

Harrington & Salowey Expires September 5, December 10, 2006 [Page 20]

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

SNMPv3MessageSyntax DEFINITIONS IMPLICIT TAGS ::= BEGIN

SNMPv3Message ::= SEQUENCE {
-- identify

The parameters needed for generating a message are supplied to the layout of
MPSP by the SNMPv3Message
-- this element is in same position as in SNMPv1
-- Message Processing Model via the generateRequestMsg() or
the generateResponseMsg() ASI. The TMSM architectural extension has
added the transportDomain, transportAddress, and SNMPv2c, allowing recognition
-- tmStateReference
parameters to the value 3 is used for snmpv3
msgVersion INTEGER ( 0 .. 2147483647 ), original RFC3411 ASIs.

statusInformation = -- administrative parameters
msgGlobalData HeaderData, success or errorIndication
generateRequestMsg(
IN messageProcessingModel -- security model-specific parameters typically, SNMP version
IN globalData -- format defined message header, admin data
IN maxMessageSize -- of the sending SNMP entity
IN transportDomain -- as specified by Security Model
msgSecurityParameters OCTET STRING,
msgData ScopedPduData
}

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

msgFlags OCTET STRING (SIZE(1)), application
IN transportAddress -- .... ...1 authFlag as specified by application
IN securityModel -- .... ..1. privFlag for the outgoing message
IN securityEngineID -- .... .1.. reportableFlag authoritative SNMP entity
IN securityName -- Please observe: on behalf of this principal
IN securityLevel -- .... ..00 is OK, means noAuthNoPriv Level of Security requested
IN scopedPDU -- .... ..01 is OK, means authNoPriv message (plaintext) payload
OUT securityParameters -- .... ..10 reserved, MUST NOT be used. filled in by Security Module
OUT wholeMsg -- .... ..11 is OK, means authPriv

msgSecurityModel INTEGER (1..2147483647)
}

ScopedPduData ::= CHOICE {
plaintext ScopedPDU,
encryptedPDU OCTET STRING complete generated message
OUT wholeMsgLength -- encrypted scopedPDU value
}

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

Harrington & Salowey Expires September 5, 2006 [Page 21]

Internet-Draft Secure Shell Security Model for SNMP March 2006

3.2.2.1. msgGlobalData

SSHSM requires that transport always be authenticated, integrity-
checked, and encrypted, so all SSHSM messages are authPriv. The
msgFlags MUST always be set to authPriv.

msgSecurityModel is set reference to session info
)

statusInformation = -- success or errorIndication
generateResponseMsg(
IN messageProcessingModel -- typically, SNMP version
IN globalData -- message header, admin data
IN maxMessageSize -- of the IANA-assigned value sending SNMP entity
IN transportDomain -- as specified by application
IN transportAddress -- as specified by application
IN securityModel -- for the Secure
Shell Security Model. See
http://www.iana.org/assignments/snmp-number-spaces.

3.2.2.1.1. msgSecurityParameters

Since outgoing message security is provided by a "lower layer", and the
securityName parameter is always determined from the SSH
authentication method, the
IN securityEngineID -- authoritative SNMP message does not need to carry
message security parameters within the msgSecurityParameters field.
To prevent its being used in a manner that could be damaging, such as
for carrying a virus or worm, when used with SSHSM, it is an empty
field.

The field msgSecurityParameters in SNMPv3 messages has a data type entity
IN securityName -- on behalf of
OCTET STRING. Its value MUST be the BER serialization this principal
IN securityLevel -- Level of the
following ASN.1 sequence:

SSHSMSecurityParametersSyntax DEFINITIONS IMPLICIT TAGS ::= BEGIN

SSHsmSecurityParameters :: SEQUENCE {
OCTET STRING
}
END

3.2.2.1.2. msgFlags

For an outgoing message, msgFlags is the Security requested
IN scopedPDU -- message (plaintext) payload
IN securityStateReference -- reference to security for the
message; if a SSHSM cannot provide the requested securityLevel, the state
-- information from original
-- request MUST be discarded and SHOULD notify the
OUT securityParameters -- filled in by Security Module
OUT wholeMsg -- complete generated message processing
model that the request failed.

For an outgoing message, it is acceptable for the SSHSM to provide
stronger than requested security. To avoid the need to mess with the
ASN.1 encoding, the SNMPv3
OUT wholeMsgLength -- length of generated message carries the requested msgFlags,
not the actual securityLevel applied
OUT tmStateReference -- reference to the message. If a message
format other than SNMPv3 is used, then the new message may carry the
more accurate securityLevel in the SNMP message. session info
)

Harrington & Salowey Expires September 5, December 10, 2006 [Page 22] 21]

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

3.2.3. Passing Security Parameters

For each message received, the Security Model caches the state
information such that a Response message can be generated using the
same security information, even if

o statusInformation - An indication of whether the Configuration Datastore is
altered between construction of
the time message was successful. If not it contains an indication of
the incoming request and problem.
o messageProcessingModel - The SNMP version number for the outgoing
response. For SSHSM, there are three levels of state that need message
to be
maintained: the session, the message, and the model-independent
translations. generated.
o globalData - The tmStateReference message header (i.e., its administrative
information). This data is used to pass model- and mechanism-specific
parameters opaque to coordinate the session-related activities and specific
message pair processing between the TMSP and MPSP. SSHSM.
o maxMessageSize - The SSHSM has maximum message size as included in the
responsibility for explicitly releasing
message. This data is not used by SSHSM.
o transportDomain - as specified by the complete tmStateReference
when application.
o transportAddress - as specified by the session is destroyed. application.
o securityModel - The SSHSM has securityModel in use. In this case, the responsibility for
releasing SSH
Security Model.
o securityEngineID - SSHSM always sets this to the message-specific parameters in snmpEngineID of
the tmStateReference
once sending SNMP engine.
o securityName - identifies a response message principal to be used for securing an
outgoing message. The securityName has been sent, or the data a format that is no longer
needed.

The MPSP translates select parameters from the tmStateReference cache
into model-independent parameters subsequently passed in
independent of the
securityStateReference cache to a Message Processing Security Model. The
Message Processing Model has In case of a response this
parameter is ignored and the responsibility for explicitly
releasing value from the securityStateReference if such data
cache is no longer
needed. used.
o securityLevel - Ignored by SSHSM, which always uses an authPriv
securityLevel.
o scopedPDU - The message payload. The scopedPDU is opaque to
SSHSM.
o 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."

SSH does not require that a session be maintained nor - A handle/reference to cachedSecurityData
that it be
closed is used when the keys associated with the host or client associated
with the session are changed. Some SSH implementations may close sending an
existing session if the keys associated with outgoing Response message. This is
the session change. For
SSHSM, if exact same securityStateReference as was generated by the session is closed between SSH
Security module when processing the time a incoming Request is
received and a Response message to
which this is being prepared, then the Response
should be discarded.

3.2.3.1. Transport Session Parameters

SSHSM will create a session between the TMSM of one message.
o securityParameters - Always set to empty by SSHSM.
o wholeMsg - The fully encoded SNMP entity and message ready for sending on the TMSM of another SNMP entity.
wire.
o wholeMsgLength - The created SSH "tunnel" MUST
provide authentication length of the client and server, and MUST integrity-
check and encrypt encoded SNMP message
(wholeMsg).
o tmStateReference - a handle/reference to the messages.

Upon establishment of an SSH session, session information
to be passed to the TMSP will cache the
transport parameters in portion of the tmStateReference for subsequent usage.
This information should be stored in a local datastore.

Harrington & Salowey Expires September 5, 2006 [Page 23]

Internet-Draft Secure Shell SSH Security Model for SNMP March 2006

The Model.
Note that SSHSM adds transportDomain, transportAddress, and
tmStateReference cache for use with the SSH Authentication
Protocol [RFC4252] will include the following transport-related
information: [discuss] #15: What data needs have been added to these ASIs.

4.2.1. MPSP Procedures

1) verify that securityModel is sshsmSecurityModel. If not, then
an error indication is returned to be stored in the
tmStateReference, calling message model, and how does SSHSM get the information from SSH,
MPSP processing stops for the various authentication and transport options?
tmSessionID = this message.
2) If there is a unique local identifier
tmTransportDomain = tDomainSSH
tmTransportAddress = x.x.x.x:y
tmSecurityModel - SSHSM
tmSecurityLevel = "authPriv"

Additional information will be added to securityStateReference, then extract the
tmStateReference by from the
authentication portion of cachedSecurityData. At this point, the SSHSM.

[discuss] #16B: Passing a securityname might
SecurityDataCache can now be useful released.

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

Internet-Draft Secure Shell Security Model for passing as
a hint to RADIUS or other authorization mechanism to indicate which
identity we want SNMP June 2006

2b) If the session referenced by securityStateReference does not
still exist (i.e., the session used to use when doing access control, and RADIUS,etc.
can tell us whether receive the username being authenticated request is allowed to be
mapped no
longer available to that authorization/accounting identity. Should we provide
securityname when establishing a session, so send the authentication
machanisms can use it as a hint?

3.2.3.1.1. Authenticating Servers and Clients

tmSecurityName = corresponding response) then the user name authenticated by SSH

tmSecurityName
tmsmSessionNoAvailableSessions counter is the name that has been successfully authenticated
by SSH, from the user name field of the SSH_MSG_USERAUTH_REQUEST
message.

How this data incremented, an error
indication is extracted from the SSH environment returned to put into the
SNMP environment is implementation-dependent.

[todo] #18: I currently have multiple sections, one calling module, the message is
discarded, and MPSP processing stops for each known
auth mechanism. We need this message.
3) If there is no securityStateReference, then find or create an
entry in a Local Configuration Datastore containing the provided
transportDomain, transportAddress, securityName, securityLevel,
and securityModel, and create a tmStateReference to discuss reference the parameters that need
entry.
4) fill in the securityParameters with the serialization of a
zero-length OCTET STRING.
5) Combine the message parts into a wholeMsg and calculate
wholeMsgLength.
6) The completed message (wholeMsg) with its length
(wholeMsgLength) and securityParameters (a zero-length octet
string) and tmStateReference is returned to be
cached the calling module
with the statusInformation set to success.

The Message Processing Model then passes information to the
disptacher for each. Once we are complete, I will collapse this into one
section.

3.2.3.2. [discuss] Using Passwords forwarding to Authenticate SNMP Principals

Upon creation the Transport Mapping.

4.3. TMSP for an Outgoing Message

The Dispatcher passes the information to the Transport Mapping using
the ASI defined in the TMSM extension:

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
)

The TMSP portion of a SSH session, the SSHSM performs the following tasks:

4.3.1. TMSP will cache Procedures

7) Lookup the session
authentication information in the tmStateReference:
tmSecurityName is Local Configuration Datastore using
the name extracted transportDomain, transportAddress, securityName,
securityLevel, and securityModel from the user name field of tmStateReference.
Extract any implementation-specific parameters from the SSH_MSG_USERAUTH_REQUEST message, after authentication has
completed successfully. LCD.

Harrington & Salowey Expires September 5, December 10, 2006 [Page 24] 23]

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

tmAuthMechanism = "password"
tmAuthProtocol = "password"
tmSecurityLevel = appropriate choice from SnmpSecurityLevel
tmAuthzRef = "[todo] authorization data obtained during

8) If there is no session open associated with the
exchange"

3.2.3.3. [discuss] Using Public keys
transportDomain, transportAddress, securityName, securityLevel,
and securityModel, then call openSession(). If an error is
returned from OpenSession(), then discard the message and return
the error indication in the statusInformation.
9) Store any implementation-specific information in the LCD for
subsequent use.
10) Pass the wholeMessage to Authenticate SNMP Principals

Upon creation of a SSH session, for encapsulation in an
SSH_MSG_CHANNEL_DATA message.

4.4. Processing an Incoming SNMP Message

4.4.1. TMSP for an Incoming Message

For an incoming message, the TMSP will cache the session
authentication need to put information in from
the tmStateReference:
tmSecurityName is SSH layer into a Local Configuration Datastore referenced by
tmStateReference.

1) The SSHSM queries the name extracted from associated SSH engine, in an
implementation-dependent manner, to determine the user name field of transport and
security parameters for the SSH_MSG_USERAUTH_REQUEST message
tmAuthMechanism received message.

transportDomain = "publickey"
tmAuthProtocol transportDomainSSH
transportAddress = public key algorithm name
tmSecurityLevel a TransportAddressSSH
tmsmSecurityModel - SSHSM
tmsmSecurityLevel = appropriate choice from SnmpSecurityLevel
tmAuthzRef "authPriv"
tmsmSecurityName = "[todo] authorization the principal name authenticated by SSH.
How this data obtained during is extracted from the
exchange"

3.2.3.4. [discuss] Using Host-based Authentication of SNMP Principals

Upon creation of a SSH session, the TMSP will cache the session
authentication information in environment and how it
is translated into a securityName is implementation-dependent.
By default, the tmStateReference: tmSecurityName is the name used in that has been
successfully authenticated by SSH, from the user name field of
the SSH_MSG_USERAUTH_REQUEST message
tmAuthMechanism = "hostbased"
tmAuthProtocol = public key algorithm for host key
tmSecurityLevel = appropriate choice from SnmpSecurityLevel
tmAuthzRef = "[todo] authorization data obtained during message.
2) If one does not exist, the
exchange"

3.2.3.5. securityStateReference for SSHSM

The parameters associated with TMSP creates an incoming request message to be
applied to entry in a Local
Configuration Datastore, in an implementation-dependent format,
containing the outgoing response.
messageProcessingModel = SNMPv3
securityModel = SSHSM
sessionID = tmSessionID

3.2.4. MIB Module information and any implementation-specific
parameters desired, and creates a tmStateReference for SSH Security Model

Each security model should use its own MIB module, rather than
utilizing the USM MIB, subsequent
reference to eliminate dependencies on a model that
could be replaced some day. See RFC 3411 section 4.1.1.

[todo] the information.

Then the Transport mapping from model-specific identity passes the message to a model
independent securityName the Dispatcher using
the following primitive:
statusInformation =
recvMessage(
OUT transportDomain -- domain for storage in an LCD is implementation- 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
)

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

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

dependent. This is Implementation-dependent, both in the case of
extracting tmSecurityname from SSH for an incoming message, and for
providing an LCD mapping.

[todo] Module needs to be worked out once things become stable..

3.2.5. [todo] Notifications

For notifications, if no session has yet been created, or the session
has been closed, then the TMSP will establish a session and populate
the cache for subsequent usage. [discuss] #21: we need to determine
what data should be persistent and stored in the LCD for notification
purposes.

3.3.

4.5. Prepare Data Elements of Procedure

3.3.1. Establishing a Session from Incoming Messages

The Secure Shell Security Model provides the following abstract service primitive to
pass data back and forth between the Transport Mapping portion of from the
Security Dispatcher to a Message
Processing Model and the SSH service:

statusInformation establishSession( for a received message is:

result = -- SUCCESS or errorIndication
prepareDataElements(
IN destTransportDomain transportDomain -- origin transport domain to be used
IN destTransportAddress transportAddress -- origin transport address to be used
IN securityModel wholeMsg -- Security Model to use as received from the network
IN securityEngineID wholeMsgLength -- SNMP entity as received from the network
IN tmStateReference -- from the transport mapping
OUT messageProcessingModel -- typically, SNMP version
OUT securityModel -- Security Model to use
OUT securityName -- on behalf of this principal
IN
OUT securityLevel -- Level of Security requested
IN subsystem
OUT sessionID
)

The following describes contextEngineID -- data from/at this entity
OUT contextName -- data from/in this context
OUT pduVersion -- the procedure version of the PDU
OUT PDU -- SNMP Protocol Data Unit
OUT pduType -- SNMP PDU type
OUT sendPduHandle -- handle for matched request
OUT maxSizeResponseScopedPDU -- maximum size sender can accept
OUT statusInformation -- success or errorIndication
-- error counter OID/value if error
OUT stateReference -- reference to follow state information
-- to establish a
session between a client and sever be used for possible Response
)

Note that tmStateReference has been added to run SNMP over SSH. this ASI.

4.6. MPSP for an Incoming Message

This
process is section describes the procedure followed by any SNMP engine establishing a session for
subsequent use. In practice, this is done by the MPSP whenever it
receives an application that
initiates a transaction, such as a Command Generator or a
Notification Originator or incoming message containing a Proxy Forwarder. It is never triggered
by an application preparing management operation on
behalf of a response message, such as user from a Command
Responder or Notification Receiver, because securityStatereference
will always have session Message Processing model.

The Message Processing Model extracts some information for a response message from the
wholeMsg. The parameters necessary to establish abstract service primitive from a session are provided by Message Processing
Model to the Security Subsystem for a received message is::

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

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

Secure Shell Security Model to

1) If received message
IN securityModel -- for the received message
IN securityLevel specifies that -- Level of Security
IN wholeMsg -- as received on the message is to be
authenticated, but wire
IN wholeMsgLength -- length as received on the SSH implementation does not support an
authentication protocol, then wire
IN tmStateReference -- from the transport mapping
OUT securityEngineID -- authoritative SNMP entity
OUT securityName -- identification of the principal
OUT scopedPDU, -- message cannot be sent. An error
indication (unsupportedSecurityLevel) (plaintext) payload
OUT maxSizeResponseScopedPDU -- maximum size sender can handle
OUT securityStateReference -- reference to security state
) -- information, needed for response

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

2) If Extract the securityLevel specifies that value of securityName from the message Local Configuration
Datastore entry referenced by tmStateReference.

3) The scopedPDU component is to be protected extracted from disclosure, but the SSH implementation does not support
encryption, then wholeMsg.

4) The maxSizeResponseScopedPDU is calculated. This is the message cannot be sent. An error indication
(unsupportedSecurityLevel) maximum
size allowed for a scopedPDU for a possible Response message.

5)The security data is returned cached as cachedSecurityData, so that a
possible response to the calling module.

3) Using destTransportDomain this message can and destTransportAddress, the client will establish an SSH transport connection using the SSH transport
protocol, and use the client and server will mutually authenticate, and
exchange keys same security
parameters. Then securityStateReference is set for message integrity and encryption. if the attempt subsequent
reference to
establish this cached data. For SSHSM, the securityStateReference
should include a connection is successful, then tmStateReference is
created, and reference to the values of transportDomain and transportAddress are
saved. tmStateReference.

3) If the attempt to establish a connection received securityParameters is unsuccessful,
then an error indication [todo] will be returned, and [todo]
processing stops.

[discuss] #22: There are a significant number not the serialization of security problems
associated with mapping to a transport address which may need an
OCTET STRING formatted according to be
discussed in the security considerations section.

4) The provided securityEngineID and securityName SSHsmSecurityParameters, and securityLevel
are used to lookup
the associated entry in contained OCTET STRING is not empty, then the Local Configuration
Datastore (LCD), snmpInASNParseErrs
counter [RFC3418] is incremented, and the model-specific information concerning the
principal at the destination an error indication
(parseError) is extracted. This step allows
preconfiguration of model-specific principals mapped to the engine/
name/level, for example, for sending notifications using host-only
authentication. Set the username in the SSH_MSG_USERAUTH_REQUEST returned to the username extracted from the LCD.

If information about the user calling module.

4) The statusInformation 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 success and model-independent names, but the
securityName will need to contain a username recognized by the
authentication mechanism.

5)The client will then invoke the "ssh-userauth" service return is made to
authenticate
the user, calling module passing back the OUT parameters as described specified in
the SSH authentication
protocol [RFC4252]. processIncomingMsg primitive.

Harrington & Salowey Expires September 5, December 10, 2006 [Page 27] 26]

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

6) If the authentication is unsuccessful, then the transport
connection should be closed, tmStateReference is discarded,

4.7. Establishing a Session

The Secure Shell Security Model provides the
message is discarded, an error indication (unknownSecurityName) is
returned following primitive to the calling module,
pass data back and processing stops for this
message.

7) Once the user has been successfully authenticated, forth between the client will
invoke Transport Mapping portion of the "ssh- connection" service, also known as
Security Model and the SSH
connection protocol [RFC4254].

8) After the ssh-connection service is established, the client will
use an SSH_MSG_CHANNEL_OPEN message service:

statusInformation =
openSession(
IN destTransportDomain -- transport domain to open a channel be used
IN destTransportAddress -- transport address to be used
IN maxMessageSize -- of type
"session", providing a selected sender channel number, and a maximum
packet size based the sending SNMP entity
IN securityModel -- Security Model to use
IN securityName -- on maxMessageSize.

9) If successful, behalf of this will result in an SSH session. principal
IN securityLevel -- Level of Security requested
OUT tmStateReference
)

The
destTransportDomain nd the destTransportAddress, plus following describes the "recipient
channel" and "sender channel" procedure to follow to establish a
session between a client and other relevant data from the
SSH_MSG_CHANNEL_OPEN_CONFIRMATION are added server to the tmStateReference
for subsequent use.

10) Running run SNMP as an SSH subsystem avoids the need for the script
to recognize shell prompts or skip over extraneous information, such
as a system message that SSH. This
process is printed at shell start-up. Once the SSH
session has been established, the followed by any SNMP engine establishing a session for
subsequent use.

This will invoke be done automatically for an SNMP application that
initiates a transaction, such as an
SSH subsystem, a Command Generator or a
Notification Originator or a Proxy Forwarder. It is never triggered
by an application preparing a response message, such as indicated in a Command
Responder or Notification Receiver, because securityStateReference
will always have the "subsystem" parameter.

In order to allow SNMP traffic to be easily identified and filtered
by firewalls session information for a response message

1) Using destTransportDomain and other network devices, servers associated with SNMP
entities using the Secure Shell Security Model MUST default to
providing access to the "SNMP" SSH subsystem only when destTransportAddress, the client
will establish an SSH
session is established transport connection using the IANA-assigned TCP port (TBD).
Servers SHOULD be configurable to allow access to the SNMP SSH
subsystem over other ports.

[todo] check whether there is a better way to establish a tunnel transport
protocol, authenticate the server, and exchange keys for
SNMP messages.

[discuss] We must perform some type message
integrity and encryption. The parameters of engineID discovery to provide the mapping between transport address, session, connection
and engineID at this
point in the session establishment procedure? We have credentials used to authenticate are provided in an established
channel; can we simply send
implementation-dependent manner.

If the attempt to establish a GET of snmpEngineID connection is unsuccessful, or server
authentication fails, then an error indication is returned, and record the
value
openSession processing stops.

2) The provided transport domain, transport address, securityModel,
securityName and securityLevel are used to lookup an associated entry
in the tmStateReference?

11) [todo] Local Configuration Datastore (LCD). Any model-specific
information concerning the engine will perform an SNMP GET command requesting principal at the
value destination is extracted.
This step allows preconfiguration of model-specific principals mapped
to the remote engine's snmpEngineID object, and create a
tmStateReference cache recording transport/name/level, for example, for sending notifications.
Set the following information: username in the SSH_MSG_USERAUTH_REQUEST to the username

Harrington & Salowey Expires September 5, December 10, 2006 [Page 28] 27]

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

extracted from the remote engine's snmpEngineID
the transport address
the recipient and sender channels

3.3.2. Closing a Session

The Secure Shell Security Model provides LCD.

If information about the following primitive to
pass data back and forth between principal is absent from the Security Model and LCD, then set
the SSH
service:

statusInformation closeSession(
IN sessionID
)

The following describes username in the procedure to follow SSH_MSG_USERAUTH_REQUEST to close the value of
securityName. This allows a session deployment without preconfigured
mappings between a client model-specific and sever to run SNMP over SSH. This process is
followed by any SNMP engine closing model-independent names, but the corresponding SNMP session.

The Secure Shell Security Model identifies which session should be
closed
securityName will need to contain a username recognized by the SSH
authentication mechanism.

3)The client code, using will then invoke the closeSession() ASI.

[discuss] #23: We need "ssh-userauth" service to discuss
authenticate the circumstances under which a
session should be closed, and how an SNMP engine should determine if,
and respond if user, as described in the SSH session is closed by other means.

3.3.3. Discovery

Since snmpEngineID isn't really needed for authentication and
integrity checking, it becomes useful primarily for contextEngineID.
contextEngineID
protocol [RFC4252].

If the authentication is useful for proxy, and for a management application
to uniquely identify an SNMP entity. Since snmpEngineID unsuccessful, then the transport connection
is an object
in closed, tmStateReference is released, the SNMP-FRAMEWORK-MIB, message is discarded, an
error indication (unknownSecurityName) is returned to the mapping between engineID calling
module, and transport
address could be established after a tunnel 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, or could
be determined using noAuthNoPriv (with suitable caveats).

[discuss] #24: How should we enable auto-discovery? Auto-discovery
of SNMP devices is the client will
use an important feature SSH_MSG_CHANNEL_OPEN message to open a channel of many NMS platforms.
Should we simply use type
"session", providing a noAuthNoPriv request, selected sender channel number, and recommend a maximum
packet size calculated from the SNMP maxMessageSize.

6) If successful, this will result in an
associated access control configuration that only makes accessible
relatively benign data such as sysOID, sysDescription, SSH session. The
destTransportDomain and
snmpEngineID? Should we standardize this approach for all TMSM
models, including a "named policy" for what 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 discovered (a
policy
added to be configured within whatever access control system is
used)?

Harrington & Salowey Expires September 5, 2006 [Page 29]

Internet-Draft Secure Shell Security Model the LCD for subsequent use.

7) Once the SSH session has been established, the client will invoke
SNMP March 2006

Alternatively, can we let USM perform discovery so we don't have to
attenpt to establish as an SSH connection first? USM is subsystem, as indicated in the mandatory-
to-implement security model, so this could make sense.

3.3.4. Generating an Outgoing "subsystem" parameter.

In order to allow SNMP Message

This section describes the procedure followed traffic to be easily identified and filtered
by firewalls and other network devices, servers associated with SNMP
entities using the Secure Shell Security Model whenever it generates a message containing a
management operation (like a request, a response, a notification, or
a report) on behalf of a user.

The parameters needed are supplied by the Message Processing Model
via MUST default to
providing access to the generateRequestMsg() or "SNMP" SSH subsystem only when the generateResponseMsg() ASI

statusInformation = -- success or errorIndication
generateRequestMsg(
IN messageProcessingModel -- typically, SNMP version
IN globalData -- message header, admin data
IN maxMessageSize -- of SSH
session is established using the sending SNMP entity
IN securityModel -- for IANA-assigned TCP port (TBD by
IANA). Servers SHOULD be configurable to allow access to the outgoing message
IN securityEngineID -- authoritative SNMP entity
IN securityName -- on behalf of this principal
IN securityLevel -- Level of Security requested
IN scopedPDU -- message (plaintext) payload
OUT securityParameters -- filled
SSH subsystem over other ports.

8) Create an entry in by Security Module
OUT wholeMsg -- complete generated message
OUT wholeMsgLength -- length of generated message
OUT a Local Configuration Datastore containing the
provided transportDomain, transportAddress, securityName,
securityLevel, and securityModel, and SSH-speciifc parameters and
create a tmStateReference -- reference to session info
) reference the entry.

Harrington & Salowey Expires September 5, December 10, 2006 [Page 30] 28]

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

statusInformation = -- success or errorIndication
generateResponseMsg(
IN messageProcessingModel -- typically, SNMP version
IN globalData -- message header, admin data
IN maxMessageSize --

9) At this point an implementation MAY perform some type of engineID
discovery to determine a mapping between the sending SNMP entity
IN securityModel -- remote transport
address, SSH session, TMSM session, and a contextEngineID.

The contextEngineID of a remote engine needs to be "discovered" for
use in request messages. USM, the outgoing message
IN securityEngineID -- authoritative SNMP entity
IN securityName -- on behalf of this principal
IN securityLevel -- Level mandatory-to-implement security
model, can perform discovery of Security requested
IN scopedPDU -- message (plaintext) payload
IN securityStateReference -- reference to 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 security state
-- information model.

10) The Local Configuration Datastore may also record implement-
specific information, such as recording the following information:
the remote engine's snmpEngineID
the recipient and sender channels from original
-- request
OUT securityParameters -- filled in by Security Module
OUT wholeMsg -- complete generated message
OUT wholeMsgLength -- length of generated the
SSH_MSG_CHANNEL_OPEN_CONFIRMATION message
OUT tmStateReference -- reference to session info
)

1) verify securityModel = sshsmSecurityModel
determine whether we need
the IP address corresponding to use the hostname
The SSH subsystem that was opened for this session for Request/
Responses ("SNMP"), or for Notifications ("SNMPNotification") or
Reports. [discuss] #34 - how do we determine this? [discuss] #35 -
which subsystem is used for Reports?
2) If there is a securityStateReference, extract ("SNMPNotification").

Return the tmStateReference information from the cachedSecurityData from to the
Request message. At this point, calling module.

4.8. Closing a Session

The Secure Shell Security Model provides the cachedSecurityData can now be
discarded. [todo] clarify which following primitive to
pass data can be discarded.
2b) [todo] #13 - If back and forth between the message is a Response, Security Model and a session never
existed or has been closed, or the Request/Response subsystem
never existed or was closed, then discard SSH
service:

statusInformation =
closeSession(
IN tmStateReference
)

The following describes the message, and
generate procedure to follow to close a Report
3) If there is no securityStateReference, then lookup the session
info indexed by {securityModel, securityName, securityLevel},
between a client and
set tmStateReference.
[todo] insert check for msgflags versus session/transport
characterstics here, and in the transport-mapping portion.
4) If there sever to run SNMP over SSH. This process is no session info for this index, then create an
incomplete tmStateReference indexed
followed by any SNMP engine closing the provided {securityName,
securityLevel}. Store the securityModel and maxMessageSize
information. When the TMSP gets the incomplete tmStateReference,
it will recognize that it needs corresponding SNMP session.

The Secure Shell Security Model identifies which session should be
closed to establish a new session, and
fill in the rest of the information for subsequent use.
5) fill in the securityParameters with SSH client code, using the serialization closeSession() ASI.

5. Overview

This MIB module provides management of a
zero-length OCTET STRING.
6) The wholeMsg is now serialized and then represents the
unauthenticated message being prepared. Secure Shell Security
Model. It defines some needed textual conventions, and some
statistics.

Harrington & Salowey Expires September 5, December 10, 2006 [Page 31] 29]

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

7) The completed message (wholeMsg) with its length
(wholeMsgLength) and securityParameters (a zero-length octet
string) and tmStateReference is returned to

5.1. Structure of the calling MIB Module

Objects in this MIB module
with the statusInformation are arranged into subtrees. Each subtree
is organized as a set to success. of related objects. The Message Processing Model then passes information to the
disptacher for forwarding to the Transport Mapping.

3.3.5. Sending an Outgoing SNMP Message overall structure and
assignment of objects to their subtrees, and the Network

The TMSP portion intended purpose of the Secure Shell Security Model performs the
following tasks:
8) Uses tmStateReference to lookup session information.
9) [todo] verifies that auth
each subtree, is shown below.

5.2. Textual Conventions

Generic and priv Common Textual Conventions used in this document can be provided, as
requested, and error-out if not.
[todo] insert check for msgflags versus session/transport
characterstics here.
10) If the session
found summarized at http://www.ops.ietf.org/mib-common-tcs.html

5.3. The sshsmStats Subtree

This subtree contains SSHSM security-model-dependent counters.

This subtree provides information is incomplete (i.e, has no
tmTransportAddress), then call establishSession() using the
destTransportDomain and destTransportAddress (the output of the
PrepareOutgoingMessage() ASI) for identifying fault conditions
and the securityModel,
securityEngineID, securityName, securityLevel from the
tmStateReference. Store all performance degradation.

5.4. The sshsmsSession Subtree

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

5.5. Relationship to Other MIB Modules

Some management objects defined in the tmStateReference
for subsequent use.
[discuss] #25: Where is the best place other MIB modules are applicable
to call establishSession()?
Note that the whole message an entity implementing SSHSM. In particular, it is completely put together within the
message-processing portion of the security model, in the hopes assumed that a session
an entity implementing SSHSM will be able to be established when implement the message
gets to SNMPv2-MIB [RFC3418],
the transport mapping portion of SNMP-FRAMEWORK-MIB [RFC3411] and the architecture. It TMSM-MIB [I-D.ietf-isms-
tmsm].

This MIB module is
done this way because the RFC3411 arcitecture doesn't pass the
transport addressing info into the security model via messaging
model. It would seem a much more efficient approach for managing SSHSM-specific information.

5.5.1. Relationship to verify
that the session can be established, while still SNMPv2-MIB

The 'system' group in the security
model portion of the messaging model. If we don't establish SNMPv2-MIB [RFC3418] is defined as being
mandatory for all systems, and the
session until we get objects apply to the transport mapping, we've done entity as a lot
whole. The 'system' group provides identification of
work for nothing. And thus far, there is no place to record
failed attempts to establish a session, so an engine doesn't learn
to not try to open a session. In an environment where the SNMP
engine might be a daemon used by multiple applications, an
attacker could use this to cause a denial of service attack at the
NMS. This would likely occur on the NMS side. I don't know if
there's any way to cause it to happen on the agent side. I
suppose a rogue agent with callhome functionality might be able to
cause a denial of service for an NMS by repeatedly requesting
callhome and then refusing the connections.
11) An SSH_MSG_CHANNEL_DATA message is sent, indicating the
recipient channel and encapsulating the wholeMessage.

Harrington & Salowey Expires September 5, 2006 [Page 32]

Internet-Draft Secure Shell Security Model for SNMP March 2006

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

[discuss] #28: For notification tables, how do we predefine the
dynamic session identifiers? We might have a MIB module that records
the session information for subsequent use by the applications and
other subsytems, or it might be passed in the tmStateReference cache.
For notifications, I assume the SNMPv3 notification tables would be a
place to find the address, but I'm not sure how to identify the
presumably-dynamic session identifiers. The MIB module could
identify whether the session was initiated by the remote engine or
initiated by the current engine, and possibly assigned a purpose
(incoming request/response or outgoing notifications).

3.3.6. [todo] Prepare Data Elements from an Incoming SNMP Message

For an incoming message, the TMSP will need to put information from
the transport mechanisms used into the tmStateReference so the MPSP
can extract the information and add it conceptually to the
securityStateReference.

3.3.7. Processing an Incoming SNMP Message

This section describes the procedure followed by an SNMP engine
whenever it receives a message containing a management operation on
behalf of a user.

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. Also, an error indication can
return an OID and value for an incremented counter and optionally a
value for securityLevel, and values for contextEngineID or
contextName for the counter. In addition, the securityStateReference
data is returned if any such information is available at the point
where the error is detected. [todo] this paragraph may no longer be
accurate because of persistent session state information.

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

Harrington & Salowey Expires September 5, 2006 [Page 33]

Internet-Draft Secure Shell Security Model for SNMP March 2006

statusInformation = -- errorIndication or success
-- error counter OID/value if error
processIncomingMsg(
IN messageProcessingModel -- typically, SNMP version
IN maxMessageSize -- of the sending SNMP entity
IN securityParameters -- for the received message
IN securityModel -- for the received message
IN securityLevel -- Level of Security
IN wholeMsg -- as received on the wire
IN wholeMsgLength -- length as received on the wire
OUT securityEngineID -- authoritative SNMP entity
OUT securityName -- identification of the principal
OUT scopedPDU, -- message (plaintext) payload
OUT maxSizeResponseScopedPDU -- maximum size sender can handle
OUT securityStateReference -- reference to security state
) -- information, needed for response

1) If the received securityParameters is not the serialization of an
OCTET STRING formatted according to the SSHsmSecurityParameters, then
the snmpInASNParseErrs counter [RFC3418] is incremented, and an error
indication (parseError) is returned to the calling module. Note that
we return without the OID and value of the incremented counter, which
may be important if this security model supports generating a Report
PDU (which SSHSM doesn't so far), because in this case there is not
enough information to generate a Report PDU.

[todo] check whether this field parses correctly and report errors
through Reports

2) The SSHSM queries the associated SSH engine, in an implementation-
dependent manner, to determine the transport and security parameters
for the received message:
a) the transportDomain and transportAddress
b) tmSecurityName - an identifier for the authenticated entity
c) whether authentication is on or off,
d) whether encryption is on or off,
e) integrity-checking options

3) The securityEngineID to be returned to the caller is determined in
an implementation-dependent manner, such as by using the transport
address to perform a lookup in its Local Configuration Datastore
(LCD). If the securityEngineID is unknown, then an SNMP engine may
perform discovery to create a new entry in its LCD and continue
processing. Note that securityEngineID is required by the SNMPv3
message processing model in RFC 3412 section 7.2 13a)

4) If the information about the message security indicates that the
security options do not match the securityLevel requested by the

Harrington & Salowey Expires September 5, 2006 [Page 34]

Internet-Draft Secure Shell Security Model for SNMP March 2006

caller, then the SSHsmStatsUnsupportedSecLevels counter is
incremented and an error indication (unsupportedSecurityLevel)
together with the OID and value of the incremented counter is
returned to the calling module.

5) The scopedPDU component is assumed to be in plain text and is the
message payload to be returned to the calling module.

7) The maxSizeResponseScopedPDU is calculated. This is the maximum
size allowed for a scopedPDU for a possible Response message.
Provision is made for a message header that allows the same
securityLevel as the received Request.

10) Information about the value of tmSecurityName is extracted from
the Local Configuration Datastore (LCD) to provide conversion from
the SSH authentication-method-specific tmSecurityName to a model-
independent securityName. If no information is available for the
username in the LCD, then the securityName is set to the username
associated with the session.

11) The security data is cached as cachedSecurityData, so that a
possible response to this message can and will use the same
authentication and privacy parameters. Information to be saved/
cached is as follows: [todo] copy from the "Passing Security
Parameters" section above.
transportDomain, transportAddress
securityEngineID
SSH username,
auth options
encryption options
Integrity checking options

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

3.4. Overview

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

Harrington & Salowey Expires September 5, 2006 [Page 35]

Internet-Draft Secure Shell Security Model for SNMP March 2006

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

3.5.2. The sshsmStats Subtree

This subtree contains SSHSM security-model-dependent counters.

This subtree provides information for identifying fault conditions
and performance degradation.

3.5.3. The sshsmsSession Subtree

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

3.5.4. Relationship to Other MIB Modules

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

This MIB module is for managing SSHSM-specific information.

3.5.4.1. Relationship to the SNMPv2-MIB

The 'system' group in the SNMPv2-MIB [RFC3418] is defined as being
mandatory for all systems, and the objects apply to the entity as a
whole. The 'system' group provides identification of the management
entity and certain other system-wide data. The SSHSM-MIB does not
duplicate those objects.

3.5.4.2. Relationship to the TMSM-MIB

The 'tmsmSession' group in the TMSM-MIB [I-D.ietf-isms-tmsm] is
defined as being applicable to all Transport-Mapping Security Models
that use sessions.

3.5.4.3. MIB Modules Required for IMPORTS

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

Harrington & Salowey Expires September 5, 2006 [Page 36]

Internet-Draft Secure Shell Security Model for SNMP March 2006

3.6. MIB module definition

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

SSHSM-MIB DEFINITIONS ::= BEGIN

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

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

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

Juergen Schoenwaelder
International University Bremen
Campus Ring 1
28725 Bremen
Germany
+49 421 200-3587

Harrington & Salowey Expires September 5, 2006 [Page 37]

Internet-Draft Secure Shell Security Model for SNMP March 2006

j.schoenwaelder@iu-bremen.de

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

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

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

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

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

-- ---------------------------------------------------------- --
-- subtrees in the SSHSM-MIB
-- ---------------------------------------------------------- --

sshsmNotifications OBJECT IDENTIFIER ::= { sshsmMIB 0 }
sshsmObjects OBJECT IDENTIFIER ::= { sshsmMIB 1 }
sshsmConformance OBJECT IDENTIFIER ::= { sshsmMIB 2 }

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

Harrington & Salowey Expires September 5, 2006 [Page 38]

Internet-Draft Secure Shell Security Model for SNMP March 2006

TransportAddressSSH ::= TEXTUAL-CONVENTION
DISPLAY-HINT "1a"
STATUS current
DESCRIPTION
"[discuss] Represents either a hostname encoded in ASCII
using the IDNA protocol [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
address is of type TransportAddressSSH."
::= { snmpDomains xxxx }
-- RFC Ed.: replace xxxx with IANA-assigned number and
-- remove this note

sshsmPasswordAuthProtocol OBJECT-IDENTITY
STATUS current

Harrington & Salowey Expires September 5, 2006 [Page 39]

Internet-Draft Secure Shell Security Model for SNMP March 2006

DESCRIPTION "The Secure Shell Password Authentication Method"
REFERENCE "RFC 4252"

::= { snmpAuthProtocols 4 }

sshsmPublickeyAuthProtocol OBJECT-IDENTITY
STATUS current
DESCRIPTION "The Secure Shell Public Key Authentication Method"
REFERENCE "RFC 4252"

::= { snmpAuthProtocols 5 }

sshsmHostbasedAuthProtocol OBJECT-IDENTITY
STATUS current
DESCRIPTION "The Secure Shell Host-based Authentication Method"
REFERENCE "RFC 4252"

::= { snmpAuthProtocols 6 }

sshsmAESPrivProtocol OBJECT-IDENTITY
STATUS current
DESCRIPTION "The AES Encryption Protocol."
::= { snmpPrivProtocols 5 }

-- Statistics for the Secure Shell Security Model

sshsmStats OBJECT IDENTIFIER ::= { sshsmObjects 1 }

-- [todo] do we need any of these? or other stats?

sshsmStatsUnsupportedSecLevels OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The total number of packets received by the SNMP
engine which were dropped because they requested a
securityLevel that was unknown the management
entity and certain other system-wide data. The SSHSM-MIB does not
duplicate those objects.

5.5.2. Relationship to the SNMP engine
or otherwise unavailable. SNMP-FRAMEWORK-MIB

[todo] we should never hit any of
these because they should never be sent by the remote
SNMP engine if an appropriate session the SSHSM-MIB does not exist.
We also do not know what was requested by the remote
session.
"
::= { sshsmStats 1 } actually have dependencies on SNMP-
FRAMEWORK-MIB other than imports, then remove this paragraph.

Harrington & Salowey Expires September 5, December 10, 2006 [Page 40] 30]

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

sshsmStatsUnknownUserNames OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The total number of packets received by the SNMP
engine which were dropped because they referenced a
user that was not known

5.5.3. Relationship to the SNMP engine.

[discuss] In SSHSM, we do no preconfiguration, so we
don't know any SSH users. If authentication is based on
principals defined TMSM-MIB

The 'tmsmSession' group in the SSH authentication, if the user TMSM-MIB [I-D.ietf-isms-tmsm] is not known by SSH, the message wouldn't reach the SNMP
engine, so this count would always be zero.
"
::= { sshsmStats 3 }

sshsmStatsUnknownEngineIDs OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The total number of packets received by the SNMP
engine which were dropped because they referenced an
snmpEngineID that was not known
defined as being applicable to the SNMP engine.

[todo] We don't all Transport-Mapping Security Models
that use sessions. [todo] if the engineID during authentication,
encryption, or integrity checking, so there is never an error
condition related to unknown securityEngineID. (But check
the RFC3413 and the RFC3584 SSHSM-MIB does not actually have
dependencies on knowing the
securityEngineID.)
"
::= { sshsmStats 4 }

-- TMSM-MIB other than imports, then remove this
paragraph.

5.5.4. MIB Modules Required for IMPORTS

The sshsmSession Group

sshsmSession OBJECT IDENTIFIER ::= { sshsmObjects 2 }

sshsmSessionSpinLock OBJECT-TYPE
SYNTAX TestAndIncr
MAX-ACCESS read-write
STATUS current
DESCRIPTION "An advisory lock used following MIB module imports items from [RFC2578], [RFC2579],
[RFC2580], [RFC3411], [RFC3419], and [I-D.ietf-isms-tmsm]

This MIB module also references [RFC3490]

6. MIB module definition

** Is AES the only officially required to allow several cooperating
Command Generator Applications support SSH encryption **
mechanisms? It seems RFC 4344 has much more to coordinate their
use of facilities offer. BTW, is it **
useful to create sessions export all this information in an SSHSM MIB module? Some
** of the
usmUserTable.
" stuff seems generic SSH...

SSHSM-MIB DEFINITIONS ::= { sshsmSession 1 } BEGIN

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

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

Chairs:
Juergen Quittek
NEC Europe Ltd.

Harrington & Salowey Expires September 5, December 10, 2006 [Page 41] 31]

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

sshsmSessionTable OBJECT-TYPE
SYNTAX SEQUENCE OF SshsmSessionEntry
MAX-ACCESS not-accessible
STATUS current

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

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

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

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

Copyright (C) The Internet Society (2006). This
version of currently available sessions configured
in this MIB module is part of RFC XXXX;
see the SNMP engine's Local Configuration Datastore
(LCD) RFC itself for SNMP over SSH sessions.

Sessions are created as needed, and do not persist
across network management system reboots.
"
::= { sshsmSession 2 }

sshsmSessionEntry OBJECT-TYPE
SYNTAX SshsmSessionEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "A session configured in the SNMP engine's Local
Configuration Datastore (LCD) full legal notices.
-- NOTE to RFC editor: replace XXXX with actual RFC number
-- for the Secure Shell
Security Model. this document and remove this note
"
INDEX { sshsmSessionID }
::= { sshsmSessionTable 1 }

SshsmSessionEntry ::= SEQUENCE
{
sshsmSessionID Integer32,
sshsmTMSMSession tmsmSessionID,
sshsmSessionTDomain transportDomain,
sshsmSessionTAddress transportAddress,
sshsmSessionUserName SnmpAdminString,
sshsmSessionSecurityName SnmpAdminString,
sshsmSessionSecurityLevel SnmpSecurityLevel
}

sshsmSessionID OBJECT-TYPE
SYNTAX Integer32 (1..65535)
MAX-ACCESS not-accessible
STATUS current

REVISION "200509020000Z" -- 02 September 2005
DESCRIPTION "A locally-unique identifier "The initial version, published in RFC XXXX.
-- NOTE to RFC editor: replace XXXX with actual RFC number
-- for a session. this document and remove this note
"

::= { sshsmSessionEntry 1 mib-2 xxxx }

sshsmSessionID OBJECT-TYPE
SYNTAX Integer32 (1..65535)
MAX-ACCESS not-accessible
STATUS current
-- RFC Ed.: replace xxxx with IANA-assigned number and

Harrington & Salowey Expires September 5, December 10, 2006 [Page 42] 32]

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

DESCRIPTION "A locally-unique identifier for a TMSM session.

This is

-- remove this note

-- ---------------------------------------------------------- --
-- subtrees in the associated tmsmSessionID from TMSM-MIB.
" SSHSM-MIB
-- ---------------------------------------------------------- --

sshsmNotifications OBJECT IDENTIFIER ::= { sshsmSessionEntry 2 sshsmMIB 0 }

sshsmSessionTDomain OBJECT-TYPE
SYNTAX TransportDoaminSSH
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The transport domain associated with this session.
"
sshsmObjects OBJECT IDENTIFIER ::= { sshsmSessionEntry 3 sshsmMIB 1 }

sshsmSessionTAddress OBJECT-TYPE
SYNTAX
sshsmConformance OBJECT IDENTIFIER ::= { sshsmMIB 2 }

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

TransportAddressSSH
MAX-ACCESS read-only ::= TEXTUAL-CONVENTION
DISPLAY-HINT "1a"
STATUS current
DESCRIPTION "The
"Represents either a hostname encoded in ASCII
using the IDNA protocol, as specified in RFC3490, followed by
a colon ':' (ASCII character 0x3A) and port, a decimal port number
in ASCII, or the transport an IP address
associated with this session.
"
::= { sshsmSessionEntry 4 }

sshsmSessionUserName OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-only
STATUS current
DESCRIPTION "A human readable string representing the principal followed by a colon ':'
(ASCII character 0x3A) and a decimal port number in Security Model dependent format, such as the
the user ASCII.
The name used in the
SSH-USERAUTH-REQUEST message 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 a successful
authentication.
"
::= { sshsmSessionEntry 5 }

sshsmSessionSecurityName OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-only
STATUS current
DESCRIPTION "A human readable string representing handling errors if such values are
not supported, or cannot be resolved (if resolution occurs
at the principal
in Security Model independent format.

The default transformation time of the Secure Shell
Security Model dependent security ID management operation).

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

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

When this textual convention is the same used as a syntax of an
index object, there may be issues with the SSH user name.
" 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."

Harrington & Salowey Expires September 5, December 10, 2006 [Page 43] 33]

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

::= { sshsmSessionEntry 6 }

sshsmSessionSecurityLevel OBJECT-TYPE

SYNTAX SnmpSecurityLevel
MAX-ACCESS read-only OCTET STRING (SIZE (1..255))

transportDomainSSH OBJECT-IDENTITY
STATUS current
DESCRIPTION
"The Level SSH transport domain. The corresponding transport
address is of Security at which type TransportAddressSSH.

When an SNMP messages can entity uses the transportDomainSSH transport
mapping, it must be sent using this session, in particular, one of:

noAuthNoPriv - without authentication and
without privacy,
authNoPriv - with authentication but
without privacy,
authPriv - with authentication capable of accepting messages up to
and
with privacy.
"
DEFVAL including 8192 octets in size. Implementation of
larger values is encouraged whenever possible."
::= { authPriv snmpDomains xxxx }
-- RFC Ed.: replace xxxx with IANA-assigned number and
-- remove this note

-- Statistics for the Secure Shell Security Model

sshsmStats OBJECT IDENTIFIER ::= { sshsmSessionEntry 7 sshsmObjects 1 }

-- [todo] do we need any stats?

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

sshsmGroups OBJECT IDENTIFIER ::= { sshsmConformance 1 }

sshsmCompliances OBJECT IDENTIFIER ::= { sshsmConformance 2 }

-- -------------------------------------------------------------
-- Units of conformance
-- -------------------------------------------------------------
sshsmGroup OBJECT-GROUP
OBJECTS {
sshsmStatsUnsupportedSecLevels,
sshsmStatsUnknownUserNames,
sshsmStatsUnknownEngineIDs,
sshsmSessionTMSession,
sshsmSessionTDomain,
sshsmSessionTAddress,
sshsmSessionTransportDomain,
sshsmSessionAddress,
sshsmSessionUserName,
sshsmSessionSecurityName,
sshsmSessionSecurityLevel,
sshsmSessionAuthProtocol,
sshsmSessionPrivProtocol,
sshsmSessionEngineID,
sshsmSessionPrivProtocol,

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

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

Internet-Draft Secure Shell Security Model for SNMP June 2006

::= { sshsmGroups 2 }

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

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

END

7. Security Considerations

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

SSHSM relies on SSH mutual authentication, binding of keys,
confidentiality and integrity. Any authentication method that meets
the requirements of 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 SSHSM.

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

SSHSM 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. SSHSM simply trusts that these are properly
cvonfigured by the implementer and deployer.

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

Harrington & Salowey Expires September 5, December 10, 2006 [Page 44] 35]

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

sshsmSessionSpinLock
}
STATUS current
DESCRIPTION "A collection

which has the effect of objects for maintaining session
information not authenticating the ssh client to the ssh
server. Doing this does not compromise authentication of an SNMP engine which implements the
SNMP Secure Shell Security Model.
"

::= { sshsmGroups 2 }

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

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

END

3.7. Implementation Considerations

[discuss] #27: The SNMP over TCP Transport Mapping document
[RFC3430]says that TCP connections ssh client, nor does it compromise data confidentiality
or data integrity.

SSH supports anonymous access. If SSHSM can extract from SSH an
authenticated principal to map to securityName, then anonymous access
SHOULD be recreated dynamically or
kept supported. It is possible for future use and actually leaves all that 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
mapping. Do we need protocol
and provide an authenticated principal for mapping to discuss these issues? Where?

3.8. Security Considerations

This document describes a security model that would securityName
for access control purposes.

The RFC 3411 architecture does not permit SNMP noAuthPriv. SSHSM should
not be used with an SSH connection with the "none" userauth method.

7.2. skipping public key verification

Most key exchange algorithms are able to
utilize SSH security services. [todo] expand as needed.

SSHSM relies on authenticate the SSH mutual authentication, binding
server's identity to the client. However, for the common case of DH
signed by public keys,
confidentiality this requires the client to know the host's
public key a priori and integrity. Any authentication method to verify that meets the requirements correct key is being used.
If this step is skipped, then authentication of the SSH architecture will provide ssh server to the properties
ssh client is not done. Data confidentiality and data integrity
protection to the server still exist, but these are of mutual authentication dubious value
when an attacker can insert himself between the client and binding the real
ssh server. Note that some userauth methods may defend against this
situation, but many of keys. While SSH does support
turning off confidentiality the common ones (including password and integrity, they SHOULD
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 turned
off when used configured to skip public key verification for use
with SSHSM.

SSHv2 the SSHSM security model.

7.3. the 'none' MAC algorithm

SSH provides Perfect Forward Security (PFS) for encryption keys.
PFS is a major design goal of SSH, and any well-designed keyex 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 will provide it. for use
with the SSHSM security model.

Harrington & Salowey Expires September 5, December 10, 2006 [Page 45] 36]

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

[todo] We will probably need to discuss the

7.4. MIB module security implications of
password based authentication methods.

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.

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), 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], [RFC3410] section 8), including
full support for the SNMPv3 USM and SSHSM 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

Harrington & Salowey Expires September 5, 2006 [Page 46]

Internet-Draft Secure Shell Security Model for SNMP March 2006
the objects only to those principals (users) that have legitimate
rights to indeed GET or SET (change/create/delete) them.

3.9.

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

Internet-Draft Secure Shell Security Model for SNMP June 2006

8. 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 SSH sessions as defined in this
document,
2. an SMI number under mib-2, for the MIB module in this document,
3. an SnmpSecurityModel for the Secure Shell Security Model, as
documented in the MIB module in this document,
4. "snmp" as an SSH Service Name in the
http://www.iana.org/assignments/ssh-parameters registry.

3.10.

9. Acknowledgements

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

10. References

4.1.

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

Harrington & Salowey Expires September 5, December 10, 2006 [Page 47] 38]

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

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

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

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

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

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

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

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

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

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

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

[I-D.ietf-isms-tmsm]
Harrington, D. and J. Schoenwaelder, "Transport Mapping
Security Model (TMSM) Architectural Extension for the
Simple Network Management
Protocol", draft-ietf-isms-tmsm-00 Protocol (SNMP)",

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

Internet-Draft Secure Shell Security Model for SNMP June 2006

draft-ietf-isms-tmsm-02 (work in progress),
October 2005.

4.2. May 2006.

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

[RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple Network Applicability Statements for Internet-
Standard Management Protocol (SNMP) Applications", STD 62, Framework", RFC 3413, 3410, December 2002.

[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.

Harrington & Salowey Expires September 5, 2006 [Page 48]

Internet-Draft Secure Shell Security Model for SNMP March 2006
Arkko, "Diameter Base Protocol", RFC 3588, September 2003.

[I-D.ietf-netconf-prot]
Enns, R., "NETCONF Configuration

[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",
draft-ietf-netconf-prot-11 (work in progress),
February 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-05 (work in progress),
October 2005.

[I-D.ietf-secsh-gsskeyex]
Hutzelman, J., "GSSAPI Authentication and Key Exchange for
the Secure Shell Protocol", draft-ietf-secsh-gsskeyex-10
draft-ietf-netconf-ssh-06 (work in progress), August 2005. March 2006.

Appendix A. Open Issues

We need to reach consensus on some issues. I numbered

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

The MIB module needs to be defined.

Consistency with TMSM needs to be done (TMSM needs some changes due
to changes in SSHSM)

A.1. Closed Issues

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

#2: a) is server authentication a requirement that SNMP will require
of the text for easy correlation client? yes. b) how can we verify that server authentication
was performed, or do we take simply trust the SSH client layer to
perform such authentication? we trust the issue discussions.
*** When discussing these issues, please use SSH layer to provide such

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

Internet-Draft Secure Shell Security Model for SNMP June 2006

auithentication. c) for the provided # in common case of DH signed by public keys,
how does the
subject line, client learn the host's public key in advance, and please limit
verify that the message to one topic at a time.
***

Here correct key is the current list being used? this is out of issues from the SSHSM scope for
this document where we
need to reach consensus.

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

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

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

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

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

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

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

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

Harrington & Salowey Expires September 5, 2006 [Page 49]

Internet-Draft Secure Shell Security Model for SNMP March 2006

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

#12: a) how does SSHSM determine whether SSH can provide the security
services requested in msgFlags? It doesn't. B) There were
discussions about whether it was acceptable for a transport-
mapping-model transport-mapping-

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

Internet-Draft Secure Shell Security Model for SNMP June 2006

model to provide stronger security than requested. Does this need to
be discussed in the SSHSM document, or should we discuss this in the TMSM document? c) when sending a message into
an environment where encryption is not legal, how do we ensure
that encryption is not provided?
TMSM document? Both. c) when sending a message into an environment
where encryption is not legal, how do we ensure that encryption is
not provided? The Danvers Doctrine seems to indicate this in not
necessary to discuss.

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

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

#15: What data needs to be stored in the tmStateReference, and how
does SSHSM get the information from SSH, for the various
authentication and transport options?
#16 B) passing a securityname might be useful for passing as a
hint to RADIUS or other authorization mechanism to indicate which
identity we want to use when doing access control, and RADIUS,etc.
can tell us whether the username being authenticated is allowed to
be mapped to that authorization/accounting identity. Should we
provide securityname when establishing a session, so the
authentication machanisms can use it as a hint?
#17: I believe somebody suggested we require mutual
authentication. I'm not sure I understand

#16: The SSH server doesn't necessarily authorize the edits.
#21: we need to determine what data should be persistent and
stored name carried in
the LCD for notification purposes.
#22: Joe: There are SSH_MSG_USERAUTH_REQUEST message, but may return a significant number different name
or list of security problems
associated with mapping to a transport address which may need names that are authorized to be discussed in the security considerations section.
#23: We need to discuss used given the circumstances under which a session
should be closed, and how an SNMP engine should determine if, and
respond if
authentication of the SSH session is closed by other means
#24: How should we enable auto-discovery?
#25: Where provided username. Resolution: this is
mistaken; the best place to call establishSession()? See the
"Sending an Outgoing Message to username from the Network" section for more
details on this issue.
#26: According to RFC 3411, section 4.1.1, SSH_MSG_USERAUTH_REQUEST SHOULD be
used. A) What should be the application
provides source of the transportDomain and transportAddress SSHSM mechanism-specific
username for mapping to securityname? Resolution: the PDU
dispatcher via username from
the sendPDU() primitive. If we permit multiple
sessions per transportAddress, then SSH_MSG_USERAUTH_REQUEST SHOULD be used.

#16 B) passing a securityName might be useful for passing as a hint
to RADIUS or other authorization mechanism to indicate which identity
we would need want to define how
session identifiers get passed from use when doing access control, and RADIUS,etc. can tell us
whether the application username being authenticated is allowed to the PDU
dispatcher (and then be mapped to the MP model).
#27: The SNMP over TCP Transport Mapping document (RFC3430) says
that TCP connections authorization/accounting identity. Should we provide
securityName when establishing a session, so the authentication
machanisms can be recreated dynamically or kept for
future use it as a hint? SSHSM provides securityName/Model/
Level and actually leaves all that tranport; whether SSH passes this to the transport mapping.
Do RADIUS is out of scope
for this document.

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

#18: I currently have multiple sections, one for each known auth
mechanism. We need to discuss these issues? Where? in the security
considerations?
#28: For notification tables, how do we predefine the dynamic
session identifiers?
#31: Is maxSizeResponseScopedPDU relevant? Can it parameters that need to be calculated
once cached
for the session? Do each, and determine whether we need to take can collapse this into consideration the
SSH window size? one
section. a) Using Passwords to Authenticate SNMP Principals B) Using
Public keys to Authenticate SNMP Principals C) Using Host-based
Authentication of SNMP Principals Resolution: I will collapse this
later, after we have verified we have considered all current/likely

Harrington & Salowey Expires September 5, December 10, 2006 [Page 50] 42]

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

#33: does

scenarios. Done.

#19: RADIUS is just an instance of the mib need password authentication
protocol. The details of RADIUS are within the SSH layer. I don't
think it is a good idea to expose this outside of SSH. Resolution:
If possible, the details of RADIUS should not be writable, so sessions can be
preconfigured, such as for callhome, or would it exposed in SSHSM.
There may be populated at
creation time by an issue with receiving authorization without exposing
the underlying instrumentation, and not writable
by SNMP?
[discuss] #34 - how details.

#20: How do we determine whether a PDU contains a
Request /Responseor a Notification? ** Reports are a reaction get the mapping from model-specific identity to a
previously received message and thus they go wherever the previous
message triggering
model independent securityName?. Resolution: Implementation-
dependent, both in the report came from.
[discuss] #35 - which subsystem is used case of extracting tmSecurityname from SSH for Reports?
[todo] We
an incoming message, and for providing an LCD mapping.

#21: we need to define somewhere determine what the max message size is
that needs to data should be supported over the SSH transport. RFC 3430 says persistent and stored
in 2.2 that implementations have to support 8192 octets...

A.1. Issues the LCD for notification purposes.

#22: Joe: There are a significant number of security problems
associated with Resolutions nearing Consensus

A.2. Closed Issues

#1: is it important mapping to support anonymous user access a transport address which may need to SNMP? be
discussed in the security considerations section. Resolution: add a
transporttype for hostname.

#23: We need to discuss the circumstances under which a session
should be closed, and how an SNMP engine should support whatever authorizations are provided by
SSH; determine if, and
respond if the SSH supports anonymous access, session is closed by other means, See TMSM, and SSHSM can extract a
username, then it
implementation-dependent.

#24: How should be supported.

#2: a) we enable auto-discovery?

#25: Where is server authentication a requirement the best place to call openSession()? Note that SNMP will require the
whole message is completely put together within the message-
processing portion of the client? b) how can we verify security model, in the hopes that server authentication was
performed, or do we take simply trust a session
will be able to be established when the SSH client layer message gets to perform
such authentication? c) for the common case transport
mapping portion of DH signed by public
keys, how does the client learn architecture. It is done this way because the host's public key in advance, and
RFC3411 arcitecture doesn't pass the transport addressing info into
the security model via messaging model. It would seem a much more
efficient approach to verify that the correct key is being used?

#8: Do we need a mapping between session can be established,
while still in the SSH key (or other SSH engine
identifier) and SNMP engineID? What happens if an agent "spoofs"
another engineID, and an NMS perfoms a SET security model portion of sensitive parameters to the agent? Resolution: messaging model. If
we do not need don't establish the session until we get to address this for local SSH
and local snmpEngineID, unless smebody can show the transport mapping,
we've done a use case
requirement. There lot of work for nothing. And thus far, there is likely no
place to be a need record failed attempts to map, in establish a session, so an
implementation-dependent manner, the remote engineIDs with the
associated SSH host (mapping of engineID/transport address/host key).

#11: If we eliminate all msgSecurityParameters, should the
msgSecurityParameters field in the SNMPv3 message simply be engine
doesn't learn to not try to open a zero-
length OCTET STRING, or should it be session. In an ASN.1 NULL? It MUST environment where
the SNMP engine might be a
BER-encoded OCTET STRING

#13: will SSHSM be impacted daemon used by keychanges multiple applications, an
attacker could use this to cause a denial of service attack at the SSH local datastore?
Resolution: if the session is closed whe the Response is being
prepared, discard
NMS. This would likely occur on the Response.

#14: MUST NMS side. I don't know if
there's any way to cause it to happen on the SSHSM model provide mutual authentication agent side. I suppose a
rogue agent with callhome functionality might be able to cause a
denial of the client service for an NMS by repeatedly requesting callhome and

Harrington & Salowey Expires September 5, December 10, 2006 [Page 51] 43]

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

and server, and MUST it authenticate, integrity-check, and encrypt
the messages? Resolution: yes.

#16: The SSH server doesn't necessarily authorize the name carried in
the SSH_MSG_USERAUTH_REQUEST message, but may return a different name
or list of names that are authorized to be used given the
authentication of

then refusing the provided username. connections. Resolution: this is
mistaken; the username called from TMSP.

#26: According to RFC 3411, section 4.1.1, the SSH_MSG_USERAUTH_REQUEST SHOULD be
used. A) What should be the source of the SSHSM mechanism-specific
username for mapping application provides
the transportDomain and transportAddress to securityname? Resolution: the username from PDU dispatcher via
the SSH_MSG_USERAUTH_REQUEST SHOULD be used.

#18: I currently have sendPDU() primitive. If we permit multiple sections, one for each known auth
mechanism. We sessions per
transportAddress, then we would need to discuss define how session
identifiers get passed from the parameters that need application to the PDU dispatcher
(and then to the MP model).Resolution: applications do not know about
sessions.

#27: The SNMP over TCP Transport Mapping document [RFC3430] says that
TCP connections can be cached recreated dynamically or kept for each, future use
and determine whether we can collapse this into one
section. a) Using Passwords to Authenticate SNMP Principals B) Using
Public keys actually leaves all that to Authenticate SNMP Principals C) Using Host-based
Authentication of SNMP Principals Resolution: I will collapse this
later, after the transport mapping. Do we have verified need to
discuss these issues? Where? in the security considerations? See
TMSM.

#28: For notification tables, how do we predefine the dynamic session
identifiers? We might have considered all current/likely
scenarios.

#19: RADIUS is just an instance of a MIB module that records the password authentication
protocol. The details of RADIUS are within session
information for subsequent use by the SSH layer. I don't
think applications and other
subsytems, or it is might be passed in the tmStateReference cache. For
notifications, I assume the SNMPv3 notification tables would be a good idea
place to expose this outside of SSH. Resolution:
If possible, find the details of RADIUS should address, but I'm not be exposed in SSHSM.
There may be an issue with receiving authorization without exposing sure how to identify the
presumably-dynamic session identifiers. The MIB module could
identify whether the details.

#20: How do we get session was initiated by the mapping from model-specific identity to remote engine or
initiated by the current engine, and possibly assigned a
model independent securityName?. purpose
(incoming request/response or outgoing notifications).. Resolution: Implementation-
dependent, both in the case of extracting tmSecurityname from SSH for
an incoming message,
applications do not know about sessions, only transport and for providing an LCD mapping.
securityN/M/L; if separate sessions are desired, then they can be
differentiated by transport and securityN/M/L parameters.

#29: do we need to support reports? For what purpose? Yes, reports
are used from application processing and for contextEngine discovery.

#30: If we actually do not extract anything from securityParameters,
do we need to check whether this field parses correctly? It
apparently parsed well enough to pass the parse test in the messaging
model. Could we simply ignore the securityParameters being passed
in? The only argument I see for checking to ensure this is empty is
to ensure somebody isn't using the filed for non-standard purposes,
such as passing a virus in the field. If we do check it, do we need
to report it through Reports? Resolution: yes; it won't hurt it through Reports? Resolution: yes; it won't hurt to
check it.

#32: For an incoming message (Processing an Incoming Message section
10), is using a default securityName mapping the right thing to do?
Resolution: Yes, it is the right thing to do.

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

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

Internet-Draft Secure Shell Security Model for SNMP June 2006

for the session? Do we need to take into consideration the SSH
window size? Resolution: It can probably be calculated once per
session.

#33: does the mib need to be writable, so sessions can be
preconfigured, such as for callhome, or would it be populated at
creation time by the underlying instrumentation, and not writable by
SNMP? This is about the session table, which has been moved to TMSM.

[discuss] #34 - how do we determine whether a PDU contains a Request
/Response or a Notification? By configuring the securityName or the
transport parameters.

[discuss] #35 - which subsystem is used for Reports? ** Reports are a
reaction to a previously received message and thus they go wherever
the previous message triggering the report came from.

Appendix B. Change Log

"From -02- to
check it.

#32: For an incoming message (Processing an Incoming Message -03-"

rewrote almost all sections
merged ASI section
10), is using and Elements of Procedure sections
removed references to the SSH user, in preference to SSH client
updated references
creayted a default securityName conventions section to identify common terminology.
rewrote sections on how SSH addresses threats
rewrote mapping SSH to engineID
eliminated discovery section
detailed the right thing Elements of Procedure
eliminated secrtions on msgFlags, transport parameters
resolved issues of opening notifications
eliminated sessionID (TMSM needs to do? be updated to match)
eliminated use of tmsmSessiontable 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 architecural
extension
updated conventions

Harrington & Salowey Expires September 5, December 10, 2006 [Page 52] 45]

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

Resolution: Yes, it is

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 right thing roles of MPSP and TMSP
clarified how snmpv3 message parts are ised by SSHSM
modified nesting of subsections as needed
securityLevel used by SSHSM 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 do.

Appendix B. Change Log 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
ran the mib module through smilint

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

Authors' Addresses

David Harrington
Futurewei
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

Full Copyright Statement

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

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

Harrington & Salowey Expires September 5, 2006 [Page 53]

Internet-Draft Secure Shell Security Model for SNMP March 2006
"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 currently provided by the
Internet Society.

Harrington & Salowey Expires September 5, December 10, 2006 [Page 54] 47]

----