WDIFF

draft-ietf-isms-transport-security-model-00.txt --> draft-ietf-isms-transport-security-model-01.txt

Network Working Group D. Harrington
Internet-Draft Huawei Technologies (USA)
Intended status: Standards Track October 11, December 29, 2006
Expires: April 14, July 2, 2007

Transport Security Model for SNMP
draft-ietf-isms-transport-security-model-00.txt
draft-ietf-isms-transport-security-model-01

Status of This Memo

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

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

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

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

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

This Internet-Draft will expire on April 14, July 2, 2007.

Abstract

This memo describes a Transport Security Model for the Simple Network
Management Protocol.

Harrington Expires April 14, July 2, 2007 [Page 1]

Internet-Draft Transport Security Model for SNMP October December 2006

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 3
1.1. The Internet-Standard Management Framework . . . . . . . . 4 3
1.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4 3
1.3. Modularity . . . . . . . . . . . . . . . . . . . . . . . . 5 4
1.4. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 5 4
1.5. Constraints . . . . . . . . . . . . . . . . . . . . . . . 6 5
2. How Transport Security Model Fits in the Architecture . . . . 6 5
2.1. Security Capabilities of this Model . . . . . . . . . . . 7 6
2.1.1. Threats . . . . . . . . . . . . . . . . . . . . . . . 7 6
2.1.2. Security Levels . . . . . . . . . . . . . . . . . . . 7 6
2.2. No Sessions . . . . . . . . . . . . . . . . . . . . . . . 7 6
2.3. Coexistence . . . . . . . . . . . . . . . . . . . . . . . 8 7
2.4. Security Parameter Passing . . . . . . . . . . . . . . . . 9 8
2.5. Notifications and Proxy . . . . . . . . . . . . . . . . . 9 8
3. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 10 8
3.1. SNMPv3 Message Fields . . . . . . . . . . . . . . . . . . 10 9
3.1.1. msgGlobalData . . . . . . . . . . . . . . . . . . . . 12 11
3.1.2. securityLevel and msgFlags . . . . . . . . . . . . . . 12 11
3.1.3. msgSecurityParameters . . . . . . . . . . . . . . . . 13 12
3.2. Cached Information and References . . . . . . . . . . . . 13 12
3.2.1. securityStateReference . . . . . . . . . . . . . . . . 14 13
3.2.2. tmStateReference . . . . . . . . . . . . . . . . . . . 14 13
4. Elements of Procedure . . . . Processing an Outgoing Message . . . . . . . . . . . . . . . . 15 14
4.1. Generating Security Processing for an Outgoing SNMP Message . . . . . . . . . . . 15 14
4.2. Security Processing Elements of Procedure for an Outgoing Message Messages . . . . . . . 16
4.3. 15
5. Processing an Incoming SNMP Message . . . . . . . . . . . 19
4.4. Prepare Data Elements from . . 16
5.1. Security Processing for an Incoming Messages Message . . . . . . . 19
4.5. Security Processing 16
5.2. Elements of Procedure for an Incoming Message Messages . . . . . . . 20
5. 17
6. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
5.1. 18
6.1. Structure of the MIB Module . . . . . . . . . . . . . . . 21
5.2. 18
6.2. Textual Conventions . . . . . . . . . . . . . . . . . . . 21
5.3. 18
6.3. The transportStats Subtree . . . . . . . . . . . . . . . . 21
5.4. The transportState Subtree . . . . . . . . . . . . . . . . 21
5.5. 18
6.4. Relationship to Other MIB Modules . . . . . . . . . . . . 22
5.5.1. 19
6.4.1. Relationship to the SNMPv2-MIB . . . . . . . . . . . . 22
5.5.2. 19
6.4.2. Relationship to the SNMP-FRAMEWORK-MIB . . . . . . . . 22
5.5.3. Relationship to the Transport-Subsystem-MIB . . . . . 22
5.5.4. 19
6.4.3. MIB Modules Required for IMPORTS . . . . . . . . . . . 22
6. 19
7. MIB module definition . . . . . . . . . . . . . . . . . . . . 22
7. 19
8. Security Considerations . . . . . . . . . . . . . . . . . . . 27
7.1. 22
8.1. MIB module security . . . . . . . . . . . . . . . . . . . 28
8. 23
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29 23
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 24
10.1. Normative References . . . . . . . . . . . . . . . . . . . 29 24
10.2. Informative References . . . . . . . . . . . . . . . . . . 30

Harrington Expires April 14, 2007 [Page 2]

Internet-Draft Transport Security Model for SNMP October 2006 25
Appendix A. Notification Tables Configuration . . . . . . . . . . 30 25
A.1. Security Model Configuration . . . . . . . . . . . . . . . 32
A.2. Transport Security Model Configuration . . . Processing . . . . . . . . . . . 33 27
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 33 27

Harrington Expires April 14, July 2, 2007 [Page 3] 2]

Internet-Draft Transport Security Model for SNMP October December 2006

1. Introduction

This memo describes a Transport Security Model for the Simple Network
Management Protocol, for use with secure transport models in the
Transport Subsystem [I-D.ietf-isms-tmsm].

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

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

1.1. The Internet-Standard Management Framework

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

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

1.2. Conventions

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

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

Harrington Expires April 14, July 2, 2007 [Page 4] 3]

Internet-Draft Transport Security Model for SNMP October December 2006

applications, or a combination of these within an administrative
domain.

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

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

1.3. Modularity

The reader is expected to have read and understood the description of
the SNMP architecture, as defined in [RFC3411],and the architecture
extension specified in "Transport Subsystem for the Simple Network
Management Protocol" [I-D.ietf-isms-tmsm], which enables the use of
external "lower layer transport" protocols to provide message
security, tied into the SNMP architecture through the transport
subsystem. The Transport Security Model is designed to work with
such lower-layer secure transport models.

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 Transport
Security Model for SNMP. These MIB objects SHOULD not be referenced
in other documents. This allows the Transport Security Model to be
designed and documented as independent and self- contained, self-contained, having no
direct impact on other modules, and allowing this module to be
upgraded and supplemented as the need arises, and to move along the
standards track on different time-lines from other modules.

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

1.4. Motivation

Version 3 of the Simple Network Management Protocol (SNMPv3) added
security to the previous versions of the protocol. The User User-based
Security Model (USM) [RFC3414] was designed to be independent of
other existing security infrastructures, to ensure it could function
when third party authentication services were not available, such as
in a broken network. As a result, USM 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.

Harrington Expires April 14, July 2, 2007 [Page 5] 4]

Internet-Draft Transport Security Model for SNMP October December 2006

