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
   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 are
   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
   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 a 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.

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.  Modification
      to objects in this table need to be adequately authenticated since
      modification to 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.
      Modification to objects in this table need to be adequately
      authenticated since modification to 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 snmpTlstmCertToTSNTable is used to specify the mapping of
      incoming X.509 certificates to tmSecurityNames, which eventually
      get mapped to a SNMPv3 securityName.  Modification to objects in
      this table need to be adequately authenticated since modification
      to 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
   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          [RFC5953]
     snmpdtls        10161/udp    SNMP-DTLS         [RFC5953]
     snmptls-trap    10162/tcp    SNMP-Trap-TLS     [RFC5953]
     snmpdtls-trap   10162/udp    SNMP-Trap-DTLS    [RFC5953]

   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.

   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

   [RFC1033]    Lottor, M., "Domain administrators operations guide",
                RFC 1033, November 1987.

   [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.

   [RFC3418]    Presuhn, R., "Management Information Base (MIB) for the
                Simple Network Management Protocol (SNMP)", STD 62,
                RFC 3418, December 2002.

   [RFC3490]    Faltstrom, P., Hoffman, P., and A. Costello,
                "Internationalizing Domain Names in Applications
                (IDNA)", RFC 3490, March 2003.

   [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

   [RFC3410]    Case, J., Mundy, R., Partain, D., and B. Stewart,
                "Introduction and Applicability Statements for Internet-
                Standard Management Framework", RFC 3410, December 2002.

   [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.

   [HEARTBEAT]  Seggelmann, R., Tuexen, M., and M. Williams, "Transport
                Layer Security and Datagram Transport Layer Security
                Heartbeat Extension", Work in Progress, February 2010.

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)
       snmpTargetAddrColumnStatus      = 4          (createAndGo)

   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          (createAndGo0

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)

Author's Address

   Wes Hardaker
   SPARTA, Inc.
   P.O. Box 382
   Davis, CA  95617
   USA

   Phone: +1 530 792 1913
   EMail: ietf@hardakers.net