draft-ietf-isms-tmsm-06.txt   draft-ietf-isms-tmsm-07.txt 
Network Working Group D. Harrington Network Working Group D. Harrington
Internet-Draft Huawei Technologies (USA) Internet-Draft Huawei Technologies (USA)
Updates: 3411,3412,3414,3417 J. Schoenwaelder Updates: 3411,3412,3414,3417 J. Schoenwaelder
(if approved) International University Bremen (if approved) International University Bremen
Intended status: Standards Track February 5, 2007 Intended status: Standards Track March 4, 2007
Expires: August 9, 2007 Expires: September 5, 2007
Transport Subsystem for the Simple Network Management Protocol (SNMP) Transport Subsystem for the Simple Network Management Protocol (SNMP)
draft-ietf-isms-tmsm-06 draft-ietf-isms-tmsm-07
Status of This Memo Status of This Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 36 skipping to change at page 1, line 36
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 9, 2007. This Internet-Draft will expire on September 5, 2007.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document defines a Transport Subsystem, extending the Simple This document defines a Transport Subsystem, extending the Simple
Network Management Protocol (SNMP) architecture defined in RFC 3411. Network Management Protocol (SNMP) architecture defined in RFC 3411.
This document defines a subsystem to contain Transport Models, This document defines a subsystem to contain Transport Models,
comparable to other subsystems in the RFC3411 architecture. As work comparable to other subsystems in the RFC3411 architecture. As work
is being done to expand the transport to include secure transport is being done to expand the transport to include secure transport
such as SSH and TLS, using a subsystem will enable consistent design such as SSH and TLS, using a subsystem will enable consistent design
and modularity of such Transport Models. This document identifies and modularity of such Transport Models. This document identifies
and describes some key aspects that need to be considered for any and describes some key aspects that need to be considered for any
Transport Model for SNMP. Transport Model for SNMP.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. The Internet-Standard Management Framework . . . . . . . . 4 1.1. The Internet-Standard Management Framework . . . . . . . . 3
1.2. Where this Extension Fits . . . . . . . . . . . . . . . . 4 1.2. Where this Extension Fits . . . . . . . . . . . . . . . . 3
1.3. Conventions . . . . . . . . . . . . . . . . . . . . . . . 6 1.3. Conventions . . . . . . . . . . . . . . . . . . . . . . . 5
2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Requirements of a Transport Model . . . . . . . . . . . . . . 8 3. Requirements of a Transport Model . . . . . . . . . . . . . . 7
3.1. Message Security Requirements . . . . . . . . . . . . . . 8 3.1. Message Security Requirements . . . . . . . . . . . . . . 7
3.1.1. Security Protocol Requirements . . . . . . . . . . . . 8 3.1.1. Security Protocol Requirements . . . . . . . . . . . . 7
3.2. SNMP Requirements . . . . . . . . . . . . . . . . . . . . 9 3.2. SNMP Requirements . . . . . . . . . . . . . . . . . . . . 8
3.2.1. Architectural Modularity Requirements . . . . . . . . 9 3.2.1. Architectural Modularity Requirements . . . . . . . . 8
3.2.2. Access Control Requirements . . . . . . . . . . . . . 13 3.2.2. Access Control Requirements . . . . . . . . . . . . . 12
3.2.3. Security Parameter Passing Requirements . . . . . . . 14 3.2.3. Security Parameter Passing Requirements . . . . . . . 13
3.2.4. Separation of Authentication and Authorization . . . . 15 3.2.4. Separation of Authentication and Authorization . . . . 14
3.3. Session Requirements . . . . . . . . . . . . . . . . . . . 16 3.3. Session Requirements . . . . . . . . . . . . . . . . . . . 14
3.3.1. Session Establishment Requirements . . . . . . . . . . 17 3.3.1. Session Establishment Requirements . . . . . . . . . . 15
3.3.2. Session Maintenance Requirements . . . . . . . . . . . 18 3.3.2. Session Maintenance Requirements . . . . . . . . . . . 16
3.3.3. Message security versus session security . . . . . . . 18 3.3.3. Message security versus session security . . . . . . . 16
4. Scenario Diagrams for the Transport Subsystem . . . . . . . . 19 4. Scenario Diagrams and the Transport Subsystem . . . . . . . . 17
4.1. Command Generator or Notification Originator . . . . . . . 19 5. Cached Information and References . . . . . . . . . . . . . . 17
4.2. Command Responder . . . . . . . . . . . . . . . . . . . . 21 5.1. securityStateReference . . . . . . . . . . . . . . . . . . 18
5. Cached Information and References . . . . . . . . . . . . . . 22 5.2. tmStateReference . . . . . . . . . . . . . . . . . . . . . 18
5.1. securityStateReference . . . . . . . . . . . . . . . . . . 23 6. Abstract Service Interfaces . . . . . . . . . . . . . . . . . 19
5.2. tmStateReference . . . . . . . . . . . . . . . . . . . . . 24 6.1. sendMessage ASI . . . . . . . . . . . . . . . . . . . . . 19
6. Abstract Service Interfaces . . . . . . . . . . . . . . . . . 24 6.2. Other Outgoing ASIs . . . . . . . . . . . . . . . . . . . 20
6.1. sendMessage ASI . . . . . . . . . . . . . . . . . . . . . 24 6.3. The receiveMessage ASI . . . . . . . . . . . . . . . . . . 21
6.2. Other Outgoing ASIs . . . . . . . . . . . . . . . . . . . 25 6.4. Other Incoming ASIs . . . . . . . . . . . . . . . . . . . 22
6.3. The receiveMessage ASI . . . . . . . . . . . . . . . . . . 26 7. Security Considerations . . . . . . . . . . . . . . . . . . . 23
6.4. Other Incoming ASIs . . . . . . . . . . . . . . . . . . . 27 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
7. Security Considerations . . . . . . . . . . . . . . . . . . . 28 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 10.1. Normative References . . . . . . . . . . . . . . . . . . . 24
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 10.2. Informative References . . . . . . . . . . . . . . . . . . 25
10.1. Normative References . . . . . . . . . . . . . . . . . . . 29 Appendix A. Parameter Table . . . . . . . . . . . . . . . . . . . 26
10.2. Informative References . . . . . . . . . . . . . . . . . . 30 A.1. ParameterList.csv . . . . . . . . . . . . . . . . . . . . 26
Appendix A. Parameter Table . . . . . . . . . . . . . . . . . . . 31 Appendix B. Why tmStateReference? . . . . . . . . . . . . . . . . 28
A.1. ParameterList.csv . . . . . . . . . . . . . . . . . . . . 31 B.1. Define an Abstract Service Interface . . . . . . . . . . . 28
Appendix B. Why tmStateReference? . . . . . . . . . . . . . . . . 33 B.2. Using an Encapsulating Header . . . . . . . . . . . . . . 28
B.1. Define an Abstract Service Interface . . . . . . . . . . . 33 B.3. Modifying Existing Fields in an SNMP Message . . . . . . . 29
B.2. Using an Encapsulating Header . . . . . . . . . . . . . . 33 B.4. Using a Cache . . . . . . . . . . . . . . . . . . . . . . 29
B.3. Modifying Existing Fields in an SNMP Message . . . . . . . 34 Appendix C. Open Issues . . . . . . . . . . . . . . . . . . . . . 29
B.4. Using a Cache . . . . . . . . . . . . . . . . . . . . . . 34 Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 30
Appendix C. Open Issues . . . . . . . . . . . . . . . . . . . . . 34
Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 35
1. Introduction 1. Introduction
This document defines a Transport Subsystem, extending the Simple This document defines a Transport Subsystem, extending the Simple
Network Management Protocol (SNMP) architecture defined in [RFC3411]. Network Management Protocol (SNMP) architecture defined in [RFC3411].
This document identifies and describes some key aspects that need to This document identifies and describes some key aspects that need to
be considered for any Transport Model for SNMP. be considered for any Transport Model for SNMP.
1.1. The Internet-Standard Management Framework 1.1. The Internet-Standard Management Framework
skipping to change at page 10, line 17 skipping to change at page 9, line 17
Transport Model might perform the translation of transport security Transport Model might perform the translation of transport security
parameters to/from security-model-independent parameters. parameters to/from security-model-independent parameters.
To accommodate this, an implementation-specific cache of transport- To accommodate this, an implementation-specific cache of transport-
specific information will be described (not shown), and the data specific information will be described (not shown), and the data
flows between the Transport Subsystem and the Transport Dispatch, flows between the Transport Subsystem and the Transport Dispatch,
between the Message Dispatch and the Message Processing Subsystem, between the Message Dispatch and the Message Processing Subsystem,
and between the Message Processing Subsystem and the Security and between the Message Processing Subsystem and the Security
Subsystem will be extended to pass security-model-independent values. Subsystem will be extended to pass security-model-independent values.
New Security Models may also be defined that understand how to work New Security Models may also be defined that understand how to work
with the modified ASIs and the cache. One such Security Mode, the with the modified ASIs and the cache. One such Security Model, the
Transport Security Model, is defined in Transport Security Model, is defined in
[I-D.ietf-isms-transport-security-model]
The following diagram depicts the SNMPv3 architecture including the The following diagram depicts the SNMPv3 architecture including the
new Transport Subsystem defined in this document, and a new Transport new Transport Subsystem defined in this document, and a new Transport
Security Model defined in [I-D.ietf-isms-transport-security-model]. Security Model defined in [I-D.ietf-isms-transport-security-model].
+------------------------------+ +------------------------------+
| Network | | Network |
+------------------------------+ +------------------------------+
^ ^ ^ ^ ^ ^
| | | | | |
skipping to change at page 13, line 51 skipping to change at page 13, line 5
The securityName MUST be mapped from the mechanism-specific The securityName MUST be mapped from the mechanism-specific
authenticated identity, and this mapping must be done for incoming authenticated identity, and this mapping must be done for incoming
messages before the Security Model passes securityName to the Message messages before the Security Model passes securityName to the Message
Processing Model via the processIncoming ASI. This translation from Processing Model via the processIncoming ASI. This translation from
a mechanism-specific authenticated identity to a securityName might a mechanism-specific authenticated identity to a securityName might
be done by the Transport Model, and the securityName is then provided be done by the Transport Model, and the securityName is then provided
to the Security Model via the tmStateReference to be passed to the to the Security Model via the tmStateReference to be passed to the
Message Processing Model. Message Processing Model.
If the type of authentication provided by the transport layer (e.g.,
TLS) is considered adequate to secure and/or encrypt the message, but
inadequate to provide the desired granularity of access control
(e.g., user-based), then a second authentication (e.g., one provided
via a RADIUS server) MAY be used to provide the authentication
identity which is mapped to the securityName. This approach would
require a good analysis of the potential for man-in-the-middle
attacks or masquerade possibilities.
3.2.3. Security Parameter Passing Requirements 3.2.3. Security Parameter Passing Requirements
RFC3411 section 4 describes abstract data flows between the RFC3411 section 4 describes abstract data flows between the
subsystems, models and applications within the architecture. subsystems, models and applications within the architecture.
Abstract Service Interfaces describe the flow of data, passing model- Abstract Service Interfaces describe the flow of data, passing model-
independent information between subsystems within an engine. The independent information between subsystems within an engine. The
RFC3411 architecture has no ASI parameters for passing security RFC3411 architecture has no ASI parameters for passing security
information between the Transport Subsystem and the dispatcher, or information between the Transport Subsystem and the dispatcher, or
between the dispatcher and the Message Processing Model. This between the dispatcher and the Message Processing Model. This
document defines or modifies ASIs for this purpose. document defines or modifies ASIs for this purpose.
skipping to change at page 15, line 17 skipping to change at page 14, line 10
For incoming messages, even when a secure Transport Model provides For incoming messages, even when a secure Transport Model provides
security services, a Security Model might provide some security security services, a Security Model might provide some security
functionality that can only be provided after the message version or functionality that can only be provided after the message version or
other parameters are extracted from the message. other parameters are extracted from the message.
3.2.4. Separation of Authentication and Authorization 3.2.4. Separation of Authentication and Authorization
The RFC3411 architecture defines a separation of authentication and The RFC3411 architecture defines a separation of authentication and
authorization (access control), and a Transport Model that provides authorization (access control), and a Transport Model that provides
security services should take care to not violate this separation. A security services should take care to not violate this separation. A
Transport Model must not specify how the securityModel and Transport Model does not know which securityModel will be used for an
incoming message, so must not specify how the securityModel and
securityName could be dynamically mapped to an access control securityName could be dynamically mapped to an access control
mechanism, such as a VACM-style groupName. mechanism, such as a VACM-style groupName.
The RECOMMENDED approach is to pass the model-independent security The RECOMMENDED approach is to pass the model-independent security
parameters via the isAccessAllowed ASI, and perform the mapping from parameters via the isAccessAllowed ASI, and perform the mapping from
the model-independent security parameters to an access-control-model- the model-independent security parameters to an access-control-model-
dependent policy within the Access Control Model. The dependent policy within the Access Control Model. The
isAccessAllowed ASI is used for passing the securityModel, isAccessAllowed ASI is used for passing the securityModel,
securityName, and securityLevel parameters that are independent of securityName, and securityLevel parameters that are independent of
any specific security model and any specific access control model to any specific security model and any specific access control model to
skipping to change at page 15, line 47 skipping to change at page 14, line 41
control) capabilities, and to support authorization schemes, such as control) capabilities, and to support authorization schemes, such as
VACM, that do not perform their own authentication. VACM, that do not perform their own authentication.
The View-based Access Control Model uses the securityModel and the The View-based Access Control Model uses the securityModel and the
securityName as inputs to check for access rights. It determines the securityName as inputs to check for access rights. It determines the
groupName as a function of securityModel and securityName. Providing groupName as a function of securityModel and securityName. Providing
a binding outside the Access Control Subsystem might create a binding outside the Access Control Subsystem might create
dependencies that could make it harder to develop alternate models of dependencies that could make it harder to develop alternate models of
access control, such as one built on UNIX groups or Windows domains. access control, such as one built on UNIX groups or Windows domains.
To provide support for protocols which simultaneously send
information for authentication and authorization (access control),
such as RADIUS [RFC2865], access-control-model-specific information
might be cached or otherwise made available to the Access Control
Subsystem, e.g., via a MIB table similar to the
vacmSecurityToGroupTable, so the Access Control Subsystem can create
an appropriate binding between the access-control-model-independent
securityModel and securityName and an access-control-model-specific
policy. This would be highly undesirable, however, if it creates a
dependency between a Transport Model or a Security Model and an
Access Control Model.
3.3. Session Requirements 3.3. Session Requirements
Some secure transports might have a notion of sessions, while other Some secure transports might have a notion of sessions, while other
secure transports might provide channels or other session-like secure transports might provide channels or other session-like
mechanism. Throughout this document, the term session is used in a mechanism. Throughout this document, the term session is used in a
broad sense to cover sessions, channels, and session-like mechanisms. broad sense to cover sessions, channels, and session-like mechanisms.
Session refers to an association between two SNMP engines that Session refers to an association between two SNMP engines that
permits the transmission of one or more SNMP messages within the permits the transmission of one or more SNMP messages within the
lifetime of the session. How the session is actually established, lifetime of the session. How the session is actually established,
opened, closed, or maintained is specific to a particular Transport opened, closed, or maintained is specific to a particular Transport
Model. Model.
Sessions are not part of the SNMP architecture defined in [RFC3411], Sessions are not part of the SNMP architecture defined in [RFC3411],
but are considered desirable because the cost of authentication can but are considered desirable because the cost of authentication can
be amortized over potentially many transactions. be amortized over potentially many transactions.
The architecture defined in [RFC3411] does not include a session The architecture defined in [RFC3411] does not include a session
selector in the Abstract Service Interfaces, and neither is that done selector in the Abstract Service Interfaces, and neither is that done
for the Transport Subsystem, so an SNMP application has no mechanism for the Transport Subsystem, so an SNMP application has no mechanism
to select a session using the ASIs except by passing a unique to select a session using the ASIs except by passing a unique
combination of transportDomain, transportAddress, securityName, combination of transportDomain, transportAddress, securityName, and
securityModel, and securityLevel. Implementers, of course, might securityLevel. Implementers, of course, might provide non-standard
provide non-standard mechanisms to select sessions. The mechanisms to select sessions. The transportDomain and
transportDomain and transportAddress identify the transport transportAddress identify the transport connection to a remote
connection to a remote network node; the securityName identifies network node; the securityName identifies which security principal to
which security principal to communicate with at that address (e.g., communicate with at that address (e.g., different NMS applications),
different NMS applications), and the securityModel and securityLevel and the securityLevel might permit selection of different sets of
might permit selection of different sets of security properties for security properties for different purposes (e.g., encrypted SETs vs.
different purposes (e.g., encrypted SETs vs. non-encrypted GETs). non-encrypted GETs).
All Transport Models should discuss the impact of sessions on SNMP
usage, including how to establish/open a transport session (i.e., how
it maps to the concepts of session-like mechanisms of the underlying
protocol), how to behave when a session cannot be established, how to
close a session properly, how to behave when a session is closed
improperly, the session security properties, session establishment
overhead, and session maintenance overhead.
To reduce redundancy, this document describes aspects that are To reduce redundancy, this document describes aspects that are
expected to be common to all Transport Model sessions. expected to be common to all Transport Model sessions.
3.3.1. Session Establishment Requirements 3.3.1. Session Establishment Requirements
SNMP applications must provide the transportDomain, transportAddress, SNMP applications provide the transportDomain, transportAddress,
securityName, securityModel, and securityLevel to be used for a securityName, and securityLevel to be used to identify a session in a
session. transport-independent manner.
SNMP Applications might have no knowledge of whether the session that
will be used to carry commands was initially established as a
notification session, or a request-response session, and SHOULD NOT
make any assumptions based on knowing the direction of the session.
If an administrator or Transport Model designer wants to
differentiate a session established for different purposes, such as a
notification session versus a request-response session, the
application can use different securityNames or transport addresses
(e.g., port 161 vs. port 162) for different purposes.
An SNMP engine containing an application that initiates
communication, e.g., a Command Generator or Notification Originator,
must be able to attempt to establish a session for delivery if a
session does not yet exist. If a session cannot be established then
the message is discarded.
Sessions are usually established by the Transport Model when no For an outgoing message, securityLevel is the requested security for
appropriate session is found for an outgoing message, but sessions the message, passed in the ASIs. If the Transport Model cannot
might be established in advance to support features such as provide at least the requested level of security, the Transport Model
notifications. How sessions are established in advance is beyond the SHOULD discard the message and notify the dispatcher that sending the
scope of this document. message failed.
Sessions are initiated by notification originators when there is no A Transport Model determines whether an approrpiate session exists
currently established connection that can be used to send the (transportDomain, transportAddress, securityName, and securityLevel)
notification. For a client-server security protocol, this might for an outgoing message. If an appropriate session does not yet
require provisioning authentication credentials on the agent, either exist, the Transport Model attempts to establish a session for
statically or dynamically, so the client/agent can successfully delivery . If a session cannot be established then the message is
authenticate to a notification receiver. discarded and the dispatcher should be notified that sending the
message failed.
A Transport Model must be able to determine whether a session does or Depending on the secure transport protocol, session establishment
does not exist, and must be able to determine which session has the might require provisioning authentication credentials on the agent,
appropriate security characteristics (transportDomain, either statically or dynamically, so the client/agent can
transportAddress, securityName, securityModel, and securityLevel) for successfully authenticate to a receiver.
an outgoing message.
A Transport Model implementation MAY reuse an already established The Transport Subsystem has no knowledge of pdutype, so cannot
session with the appropriate transportDomain, transportAddress, distinguish between a session created to carry different pduTypes.
securityName, securityModel, and securityLevel characteristics for
delivery of a message containing a different pduType than originally
caused the session to be created. For example, an implementation
that has an existing session originally established to receive a
request MAY use that session to send an outgoing notification, and
MAY use a session that was originally established to send a
notification to send a request. Responses SHOULD be returned using
the same session that carried the corresponding request message.
Reuse of sessions is not required for conformance.
If a session can be reused for a different pduType, but a receiver is To differentiate a session established for different purposes, such
not prepared to accept different pduTypes over the same session, then as a notification session versus a request-response session, an
the message MAY be dropped by the receiver. application can use different securityNames or transport addresses
(e.g., port 161 vs. port 162).
3.3.2. Session Maintenance Requirements 3.3.2. Session Maintenance Requirements
A Transport Model can tear down sessions as needed. It might be A Transport Model can tear down sessions as needed. It might be
necessary for some implementations to tear down sessions as the necessary for some implementations to tear down sessions as the
result of resource constraints, for example. result of resource constraints, for example.
The decision to tear down a session is implementation-dependent. The decision to tear down a session is implementation-dependent.
While it is possible for an implementation to automatically tear down While it is possible for an implementation to automatically tear down
each session once an operation has completed, this is not recommended each session once an operation has completed, this is not recommended
skipping to change at page 19, line 9 skipping to change at page 17, line 6
in the session which can be used to prevent the replay and reordering in the session which can be used to prevent the replay and reordering
of messages within a session. If each session uses new keys, then a of messages within a session. If each session uses new keys, then a
cross-session replay attack will be unsuccessful; that is, an cross-session replay attack will be unsuccessful; that is, an
attacker cannot successfully replay on one session a message he attacker cannot successfully replay on one session a message he
observed from another session. A good security protocol will also observed from another session. A good security protocol will also
protect against replay attacks _within_ a session; that is, an protect against replay attacks _within_ a session; that is, an
attacker cannot successfully replay a message observed earlier in the attacker cannot successfully replay a message observed earlier in the
same session. same session.
A Transport Model session will have a single transportDomain, A Transport Model session will have a single transportDomain,
transportAddress, securityModel, securityName and securityLevel transportAddress, securityName and securityLevel associated with it.
associated with it. If an exchange between communicating engines If an exchange between communicating engines requires a different
requires a different securityLevel or is on behalf of a different securityLevel or is on behalf of a different securityName, then
securityName, or uses a different securityModel, then another session another session would be needed. An immediate consequence of this is
would be needed. An immediate consequence of this is that that implementations SHOULD be able to maintain some reasonable
implementations SHOULD be able to maintain some reasonable number of number of concurrent sessions.
concurrent sessions.
For Transport Models, securityName should be specified during session For Transport Models, securityName should be specified during session
setup, and associated with the session identifier. setup, and associated with the session identifier.
SNMPv3 was designed to support multiple levels of security, SNMPv3 was designed to support multiple levels of security,
selectable on a per-message basis by an SNMP application, because, selectable on a per-message basis by an SNMP application, because,
for example, there is not much value in using encryption for a for example, there is not much value in using encryption for a
Commander Generator to poll for potentially non-sensitive performance Commander Generator to poll for potentially non-sensitive performance
data on thousands of interfaces every ten minutes; the encryption data on thousands of interfaces every ten minutes; the encryption
might add significant overhead to processing of the messages. might add significant overhead to processing of the messages.
Some Transport Models might support only specific authentication and Some Transport Models might support only specific authentication and
encryption services, such as requiring all messages to be carried encryption services, such as requiring all messages to be carried
using both authentication and encryption, regardless of the security using both authentication and encryption, regardless of the security
level requested by an SNMP application. A Transport Model may level requested by an SNMP application. A Transport Model may
upgrade the requested security level, i.e. noAuthNoPriv and upgrade the requested security level, i.e. noAuthNoPriv and
authNoPriv MAY be sent over an authenticated and encrypted session. authNoPriv MAY be sent over an authenticated and encrypted session.
4. Scenario Diagrams for the Transport Subsystem 4. Scenario Diagrams and the Transport Subsystem
RFC3411 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.6.1,
the diagram doesn't show an ASI for sending an SNMP request to the
network or for receiving an SNMP response message from the network.
In section 4.6.2, the diagram doesn't show the ASIs to receive an
SNMP message from the network, or to send an SNMP message to the
network.
4.1. Command Generator or Notification Originator
This diagram from RFC3411 4.6.1 shows how a Command Generator or RFC3411 section 4.6.1 and 4.6.2 provide scenario diagrams to
Notification Originator application [RFC3413] requests that a PDU be illustrate how an outgoing message is created, and how an incoming
sent, and how the response is returned (asynchronously) to that message is processed. RFC3411 does not define ASIs for "Send SNMP
application. Request Message to Network" or "Receive SNMP Response Message from
Network", and does not define ASIs for "Receive SNMP Message from
Network" or "Send SNMP message to Network".
This document defines a sendMessage ASI to send SNMP messages to the This document defines a sendMessage ASI to send SNMP messages to the
network, and a receiveMessage ASI to receive SNMP messages from the network, regardless of pduType, and a receiveMessage ASI to receive
network. SNMP messages from the network, regardless of pdutype.
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 | | |
|<-------------------| | |
| | | |
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) sent back to the network.
This document defines the sendMessage and receiveMessage ASIs for
this purpose.
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 | |
5. Cached Information and References 5. Cached Information and References
The RFC3411 architecture uses caches to store dynamic model-specific The RFC3411 architecture uses caches to store dynamic model-specific
information, and uses references in the ASIs to indicate in a model- information, and uses references in the ASIs to indicate in a model-
independent manner which cached information flows between subsystems. independent manner which cached information flows between subsystems.
There are two levels of state that might need to be maintained: the There are two levels of state that might need to be maintained: the
security state in a request-response pair, and potentially long-term security state in a request-response pair, and potentially long-term
state relating to transport and security. state relating to transport and security.
skipping to change at page 23, line 29 skipping to change at page 18, line 25
securityStateReference. This document does not specify an securityStateReference. This document does not specify an
implementation strategy, only an abstract description of the data implementation strategy, only an abstract description of the data
that flows between subsystems. An implementation might use one cache that flows between subsystems. An implementation might use one cache
and one reference to serve both functions, but an implementer must be and one reference to serve both functions, but an implementer must be
aware of the cache-release issues to prevent the cache from being aware of the cache-release issues to prevent the cache from being
released before a security or Transport Model has had an opportunity released before a security or Transport Model has had an opportunity
to extract the information it needs. to extract the information it needs.
5.1. securityStateReference 5.1. securityStateReference
From RFC3411: "For each message received, the Security Model caches The securityStateReference parameter is defined in RFC3411.
the state information such that a Response message can be generated securityStateReference is not accessible to models of the Transport
using the same security information, even if the Local Configuration Subsystem.
Datastore is altered between the time of the incoming request and the
outgoing response." To enable this, an abstract
securityStateReference data element, defined in RFC3411 section
A.1.5, is passed from the Security Model to the Message Processing
Model.
The information saved should include the model-independent parameters
(transportDomain, transportAddress, securityName, securityModel, and
securityLevel), related security parameters, and other information
needed to match the response with the request. The related security
parameters may include transport-specific security information.
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 ASI, as defined 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.
5.2. tmStateReference 5.2. tmStateReference
For each message or transport session, information about the message For each transport session, information about the message security is
security is stored in a cache, which may include model- and stored in a cache to pass model- and mechanism-specific parameters.
mechanism-specific parameters. The tmStateReference is passed The state referenced by tmStateReference may be saved across multiple
between subsystems to provide a handle for the cache. A Transport messages, in a Local Configuration Datastore (LCD), as compared to
Model may store transport-specific parameters in the cache for securityStateReference which is usually only saved for the life of a
subsequent usage. Since the contents of a cache are meaningful only request-response pair of messages.
within an implementation, and not on-the-wire, the format of the
cache is implementation-specific.
The state referenced by tmStateReference might be saved in a Local For security reasons, if a secure transport session is closed between
Configuration Datastore (LCD) to make it available across multiple the time a request message is received and the corresponding response
messages, as compared to securityStateReference which is designed to message is sent, then the response message MUST be discarded, even if
be saved only for the life of a request-response pair of messages. a new session has been established. The tmStateReference captured
It is expected that an LCD will allow lookup based on the combination during processing of an incoming message SHOULD include a transport-
of transportDomain, transportAddress, securityName, securityModel, specific session identifier. Each Security Model SHOULD pass a
and securityLevel, and that the cache contain these values to tmSameSession parameter in the tmStateReference cache for outgoing
reference entries in the LCD. messages to indicate whether the same session must be used for the
outgoing message as was used for the corresponding incoming message.
If the session identified in the tmStateReference does not match the
current established session, the message MUST be discarded, and the
dispatcher should be notified the sending of the message failed.
Since the contents of a cache are meaningful only within an
implementation, and not on-the-wire, the format of the cache and the
LCD are implementation-specific.
6. Abstract Service Interfaces 6. Abstract Service Interfaces
Abstract service interfaces have been defined by RFC 3411 to describe Abstract service interfaces have been defined by RFC 3411 to describe
the conceptual data flows between the various subsystems within an the conceptual data flows between the various subsystems within an
SNMP entity, and to help keep the subsystems independent of each SNMP entity, and to help keep the subsystems independent of each
other except for the common parameters. other except for the common parameters.
This document follows the example of RFC3411 regarding the release of This document follows the example of RFC3411 regarding the release of
state information, and regarding error indications. state information, and regarding error indications.
1) The release of state information is not always explicitly 1) The release of state information is not always explicitly
specified in a transport model. As a general rule, if state specified in a transport model. As a general rule, if state
information is available when a message gets discarded, the message- information is available when a message gets discarded, the message-
state information should also be released, and if state information state information should also be released, and if state information
is available when a session is closed, the session state information is available when a session is closed, the session state information
should also be released. should also be released. Note that keeping sensitive security
information longer than necessary might introduce potential
vulnerabilities to an implementation.
2) An error indication in statusInformation may include an OID and 2) An error indication in statusInformation may include an OID and
value for an incremented counter and a value for securityLevel, and value for an incremented counter and a value for securityLevel, and
values for contextEngineID and contextName for the counter, and the values for contextEngineID and contextName for the counter, and the
securityStateReference if the information is available at the point securityStateReference if the information is available at the point
where the error is detected. where the error is detected.
6.1. sendMessage ASI 6.1. sendMessage ASI
The sendMessage ASI is used to pass a message from the Dispatcher to The sendMessage ASI is used to pass a message from the Dispatcher to
skipping to change at page 26, line 14 skipping to change at page 20, line 52
The tmStateReference parameter of generateRequestMsg or The tmStateReference parameter of generateRequestMsg or
generateResponseMsg is passed in the return parameters of the generateResponseMsg is passed in the return parameters of the
Security Subsystem to the Message Processing Subsystem. If a cache Security Subsystem to the Message Processing Subsystem. If a cache
exists for a session identifiable from transportDomain, exists for a session identifiable from transportDomain,
transportAddress, securityModel, securityName, and securityLevel, transportAddress, securityModel, securityName, and securityLevel,
then an appropriate Security Model might create a tmStateReference to then an appropriate Security Model might create a tmStateReference to
the cache and pass that as an OUT parameter. the cache and pass that as an OUT parameter.
If one does not exist, the Security Model might create a cache If one does not exist, the Security Model might create a cache
referenced by tmStateReference. This information might include referenced by tmStateReference. This information might include
transportDomain, transportAddress, the securityModel, the transportDomain, transportAddress, the securityLevel, and the
securityLevel, and the securityName, plus any model or mechanism- securityName, plus any model or mechanism-specific details. The
specific details. The contents of the cache may be incomplete until contents of the cache may be incomplete until the Transport Model has
the Transport Model has established a session. What information is established a session. What information is passed, and how this
passed, and how this information is determined, is implementation and information is determined, is implementation and security-model-
security-model-specific. specific.
The prepareOutgoingMessage ASI passes tmStateReference from the The prepareOutgoingMessage ASI passes tmStateReference from the
Message Processing Subsystem to the dispatcher. How or if the Message Processing Subsystem to the dispatcher. How or if the
Message Processing Subsystem modifies or utilizes the contents of the Message Processing Subsystem modifies or utilizes the contents of the
cache is message-processing-model-specific. cache is message-processing-model-specific.
This may sound underspecified, but keep in mind that a message This may sound underspecified, but keep in mind that a message
processing model might have access to all the information from the processing model might have access to all the information from the
cache and from the message, and have no need to call a Security Model cache and from the message, and have no need to call a Security Model
to do any processing; an application might choose a Security Model to do any processing; an application might choose a Security Model
skipping to change at page 31, line 33 skipping to change at page 26, line 33
Protocol Architecture", Protocol Architecture",
RFC 4251, January 2006. RFC 4251, January 2006.
[RFC4741] Enns, R., "NETCONF [RFC4741] Enns, R., "NETCONF
Configuration Protocol", Configuration Protocol",
RFC 4741, December 2006. RFC 4741, December 2006.
[I-D.ietf-isms-transport-security-model] Harrington, D., "Transport [I-D.ietf-isms-transport-security-model] Harrington, D., "Transport
Security Model for SNMP", d Security Model for SNMP", d
raft-ietf-isms-transport- raft-ietf-isms-transport-
security-model-02 (work in security-model-03 (work in
progress), January 2007. progress), February 2007.
Appendix A. Parameter Table Appendix A. Parameter Table
Following is a Comma-separated-values (CSV) formatted matrix useful Following is a Comma-separated-values (CSV) formatted matrix useful
for tracking data flows into and out of the dispatcher, Transport, for tracking data flows into and out of the dispatcher, Transport,
Message Processing, and Security Subsystems. This will be of most Message Processing, and Security Subsystems. This will be of most
use to designers of models, to understand what information is use to designers of models, to understand what information is
available at which points in the processing, following the RFC3411 available at which points in the processing, following the RFC3411
architecture (and this subsystem). Import this into your favorite architecture (and this subsystem). Import this into your favorite
spreadsheet or other CSV compatible application. You will need to spreadsheet or other CSV compatible application. You will need to
skipping to change at page 35, line 5 skipping to change at page 30, line 5
approach of passing a model-independent reference to a model- approach of passing a model-independent reference to a model-
dependent cache is consistent with the securityStateReference already dependent cache is consistent with the securityStateReference already
being passed around in the RFC3411 ASIs. being passed around in the RFC3411 ASIs.
Appendix C. Open Issues Appendix C. Open Issues
NOTE to RFC editor: If this section is empty, then please remove this NOTE to RFC editor: If this section is empty, then please remove this
open issues section before publishing this document as an RFC. (If open issues section before publishing this document as an RFC. (If
it is not empty, please send it back to the editor to resolve. it is not empty, please send it back to the editor to resolve.
o MUST responses go back on the same session? o MUST responses go back on the same transport session? How is this
o How should we describe the case where a management system wants to accomplished since the TM does not know pduType, and subsystems
keep session info available for inspection after a session has with knowledge of pdutype do not known about transport sessions.
closed? see "Abstract Service Interfaces"
o Do Informs work correctly? o Do Informs work correctly?
o How does a Transport Model know whether a message is a
notification or a request/response?
o cache contents - do we define this?
Appendix D. Change Log Appendix D. Change Log
NOTE to RFC editor: Please remove this change log before publishing NOTE to RFC editor: Please remove this change log before publishing
this document as an RFC. this document as an RFC.
Changes from -06- to -07-
o Removed discussion of double authentication
o Removed all direct and indirect references to pduType by Transport
Subsystem
o Added warning regarding keeping sensitive security informaiton
available longer than needed.
o Removed knowledge of securityStateReference from Transport
Subsystem.
o Changed transport session identifier to not include securityModel,
since this is not known for incoming messages until the message
processing model.
Changes from revision -05- to -06- Changes from revision -05- to -06-
mostly editorial changes mostly editorial changes
removed some paragraphs considered unnecessary removed some paragraphs considered unnecessary
added Updates to header added Updates to header
modified some text to get the security details right modified some text to get the security details right
modified text re: ASIs so they are not API-like modified text re: ASIs so they are not API-like
cleaned up some diagrams cleaned up some diagrams
cleaned up RFC2119 language cleaned up RFC2119 language
added section numbers to citations to RFC3411 added section numbers to citations to RFC3411
 End of changes. 29 change blocks. 
309 lines changed or deleted 150 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/