This memo describes a security model that will make use of transport
models that rely on lower layer secure transports and existing and
commonly deployed security infrastructures. This security model is
designed to meet the security and operational needs of network
administrators, maximize usability in operational environments to
achieve high deployment success and at the same time minimize
implementation and deployment costs to minimize the time until
deployment is possible.

1.5. 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 effective management.
2. In times of network stress, the security protocol and its
underlying security mechanisms SHOULD NOT depend upon the ready
availability of other network services (e.g., Network Time
Protocol (NTP) or AAA protocols).
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 model should require no changes to the SNMP
architecture.
6. A security model should require no changes to the underlying
security protocol.

2. How Transport Security Model Fits in the Architecture

The Transport Security Model is designed to fit into the RFC3411
architecture as a security model in the security subsystem, and to
utilize the services of a secure transport model.

Within an engine using secure

The transport model, outgoing SNMP messages
are passed unencrypted from the message dispatcher to the transport
model, and incoming messages are passed unencrypted from the
transport model to the message dispatcher.

[todo] locate and eliminate discussion of "dispatcher" functionality.

The transport model of an model of an SNMP engine will perform the translation
between transport-specific security parameters and the SNMP-specific,
model-independent parameters. Some security parameters may also securityName and securityLevel. To
maintain the RFC3411 modularity, the transport model does not know
which securityModel will be
translated within a security model, used for compatibility with an incoming message; the ASIs
between message
processing model will determine the RFC 3411 securityModel to be used, in a
message processing model dependent manner. In an SNMPv3 message, the
Transport Security Subsystem and Model should be specified in the Message Processing message header.

Harrington Expires April 14, July 2, 2007 [Page 6] 5]

Internet-Draft Transport Security Model for SNMP October December 2006

Subsystem.

2.1. Security Capabilities of this Model

2.1.1. Threats

The Transport Security Model, when used with suitable secure
transport models, provides protection against the threats identified
by the RFC 3411 architecture [RFC3411].

Which threats are addressed depends on the transport model. The
Transport Security Model does not address any threats itself, but
delegates that responsibility to a secure transport model.

The Transport Security Model is called a security model to be
compatible with the RFC3411 architecure. However, this security
model provides no does not provide security mechanisms such as authenticatio and
encryption itself, so it SHOULD always be used with a transport model
that provides appropriate security.

2.1.2. Security Levels

The RFC 3411 architecture recognizes three levels of security:
- without authentication and without privacy (noAuthNoPriv)
- with authentication but without privacy (authNoPriv)
- with authentication and with privacy (authPriv)

The model-independent securityLevel parameter is used to request
specific levels of security for outgoing messages, and to assert that
specific levels of security were applied during the transport and
processing of incoming messages.

The transport layer algorithms used to provide security SHOULD NOT be
exposed to the Transport Security Model, s as the Transport Security
Model has no mechanisms by which it can test whether an assertion
made by a transport model is accurate.

The Transport Security Model trusts that the underlying secure
transport connection has been properly configured to support security
characteristics at least as strong as requested in securityLevel.

2.2. No Sessions

The Transport Security Model will associate state regarding each
message and each known remote engine with a single combination of
transportType, transportAddress, securityName, securityModel, and
securityLevel.

Some transport models will utilize sessions to maintain long-lived
state; others will use stateless transport. For reasons of module

Harrington Expires April 14, July 2, 2007 [Page 7] 6]

Internet-Draft Transport Security Model for SNMP October December 2006

state; others will use stateless transport. For reasons of module

independence, the Transport Security Model will make no assumptions
about there being a session of any kind. Each message may be totally
independent of other messages. Any binding of multiples messages
into a session is specific to the transport model. There may be
circumstances where having an snmp-specific session provided by a
security model is useful; such functionality is left to future
security models.

2.3. Coexistence

In RFC3411, there

There are dependencies between two primary factors which determine whether security modles
can coexist. First, there must be a mechanism to select different
security models at run-time. Second, the message model and processing of one security
should not impact the processing of another security models; model.

In the RFC3411 architecture, a message processing model determines
which security model fills in portions should be called. As of the message,
and thus must know the message format. When considering coexistence,
one must consider coexistence with other this writing, there are
three message formats processing models and three other security models.

RFC3584 describes how to transfer fields between SNMPv3 models:
SNMPv1, SNMPv2c, and SNMPv1/
v2c messages. The Transport Security Model usage of the
msgSecurityParameters fields in SNMPv3 messages will be covered
below.

The coexistence of the Transport User-based Security Model with the community-
based secruity used by Model.

The SNMPv1 and SNMPv2c can be message processing described in a
different document.

The Transport Security Model can coexist with RFC3584 (BCP
74) [RFC3584] always selects the USM SNMPv1(1) security model,
the only other currently defined security model. This can occur in
multiple ways.

o USM is combined with a non-secure transport model (the normal way
to use USM). The SNMPv3 messaging model would pass the message to for an
SNMPv1 message, or the USM SNMPv2c(2) security model for processing based on the securityModel
expressed in msgSecurityParameters.
o USM an SNMPv2c
message. Since there is combined with no field in the message format that permits
specifying a secure transport security model, which would
encapsulate the whole SNMPv3 RFC3584 message to provide secure transport,
but the global parameters specify USM as processing does not
permit the selection of security model, so
SNMPv3 would pass models other than SNMPv1 or SNMPv2.
Therefore, the wholeMessage to Transport Security Model can coexist with SNMPv1 and
SNMPv2c community-based security models, but the SNMPv3 messaging model. Transport Security
Model cannot be used with SNMPv1 or SNMPv2c messages.

The SNMPv3 messaging model would pass the message to processing defined in RFC3412 [RFC3412], extracts
the USM securityModel from the msgSecurityModel field of an incoming
SNMPv3Message. When the extracted value of msgSecurityModel is
transportSecurityModel(4), security model for processing based on is directed to the securityModel expressed
in msgSecurityParameters.
o The SNMPv3
Transport Security Model. So for an outgoing message specifies secured using
the Transport Security Model, so
SNMPv3 sends the message msgSecurityModel should be set to this security model for processing.
Should secure transport models specify the securityModel as being
the
transportSecurityModel(4).

