draft-ietf-isms-tmsm-08.txt   draft-ietf-isms-tmsm-09.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) Jacobs University Bremen
Intended status: Standards Track May 1, 2007 Intended status: Standards Track July 7, 2007
Expires: November 2, 2007 Expires: January 8, 2008
Transport Subsystem for the Simple Network Management Protocol (SNMP) Transport Subsystem for the Simple Network Management Protocol (SNMP)
draft-ietf-isms-tmsm-08 draft-ietf-isms-tmsm-09
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 November 2, 2007. This Internet-Draft will expire on January 8, 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 26 skipping to change at page 2, line 26
3.1. Message Security Requirements . . . . . . . . . . . . . . 7 3.1. Message Security Requirements . . . . . . . . . . . . . . 7
3.1.1. Security Protocol Requirements . . . . . . . . . . . . 7 3.1.1. Security Protocol Requirements . . . . . . . . . . . . 7
3.2. SNMP Requirements . . . . . . . . . . . . . . . . . . . . 8 3.2. SNMP Requirements . . . . . . . . . . . . . . . . . . . . 8
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 . . . . . . . 16 3.3.3. Message security versus session security . . . . . . . 17
4. Scenario Diagrams and the Transport Subsystem . . . . . . . . 17 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 . . . . . . . . . . . . . . . . . . 18
5.2. tmStateReference . . . . . . . . . . . . . . . . . . . . . 18 5.2. tmStateReference . . . . . . . . . . . . . . . . . . . . . 19
6. Abstract Service Interfaces . . . . . . . . . . . . . . . . . 19 6. Abstract Service Interfaces . . . . . . . . . . . . . . . . . 19
6.1. sendMessage ASI . . . . . . . . . . . . . . . . . . . . . 19 6.1. sendMessage ASI . . . . . . . . . . . . . . . . . . . . . 20
6.2. Other Outgoing ASIs . . . . . . . . . . . . . . . . . . . 20 6.2. Other Outgoing ASIs . . . . . . . . . . . . . . . . . . . 20
6.3. The receiveMessage ASI . . . . . . . . . . . . . . . . . . 21 6.3. The receiveMessage ASI . . . . . . . . . . . . . . . . . . 22
6.4. Other Incoming ASIs . . . . . . . . . . . . . . . . . . . 22 6.4. Other Incoming ASIs . . . . . . . . . . . . . . . . . . . 22
7. Security Considerations . . . . . . . . . . . . . . . . . . . 23 7. Security Considerations . . . . . . . . . . . . . . . . . . . 24
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
10.1. Normative References . . . . . . . . . . . . . . . . . . . 24 10.1. Normative References . . . . . . . . . . . . . . . . . . . 25
10.2. Informative References . . . . . . . . . . . . . . . . . . 25 10.2. Informative References . . . . . . . . . . . . . . . . . . 26
Appendix A. Parameter Table . . . . . . . . . . . . . . . . . . . 26 Appendix A. Why tmStateReference? . . . . . . . . . . . . . . . . 27
A.1. ParameterList.csv . . . . . . . . . . . . . . . . . . . . 26 A.1. Define an Abstract Service Interface . . . . . . . . . . . 27
Appendix B. Why tmStateReference? . . . . . . . . . . . . . . . . 28 A.2. Using an Encapsulating Header . . . . . . . . . . . . . . 27
B.1. Define an Abstract Service Interface . . . . . . . . . . . 28 A.3. Modifying Existing Fields in an SNMP Message . . . . . . . 28
B.2. Using an Encapsulating Header . . . . . . . . . . . . . . 28 A.4. Using a Cache . . . . . . . . . . . . . . . . . . . . . . 28
B.3. Modifying Existing Fields in an SNMP Message . . . . . . . 29 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . . 28
B.4. Using a Cache . . . . . . . . . . . . . . . . . . . . . . 29 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 29
Appendix C. Open Issues . . . . . . . . . . . . . . . . . . . . . 29
Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 30
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 5, line 23 skipping to change at page 5, line 23
document are not to be interpreted as described in RFC2119. They document are not to be interpreted as described in RFC2119. They
will usually, but not always, be used in a context relating to will usually, but not always, be used in a context relating to
compatibility with the RFC3411 architecture or the subsystem defined compatibility with the RFC3411 architecture or the subsystem defined
here, but which might have no impact on on-the-wire compatibility. here, but which might have no impact on on-the-wire compatibility.
These terms are used as guidance for designers of proposed IETF These terms are used as guidance for designers of proposed IETF
models to make the designs compatible with RFC3411 subsystems and models to make the designs compatible with RFC3411 subsystems and
Abstract Service Interfaces (see section 3.2). Implementers are free Abstract Service Interfaces (see section 3.2). Implementers are free
to implement differently. Some usages of these lowercase terms are to implement differently. Some usages of these lowercase terms are
simply normal English usage. simply normal English usage.
Some terminology used in this document was defined as part of the
IETF SNMPv3 Standard (STD62) or existed in normal English before the
informational 'Internet Security Glossary' [RFC2828] was published.
For consistency with related specifications, where necessary, this
document favors terminology consistent with STD62 rather than with
the Internet Security Glossary. This is consistent with the IESG
decision to not require the SNMPv3 terminology be modified to match
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
employee , schedule the employee, position the employee to guard what employee , schedule the employee, position the employee to guard what
skipping to change at page 11, line 32 skipping to change at page 11, line 32
checking, and translation of parameters to model-independent checking, and translation of parameters to model-independent
parameters. A secure transport performs those security functions on parameters. A secure transport performs those security functions on
the message, before the ASN.1 is decoded. the message, before the ASN.1 is decoded.
Step 6 cannot occur until after decryption occurs. Step 6 and beyond Step 6 cannot occur until after decryption occurs. Step 6 and beyond
are the same for USM and a secure transport. are the same for USM and a secure transport.
3.2.1.1.1. USM and the RFC3411 Architecture 3.2.1.1.1. USM and the RFC3411 Architecture
1) decode the ASN.1 header (Message Processing Model) 1) decode the ASN.1 header (Message Processing Model)
2) determine the SNMP Security Model and parameters (Message 2) determine the SNMP Security Model and parameters (Message
Processing Model) Processing Model)
3) verify securityLevel. [Security Model] 3) verify securityLevel. [Security Model]
4) translate parameters to model-independent parameters (Security 4) translate parameters to model-independent parameters (Security
Model) Model)
5) authenticate the principal, check message integrity and
5) authenticate and decrypt message. [Security Model] timeliness, and decrypt the message. [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 parameters. 7) pass on the decrypted portions with model-independent parameters.
3.2.1.2. Transport Subsystem and the RFC3411 Architecture 3.2.1.2. Transport Subsystem and the RFC3411 Architecture
1) authenticate and decrypt message. [Transport Model]
1) authenticate the principal, check integrity and timeliness of the
message, and decrypt the message. [Transport Model]
2) translate parameters to model-independent parameters (Transport 2) translate parameters to model-independent parameters (Transport
Model) Model)
3) decode the ASN.1 header (Message Processing Model) 3) decode the ASN.1 header (Message Processing Model)
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 the securityName in step 3.
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
skipping to change at page 12, line 38 skipping to change at page 12, line 29
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.
3.2.2. Access Control Requirements 3.2.2. Access Control Requirements
RFC3411 made some design decisions related to the support of an RFC3411 made some design decisions related to the support of an
Access Control Subsystem. These include a securityName and Access Control Subsystem. These include establishing and passing in
securityLevel mapping, the separation of Authentication and a model-independent manner the securityModel, securityName and
Authorization, and the passing of model-independent security securityLevel parameters, and separating message authentication from
parameters. data access authorization.
3.2.2.1. securityName and securityLevel Mapping 3.2.2.1. securityName and securityLevel Mapping
For SNMP access control to function properly, Security Models MUST SNMP data access controls are expected to work on the basis of who
establish a securityLevel and a securityName, which is the security- can perform what operations on which subsets of data, and based on
model-independent identifier for a principal. The Message Processing the security services that will be provided to secure the data in
Subsystem relies on a Security Model, such as USM, to play a role in transit. The securityModel and securityLevel parameters establish
security that goes beyond protecting the message - it provides a the protections for transit - whether authentication and privacy
mapping between the security-model-specific principal to a security- services will be or have been applied to the message. The
model independent securityName which can be used for subsequent securityName is a model-independent identifier of the security
processing, such as for access control. "principal",
The securityName MUST be mapped from the mechanism-specific The Message Processing Subsystem relies on a Security Model, such as
authenticated identity, and this mapping must be done for incoming USM, to play a role in security that goes beyond protecting the
messages before the Security Model passes securityName to the Message message - it provides a mapping between the security-model-specific
Processing Model via the processIncoming ASI. This translation from principal for an incoming message to a security-model independent
a mechanism-specific authenticated identity to a securityName might securityName which can be used for subsequent processing, such as for
be done by the Transport Model, and the securityName is then provided access control. The securityName is mapped from a mechanism-specific
to the Security Model via the tmStateReference to be passed to the identity, and this mapping must be done for incoming messages by the
Message Processing Model. Security Model before it passes securityName to the Message
Processing Model via the processIncoming ASI.
A Security Model is also responsible to specify, via the
securityLevel parameter, whether incoming messages have been
authenticated and/or encrypted, and to ensure that outgoing messages
are authenticated and/or encrypted based on the value of
securityLevel.
A translation from a mechanism-specific identity to a securityName
might be done by a Transport Model, and the proposed securityName and
a proposed securityLevel might then be made available to a Security
Model via the tmStateReference. A Security Model may have multiple
sources for determining the principal and desired security services,
and a particular Security Model may or may not utilize the
securityName mapping and securityLevel made available by the
Transport Model when deciding the value of the securityName and
securityLevel to be passed to the Message Processing Model.
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.
The SNMP security parameters include a model-independent identifier
of the security "principal" (the securityName), the Security Model
used to perform the authentication, and which authentication and
privacy services were (should be) applied to the message
(securityLevel).
A Message Processing Model might unpack SNMP-specific security A Message Processing Model might unpack SNMP-specific security
parameters from an incoming message before calling a specific parameters from an incoming message before calling a specific
Security Model to authenticate and decrypt an incoming message, Security Model to authenticate and decrypt an incoming message,
perform integrity checking, and translate security-model-specific perform integrity checking, and translate security-model-specific
parameters into model-independent parameters. When using a secure parameters into model-independent parameters. When using a secure
Transport Model, some security parameters might be provided through Transport Model, some security parameters might be provided through
means other than carrying them in the SNMP message; some of the means other than carrying them in the SNMP message; some of the
parameters for incoming messages might be extracted from the parameters for incoming messages might be extracted from the
transport layer by the Transport Model before the message is passed transport layer by the Transport Model before the message is passed
to the Message Processing Subsystem. to the Message Processing Subsystem.
skipping to change at page 14, line 19 skipping to change at page 14, line 21
parts. Whether there are any security services provided by the parts. Whether there are any security services provided by the
Security Model for an outgoing message is security-model-dependent. Security Model for an outgoing message is security-model-dependent.
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 the authorization to access and/or modify MIB data. A set of model-
security services should take care to not violate this separation. A independent parameters (securityModel, securityName, and
Transport Model does not know which securityModel will be used for an securityLevel) are passed between the Security Subsystem, the
incoming message, so must not specify how the securityModel and applications, and the Access Control Subsystem.
securityName could be dynamically mapped to an access control
mechanism, such as a VACM-style groupName.
The RECOMMENDED approach is to pass the model-independent security This separation was a deliberate decision of the SNMPv3 WG, to allow
parameters via the isAccessAllowed ASI, and perform the mapping from support for authentication protocols which did not provide data
the model-independent security parameters to an access-control-model- access authorization capabilities, and to support data access
dependent policy within the Access Control Model. The authorization schemes, such as VACM, that do not perform their own
isAccessAllowed ASI is used for passing the securityModel, authentication. This decision also permits different types of data
securityName, and securityLevel parameters that are independent of access policies, such as one built on UNIX groups or Windows domains.
any specific security model and any specific access control model to The VACM approach is based on administrator-defined groups of users.
A Message Processing Model determines which Security Model is used,
either based on the message version, e.g., SNMPv1 and SNMPv2c, and
possibly by a value specified in the message, e.g., SNMPv3.
The Security Model makes the decision which securityName and
securityLevel values are passed as model-independent parameters to an
application, which then passes them via the isAccessAllowed ASI to
the Access Control Subsystem. the Access Control Subsystem.
The mapping of (securityModel, securityName, securityLevel) to an An Access Control Model performs the mapping from the model-
access-control-model-specific policy should be handled within a independent security parameters to a policy within the Access Control
specific access control model. This mapping should not be done in Model that is access-control-model-dependent.
the Transport or Security Subsystems, to be consistent with the
modularity of the RFC3411 architecture. This separation was a
deliberate decision of the SNMPv3 WG, to allow support for
authentication protocols which did not provide authorization (access
control) capabilities, and to support authorization schemes, such as
VACM, that do not perform their own authentication.
The View-based Access Control Model uses the securityModel and the A Transport Model does not know which securityModel will be used for
securityName as inputs to check for access rights. It determines the an incoming message, so a Transport Model cannot know how the
groupName as a function of securityModel and securityName. Providing securityName and securityLevel parameters are determined. A
a binding outside the Access Control Subsystem might create Transport Model can provide a mapping from a transport-specific
dependencies that could make it harder to develop alternate models of identity and provide candidate values for the securityName and
access control, such as one built on UNIX groups or Windows domains. securityLevel, but there is no guarantee the transport-provided
values will be used by the Security Model.
For example, the SNMPv1 Message Processing Model described in RFC3584
always selects the SNMPv1 Security Model. This is true even if the
SNMPv1 message was protected in transit using a secure Transport
Model, such as one based on SSH or TLS. The SNMPv1 Security Model
does not know the tmStateReference exists.
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,
skipping to change at page 16, line 22 skipping to change at page 16, line 32
successfully authenticate to a receiver. successfully authenticate to a receiver.
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 traffic, but configure choose to define one port for SNMP request-response traffic, but
notifications to be sent to a different port. configure notifications to be sent to a different port.
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 24, line 25 skipping to change at page 24, line 50
implementers should store this information (in memory or in implementers should store this information (in memory or in
persistent storage) in a manner to protect it from unauthorized persistent storage) in a manner to protect it from unauthorized
disclosure and/or modification. disclosure and/or modification.
Care must be taken to ensure that a SNMP engine is sending packets Care must be taken to ensure that a SNMP engine is sending packets
out over a transport using credentials that are legal for that engine out over a transport using credentials that are legal for that engine
to use on behalf of that user. Otherwise an engine that has multiple to use on behalf of that user. Otherwise an engine that has multiple
transports open might be "tricked" into sending a message through the transports open might be "tricked" into sending a message through the
wrong transport. wrong transport.
A Security Model may have multiple sources from which to define the
securityName and securityLevel. The use of a secure Transport Model
does not imply that the securityName and securityLevel chosen by the
Security Model represent the transport-authenticated identity or the
transport-provided security services. The securityModel,
securityName, and securityLevel parameters are a related set, and an
administrator should understand how the specified securityModel
selects the corresponding securityName and securityLevel.
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 25, line 37 skipping to change at page 26, line 23
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 26, line 26 skipping to change at page 27, line 17
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-03 (work in security-model-04 (work in
progress), February 2007. progress), May 2007.
Appendix A. Parameter Table
Following is a Comma-separated-values (CSV) formatted matrix useful
for tracking data flows into and out of the dispatcher, Transport,
Message Processing, and Security Subsystems. This will be of most
use to designers of models, to understand what information is
available at which points in the processing, following the RFC3411
architecture (and this subsystem). Import this into your favorite
spreadsheet or other CSV compatible application. You will need to
remove lines feeds from the second, third, and fourth lines, which
needed to be wrapped to fit into RFC line lengths.
[todo] this table needs to be updated.
A.1. ParameterList.csv
,Dispatcher,,,,Messaging,,,Security,,,Transport,
,sendPDU,returnResponse,processPDU,processResponse,
prepareOutgoingMessage,prepareResponseMessage,prepareDataElements,
generateRequest,processIncoming,generateResponse,
sendMessage,receiveMessage
transportDomain,In,,,,In,,In,,,,,In
transportAddress,In,,,,In,,In,,,,,In
destTransportDomain,,,,,Out,Out,,,,,In,
destTransportAddress,,,,,Out,Out,,,,,In,
messageProcessingModel,In,In,In,In,In,In,Out,In,In,In,,
securityModel,In,In,In,In,In,In,Out,In,In,In,,
securityName,In,In,In,In,In,In,Out,In,Out,In,,
securityLevel,In,In,In,In,In,In,Out,In,In,In,,
contextEngineID,In,In,In,In,In,In,Out,,,,,
contextName,In,In,In,In,In,In,Out,,,,,
expectResponse,In,,,,In,,,,,,,
PDU,In,In,In,In,In,In,Out,,,,,
pduVersion,In,In,In,In,In,In,Out,,,,,
statusInfo,Out,In,,In,,In,Out,Out,Out,Out,,
errorIndication,Out,Out,,,,,Out,,,,,
sendPduHandle,Out,,,In,In,,Out,,,,,
maxSizeResponsePDU,,In,In,,,In,Out,,Out,,,
stateReference,,In,In,,,In,Out,,,,,
wholeMessage,,,,,Out,Out,In,Out,In,Out,In,In
messageLength,,,,,Out,Out,In,Out,In,Out,In,In
maxMessageSize,,,,,,,,In,In,In,,
globalData,,,,,,,,In,,In,,
securityEngineID,,,,,,,,In,Out,In,,
scopedPDU,,,,,,,,In,Out,In,,
securityParameters,,,,,,,,Out,In,Out,,
securityStateReference,,,,,,,,,Out,In,,
pduType,,,,,,,Out,,,,,
tmStateReference,,,,,Out,Out,In,,In,,In,In
Appendix B. 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
2. one could add a header to encapsulate the SNMP message, 2. one could add a header to encapsulate the SNMP message,
3. one could utilize fields already defined in the existing SNMPv3 3. one could utilize fields already defined in the existing SNMPv3
message, or message, or
4. one could pass the information in an implementation-specific 4. one could pass the information in an implementation-specific
cache or via a MIB module. cache or via a MIB module.
B.1. Define an Abstract Service Interface A.1. Define an Abstract Service Interface
Abstract Service Interfaces (ASIs) are defined by a set of primitives Abstract Service Interfaces (ASIs) are defined by a set of primitives
that specify the services provided and the abstract data elements that specify the services provided and the abstract data elements
that are to be passed when the services are invoked. Defining that are to be passed when the services are invoked. Defining
additional ASIs to pass the security and transport information from additional ASIs to pass the security and transport information from
the Transport Subsystem to Security Subsystem has the advantage of the Transport Subsystem to Security Subsystem has the advantage of
being consistent with existing RFC3411/3412 practice, and helps to being consistent with existing RFC3411/3412 practice, and helps to
ensure that any Transport Model proposals pass the necessary data, ensure that any Transport Model proposals pass the necessary data,
and do not cause side effects by creating model-specific dependencies and do not cause side effects by creating model-specific dependencies
between itself and other models or other subsystems other than those between itself and other models or other subsystems other than those
that are clearly defined by an ASI. that are clearly defined by an ASI.
B.2. Using an Encapsulating Header A.2. Using an Encapsulating Header
A header could encapsulate the SNMP message to pass necessary A header could encapsulate the SNMP message to pass necessary
information from the Transport Model to the dispatcher and then to a information from the Transport Model to the dispatcher and then to a
Message Processing Model. The message header would be included in Message Processing Model. The message header would be included in
the wholeMessage ASI parameter, and would be removed by a the wholeMessage ASI parameter, and would be removed by a
corresponding Message Processing Model. This would imply the (one corresponding Message Processing Model. This would imply the (one
and only) messaging dispatcher would need to be modified to determine and only) messaging dispatcher would need to be modified to determine
which SNMP message version was involved, and a new Message Processing which SNMP message version was involved, and a new Message Processing
Model would need to be developed that knew how to extract the header Model would need to be developed that knew how to extract the header
from the message and pass it to the Security Model. from the message and pass it to the Security Model.
B.3. Modifying Existing Fields in an SNMP Message A.3. Modifying Existing Fields in an SNMP Message
[RFC3412] defines the SNMPv3 message, which contains fields to pass [RFC3412] defines the SNMPv3 message, which contains fields to pass
security related parameters. The Transport Subsystem could use these security related parameters. The Transport Subsystem could use these
fields in an SNMPv3 message, or comparable fields in other message fields in an SNMPv3 message, or comparable fields in other message
formats to pass information between Transport Models in different formats to pass information between Transport Models in different
SNMP engines, and to pass information between a Transport Model and a SNMP engines, and to pass information between a Transport Model and a
corresponding Message Processing Model. corresponding Message Processing Model.
If the fields in an incoming SNMPv3 message are changed by the If the fields in an incoming SNMPv3 message are changed by the
Transport Model before passing it to the Security Model, then the Transport Model before passing it to the Security Model, then the
Transport Model will need to decode the ASN.1 message, modify the Transport Model will need to decode the ASN.1 message, modify the
fields, and re-encode the message in ASN.1 before passing the message fields, and re-encode the message in ASN.1 before passing the message
on to the message dispatcher or to the transport layer. This would on to the message dispatcher or to the transport layer. This would
require an intimate knowledge of the message format and message require an intimate knowledge of the message format and message
versions so the Transport Model knew which fields could be modified. versions so the Transport Model knew which fields could be modified.
This would seriously violate the modularity of the architecture. This would seriously violate the modularity of the architecture.
B.4. Using a Cache A.4. Using a Cache
This document describes a cache, into which the Transport Model puts This document describes a cache, into which the Transport Model puts
information about the security applied to an incoming message, and a information about the security applied to an incoming message, and a
Security Model can extract that information from the cache. Given Security Model can extract that information from the cache. Given
that there might be multiple TM-security caches, a tmStateReference that there might be multiple TM-security caches, a tmStateReference
is passed as an extra parameter in the ASIs between the Transport is passed as an extra parameter in the ASIs between the Transport
Subsystem and the Security Subsystem, so the Security Model knows Subsystem and the Security Subsystem, so the Security Model knows
which cache of information to consult. which cache of information to consult.
This approach does create dependencies between a specific Transport This approach does create dependencies between a specific Transport
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 C. 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 MUST responses go back on the same transport session? How is this o
accomplished since the TM does not know pduType, and subsystems
with knowledge of pdutype do not known about transport sessions.
o Do Informs work correctly?
Appendix D. 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 -08- to -09-
o A question was raised that notifications would not work properly,
but we could never find the circumstances where this was true.
o removed appendix with parameter matrix
o Added a note about terminology, for consistency with SNMPv2 rather
than with RFC2828.
Changes from -07- to -08- Changes from -07- to -08-
o Identfied new parameters in ASIs. o Identfied 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 informaiton
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
Changes from revision -04- to -05- Changes from revision -04- to -05-
removed all objects from the MIB module. removed all objects from the MIB module.
changed document status to "Standard" rather than the xml2rfc changed document status to "Standard" rather than the xml2rfc
default of informational. default of informational.
changed mention of MD5 to SHA changed mention of MD5 to SHA
moved addressing style to TDomain and TAddress moved addressing style to TDomain and TAddress
modified the diagrams as requested modified the diagrams as requested
removed the "layered stack" diagrams that compared USM and a removed the "layered stack" diagrams that compared USM and a
Transport Model processing Transport Model processing
removed discussion of speculative features that might exist in removed discussion of speculative features that might exist in
future Transport Models future Transport Models
removed openSession and closeSession ASIs, since those are model- removed openSession and closeSession ASIs, since those are model-
dependent dependent
removed the MIB module removed the MIB module
removed the MIB boilerplate intro (this memo defines a SMIv2 MIB removed the MIB boilerplate intro (this memo defines a SMIv2 MIB
...) ...)
removed IANA considerations related to the now-gone MIB module removed IANA considerations related to the now-gone MIB module
removed security considerations related to the MIB module removed security considerations related to the MIB module
removed references needed for the MIB module removed references needed for the MIB module
changed receiveMessage ASI to use origin transport domain/address changed receiveMessage ASI to use origin transport domain/address
updated Parameter CSV appendix updated Parameter CSV appendix
Changes from revision -03- to -04- Changes from revision -03- to -04-
changed title from Transport Mapping Security Model Architectural changed title from Transport Mapping Security Model Architectural
Extension to Transport Subsystem Extension to Transport Subsystem
modified the abstract and introduction modified the abstract and introduction
changed TMSM to TMS changed TMSM to TMS
changed MPSP to simply Security Model changed MPSP to simply Security Model
changed SMSP to simply Security Model changed SMSP to simply Security Model
changed TMSP to Transport Model changed TMSP to Transport Model
removed MPSP and TMSP and SMSP from Acronyms section removed MPSP and TMSP and SMSP from Acronyms section
modified diagrams modified diagrams
removed most references to dispatcher functionality removed most references to dispatcher functionality
worked to remove dependencies between transport and security worked to remove dependencies between transport and security
models. models.
defined snmpTransportModel enumeration similar to defined snmpTransportModel enumeration similar to
snmpSecurityModel, etc. snmpSecurityModel, etc.
eliminated all reference to SNMPv3 msgXXXX fields eliminated all reference to SNMPv3 msgXXXX fields
changed tmSessionReference back to tmStateReference changed tmSessionReference back to tmStateReference
Changes from revision -02- to -03- Changes from revision -02- to -03-
o removed session table from MIB module o removed session table from MIB module
o removed sessionID from ASIs o removed sessionID from ASIs
o reorganized to put ASI discussions in EOP section, as was done in o reorganized to put ASI discussions in EOP section, as was done in
SSHSM SSHSM
o changed user auth to client auth o changed user auth to client auth
o changed tmStateReference to tmSessionReference o changed tmStateReference to tmSessionReference
o modified document to meet consensus positions published by JS o modified document to meet consensus positions published by JS
* authoritative is model-specific * authoritative is model-specific
* msgSecurityParameters usage is model-specific * msgSecurityParameters usage is model-specific
* msgFlags vs. securityLevel is model/implementation-specific * msgFlags vs. securityLevel is model/implementation-specific
* notifications must be able to cause creation of a session * notifications must be able to cause creation of a session
* security considerations must be model-specific * security considerations must be model-specific
* TDomain and TAddress are model-specific * TDomain and TAddress are model-specific
* MPSP changed to SMSP (Security Model security processing) * MPSP changed to SMSP (Security Model security processing)
Changes from revision -01- to -02- Changes from revision -01- to -02-
o wrote text for session establishment requirements section. o wrote text for session establishment requirements section.
o wrote text for session maintenance requirements section. o wrote text for session maintenance requirements section.
o removed section on relation to SNMPv2-MIB o removed section on relation to SNMPv2-MIB
o updated MIB module to pass smilint o updated MIB module to pass smilint
o Added Structure of the MIB module, and other expected MIB-related o Added Structure of the MIB module, and other expected MIB-related
sections. sections.
o updated author address o updated author address
o corrected spelling o corrected spelling
o removed msgFlags appendix o removed msgFlags appendix
o Removed section on implementation considerations. o Removed section on implementation considerations.
o started modifying the security boilerplate to address TMS and MIB o started modifying the security boilerplate to address TMS and MIB
security issues security issues
o reorganized slightly to better separate requirements from proposed o reorganized slightly to better separate requirements from proposed
solution. This probably needs additional work. solution. This probably needs additional work.
o removed section with sample protocols and sample o removed section with sample protocols and sample
tmSessionReference. tmSessionReference.
o Added section for acronyms o Added section for acronyms
o moved section comparing parameter passing techniques to appendix. o moved section comparing parameter passing techniques to appendix.
o Removed section on notification requirements. o Removed section on notification requirements.
Changes from revision -00- Changes from revision -00-
o changed SSH references from I-Ds to RFCs o changed SSH references from I-Ds to RFCs
o removed parameters from tmSessionReference for DTLS that revealed o removed parameters from tmSessionReference for DTLS that revealed
lower layer info. lower layer info.
o Added TMS-MIB module o Added TMS-MIB module
o Added Internet-Standard Management Framework boilerplate o Added Internet-Standard Management Framework boilerplate
o Added Structure of the MIB Module o Added Structure of the MIB Module
o Added MIB security considerations boilerplate (to be completed) o Added MIB security considerations boilerplate (to be completed)
o Added IANA Considerations o Added IANA Considerations
o Added ASI Parameter table o Added ASI Parameter table
o Added discussion of Sessions o Added discussion of Sessions
o Added Open issues and Change Log o Added Open issues and Change Log
o Rearranged sections o Rearranged sections
Authors' Addresses Authors' Addresses
David Harrington David Harrington
Huawei Technologies (USA) Huawei Technologies (USA)
1700 Alma Dr. Suite 100 1700 Alma Dr. Suite 100
Plano, TX 75075 Plano, TX 75075
USA USA
skipping to change at page 34, line 35 skipping to change at page 32, line 17
David Harrington David Harrington
Huawei Technologies (USA) Huawei Technologies (USA)
1700 Alma Dr. Suite 100 1700 Alma Dr. Suite 100
Plano, TX 75075 Plano, TX 75075
USA USA
Phone: +1 603 436 8634 Phone: +1 603 436 8634
EMail: dharrington@huawei.com EMail: dharrington@huawei.com
Juergen Schoenwaelder Juergen Schoenwaelder
International University Bremen Jacobs University Bremen
Campus Ring 1 Campus Ring 1
28725 Bremen 28725 Bremen
Germany Germany
Phone: +49 421 200-3587 Phone: +49 421 200-3587
EMail: j.schoenwaelder@iu-bremen.de EMail: j.schoenwaelder@iu-bremen.de
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
 End of changes. 120 change blocks. 
266 lines changed or deleted 142 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/