Network Working Group D. Harrington
Internet-Draft Effective Software
Expires: April 17, 2006 J. Schoenwaelder
International University Bremen
J. Salowey
Cisco Systems
October 14, 2005
Secure Shell Security Model for SNMP
draft-ietf-isms-secshell-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 17, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This memo describes a Security Model for the Simple Network
Management Protocol, using the Secure Shell protocol within a
Transport Mapping.
Harrington, et al. Expires April 17, 2006 [Page 1]
Internet-Draft Secure Shell Security Model for SNMP October 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. The Internet-Standard Management Framework . . . . . . . . 6
1.3. The Secure Shell Protocol . . . . . . . . . . . . . . . . 6
1.4. Constraints . . . . . . . . . . . . . . . . . . . . . . . 7
1.5. Conventions . . . . . . . . . . . . . . . . . . . . . . . 7
2. How SSHSM Fits into the TMSM Architecture . . . . . . . . . . 7
2.1. Security Capabilities of this Model . . . . . . . . . . . 8
2.1.1. Threats . . . . . . . . . . . . . . . . . . . . . . . 8
2.1.2. Sessions . . . . . . . . . . . . . . . . . . . . . . . 11
2.1.3. Authentication Protocol . . . . . . . . . . . . . . . 12
2.1.4. Privacy Protocol . . . . . . . . . . . . . . . . . . . 12
2.1.5. Protection against Message Replay, Delay and
Redirection . . . . . . . . . . . . . . . . . . . . . 12
2.1.6. Security Protocol Requirements . . . . . . . . . . . . 13
2.2. Security Parameter Passing Requirement . . . . . . . . . . 15
2.3. Requirements for Notifications . . . . . . . . . . . . . . 15
2.4. Scenario Diagrams . . . . . . . . . . . . . . . . . . . . 16
2.4.1. Command Generator or Notification Originator . . . . . 16
2.4.2. Command Responder . . . . . . . . . . . . . . . . . . 17
3. RFC 3411 Abstract Service Interfaces . . . . . . . . . . . . . 18
3.1. Public Abstract Service Interfaces . . . . . . . . . . . . 19
3.1.1. Public ASIs for Outgoing Messages . . . . . . . . . . 19
3.1.2. Public ASIs for Incoming Messages . . . . . . . . . . 21
3.2. Private Abstract Service Interfaces . . . . . . . . . . . 23
4. SNMP Messages Using this Security Model . . . . . . . . . . . 23
4.1. SNMPv1 and SNMPv2c Messages Using this Security Model . . 23
4.2. SNMPv3 Messages Using this Security Model . . . . . . . . 24
4.2.1. msgGlobalData . . . . . . . . . . . . . . . . . . . . 26
4.3. Passing Security Parameters . . . . . . . . . . . . . . . 27
4.3.1. Transport Session Parameters . . . . . . . . . . . . . 28
4.3.2. [discuss] Using Passwords to Authenticate SNMP
Principals . . . . . . . . . . . . . . . . . . . . . . 29
4.3.3. [discuss] Using Public keys to Authenticate SNMP
Principals . . . . . . . . . . . . . . . . . . . . . . 29
4.3.4. [discuss] Using Host-based Authentication of SNMP
Principals . . . . . . . . . . . . . . . . . . . . . . 29
4.3.5. [discuss] Using RADIUS to Authenticate SNMP
Principals . . . . . . . . . . . . . . . . . . . . . . 30
4.3.6. securityStateReference for SSHSM . . . . . . . . . . . 30
4.4. MIB Module for SSH Security Model . . . . . . . . . . . . 30
4.5. [todo] Notifications . . . . . . . . . . . . . . . . . . . 31
5. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 31
5.1. Establishing a Session . . . . . . . . . . . . . . . . . . 31
5.2. Closing a Session . . . . . . . . . . . . . . . . . . . . 34
5.3. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 34
Harrington, et al. Expires April 17, 2006 [Page 2]
Internet-Draft Secure Shell Security Model for SNMP October 2005
5.4. Generating an Outgoing SNMP Message . . . . . . . . . . . 35
5.5. Sending an Outgoing SNMP Message to the Network . . . . . 36
5.6. [todo] Prepare Data Elements from an Incoming SNMP
Message . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.7. Processing an Incoming SNMP Message . . . . . . . . . . . 38
6. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
7. Structure of the MIB Module . . . . . . . . . . . . . . . . . 41
8. MIB module definition . . . . . . . . . . . . . . . . . . . . 41
9. Security Considerations . . . . . . . . . . . . . . . . . . . 49
9.1. Sensitive Modifiable Objects . . . . . . . . . . . . . . . 49
9.2. Sensitive Readable Objects . . . . . . . . . . . . . . . . 50
9.3. Protocol Security . . . . . . . . . . . . . . . . . . . . 50
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 50
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 51
12.1. Normative References . . . . . . . . . . . . . . . . . . . 51
12.2. Informative References . . . . . . . . . . . . . . . . . . 52
Appendix A. Open Issues . . . . . . . . . . . . . . . . . . . . . 53
Appendix B. Change Log from the first revision of -00- . . . . . 55
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 55
Intellectual Property and Copyright Statements . . . . . . . . . . 56
Harrington, et al. Expires April 17, 2006 [Page 3]
Internet-Draft Secure Shell Security Model for SNMP October 2005
1. Introduction
This memo describes a Security Model for the Simple Network
Management Protocol, using the Secure Shell protocol within a
Transport Mapping.
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. The reader is
expected to have read and understood the description of the SNMP
architecture, as defined in [RFC3411],and the "Transport Mapping
Security Model (TMSM) for the Simple Network Management Protocol"
architecture extension defined in [I-D.schoenw-snmp-tlsm], 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 [I-D.ietf-secsh-architecture].
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.
This memo 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.
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.1. 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
Harrington, et al. Expires April 17, 2006 [Page 4]
Internet-Draft Secure Shell Security Model for SNMP October 2005
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 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), and how SNMP can make use of the authenticated
identities in authentication and auditing. .
The work will include the ability to use any of the user
authentication methods described in "SSH Authentication Protocol"
[I-D.ietf-secsh-userauth] - 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 be able to take advantage of other defined
authentication mechanism such as those defined in [I-D.ietf-secsh-
gsskeyex] and future mechanism such as those that make use of X.509
certificate credentials. This will allow SSHSM to utilize user
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 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 memo describes a method
for invoking and running the SNMP protocol within a Secure Shell
(SSH) session as an SSH subsystem.
This memo defines how SNMP can be used within a Secure Shell (SSH)
session, using the SSH connection protocol [I-D.ietf-secsh-connect]
over the SSH transport protocol [I-D.ietf-secsh-transport], using SSH
user-auth [I-D.ietf-secsh-userauth]for authentication.
Harrington, et al. Expires April 17, 2006 [Page 5]
Internet-Draft Secure Shell Security Model for SNMP October 2005
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 are identified by
[todo] markers in the text. Points requiring further WG research and
discussion are identified by [discuss] markers in the text.
1.2. 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.3. 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 [[I-D.ietf-secsh-transport]
provides server authentication, 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 [I-D.ietf-secsh-userauth]
authenticates the client-side user to the server. It runs over
the transport layer protocol.
o The Connection Protocol [I-D.ietf-secsh-connect] multiplexes the
encrypted tunnel into several logical channels. It runs over the
user authentication protocol.
The client sends a service request once a secure transport layer
connection has been established. A second service request is sent
after user authentication is complete. This allows new protocols to
be defined and coexist with the protocols listed above.
The connection protocol provides channels that can be used for a wide
range of purposes. Standard methods are provided for setting up
secure interactive shell sessions and for forwarding ("tunneling")
arbitrary TCP/IP ports and X11 connections.
Harrington, et al. Expires April 17, 2006 [Page 6]
Internet-Draft Secure Shell Security Model for SNMP October 2005
1.4. 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.
2. In times of network stress, neither the security protocol nor its
underlying security mechanisms should depend upon the ready
availability of other network services (e.g., Network Time
Protocol (NTP) or AAA protocols).
3. When the network is not under stress, the security 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 should entail no changes to the basic SNMP
network management philosophy.
1.5. Conventions
The terms "manager" and "agent" are not used in this document,
because in the RFC 3411 architecture, all 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 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 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].
2. How SSHSM Fits into the TMSM Architecture
SSH is a security layer which is plugged into the TMSM architecture
between the underlying transport layer and the message dispatcher.
The SSHSM model will establish an encrypted tunnel between the
transport mappings of two SNMP engines. The sending transport
Harrington, et al. Expires April 17, 2006 [Page 7]
Internet-Draft Secure Shell Security Model for SNMP October 2005
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 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.
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]:
1. Message stream modification - Provide for verification that each
received SNMP message has not been modified during its
transmission through the network. .
2. Information modification - Provide for verification that the
contents of each received SNMP message has not been modified
during its transmission through the network. Data has not been
altered or destroyed in an unauthorized manner, nor have data
sequences been altered to an extent greater than can occur non-
maliciously
3. Masquerade - Provide for both verification of the identity of the
user on whose behalf a received SNMP message claims to have been
generated, and the verification of the identity of the MIB owner.
For the protocols specified in this memo, it is not possible to
assure the specific user that originated a received SNMP message;
Harrington, et al. Expires April 17, 2006 [Page 8]
Internet-Draft Secure Shell Security Model for SNMP October 2005
rather, it is the user on whose behalf the message was originated
that is authenticated. SSH provides verification of the identity
of the MIB owner through the SSH Transport Protocol server
authentication [I-D.ietf-secsh-transport]
4. Verification of user identity is important for use with the SNMP
access control subsystem, to ensure that only authorized users
have access to potentially sensitive data. The SSH user identity
will be used to map to an SNMP model-independent securityname for
use with SNMP access control.
5. Authenticating the server ensures the authenticity of the SSH
server that is associated with the SNMP engine that provides MIB
data. Operators or management applications could act upon the
data they receive (e.g. raise an alarm for an operator, modify
the configuration of the device that sent the notification,
modify the configuration of other devices in the network as the
result of the notification, and so on) , so it is important to
know that the data is authentic. SSH allows for authenticaiton
of the SSH server using the SSH public key credentials described
in [I-D.ietf-secsh-transport] and mechanisms such as those
described in [I-D.ietf-secsh-gsskeyex].
6. Disclosure - Provide, when necessary, that the contents of each
received SNMP message are protected from disclosure to
unauthorized persons..
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 that message
reordering is not dealt with and can occur in normal conditions
2.1.1.1. Data Origin Authentication Issues
The RFC 3411 architecture recognizes three levels of security:
- without authentication and without privacy (noAuthNoPriv)
- with authentication but without privacy (authNoPriv)
- with authentication and with privacy (authPriv)
SSH provides support for encryption and data integrity. While it is
technically possible to support noAuthNoPriv and authNoPriv in SSH it
is NOT RECOMMENDED by [I-D.ietf-secsh-transport]. This means that an
SSH connection should support authPriv, which is the highest level 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 the this case an
implementation MUST still support data integrity within the SSH
transport protocol. The security protocols used in [I-D.ietf-secsh-
transport] 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.
Harrington, et al. Expires April 17, 2006 [Page 9]
Internet-Draft Secure Shell Security Model for SNMP October 2005
authNoPriv may be important to accommodate governmental regulation
(e.g. export laws) regarding encryption technologies.
[discuss] #1: is it important to support anonymous user access to
SNMP?
Should the transport layer provide what data integrity and encryption
algorithms were negotiated to the SSHSM layer? In SNMP, we
deliberately avoided this, and settled for an assertion that auth and
priv were applied accoridng to the rules of the security model.
SSH should also provide the identity of the authenticated parties.
From this information it should be possible for the SNMP subsystem to
determine if the session is allowed access to the subsystem.
2.1.1.1.1. noAuthPriv
SSH provides the "none" userauth method, which is normally rejected
by servers and used only to find out what userauth methods are
supported. However, it is legal for a server to accept this method,
which has the effect of not authenticating the ssh client to the ssh
server. Doing this does not compromise authentication of the ssh
server to the ssh client, nor does it compromise data confidentiality
or data integrity.
The RFC 3411 architecture does not permit noAuthPriv. SSHSM should
refuse a noAuthPriv session [todo] If we do not allow some of these
options, how do we determine the option was used, so we can reject
it? How does an SNMP engine reject a session?
2.1.1.1.2. skipping public key verification
[todo] Most key exchange algorithms are able to authenticate the SSH
server's identity to the client. However, for the common case of DH
signed by public keys, this requires the client to know the host's
public key a priori and to verify that the correct key is being used.
If this step is skipped, you no longer have authentication of the ssh
server to the ssh client. You do still get data confidentiality and
data integrity protection to whatever server you're talking to, 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
(otherwise you may be giving your password to an attacker). [discuss]
#2: a) is server authentication a requirement that SNMP will require
of the client? b) how can we verify that server authentication was
performed, or do we take simply trust the SSH client layer to perform
Harrington, et al. Expires April 17, 2006 [Page 10]
Internet-Draft Secure Shell Security Model for SNMP October 2005
such authentication? c) for the common case of DH signed by public
keys, how does the client learn the host's public key in advance, and
verify that the correct key is being used?
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. Sessions
Sessions are not part of RFC 3411 architecture, but are considered
desirable because the cost of authentication can be amortized over
potentially many transactions. The Secure Shell security model will
utilize sessions, with a single user and security level associated
with each session. If an exchange with another engine would require
a different security level or would be on behalf of a different user,
then another session would be needed. An immediate consequence of
this is that implementations should be able to maintain some
reasonable number of concurrent sessions.
A session is associated with state information that is maintained for
its lifetime. This state information allows for the application of
various security services. Cryptographic keys established at the
beginning of the session and stored in the session state can be used
to authenticate and encrypt data that is communicated during the
session. The cryptographic protocols used to establish keys for a
session ensure that fresh new session keys are generated for each
session. Since each session uses new session keys messages cannot be
replayed from one session to another. In addition sequence
information can be maintained in the session which can be used to
prevent the replay and reordering of messages within a session.
This document will discuss the impact of sessions on SNMP usage.
[discuss] #3: we need some text contributed to discuss the
implications of sessions on SNMP.
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
Harrington, et al. Expires April 17, 2006 [Page 11]
Internet-Draft Secure Shell Security Model for SNMP October 2005
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
messgaes. 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 then 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 authentication mechanism supported by
SSH. This includes the three authentication methods described in the
SSH Authentication Protocol document - publickey, password, and 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 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 leave the
password in the clear on the device that is authenticating the
password which introduces threats on the authentication
infrastructure which is less than ideal.
GSSKeyex [I-D.ietf-secsh-gsskeyex] provides a framework for the
addition of user authentication mechanisms which support different
security infrastructures and provide different security properties.
Additional authentication mechanisms, such as one that supports X.509
certificates, may be added to SSH in the future.
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.
Harrington, et al. Expires April 17, 2006 [Page 12]
Internet-Draft Secure Shell Security Model for SNMP October 2005
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 for
SNMP.
It has been a long-standing requirement that SNMP be able to work
when the network is unstable, to enable network troubleshooting and
repair. The UDP approach has been considered to meet that need well,
with an assumption that getting small messages through, even if out
of order, is better than gettting no messages through. There has
been a long debate about whether UDP actually offers better support
than TCP when the underlying IP or lower layers are unstable. There
has been recent discussion of whether operators actually use SNMP to
troubleshoot and repair unstable networks. This document includes a
discussion of the operational expectations of this model for use in
troubleshooting a broken network.[discuss] #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?
There has been discussion of ways SNMP could be extended to better
support management/monitoring needs when a network is running just
fine. Use of a TCP transport, for example, could enable larger
message sizes and more efficient table retrievals. Secure Shell runs
over TCP. This document will discuss the expected ramifications of
using a TCP transport for SNMP, and the coexistence of UDP and TCP
transport for SNMP. [discuss] #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
Harrington, et al. Expires April 17, 2006 [Page 13]
Internet-Draft Secure Shell Security Model for SNMP October 2005
document?
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?
2.1.6.1. 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 application uses a
contextEngineID equal to the snmpEngineID of its associated SNMP
engine.
securityEngineID - The RFC3411 architecture defines ASIs that
include a securityEngineID - the authoritative SNMP entity - which
is either the local snmpEngineID or the target snmpEngineID,
depending on the type of operation. Since a security model might
utilize shared credentials and integrity-checking parameters, and
the datastores of the two endpoints could get out of sync, the
"authoritative" engineID indicates which end has the values to be
used.
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 a TMSM/SSHSM
environment? In SNMPv3, the authoritative engine is usually the
engine with the command responder, i.e. the agent; in non-proxy
situations, securityEngineID equals contextEngineID. in client-server
terms, the authoritative engine is usually the server. So, should
the SNMP engine associated with the SSH server be authoritative?
Would Infoms change that? Would bidirectional messaging change that?
Would call-home change that? Do we need to set the securityEngineID
to indicate which side is the SSH server?
[discuss] #8: Do we need a mapping between the SSH key (or other SSH
Harrington, et al. Expires April 17, 2006 [Page 14]
Internet-Draft Secure Shell Security Model for SNMP October 2005
engine identifier) and SNMP engine ID(s)? What happens if an agent
"spoofs" another engineID, and an NMS perfoms a SET of sensitive
parameters to the agent?
2.2. Security Parameter Passing Requirement
SSHSM follows the TMSM approach, in which the security-model has two
separate areas of security procoessing - the TMSP performs transport-
mapping-related security processing, and the MPSP performs security
processing within the security model subsystem of the messaging model
(MPSP). specific parameters for an incoming message can be determined
from the transport layer by the transport mapping security
procoessing (TMSP), before the message processing begins, and for
outgping messages, the security-model-specific parameters are
gathered by the messaging-security-processing (MPSP) and passed with
the outgoing message to the transport mapping.
For outgoing messages, 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 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
and a corresponding specific MPSP. If a TMSM-model-independent ASI
parameter is passed, this approach would be consistent with the
securityStateReference cache already being passed around in the ASI.
2.3. Requirements for Notifications
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
Harrington, et al. Expires April 17, 2006 [Page 15]
Internet-Draft Secure Shell Security Model for SNMP October 2005
automated processes. As a result, it will be necessary to provision
authentication credentials on the SNMP engine containing the
notification originator so it can successfully authenticate to an
engine containing a notification receiver.
[discuss] #9: Can an existing R/R session be reused for
notifications?
There is some text in Appendix A in RFC 3430 [RFC3430]which captured
some of these discussions when RFC 3430 was written.
2.4. Scenario Diagrams
RFC 3411 section 4.6 provides scenario diagrams to illustrate how an
outgoing message is created, and how an incoming message is
processed. Both diagrams are incomplete, however.In section 4.61,
the diagram doesn't show the ASI for sending an SNMP request to the
network or receiving an SNMP response message from the network. In
section 4.6.2, the diagram doesn't illustrate the interfaces required
to receive an SNMP message from the network, or to send an SNMP
message to the network.
2.4.1. Command Generator or Notification Originator
This diagram from RFC 3411 4.6.1 shows how a Command Generator or
Notification Originator application requests that a PDU be sent, and
how the response is returned (asynchronously) to that application.
Harrington, et al. Expires April 17, 2006 [Page 16]
Internet-Draft Secure Shell Security Model for SNMP October 2005
Command Dispatcher Message Security
Generator | Processing Model
| | Model |
| sendPdu | | |
|------------------->| | |
| | prepareOutgoingMessage | |
: |----------------------->| |
: | | generateRequestMsg |
: | |-------------------->|
: | | |
: | |<--------------------|
: | | |
: |<-----------------------| |
: | | |
: |------------------+ | |
: | Send SNMP | | |
: | Request Message | | |
: | to Network | | |
: | v | |
: : : : :
: : : : :
: : : : :
: | | | |
: | Receive SNMP | | |
: | Response Message | | |
: | from Network | | |
: |<-----------------+ | |
: | | |
: | prepareDataElements | |
: |----------------------->| |
: | | processIncomingMsg |
: | |-------------------->|
: | | |
: | |<--------------------|
: | | |
: |<-----------------------| |
| processResponsePdu | | |
|<-------------------| | |
| | | |
2.4.2. Command Responder
This diagram shows how a Command Responder or Notification Receiver
application registers for handling a pduType, how a PDU is dispatched
to the application after an SNMP message is received, and how the
Response is (asynchronously) send back to the network.
Harrington, et al. Expires April 17, 2006 [Page 17]
Internet-Draft Secure Shell Security Model for SNMP October 2005
Command Dispatcher Message Security
Responder | Processing Model
| | Model |
| | | |
| registerContextEngineID | | |
|------------------------>| | |
|<------------------------| | | |
| | Receive SNMP | | |
: | Message | | |
: | from Network | | |
: |<-------------+ | |
: | | |
: |prepareDataElements | |
: |------------------->| |
: | | processIncomingMsg |
: | |------------------->|
: | | |
: | |<-------------------|
: | | |
: |<-------------------| |
| processPdu | | |
|<------------------------| | |
| | | |
: : : :
: : : :
| returnResponsePdu | | |
|------------------------>| | |
: | prepareResponseMsg | |
: |------------------->| |
: | |generateResponseMsg |
: | |------------------->|
: | | |
: | |<-------------------|
: | | |
: |<-------------------| |
: | | |
: |--------------+ | |
: | Send SNMP | | |
: | Message | | |
: | to Network | | |
: | v | |
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 an
Harrington, et al. Expires April 17, 2006 [Page 18]
Internet-Draft Secure Shell Security Model for SNMP October 2005
SNMP entity. The Secure Shell Security Model uses some of these
conceptual data flows when communicating with other subsystems, such
as the 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 the prepareOutgoingMessage() ASI are used to
pass information from the dispatcher (application subsystem) to the
message processing subsystem. The OUT parameters are used to pass
information from the message processing subsystem to the dispatcher
and on to 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 -- Security Model to use
IN securityName -- on behalf of this principal
IN securityLevel -- Level of Security requested
IN contextEngineID -- data from/at this entity
IN contextName -- data from/in this context
IN pduVersion -- the version of the PDU
IN PDU -- SNMP Protocol Data Unit
IN expectResponse -- TRUE or FALSE
IN sendPduHandle -- the handle for matching
-- incoming responses
OUT destTransportDomain -- destination transport domain
OUT destTransportAddress -- destination transport address
OUT outgoingMessage -- the message to send
OUT outgoingMessageLength -- its length
)
The abstract service primitive from a Message Processing Model to a
Security Model to generate the components of a Request message is:
Harrington, et al. Expires April 17, 2006 [Page 19]
Internet-Draft Secure Shell Security Model for SNMP October 2005
statusInformation = -- success or errorIndication
generateRequestMsg(
IN messageProcessingModel -- typically, SNMP version
IN globalData -- message header, admin data
IN maxMessageSize -- of the sending SNMP entity
IN securityModel -- for 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 in by Security Module
OUT wholeMsg -- complete generated message
OUT wholeMsgLength -- length of generated message
)
The abstract service primitive from a Message Processing Model to a
Security Model to generate the components of a Response message is:
statusInformation = -- success or errorIndication
generateResponseMsg(
IN messageProcessingModel -- typically, SNMP version
IN globalData -- message header, admin data
IN maxMessageSize -- of the sending SNMP entity
IN securityModel -- for the outgoing message
IN securityEngineID -- authoritative SNMP entity
IN securityName -- on behalf of this principal
IN securityLevel -- Level of Security requested
IN scopedPDU -- message (plaintext) payload
IN securityStateReference -- reference to security state
-- information from original
-- request
OUT securityParameters -- filled in by Security Module
OUT wholeMsg -- complete generated message
OUT wholeMsgLength -- length of generated message
)
The abstract data elements passed as parameters in the abstract
service primitives are as follows: [todo] check each parameter and
determine if it is necessary for SSHSM and whether the description is
accurate
statusInformation - An indication of whether the encoding and
securing of the message was successful. If not it is an
indication of the problem.
messageProcessingModel - The SNMP version number for the message
to be generated. This data is not used by the User-based Security
module.
Harrington, et al. Expires April 17, 2006 [Page 20]
Internet-Draft Secure Shell Security Model for SNMP October 2005
globalData - The message header (i.e., its administrative
information). This data is not used by the User-based Security
module.
maxMessageSize - The maximum message size as included in the
message. This data is not used by the User-based Security module.
securityParameters - These are the security parameters. They will
be filled in by the SSH Security module.
securityModel - The securityModel in use. Should be SSH Security
Model.
securityName - identifies a principal to be used for securing an
outgoing message. The securityName has a format that is
independent of the Security Model. In case of a response this
parameter is ignored and the value from the cache is used.
securityLevel - The Level of Security from which the SSH Security
module determines if the message needs to be protected from
disclosure and if the message needs to be authenticated.
securityEngineID - The snmpEngineID of the authoritatvie SNMP
engine to which a dateRequest message is to be sent. In case of a
response it is implied to be the processing SNMP engine's
snmpEngineID and so if it is specified, then it is ignored.
scopedPDU - The message payload. The data is opaque as far as the
SSH Security Model is concerned.
securityStateReference - A handle/reference to cachedSecurityData
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 the incoming Request message to
which this is the Response message.
wholeMsg - The fully encoded SNMP message ready for sending on the
wire.
wholeMsgLength - The length of the encoded SNMP message
(wholeMsg).
Upon completion of the process, 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 successful, then an
errorIndication is returned.
3.1.2. Public ASIs for Incoming Messages
The abstract service primitive from a Transport Mapping (in the
dispatcher) to a Message Processing Model for a received message is::
Harrington, et al. Expires April 17, 2006 [Page 21]
Internet-Draft Secure Shell Security Model for SNMP October 2005
result = -- SUCCESS or errorIndication
prepareDataElements(
IN transportDomain -- origin transport domain
IN transportAddress -- origin transport address
IN wholeMsg -- as received from the network
IN wholeMsgLength -- as received from the network
OUT messageProcessingModel -- typically, SNMP version
OUT securityModel -- Security Model to use
OUT securityName -- on behalf of this principal
OUT securityLevel -- Level of Security requested
OUT contextEngineID -- data from/at this entity
OUT contextName -- data from/in this context
OUT pduVersion -- the version of the PDU
OUT PDU -- SNMP Protocol Data Unit
OUT pduType -- SNMP PDU type
OUT sendPduHandle -- handle for matched request
OUT maxSizeResponseScopedPDU -- maximum size sender can accept
OUT statusInformation -- success or errorIndication
-- error counter OID/value if error
OUT stateReference -- reference to state information
-- to be used for possible Response
)
The abstract service primitive from a Message Processing Model to the
Security Subsystem for a received message is::
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
Harrington, et al. Expires April 17, 2006 [Page 22]
Internet-Draft Secure Shell Security Model for SNMP October 2005
3.2. Private Abstract Service Interfaces
A set of abstract service interfaces have been defined within this
document to describe the conceptual data flows between the Secure
Shell Security Model (SSHSM) and the self-contained transport mapping
services.These apply only to the Secure Shell Security Model (SSHSM),
and are referred to here as private interfaces.
The Secure Shell Security Model provides the following internal
primitives to pass data back and forth between the Security Model
itself and the SSH authentication service:
statusInformation =
establishSession(
IN transportDomain -- transport domain to be used
IN transportAddress -- transport address to be used
IN securityModel -- Security Model to use
IN securityEngineID -- SNMP entity
IN securityName -- on behalf of this principal
IN securityLevel -- Level of Security requested
OUT sessionID
)
4. SNMP Messages Using this Security Model
The syntax of an SNMP message using this Security Model adheres to
the message format defined in the version-specific Message Processing
Model document (for example [RFC3412]). At the time of this writing,
there are three defined message formats - SNMPv1, SNMPv2c, and
SNMPv3.
4.1. SNMPv1 and SNMPv2c Messages Using this Security Model
Since message security is provided by a "lower layer", the message
does not need to carry message security parameters.
The securityModel and securityName parameters are determined by the
Secure Shell Security Model from 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 message lacks a msgFlags field, the msgFlags is
always treated as authPriv.
The communitystring is not used as an authentication mechansism,
Harrington, et al. Expires April 17, 2006 [Page 23]
Internet-Draft Secure Shell Security Model for SNMP October 2005
since user authentication is provided by SSH userauth. The community
string is still used to provide context information.
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.
4.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 for the SSHSM model, and why? Which services
provided in USM are needed in TMSM/SSHSM? How does the Message
Processing model provides this information to the security model via
generateRequestMsg() and processIncomingMsg() primitives?
The SNMPv3Message SEQUENCE is defined in [RFC3412]. The following
fields are specific to the Secure Shell Security Model:
Harrington, et al. Expires April 17, 2006 [Page 24]
Internet-Draft Secure Shell Security Model for SNMP October 2005
SNMPv3MessageSyntax DEFINITIONS IMPLICIT TAGS ::= BEGIN
SNMPv3Message ::= SEQUENCE {
-- identify the layout of the SNMPv3Message
-- this element is in same position as in SNMPv1
-- and SNMPv2c, allowing recognition
-- the value 3 is used for snmpv3
msgVersion INTEGER ( 0 .. 2147483647 ),
-- administrative parameters
msgGlobalData HeaderData,
-- security model-specific parameters
-- 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)),
-- .... ...1 authFlag
-- .... ..1. privFlag
-- .... .1.. reportableFlag
-- Please observe:
-- .... ..00 is OK, means noAuthNoPriv
-- .... ..01 is OK, means authNoPriv
-- .... ..10 reserved, MUST NOT be used.
-- .... ..11 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
Harrington, et al. Expires April 17, 2006 [Page 25]
Internet-Draft Secure Shell Security Model for SNMP October 2005
4.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 to the IANA-assigned value for the Secure
Shell Security Model. See
http://www.iana.org/assignments/snmp-number-spaces.
4.2.1.1. msgSecurityParameters
Since message security is provided by a "lower layer", and the
securityName parameter is always determined from the SSH
authentication method, the 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. [todo] #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?
The field msgSecurityParameters in SNMPv3 messages has a data type of
OCTET STRING. Its value MUST be the BER serialization of the
following ASN.1 sequence:
SSHSMSecurityParametersSyntax DEFINITIONS IMPLICIT TAGS ::= BEGIN
SSHsmSecurityParameters ::=
SEQUENCE {
OCTET STRING
}
END
4.2.1.2. msgFlags
For an outgoing message, msgFlags is the requested security for the
message; if a SSHSM cannot provide the requested securityLevel, the
request MUST be discarded and SHOULD notify the message processing
model that the request failed. [discuss: #12: how does SSHSM
determine whether SSH can provide the security services requested in
msgFlags? ]
[discuss] There were discussions about whether it was acceptable for
a transport-mapping-model to provide stronger security than
requested. Does this need to be discussed in the SSHSM document, or
should we discuss this in the TMSM document? when sending a message
into an environment where encryption is not legal, how do we ensure
Harrington, et al. Expires April 17, 2006 [Page 26]
Internet-Draft Secure Shell Security Model for SNMP October 2005
that encryption is not provided?
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 message carries the requested msgFlags,
not the actual securityLevel applied 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.
For an incoming message, the receiving SSHSM knows what must be done
to process the message based on the transport layer mechanisms. If
the underlying transport security mechanisms for the receiver cannot
provide the matching securityLevel, then the message should follow
the standard behaviors for the transport security mechanism, or be
discarded silently.
Part of the responsibility of the SSHSM is to ensure that the actual
security provided by the underlying transport layer security
mechanisms is configured to meet or exceed the securityLevel required
by the msgFlags in the SNMP message. When the MPSP processes the
incoming message, it should compare the msgFlags field to the
securityLevel actually provided for the message by the transport
layer security. If they differ, the MPSP should determine whether
the changed securityLevel is acceptable. If not, it should discard
the message.
4.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 the Configuration Datastore is
altered between the time of the incoming request and the outgoing
response. For SSHSM, there are three levels of state that need to be
maintained: the session, the message, and the model-independent
translations.
[discuss] #13: will SSHSM be impacted by keychanges to the SSH local
datastore?
tmStateReference is used to pass model- and mechanism-specific
parameters to coordinate the session-related activities and specific
message pair processing between the TMSP and MPSP. The SSHSM has the
responsibility for explicitly releasing the complete tmStateReference
when the session is destroyed. The SSHSM has the responsibility for
releasing the message-specific parameters in the tmStateReference
once a response message has been sent, or the data is no longer
needed.
Harrington, et al. Expires April 17, 2006 [Page 27]
Internet-Draft Secure Shell Security Model for SNMP October 2005
The MPSP translates select parameters from the tmStateReference cache
into model-independent parameters subsequently passed in the
securityStateReference cache to a Message Processing Model. The
Message Processing Model has the responsibility for explicitly
releasing the securityStateReference if such data is no longer
needed. The securityStateReference cached data may be implicitly
released via the generation of a response, or explicitly released by
using the stateRelease primitive, as described in RFC 3411 section
4.5.1."
4.3.1. Transport Session Parameters
SSHSM will create a session between the TMSM of one SNMP entity and
the TMSM of another SNMP entity. The created "tunnel" will provide
encryption and data integrity. [discuss] #14: MUST the SSHSM model
provide mutual authentication of the client and server, and MUST it
authenticate, integrity-check, and encrypt the messages?
Upon establishment of an SSH session, the TMSP will cache the
transport parameters in the tmStateReference for subsequent usage.
This information should be stored in a local datastore.
The tmStateReference cache for use with the SSH Authentication
Protocol [I-D.ietf-secsh-userauth] will include the following
transport-related information: [discuss] #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?
tmSessionID = a unique local identifier
tmTransportDomain = TCP/IPv4
tmTransportAddress = x.x.x.x:y
tmSecurityModel - SSHSM
tmSecurityLevel = "authPriv"
tmPrivProtocol = from the SSH session parameters
tmSSHKeyExchangeProtocol for authenticating the server
Additional information will be added to the tmStateReference by the
authentication portion of the SSHSM.
[discuss] #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 by the
authentication of the provided username. What should be the source
of the SSHSM mechanism-specific username for mapping to securityname?
Pssing 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
Harrington, et al. Expires April 17, 2006 [Page 28]
Internet-Draft Secure Shell Security Model for SNMP October 2005
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?
4.3.1.1. Authenticating Servers and Clients
[discuss] #17: I believe somebody suggested we require mutual
authentication. I'm not sure I understand the edits.
[discuss] #18: I currently have multiple sections, one for each known
auth mechanism. We need to discuss the parameters that need to be
cached for each, and determine whether we can collapse this into one
section.
4.3.2. [discuss] Using Passwords to Authenticate SNMP Principals
Upon creation of a SSH session, the TMSP will cache the session
authentication information in the tmStateReference:
tmUserName is the name used in user name field of the
SSH_MSG_USERAUTH_REQUEST message
tmSecurityName is the name used in user name field of the
SSH_MSG_USERAUTH_REQUEST message
tmAuthMechanism = "password"
tmAuthProtocol = "password"
tmSecurityLevel = appropriate choice from SnmpSecurityLevel
tmAuthzData = "[todo] authorization data obtained during the
exchange"
4.3.3. [discuss] Using Public keys to Authenticate SNMP Principals
Upon creation of a SSH session, the TMSP will cache the session
authentication information in the tmStateReference:
tmSecurityName is the name used in user name field of the
SSH_MSG_USERAUTH_REQUEST message
tmAuthMechanism = "publickey"
tmAuthProtocol = public key algorithm name
tmSecurityLevel = appropriate choice from SnmpSecurityLevel
tmAuthzData = "[todo] authorization data obtained during the
exchange"
4.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 the tmStateReference:
tmSecurityName is the name used in user name field of the
SSH_MSG_USERAUTH_REQUEST message
Harrington, et al. Expires April 17, 2006 [Page 29]
Internet-Draft Secure Shell Security Model for SNMP October 2005
tmAuthMechanism = "hostbased"
tmAuthProtocol = public key algorithm for host key
tmSecurityLevel = appropriate choice from SnmpSecurityLevel
tmAuthzData = "[todo] authorization data obtained during the
exchange"
4.3.5. [discuss] Using RADIUS to Authenticate SNMP Principals
SSHSM SHOULD use RADIUS Digest for authentication for security
reasons. Implementations MAY however choose to use RADIUS PAP to
support additional backend authentication systems such as Active
Directory and Token Servers.
Upon creation of a SSH session, the TMSP will cache the session
authentication information in the tmStateReference:
tmSecurityName is the name used in username field of the RADIUS
ACCESS-REQUEST message.
tmAuthMechanism = ""
tmAuthProtocol = RADIUS
tmRadiusServer = x.x.x.x:y
tmSecurityLevel = appropriate choice from SnmpSecurityLevel
tmAuthzData = "[todo] authorization data obtained during the
exchange"
[discuss] #19: RADIUS is just an instance of the password
authentication protocol. The details of RADIUS are within the SSH
layer. I don't think it is a good idea to expose this outside of
SSH.
4.3.6. securityStateReference for SSHSM
The parameters associated with an incoming request message to be
applied to the outgoing response.
messageProcessingModel = SNMPv3
securityModel = SSHSM
sessionID = tmSessionID
4.4. MIB Module for SSH Security Model
Each security model should use its own MIB module, rather than
utilizing the USM MIB, to eliminate dependencies on a model that
could be replaced some day. See RFC 3411 section 4.1.1.
[discuss] #20: How do we get the mapping from model-specific identity
to a model independent securityName?.
Harrington, et al. Expires April 17, 2006 [Page 30]
Internet-Draft Secure Shell Security Model for SNMP October 2005
[todo] Module needs to be worked out once things become stable...
4.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.
5. Elements of Procedure
5.1. Establishing a Session
The Secure Shell Security Model provides the following primitive to
pass data back and forth between the Security Model and the SSH
service:
statusInformation =
establishSession(
IN destTransportDomain -- transport domain to be used
IN destTransportAddress -- transport address to be used
IN securityModel -- Security Model to use
IN securityEngineID -- SNMP entity
IN securityName -- on behalf of this principal
IN securityLevel -- Level of Security requested
OUT sessionID
)
The following describes the procedure to follow to establish a
session between a client and sever to run SNMP over SSH. This
process is followed by any SNMP engine establishing a session for
subsequent use. In practice, this is done by an application that
initiates a transaction, such as a Command Generator or a
Notification Originator or a Proxy Forwarder. It is never triggered
by an application preparing a response message, such as a Command
Responder or Notification Receiver, because securityStatereference
will always have session information for a response message
The parameters necessary to establish a session are provided by the
Secure Shell Security Model to the SSH client code, using the
establishSession() ASI.
1) If the securityLevel specifies that the message is to be
Harrington, et al. Expires April 17, 2006 [Page 31]
Internet-Draft Secure Shell Security Model for SNMP October 2005
authenticated, but the SSH implementation does not support an
authentication protocol, then the message cannot be sent. An error
indication (unsupportedSecurityLevel) is returned to the calling
module.
2) If the securityLevel specifies that the message is to be protected
from disclosure, but the SSH implementation does not support
encryption, then the message cannot be sent. An error indication
(unsupportedSecurityLevel) is returned to the calling module.
3) Using destTransportDomain and destTransportAddress, the client
will establish an SSH transport connection using the SSH transport
protocol, and the client and server will mutually authenticate, and
exchange keys for message integrity and encryption. if the attempt to
establish a connection is successful, then tmStateReference is
created, and the values of transportDomain and transportAddress are
saved. If the attempt to establish a connection is unsuccessful,
then an error indication [todo] will be returned, and [todo]
processing stops.
[discuss] #22: There are a significant number of security problems
associated with mapping to a transport address which may need to be
discussed in the security considerations section.
4) The provided securityEngineID and securityName and securityLevel
are used to lookup the associated entry in the Local Configuration
Datastore (LCD), and the model-specific information concerning the
principal at the destination is extracted. This step allows
preconfiguration of model-specific principals mapped to the engine/
name/level. Set the username in the SSH_MSG_USERAUTH_REQUEST to the
username extracted from the LCD.
If information about the user is absent from the LCD, then set the
username in the SSH_MSG_USERAUTH_REQUEST to the value of
securityName. This allows a deployment without preconfigured
mappings between model-specific and model-independent names, but the
securityName will need to contain a username recognized by the
authentication mechanism.
5)The client will then invoke the "ssh-userauth" service to
authenticate the user, as described in the SSH authentication
protocol [I-D.ietf-secsh-userauth].
6) If the authentication is unsuccessful, then the transport
connection should be closed, tmStateReference is discarded, the
message is discarded, an error indication (unknownSecurityName) is
returned to the calling module, and processing stops for this
message.
Harrington, et al. Expires April 17, 2006 [Page 32]
Internet-Draft Secure Shell Security Model for SNMP October 2005
7) Once the user has been successfully authenticated, the client will
invoke the "ssh- connection" service, also known as the SSH
connection protocol [I-D.ietf-secsh-connect].
8) After the ssh-connection service is established, the client will
use an SSH_MSG_CHANNEL_OPEN message to open a channel of type
"session", providing a selected sender channel number, and a maximum
packet size based on maxMessageSize.
9) If successful, this will result in an SSH session. The
destTransportDomain nd the destTransportAddress, plus the "recipient
channel" and "sender channel" and other relevant data from the
SSH_MSG_CHANNEL_OPEN_CONFIRMATION are added to the tmStateReference
for subsequent use.
10) Once the SSH session has been established, the SNMP engine will
invoke SNMP as an SSH subsystem called "SNMP". Running 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 is printed at shell start-up.
In order to allow SNMP traffic to be easily identified and filtered
by firewalls and other network devices, servers associated with SNMP
entities using the Secure Shell Security Model MUST default to
providing access to the "SNMP" SSH subsystem only when the SSH
session is established using the IANA-assigned TCP port (TBD).
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 for
SNMP messages.
[todo] Should we perform some type of engineID discovery to provide
the mapping between transport address, session, and engineID at this
point in the session establishment procedure? We have an established
channel; can we simply send a GET of snmpEngineID and record the
value in the tmStateReference?
11) [todo] the engine will perform an SNMP GET command requesting the
value of the remote engine's snmpEngineID object, and create a
tmStateReference cache recording the following information:
the remote engine's snmpEngineID
the transport address
the recipient and sender channels
Harrington, et al. Expires April 17, 2006 [Page 33]
Internet-Draft Secure Shell Security Model for SNMP October 2005
5.2. Closing a Session
The Secure Shell Security Model provides the following primitive to
pass data back and forth between the Security Model and the SSH
service:
statusInformation =
closeSession(
IN sessionID
)
The following describes the procedure to follow to close a session
between a client and sever to run SNMP over SSH. This process is
followed by any SNMP engine closing the corresponding SNMP session.
The Secure Shell Security Model identifies which session should be
closed to the SSH client code, using the closeSession() ASI.
[discuss] #23: We need to discuss the circumstances under which a
session should be closed, and how an SNMP engine should determine if,
and respond if the SSH session is closed by other means.
5.3. Discovery
Since snmpEngineID isn't really needed for authentication and
integrity checking, it becomes useful primarily for contextEngineID.
contextEngineID is useful for proxy, and for a management application
to uniquely identify an SNMP entity. Since snmpEngineID is an object
in the SNMP-FRAMEWORK-MIB, the mapping between engineID and transport
address could be established after a tunnel 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 an important feature of many NMS platforms.
Should we simply use a noAuthNoPriv request, and recommend an
associated access control configuration that only makes accessible
relatively benign data such as sysOID, sysDescription, and
snmpEngineID? Should we standardize this approach for all TMSM
models, including a "named policy" for what can be discovered (a
policy to be configured within whatever access control system is
used)?
Alternatively, can we let USM perform discovery so we don't have to
attenpt to establish an SSH connection first? USM is the mandatory-
to-implement security model, so this could make sense.
Harrington, et al. Expires April 17, 2006 [Page 34]
Internet-Draft Secure Shell Security Model for SNMP October 2005
5.4. Generating an Outgoing SNMP Message
This section describes the procedure followed by 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 the generateRequestMsg() or the generateResponseMsg() ASI
statusInformation = -- success or errorIndication
generateRequestMsg(
IN messageProcessingModel -- typically, SNMP version
IN globalData -- message header, admin data
IN maxMessageSize -- of the sending SNMP entity
IN securityModel -- for 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 in by Security Module
OUT wholeMsg -- complete generated message
OUT wholeMsgLength -- length of generated message
OUT tmStateReference -- reference to session info
)
statusInformation = -- success or errorIndication
generateResponseMsg(
IN messageProcessingModel -- typically, SNMP version
IN globalData -- message header, admin data
IN maxMessageSize -- of the sending SNMP entity
IN securityModel -- for the outgoing message
IN securityEngineID -- authoritative SNMP entity
IN securityName -- on behalf of this principal
IN securityLevel -- Level of Security requested
IN scopedPDU -- message (plaintext) payload
IN securityStateReference -- reference to security state
-- information from original
-- request
OUT securityParameters -- filled in by Security Module
OUT wholeMsg -- complete generated message
OUT wholeMsgLength -- length of generated message
OUT tmStateReference -- reference to session info
)
Harrington, et al. Expires April 17, 2006 [Page 35]
Internet-Draft Secure Shell Security Model for SNMP October 2005
1) verify securityModel = sshsmSecurityModel
2) If there is a securityStateReference, extract the
tmStateReference information from the cachedSecurityData from the
Request message. At this point, the cachedSecurityData can now be
discarded. [todo] clarify which data can be discarded.
3) If there is no securityStateReference, then lookup the session
info indexed by {securityEngineID, securityName, securityLevel},
and set tmStateReference.
4) If there is no session info for this index, then create an
incomplete tmStateReference indexed by the provided
{securityEngineID, securityName, securityLevel}. Store the
securityModel and maxMessageSize information. When the TMSP gets
the incomplete tmStateReference, it will recognize that it needs
to establish a new session, and fill in the rest of the
information for subsequent use.
5) fill in securityParameters with a NULL octet string.
[todo] we don't need to send securityEngineID, unless it is
needed for a discovery mechanism..
[todo] we don't need to send Boots and Time values
[todo] we don't need to send a username, since we use the one
from SSH authentication.
[todo] we don't need to call authenticateOutgoingMsg()
6) The wholeMsg is now serialized and then represents the
unauthenticated message being prepared.
7) The completed message (wholeMsg) with its length
(wholeMsgLength) and securityParameters (a NULL octet string) and
tmStateReference is returned to the calling module with the
statusInformation set to success.
The Message Processing Model then passes information to the
disptacher for forwarding to the Transport Mapping.
5.5. Sending an Outgoing SNMP Message to the Network
The TMSP portion of the Secure Shell Security Model performs the
following tasks:
8) Uses tmStateReference to lookup session information.
9) [todo] verifies that auth and priv can be provided, as
requested, and error-out if not.
10) If the session information is incomplete (i.e, has no
tmTransportAddress), then call establishSession() using the
destTransportDomain and destTransportAddress (the output of the
PrepareOutgoingMessage() ASI) and the securityModel,
securityEngineID, securityName, securityLevel from the
tmStateReference. Store all information in the tmStateReference
for subsequent use.
Harrington, et al. Expires April 17, 2006 [Page 36]
Internet-Draft Secure Shell Security Model for SNMP October 2005
[discuss] #25: Where is the best place to call establishSession()?
Note that the whole message is completely put together within the
message-processing portion of the security model, in the hopes
that a session will be able to be established when the message
gets to the transport mapping portion of the architecture. It is
done this way because the RFC3411 arcitecture doesn't pass the
transport addressing info into the security model via messaging
model. It would seem a much more efficient approach to very that
the session can be established, while still in the security model
portion of the messaging model. If we do'nt establish the session
until we get to the transport mapping, we've done a lot of work
for nothing. And thus far, there is no place to record failed
attempts to establish as 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.
[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] #27: The SNMP over TCP Transport Mapping document
[RFC3430]says that TCP connections can be recreated dynamically or
kept for future use and actually leaves all that to the transport
mapping. Do we need to discuss these issues? Where? in the security
considerations?
[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).
Harrington, et al. Expires April 17, 2006 [Page 37]
Internet-Draft Secure Shell Security Model for SNMP October 2005
5.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.
5.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::
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 ,
Harrington, et al. Expires April 17, 2006 [Page 38]
Internet-Draft Secure Shell Security Model for SNMP October 2005
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.
[discuss] #29: do we need to support reports? This was important for
USM, but much less so for SSHSM, since we don't need to synchronize
clocks and report other USM-specific issues, and we may not need it
for discovery either.
[discuss] #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/null 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?
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
[todo] we only need the authentication options and the encryption and
integrity-checking options, to verify that SSH is providing the
expected services, and didn't use "none" for any of these services.
If we can simply assume those services have always been provided
adequately without checking, then we only need the tmSecurityName
from SSH; all traffic can be assumed to be authPriv, and we know the
securityModel. I think this is inadequate, since some environments
may be legally prevented from using encryption, and SSH isn't going
to tell SNMP whether it met the requirements specified in msgFlags;
only the SNMP security model can compare what SSH says was provided
with what the SNMP application requested.
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
Harrington, et al. Expires April 17, 2006 [Page 39]
Internet-Draft Secure Shell Security Model for SNMP October 2005
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
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.
[discuss] #31: Is maxSizeResponseScopedPDU relevant? Can it be
calculated once for the session? Do we need to take into
consideration the SSH window size?
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.
Note that USM at this point would return an unknownSecurityName error
to the caller, because it didn't automatically assign a securityname
from the model-specific parameters. The message should never reach
us if it didn't pass authentication, so tmSecurityname should always
be present. [discuss] #32: For an incoming message, is using a
default securityName mapping the right thing to do?
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
Harrington, et al. Expires April 17, 2006 [Page 40]
Internet-Draft Secure Shell Security Model for SNMP October 2005
the calling module passing back the OUT parameters as specified in
the processIncomingMsg primitive.
6. Overview
7. Structure of the MIB Module
8. MIB module definition
[discuss] #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.
[todo] do we want a separate writable table that can be configured
with a SSH username to SNMP securityname mapping? I currently have
both user name and securityname in the session table, but since this
is dynamically created, I don't see how anybody could configure the
username to securityname mappings in the session table using SNMP.
The elements of procedure have been written to use the SSH username
directly if there is no securityname mapping configured. Of course,
RADIUS might be able to pass a securityname to go with the username
(Cf: RADIUS MAY return a different username in the ACCESS-ACCEPT
message than was used in the ACCESS-REQUEST message, for purposes of
accounting.)
SSHSM-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE,
OBJECT-IDENTITY, mib-2 FROM SNMPv2-SMI
TEXTUAL-CONVENTION FROM SNMPv2-TC
MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF
SnmpSecurityModel FROM SNMP-FRAMEWORK-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
Chair:
Juergen Quittek
NEC Europe Ltd.
Network Laboratories
Kurfuersten-Anlage 36
Harrington, et al. Expires April 17, 2006 [Page 41]
Internet-Draft Secure Shell Security Model for SNMP October 2005
69115 Heidelberg
Germany
+49 6221 90511-15
quittek@netlab.nec.de
Co-editors:
David Harrington
Effective Software
50 Harding Rd
Portsmouth, New Hampshire 03801
USA
+1 603-436-8634
ietfdbh@comcast.net
Juergen Schoenwaelder
International University Bremen
Campus Ring 1
28725 Bremen
Germany
+49 421 200-3587
j.schoenwaelder@iu-bremen.de
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
Harrington, et al. Expires April 17, 2006 [Page 42]
Internet-Draft Secure Shell Security Model for SNMP October 2005
-- ---------------------------------------------------------- --
-- subtrees in the SSHSM-MIB
-- ---------------------------------------------------------- --
sshsmNotifications OBJECT IDENTIFIER ::= { sshsmMIB 0 }
sshsmObjects OBJECT IDENTIFIER ::= { sshsmMIB 1 }
sshsmConformance OBJECT IDENTIFIER ::= { sshsmMIB 2 }
-- -------------------------------------------------------------
-- Objects
-- -------------------------------------------------------------
-- Identification of Authentication and Privacy Protocols
sshsmPasswordAuthProtocol OBJECT-IDENTITY
STATUS current
DESCRIPTION "The
REFERENCE ""
::= { snmpAuthProtocols xx }
sshsmPublickeyAuthProtocol OBJECT-IDENTITY
STATUS current
DESCRIPTION "The
REFERENCE ""
::= { snmpAuthProtocols xx }
sshsmHostbasedAuthProtocol OBJECT-IDENTITY
STATUS current
DESCRIPTION "The
REFERENCE ""
::= { snmpAuthProtocols xx }
sshsmRADIUSAuthProtocol OBJECT-IDENTITY
STATUS current
DESCRIPTION "The
REFERENCE ""
::= { snmpAuthProtocols xx }
sshsmAESPrivProtocol OBJECT-IDENTITY
STATUS current
DESCRIPTION "AES Encryption Protocol."
::= { snmpPrivProtocols xx }
Harrington, et al. Expires April 17, 2006 [Page 43]
Internet-Draft Secure Shell Security Model for SNMP October 2005
-- 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 to the SNMP engine
or otherwise unavailable.
[todo] we should never hit any of
these because they should never be sent by the remote
SNMP engine if an appropriate session does not exist.
We also do not know what was requested by the remote
session.
"
::= { sshsmStats 1 }
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 to the SNMP engine.
discuss] In SSHSM, we do no preconfiguration, so we
don't know any users. If authentication is based on
principals defined in the SSH authentication, if the user
is not known, they cannot be authenticated, so they
wouldn't reach the SNMP engine (assuming
we don't permit noAuthNoPriv over SSH.
"
::= { 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
Harrington, et al. Expires April 17, 2006 [Page 44]
Internet-Draft Secure Shell Security Model for SNMP October 2005
snmpEngineID that was not known to the SNMP engine.
[todo] We don't use the engineID during authentication,
encryption, or integrity checking, so there is never an error
condition related to unknown securityEngineID. (But check
the SNMPv3 dependency on knowing the securityEngineID.)
"
::= { sshsmStats 4 }
-- The sshsmSession Group
sshsmSession OBJECT IDENTIFIER ::= { sshsmObjects 2 }
sshsmSessionSpinLock OBJECT-TYPE
SYNTAX TestAndIncr
MAX-ACCESS read-write
STATUS current
DESCRIPTION "An advisory lock used to allow several cooperating
Command Generator Applications to coordinate their
use of facilities to create sessions in the
usmUserTable.
"
::= { sshsmSession 1 }
sshsmSessionTable OBJECT-TYPE
SYNTAX SEQUENCE OF SshsmSessionEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "The table of currently available sessions configured
in the SNMP engine's Local Configuration Datastore
(LCD).
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) for the Secure Shell
Security Model.
"
Harrington, et al. Expires April 17, 2006 [Page 45]
Internet-Draft Secure Shell Security Model for SNMP October 2005
INDEX { sshsmSessionID }
::= { sshsmSessionTable 1 }
SshsmSessionEntry ::= SEQUENCE
{
sshsmSessionID Integer32,
sshsmSessionTransport TransportAddressType,
sshsmSessionAddress TransportAddress,
sshsmSessionUserName SnmpAdminString,
sshsmSessionSecurityName SnmpAdminString,
sshsmSessionSecurityLevel SnmpAdminString,
sshsmSessionAuthProtocol AutonomousType,
sshsmSessionPrivProtocol AutonomousType,
sshsmSessionEngineID SmpEngineID
}
sshsmSessionID OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "A locally-unique identifier for a session.
"
::= { sshsmSessionEntry 1 }
sshsmSessionTransport OBJECT-TYPE
SYNTAX TransportAddressType
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The transport domain associated with this session.
"
::= { sshsmSessionEntry 2 }
sshsmSessionAddress OBJECT-TYPE
SYNTAX TransportAddress
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "The transport address associated with this session.
"
::= { sshsmSessionEntry 3 }
sshsmSessionUserName OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-only
STATUS current
DESCRIPTION "A human readable string representing the principal
in Security Model dependent format, such as the
the user name used in the
SSH-USERAUTH-REQUEST message for a successful
Harrington, et al. Expires April 17, 2006 [Page 46]
Internet-Draft Secure Shell Security Model for SNMP October 2005
authentication.
"
::= { sshsmSessionEntry 4 }
sshsmSessionSecurityName OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-only
STATUS current
DESCRIPTION "A human readable string representing the principal
in Security Model independent format.
The default transformation of the Secure Shell
Security Model dependent security ID to the
securityName
and vice versa is the identity function so that the
securityName is the same as the SSH user name.
"
::= { sshsmSessionEntry 5 }
sshsmSessionSecurityLevel OBJECT-TYPE
SYNTAX SnmpSecurityLevel
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The Level of Security at which SNMP messages can be
sent using this session, in particular, one of:
noAuthNoPriv - without authentication and
without privacy,
authNoPriv - with authentication but
without privacy,
authPriv - with authentication and
with privacy.
"
DEFVAL { authPriv }
::= { sshsmSessionEntry 6 }
sshsmSessionAuthProtocol OBJECT-TYPE
SYNTAX AutonomousType
MAX-ACCESS read-create
STATUS current
DESCRIPTION "The type of authentication protocol used by the SSH
session associated with this SSHSM session.
"
::= { sshsmSessionEntry 7 }
sshsmSessionPrivProtocol OBJECT-TYPE
SYNTAX AutonomousType
MAX-ACCESS read-create
Harrington, et al. Expires April 17, 2006 [Page 47]
Internet-Draft Secure Shell Security Model for SNMP October 2005
STATUS current
DESCRIPTION "The type of encryption protocol used by the SSH
session associated with this SSHSM session.
"
::= { sshsmSessionEntry 8 }
sshsmSessionEngineID OBJECT-TYPE
SYNTAX SnmpEngineID
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "The administratively-unique identifier for the
remote SNMP engine associated with this session.
"
::= { sshsmSessionEntry 9 }
-- -------------------------------------------------------------
-- sshsmMIB - Conformance Information
-- -------------------------------------------------------------
sshsmGroups OBJECT IDENTIFIER ::= { sshsmConformance 1 }
sshsmCompliances OBJECT IDENTIFIER ::= { sshsmConformance 2 }
-- -------------------------------------------------------------
-- Units of conformance
-- -------------------------------------------------------------
sshsmGroup OBJECT-GROUP
OBJECTS {
sshsmStatsUnsupportedSecLevels,
sshsmStatsUnknownUserNames,
sshsmStatsUnknownEngineIDs,
sshsmSessionID,
sshsmSessionTransport,
sshsmSessionAddress,
sshsmSessionUserName,
sshsmSessionSecurityName,
sshsmSessionSecurityLevel,
sshsmSessionAuthProtocol,
sshsmSessionPrivProtocol
sshsmSessionEngineID
}
STATUS current
DESCRIPTION "A collection of objects for maintaining session
information of an SNMP engine which implements the
SNMP Secure Shell Security Model.
"
::= { sshsmGroups 2 }
Harrington, et al. Expires April 17, 2006 [Page 48]
Internet-Draft Secure Shell Security Model for SNMP October 2005
-- -------------------------------------------------------------
-- 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
9. Security Considerations
This document describes a security model that would permit SNMP to
utilize SSH security services. [todo] expand as needed.
SSHv2 provides PFS for encryption keys. PFS is a major design goal
of SSH, and any well-designed keyex algorithm will provide it.
[todo] We will probably need to discuss the security implications of
password based authentication methods.
9.1. Sensitive Modifiable Objects
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
There are no management objects defined in this MIB module that have
a MAX-ACCESS clause of read-write and/or read-create. So, if this
MIB module is implemented correctly, then there is no risk that an
intruder can alter or create any management objects of this MIB
module via direct SNMP SET operations.
Harrington, et al. Expires April 17, 2006 [Page 49]
Internet-Draft Secure Shell Security Model for SNMP October 2005
9.2. Sensitive Readable Objects
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
9.3. Protocol Security
SNMP versions prior to SNMPv3 did not include adequate security.
Even if the network itself is secure (for example by using IPSec),
even then, there is no control as to who on the secure network is
allowed to access and GET/SET (read/change/create/delete) the objects
in this MIB module.
It is RECOMMENDED that implementers consider the security features as
provided by the SNMPv3 framework (see [RFC3410], section 8),
including full support for the SNMPv3 cryptographic mechanisms (for
authentication and privacy).
Further, deployment of SNMP versions prior to SNMPv3 is NOT
RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to
enable cryptographic security. It is then a customer/operator
responsibility to ensure that the SNMP entity giving access to an
instance of this MIB module is properly configured to give access to
the objects only to those principals (users) that have legitimate
rights to indeed GET or SET (change/create/delete) them.
10. IANA Considerations
IANA is requested to assign:
1. a TCP port number 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 SNMP SecurityModel for the Secure Shell Security Model, as
documented in the MIB module in this document,
4. An SSH connection protocol subsystem name for the SNMP subsystem
defined in this document.
11. Acknowledgments
The editors would like to thank Jeffrey Hutzelman and Nicholas
Harrington, et al. Expires April 17, 2006 [Page 50]
Internet-Draft Secure Shell Security Model for SNMP October 2005
Williams for sharing their SSH insights.
12. References
12.1. Normative References
[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J.
Schoenwaelder, Ed., "Structure of Management Information
Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
[RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J.
Schoenwaelder, Ed., "Textual Conventions for SMIv2",
STD 58, RFC 2579, April 1999.
[RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder,
"Conformance Statements for SMIv2", STD 58, RFC 2580,
April 1999.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, June 2000.
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An
Architecture for Describing Simple Network Management
Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,
December 2002.
[RFC3412] Case, J., Harrington, D., Presuhn, R., and B. Wijnen,
"Message Processing and Dispatching for the Simple Network
Management Protocol (SNMP)", STD 62, RFC 3412,
December 2002.
[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.
[RFC3430] Schoenwaelder, J., "Simple Network Management Protocol
Over Transmission Control Protocol Transport Mapping",
RFC 3430, December 2002.
[I-D.schoenw-snmp-tlsm]
Harrington, D. and J. Schoenwaelder, "Transport Mapping
Security Model (TMSM) for the Simple Network Management
Protocol version 3 (SNMPv3)", draft-schoenw-snmp-tlsm-02
(work in progress), May 2005.
[I-D.ietf-secsh-architecture]
Harrington, et al. Expires April 17, 2006 [Page 51]
Internet-Draft Secure Shell Security Model for SNMP October 2005
Ylonen, T. and C. Lonvick, "SSH Protocol Architecture",
draft-ietf-secsh-architecture-22 (work in progress),
March 2005.
[I-D.ietf-secsh-connect]
Lonvick, C. and T. Ylonen, "SSH Connection Protocol",
draft-ietf-secsh-connect-25 (work in progress),
March 2005.
[I-D.ietf-secsh-transport]
Lonvick, C., "SSH Transport Layer Protocol",
draft-ietf-secsh-transport-24 (work in progress),
March 2005.
[I-D.ietf-secsh-userauth]
Lonvick, C. and T. Ylonen, "SSH Authentication Protocol",
draft-ietf-secsh-userauth-27 (work in progress),
March 2005.
12.2. Informative References
[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
Management Protocol (SNMP) Applications", STD 62,
RFC 3413, December 2002.
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[I-D.ietf-netconf-prot]
Enns, R., "NETCONF Configuration Protocol",
draft-ietf-netconf-prot-09 (work in progress),
October 2005.
[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
(work in progress), August 2005.
Harrington, et al. Expires April 17, 2006 [Page 52]
Internet-Draft Secure Shell Security Model for SNMP October 2005
Appendix A. Open Issues
We need to reach consensus on some issues. I numbered the [discuss]
markers in the text for easy correlation to the issue discussions.
*** When discussing these issues, please use the provided # in the
subject line, and please limit the message to one topic at a time.
***
Here is the current list of issues from the SSHSM document where we
need to reach consensus.
#1: is it important to support anonymous user access to SNMP?
#2: a) is server authentication a requirement that SNMP will
require of the client? b) how can we verify that server
authentication was performed, or do we take simply trust the SSH
client layer to perform such authentication? c) for the common
case of DH signed by public keys, how does the client learn the
host's public key in advance, and verify that the correct key is
being used?
#3: we need some text contributed to discuss the implications of
sessions on SNMP.
#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)
#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?
#6: Are there are any wrinkles to coexistence with SNMPv1/v2c/USM?
#7: is there still a need for an "authoritative SNMP engine"?
#8: Do we need a mapping between 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 of sensitive parameters
to the agent?
#9: Can an existing R/R session be reused for notifications?
#10: a) which securityparameters must be supported for the SSHSM
model? b) Which services provided in USM are needed in TMSM/SSHSM?
C) How does the Message Processing model provide this information
to the security model via generateRequestMsg() and
processIncomingMsg() primitives?
#11: If we eliminate all msgSecurityParameters, should the
msgSecurityParameters field in the SNMPv3 message simply be a
zero-length OCTET STRING, or should it be an ASN.1 NULL?
#12: a) how does SSHSM determine whether SSH can provide the
security services requested in msgFlags? B) There were
discussions about whether it was acceptable for a transport-
mapping-model to provide stronger security than requested. Does
this need to be discussed in the SSHSM document, or should we
Harrington, et al. Expires April 17, 2006 [Page 53]
Internet-Draft Secure Shell Security Model for SNMP October 2005
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?
#13: will SSHSM be impacted by keychanges to the SSH local
datastore?
#14: MUST the SSHSM model provide mutual authentication of the
client and server, and MUST it authenticate, integrity-check, and
encrypt the messages?
#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: The SSH server doesn't necessarily authorize the name carried
in the SSH_MSG_USERAUTH_REQUEST message, but may return a
different name or list of names that are authorized to be used
given the authentication of the provided username. A) What should
be the source of the SSHSM mechanism-specific username for mapping
to securityname? 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 the edits.
#18: I currently have multiple sections, one for each known auth
mechanism. We need to discuss the parameters that need to be
cached for each, and determine whether we can collapse this into
one section. a) Using Passwords to Authenticate SNMP Principals B)
Using Public keys to Authenticate SNMP Principals C) Using Host-
based Authentication of SNMP Principals D) Using RADIUS to
Authenticate SNMP Principals
#19: RADIUS is just an instance of the password authentication
protocol. The details of RADIUS are within the SSH layer. I
don't think it is a good idea to expose this outside of SSH.
#20: How do we get the mapping from model-specific identity to a
model independent securityName?.
#21: we need to determine what data should be persistent and
stored in the LCD for notification purposes.
#22: Joe: There are a significant number of security problems
associated with mapping to a transport address which may need to
be discussed in the security considerations section.
#23: We need to discuss the circumstances under which a session
should be closed, and how an SNMP engine should determine if, and
respond if the SSH session is closed by other means
Harrington, et al. Expires April 17, 2006 [Page 54]
Internet-Draft Secure Shell Security Model for SNMP October 2005
#24: How should we enable auto-discovery?
#25: Where is the best place to call establishSession()? See the
"Sending an Outgoing Message to the Network" section for more
details on this issue.
#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).
#27: The SNMP over TCP Transport Mapping document (RFC3430) says
that TCP connections can be recreated dynamically or kept for
future use and actually leaves all that to the transport mapping.
Do we need to discuss these issues? Where? in the security
considerations?
#28: For notification tables, how do we predefine the dynamic
session identifiers?
#29: do we need to support reports? For what purpose?
#30: If we actually do not extract anything from
securityParameters, do we need to check whether this field parses
correctly?
#31: Is maxSizeResponseScopedPDU relevant? Can it be calculated
once for the session? Do we need to take into consideration the
SSH window size?
#32: For an incoming message, is using a default securityName
mapping the right thing to do?
#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?
Appendix B. Change Log from the first revision of -00-
-00- initial draft as ISMS workl product:
Authors' Addresses
David Harrington
Effective Software
Harding Rd
Portsmouth NH
USA
Phone: +1 603 436 8634
Email: dbharrington@comcast.net
Harrington, et al. Expires April 17, 2006 [Page 55]
Internet-Draft Secure Shell Security Model for SNMP October 2005
Juergen Schoenwaelder
International University Bremen
Campus Ring 1
28725 Bremen
Germany
Phone: +49 421 200-3587
Email: j.schoenwaelder@iu-bremen.de
Joseph Salowey
Cisco Systems
2901 3rd Ave
Seattle, WA 98121
USA
Email: jsalowey@cisco.com
Full Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
Harrington, et al. Expires April 17, 2006 [Page 56]
Internet-Draft Secure Shell Security Model for SNMP October 2005
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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Harrington, et al. Expires April 17, 2006 [Page 57]