The Transport Security Model, as well as determining the
securityname and securityLevel? Model uses its own MIB module for processing
to maintain independence from other security models. This has allows the unfortunate property
of binding specific transport models
Transport Security Model to a specific coexist with other security model.
[discuss: this must be done by models, such
as the User-based Security Model.

Note that the transport model, because only

Harrington Expires April 14, 2007 [Page 8]

Internet-Draft Transport Security Model may work with multiple
transport models, but the isAccessAllowed() primitive only accepts a
value for SNMP October 2006 the security model, not for transport model knows the message was secured at the transport
level; it makes this assertion by setting securityLevel for
incoming mesages, so models. As a result,
it is not possible that the transport
**subsystem** could handle the choice of securityModel, if all
transport models must default to an "unknown" securityLevel unless
it actually does provide a known security level. Then the
transport subsystem could check the securityLevel coming from the
transport model, and if securityLevel is not "unknown", it could
specify the transportSecurityModel. But this is a side-effect
approach that could be problematic have different access control rules for future
different transport models and
security models, so I prefer to not go that direction. It seems
simpler to have the transport model specify it should be used with use the Transport Security Model. An alternative could be to add a
table in

Harrington Expires July 2, 2007 [Page 7]

Internet-Draft Transport Security Model for SNMP December 2006

2.4. Security Parameter Passing

For outgoing messages, Transport Security Model takes input provided
by the trasnport subsystem SNMP application, converts that provided a mapping between information into suitable
transport model and security model, but that smacks parameters in a cache referenced by
tmStateReference. The wholeMsg and the tmStateReference are passed
to the appropriate transport model through a series of over-
engineering ]

2.4. Security Parameter Passing APIs, as
described in "Transport Subsystem for the Simple Network Management
Protocol" [I-D.ietf-isms-tmsm].

For incoming messages, the transport model accepts messages from the
lower layer transport, and records the transport-related information
and security-related information, including a securityName that
represents the authenticated identity, and a securityLevel that
represents the security features provided during transport, in a
cache referenced by tmStateReference. Then the
transport model passes the WholeMsg The wholeMsg and the
tmStateReference are passed to the appropriate security subsystem. model through
a series of APIs, as described in "Transport Subsystem for the Simple
Network Management Protocol" [I-D.ietf-isms-tmsm].

For outgoing messages, an incoming SNMPv3 message, the messaging model extracts the
requested securityLevel from the msgFlags field, and passes this to
the security model. The Transport Security Model takes input provided
by the SNMP application, converts verifies that information into suitable
transport and security parameters, and passes these in a cache
referenced by tmStateReference to the transport subsystem.

The cache reference is an additional parameter
securityLevel passed in the ASIs between
the transport model and the security model. Passing a model-
independent cache reference as a parameter in an ASI is consistent
with at least as strong as the securityStateReference cache already being
securityLevel passed around in the ASI. ASI securityLevel parameter.

2.5. Notifications and Proxy

The SNMP-TARGET-MIB module [RFC3413] contains objects for defining
management targets, including transportType, transportAddress,
securityName, securityModel, and securityLevel parameters, for
applications such as notifications and proxy. For the Transport
Security Model, transport type and address are configured in the
snmpTargetAddrTable, and the securityModel, securityName, and
securityLevel parameters are configured in the snmpTargetParamsTable.

The default approach is for an administrator to statically

Harrington Expires April 14, 2007 [Page 9]

Internet-Draft Transport Security Model for SNMP October 2006
preconfigure this information to identify the targets authorized to
receive notifications or perform proxy.

3. Message Formats

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. The Transport Security Model deos not work with SNMPv1 and
SNMPv2c have been declared Historic, for reasons described above, so this memo only deals with

Harrington Expires July 2, 2007 [Page 8]

Internet-Draft Transport Security Model for SNMP December 2006

SNMPv3 messages.

The processing is compatible with the RFC 3412 primitives,
generateRequestMsg() and processIncomingMsg(), that show the data
flow between the Message Processor and the security model.

3.1. SNMPv3 Message Fields

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

Harrington Expires April 14, July 2, 2007 [Page 10] 9]

Internet-Draft Transport Security Model for SNMP October December 2006

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] RFC3416
}
END

The following describes how the Transport Security Model treats
certain fields in the message:

Harrington Expires April 14, July 2, 2007 [Page 11] 10]

Internet-Draft Transport Security Model for SNMP October December 2006

3.1.1. msgGlobalData

The msgGlobalData values are set by the Message Processing model
(e.g., SNMPv3 Message Processing), and are not modified by the
Transport Security Model.

msgMaxSize is determined by the implementation.

For outgoing messages, msgSecurityModel is set by the Message
Processing model (e.g., SNMPv3) to the IANA-assigned value for the
Transport Security Model. See
http://www.iana.org/assignments/snmp-number-spaces.

For outgoing messages, the value of msgFlags is set by the Message
Processing model (e.g., SNMPv3 Message Processing), which is not
necessarily the actual securityLevel applied to the message by the
transport model.

For incoming messages, the value of msgFlags is determined by the
Message Processing model (e.g., SNMPv3 Message Processing), and the
value is passed in the securityLevel parameter in the ASI between the
messaging model and the security model.

3.1.2. securityLevel and msgFlags

For an outgoing message, securityLevel is the requested security for
the message, passed in the ASIs. If a Transport Model cannot provide
the requested securityLevel, the model MUST describe a standard
behavior that is followed for that situation. if If the Transport Model
is able to provide stronger than requested security, that may be
acceptable. If the Transport Model cannot provide at least the
requested level of security, the Transport Model MUST discard the
request and SHOULD notify the message processing model that the
request failed.

The msgFlags field in the SNMPv3 message is closely related to
securityLevel. msgFlags is Messaging Model dependent, while
securityLevel is Messaging Model independent. To maintain the
separation between subsystems, the Transport Model SHOULD NOT modify
Message Model dependent fields. As a result, msgFlags in the SNMPv3
message MAY reflect the requested securityLevel, not the actual
securityLevel applied to the message by the Transport Model.

Part of the responsibility of a Security Model is to ensure that the
actual security provided by the underlying transport layer security
mechanisms is configured to meet or exceed the securityLevel
requested. When the Security Model processes the incoming message,
it should compare the securityLevel provided by the messaging model

Harrington Expires April 14, July 2, 2007 [Page 12] 11]

Internet-Draft Transport Security Model for SNMP October December 2006

