[Isms] RFC 5953 Implementation Report

[Robert Story <[e-mail]>]

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


2 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:

    * http://www.net-snmp.org/download.html 

  The TLS and DTLS cryptographic functionality is provided by OpenSSL
  libraries.


3 Interoperability Testing

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

3.2 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:

    * http://www.net-snmp.org/wiki/index.php/TUT:Using_TLS 

  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,
  <[e-mail]>.


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


5 Challenges

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

5.2 Configuring transport security

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

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


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

-- 
Robert Story
Senior Software Engineer
SPARTA (dba Cobham Analytic Soloutions)