draft-ietf-isms-tmsm-11.txt   draft-ietf-isms-tmsm-12.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 November 18, 2007 Intended status: Standards Track February 25, 2008
Expires: May 21, 2008 Expires: August 28, 2008
Transport Subsystem for the Simple Network Management Protocol (SNMP) Transport Subsystem for the Simple Network Management Protocol (SNMP)
draft-ietf-isms-tmsm-11 draft-ietf-isms-tmsm-12
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 May 21, 2008. This Internet-Draft will expire on August 28, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
Abstract Abstract
This document defines a Transport Subsystem, extending the Simple This document defines a Transport Subsystem, extending the Simple
Network Management Protocol (SNMP) architecture defined in RFC 3411. Network Management Protocol (SNMP) architecture defined in RFC 3411.
This document defines a subsystem to contain Transport Models, This document defines a subsystem to contain Transport Models,
comparable to other subsystems in the RFC3411 architecture. As work comparable to other subsystems in the RFC3411 architecture. As work
is being done to expand the transport to include secure transport is being done to expand the transport to include secure transport
such as SSH and TLS, using a subsystem will enable consistent design such as SSH and TLS, using a subsystem will enable consistent design
and modularity of such Transport Models. This document identifies and modularity of such Transport Models. This document identifies
skipping to change at page 5, line 6 skipping to change at page 5, line 6
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 Transport Security Model [I-D.ietf-isms-transport-security-model] The Transport Security Model [I-D.ietf-isms-transport-security-model]
and the Secure Shell Transport Model [I-D.ietf-isms-secshell] utilize and the Secure Shell Transport Model [I-D.ietf-isms-secshell] utilize
the Transport Subsystem. The Transport Security Model is an the Transport Subsystem. The Transport Security Model is an
alternative to the existing SNMPv1 Security Model [RFC3584], the alternative to the existing SNMPv1 Security Model [RFC3584], the
SNMPv2c Security Model [RFC3584], and the User-based Secutiry Model SNMPv2c Security Model [RFC3584], and the User-based Security Model
[RFC3414]. The Secure Shell Transport Model is an alternative to [RFC3414]. The Secure Shell Transport Model is an alternative to
existing transport mappings (or models) as described in [RFC3417]. 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
skipping to change at page 18, line 32 skipping to change at page 18, line 32
message is sent, then the response message SHOULD be discarded, even message is sent, then the response message SHOULD be discarded, even
if a new session has been established. The SNMPv3 WG decided that if a new session has been established. The SNMPv3 WG decided that
this should be a SHOULD architecturally, and it is a security-model- this should be a SHOULD architecturally, and it is a security-model-
specific decision whether to REQUIRE this. specific decision whether to REQUIRE this.
Since a transport model does not know whether a message contains a Since a transport model does not know whether a message contains a
response, and transport session information is transport-model- response, and transport session information is transport-model-
specific, the tmStateReference contains two pieces of information for specific, the tmStateReference contains two pieces of information for
performing the request-response transport session pairing. performing the request-response transport session pairing.
Each Security Model that supports the tmStateReference cache SHOULD
pass a tmSameSecurity parameter in the tmStateReference cache for
outgoing messages to indicate whether the same security parameters
MUST be used for the outgoing message as was used for the
corresponding incoming message.
Each transport model that supports sessions and supports the Each transport model that supports sessions and supports the
tmStateReference cache SHOULD include a transport-specific session tmStateReference cache SHOULD include a transport-specific session
identifier in the cache for an incoming message, so that if a identifier in the cache for an incoming message, so that if a
security model requests the same session, the transport model can security model requests tmSameSecurity, the transport model can
determine whether the current existing session is the same as the determine whether the current existing transport session is the same
session used for the incoming request. as the transport session used for the incoming request.
Each Security Model that supports the tmStateReference cache SHOULD
pass a tmSameSession parameter in the tmStateReference cache for
outgoing messages to indicate whether the same session MUST be used
for the outgoing message as was used for the corresponding incoming
message.
If the same session requirement is indicated by the security model, When processing an outgoing message, if the tmSameSecurity
but the session identified in the tmStateReference does not match the requirement is indicated by the security model, but the session
current established transport session, i.e., it is not the same identified in the tmStateReference does not match the current
established transport session, i.e., it is not the same transport
session, then the message MUST be discarded, and the dispatcher session, then the message MUST be discarded, and the dispatcher
should be notified the sending of the message failed. should be notified the sending of the message failed.
Since the contents of a cache are meaningful only within an Since the contents of a cache are meaningful only within an
implementation, and not on-the-wire, the format of the cache and the implementation, and not on-the-wire, the format of the cache and the
LCD are implementation-specific. LCD are implementation-specific.
6. Abstract Service Interfaces 6. Abstract Service Interfaces
Abstract service interfaces have been defined by RFC 3411 to describe Abstract service interfaces have been defined by RFC 3411 to describe
skipping to change at page 25, line 47 skipping to change at page 25, line 47
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 mapping 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
SNMPv3 message specifies the Transport Security Model (TSM), the 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
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
skipping to change at page 28, line 19 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-06 (work in security-model-07 (work in
progress), September 2007. progress), November 2007.
[I-D.ietf-isms-secshell] Harrington, D. and J. [I-D.ietf-isms-secshell] Harrington, D. and J.
Salowey, "Secure Shell Salowey, "Secure Shell
Transport Model for SNMP", Transport Model for SNMP",
draft-ietf-isms-secshell-09 draft-ietf-isms-secshell-09
(work in progress), (work in progress),
November 2007. November 2007.
Appendix A. Why tmStateReference? Appendix A. Why tmStateReference?
skipping to change at page 34, line 7 skipping to change at page 34, line 7
Jacobs 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 (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 End of changes. 12 change blocks. 
24 lines changed or deleted 25 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/