to the securityLevel provided by the transport model in
tmStateReference. If they differ, the Security Model should
determine whether the securityLevel provided by the transport model
is acceptable (e.g. the transport securityLevel is greater than or
equal to the requested securityLevel. If not, it should discard the
message. Depending on the model, the Security Model may issue a
reportPDU with a model-specific counter.

3.1.3. msgSecurityParameters

Since message security is provided by a "lower layer", and the
securityName parameter is always determined by the transport model
from the lower layer authentication method, the SNMP message does not
need to carry message security parameters within the
msgSecurityParameters field.

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

TransportSecurityParametersSyntax DEFINITIONS IMPLICIT TAGS
::= BEGIN

TransportSecurityParameters ::=
SEQUENCE {
OCTET STRING
}
END

3.2. Cached Information and References

The RFC3411 architecture uses caches to store dynamic model-specific
information, and uses references in the ASIs to indicate in a model-
independent manner which cached information must flow between
subsystems.

There are two levels of state that may need to be maintained: the
security state in a request-response pair, and potentially long-term
state relating to transport and security.

This state is maintained in caches and a Local Configuration
Datastore (LCD). 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 being
processed gets discarded, the state related to that message should
also be discarded, and if state information is available when a

Harrington Expires April 14, 2007 [Page 13]

Internet-Draft Transport Security Model for SNMP October 2006
relationship between engines is severed, such as the closing of a
transport session, the state information for that relationship might

Harrington Expires July 2, 2007 [Page 12]

Internet-Draft Transport Security Model for SNMP December 2006

also be discarded.

This document differentiates the tmStateReference from the
securityStateReference. This document does not specify an
implementation strategy, only an abstract discussion of the data that
must flow between subsystems. An implementation MAY use one cache
and one reference to serve both functions, but an implementer must be
aware of the cache-release issues to prevent the cache from being
released before a security or transport model has had an opportunity
to extract the information it needs.

3.2.1. securityStateReference

From RFC3411: "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 Local Configuration
Datastore is altered between the time of the incoming request and the
outgoing response.

A Message Processing Model has the responsibility for explicitly
releasing the cached data if such data is no longer needed. To
enable this, an abstract securityStateReference data element is
passed from the Security Model to the Message Processing Model. The
cached security data may be implicitly released via the generation of
a response, or explicitly released by using the stateRelease
primitive, as described in RFC3411 section 4.5.1."

The information saved should include the model-independent parameters
(transportType, transportAddress, securityName, securityModel, and
securityLevel), related security parameters, and other information
needed to imatch match the response with the request. The Message
Processing Model has the responsibility for explicitly releasing the
securityStateReference when such data is no longer needed. The
securityStateReference cached data may be implicitly released via the
generation of a response, or explicitly released by using the
stateRelease primitive, as described in RFC 3411 section 4.5.1."

If the transport model connection is closed between the time a
Request is received and a Response message is being prepared, then
the Response message MAY be discarded.

3.2.2. tmStateReference

For each message or transport session, information about the message
security is stored in the Local Configuration Datastore (LCD),
supplemented with a cache, to pass model- and mechanism-specific

Harrington Expires April 14, 2007 [Page 14]

Internet-Draft Transport Security Model for SNMP October 2006

parameters. The state referenced by tmStateReference may be saved
across multiple messages, as compared to securityStateReference which
is only saved for the life of a request-response pair of messages.

The format of the cache and the LCD are implementation-specific. For
ease of explanation, this document defines a MIB module to
conceptually represent the LCD, but this is not meant to contrain
implementations from doing it differently.

It is expected that the LCD will allow lookup based on the
combination of transportType, transportAddress, securityName,
securityModel, and securityLevel. It is expected that the cache
contain these values or contain pointers/references to entries in the
LCD.

It is expected that a transport model may store transport-specific
parameters in the LCD for subsequent usage.

4. Elements of Procedure

An error indication may return an OID and value for an incremented
counter and a value for securityLevel, and values for contextEngineID
and contextName for the counter, and the securityStateReference if
the information is available at the point where the error is
detected.

4.1. Generating an Outgoing SNMP Message

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

Harrington Expires April 14, 2007 [Page 15]

Internet-Draft Transport Security Model for SNMP October 2006

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 IN parameters of the prepareOutgoingMessage() ASI are used to
pass information from the dispatcher (for the application subsystem)
to the message processing subsystem.

The abstract service primitive from a with the request. The Message
Processing Model to a
security model to generate has the responsibility for explicitly releasing the
securityStateReference when such data is no longer needed. The
securityStateReference cached data may be implicitly released via the components
generation of a Request message is
generateRequestMsg(), response, or explicitly released by using the
stateRelease primitive, as described in Section 4.2.

The abstract service primitive from RFC 3411 section 4.5.1."

If the transport model connection is closed between the time a Message Processing Model to
Request is received and a
Security Model to generate Response message is being prepared, then
the components of a Response message MAY be discarded.

3.2.2. tmStateReference

For each message or transport session, information about the message
security is
generateResponseMsg(), as described stored in Section 4.2.:

Upon completion of processing, the cache to pass model- and mechanism-specific
parameters. The state referenced by tmStateReference may be saved
across multiple messages, in a Local Configuration Datastore (LCD),
as compared to securityStateReference which is only saved for the

Harrington Expires July 2, 2007 [Page 13]

Internet-Draft Transport Security Model returns
statusInformation. If the process was successful, for SNMP December 2006

life of a request-response pair of messages.

The format of the completed
message is returned, without any privacy cache and authentication applied
yet. If the process was not successful, then an errorIndication is
returned.

The OUT parameters LCD are used to pass information from the message
processing subsystem to implementation-specific.

4. Processing an Outgoing Message

An error indication may return an OID and value for an incremented
counter and a value for securityLevel, and values for contextEngineID
and contextName for the dispatcher counter, and on to the transport
subsystem:

4.2. securityStateReference if
the information is available at the point where the error is
detected.

4.1. Security Processing for an Outgoing Message

This section describes the procedure followed by the Transport
Security Model.

Harrington Expires April 14, 2007 [Page 16]

Internet-Draft the Transport
Security Model for SNMP October 2006 Model.

The parameters needed for generating a message are supplied to the
security model by the message processing model via the
generateRequestMsg() or the generateResponseMsg() ASI. The Transport
Subsystem architectural extension has added the transportDomain,
transportAddress, and tmStateReference parameters to the original
RFC3411 ASIs.

statusInformation = -- success or errorIndication
generateRequestMsg(
IN messageProcessingModel -- typically, SNMP version
IN globalData -- message header, admin data
IN maxMessageSize -- of the sending SNMP entity
IN transportDomain -- as specified by application
IN transportAddress -- as specified by application
IN securityModel -- for 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 transport info
)

Harrington Expires July 2, 2007 [Page 14]

Internet-Draft Transport Security Model for SNMP December 2006

statusInformation = -- success or errorIndication
generateResponseMsg(
IN messageProcessingModel -- typically, SNMP version
IN globalData -- message header, admin data
IN maxMessageSize -- of the sending SNMP entity
IN transportDomain -- as specified by application
IN transportAddress -- as specified by application
IN securityModel -- for 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 Expires April 14, 2007 [Page 17]

Internet-Draft Transport Security Model for SNMP October 2006

o statusInformation - An indication of whether the construction of
the message was successful. If not it contains an indication of
the problem.
o messageProcessingModel - The SNMP version number for the message
to be generated.
o globalData - The message header (i.e., its administrative
information). This data is opaque to Transport Security Model.
o maxMessageSize - The maximum message size as included in the
message. This data is not used by Transport Security Model.
o transportDomain - as specified by the application.
o transportAddress - as specified by the application.
o securityEngineID - Transport Security Model always sets this to
the snmpEngineID of the sending SNMP engine.
o 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 securityStateReference
cache is used.
o securityLevel
o scopedPDU - The message payload. The scopedPDU is opaque to
Transport Security Model.
o securityStateReference - A handle/reference to cachedSecurityData
that is used when sending an outgoing Response message. This is
the exact same securityStateReference as was generated by the
Transport Security module when processing the incoming Request
message to which this is the Response message.
o
OUT securityParameters - Always set to empty -- filled in by Transport Security
Model.
o Module
OUT wholeMsg - The fully encoded SNMP -- complete generated message ready for sending on the
wire.
o
OUT wholeMsgLength - The -- length of the encoded SNMP generated message
(wholeMsg).
o
OUT tmStateReference - a handle/reference to the session information
to be passed -- reference to the transport model. info
)

Note that the Transport Subystem architectural extension adds
transportDomain, transportAddress, and tmStateReference to these
ASIs.

4.2. Elements of Procedure for Outgoing Messages

[todo] compare to USM processing to see what fields must be filled in
by TSM before assembly.

1) verify that securityModel is transportSecurityModel. transportSecurityModel(4). If not,
then an error indication is returned to the calling message model,
and security model processing stops for this message.

