draft-ietf-isms-tmsm-09.txt   draft-ietf-isms-tmsm-10.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) Jacobs University Bremen (if approved) Jacobs University Bremen
Intended status: Standards Track July 7, 2007 Intended status: Standards Track September 15, 2007
Expires: January 8, 2008 Expires: March 18, 2008
Transport Subsystem for the Simple Network Management Protocol (SNMP) Transport Subsystem for the Simple Network Management Protocol (SNMP)
draft-ietf-isms-tmsm-09 draft-ietf-isms-tmsm-10
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 January 8, 2008. This Internet-Draft will expire on March 18, 2008.
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,
skipping to change at page 2, line 29 skipping to change at page 2, line 29
3.2.1. Architectural Modularity Requirements . . . . . . . . 8 3.2.1. Architectural Modularity Requirements . . . . . . . . 8
3.2.2. Access Control Requirements . . . . . . . . . . . . . 12 3.2.2. Access Control Requirements . . . . . . . . . . . . . 12
3.2.3. Security Parameter Passing Requirements . . . . . . . 13 3.2.3. Security Parameter Passing Requirements . . . . . . . 13
3.2.4. Separation of Authentication and Authorization . . . . 14 3.2.4. Separation of Authentication and Authorization . . . . 14
3.3. Session Requirements . . . . . . . . . . . . . . . . . . . 15 3.3. Session Requirements . . . . . . . . . . . . . . . . . . . 15
3.3.1. Session Establishment Requirements . . . . . . . . . . 15 3.3.1. Session Establishment Requirements . . . . . . . . . . 15
3.3.2. Session Maintenance Requirements . . . . . . . . . . . 16 3.3.2. Session Maintenance Requirements . . . . . . . . . . . 16
3.3.3. Message security versus session security . . . . . . . 17 3.3.3. Message security versus session security . . . . . . . 17
4. Scenario Diagrams and the Transport Subsystem . . . . . . . . 18 4. Scenario Diagrams and the Transport Subsystem . . . . . . . . 18
5. Cached Information and References . . . . . . . . . . . . . . 18 5. Cached Information and References . . . . . . . . . . . . . . 18
5.1. securityStateReference . . . . . . . . . . . . . . . . . . 18 5.1. securityStateReference . . . . . . . . . . . . . . . . . . 19
5.2. tmStateReference . . . . . . . . . . . . . . . . . . . . . 19 5.2. tmStateReference . . . . . . . . . . . . . . . . . . . . . 19
6. Abstract Service Interfaces . . . . . . . . . . . . . . . . . 19 6. Abstract Service Interfaces . . . . . . . . . . . . . . . . . 20
6.1. sendMessage ASI . . . . . . . . . . . . . . . . . . . . . 20 6.1. sendMessage ASI . . . . . . . . . . . . . . . . . . . . . 20
6.2. Other Outgoing ASIs . . . . . . . . . . . . . . . . . . . 20 6.2. Other Outgoing ASIs . . . . . . . . . . . . . . . . . . . 21
6.3. The receiveMessage ASI . . . . . . . . . . . . . . . . . . 22 6.3. The receiveMessage ASI . . . . . . . . . . . . . . . . . . 23
6.4. Other Incoming ASIs . . . . . . . . . . . . . . . . . . . 22 6.4. Other Incoming ASIs . . . . . . . . . . . . . . . . . . . 23
7. Security Considerations . . . . . . . . . . . . . . . . . . . 24 7. Security Considerations . . . . . . . . . . . . . . . . . . . 25
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 7.1. Coexistence, Security Parameters, and Access Control . . . 26
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27
10.1. Normative References . . . . . . . . . . . . . . . . . . . 25 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
10.2. Informative References . . . . . . . . . . . . . . . . . . 26 10.1. Normative References . . . . . . . . . . . . . . . . . . . 27
Appendix A. Why tmStateReference? . . . . . . . . . . . . . . . . 27 10.2. Informative References . . . . . . . . . . . . . . . . . . 28
A.1. Define an Abstract Service Interface . . . . . . . . . . . 27 Appendix A. Why tmStateReference? . . . . . . . . . . . . . . . . 29
A.2. Using an Encapsulating Header . . . . . . . . . . . . . . 27 A.1. Define an Abstract Service Interface . . . . . . . . . . . 29
A.3. Modifying Existing Fields in an SNMP Message . . . . . . . 28 A.2. Using an Encapsulating Header . . . . . . . . . . . . . . 29
A.4. Using a Cache . . . . . . . . . . . . . . . . . . . . . . 28 A.3. Modifying Existing Fields in an SNMP Message . . . . . . . 30
Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . . 28 A.4. Using a Cache . . . . . . . . . . . . . . . . . . . . . . 30
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 29 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . . 30
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 31
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 4, line 47 skipping to change at page 4, line 47
| +-------------------------------------------------------------+ | | +-------------------------------------------------------------+ |
| | | |
+-------------------------------------------------------------------+ +-------------------------------------------------------------------+
The transport mappings defined in RFC3417 do not provide lower-layer The transport mappings defined in RFC3417 do not provide lower-layer
security functionality, and thus do not provide transport-specific security functionality, and thus do not provide transport-specific
security parameters. This document updates RFC3411 and RFC3417 by security parameters. This document updates RFC3411 and RFC3417 by
defining an architectural extension and ASIs that transport mappings defining an architectural extension and ASIs that transport mappings
(models) can use to pass transport-specific security parameters to (models) can use to pass transport-specific security parameters to
other subsystems, including transport-specific security parameters other subsystems, including transport-specific security parameters
translated into the transport-independent securityName and translated into transport-independent securityName and securityLevel
securityLevel. parameters
The Secure Shell Transport Model [I-D.ietf-isms-secshell] and the
Transport Security Model [I-D.ietf-isms-transport-security-model]
utilize the Transport Subsystem.
1.3. Conventions 1.3. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
The key words "must", "must not", "required", "shall", "shall not", Non uppercased versions of the keywords should be read as in normal
"should", "should not", "recommended", "may", and "optional" in this English. They will usually, but not always, be used in a context
document are not to be interpreted as described in RFC2119. They relating to compatibility with the RFC3411 architecture or the
will usually, but not always, be used in a context relating to subsystem defined here, but which might have no impact on on-the-wire
compatibility with the RFC3411 architecture or the subsystem defined compatibility. These terms are used as guidance for designers of
here, but which might have no impact on on-the-wire compatibility. proposed IETF models to make the designs compatible with RFC3411
These terms are used as guidance for designers of proposed IETF subsystems and Abstract Service Interfaces (see section 3.2).
models to make the designs compatible with RFC3411 subsystems and Implementers are free to implement differently. Some usages of these
Abstract Service Interfaces (see section 3.2). Implementers are free lowercase terms are simply normal English usage.
to implement differently. Some usages of these lowercase terms are
simply normal English usage.
Some terminology used in this document was defined as part of the For consistency with SNMP-related specifications, this document
IETF SNMPv3 Standard (STD62) or existed in normal English before the favors terminology as defined in STD62 rather than favoring
informational 'Internet Security Glossary' [RFC2828] was published. terminology that is consistent with non-SNMP specifications that use
For consistency with related specifications, where necessary, this different variations of the same terminology. This is consistent
document favors terminology consistent with STD62 rather than with with the IESG decision to not require the SNMPv3 terminology be
the Internet Security Glossary. This is consistent with the IESG modified to match the usage of other non-SNMP specifications when
decision to not require the SNMPv3 terminology be modified to match SNMPv3 was advanced to Full Standard.
RFC2828 when SNMPv3 was advanced to Full Standard.
2. Motivation 2. Motivation
Just as there are multiple ways to secure one's home or business, in Just as there are multiple ways to secure one's home or business, in
a continuum of alternatives, there are multiple ways to secure a a continuum of alternatives, there are multiple ways to secure a
network management protocol. Let's consider three general network management protocol. Let's consider three general
approaches. approaches.
In the first approach, an individual could sit on his front porch In the first approach, an individual could sit on his front porch
waiting for intruders. In the second approach, he could hire an waiting for intruders. In the second approach, he could hire an
skipping to change at page 11, line 7 skipping to change at page 11, line 7
| +-------------+ +---------+ +--------------+ +-------------+ | | +-------------+ +---------+ +--------------+ +-------------+ |
| ^ ^ | | ^ ^ |
| | | | | | | |
| v v | | v v |
| +----------------------------------------------+ | | +----------------------------------------------+ |
| | MIB instrumentation | SNMP entity | | | MIB instrumentation | SNMP entity |
+-------------------------------------------------------------------+ +-------------------------------------------------------------------+
3.2.1.1. Processing Differences between USM and Secure Transport 3.2.1.1. Processing Differences between USM and Secure Transport
USM and secure transports differ is the processing order and USM and secure transports differ in the processing order and
responsibilities within the RFC3411 architecture. While the steps responsibilities within the RFC3411 architecture. While the steps
are the same, they occur in a different order, and may be done by are the same, they occur in a different order, and may be done by
different subsystems. The following lists illustrate the difference different subsystems. The following lists illustrate the difference
in the flow and the responsibility for different processing steps for in the flow and the responsibility for different processing steps for
incoming messages when using USM and when using a secure transport. incoming messages when using USM and when using a secure transport.
(Note that these lists are simplified for illustrative purposes, and (Note that these lists are simplified for illustrative purposes, and
do not represent all details of processing. Transport Models must do not represent all details of processing. Transport Models must
provide the detailed elements of procedure.) provide the detailed elements of procedure.)
With USM and other Security Models, security processing starts when With USM and other Security Models, security processing starts when
skipping to change at page 12, line 15 skipping to change at page 12, line 15
4) determine the SNMP Security Model and parameters (Message 4) determine the SNMP Security Model and parameters (Message
Processing Model) Processing Model)
5) verify securityLevel [Security Model] 5) verify securityLevel [Security Model]
6) determine the pduType in the decrypted portions (Message 6) determine the pduType in the decrypted portions (Message
Processing Model), and Processing Model), and
7) pass on the decrypted portions with model-independent security 7) pass on the decrypted portions with model-independent security
parameters parameters
If a message is secured using a secure transport layer, then the If a message is secured using a secure transport layer, then the
Transport Model should provide the translation from the authenticated Transport Model should provide the translation from the authenticated
identity (e.g., an SSH user name) to the securityName in step 3. identity (e.g., an SSH user name) to a model-independent securityName
in step 2.
3.2.1.3. Passing Information between Engines 3.2.1.3. Passing Information between Engines
A secure Transport Model will establish an authenticated and/or A secure Transport Model will establish an authenticated and/or
encrypted tunnel between the Transport Models of two SNMP engines. encrypted tunnel between the Transport Models of two SNMP engines.
After a transport layer tunnel is established, then SNMP messages can After a transport layer tunnel is established, then SNMP messages can
be sent through the tunnel from one SNMP engine to the other SNMP be sent through the tunnel from one SNMP engine to the other SNMP
engine. Transport Models MAY support sending multiple SNMP messages engine. Transport Models MAY support sending multiple SNMP messages
through the same tunnel. through the same tunnel.
skipping to change at page 15, line 48 skipping to change at page 15, line 49
communicate with at that address (e.g., different NMS applications), communicate with at that address (e.g., different NMS applications),
and the securityLevel might permit selection of different sets of and the securityLevel might permit selection of different sets of
security properties for different purposes (e.g., encrypted SETs vs. security properties for different purposes (e.g., encrypted SETs vs.
non-encrypted GETs). non-encrypted GETs).
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 provide the transportDomain, transportAddress, SNMP has no mechanism to specify a transport session using the ASIs
securityName, and securityLevel to be used to identify a session in a except by passing a unique combination transportDomain,
transport-independent manner. transportAddress, securityName, and securityLevel to be used to
identify a session in a transport-independent manner. SNMP
applications provide the transportDomain, transportAddress,
securityName, and securityLevel to be used to create a session.
For an outgoing message, securityLevel is the requested security for For an outgoing message, securityLevel is the requested security for
the message, passed in the ASIs. If the Transport Model cannot the message, passed in the ASIs. If the Transport Model cannot
provide at least the requested level of security, the Transport Model provide at least the requested level of security, the Transport Model
SHOULD discard the message and notify the dispatcher that sending the SHOULD discard the message and notify the dispatcher that
message failed. establishing a session and sending the message failed.
A Transport Model determines whether an appropriate session exists A Transport Model determines whether an appropriate session exists
(transportDomain, transportAddress, securityName, and securityLevel) (transportDomain, transportAddress, securityName, and securityLevel)
for an outgoing message. If an appropriate session does not yet for an outgoing message. If an appropriate session does not yet
exist, the Transport Model attempts to establish a session for exist, the Transport Model attempts to establish a session for
delivery . If a session cannot be established then the message is delivery . If a session cannot be established then the message is
discarded and the dispatcher should be notified that sending the discarded and the dispatcher should be notified that sending the
message failed. message failed.
Depending on the secure transport protocol, session establishment Transport session establishment might require provisioning
might require provisioning authentication credentials on the agent, authentication credentials at an engine, either statically or
either statically or dynamically, so the client/agent can dynamically. How this is done is dependent on the transport model
successfully authenticate to a receiver. and the implementation.
The Transport Subsystem has no knowledge of pdutype, so cannot The Transport Subsystem has no knowledge of pduType, so cannot
distinguish between a session created to carry different pduTypes. distinguish between a session created to carry different pduTypes.
To differentiate a session established for different purposes, such To differentiate a session established for different purposes, such
as a notification session versus a request-response session, an as a notification session versus a request-response session, an
application can use different securityNames or transport addresses. application can use different securityNames or transport addresses.
For example, in SNMPv1, UDP ports 161 and 162 were used to For example, in SNMPv1, UDP ports 161 and 162 were used to
differentiate types of traffic. New transport models may define a differentiate types of traffic. New transport models may define a
single well-known port for all traffic types. Administrators might single well-known port for all traffic types. Administrators might
choose to define one port for SNMP request-response traffic, but choose to define one port for SNMP request-response traffic, but
configure notifications to be sent to a different port. configure notifications to be sent to a different port.
skipping to change at page 17, line 15 skipping to change at page 17, line 18
If a Transport Model defines MIB module objects to maintain session If a Transport Model defines MIB module objects to maintain session
state information, then the Transport Model MUST define what SHOULD state information, then the Transport Model MUST define what SHOULD
happen to the objects when a related session is torn down, since this happen to the objects when a related session is torn down, since this
will impact interoperability of the MIB module. will impact interoperability of the MIB module.
3.3.3. Message security versus session security 3.3.3. Message security versus session security
A Transport Model session is associated with state information that A Transport Model session is associated with state information that
is maintained for its lifetime. This state information allows for is maintained for its lifetime. This state information allows for
the application of various security services to multiple messages. the application of various security services to multiple messages.
Cryptographic keys established at the beginning of the session SHOULD Cryptographic keys associated with the transport session SHOULD be
be used to provide authentication, integrity checking, and encryption used to provide authentication, integrity checking, and encryption
services for data that is communicated during the session. The services, as needed, for data that is communicated during the
cryptographic protocols used to establish keys for a Transport Model session. The cryptographic protocols used to establish keys for a
session SHOULD ensure that fresh new session keys are generated for Transport Model session SHOULD ensure that fresh new session keys are
each session. In addition sequence information might be maintained generated for each session. In addition sequence information might
in the session which can be used to prevent the replay and reordering be maintained in the session which can be used to prevent the replay
of messages within a session. If each session uses new keys, then a and reordering of messages within a session. If each session uses
cross-session replay attack will be unsuccessful; that is, an new keys, then a cross-session replay attack will be unsuccessful;
attacker cannot successfully replay on one session a message he that is, an attacker cannot successfully replay on one session a
observed from another session. A good security protocol will also message he observed from another session. A good security protocol
protect against replay attacks _within_ a session; that is, an will also protect against replay attacks _within_ a session; that is,
attacker cannot successfully replay a message observed earlier in the an attacker cannot successfully replay a message observed earlier in
same session. the same session.
A Transport Model session will have a single transportDomain, A Transport Model session will have a single transportDomain,
transportAddress, securityName and securityLevel associated with it. transportAddress, securityName and securityLevel associated with it.
If an exchange between communicating engines requires a different If an exchange between communicating engines requires a different
securityLevel or is on behalf of a different securityName, then securityLevel or is on behalf of a different securityName, then
another session would be needed. An immediate consequence of this is another session would be needed. An immediate consequence of this is
that implementations SHOULD be able to maintain some reasonable that implementations SHOULD be able to maintain some reasonable
number of concurrent sessions. number of concurrent sessions.
For Transport Models, securityName should be specified during session For Transport Models, securityName should be specified during session
skipping to change at page 18, line 17 skipping to change at page 18, line 21
RFC3411 section 4.6.1 and 4.6.2 provide scenario diagrams to RFC3411 section 4.6.1 and 4.6.2 provide scenario diagrams to
illustrate how an outgoing message is created, and how an incoming illustrate how an outgoing message is created, and how an incoming
message is processed. RFC3411 does not define ASIs for "Send SNMP message is processed. RFC3411 does not define ASIs for "Send SNMP
Request Message to Network" or "Receive SNMP Response Message from Request Message to Network" or "Receive SNMP Response Message from
Network", and does not define ASIs for "Receive SNMP Message from Network", and does not define ASIs for "Receive SNMP Message from
Network" or "Send SNMP message to Network". 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, regardless of pduType, and a receiveMessage ASI to receive network, regardless of pduType, and a receiveMessage ASI to receive
SNMP messages from the network, regardless of pdutype. SNMP messages from the network, regardless of pduType.
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 19, line 16 skipping to change at page 19, line 22
For each transport session, information about the message security is For each transport session, information about the message security is
stored in a cache to pass model- and mechanism-specific parameters. stored in a cache to pass model- and mechanism-specific parameters.
The state referenced by tmStateReference may be saved across multiple The state referenced by tmStateReference may be saved across multiple
messages, in a Local Configuration Datastore (LCD), as compared to messages, in a Local Configuration Datastore (LCD), as compared to
securityStateReference which is usually only saved for the life of a securityStateReference which is usually only saved for the life of a
request-response pair of messages. request-response pair of messages.
For security reasons, if a secure transport session is closed between For security reasons, if a secure transport session is closed between
the time a request message is received and the corresponding response the time a request message is received and the corresponding response
message is sent, then the response message MUST be discarded, even if message is sent, then the response message SHOULD be discarded, even
a new session has been established. The tmStateReference captured if a new session has been established. The SNMPv3 WG decided that
during processing of an incoming message SHOULD include a transport- this should be a SHOULD architecturally, and it is a security-model-
specific session identifier. Each Security Model SHOULD pass a specific decision whether to REQUIRE this.
tmSameSession parameter in the tmStateReference cache for outgoing
messages to indicate whether the same session must be used for the Since a transport model does not know whether a message contains a
outgoing message as was used for the corresponding incoming message. response, and transport session information is transport-model-
If the session identified in the tmStateReference does not match the specific, the tmStateReference contains two pieces of information for
current established session, the message MUST be discarded, and the performing the request-response transport session pairing.
dispatcher should be notified the sending of the message failed.
Each transport model that supports sessions and supports the
tmStateReference cache SHOULD include a transport-specific session
identifier in the cache for an incoming message, so that if a
security model requests the same session, the transport model can
determine whether the current existing session is the same as the
session used for the incoming request.
Each Security Model that supports the tmStateReference cache SHOULD
pass a tmSameSession parameter in the tmStateReference cache for
outgoing messages to indicate whether the same session MUST be used
for the outgoing message as was used for the corresponding incoming
message.
If the same session requirement is indicated by the security model,
but the session identified in the tmStateReference does not match the
current established transport session, i.e., it is not the same
session, then 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 Since the contents of a cache are meaningful only within an
implementation, and not on-the-wire, the format of the cache and the implementation, and not on-the-wire, the format of the cache and the
LCD are implementation-specific. 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
skipping to change at page 20, line 12 skipping to change at page 20, line 36
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
the appropriate Transport Model for sending. the appropriate Transport Model for sending.
In the diagram in section 4.6.1 of RFC 3411, the sendMessage ASI
replaces the text "Send SNMP Request Message to Network". In section
4.6.2, the sendMessage ASI replaces the text "Send SNMP Message to
Network"
If present and valid, the tmStateReference refers to a cache If present and valid, the tmStateReference refers to a cache
containing transport-model-specific parameters for the transport and containing transport-model-specific parameters for the transport and
transport security. How the information in the cache is used is transport security. How the information in the cache is used is
transport-model-dependent and implementation-dependent. How a transport-model-dependent and implementation-dependent. How a
tmStateReference is determined to be present and valid is tmStateReference is determined to be present and valid is
implementation-dependent. implementation-dependent.
This may sound underspecified, but keep in mind that a transport This may sound underspecified, but a transport model might be
model might be something like SNMP over UDP over IPv6, where no something like SNMP over UDP over IPv6, where no security is
security is provided, so it might have no mechanisms for utilizing a provided, so it might have no mechanisms for utilizing a securityName
securityName and securityLevel. and securityLevel.
statusInformation = statusInformation =
sendMessage( sendMessage(
IN destTransportDomain -- transport domain to be used IN destTransportDomain -- transport domain to be used
IN destTransportAddress -- transport address to be used IN destTransportAddress -- transport address to be used
IN outgoingMessage -- the message to send IN outgoingMessage -- the message to send
IN outgoingMessageLength -- its length IN outgoingMessageLength -- its length
IN tmStateReference -- reference to transport state IN tmStateReference -- reference to transport state
) )
6.2. Other Outgoing ASIs 6.2. Other Outgoing ASIs
A tmStateReference parameter has been added to the A tmStateReference parameter has been added to the
prepareOutgoingMessage, generateRequestMsg, and generateResponseMsg prepareOutgoingMessage, prepareResponseMessage, generateRequestMsg,
ASIs as an OUT parameter. The transportDomain and transportAddress and generateResponseMsg ASIs as an OUT parameter. The
parameters have been added to the generateRequestMsg, and transportDomain and transportAddress parameters have been added to
generateResponseMsg ASIs as IN parameters (not shown). the generateRequestMsg, and generateResponseMsg ASIs as IN parameters
(not shown).
statusInformation = -- success or errorIndication statusInformation = -- success or errorIndication
prepareOutgoingMessage( prepareOutgoingMessage(
IN transportDomain -- transport domain to be used IN transportDomain -- transport domain to be used
IN transportAddress -- transport address to be used IN transportAddress -- transport address to be used
IN messageProcessingModel -- typically, SNMP version IN messageProcessingModel -- typically, SNMP version
IN securityModel -- Security Model to use IN securityModel -- Security Model to use
IN securityName -- on behalf of this principal IN securityName -- on behalf of this principal
IN securityLevel -- Level of Security requested IN securityLevel -- Level of Security requested
IN contextEngineID -- data from/at this entity IN contextEngineID -- data from/at this entity
skipping to change at page 21, line 26 skipping to change at page 22, line 4
IN PDU -- SNMP Protocol Data Unit IN PDU -- SNMP Protocol Data Unit
IN expectResponse -- TRUE or FALSE IN expectResponse -- TRUE or FALSE
IN sendPduHandle -- the handle for matching IN sendPduHandle -- the handle for matching
incoming responses incoming responses
OUT destTransportDomain -- destination transport domain OUT destTransportDomain -- destination transport domain
OUT destTransportAddress -- destination transport address OUT destTransportAddress -- destination transport address
OUT outgoingMessage -- the message to send OUT outgoingMessage -- the message to send
OUT outgoingMessageLength -- its length OUT outgoingMessageLength -- its length
OUT tmStateReference -- (NEW) reference to transport state OUT tmStateReference -- (NEW) reference to transport state
) )
statusInformation = -- success or errorIndication
prepareResponseMessage(
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 maxSizeResponseScopedPDU -- maximum size able to accept
IN stateReference -- reference to state information
-- as presented with the request
IN statusInformation -- success or errorIndication
-- error counter OID/value if error
OUT destTransportDomain -- destination transport domain
OUT destTransportAddress -- destination transport address
OUT outgoingMessage -- the message to send
OUT outgoingMessageLength -- its length
OUT tmStateReference -- (NEW) reference to transport state
)
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 OUT parameters of the Security
Security Subsystem to the Message Processing Subsystem. If a cache Subsystem to the Message Processing Subsystem. If a cache exists for
exists for a session identifiable from transportDomain, a session identifiable from transportDomain, transportAddress,
transportAddress, securityModel, securityName, and securityLevel, securityModel, securityName, and securityLevel, then an appropriate
then an appropriate Security Model might create a tmStateReference to Security Model might create a tmStateReference to the cache and pass
the cache and pass that as an OUT parameter. 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 securityLevel, and the transportDomain, transportAddress, the securityLevel, and the
securityName, plus any model or mechanism-specific details. The securityName, plus any model or mechanism-specific details. The
contents of the cache may be incomplete until the Transport Model has contents of the cache may be incomplete until the Transport Model has
established a session. What information is passed, and how this established a session. What information is passed, and how this
information is determined, is implementation and security-model- information is determined, is implementation and 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 a message processing model might
processing model might have access to all the information from the have access to all the information from the cache and from the
cache and from the message, and have no need to call a Security Model message, and an application might specify a Security Model such as
to do any processing; an application might choose a Security Model USM to authenticate and secure the SNMP message, but also specify a
such as USM to authenticate and secure the SNMP message, but also secure transport such as that provided by the SSH Transport Model to
utilize a secure transport such as that provided by the SSH Transport send the message to its destination.
Model to send the message to its destination.
6.3. The receiveMessage ASI 6.3. The receiveMessage ASI
If one does not exist, the Transport Model might create a cache If one does not exist, the Transport Model might create a cache
referenced by tmStateReference. If present, this information might referenced by tmStateReference. If present, this information might
include transportDomain, transportAddress, securityLevel, and include transportDomain, transportAddress, securityLevel, and
securityName, plus model or mechanism-specific details. How this securityName, plus model or mechanism-specific details. How this
information is determined is implementation and transport-model- information is determined is implementation and transport-model-
specific. specific.
This may sound underspecified, but keep in mind that a transport In the diagram in section 4.6.1 of RFC 3411, the receiveMessage ASI
model might be something like SNMP over UDP over IPv6, where no replaces the text "Receive SNMP Response Message from Network". In
security is provided, so it might have no mechanisms for determining section 4.6.2, the receiveMessage ASI replaces the text "Receive SNMP
a securityName and securityLevel. Message from Network"
This may sound underspecified, but a transport model might be
something like SNMP over UDP over IPv6, where no security is
provided, so it might have no mechanisms for determining a
securityName and securityLevel.
The Transport Model does not know the securityModel for an incoming The Transport Model does not know the securityModel for an incoming
message; this will be determined by the Message Processing Model in a message; this will be determined by the Message Processing Model in a
message-processing-model-dependent manner. message-processing-model-dependent manner.
The receiveMessage ASI is used to pass a message from the Transport The receiveMessage ASI is used to pass a message from the Transport
Subsystem to the Dispatcher. Subsystem to the Dispatcher.
statusInformation = statusInformation =
receiveMessage( receiveMessage(
skipping to change at page 24, line 13 skipping to change at page 25, line 13
cache is message-processing-model-specific. cache is message-processing-model-specific.
The processIncomingMessage ASI passes tmStateReference from the The processIncomingMessage ASI passes tmStateReference from the
Message Processing Subsystem to the Security Subsystem. Message Processing Subsystem to the Security Subsystem.
If tmStateReference is present and valid, an appropriate Security If tmStateReference is present and valid, an appropriate Security
Model might utilize the information in the cache. How or if the Model might utilize the information in the cache. How or if the
Security Subsystem utilizes the information in the cache is security- Security Subsystem utilizes the information in the cache is security-
model-specific. model-specific.
This may sound underspecified, but keep in mind that a message This may sound underspecified, but a message processing model might
processing model might have access to all the information from the have access to all the information from the cache and from the
cache and from the message, and have no need to call a Security Model message. The Message Processing Model might determine that the USM
to do any processing. The Message Processing Model might determine Security Model is specified in an SNMPv3 message header; the USM
that the USM Security Model is specified in an SNMPv3 message header; Security Model has no need of values in the tmStateReference cache to
the USM Security Model has no need of values in the tmStateReference authenticate and secure the SNMP message, but an application might
cache to authenticate and secure the SNMP message, but an application have specified to use a secure transport such as that provided by the
might have chosen to use a secure transport such as that provided by SSH Transport Model to send the message to its destination.
the SSH Transport Model to send the message to its destination.
7. Security Considerations 7. Security Considerations
This document defines an architectural approach that permits SNMP to This document defines an architectural approach that permits SNMP to
utilize transport layer security services. Each proposed Transport utilize transport layer security services. Each proposed Transport
Model should discuss the security considerations of the Transport Model should discuss the security considerations of the Transport
Model. Model.
It is considered desirable by some industry segments that SNMP It is considered desirable by some industry segments that SNMP
Transport Models should utilize transport layer security that Transport Models should utilize transport layer security that
skipping to change at page 25, line 10 skipping to change at page 26, line 9
A Security Model may have multiple sources from which to define the A Security Model may have multiple sources from which to define the
securityName and securityLevel. The use of a secure Transport Model securityName and securityLevel. The use of a secure Transport Model
does not imply that the securityName and securityLevel chosen by the does not imply that the securityName and securityLevel chosen by the
Security Model represent the transport-authenticated identity or the Security Model represent the transport-authenticated identity or the
transport-provided security services. The securityModel, transport-provided security services. The securityModel,
securityName, and securityLevel parameters are a related set, and an securityName, and securityLevel parameters are a related set, and an
administrator should understand how the specified securityModel administrator should understand how the specified securityModel
selects the corresponding securityName and securityLevel. selects the corresponding securityName and securityLevel.
7.1. Coexistence, Security Parameters, and Access Control
In the RFC3411 architecture, the Message Processing Model makes the
decision about which Security Model to use. The architectural change
described by this document does not alter that.
The architecture change described by this document does however,
allow SNMP to support two different approaches to security - message-
driven security and transport-driven security. With message-driven
security, SNMP provides its own security, and passes security
parameters within the SNMP message; with transport-driven security,
SNMP depends on an external entity to provide security during
transport by "wrapping" the SNMP message.
Security models defined before the Transport Security Model (i.e.,
SNMPv1, SNMPv2c, and USM) do not support transport-based security,
and only have access to the security parameters contained within the
SNMP message. They do not know about the security parameters
associated with a secure transport. As a result, the Access Control
Subsystem bases its decisions on the security parameters extracted
from the SNMP message, not on transport-based security parameters.
Implications of coexistence of older security models with secure
transport models are known:
o An SNMPv1 message will always be paired with an SNMPv1 Security
Model (per RFC3584), regardless of the transport mapping or
transport model used, and access controls will be based on the
community name.
o An SNMPv2c message will always be paired with an SNMPv2c Security
Model (per RFC3584), regardless of the transport mapping or
transport model used, and access controls will be based on the
community name..
o An SNMPv3 message will always be paired with the securityModel
specified in the msgSecurityParameters field of the message (per
RFC3412), regardless of the transport mappng or transport model
used. If the SNMPv3 message specifies the User-based Security
Model (USM), access controls will be based on the USM user.If the
SNMPv3 message specifies the Transport Security Model (TSM),
access controls will be based on the principal authenticated by
the transport.
8. IANA Considerations 8. IANA Considerations
This document requires no action by IANA. This document requires no action by IANA.
9. Acknowledgments 9. Acknowledgments
The Integrated Security for SNMP WG would like to thank the following The Integrated Security for SNMP WG would like to thank the following
people for their contributions to the process: people for their contributions to the process:
The authors of submitted Security Model proposals: Chris Elliot, Wes The authors of submitted Security Model proposals: Chris Elliot, Wes
skipping to change at page 26, line 23 skipping to change at page 28, line 17
RFC 3414, December 2002. RFC 3414, December 2002.
[RFC3417] Presuhn, R., "Transport [RFC3417] Presuhn, R., "Transport
Mappings for the Simple Mappings for the Simple
Network Management Protocol Network Management Protocol
(SNMP)", STD 62, RFC 3417, (SNMP)", STD 62, RFC 3417,
December 2002. December 2002.
10.2. Informative References 10.2. Informative References
[RFC2828] Shirey, R., "Internet
Security Glossary",
RFC 2828, May 2000.
[RFC2865] Rigney, C., Willens, S., [RFC2865] Rigney, C., Willens, S.,
Rubens, A., and W. Simpson, Rubens, A., and W. Simpson,
"Remote Authentication Dial "Remote Authentication Dial
In User Service (RADIUS)", In User Service (RADIUS)",
RFC 2865, June 2000. RFC 2865, June 2000.
[RFC3410] Case, J., Mundy, R., [RFC3410] Case, J., Mundy, R.,
Partain, D., and B. Partain, D., and B.
Stewart, "Introduction and Stewart, "Introduction and
Applicability Statements Applicability Statements
skipping to change at page 27, line 17 skipping to change at page 29, line 8
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-04 (work in security-model-05 (work in
progress), May 2007. progress), July 2007.
[I-D.ietf-isms-secshell] Salowey, J. and D.
Harrington, "Secure Shell
Transport Model for SNMP",
draft-ietf-isms-secshell-08
(work in progress),
July 2007.
Appendix A. Why tmStateReference? Appendix A. Why tmStateReference?
This appendix considers why a cache-based approach was selected for This appendix considers why a cache-based approach was selected for
passing parameters. passing parameters.
There are four approaches that could be used for passing information There are four approaches that could be used for passing information
between the Transport Model and a Security Model. between the Transport Model and a Security Model.
1. one could define an ASI to supplement the existing ASIs, or 1. one could define an ASI to supplement the existing ASIs, or
skipping to change at page 29, line 4 skipping to change at page 30, line 48
Model and a corresponding specific Security Model. However, the Model and a corresponding specific Security Model. However, the
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 B. Open Issues Appendix B. 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 o
Appendix C. Change Log Appendix C. 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 -09- to -10-
o Pointed to companion documents
o Wordsmithed extensively
o Modified the note about SNMPv3-consistent terminology
o Modified the note about RFC2119 terminology.
o Modified discussion of cryptographic key generation.
o Added security considerations about coexistence with older
security models
o Expanded discussion of same session functionality
o Described how sendMessage and receiveMessage fit into RFC3411
diagrams
o Modified prepareResponseMessage ASI
o
Changes from -08- to -09- Changes from -08- to -09-
o A question was raised that notifications would not work properly, o A question was raised that notifications would not work properly,
but we could never find the circumstances where this was true. but we could never find the circumstances where this was true.
o removed appendix with parameter matrix o removed appendix with parameter matrix
o Added a note about terminology, for consistency with SNMPv2 rather o Added a note about terminology, for consistency with SNMPv3 rather
than with RFC2828. than with RFC2828.
Changes from -07- to -08- Changes from -07- to -08-
o Identfied new parameters in ASIs. o Identified new parameters in ASIs.
o Added discussion about well-known ports. o Added discussion about well-known ports.
Changes from -06- to -07- Changes from -06- to -07-
o Removed discussion of double authentication o Removed discussion of double authentication
o Removed all direct and indirect references to pduType by Transport o Removed all direct and indirect references to pduType by Transport
Subsystem Subsystem
o Added warning regarding keeping sensitive security informaiton o Added warning regarding keeping sensitive security information
available longer than needed. available longer than needed.
o Removed knowledge of securityStateReference from Transport o Removed knowledge of securityStateReference from Transport
Subsystem. Subsystem.
o Changed transport session identifier to not include securityModel, o Changed transport session identifier to not include securityModel,
since this is not known for incoming messages until the message since this is not known for incoming messages until the message
processing model. 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
removed gun for political correctness removed gun for political correctness
 End of changes. 35 change blocks. 
125 lines changed or deleted 236 lines changed or added

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