draft-ietf-isms-tmsm-10.txt   draft-ietf-isms-tmsm-11.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 September 15, 2007 Intended status: Standards Track November 18, 2007
Expires: March 18, 2008 Expires: May 21, 2008
Transport Subsystem for the Simple Network Management Protocol (SNMP) Transport Subsystem for the Simple Network Management Protocol (SNMP)
draft-ietf-isms-tmsm-10 draft-ietf-isms-tmsm-11
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 March 18, 2008. This Internet-Draft will expire on May 21, 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 20 skipping to change at page 2, line 20
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. The Internet-Standard Management Framework . . . . . . . . 3 1.1. The Internet-Standard Management Framework . . . . . . . . 3
1.2. Where this Extension Fits . . . . . . . . . . . . . . . . 3 1.2. Where this Extension Fits . . . . . . . . . . . . . . . . 3
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 . . . . . . . . . . . . . 11
3.2.3. Security Parameter Passing Requirements . . . . . . . 13 3.2.3. Security Parameter Passing Requirements . . . . . . . 12
3.2.4. Separation of Authentication and Authorization . . . . 14 3.2.4. Separation of Authentication and Authorization . . . . 13
3.3. Session Requirements . . . . . . . . . . . . . . . . . . . 15 3.3. Session Requirements . . . . . . . . . . . . . . . . . . . 14
3.3.1. Session Establishment Requirements . . . . . . . . . . 15 3.3.1. Session Establishment Requirements . . . . . . . . . . 14
3.3.2. Session Maintenance Requirements . . . . . . . . . . . 16 3.3.2. Session Maintenance Requirements . . . . . . . . . . . 15
3.3.3. Message security versus session security . . . . . . . 17 3.3.3. Message security versus session security . . . . . . . 16
4. Scenario Diagrams and the Transport Subsystem . . . . . . . . 18 4. Scenario Diagrams and the Transport Subsystem . . . . . . . . 17
5. Cached Information and References . . . . . . . . . . . . . . 18 5. Cached Information and References . . . . . . . . . . . . . . 17
5.1. securityStateReference . . . . . . . . . . . . . . . . . . 19 5.1. securityStateReference . . . . . . . . . . . . . . . . . . 18
5.2. tmStateReference . . . . . . . . . . . . . . . . . . . . . 19 5.2. tmStateReference . . . . . . . . . . . . . . . . . . . . . 18
6. Abstract Service Interfaces . . . . . . . . . . . . . . . . . 20 6. Abstract Service Interfaces . . . . . . . . . . . . . . . . . 19
6.1. sendMessage ASI . . . . . . . . . . . . . . . . . . . . . 20 6.1. sendMessage ASI . . . . . . . . . . . . . . . . . . . . . 19
6.2. Other Outgoing ASIs . . . . . . . . . . . . . . . . . . . 21 6.2. Other Outgoing ASIs . . . . . . . . . . . . . . . . . . . 20
6.3. The receiveMessage ASI . . . . . . . . . . . . . . . . . . 23 6.3. The receiveMessage ASI . . . . . . . . . . . . . . . . . . 22
6.4. Other Incoming ASIs . . . . . . . . . . . . . . . . . . . 23 6.4. Other Incoming ASIs . . . . . . . . . . . . . . . . . . . 22
7. Security Considerations . . . . . . . . . . . . . . . . . . . 25 7. Security Considerations . . . . . . . . . . . . . . . . . . . 24
7.1. Coexistence, Security Parameters, and Access Control . . . 26 7.1. Coexistence, Security Parameters, and Access Control . . . 25
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
10.1. Normative References . . . . . . . . . . . . . . . . . . . 27 10.1. Normative References . . . . . . . . . . . . . . . . . . . 26
10.2. Informative References . . . . . . . . . . . . . . . . . . 28 10.2. Informative References . . . . . . . . . . . . . . . . . . 27
Appendix A. Why tmStateReference? . . . . . . . . . . . . . . . . 29 Appendix A. Why tmStateReference? . . . . . . . . . . . . . . . . 28
A.1. Define an Abstract Service Interface . . . . . . . . . . . 29 A.1. Define an Abstract Service Interface . . . . . . . . . . . 28
A.2. Using an Encapsulating Header . . . . . . . . . . . . . . 29 A.2. Using an Encapsulating Header . . . . . . . . . . . . . . 29
A.3. Modifying Existing Fields in an SNMP Message . . . . . . . 30 A.3. Modifying Existing Fields in an SNMP Message . . . . . . . 29
A.4. Using a Cache . . . . . . . . . . . . . . . . . . . . . . 30 A.4. Using a Cache . . . . . . . . . . . . . . . . . . . . . . 29
Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . . 30 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . . 30
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 31 Appendix C. 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 4, line 50 skipping to change at page 4, line 50
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 transport-independent securityName and securityLevel translated into transport-independent securityName and securityLevel
parameters parameters
The Secure Shell Transport Model [I-D.ietf-isms-secshell] and the The Transport Security Model [I-D.ietf-isms-transport-security-model]
Transport Security Model [I-D.ietf-isms-transport-security-model] and the Secure Shell Transport Model [I-D.ietf-isms-secshell] utilize
utilize the Transport Subsystem. the Transport Subsystem. The Transport Security Model is an
alternative to the existing SNMPv1 Security Model [RFC3584], the
SNMPv2c Security Model [RFC3584], and the User-based Secutiry Model
[RFC3414]. The Secure Shell Transport Model is an alternative to
existing transport mappings (or models) as described in [RFC3417].
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].
Non uppercased versions of the keywords should be read as in normal Non uppercased versions of the keywords should be read as in normal
English. They will usually, but not always, be used in a context English. They will usually, but not always, be used in a context
relating to compatibility with the RFC3411 architecture or the relating to compatibility with the RFC3411 architecture or the
skipping to change at page 11, line 10 skipping to change at page 11, line 10
| 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 in 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. With USM and some other Security Models,
in the flow and the responsibility for different processing steps for security processing starts when the Message Processing Model decodes
incoming messages when using USM and when using a secure transport. portions of the encoded message to extract security parameters and
(Note that these lists are simplified for illustrative purposes, and header parameters that identify which Security Model should process
do not represent all details of processing. Transport Models must the message to perform authentication, decryption, timeliness
provide the detailed elements of procedure.) checking, integrity checking, and translation of parameters to model-
independent parameters. A secure transport performs those security
With USM and other Security Models, security processing starts when functions on the message, before the message is decoded.
the Message Processing Model decodes portions of the ASN.1 message to
extract an opaque block of security parameters and header parameters
that identify which Security Model should process the message to
perform authentication, decryption, timeliness checking, integrity
checking, and translation of parameters to model-independent
parameters. A secure transport performs those security functions on
the message, before the ASN.1 is decoded.
Step 6 cannot occur until after decryption occurs. Step 6 and beyond
are the same for USM and a secure transport.
3.2.1.1.1. USM and the RFC3411 Architecture
1) decode the ASN.1 header (Message Processing Model)
2) determine the SNMP Security Model and parameters (Message
Processing Model)
3) verify securityLevel. [Security Model]
4) translate parameters to model-independent parameters (Security
Model)
5) authenticate the principal, check message integrity and
timeliness, and decrypt the message. [Security Model]
6) determine the pduType in the decrypted portions (Message
Processing Model), and
7) pass on the decrypted portions with model-independent parameters.
3.2.1.2. Transport Subsystem and the RFC3411 Architecture
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
Model)
3) decode the ASN.1 header (Message Processing Model)
4) determine the SNMP Security Model and parameters (Message
Processing Model)
5) verify securityLevel [Security Model]
6) determine the pduType in the decrypted portions (Message
Processing Model), and
7) pass on the decrypted portions with model-independent security
parameters
If a message is secured using a secure transport layer, then the
Transport Model should provide the translation from the authenticated
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.2. 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.
3.2.2. Access Control Requirements 3.2.2. Access Control Requirements
skipping to change at page 26, line 32 skipping to change at page 25, line 32
Security models defined before the Transport Security Model (i.e., Security models defined before the Transport Security Model (i.e.,
SNMPv1, SNMPv2c, and USM) do not support transport-based security, SNMPv1, SNMPv2c, and USM) do not support transport-based security,
and only have access to the security parameters contained within the and only have access to the security parameters contained within the
SNMP message. They do not know about the security parameters SNMP message. They do not know about the security parameters
associated with a secure transport. As a result, the Access Control associated with a secure transport. As a result, the Access Control
Subsystem bases its decisions on the security parameters extracted Subsystem bases its decisions on the security parameters extracted
from the SNMP message, not on transport-based security parameters. from the SNMP message, not on transport-based security parameters.
Implications of coexistence of older security models with secure Implications of coexistence of older security models with secure
transport models are known: transport models are known. The securityName used for access control
decisions represents an SNMP-authenticated identity, not the
transport-authenticated identity. (I can transport-authenticate as
guest and then simply use a community name for root, or a USM non-
authenticated identity.)
o An SNMPv1 message will always be paired with an SNMPv1 Security o An SNMPv1 message will always be paired with an SNMPv1 Security
Model (per RFC3584), regardless of the transport mapping or Model (per RFC3584), regardless of the transport mapping or
transport model used, and access controls will be based on the transport model used, and access controls will be based on the
community name. community name.
o An SNMPv2c message will always be paired with an SNMPv2c Security o An SNMPv2c message will always be paired with an SNMPv2c Security
Model (per RFC3584), regardless of the transport mapping or Model (per RFC3584), regardless of the transport mapping or
transport model used, and access controls will be based on the transport model used, and access controls will be based on the
community name.. community name.
o An SNMPv3 message will always be paired with the securityModel o An SNMPv3 message will always be paired with the securityModel
specified in the msgSecurityParameters field of the message (per specified in the msgSecurityParameters field of the message (per
RFC3412), regardless of the transport mappng or transport model RFC3412), regardless of the transport mappng or transport model
used. If the SNMPv3 message specifies the User-based Security used. If the SNMPv3 message specifies the User-based Security
Model (USM), access controls will be based on the USM user.If the Model (USM), access controls will be based on the USM user.If the
SNMPv3 message specifies the Transport Security Model (TSM), SNMPv3 message specifies the Transport Security Model (TSM),
access controls will be based on the principal authenticated by access controls will be based on the principal authenticated by
the transport. the transport.
8. IANA Considerations 8. IANA Considerations
skipping to change at page 28, line 31 skipping to change at page 27, line 34
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.
[RFC3584] Frye, R., Levi, D.,
Routhier, S., and B.
Wijnen, "Coexistence
between Version 1, Version
2, and Version 3 of the
Internet-standard Network
Management Framework",
BCP 74, RFC 3584,
August 2003.
[RFC4346] Dierks, T. and E. Rescorla, [RFC4346] Dierks, T. and E. Rescorla,
"The Transport Layer "The Transport Layer
Security (TLS) Protocol Security (TLS) Protocol
Version 1.1", RFC 4346, Version 1.1", RFC 4346,
April 2006. 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,
skipping to change at page 29, line 8 skipping to change at page 28, line 19
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-05 (work in security-model-06 (work in
progress), July 2007. progress), September 2007.
[I-D.ietf-isms-secshell] Salowey, J. and D. [I-D.ietf-isms-secshell] Harrington, D. and J.
Harrington, "Secure Shell Salowey, "Secure Shell
Transport Model for SNMP", Transport Model for SNMP",
draft-ietf-isms-secshell-08 draft-ietf-isms-secshell-09
(work in progress), (work in progress),
July 2007. November 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
 End of changes. 16 change blocks. 
96 lines changed or deleted 70 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/