RFC 5953 Implementation Report
Implementation Report for RFC 5953, TLS Transport Model for SNMP. Submitted to the ITEF 13-Sep-2010.
Contents
Introduction
Sparta, Inc. has implemented RFC 5953 in the open source Simple Network Management package Net-SNMP. This report discusses the status of the implementation and some issues encountered during the implementation.
Code Availability
A proof-of-concept implementation of (D)TLS support based on early versions of draft-ietf-isms-dtls-tm was an available configuration option in release 5.5 of Net-SNMP. A more complete implementation, including the MIB modules in RFC 5953 and RFC 5592 (Transport Security Model) is included in release 5.6 of Net-SNMP.
The source for release 5.6 is available at:
The TLS and DTLS cryptographic functionality is provided by OpenSSL libraries.
Interoperability Testing
SNMP Research
Some limited initial interoperability testing has been done with SNMP Research's implementations. We are maintaining communication with SNMP Research, and plan on continuing interoperability testing as each of our implementations mature.
Public Interoperability Testing Available
The publicly-available Net-SNMP test server is running release 5.6 with (D)TLS support enabled. We have made it available both for end-users that wish to explore SNMP over (D)TLS technologies as well as implementers that are in the process of implementing SNMP over (D)TLS. We encourage others implementing RFC 5953 to test their implementations with the Net-SNMP test server. We welcome any questions about interoperability issues and will gladly provide assistance in debugging and resolve any such issues.
The client and server certificates needed for testing with the Net-SNMP test server, along with a tutorial on configuring and using (D)TLS with Net-SNMP, can be found at:
Questions or comments about any interoperability experiences or issues with the Net-SNMP test server should be directed to the Net-SNMP coders mailing list, <net-snmp-coders@lists.sourceforge.net>.
Net-SNMP Background
Net-SNMP implements the transports over which SNMP messages can be sent using a pluggable architecture. This architecture defines hooks that allow implemented transports to handle opening, sending and receiving packets through "something or other". The "something or other" can be almost anything and Net-SNMP has support for: IPv4/UDP, IPv6/TCP, UnixDomain Sockets, IPX, and internal pipe()s and even stdin/stdout, to name just a few of the diverse examples.
To implement (D)TLS support within Net-SNMP, several new transports were written to provide dtlsudp and tlstcp support.
Challenges
DTLS: one socket, multiple sessions
Since all DTLS traffic is sent to a single well-known port, implementations must be able to demultiplex data for multiple sessions arriving on the same port. Unfortunately, OpenSSL's internal processing algorithm appears to be greedy; this means that calling the OpenSSL API while processing a packet for a particular session can result in packets intended for other sessions being returned to the application.
To handle this, the Net-SNMP does all UDP packet processing itself (as is described in RFC 5953, section 5.1.2), handing off individual packets to OpenSSL for processing. While this works, it is inefficient. Hopefully we will find a solution for this issue in a future release as support for DTLS in the OpenSSL code base continues to be refined.
Configuring transport security
Peering into the black box
Prior to adding support for the Transport Security Model all security was in the SNMP protocol. The transport model in the Net-SNMP code base was essentially a black box with a slot to feed packets in and and a bin where packets arrived. The only real configuration needed for the transport was the address specifying where the packets were coming and going to and/or from. For example, with IP based protocols this was a simple address/port number pair.
With transport security models, the secure transports required additional configuration besides just the end-point description. The Net-SNMP transport system was extended to accommodate a new configuration API that could be used in between transport object instantiation and the point where the actual transport connection (i.e. socket opening) was performed. This additional middle configuration step allows for SNMP applications to pass opaque configuration data to the transport.
This new configuration was done in such a way that older transport's code and existing code that used the older transports did not need to be modified. However, applications that want to make use of the newer secure transports may need to understand the newer transport configuration API mechanisms.
Certificate complexity
Certificates have long been used for securing communication and providing identities. Unfortunately, no "killer application" has been written yet that makes certificate management easy for the masses.
OpenSSL is a popular choice for creating certificates since it is available for free. The web is full of examples for generating certificates for a wide range of services. A common complaint, however, is that the command line interface OpenSSL is complex and cryptic.
Net-SNMP has tried to mitigate this by creating a wrapper script for managing certificates. This script ("net-snmp-certs") can create a Certificate Authority, sign new certificates with that Certificate Authority and create self signed certificates. Certificates and keys are automatically stored in the directory structure used by the Net-SNMP tools and applications.
Applications and tools need to configure their own/local identity and the peer/remote identity. The certificates can be configured via the application configuration file or on the command line. A new feature was also added to allow the tools and applications to read a host specific configuration file.
The Net-SNMP tools and applications handle referring to certificates by file name, fingerprint or a tag. Applications will search the certificate directory structure for a certificate/key based on the default tag for the application so that explicit configuration of the local identity is not required in some cases.
Conclusions
Testing of the Net-SNMP (D)TLS implementation is ongoing. Our internal test suite exercises the code for various certificate configurations, including variations of the Subject Alt Names. Tests exist for the certificate to security name mapping MIB tables, and additional tests are planned for the target and parameter tables. While these tests are currently designed to run against Net-SNMP, it is a goal to have the ability to run the test suite against other vendor implementations as well, as an aid to interoperability testing.
If there is an area of concern for interoperability, it would be with the vagueness in the specification with regards to mapping between (D)TLS authentication and encryption algorithms and tmSecurityLevel since there is no standardized mechanisms for configuring the mapping. If an implementation allows (D)TLS to negotiate weaker algorithms but maps them to lower security levels and a client considers those same algorithms to be sufficient for authPriv then authorization errors will result.
In summary, we have implemented the (D)TLS transport and successfully conducted limited interoperability testing with SNMP Research. Interoperability testing will continue, but we believe that the (D)TLS specification is sufficient to allow for interoperability.
