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]