draft-ietf-isms-dtls-tm-03.txt   draft-ietf-isms-dtls-tm-04.txt 
ISMS W. Hardaker ISMS W. Hardaker
Internet-Draft Sparta, Inc. Internet-Draft Sparta, Inc.
Intended status: Standards Track December 23, 2009 Intended status: Standards Track December 30, 2009
Expires: June 26, 2010 Expires: July 3, 2010
Transport Layer Security (TLS) Transport Model for SNMP Transport Layer Security (TLS) Transport Model for SNMP
draft-ietf-isms-dtls-tm-03.txt draft-ietf-isms-dtls-tm-04.txt
Abstract Abstract
This document describes a Transport Model for the Simple Network This document describes a Transport Model for the Simple Network
Management Protocol (SNMP), that uses either the Transport Layer Management Protocol (SNMP), that uses either the Transport Layer
Security protocol or the Datagram Transport Layer Security (DTLS) Security protocol or the Datagram Transport Layer Security (DTLS)
protocol. The TLS and DTLS protocols provide authentication and protocol. The TLS and DTLS protocols provide authentication and
privacy services for SNMP applications. This document describes how privacy services for SNMP applications. This document describes how
the TLS Transport Model (TLSTM) implements the needed features of a the TLS Transport Model (TLSTM) implements the needed features of a
SNMP Transport Subsystem to make this protection possible in an SNMP Transport Subsystem to make this protection possible in an
skipping to change at page 2, line 9 skipping to change at page 2, line 9
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 June 26, 2010. This Internet-Draft will expire on July 3, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 36 skipping to change at page 3, line 36
4.4.1.1. tmSecurityName . . . . . . . . . . . . . . . . . . 19 4.4.1.1. tmSecurityName . . . . . . . . . . . . . . . . . . 19
4.4.1.2. tmSessionID . . . . . . . . . . . . . . . . . . . 19 4.4.1.2. tmSessionID . . . . . . . . . . . . . . . . . . . 19
4.4.1.3. Session State . . . . . . . . . . . . . . . . . . 19 4.4.1.3. Session State . . . . . . . . . . . . . . . . . . 19
5. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 20 5. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 20
5.1. Procedures for an Incoming Message . . . . . . . . . . . . 20 5.1. Procedures for an Incoming Message . . . . . . . . . . . . 20
5.1.1. DTLS Processing for Incoming Messages . . . . . . . . 20 5.1.1. DTLS Processing for Incoming Messages . . . . . . . . 20
5.1.2. Transport Processing for Incoming SNMP Messages . . . 22 5.1.2. Transport Processing for Incoming SNMP Messages . . . 22
5.2. Procedures for an Outgoing SNMP Message . . . . . . . . . 23 5.2. Procedures for an Outgoing SNMP Message . . . . . . . . . 23
5.3. Establishing a Session . . . . . . . . . . . . . . . . . . 24 5.3. Establishing a Session . . . . . . . . . . . . . . . . . . 24
5.4. Closing a Session . . . . . . . . . . . . . . . . . . . . 27 5.4. Closing a Session . . . . . . . . . . . . . . . . . . . . 27
6. MIB Module Overview . . . . . . . . . . . . . . . . . . . . . 27 6. MIB Module Overview . . . . . . . . . . . . . . . . . . . . . 28
6.1. Structure of the MIB Module . . . . . . . . . . . . . . . 28 6.1. Structure of the MIB Module . . . . . . . . . . . . . . . 28
6.2. Textual Conventions . . . . . . . . . . . . . . . . . . . 28 6.2. Textual Conventions . . . . . . . . . . . . . . . . . . . 28
6.3. Statistical Counters . . . . . . . . . . . . . . . . . . . 28 6.3. Statistical Counters . . . . . . . . . . . . . . . . . . . 28
6.4. Configuration Tables . . . . . . . . . . . . . . . . . . . 28 6.4. Configuration Tables . . . . . . . . . . . . . . . . . . . 28
6.4.1. Notifications . . . . . . . . . . . . . . . . . . . . 28 6.4.1. Notifications . . . . . . . . . . . . . . . . . . . . 29
6.5. Relationship to Other MIB Modules . . . . . . . . . . . . 29 6.5. Relationship to Other MIB Modules . . . . . . . . . . . . 29
6.5.1. MIB Modules Required for IMPORTS . . . . . . . . . . . 29 6.5.1. MIB Modules Required for IMPORTS . . . . . . . . . . . 29
7. MIB Module Definition . . . . . . . . . . . . . . . . . . . . 29 7. MIB Module Definition . . . . . . . . . . . . . . . . . . . . 29
8. Operational Considerations . . . . . . . . . . . . . . . . . . 50 8. Operational Considerations . . . . . . . . . . . . . . . . . . 51
8.1. Sessions . . . . . . . . . . . . . . . . . . . . . . . . . 51 8.1. Sessions . . . . . . . . . . . . . . . . . . . . . . . . . 51
8.2. Notification Receiver Credential Selection . . . . . . . . 51 8.2. Notification Receiver Credential Selection . . . . . . . . 51
8.3. contextEngineID Discovery . . . . . . . . . . . . . . . . 51 8.3. contextEngineID Discovery . . . . . . . . . . . . . . . . 52
8.4. Transport Considerations . . . . . . . . . . . . . . . . . 52 8.4. Transport Considerations . . . . . . . . . . . . . . . . . 52
9. Security Considerations . . . . . . . . . . . . . . . . . . . 52 9. Security Considerations . . . . . . . . . . . . . . . . . . . 52
9.1. Certificates, Authentication, and Authorization . . . . . 52 9.1. Certificates, Authentication, and Authorization . . . . . 53
9.2. Use with SNMPv1/SNMPv2c Messages . . . . . . . . . . . . . 53 9.2. Use with SNMPv1/SNMPv2c Messages . . . . . . . . . . . . . 53
9.3. MIB Module Security . . . . . . . . . . . . . . . . . . . 53 9.3. MIB Module Security . . . . . . . . . . . . . . . . . . . 54
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 55 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 55
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 56 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 57
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 57 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 57
12.1. Normative References . . . . . . . . . . . . . . . . . . . 57 12.1. Normative References . . . . . . . . . . . . . . . . . . . 57
12.2. Informative References . . . . . . . . . . . . . . . . . . 58 12.2. Informative References . . . . . . . . . . . . . . . . . . 58
Appendix A. (D)TLS Overview . . . . . . . . . . . . . . . . . . . 59 Appendix A. (D)TLS Overview . . . . . . . . . . . . . . . . . . . 59
A.1. The (D)TLS Record Protocol . . . . . . . . . . . . . . . . 59 A.1. The (D)TLS Record Protocol . . . . . . . . . . . . . . . . 60
A.2. The (D)TLS Handshake Protocol . . . . . . . . . . . . . . 60 A.2. The (D)TLS Handshake Protocol . . . . . . . . . . . . . . 60
Appendix B. PKIX Certificate Infrastructure . . . . . . . . . . . 61 Appendix B. PKIX Certificate Infrastructure . . . . . . . . . . . 61
Appendix C. Target and Notificaton Configuration Example . . . . 62 Appendix C. Target and Notificaton Configuration Example . . . . 62
C.1. Configuring the Notification Generator . . . . . . . . . . 63 C.1. Configuring the Notification Generator . . . . . . . . . . 63
C.2. Configuring the Command Responder . . . . . . . . . . . . 63 C.2. Configuring the Command Responder . . . . . . . . . . . . 63
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 64
1. Introduction 1. Introduction
It is important to understand the modular SNMPv3 architecture as It is important to understand the modular SNMPv3 architecture as
skipping to change at page 14, line 16 skipping to change at page 14, line 16
provided by the Dispatcher in the sendMessage() Abstract Service provided by the Dispatcher in the sendMessage() Abstract Service
Interface (ASI) and input from the tmStateReference cache. The Interface (ASI) and input from the tmStateReference cache. The
(D)TLS Transport Model converts that information into suitable (D)TLS Transport Model converts that information into suitable
security parameters for (D)TLS and establishes sessions as needed. security parameters for (D)TLS and establishes sessions as needed.
The elements of procedure in Section 5 discuss these concepts in much The elements of procedure in Section 5 discuss these concepts in much
greater detail. greater detail.
3.3. Notifications and Proxy 3.3. Notifications and Proxy
(D)TLS sessions may be initiated by (D)TLS clients on behalf of (D)TLS sessions may be initiated by (D)TLS clients on behalf of SNMP
command generators, notification originators, proxy forwarders or appplications that initiate communications, such as command
other applications. Command generators are frequently operated by a generators, notification originators, proxy forwarders. Command
human, but notification originators and proxy forwarders are usually generators are frequently operated by a human, but notification
unmanned automated processes. The targets to whom notifications and originators and proxy forwarders are usually unmanned automated
proxied requests should be sent is typically determined and processes. The targets to whom notifications and proxied requests
configured by a network administrator. should be sent is typically determined and configured by a network
administrator.
The SNMP-TARGET-MIB module [RFC3413] contains objects for defining The SNMP-TARGET-MIB module [RFC3413] contains objects for defining
management targets, including transportDomain, transportAddress, management targets, including transportDomain, transportAddress,
securityName, securityModel, and securityLevel parameters, for securityName, securityModel, and securityLevel parameters, for
notification generator, proxy forwarder, and SNMP-controllable notification generator, proxy forwarder, and SNMP-controllable
command generator applications. Transport domains and transport command generator applications. Transport domains and transport
addresses are configured in the snmpTargetAddrTable, and the addresses are configured in the snmpTargetAddrTable, and the
securityModel, securityName, and securityLevel parameters are securityModel, securityName, and securityLevel parameters are
configured in the snmpTargetParamsTable. This document defines a MIB configured in the snmpTargetParamsTable. This document defines a MIB
module that extends the SNMP-TARGET-MIB's snmpTargetParamsTable to module that extends the SNMP-TARGET-MIB's snmpTargetParamsTable to
skipping to change at page 26, line 18 skipping to change at page 26, line 18
3) Once a (D)TLS secured session is established and both sides have 3) Once a (D)TLS secured session is established and both sides have
verified the authenticity of the peer's certificate (e.g. verified the authenticity of the peer's certificate (e.g.
[RFC5280]) then each side will determine and/or check the [RFC5280]) then each side will determine and/or check the
identity of the remote entity using the procedures described identity of the remote entity using the procedures described
below. below.
a) The (D)TLS server side of the connection identifies the a) The (D)TLS server side of the connection identifies the
authenticated identity from the (D)TLS client's principal authenticated identity from the (D)TLS client's principal
certificate using configuration information from the certificate using configuration information from the
tlstmCertToTSNTable mapping table. The resulting derived tlstmCertToTSNTable mapping table. The (D)TLS server MUST
tmSecurityName is recorded in the tmStateReference cache as request and expect a certificate from the client and MUST NOT
tmSecurityName. The details of the lookup process are fully accept SNMP messages over the (D)TLS session until the client
described in the DESCRIPTION clause of the has sent a certificate and it has been authenticated. The
tlstmCertToTSNTable MIB object. If any verification fails in resulting derived tmSecurityName is recorded in the
any way (for example because of failures in cryptographic tmStateReference cache as tmSecurityName. The details of the
verification or because of the lack of an appropriate row in lookup process are fully described in the DESCRIPTION clause
the tlstmCertToTSNTable) then the session establishment MUST of the tlstmCertToTSNTable MIB object. If any verification
fail, the snmpTlstmSessionInvalidClientCertificates object is fails in any way (for example because of failures in
cryptographic verification or because of the lack of an
appropriate row in the tlstmCertToTSNTable) then the session
establishment MUST fail, the
snmpTlstmSessionInvalidClientCertificates object is
incremented and processing stops. incremented and processing stops.
b) The (D)TLS client side of the connection MUST verify that b) The (D)TLS client side of the connection MUST verify that
authenticated identity of the (D)TLS server's presented authenticated identity of the (D)TLS server's presented
certificate is the expected certificate. certificate is the expected certificate. The (D)TLS client
MUST NOT transmit SNMP messages until the server certificate
has been authenticated and the client certificate has been
transmitted.
If the connection is being established from configuration If the connection is being established from configuration
based on SNMP-TARGET-MIB configuration then the procedures in based on SNMP-TARGET-MIB configuration then the procedures in
the tlstmAddrTable DESCRIPTION clause should be followed to the tlstmAddrTable DESCRIPTION clause should be followed to
determine the if the presented identity matches the determine if the presented identity matches the expectations
expectations of the configuration. Path validation of the configuration. Path validation procedures (like those
procedures (like those defined in [RFC5280]) MUST be defined in [RFC5280]) MUST be followed. If a server identity
followed. If a server identity name has been configured in name has been configured in the tlstmAddrServerIdentity
the tlstmAddrServerIdentity column then this reference column then this reference identity must be compared against
identity must be compared against the presented identity (for the presented identity (for example using procedures
example using procedures described in described in [I-D.saintandre-tls-server-id-check]).
[I-D.saintandre-tls-server-id-check]).
If the connection is being established for other reasons then If the connection is being established for other reasons then
configuration and procedures outside the scope of this configuration and procedures outside the scope of this
document should be followed. document should be followed.
(D)TLS provides assurance that the authenticated identity has (D)TLS provides assurance that the authenticated identity has
been signed by a trusted configured certificate authority. been signed by a trusted configured certificate authority.
If verification of the server's certificate fails in any way If verification of the server's certificate fails in any way
(for example because of failures in cryptographic (for example because of failures in cryptographic
verification or the presented identity did not match the verification or the presented identity did not match the
expected named entity) then the session establishment MUST expected named entity) then the session establishment MUST
fail, the snmpTlstmSessionInvalidServerCertificates object is fail, the snmpTlstmSessionInvalidServerCertificates object is
incremented and processing stops. incremented and processing stops.
4) The (D)TLS-specific session identifier is set in the sessionID of 4) The TLSTM-specific session identifier (tlstmSessionID) is set in
the tmStateReference passed to the TLS Transport Model to the sessionID of the tmStateReference passed to the TLS Transport
indicate that the session has been established successfully and Model to indicate that the session has been established
to point to a specific (D)TLS session for future use. successfully and to point to a specific (D)TLS session for future
use.
Servers that wish to support multiple principals at a particular port Servers that wish to support multiple principals at a particular port
SHOULD make use of the Server Name Indication extension defined in SHOULD make use of the Server Name Indication extension defined in
Section 3.1 of [RFC4366]. Supporting this will allow, for example, Section 3.1 of [RFC4366]. Supporting this will allow, for example,
sending notifications to a specific principal at a given TCP, UDP or sending notifications to a specific principal at a given TCP, UDP or
SCTP port. SCTP port.
5.4. Closing a Session 5.4. Closing a Session
The TLS Transport Model provides the following primitive to close a The TLS Transport Model provides the following primitive to close a
skipping to change at page 29, line 44 skipping to change at page 30, line 6
FROM SNMPv2-TC FROM SNMPv2-TC
MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP
FROM SNMPv2-CONF FROM SNMPv2-CONF
SnmpAdminString SnmpAdminString
FROM SNMP-FRAMEWORK-MIB FROM SNMP-FRAMEWORK-MIB
snmpTargetParamsName, snmpTargetAddrName snmpTargetParamsName, snmpTargetAddrName
FROM SNMP-TARGET-MIB FROM SNMP-TARGET-MIB
; ;
tlstmMIB MODULE-IDENTITY tlstmMIB MODULE-IDENTITY
LAST-UPDATED "200912230000Z" LAST-UPDATED "200912300000Z"
ORGANIZATION "ISMS Working Group" ORGANIZATION "ISMS Working Group"
CONTACT-INFO "WG-EMail: isms@lists.ietf.org CONTACT-INFO "WG-EMail: isms@lists.ietf.org
Subscribe: isms-request@lists.ietf.org Subscribe: isms-request@lists.ietf.org
Chairs: Chairs:
Juergen Schoenwaelder Juergen Schoenwaelder
Jacobs University Bremen Jacobs University Bremen
Campus Ring 1 Campus Ring 1
28725 Bremen 28725 Bremen
Germany Germany
skipping to change at page 30, line 44 skipping to change at page 31, line 4
to the license terms contained in, the Simplified BSD License to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info).
This version of this MIB module is part of RFC XXXX; This version of this MIB module is part of RFC XXXX;
see the RFC itself for full legal notices." see the RFC itself for full legal notices."
-- NOTE to RFC editor: replace XXXX with actual RFC number -- NOTE to RFC editor: replace XXXX with actual RFC number
-- for this document and remove this note -- for this document and remove this note
REVISION "200912300000Z"
REVISION "200912230000Z"
DESCRIPTION "The initial version, published in RFC XXXX." DESCRIPTION "The initial version, published in RFC XXXX."
-- NOTE to RFC editor: replace XXXX with actual RFC number -- NOTE to RFC editor: replace XXXX with actual RFC number
-- for this document and remove this note -- for this document and remove this note
::= { snmpModules xxxx } ::= { snmpModules xxxx }
-- RFC Ed.: replace xxxx with IANA-assigned number and -- RFC Ed.: replace xxxx with IANA-assigned number and
-- remove this note -- remove this note
-- ************************************************ -- ************************************************
-- subtrees of the TLSTM-MIB -- subtrees of the TLSTM-MIB
skipping to change at page 51, line 30 skipping to change at page 51, line 37
Implementations SHOULD limit the lifetime of established sessions Implementations SHOULD limit the lifetime of established sessions
depending on the algorithms used for generation of the master session depending on the algorithms used for generation of the master session
secret, the privacy and integrity algorithms used to protect secret, the privacy and integrity algorithms used to protect
messages, the environment of the session, the amount of data messages, the environment of the session, the amount of data
transferred, and the sensitivity of the data. transferred, and the sensitivity of the data.
8.2. Notification Receiver Credential Selection 8.2. Notification Receiver Credential Selection
When an SNMP engine needs to establish an outgoing session for When an SNMP engine needs to establish an outgoing session for
notifications, the snmpTargetParamsTable includes an entry for the notifications, the snmpTargetParamsTable includes an entry for the
snmpTargetParamsSecurityName of the target. However, the receiving snmpTargetParamsSecurityName of the target. Servers that wish to
SNMP engine (Server) does not know which (D)TLS certificate to offer support multiple principals at a particular port SHOULD make use of
to the Client so that the tmSecurityName identity-authentication will the Server Name Indication extension defined in Section 3.1 of
be successful. [RFC4366]. Without the Server Name Indication the receiving SNMP
engine (Server) will not know which (D)TLS certificate to offer to
the Client so that the tmSecurityName identity-authentication will be
successful.
One solution is to maintain a one-to-one mapping between certificates Another solution is to maintain a one-to-one mapping between
and incoming ports for notification receivers. This can be handled certificates and incoming ports for notification receivers. This can
at the notification originator by configuring the snmpTargetAddrTable be handled at the notification originator by configuring the
(snmpTargetAddrTDomain and snmpTargetAddrTAddress) and requiring the snmpTargetAddrTable (snmpTargetAddrTDomain and
receiving SNMP engine to monitor multiple incoming static ports based snmpTargetAddrTAddress) and requiring the receiving SNMP engine to
on which principals are capable of receiving notifications. monitor multiple incoming static ports based on which principals are
capable of receiving notifications.
Implementations MAY also choose to designate a single Notification Implementations MAY also choose to designate a single Notification
Receiver Principal to receive all incoming notifications or select an Receiver Principal to receive all incoming notifications or select an
implementation specific method of selecting a server certificate to implementation specific method of selecting a server certificate to
present to clients. present to clients.
8.3. contextEngineID Discovery 8.3. contextEngineID Discovery
Most command responders have contextEngineIDs that are identical to Most command responders have contextEngineIDs that are identical to
the USM securityEngineID. USM provides a discovery service that the USM securityEngineID. USM provides a discovery service that
skipping to change at page 56, line 51 skipping to change at page 57, line 14
to publication. to publication.
11. Acknowledgements 11. Acknowledgements
This document closely follows and copies the Secure Shell Transport This document closely follows and copies the Secure Shell Transport
Model for SNMP defined by David Harrington and Joseph Salowey in Model for SNMP defined by David Harrington and Joseph Salowey in
[RFC5292]. [RFC5292].
This document was reviewed by the following people who helped provide This document was reviewed by the following people who helped provide
useful comments (in alphabetical order): Andy Donati, Pasi Eronen, useful comments (in alphabetical order): Andy Donati, Pasi Eronen,
David Harrington, Jeffrey Hutzelman, Alan Luchuk, Randy Presuhn, Ray David Harrington, Jeffrey Hutzelman, Alan Luchuk, Tom Petch, Randy
Purvis, Joseph Salowey, Jurgen Schonwalder, Dave Shield. Presuhn, Ray Purvis, Joseph Salowey, Jurgen Schonwalder, Dave Shield.
This work was supported in part by the United States Department of This work was supported in part by the United States Department of
Defense. Large portions of this document are based on work by Defense. Large portions of this document are based on work by
General Dynamics C4 Systems and the following individuals: Brian General Dynamics C4 Systems and the following individuals: Brian
Baril, Kim Bryant, Dana Deluca, Dan Hanson, Tim Huemiller, John Baril, Kim Bryant, Dana Deluca, Dan Hanson, Tim Huemiller, John
Holzhauer, Colin Hoogeboom, Dave Kornbau, Chris Knaian, Dan Knaul, Holzhauer, Colin Hoogeboom, Dave Kornbau, Chris Knaian, Dan Knaul,
Charles Limoges, Steve Moccaldi, Gerardo Orlando, and Brandon Yip. Charles Limoges, Steve Moccaldi, Gerardo Orlando, and Brandon Yip.
12. References 12. References
 End of changes. 21 change blocks. 
56 lines changed or deleted 67 lines changed or added

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