2) If there is a securityStateReference, then this is a response to a
request, so extract the cached security data. This should include
transportDomain, transportAddress, securityName, securityLevel, and
securityModel, and a tmStateReference. At this point, the data cache
referenced by the securityStateReference can be released.

Harrington Expires April 14, 2007 [Page 18]

Internet-Draft Transport Security Model for SNMP October 2006

[todo: is the securityStateReference still accessible? Doesn't the
MPM release the cache before calling the security model?]

3) If there is no securityStateReference, then find or create an
entry in a Local Configuration Datastore containing the provided
transportDomain, transportAddress, securityName, securityLevel, and
securityModel, and create a tmStateReference to reference the entry.

Harrington Expires July 2, 2007 [Page 15]

Internet-Draft Transport Security Model for SNMP December 2006

4) fill in the msgSecurityModel with the value for
transportSecurityModel.

5) fill in the msgFlags corresponding to the securityLevel specified
in the parameter.

6) fill in the securityParameters with the serialization of a
zero-length zero-
length OCTET STRING.
5)

7) Combine the message parts into a wholeMsg and calculate
wholeMsgLength.
6)

8) The completed message (wholeMsg) with its length (wholeMsgLength)
and securityParameters (a zero-length octet string) and
tmStateReference is returned to the calling messaging model with the statusInformation set to success.

4.3. Processing an Incoming SNMP Message

4.4. Prepare Data Elements from Incoming Messages

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

result = -- SUCCESS or errorIndication
prepareDataElements(
IN transportDomain -- origin transport domain
IN transportAddress -- origin transport address
IN wholeMsg -- as received from the network
IN wholeMsgLength -- as received from the network
IN tmStateReference -- from the transport model
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 the
statusInformation -- success or errorIndication
-- set to success.

5. Processing an Incoming SNMP Message

An error indication may return an OID and value for an incremented
counter OID/value if error
OUT stateReference -- reference to state information
-- to be used and a value for possible Response
)

Harrington Expires April 14, 2007 [Page 19]

Internet-Draft Transport Security Model securityLevel, and values for SNMP October 2006

Note that tmStateReference has been added to this ASI.

4.5. contextEngineID
and contextName for the counter, and the securityStateReference if
the information is available at the point where the error is
detected.

5.1. Security Processing for an Incoming Message

This section describes the procedure followed by the Transport
Security Model whenever it receives an incoming message containing a
management operation on behalf of a user from a Message Processing
model. The Message Processing Model extracts some information from the
wholeMsg. The abstract service primitive from a Message Processing
Model to the Security Subsystem for a received message is:: is:

Harrington Expires July 2, 2007 [Page 16]

Internet-Draft Transport Security Model for SNMP December 2006

statusInformation = -- errorIndication or success
-- error counter OID/value if error
processIncomingMsg(
IN messageProcessingModel -- typically, SNMP version
IN maxMessageSize -- of the sending SNMP entity
IN securityParameters -- for the received message
IN securityModel -- for the received message
IN securityLevel -- Level of Security
IN wholeMsg -- as received on the wire
IN wholeMsgLength -- length as received on the wire
IN tmStateReference -- from the transport model
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

5.2. Elements of Procedure for Incoming Messages

1) verify that securityModel is transportSecurityModel(4). If not,
then an error indication is returned to the calling message model,
and security model processing stops for this message.

2) If the messageProcessingModel is SNMPv3, then the securityEngineID
is set to the local snmpEngineID, to satisfy the SNMPv3 message
processing defined in RFC 3412 section 7.2 13a).

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

2) [todo: discuss how to compare the requested security parameters
(extracted from msgFlags by the MPM), module, and the transport-model-
provided actual
security (reported in tmStateReference); compare
securityLevel, securityModel, and securityName. While a different
user-name may be used during authnentication, the model processing stops for this message.

4) if tmStateReference
should contain the model-independent securityName. This does imply
we need not refer to provide the a cache containing values
for securityName in and securityLevel, then the tsmInvalidCache counter
is incremented, an error indication is returned to the calling
module, and security model processing stops for this message.

5) Compare the securityParameters value of securityLevel in the
SNMPv3 message, right?

2) Extract cache referenced by
tmStateReference to the value of securityName from the Local Configuration
Datastore entry referenced securityLevel parameter passed
in the processIncomingMessage service primitive. If the parameter
specifies privacy (Priv), and the cache specifies no privacy (noPriv)
was provided by tmStateReference. the transport model, or the parameter specifies
authentication (auth) and the cache specifies no authentication
(noAuth) was provided by the transport model, then the [todo:
snmpInadequateSecurity] counter is incremented, and an error

Harrington Expires April 14, July 2, 2007 [Page 20] 17]

Internet-Draft Transport Security Model for SNMP October December 2006

1) The securityEngineID

indication ([todo]) is set returned to the local snmpEngineID, to satisfy calling module.

6) Extract the SNMPv3 message processing model in RFC 3412 section 7.2 13a).

