Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 6353

Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP)

Pages: 65
Internet Standard: 78
STD 78 is also:  534355905591
Obsoletes:  5953
Updated by:  89969456
Part 4 of 4 – Pages 54 to 65
First   Prev   None

Top   ToC   RFC6353 - Page 54   prevText

8. Operational Considerations

This section discusses various operational aspects of deploying TLSTM.

8.1. Sessions

A session is discussed throughout this document as meaning a security association between two TLSTM instances. State information for the sessions are maintained in each TLSTM implementation and this information is created and destroyed as sessions are opened and closed. A "broken" session (one side up and one side down) can result if one side of a session is brought down abruptly (i.e., reboot, power outage, etc.). Whenever possible, implementations SHOULD provide graceful session termination through the use of TLS disconnect messages. Implementations SHOULD also have a system in place for detecting "broken" sessions through the use of heartbeats [HEARTBEAT] or other detection mechanisms. Implementations SHOULD limit the lifetime of established sessions depending on the algorithms used for generation of the master session secret, the privacy and integrity algorithms used to protect messages, the environment of the session, the amount of data transferred, and the sensitivity of the data.

8.2. Notification Receiver Credential Selection

When an SNMP engine needs to establish an outgoing session for notifications, the snmpTargetParamsTable includes an entry for the snmpTargetParamsSecurityName of the target. Servers that wish to support multiple principals at a particular port SHOULD make use of the Server Name Indication extension defined in Section 3.1 of [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. Another solution is to maintain a one-to-one mapping between certificates and incoming ports for notification receivers. This can be handled at the notification originator by configuring the snmpTargetAddrTable (snmpTargetAddrTDomain and snmpTargetAddrTAddress) and requiring the receiving SNMP engine to monitor multiple incoming static ports based on which principals are capable of receiving notifications. Implementations MAY also choose to designate a single Notification Receiver Principal to receive all incoming notifications or select an
Top   ToC   RFC6353 - Page 55
   implementation specific method of selecting a server certificate to
   present to clients.

8.3. contextEngineID Discovery

SNMPv3 requires that an application know the identifier (snmpEngineID) of the remote SNMP protocol engine in order to retrieve or manipulate objects maintained on the remote SNMP entity. [RFC5343] introduces a well-known localEngineID and a discovery mechanism that can be used to learn the snmpEngineID of a remote SNMP protocol engine. Implementations are RECOMMENDED to support and use the contextEngineID discovery mechanism defined in [RFC5343].

8.4. Transport Considerations

This document defines how SNMP messages can be transmitted over the TLS- and DTLS-based protocols. Each of these protocols is additionally based on other transports (TCP and UDP). These two base protocols also have operational considerations that must be taken into consideration when selecting a (D)TLS-based protocol to use such as its performance in degraded or limited networks. It is beyond the scope of this document to summarize the characteristics of these transport mechanisms. Please refer to the base protocol documents for details on messaging considerations with respect to MTU size, fragmentation, performance in lossy networks, etc.

9. Security Considerations

This document describes a transport model that permits SNMP to utilize (D)TLS security services. The security threats and how the (D)TLS transport model mitigates these threats are covered in detail throughout this document. Security considerations for DTLS are covered in [RFC4347] and security considerations for TLS are described in Section 11 and Appendices D, E, and F of TLS 1.2 [RFC5246]. When run over a connectionless transport such as UDP, DTLS is more vulnerable to denial-of-service attacks from spoofed IP addresses; see Section 4.2 for details how the cookie exchange is used to address this issue.

9.1. Certificates, Authentication, and Authorization

Implementations are responsible for providing a security certificate installation and configuration mechanism. Implementations SHOULD support certificate revocation lists. (D)TLS provides for authentication of the identity of both the (D)TLS server and the (D)TLS client. Access to MIB objects for the
Top   ToC   RFC6353 - Page 56
   authenticated principal MUST be enforced by an access control
   subsystem (e.g., the VACM).

   Authentication of the command generator principal's identity is
   important for use with the SNMP access control subsystem to ensure
   that only authorized principals have access to potentially sensitive
   data.  The authenticated identity of the command generator
   principal's certificate is mapped to an SNMP model-independent
   securityName for use with SNMP access control.

   The (D)TLS handshake only provides assurance that the certificate of
   the authenticated identity has been signed by a configured accepted
   Certification Authority.  (D)TLS has no way to further authorize or
   reject access based on the authenticated identity.  An Access Control
   Model (such as the VACM) provides access control and authorization of
   a command generator's requests to a command responder and a
   notification receiver's authorization to receive Notifications from a
   notification originator.  However, to avoid man-in-the-middle
   attacks, both ends of the (D)TLS-based connection MUST check the
   certificate presented by the other side against what was expected.
   For example, command generators must check that the command responder
   presented and authenticated itself with an X.509 certificate that was
   expected.  Not doing so would allow an impostor, at a minimum, to
   present false data, receive sensitive information, and/or provide a
   false belief that configuration was actually received and acted upon.
   Authenticating and verifying the identity of the (D)TLS server and
   the (D)TLS client for all operations ensures the authenticity of the
   SNMP engine that provides MIB data.

   The instructions found in the DESCRIPTION clause of the
   snmpTlstmCertToTSNTable object must be followed exactly.  It is also
   important that the rows of the table be searched in prioritized order
   starting with the row containing the lowest numbered
   snmpTlstmCertToTSNID value.

9.2. (D)TLS Security Considerations

This section discusses security considerations specific to the usage of (D)TLS.

9.2.1. TLS Version Requirements

Implementations of TLS typically support multiple versions of the Transport Layer Security protocol as well as the older Secure Sockets Layer (SSL) protocol. Because of known security vulnerabilities, TLSTM clients and servers MUST NOT request, offer, or use SSL 2.0. See Appendix E.2 of [RFC5246] for further details.
Top   ToC   RFC6353 - Page 57

9.2.2. Perfect Forward Secrecy

The use of Perfect Forward Secrecy is RECOMMENDED and can be provided by (D)TLS with appropriately selected cipher_suites, as discussed in Appendix F of [RFC5246].

9.3. Use with SNMPv1/SNMPv2c Messages

The SNMPv1 and SNMPv2c message processing described in [RFC3584] (BCP 74) always selects the SNMPv1 or SNMPv2c Security Models, respectively. Both of these and the User-based Security Model typically used with SNMPv3 derive the securityName and securityLevel from the SNMP message received, even when the message was received over a secure transport. Access control decisions are therefore made based on the contents of the SNMP message, rather than using the authenticated identity and securityLevel provided by the TLS Transport Model. It is RECOMMENDED that only SNMPv3 messages using the Transport Security Model (TSM) or another secure-transport aware security model be sent over the TLSTM transport. Using a non-transport-aware Security Model with a secure Transport Model is NOT RECOMMENDED. See [RFC5590], Section 7.1 for additional details on the coexistence of security-aware transports and non- transport-aware security models.

9.4. MIB Module Security

There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. These are the tables and objects and their sensitivity/vulnerability: o The snmpTlstmParamsTable can be used to change the outgoing X.509 certificate used to establish a (D)TLS connection. Modifications to objects in this table need to be adequately authenticated since modifying the values in this table will have profound impacts to the security of outbound connections from the device. Since knowledge of authorization rules and certificate usage mechanisms may be considered sensitive, protection from disclosure of the SNMP traffic via encryption is also highly recommended. o The snmpTlstmAddrTable can be used to change the expectations of the certificates presented by a remote (D)TLS server. Modifications to objects in this table need to be adequately authenticated since modifying the values in this table will have
Top   ToC   RFC6353 - Page 58
      profound impacts to the security of outbound connections from the
      device.  Since knowledge of authorization rules and certificate
      usage mechanisms may be considered sensitive, protection from
      disclosure of the SNMP traffic via encryption is also highly
      recommended.

   o  The snmpTlstmCertToTSNTable is used to specify the mapping of
      incoming X.509 certificates to tmSecurityNames, which eventually
      get mapped to an SNMPv3 securityName.  Modifications to objects in
      this table need to be adequately authenticated since modifying the
      values in this table will have profound impacts to the security of
      incoming connections to the device.  Since knowledge of
      authorization rules and certificate usage mechanisms may be
      considered sensitive, protection from disclosure of the SNMP
      traffic via encryption is also highly recommended.  When this
      table contains a significant number of rows it may affect the
      system performance when accepting new (D)TLS connections.

   Some of the readable objects in this MIB module (i.e., objects with a
   MAX-ACCESS other than not-accessible) may be considered sensitive or
   vulnerable in some network environments.  It is thus important to
   control even GET and/or NOTIFY access to these objects and possibly
   to even encrypt the values of these objects when sending them over
   the network via SNMP.  These are the tables and objects and their
   sensitivity/vulnerability:

   o  This MIB contains a collection of counters that monitor the (D)TLS
      connections being established with a device.  Since knowledge of
      connection and certificate usage mechanisms may be considered
      sensitive, protection from disclosure of the SNMP traffic via
      encryption is highly recommended.

   SNMP versions prior to SNMPv3 did not include adequate security.
   Even if the network itself is secure (for example, by using IPsec),
   even then, there is no control as to who on the secure network is
   allowed to access and GET/SET (read/change/create/delete) the objects
   in this MIB module.

   It is RECOMMENDED that implementers consider the security features as
   provided by the SNMPv3 framework (see [RFC3410], Section 8),
   including full support for the SNMPv3 cryptographic mechanisms (for
   authentication and privacy).

   Further, deployment of SNMP versions prior to SNMPv3 is NOT
   RECOMMENDED.  Instead, it is RECOMMENDED to deploy SNMPv3 and to
   enable cryptographic security.  It is then a customer/operator
   responsibility to ensure that the SNMP entity giving access to an
   instance of this MIB module is properly configured to give access to
Top   ToC   RFC6353 - Page 59
   the objects only to those principals (users) that have legitimate
   rights to indeed GET or SET (change/create/delete) them.

10. IANA Considerations

IANA has assigned: 1. Two TCP/UDP port numbers from the "Registered Ports" range of the Port Numbers registry, with the following keywords: Keyword Decimal Description References ------- ------- ----------- ---------- snmptls 10161/tcp SNMP-TLS [RFC6353] snmpdtls 10161/udp SNMP-DTLS [RFC6353] snmptls-trap 10162/tcp SNMP-Trap-TLS [RFC6353] snmpdtls-trap 10162/udp SNMP-Trap-DTLS [RFC6353] These are the default ports for receipt of SNMP command messages (snmptls and snmpdtls) and SNMP notification messages (snmptls-trap and snmpdtls-trap) over a TLS Transport Model as defined in this document. 2. An SMI number (8) under snmpDomains for the snmpTLSTCPDomain object identifier 3. An SMI number (9) under snmpDomains for the snmpDTLSUDPDomain object identifier 4. An SMI number (198) under mib-2, for the MIB module in this document 5. "tls" as the corresponding prefix for the snmpTLSTCPDomain in the SNMP Transport Domains registry 6. "dtls" as the corresponding prefix for the snmpDTLSUDPDomain in the SNMP Transport Domains registry

11. Acknowledgements

This document closely follows and copies the Secure Shell Transport Model for SNMP documented by David Harrington and Joseph Salowey in [RFC5592]. This document was reviewed by the following people who helped provide useful comments (in alphabetical order): Andy Donati, Pasi Eronen, David Harrington, Jeffrey Hutzelman, Alan Luchuk, Michael Peck, Tom Petch, Randy Presuhn, Ray Purvis, Peter Saint-Andre, Joseph Salowey, Juergen Schoenwaelder, Dave Shield, and Robert Story.
Top   ToC   RFC6353 - Page 60
   This work was supported in part by the United States Department of
   Defense.  Large portions of this document are based on work by
   General Dynamics C4 Systems and the following individuals: Brian
   Baril, Kim Bryant, Dana Deluca, Dan Hanson, Tim Huemiller, John
   Holzhauer, Colin Hoogeboom, Dave Kornbau, Chris Knaian, Dan Knaul,
   Charles Limoges, Steve Moccaldi, Gerardo Orlando, and Brandon Yip.

12. References

12.1. Normative References

[RFC1123] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. [RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple Network Management Protocol (SNMP) Applications", STD 62, RFC 3413, December 2002. [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", STD 62, RFC 3414, December 2002. [RFC3415] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3415, December 2002.
Top   ToC   RFC6353 - Page 61
   [RFC3418]    Presuhn, R., "Management Information Base (MIB) for the
                Simple Network Management Protocol (SNMP)", STD 62,
                RFC 3418, 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.

   [RFC4347]    Rescorla, E. and N. Modadugu, "Datagram Transport Layer
                Security", RFC 4347, April 2006.

   [RFC4366]    Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen,
                J., and T. Wright, "Transport Layer Security (TLS)
                Extensions", RFC 4366, April 2006.

   [RFC5246]    Dierks, T. and E. Rescorla, "The Transport Layer
                Security (TLS) Protocol Version 1.2", RFC 5246,
                August 2008.

   [RFC5280]    Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
                Housley, R., and W. Polk, "Internet X.509 Public Key
                Infrastructure Certificate and Certificate Revocation
                List (CRL) Profile", RFC 5280, May 2008.

   [RFC5590]    Harrington, D. and J. Schoenwaelder, "Transport
                Subsystem for the Simple Network Management Protocol
                (SNMP)", RFC 5590, June 2009.

   [RFC5591]    Harrington, D. and W. Hardaker, "Transport Security
                Model for the Simple Network Management Protocol
                (SNMP)", RFC 5591, June 2009.

   [RFC5952]    Kawamura, S. and M. Kawashima, "A Recommendation for
                IPv6 Address Text Representation", RFC 5952,
                August 2010.

12.2. Informative References

[HEARTBEAT] Seggelmann, R., Tuexen, M., and M. Williams, "Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Heartbeat Extension", Work in Progress, July 2011. [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002.
Top   ToC   RFC6353 - Page 62
   [RFC5343]    Schoenwaelder, J., "Simple Network Management Protocol
                (SNMP) Context EngineID Discovery", RFC 5343,
                September 2008.

   [RFC5592]    Harrington, D., Salowey, J., and W. Hardaker, "Secure
                Shell Transport Model for the Simple Network Management
                Protocol (SNMP)", RFC 5592, June 2009.

   [RFC5890]    Klensin, J., "Internationalized Domain Names for
                Applications (IDNA): Definitions and Document
                Framework", RFC 5890, August 2010.

   [RFC5953]    Hardaker, W., "Transport Layer Security (TLS) Transport
                Model for the Simple Network Management Protocol
                (SNMP)", RFC 5953, August 2010.
Top   ToC   RFC6353 - Page 63

Appendix A. Target and Notification Configuration Example

The following sections describe example configuration for the SNMP- TLS-TM-MIB, the SNMP-TARGET-MIB, the NOTIFICATION-MIB, and the SNMP- VIEW-BASED-ACM-MIB.

A.1. Configuring a Notification Originator

The following row adds the "Joe Cool" user to the "administrators" group: vacmSecurityModel = 4 (TSM) vacmSecurityName = "Joe Cool" vacmGroupName = "administrators" vacmSecurityToGroupStorageType = 3 (nonVolatile) vacmSecurityToGroupStatus = 4 (createAndGo) The following row configures the snmpTlstmAddrTable to use certificate path validation and to require the remote notification receiver to present a certificate for the "server.example.org" identity. snmpTargetAddrName = "toNRAddr" snmpTlstmAddrServerFingerprint = "" snmpTlstmAddrServerIdentity = "server.example.org" snmpTlstmAddrStorageType = 3 (nonVolatile) snmpTlstmAddrRowStatus = 4 (createAndGo) The following row configures the snmpTargetAddrTable to send notifications using TLS/TCP to the snmptls-trap port at 192.0.2.1: snmpTargetAddrName = "toNRAddr" snmpTargetAddrTDomain = snmpTLSTCPDomain snmpTargetAddrTAddress = "192.0.2.1:10162" snmpTargetAddrTimeout = 1500 snmpTargetAddrRetryCount = 3 snmpTargetAddrTagList = "toNRTag" snmpTargetAddrParams = "toNR" (MUST match below) snmpTargetAddrStorageType = 3 (nonVolatile) snmpTargetAddrRowStatus = 4 (createAndGo)
Top   ToC   RFC6353 - Page 64
   The following row configures the snmpTargetParamsTable to send the
   notifications to "Joe Cool", using authPriv SNMPv3 notifications
   through the TransportSecurityModel [RFC5591]:

       snmpTargetParamsName            = "toNR"     (must match above)
       snmpTargetParamsMPModel         = 3 (SNMPv3)
       snmpTargetParamsSecurityModel   = 4 (TransportSecurityModel)
       snmpTargetParamsSecurityName    = "Joe Cool"
       snmpTargetParamsSecurityLevel   = 3          (authPriv)
       snmpTargetParamsStorageType     = 3          (nonVolatile)
       snmpTargetParamsRowStatus       = 4          (createAndGo)

A.2. Configuring TLSTM to Utilize a Simple Derivation of tmSecurityName

The following row configures the snmpTlstmCertToTSNTable to map a validated client certificate, referenced by the client's public X.509 hash fingerprint, to a tmSecurityName using the subjectAltName component of the certificate. snmpTlstmCertToTSNID = 1 (chosen by ordering preference) snmpTlstmCertToTSNFingerprint = HASH (appropriate fingerprint) snmpTlstmCertToTSNMapType = snmpTlstmCertSANAny snmpTlstmCertToTSNData = "" (not used) snmpTlstmCertToTSNStorageType = 3 (nonVolatile) snmpTlstmCertToTSNRowStatus = 4 (createAndGo) This type of configuration should only be used when the naming conventions of the (possibly multiple) Certification Authorities are well understood, so two different principals cannot inadvertently be identified by the same derived tmSecurityName.

A.3. Configuring TLSTM to Utilize Table-Driven Certificate Mapping

The following row configures the snmpTlstmCertToTSNTable to map a validated client certificate, referenced by the client's public X.509 hash fingerprint, to the directly specified tmSecurityName of "Joe Cool". snmpTlstmCertToTSNID = 2 (chosen by ordering preference) snmpTlstmCertToTSNFingerprint = HASH (appropriate fingerprint) snmpTlstmCertToTSNMapType = snmpTlstmCertSpecified snmpTlstmCertToTSNSecurityName = "Joe Cool" snmpTlstmCertToTSNStorageType = 3 (nonVolatile) snmpTlstmCertToTSNRowStatus = 4 (createAndGo)
Top   ToC   RFC6353 - Page 65

Author's Address

Wes Hardaker SPARTA, Inc. P.O. Box 382 Davis, CA 95617 USA Phone: +1 530 792 1913 EMail: ietf@hardakers.net