[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

ISMS                                               J. Schoenwaelder, Ed.
Internet-Draft                                  Jacobs University Bremen
Intended status: Informational                                  R. Story
Expires: October 6, 2011                                   SPARTA/Cobham
                                                               M. Vrecko
                                                                 MG-SOFT
                                                           April 4, 2011


 Interoperability Report for RFC 5343, RFC 5590, RFC 5591, and RFC 5953
             draft-schoenw-isms-interoperability-report-01

Abstract

   This document provides the interoperability report for RFC 5343, RFC
   5590, RFC 5591, and RFC 5953.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on October 6, 2011.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of



Schoenwaelder, et al.    Expires October 6, 2011                [Page 1]


Internet-Draft        ISMS Interoperability Report            April 2011


   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  RFC 5343 Report (Net-SNMP - SNMP Research) . . . . . . . . . .  3
   3.  RFC 5343 Report (MG-SOFT - Net-SNMP / SNMP Research) . . . . .  4
   4.  RFC 5590 Report (Net-SNMP - SNMP Research) . . . . . . . . . .  5
   5.  RFC 5590 Report (MG-SOFT - Net-SNMP / SNMP Research) . . . . .  9
   6.  RFC 5591 Report (Net-SNMP - SNMP Research) . . . . . . . . . . 11
   7.  RFC 5591 Report (MG-SOFT - Net-SNMP / SNMP Research) . . . . . 13
   8.  RFC 5953 Report (Net-SNMP - SNMP Research) . . . . . . . . . . 15
   9.  RFC 5953 Report (MG-SOFT - Net-SNMP / SNMP Research) . . . . . 16
   10. Security Considerations  . . . . . . . . . . . . . . . . . . . 19
   11. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 19
   12. Informative References . . . . . . . . . . . . . . . . . . . . 19
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20




























Schoenwaelder, et al.    Expires October 6, 2011                [Page 2]


Internet-Draft        ISMS Interoperability Report            April 2011


1.  Introduction

   This document provides the interoperability report for SNMP Context
   EngineID Discovery [RFC5343], the Transport Subsystem for SNMP
   [RFC5590], the Transport Security Model for SNMP [RFC5591], and the
   Transport Layer Security (TLS) Transport Model for SNMP [RFC5953].


2.  RFC 5343 Report (Net-SNMP - SNMP Research)


  Summary

        Two independent implementations of SNMP Context EngineID
        Discovery have been developed, tested, and found to be
        interoperable. The developers of both implementation agree that
        RFC 5343 is sufficiently clear to allow for interoperable
        implementations.

        The two implementations which have been tested for
        interoperability are Net-SNMP release 5.6 and SNMP Research
        DR-Web EMANATE/Lite Agent Version 17.1.1.3.

  Methodology

        Each implementation provided remote access to running command
        responders and tested the other implementation using their own
        command generators. Packet captures were used to verify data
        sent/received on the wire.

  Exceptions

        The list of untestable requirements are listed below in this
        document. Initially one implementation was erroneously
        performing discovery for all PDUs, including traps. This was
        quickly fixed when discovered.

  Testable Requirements

        There were no testable requirements, as all requirements were
        internal implementation details.

        Packet sniffing was use to determine that implementations were
        sending the correct localEngineID during discovery.

  Untestable Requirements

     3.1. Local EngineID



Schoenwaelder, et al.    Expires October 6, 2011                [Page 3]


Internet-Draft        ISMS Interoperability Report            April 2011


          An SNMP command responder implementing this specification MUST
          register their pduTypes using the localEngineID snmpEngineID
          value (defined below) by invoking the
          registerContextEngineID() Abstract Service Interface (ASI)
          defined in RFC 3412 [RFC3412].

          Note that the localEngineID value is intended to be used as a
          special value for the contextEngineID field in the ScopedPDU.
          It MUST NOT be used as a value to identify an SNMP engine;
          that is, this value MUST NOT be used in the snmpEngineID.0
          scalar [RFC3418] or in the msgAuthoritativeEngineID field in
          the securityParameters of the User-based Security Model (USM)
          [RFC3414].

     3.2. EngineID Discovery

          Discovery of the snmpEngineID is done by sending a Read Class
          protocol operation (see Section 2.8 of [RFC3411]) to retrieve
          the snmpEngineID scalar using the localEngineID defined above
          as a contextEngineID value.  Implementations SHOULD only
          perform this discovery step when it is needed.


3.  RFC 5343 Report (MG-SOFT - Net-SNMP / SNMP Research)


  Summary

        MG-SOFT's SNMP management utility built on top of MG-SOFT's
        WinSNMP API version 8.0.500 (www.mg-soft.com), acting as a
        command generator application, has been successfully tested over
        the Internet against two other command responder applications:

          1. Net-SNMP release 5.6 (www.net-snmp.org)
          2. SMMP Research agent (www.snmp.com)

        With both of these two independent implementations we have
        successfully utilized the Context EngineID discovery mechanism
        as defined in RFC 5343 and successfully passed the
        interoperability tests. Both TLS and DTLS transport domains have
        been tested.  The SNMP Get and Get-Next operations have been
        tested.

        MG-SOFT provided for interoperability testing purposes a
        publicly accessible SNMP agent that acts as command responder
        application. So far, MG-SOFT's SNMP agent supporting SNMP over
        TLS/DTLS has been successfully tested both by Net-SNMP release
        5.6 tools and SNMP Research's tools.  Both TLS and DTLS domains



Schoenwaelder, et al.    Expires October 6, 2011                [Page 4]


Internet-Draft        ISMS Interoperability Report            April 2011


        have been tested successfully from both independent
        implementations.  The Context EngineID discovery mechanism has
        been successfully utilized when (D)TLS sessions have been
        successfully established.

        In all tests the authPriv session has been successfully
        negotiated.  MG-SOFT's implementation does not implement the
        optional mapping between TLS algorithms and SNMP security
        levels.

        In all cases, testing has been performed with 'interoperability
        test' command-generator.crt and command-receiver.crt X.509
        certificates as they were generated and prepared by the Net-SNMP
        team.

        MG-SOFT's WinSNMP API is utilizing the most recent openSSL
        library (as of these tests, version 1.0.0d) for supporting the
        underlying TLS and DTLS functionality.

        MG-SOFT's developers believe that RFC 5343 is clear and exact
        enough to allow a successful implementation.

  Tested Requirements

     - 3.1 Local EngineID

        Usage of Local Engine ID has been successfully tested. Command
        generator application successfully read snmpEngineID.0 by using
        the Local Engine ID.

     - 3.2 EngineID Discovery

        The EngineID Discovery procedure has successfully been tested.


4.  RFC 5590 Report (Net-SNMP - SNMP Research)


 Summary

       Two independent implementations of the Transport Subsystem have
       been developed, tested, and found to be interoperable. The
       developers of both implementation agree that RFC 5590 is
       sufficiently clear to allow for interoperable implementations.

       The two implementations which have been tested for
       interoperability are Net-SNMP release 5.6 and SNMP Research
       EMANATE/Lite Agent Version 17.1.1.3.



Schoenwaelder, et al.    Expires October 6, 2011                [Page 5]


Internet-Draft        ISMS Interoperability Report            April 2011


 Methodology

       As the Transport Subsystem is a framework on top of which new
       transports can be defined, interoperability cannot be tested
       directly. For this report, the Transport Subsystem
       interoperability was tested during the interoperability testing
       for the TLS security model defined in RFC 5953, for which a
       separate interoperability report was submitted.

 Exceptions

       Most of the requirements in 5590 are requirements for future
       transport protocols, and as such are not testable. The list of
       untestable requirements is provided below as well.

 Tested Requirements

    - 3.3.4. Message Security versus Session Security

         A Transport Model MAY upgrade the security level requested by
         a transport-aware Security Model, i.e., noAuthNoPriv and
         authNoPriv might be sent over an authenticated and encrypted
         session.

      To test this requirement a client established an authPriv session
      and sent an authNoPriv message.

    - 3.1.1. Security Protocol Requirements

        Since multiple Transport Models can exist simultaneously within
        the Transport Subsystem, Transport Models MUST be able to
        coexist with each other.

      Net-SNMP has implemented both the DTLS and SSH transports, with no
      conflicts.

 Untestable Requirements

    - 3.1 Message Security Requirements

        Transport security protocols SHOULD provide protection against
        the following message-oriented threats:

        1.  modification of information
        2.  masquerade
        3.  message stream modification
        4.  disclosure




Schoenwaelder, et al.    Expires October 6, 2011                [Page 6]


Internet-Draft        ISMS Interoperability Report            April 2011


    - 3.1.1. Security Protocol Requirements

        A Transport Model SHOULD NOT require modifications to the
        underlying protocol. Modifying the protocol might change its
        security characteristics in ways that could impact other
        existing usages.  If a change is necessary, the change SHOULD
        be an extension that has no impact on the existing usages.

        Since multiple Transport Models can exist simultaneously within
        the Transport Subsystem, Transport Models MUST be able to
        coexist with each other.

    - 3.2.2.1. securityName and securityLevel Mapping

        Documents defining a new transport domain MUST define a prefix
        that MAY be prepended to all securityNames passed by the
        Security Model.  The prefix MUST include one to four US-ASCII
        alpha-numeric characters, not including a ":" (US-ASCII 0x3a)
        character.

    - 3.3.3. Session Maintenance Requirements

        If a Transport Model defines MIB module objects to maintain
        session state information, then the Transport Model MUST define
        what happens to the objects when a related session is torn
        down, since this will impact the interoperability of the MIB
        module.

    - 3.3.4. Message Security versus Session Security

        Cryptographic keys associated with the transport session SHOULD
        be used to provide authentication, integrity checking, and
        encryption services, as needed, for data that is communicated
        during the session.  The cryptographic protocols used to
        establish keys for a Transport Model session SHOULD ensure that
        fresh new session keys are generated for each session.

    - 3.3.4. Message Security versus Session Security

        A Transport Model MUST NOT downgrade the security level
        requested by a transport-aware Security Model, and SHOULD
        discard any message where this would occur.

    - 5.2. tmStateReference

        For architectural modularity between Transport Models and
        transport-aware Security Models, a fully-defined tmState MUST
        conceptually include at least the following fields:



Schoenwaelder, et al.    Expires October 6, 2011                [Page 7]


Internet-Draft        ISMS Interoperability Report            April 2011


           tmTransportDomain
           tmTransportAddress
           tmSecurityName
           tmRequestedSecurityLevel
           tmTransportSecurityLevel
           tmSameSecurity
           tmSessionID

    - 5.2.4. Session Information

        For security reasons, if a secure transport session is closed
        between the time a request message is received and the
        corresponding response message is sent, then the response
        message SHOULD be discarded, even if a new session has been
        established.

        o  tmSameSecurity: this flag is used by a transport-aware
           Security Model to indicate whether the Transport Model MUST
           enforce this restriction.

        o  tmSessionID: in order to verify whether the session has
           changed, the Transport Model must be able to compare the
           session used to receive the original request with the one to
           be used to send the response

        When processing an outgoing message, if tmSameSecurity is true,
        then the tmSessionID MUST match the current transport session;
        otherwise, the message MUST be discarded and the Dispatcher
        notified that sending the message failed.

    - 7. Security Considerations

        Since the cache will contain security-related parameters,
        implementers SHOULD store this information (in memory or in
        persistent storage) in a manner to protect it from unauthorized
        disclosure and/or modification.

    - 7.1. Coexistence, Security Parameters, and Access Control

        o  For outgoing messages, if a Secure Transport Model is
           selected in combination with a Security Model that does not
           populate a tmStateReference, the Secure Transport Model
           SHOULD detect the lack of a valid tmStateReference and fail.








Schoenwaelder, et al.    Expires October 6, 2011                [Page 8]


Internet-Draft        ISMS Interoperability Report            April 2011


5.  RFC 5590 Report (MG-SOFT - Net-SNMP / SNMP Research)


  Summary

        MG-SOFT's SNMP management utility built on top of MG-SOFT's
        WinSNMP API version 8.0.500 (www.mg-soft.com), acting as a
        command generator application, has been successfully tested over
        the Internet against two other command responder applications:

          1. Net-SNMP release 5.6 (www.net-snmp.org)
          2. SNMP Research agent (www.snmp.com)

        With both of these two independent implementations we have
        successfully passed the interoperability tests.

        MG-SOFT provided for interoperability testing purposes a
        publicly accessible SNMP agent that acts as command responder
        application. So far, the MG-SOFT's SNMP agent supporting SNMP
        over TLS/DTLS has been successfully tested both by Net-SNMP
        release 5.6 tools and SNMP Research's tools.  Both TLS and DTLS
        domains have been tested successfully from both independent
        implementations.

        In all cases, testing has been performed with 'interoperability
        test' command-generator.crt and command-receiver.crt X.509
        certificates as they were generated and prepared by the Net-SNMP
        team.

        MG-SOFT's WinSNMP API is utilizing the most recent openSSL
        library (as of these tests, version 1.0.0d) for supporting the
        underlying TLS and DTLS functionality.

        RFC 5590 defines a transport subsystem that extends Simple
        Network Management Protocol (SNMP) architecture defined in RFC
        3411. As RFC 5590 defines a framework for the coexistence of
        multiple different transport models and MG-SOFT's WinSNMP API
        version 8.0.500 implements only the Transport Layer Security
        (TLS) Transport Model defined in RFC 5953, the requirements
        defined in RFC 5590 could not be tested directly. The
        interoperability of the framework defined in RFC 5590 has been
        confirmed indirectly while testing interoperability of the RFC
        5953.

        MG-SOFT's developers believe that RFC 5590 is clear and exact
        enough to allow a successful implementation.

  Tested Requirements



Schoenwaelder, et al.    Expires October 6, 2011                [Page 9]


Internet-Draft        ISMS Interoperability Report            April 2011


     - 3.3.4. Message Security versus Session Security

         A Transport Model MAY upgrade the security level requested by a
         transport-aware Security Model, i.e., noAuthNoPriv and
         authNoPriv might be sent over an authenticated and encrypted
         session.

       MG-SOFT command generator application sends noAuthNoPriv message
       for ContextEngineId discovery over previously established
       authPriv session.

  Untested Requirements

     - 3.1 Message security requirements

       Protection against message-oriented threads: modification of
       information, masquerade, message stream modification and
       disclosure have not been tested.

     - 3.1.1 Security protocol requirements

       As MG-SOFT has implemented only the TLS transport model, the
       coexistence of multiple transport models could not be tested.

     - 3.2.1 Architectural Modularity Requirements

       These requirements could not be tested directly. However, MG-SOFT
       followed these requirements when extending MG-SOFT WinSNMP API.

     - 3.2.2 Access Control Requirements

       Access control requirements have not been tested.

     - 3.3.1 No SNMP Session

       Maintenance of multiple transport sessions has not been tested.

     - 3.3.2 Session Establishment Requirements

       These requirements have not been tested directly.

     - 3.3.3. Session Maintenance Requirements

       Session maintenance requirements have not been tested.

     - 3.3.4. Message Security versus Session Security

       These requirements have not been completely tested.



Schoenwaelder, et al.    Expires October 6, 2011               [Page 10]


Internet-Draft        ISMS Interoperability Report            April 2011


     - 5.2 tmStateReference

       These requirements have not been tested directly.

     - 5.2.4 Session Information

       These requirements have not been tested.

     - 7 Security Considerations

       These requirements have not been tested.

     - 7 Coexistence, Security Parameters, and Access Control

       These requirements have not been tested.


6.  RFC 5591 Report (Net-SNMP - SNMP Research)


 Summary

       Two independent implementations of the Transport Security Model
       (TSM) have been developed, tested, and found to be
       interoperable. The developers of both implementation agree that
       RFC 5591 is sufficiently clear to allow for interoperable
       implementations.

       The two implementations which have been tested for
       interoperability are Net-SNMP release 5.6 and SNMP Research
       DR-Web EMANATE/Lite Agent Version 17.1.1.3.

 Methodology

       As the TSM is a framework security model to be used with other
       secure transports, interoperability cannot be tested
       directly. For this report, TSM interoperability was tested
       during the interoperability testing for the TLS security model
       defined in RFC 5953.

 Exceptions

       The list of untestable requirements are listed below in this
       document.

       Initially one implementation was erroneously setting the security
       level for response packets to match the security level asserted
       by the transport layer. This caused the other implementation to



Schoenwaelder, et al.    Expires October 6, 2011               [Page 11]


Internet-Draft        ISMS Interoperability Report            April 2011


       drop the response when it was received.  The ASI in section
       4.1.2, Sending a Response to the Network, has a comment
       associated with the securityLevel passed to returnResponsePdu
       which indicates that the value should match the value from the
       incoming packet. This is consistent with how the SNMPv3 standard
       specifies handling of the securityLevel, thus the implementation
       was in error.

 Testable Requirements

    - 1.1 Mandatory MIB objects

        snmpTsmCompliance MODULE-COMPLIANCE
             MANDATORY-GROUPS { snmpTsmGroup }
        snmpTsmGroup OBJECT-GROUP
             snmpTsmInvalidCaches,
             snmpTsmInadequateSecurityLevels,
             snmpTsmUnknownPrefixes,
             snmpTsmInvalidPrefixes,
             snmpTsmConfigurationUsePrefix

      Client side tests
      o verify each object can be queried
      o verify that snmpTsmConfigurationUsePrefix is writable

      Exceptions
      o Both existing implementations of RFC 5953 chose to always
        negotiate authPriv sessions and did not implement the optional
        mapping of TLS algorithms to SNMP security levels. This made it
        impossible to send an authPriv message over a transport with an
        inadequate security level. Net-SNMP plans on implementing
        mapping in a future release, and SNMP Research has indicated
        that it will implement it given sufficient customer demand.

 Untestable Requirements

    - 3.1.2. tmStateReference

        For the Transport Security Model, the security parameters used
        for a response MUST be the same as those used for the
        corresponding request.

    - 3.1.3. Prefixes and securityNames

        If snmpTsmConfigurationUsePrefix is set to true, then all
        securityNames provided by, or provided to, the Transport
        Security Model MUST include a valid transport domain prefix.




Schoenwaelder, et al.    Expires October 6, 2011               [Page 12]


Internet-Draft        ISMS Interoperability Report            April 2011


        If snmpTsmConfigurationUsePrefix is set to false, then all
        securityNames provided by, or provided to, the Transport
        Security Model MUST NOT include a transport domain prefix.

    - 8. Security Considerations

        This Security Model SHOULD always be used with Transport Models
        that provide adequate security, but "adequate security" is a
        configuration and/or run-time decision of the operator or
        management application.


7.  RFC 5591 Report (MG-SOFT - Net-SNMP / SNMP Research)


  Summary

        MG-SOFT's SNMP management utility built on top of MG-SOFT's
        WinSNMP API version 8.0.500 (www.mg-soft.com), acting as a
        command generator application, has been successfully tested over
        the Internet against two other command responder applications:

          1. Net-SNMP release 5.6 (www.net-snmp.org)
          2. SNMP Research agent (www.snmp.com)

        With both of these two independent implementations we have
        successfully passed the interoperability tests.  Both the TLS
        and the DTLS transport domain have been tested. The SNMP Get and
        Get-Next operations have been tested.

        MG-SOFT provided for interoperablility testing purposes a
        publicly accessible SNMP agent that acts as command responder
        application. So far, the MG-SOFT's SNMP agent supporting SNMP
        over TLS/DTLS has been sucesfully tested both by Net-SNMP
        release 5.6 tools and SNMP Research's tools.  Both TLS and DTLS
        domains have been tested successfully from both independent
        implementations.

        In all cases, testing has been performed with 'interoperability
        test' command-generator.crt and command-receiver.crt X.509
        certificates as they were generated and prepared by the Net-SNMP
        team.

        MG-SOFT's implementation does not implement the optional mapping
        between TLS algorithms and SNMP security levels.

        MG-SOFT's WinSNMP API is utilizing the most recent openSSL
        library (as of these tests, version 1.0.0d) for supporting the



Schoenwaelder, et al.    Expires October 6, 2011               [Page 13]


Internet-Draft        ISMS Interoperability Report            April 2011


        underlying TLS and DTLS functionality.

        MG-SOFT's developers believe that RFC 5591 is clear and exact
        enough to allow a successful implementation.

  Tested Requirements

     - 2.3.1 Coexistence with Message Processing Models

        Coexistence with SNMPv1 and SNMPv2c message processing models
        has been successfully tested in the command generator role. The
        MG-SOFT SNMP management utility application has been
        successfully performing SNMP operation against different SNMP
        agents by using SNMPv1, SNMPv2c and SNMPv3-USM over unencrypted
        UDP (SNMP agents in MG-SOFT lab) and SNMPv3-TSM over TSLTM
        (Net-SNMP's and SNMP Research's publicly accessible test SNMP
        agent).

     - 2.3.2 Coexistence with Other Security Models

        Coexistence with the SNMPv3-USM security model has been
        successfully tested in the command generator role. The MG-SOFT
        SNMP management utility application has been successfully
        performing SNMP operation against different SNMP agents by using
        SNMPv3-USM over unencrypted UDP (SNMP agents in MG-SOFT lab) and
        SNMPv3-TSM over TSLTM (Net-SNMP's and SNMP Research's publicly
        accessible test SNMP agent).

     - 8. Security Considerations

        Usage of TSM without TLSTM is disabled in MG-SOFT's WinSNMP API,
        so it can not be used with a transport model without adequate
        security.

  Untested Requirements

     - 2.3.3  Coexistence with Transport Models

        Coexistence with transport models has not been tested.

     - 3.1.3 Prefixes and securityNames

        Usage of SNMP transport domain prefixes and the configuration of
        its usage in the SNMP-TSM-MIB have not been tested.

     - 6. MIB Module Overview

        The implementation of SNMP-TSM-MIB has not been tested.



Schoenwaelder, et al.    Expires October 6, 2011               [Page 14]


Internet-Draft        ISMS Interoperability Report            April 2011


8.  RFC 5953 Report (Net-SNMP - SNMP Research)


  Summary

        Two independent implementations of the Transport Layer Security
        (TLS) Transport Model been developed, tested, and found to be
        interoperable.  The developers of both implementation agree that
        RFC 5953 is sufficiently clear to allow for interoperable
        implementations.

        The two implementations which have been tested for
        interoperability are Net-SNMP version 5.6 and SNMP Research
        EMANATE/Lite Agent Version 17.1.1.3. Although the SNMP code for
        each is independent, both use the (D)TLS libraries from
        OpenSSL. However, each used a different approach for using the
        (D)TLS API.

        The Net-SNMP project has deployed a publicly available test
        server to allow for continued interoperability testing with new
        or existing implementations.

  Methodology

        Each implementation provided remote access to running command
        responders and trap receivers, and tested the other
        implementation using their own command generators. In addition
        to basic object comparisons, stimulus/response testing was
        conducted.

  Exceptions

        Both existing implementations of RFC 5953 chose to always
        negotiate authPriv sessions and did not implement the optional
        mapping of TLS algorithms to SNMP security levels. This made it
        impossible to test sending an authPriv message over a transport
        with an inadequate security level. (Net-SNMP plans to add
        security level mapping in a future release, and SNMP Research
        indicates that they will implement the feature if there is
        sufficient customer demand.)

        Implementations that do choose to implement mapping of TLS
        algorithms to SNMP security levels should provide clear
        documentation to their users about the implications of mapping
        algorithms to security levels other than authPriv. Consider the
        following scenario: Client A maps MD5/RC4 to authPriv and
        negotiates a TLS session with Agent B, who maps md5/rc4 to
        authNoPriv. Packets from Client A that are marked authPriv will



Schoenwaelder, et al.    Expires October 6, 2011               [Page 15]


Internet-Draft        ISMS Interoperability Report            April 2011


        be silently dropped, even though (D)TLS negotiations succeeded.

  Details

        The short version, for the impatient, is that "it works." Basic
        interoperability between the Net-SNMP and SNMP Research
        implementations has been demonstrated for all the core protocol
        operations (e.g. Get, Get-Next, Set, Trap, Inform).

        Neither implementation claims to be a complete, bug-free
        production ready implementation, and occasional differences have
        been found noted between the implementations. To date, however,
        all the differences have fallen into one of these categories:

          - object not implemented yet
          - corner cases not handled yet
          - code needs to be refactored to meet requirement

        In other words, so far all issues are with a particular
        implementation, not with the specification.

        Testing has been performed for various certificate
        configurations, include self-signed certificate and certificates
        signed by a trusted certificate authority.

        Security name mappings have been made by directly specifying the
        security name for a certificate, and by mapping the common name
        or subject alt names (including email addresses, dns addresses
        and IP addresses).

        It may be helpful to add text clarifying that the security level
        associated with a (D)TLS session is only used for ensuring that
        a session has sufficient security for a packet. The security
        level in outgoing/incoming packets continue to function per the
        SNMPv3 standard. In other words, the security level in outgoing
        packets is not modified to match the security level of the
        session, and response packets copy the security level from the
        original packet.


9.  RFC 5953 Report (MG-SOFT - Net-SNMP / SNMP Research)


  Summary

        MG-SOFT's SNMP management utility built on top of MG-SOFT's
        WinSNMP API version 8.0.500 (www.mg-soft.com), acting as a
        command generator application, has been successfully tested over



Schoenwaelder, et al.    Expires October 6, 2011               [Page 16]


Internet-Draft        ISMS Interoperability Report            April 2011


        the Internet against two other command responder applications:

          1. Net-SNMP release 5.6 (www.net-snmp.org)
          2. SNMP Research agent (www.snmp.com)

        With both of these two independent implementations we have
        successfully communicated using TLSTM and so passed the basic
        interoperability tests. Both TLS and DTLS transport domain have
        been been tested. The SNMP Get and Get-Next operations have been
        tested. In all tests an authPriv session has been negotiated.
        MG-SOFT's implementation does not implement the optional
        mapping between TLS algorithms and SNMP security levels.

        MG-SOFT provided for interoperability testing purposes a
        publicly accessible SNMP agent that acts as command responder
        application. So far, MG-SOFT's SNMP agent supporting SNMP over
        TLS/DTLS has been successfully tested both by Net-SNMP release
        5.6 tools and SNMP Research's tools.  Both TLS and DTLS domains
        have been tested successfully from both independent
        implementations.

        In all cases, testing has been performed with 'interoperability
        test' command-generator.crt and command-receiver.crt X.509
        certificates as they were generated and prepared by the Net-SNMP
        team.

        MG-SOFT's WinSNMP API is utilizing the most recent openSSL
        library (as of these tests, version 1.0.0d) for supporting the
        underlying TLS and DTLS functionality.

        MG-SOFT's developers believe that RFC 5953 is clear and exact
        enough to allow a successful implementation.

  Tested Requirements

     - 3.1.2 Message Protection

        In all tests the authPriv session has been negotiated. MG-SOFT's
        implementation does not implement the optional mapping of TLS
        security algorithms to SNMP security levels.

     - 3.1.3 (D)TLS Connections

        MG-SOFT implementation opens a (D)TLS connection when an SNMP
        message needs to be sent. The connection remains opened until
        the user or application decides to close it. Sending and
        receiving multiple SNMP messages over a single (D)TLS connection
        has been successfully tested.



Schoenwaelder, et al.    Expires October 6, 2011               [Page 17]


Internet-Draft        ISMS Interoperability Report            April 2011


     - 4.1 X.509 Certificates

        Both entities have used X.509 certificates for authentication.

     - 4.1.1 Provisioning for the Certificate

        Usage of a root certificate for certificate verification has
        also been tested.

     - 4.2 (D)TLS Usage

        Both, client and server side have been authenticated by X.509
        certificates. For DTLS (over UDP), each SNMP message is placed
        in a single UDP datagram. Packet fragmentation/concatenation has
        been enabled.

     - 8.3 contextEngineID Discovery

        ContextEngineID Discovery as defined in RFC 5343 has been
        successfully tested, for which a separate interoperability
        report was submitted.

     - 9.3 Use with SNMPv1/SNMPv2c Messages

        Usage of SNMPv1, SNMPv2c and SNMPv3 with USM security model over
        (D)TSL is disabled in MG-SOFT's WinSNMP API implementation.

  Untested Requirements

     - 3.1.2 Message Protection

        MG-SOFT's WinSNMP API implementation does not implement the
        optional mapping between TLS security algorithms and SNMP
        security levels.

     - 3.1.3 (D)TLS Connections

        Coexistence and operation of multiple (D)TLS connections has not
        been tested.

     - 3.3 Notification and Proxy

        These requirements have not been tested since only a command
        generator was available at the time of testing.

     - 4.1.1 Provisioning for the Certificate

        Mapping of incoming message to tmSecurityName has not been



Schoenwaelder, et al.    Expires October 6, 2011               [Page 18]


Internet-Draft        ISMS Interoperability Report            April 2011


        tested.  Mapping of a certificate's fingerprint value to a
        tmSecurityName has not been tested.

     - 4.4.1.1 tmSecurityName

        Mapping from certificate to tmSecurityName has not been tested.

     - 8.1 Sessions

        Lifetime limitation of established sessions has not been tested.

     - 8.2 Notification Receiver Credential Selection

        Notifications have not been tested.

     - 9.1 Certificates, Authentication and Authorization

        Implementation of the SNMP-TLS-TM-MIB has not been tested.


10.  Security Considerations

   The interoperability testing did not identify any security issues
   that are not covered in the security considerations of the relevant
   specifications.


11.  IANA Considerations

   This document has no IANA actions.


12.  Informative References

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

   [RFC3412]  Case, J., Harrington, D., Presuhn, R., and B. Wijnen,
              "Message Processing and Dispatching for the Simple Network
              Management Protocol (SNMP)", STD 62, RFC 3412,
              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.




Schoenwaelder, et al.    Expires October 6, 2011               [Page 19]


Internet-Draft        ISMS Interoperability Report            April 2011


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

   [RFC5343]  Schoenwaelder, J., "Simple Network Management Protocol
              (SNMP) Context EngineID Discovery", RFC 5343,
              September 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.

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


Authors' Addresses

   Juergen Schoenwaelder (editor)
   Jacobs University Bremen

   Email: j.schoenwaelder@jacobs-university.de


   Robert Story
   SPARTA/Cobham

   Email: robert.story@cobham.com


   Matjaz Vrecko
   MG-SOFT

   Email: matjaz@mg-soft.si












Schoenwaelder, et al.    Expires October 6, 2011               [Page 20]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/