3) value of securityName from the cache referenced by
tmStateReference.

7) The scopedPDU component is extracted from the wholeMsg.

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

5)The

9) The information in the tmStateReference may be saved, in an
implementation-dependent manner, in a Local Configuration Datastore
(LCD) for subsequent usage.

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

4)
tmStateReference cache.

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

6. Overview

This MIB module provides management of the Transport Security Model.
It defines some needed textual conventions, and some statistics.

5.1.

6.1. Structure of the MIB Module

Objects in this MIB module are arranged into subtrees. Each subtree
is organized as a set of related objects. The overall structure and
assignment of objects to their subtrees, and the intended purpose of
each subtree, is shown below.

5.2.

6.2. Textual Conventions

Generic and Common Textual Conventions used in this document can be
found summarized at http://www.ops.ietf.org/mib-common-tcs.html

5.3.

6.3. The transportStats Subtree

This subtree contains counters specific to the Transport Security
Model.

This subtree provides
Model, that provide information for identifying fault conditions
and performance degradation.

5.4. The transportState Subtree

This subtree contains information specific to state related to
tmStateReference. Most of the state referenced by tmStateReference conditions.

Harrington Expires April 14, July 2, 2007 [Page 21] 18]

Internet-Draft Transport Security Model for SNMP October December 2006

should be transport-model-specific, and not needed here.

5.5.

6.4. Relationship to Other MIB Modules

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

5.5.1.

6.4.1. Relationship to the SNMPv2-MIB

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

5.5.2.

6.4.2. Relationship to the SNMP-FRAMEWORK-MIB

[todo] if the TSM-MIB does not actually have dependencies on SNMP-
FRAMEWORK-MIB other than imports, then remove this paragraph.

5.5.3. Relationship to the Transport-Subsystem-MIB

The 'tmsmSession' group in the Transport-Subsystem-MIB
[I-D.ietf-isms-tmsm] is defined as being applicable to all Transport
Models. [todo] if the MIB module defined here SNMP-TRANSPORT-SM-MIB does not actually have
dependencies on Transport-Subsystem-MIB SNMP-FRAMEWORK-MIB other than imports, then remove
this paragraph.

5.5.4.

6.4.3. MIB Modules Required for IMPORTS

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

6. [RFC3411].

7. MIB module definition

TSM-MIB

SNMP-TRANSPORT-SM-MIB DEFINITIONS ::= BEGIN

IMPORTS
MODULE-IDENTITY, OBJECT-TYPE,
OBJECT-IDENTITY, mib-2, Counter32, Integer32 snmpModules, Counter32
FROM SNMPv2-SMI
TestAndIncr, AutonomousType
FROM SNMPv2-TC
MODULE-COMPLIANCE, OBJECT-GROUP

Harrington Expires April 14, 2007 [Page 22]

Internet-Draft Transport Security Model for SNMP October 2006
FROM SNMPv2-CONF
SnmpAdminString, SnmpSecurityLevel, SnmpEngineID
FROM SNMP-FRAMEWORK-MIB
TransportAddress, TransportAddressType
FROM TRANSPORT-ADDRESS-MIB
TransportAddressSSH, transportDomainSSH
FROM SSHTM-MIB
;

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

Chairs:
Juergen Quittek

Harrington Expires July 2, 2007 [Page 19]

Internet-Draft Transport Security Model for SNMP December 2006

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

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

Editor:
David Harrington
Effective Software
50 Harding Rd
Portsmouth, New Hampshire 03801
Huawei Technologies USA
1700 Alma Dr.
Plano TX 75075
USA
+1 603-436-8634
ietfdbh@comcast.net
"
DESCRIPTION "The Secure Shell Transport Security Model MIB

Copyright (C) The Internet Society IETF Trust (2006). This
version of this MIB module is part of RFC XXXX;
see the RFC itself for full legal notices.
-- NOTE to RFC editor: replace XXXX with actual RFC number

Harrington Expires April 14, 2007 [Page 23]

Internet-Draft Transport Security Model for SNMP October 2006
-- for this document and remove this note
"

REVISION "200509020000Z" "200612210000Z" -- 02 September 2005 21 December 2006
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 snmpModules xxxx }
-- RFC Ed.: replace xxxx with IANA-assigned number and
-- remove this note

-- ---------------------------------------------------------- --
-- subtrees in the TSM-MIB SNMP-TRANSPORT-SM-MIB
-- ---------------------------------------------------------- --

Harrington Expires July 2, 2007 [Page 20]

Internet-Draft Transport Security Model for SNMP December 2006

tsmNotifications OBJECT IDENTIFIER ::= { tsmMIB 0 }
tsmMIBObjects OBJECT IDENTIFIER ::= { tsmMIB 1 }
tsmConformance OBJECT IDENTIFIER ::= { tsmMIB 2 }

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

-- Statistics for the Transport Security Model

tsmStats OBJECT IDENTIFIER ::= { tsmMIBObjects 1 }

-- [todo] do we need any stats?

-- The tsmUser Group ************************************************

tsmUser OBJECT IDENTIFIER ::= { tsmMIBObjects 2 }

tsmUserSpinLock OBJECT-TYPE
SYNTAX TestAndIncr
MAX-ACCESS read-write
STATUS current
DESCRIPTION "An advisory lock used to allow several cooperating
Command Generator Applications to coordinate their
use of facilities to alter the tsmUserTable.
"
::= { tsmUser 1 }

-- The table of valid users for the SSH Transport Model ********

Harrington Expires April 14, 2007 [Page 24]

Internet-Draft Transport Security Model for SNMP October 2006

tsmUserTable OBJECT-TYPE
SYNTAX SEQUENCE OF tsmUserEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "The table of users configured in the SNMP engine's
Local Configuration Datastore (LCD).

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

1) GET(tsmUserSpinLock.0) and save in sValue.
2) SET(tsmUserSpinLock.0=sValue,
tsmUserStatus=createAndWait)

Finally, activate the new user:

3) SET(tsmUserStatus=active)

The new user should now be available and ready to be
used for SNMPv3 communication.

The use of tsmUserSpinlock is to avoid conflicts with
another SNMP command generator application which may
also be acting on the tsmUserTable.
"
::= { tsmUser 2 }

tsmUserEntry OBJECT-TYPE
SYNTAX tsmUserEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "A user configured in the SNMP engine's Local
Configuration Datastore (LCD) for the Session
Security Model.
"
INDEX { tsmUserSecurityName }
::= { tsmUserTable 1 }

tsmUserEntry ::= SEQUENCE
{
tsmUserSecurityName SnmpAdminString,
tsmUserStorageType StorageType,
tsmUserStatus RowStatus
}

