draft-ietf-isms-tmsm-07.txt   draft-ietf-isms-tmsm-08.txt 
Network Working Group D. Harrington Network Working Group D. Harrington
Internet-Draft Huawei Technologies (USA) Internet-Draft Huawei Technologies (USA)
Updates: 3411,3412,3414,3417 J. Schoenwaelder Updates: 3411,3412,3414,3417 J. Schoenwaelder
(if approved) International University Bremen (if approved) International University Bremen
Intended status: Standards Track March 4, 2007 Intended status: Standards Track May 1, 2007
Expires: September 5, 2007 Expires: November 2, 2007
Transport Subsystem for the Simple Network Management Protocol (SNMP) Transport Subsystem for the Simple Network Management Protocol (SNMP)
draft-ietf-isms-tmsm-07 draft-ietf-isms-tmsm-08
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 September 5, 2007. This Internet-Draft will expire on November 2, 2007.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document defines a Transport Subsystem, extending the Simple This document defines a Transport Subsystem, extending the Simple
Network Management Protocol (SNMP) architecture defined in RFC 3411. Network Management Protocol (SNMP) architecture defined in RFC 3411.
This document defines a subsystem to contain Transport Models, This document defines a subsystem to contain Transport Models,
skipping to change at page 2, line 23 skipping to change at page 2, line 23
1.3. Conventions . . . . . . . . . . . . . . . . . . . . . . . 5 1.3. Conventions . . . . . . . . . . . . . . . . . . . . . . . 5
2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Requirements of a Transport Model . . . . . . . . . . . . . . 7 3. Requirements of a Transport Model . . . . . . . . . . . . . . 7
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 . . . . . . . . . . . . . . . . . . . 14 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 . . . . . . . 16
4. Scenario Diagrams and the Transport Subsystem . . . . . . . . 17 4. Scenario Diagrams and the Transport Subsystem . . . . . . . . 17
5. Cached Information and References . . . . . . . . . . . . . . 17 5. Cached Information and References . . . . . . . . . . . . . . 18
5.1. securityStateReference . . . . . . . . . . . . . . . . . . 18 5.1. securityStateReference . . . . . . . . . . . . . . . . . . 18
5.2. tmStateReference . . . . . . . . . . . . . . . . . . . . . 18 5.2. tmStateReference . . . . . . . . . . . . . . . . . . . . . 18
6. Abstract Service Interfaces . . . . . . . . . . . . . . . . . 19 6. Abstract Service Interfaces . . . . . . . . . . . . . . . . . 19
6.1. sendMessage ASI . . . . . . . . . . . . . . . . . . . . . 19 6.1. sendMessage ASI . . . . . . . . . . . . . . . . . . . . . 19
6.2. Other Outgoing ASIs . . . . . . . . . . . . . . . . . . . 20 6.2. Other Outgoing ASIs . . . . . . . . . . . . . . . . . . . 20
6.3. The receiveMessage ASI . . . . . . . . . . . . . . . . . . 21 6.3. The receiveMessage ASI . . . . . . . . . . . . . . . . . . 21
6.4. Other Incoming ASIs . . . . . . . . . . . . . . . . . . . 22 6.4. Other Incoming ASIs . . . . . . . . . . . . . . . . . . . 22
7. Security Considerations . . . . . . . . . . . . . . . . . . . 23 7. Security Considerations . . . . . . . . . . . . . . . . . . . 23
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24
skipping to change at page 6, line 24 skipping to change at page 6, line 24
subcontracted services and coordinate them however, because it is subcontracted services and coordinate them however, because it is
difficult to build solid security bindings between the various difficult to build solid security bindings between the various
services, and potential for gaps in the security is significant. services, and potential for gaps in the security is significant.
A solution based on the third approach might utilize one or more A solution based on the third approach might utilize one or more
lower-layer security mechanisms to provide the message-oriented lower-layer security mechanisms to provide the message-oriented
security services required. These would include authentication of security services required. These would include authentication of
the sender, encryption, timeliness checking, and data integrity the sender, encryption, timeliness checking, and data integrity
checking. There are a number of IETF standards available or in checking. There are a number of IETF standards available or in
development to address these problems through security layers at the development to address these problems through security layers at the
transport layer or application layer, among them TLS [RFC4366], SASL transport layer or application layer, among them TLS [RFC4346], SASL
[RFC4422], and SSH [RFC4251]. [RFC4422], and SSH [RFC4251].
From an operational perspective, it is highly desirable to use From an operational perspective, it is highly desirable to use
security mechanisms that can unify the administrative security security mechanisms that can unify the administrative security
management for SNMPv3, command line interfaces (CLIs) and other management for SNMPv3, command line interfaces (CLIs) and other
management interfaces. The use of security services provided by management interfaces. The use of security services provided by
lower layers is the approach commonly used for the CLI, and is also lower layers is the approach commonly used for the CLI, and is also
the approach being proposed for NETCONF [RFC4741]. the approach being proposed for NETCONF [RFC4741].
This document defines a Transport Subsystem extension to the RFC3411 This document defines a Transport Subsystem extension to the RFC3411
architecture based on the third approach. This extension specifies architecture based on the third approach. This extension specifies
how other lower layer protocols with common security infrastructures how other lower layer protocols with common security infrastructures
can be used underneath the SNMP protocol and the desired goal of can be used underneath the SNMP protocol and the desired goal of
unified administrative security can be met. unified administrative security can be met.
This extension allows security to be provided by an external protocol This extension allows security to be provided by an external protocol
connected to the SNMP engine through an SNMP Transport Model connected to the SNMP engine through an SNMP Transport Model
[RFC3417]. Such a Transport Model would then enable the use of [RFC3417]. Such a Transport Model would then enable the use of
existing security mechanisms such as (TLS) [RFC4366] or SSH [RFC4251] existing security mechanisms such as (TLS) [RFC4346] or SSH [RFC4251]
within the RFC3411 architecture. within the RFC3411 architecture.
There are a number of Internet security protocols and mechanisms that There are a number of Internet security protocols and mechanisms that
are in wide spread use. Many of them try to provide a generic are in wide spread use. Many of them try to provide a generic
infrastructure to be used by many different application layer infrastructure to be used by many different application layer
protocols. The motivation behind the Transport Subsystem is to protocols. The motivation behind the Transport Subsystem is to
leverage these protocols where it seems useful. leverage these protocols where it seems useful.
There are a number of challenges to be addressed to map the security There are a number of challenges to be addressed to map the security
provided by a secure transport into the SNMP architecture so that provided by a secure transport into the SNMP architecture so that
skipping to change at page 13, line 16 skipping to change at page 13, line 26
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 security parameters include a model-independent identifier of the The SNMP security parameters include a model-independent identifier
security "principal" (the securityName), the Security Model used to of the security "principal" (the securityName), the Security Model
perform the authentication, and which authentication and privacy used to perform the authentication, and which authentication and
services were (should be) applied to the message (securityLevel). 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, security parameters might be provided through means Transport Model, some security parameters might be provided through
other than carrying them in the SNMP message; the parameters for means other than carrying them in the SNMP message; some of the
incoming messages might be extracted from the transport layer by the parameters for incoming messages might be extracted from the
Transport Model before the message is passed to the Message transport layer by the Transport Model before the message is passed
Processing Subsystem. to the Message Processing Subsystem.
This document describes a cache mechanism (see Section 5), into which This document describes a cache mechanism (see Section 5), into which
the Transport Model puts information about the transport and security the Transport Model puts information about the transport and security
parameters applied to a transport connection or an incoming message, parameters applied to a transport connection or an incoming message,
and a Security Model may extract that information from the cache. A and a Security Model may extract that information from the cache. A
tmStateReference is passed as an extra parameter in the ASIs of the tmStateReference is passed as an extra parameter in the ASIs of the
Transport Subsystem and the Message Processing and Security Transport Subsystem and the Message Processing and Security
Subsystems, to identify the relevant cache. This approach of passing Subsystems, to identify the relevant cache. This approach of passing
a model-independent reference is consistent with the a model-independent reference is consistent with the
securityStateReference cache already being passed around in the securityStateReference cache already being passed around in the
skipping to change at page 15, line 38 skipping to change at page 15, line 50
SNMP applications provide the transportDomain, transportAddress, SNMP applications provide the transportDomain, transportAddress,
securityName, and securityLevel to be used to identify a session in a securityName, and securityLevel to be used to identify a session in a
transport-independent manner. transport-independent manner.
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 sending the
message failed. message failed.
A Transport Model determines whether an approrpiate 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 Depending on the secure transport protocol, session establishment
might require provisioning authentication credentials on the agent, might require provisioning authentication credentials on the agent,
either statically or dynamically, so the client/agent can either statically or dynamically, so the client/agent can
skipping to change at page 16, line 4 skipping to change at page 16, line 16
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 Depending on the secure transport protocol, session establishment
might require provisioning authentication credentials on the agent, might require provisioning authentication credentials on the agent,
either statically or dynamically, so the client/agent can either statically or dynamically, so the client/agent can
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.
(e.g., port 161 vs. port 162). For example, in SNMPv1, UDP ports 161 and 162 were used to
differentiate types of traffic. New transport models may define a
single well-known port for all traffic types. Administrators might
choose to define one port for SNMP traffic, but 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 20, line 18 skipping to change at page 20, line 28
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, generateRequestMsg, and generateResponseMsg
ASIs as an OUT parameter. ASIs as an OUT parameter. The transportDomain and transportAddress
parameters have been added to 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 24, line 41 skipping to change at page 24, line 41
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
Hardaker, David Harrington, Keith McCloghrie, Kaushik Narayan, David Hardaker, David Harrington, Keith McCloghrie, Kaushik Narayan, David
Perkins, Joseph Salowey, and Juergen Schoenwaelder. Perkins, Joseph Salowey, and Juergen Schoenwaelder.
The members of the Protocol Evaluation Team: Uri Blumenthal, The members of the Protocol Evaluation Team: Uri Blumenthal,
Lakshminath Dondeti, Randy Presuhn, and Eric Rescorla. Lakshminath Dondeti, Randy Presuhn, and Eric Rescorla.
WG members who committed to and performed detailed reviews: Jeffrey WG members who performed detailed reviews: Jeffrey Hutzelman, Bert
Hutzelman Wijnen, Tom Petch.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for [RFC2119] Bradner, S., "Key words for
use in RFCs to Indicate use in RFCs to Indicate
Requirement Levels", Requirement Levels",
BCP 14, RFC 2119, BCP 14, RFC 2119,
March 1997. March 1997.
skipping to change at page 25, line 51 skipping to change at page 25, line 51
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
for Internet-Standard for Internet-Standard
Management Framework", Management Framework",
RFC 3410, December 2002. RFC 3410, December 2002.
[RFC3413] Levi, D., Meyer, P., and B. [RFC4346] Dierks, T. and E. Rescorla,
Stewart, "Simple Network "The Transport Layer
Management Protocol (SNMP) Security (TLS) Protocol
Applications", STD 62, Version 1.1", RFC 4346,
RFC 3413, December 2002. April 2006.
[RFC4366] Blake-Wilson, S., Nystrom,
M., Hopwood, D., Mikkelsen,
J., and T. Wright,
"Transport Layer Security
(TLS) Extensions",
RFC 4366, April 2006.
[RFC4422] Melnikov, A. and K. [RFC4422] Melnikov, A. and K.
Zeilenga, "Simple Zeilenga, "Simple
Authentication and Security Authentication and Security
Layer (SASL)", RFC 4422, Layer (SASL)", RFC 4422,
June 2006. June 2006.
[RFC4251] Ylonen, T. and C. Lonvick, [RFC4251] Ylonen, T. and C. Lonvick,
"The Secure Shell (SSH) "The Secure Shell (SSH)
Protocol Architecture", Protocol Architecture",
skipping to change at page 26, line 48 skipping to change at page 26, line 41
Following is a Comma-separated-values (CSV) formatted matrix useful Following is a Comma-separated-values (CSV) formatted matrix useful
for tracking data flows into and out of the dispatcher, Transport, for tracking data flows into and out of the dispatcher, Transport,
Message Processing, and Security Subsystems. This will be of most Message Processing, and Security Subsystems. This will be of most
use to designers of models, to understand what information is use to designers of models, to understand what information is
available at which points in the processing, following the RFC3411 available at which points in the processing, following the RFC3411
architecture (and this subsystem). Import this into your favorite architecture (and this subsystem). Import this into your favorite
spreadsheet or other CSV compatible application. You will need to spreadsheet or other CSV compatible application. You will need to
remove lines feeds from the second, third, and fourth lines, which remove lines feeds from the second, third, and fourth lines, which
needed to be wrapped to fit into RFC line lengths. needed to be wrapped to fit into RFC line lengths.
[todo] this table needs to be updated.
A.1. ParameterList.csv A.1. ParameterList.csv
,Dispatcher,,,,Messaging,,,Security,,,Transport, ,Dispatcher,,,,Messaging,,,Security,,,Transport,
,sendPDU,returnResponse,processPDU,processResponse, ,sendPDU,returnResponse,processPDU,processResponse,
prepareOutgoingMessage,prepareResponseMessage,prepareDataElements, prepareOutgoingMessage,prepareResponseMessage,prepareDataElements,
generateRequest,processIncoming,generateResponse, generateRequest,processIncoming,generateResponse,
sendMessage,receiveMessage sendMessage,receiveMessage
transportDomain,In,,,,In,,In,,,,,In transportDomain,In,,,,In,,In,,,,,In
transportAddress,In,,,,In,,In,,,,,In transportAddress,In,,,,In,,In,,,,,In
destTransportDomain,,,,,Out,Out,,,,,In, destTransportDomain,,,,,Out,Out,,,,,In,
destTransportAddress,,,,,Out,Out,,,,,In, destTransportAddress,,,,,Out,Out,,,,,In,
skipping to change at page 30, line 8 skipping to change at page 30, line 4
Appendix C. Open Issues Appendix C. Open Issues
NOTE to RFC editor: If this section is empty, then please remove this NOTE to RFC editor: If this section is empty, then please remove this
open issues section before publishing this document as an RFC. (If open issues section before publishing this document as an RFC. (If
it is not empty, please send it back to the editor to resolve. it is not empty, please send it back to the editor to resolve.
o MUST responses go back on the same transport session? How is this o MUST responses go back on the same transport session? How is this
accomplished since the TM does not know pduType, and subsystems accomplished since the TM does not know pduType, and subsystems
with knowledge of pdutype do not known about transport sessions. with knowledge of pdutype do not known about transport sessions.
o Do Informs work correctly? o Do Informs work correctly?
Appendix D. Change Log Appendix D. Change Log
NOTE to RFC editor: Please remove this change log before publishing NOTE to RFC editor: Please remove this change log before publishing
this document as an RFC. this document as an RFC.
Changes from -07- to -08-
o Identfied new parameters in ASIs.
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
o
* 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
 End of changes. 92 change blocks. 
38 lines changed or deleted 117 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/