tsmUserSecurityName OBJECT-TYPE

Harrington Expires April 14, 2007 [Page 25]

Internet-Draft Transport Security Model for SNMP October 2006

SYNTAX SnmpAdminString
MAX-ACCESS read-only
STATUS current
DESCRIPTION "A human readable string representing the user in
Security Model independent format.

[todo: Wehn used with transport models that perform
authentication, the tsmUserSecurityName is the
securityName passed in tmStateReference.
" for the Transport Security Model

tsmStats OBJECT IDENTIFIER ::= { tsmUserEntry tsmMIBObjects 1 }

tsmUserStorageType

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

It is an implementation issue number of messages dropped because the
tmStateReference referred to decide if a SET for
a readOnly or permanent row is accepted at all. In some
contexts this may make sense, in others it may not. If
a SET for a readOnly or permanent row is not accepted
at all, then a 'wrongValue' error must be returned. an invalid cache.
"
DEFVAL { nonVolatile }
::= { tsmUserEntry 4 tsmStats 1 }

tsmUserStatus

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

Until instances of all corresponding columns are
appropriately configured, the value number of incoming messages dropped because
the
corresponding instance of actual securtityLevel provided was less than
the tsmUserStatus column
is 'notReady'.

The RowStatus TC [RFC2579] requires that this
DESCRIPTION clause states under which circumstances
other objects in this row can be modified:

The value of this object has no effect on whether
other objects in this conceptual row can be modified. requested securityLevel.
"
::= { tsmUserEntry 5 tsmStats 2 }

Harrington Expires April 14, 2007 [Page 26]

Internet-Draft Transport Security Model for SNMP October 2006

-- -------------------------------------------------------------
-- tsmMIB - Conformance Information
-- -------------------------------------------------------------

tsmGroups OBJECT IDENTIFIER ::= { tsmConformance 1 }

tsmCompliances OBJECT IDENTIFIER ::= { tsmConformance 2 }

-- -------------------------------------------------------------
-- Units of conformance
-- -------------------------------------------------------------
tsmGroup OBJECT-GROUP
OBJECTS {
tsmInvalidCache,
tsmInadequateSecurity
}

Harrington Expires July 2, 2007 [Page 21]

Internet-Draft Transport Security Model for SNMP December 2006

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

::= { tsmGroups 2 }

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

tsmCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for SNMP engines that support
the
TSM-MIB" SNMP-TRANSPORT-SM-MIB"
MODULE
MANDATORY-GROUPS { tsmGroup }
::= { tsmCompliances 1 }

END

8. Security Considerations

This document describes a security model that permits SNMP to utilize
security services provided through an SNMP transport model. The
Transport Security Model relies on transport models for mutual
authentication, binding of keys, confidentiality and integrity. The
security threats and how those threats are mitigated should be
covered in detail in the specification of the transport model and the
underlying secure transport.

Harrington Expires April 14, 2007 [Page 27]

Internet-Draft Transport Security Model for SNMP October 2006

Transport Security Model relies on a transport model to provide an
authenticated principal for mapping to securityName, and an assertion
for mapping to securityLevel, for access control purposes.

The Transport Security Model is called a security model to be
compatible with the RFC3411 architecure. However, this security
model provides no security itself. It SHOULD always be used with a
transport model that provides security, but this is a run-time
decision of the operator or management application, or a
configuration decision of an operator.

7.1.

Harrington Expires July 2, 2007 [Page 22]

Internet-Draft Transport Security Model for SNMP December 2006

8.1. MIB module security

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

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

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

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

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

Harrington Expires April 14, 2007 [Page 28]

Internet-Draft Transport Security Model for SNMP October 2006 cryptographic
mechanisms (for authentication and privacy).

Further, deployment of SNMP versions prior to SNMPv3 is NOT
RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to
enable cryptographic security. It is then a customer/operator
responsibility to ensure that the SNMP entity giving access to an
instance of this MIB module is properly configured to give access to
the objects only to those principals (users) that have legitimate
rights to indeed GET or SET (change/create/delete) them.

9. IANA Considerations

IANA is requested to assign:
1. an SMI number under mib-2, snmpModules, for the MIB module in this
document,
2. an SnmpSecurityModel for a value, preferably 4, to identify the Transport Security Model, as
documented
in the MIB module Security Models registry at
http://www.iana.org/assignments/snmp-number-spaces. This should
result in the following table of values:

Harrington Expires July 2, 2007 [Page 23]

Internet-Draft Transport Security Model for SNMP December 2006

Value Description References
----- ----------- ----------
0 reserved for 'any' [RFC2571, RFC3411]
1 reserved for SNMPv1 [RFC2571, RFC3411]
2 reserved for SNMPv2c [RFC2571, RFC3411]
3 User-Based Security Model (USM) [RFC2571, RFC3411]
4 Transport Security Model (TSM) [RFCXXXX]

-- NOTE to RFC editor: replace XXXX with actual RFC number
-- for this document,

9. Acknowledgements document and remove this note

10. References

10.1. Normative References

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

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

[RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J.
Schoenwaelder, Ed., "Textual Conventions for
SMIv2", STD 58, RFC 2579, April 1999.

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

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

Harrington Expires April 14, 2007 [Page 29]

Internet-Draft Transport Security Model for SNMP October 2006

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

[RFC3414] Blumenthal, U. and B. Wijnen, "User-based
Security Model (USM) for version 3 of the

Harrington Expires July 2, 2007 [Page 24]

Internet-Draft Transport Security Model for SNMP December 2006

Simple Network Management Protocol (SNMPv3)",
STD 62, RFC 3414, December 2002.

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

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

[RFC3419] Daniele, M.

[RFC3584] Frye, R., Levi, D., Routhier, S., and J. Schoenwaelder, "Textual
Conventions for Transport Addresses", B.
Wijnen, "Coexistence between Version 1, Version
2, and Version 3 of the Internet-standard
Network Management Framework", BCP 74,
RFC 3419,
December 2002. 3584, August 2003.

[I-D.ietf-isms-tmsm] Harrington, D. and J. Schoenwaelder, "Transport
Mapping Security Model (TMSM) Architectural
Extension
Subsystem for the Simple Network Management
Protocol (SNMP)", draft-ietf-isms-tmsm-03 draft-ietf-isms-tmsm-05 (work
in progress), June December 2006.

10.2. Informative References

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

Appendix A. Notification Tables Configuration

The SNMP-TARGET-MIB and SNMP-NOTIFICATION-MIB [RFC3413] are used to
configure notification originators with the destinations to which
notifications should be sent.

Most of the configuration is security-model-independent and
transport-model-independent.

The values we will use in the examples for the five model-independent
security and transport parameters are:
transportType = transportDomainSSH

Harrington Expires April 14, 2007 [Page 30]

Internet-Draft Transport Security Model for SNMP October 2006 snmpSSHDomain
transportAddress = 10.0.0.1:162 192.0.2.1:162
securityModel = Transport Security Model
securityName = sampleUser
securityLevel = authPriv

The following example will configure the Notification Originator to

Harrington Expires July 2, 2007 [Page 25]

Internet-Draft Transport Security Model for SNMP December 2006

send informs to a Notification Receiver at host 10.0.0.1 192.0.2.1 port 162
using the securityName "sampleUser". The columns marked with a "*"
are the items that are Security Model or Transport Model specific.

The configuration for the "sampleUser" settings in the SNMP-VIEW-
BASED-ACM-MIB objects are not shown here for brevity. First we
configure which type of notification should be sent for this taglist
(toCRTag). In this example, we choose to send an Inform.

(preamble)
snmpNotifyTable row:
snmpNotifyName CRNotif
snmpNotifyTag toCRTag
snmpNotifyType inform
snmpNotifyStorageType nonVolatile
snmpNotifyColumnStatus createAndGo
(postamble)

Then we configure a transport address to which notifications
associated with this taglist should be sent, and we specify which
snmpTargetParamsEntry should be used (toCR) when sending to this
transport address.

(preamble)
snmpTargetAddrTable row:
snmpTargetAddrName toCRAddr
* snmpTargetAddrTDomain transportDomainSSH snmpSSHDomain
snmpTargetAddrTAddress 10.0.0.1:162 192.0.2.1:162
snmpTargetAddrTimeout 1500
snmpTargetAddrRetryCount 3
snmpTargetAddrTagList toCRTag
snmpTargetAddrParams toCR (must match below)
snmpTargetAddrStorageType nonVolatile
snmpTargetAddrColumnStatus createAndGo

(postamble)

Then we configure which prinicipal at the host should receive the
notifications associated with this taglist. Here we choose
"sampleUser", who uses the Transport Security Model.

Harrington Expires April 14, 2007 [Page 31]

Internet-Draft Transport Security Model for SNMP October 2006

(preamble)
snmpTargetParamsTable row:
snmpTargetParamsName toCR
snmpTargetParamsMPModel SNMPv3
* snmpTargetParamsSecurityModel TransportSecurityModel
* snmpTargetParamsSecurityName "sampleUser"
snmpTargetParamsSecurityLevel authPriv
snmpTargetParamsStorageType nonVolatile
snmpTargetParamsRowStatus createAndGo

(postamble)

Harrington Expires July 2, 2007 [Page 26]

Internet-Draft Transport Security Model for SNMP December 2006

A.1. Transport Security Model Processing

The Transport Security Model is called using the
generateRequestMessage() ASI, with the following parameters (* are
from the above tables):

statusInformation = -- success or errorIndication
generateRequestMsg(
IN messageProcessingModel -- *snmpTargetParamsMPModel
IN globalData -- message header, admin data
IN maxMessageSize -- of the sending SNMP entity
IN transportDomain -- *snmpTargetAddrTDomain
IN transportAddress -- *snmpTargetAddrTAddress
IN securityModel -- *snmpTargetParamsSecurityModel
IN securityEngineID -- immaterial; TSM will ignore.
IN securityName -- *snmpTargetParamsSecurityName
IN securityLevel -- *snmpTargetParamsSecurityLevel
IN scopedPDU -- message (plaintext) payload
OUT securityParameters -- filled in by Security Model Configuration

In the Module
OUT wholeMsg -- complete generated message
OUT wholeMsgLength -- length of generated message
OUT tmStateReference -- reference to transport info
)

The Transport Security Model MIB module (TSM-MIB), we configure
the Security Model Parameters. Since we are using a Transport
Security Model, we provide a pointer to will determine the appropriate transport model entry

[discuss: there are problems here. Users need additional
qualification, such as address/user or engineID/user. This is
transport-model specific. While we identify the securtyModel, there
is no ppace that has based
on the mapping from snmpTargetAddrTDomain. The selected transport model to MIB module.
A RowPointer would be more accurate, will
select the appropriate transport "session" using the
snmpTargetAddrTAddress, snmpTargetParamsSecurityName, and able to support multiple
multi-field indices, such as engineID/user or address/user, but it
would be harder for an operator
snmpTargetParamsSecurityLevel.

Appendix B. Change Log

From -00- to configure. In addition, -01-

made the transport model needs to be able to lookup an entry in the LCD, given not know anything about the address it received a message from, and security
model.
modified the username used to
perform authentication. if that name is not elements of prcedure sections, given the same as implications
of this change.
simplified elelemnts of procedure, removing most info specified in
architecture/subsystem definitons.
rethought the
securityName, then there needs to be a table to perform coexistence section
noted the username-
to-securityName conversion, and another to perform securityname-to-
username conversion. ]

(preamble)
tsmUserEntry ::= SEQUENCE
{
tsmUserSecurityName "sampleUser"
tmsUserTransportModel transportDomainSSH
tsmUserTransportParams "sshUser"
tsmUserStorageType StorageType,
tsmUserStatus RowStatus
}
An Entry from implications of the Transport Security Model on
isAccessAllowed()
modified all text related to the LCD.
removed most of the MIB module (now the TSM has no configuration
parameters).

Harrington Expires April 14, July 2, 2007 [Page 32] 27]

Internet-Draft Transport Security Model for SNMP October December 2006

A.2. Transport Model Configuration

In the Secure Shell Transport Model

added counters needed to support elements of procedure
renamed MIB module (SSH-TM-MIB), we
configure the transport model parameters.

(preamble)
sshtmUserEntry ::= SEQUENCE
{
sshtmUserName sshUser
sshtmUserSecurityName "sampleUser"
sshtmUserStorageType StorageType,
sshtmUserStatus RowStatus
}
An entry from module, and registered under snmpModules
updated IANA and Security Considerations
updated references.
modified the SSH Transport Model MIB module

Appendix B. Change Log notification configurations.

From SSHSM-04- to Transport-security-model-00

added tsmUserTable
updated Appendix - Notification Tables Configuration
remove open/closed issue appendices
changed tmSessionReference to tmStateReference

Author's Address

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

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

Harrington Expires April 14, July 2, 2007 [Page 33] 28]

Internet-Draft Transport Security Model for SNMP October December 2006

Full Copyright Statement

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

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

Intellectual Property

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

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

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

Acknowledgement

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

Harrington Expires April 14, July 2, 2007 [Page 34] 29]

----