idnits 2.17.1 draft-schoenw-isms-interoperability-report-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 6 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 118: '...r implementing this specification MUST...' RFC 2119 keyword, line 126: '... It MUST NOT be used as a val...' RFC 2119 keyword, line 127: '...t is, this value MUST NOT be used in t...' RFC 2119 keyword, line 137: '...ID value. Implementations SHOULD only...' RFC 2119 keyword, line 230: '... Transport Model MAY upgrade the secur...' (25 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 4, 2011) is 4770 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 5953 (Obsoleted by RFC 6353) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ISMS J. Schoenwaelder, Ed. 3 Internet-Draft Jacobs University Bremen 4 Intended status: Informational R. Story 5 Expires: October 6, 2011 SPARTA/Cobham 6 M. Vrecko 7 MG-SOFT 8 April 4, 2011 10 Interoperability Report for RFC 5343, RFC 5590, RFC 5591, and RFC 5953 11 draft-schoenw-isms-interoperability-report-01 13 Abstract 15 This document provides the interoperability report for RFC 5343, RFC 16 5590, RFC 5591, and RFC 5953. 18 Status of this Memo 20 This Internet-Draft is submitted to IETF in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on October 6, 2011. 41 Copyright Notice 43 Copyright (c) 2011 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. RFC 5343 Report (Net-SNMP - SNMP Research) . . . . . . . . . . 3 60 3. RFC 5343 Report (MG-SOFT - Net-SNMP / SNMP Research) . . . . . 4 61 4. RFC 5590 Report (Net-SNMP - SNMP Research) . . . . . . . . . . 5 62 5. RFC 5590 Report (MG-SOFT - Net-SNMP / SNMP Research) . . . . . 9 63 6. RFC 5591 Report (Net-SNMP - SNMP Research) . . . . . . . . . . 11 64 7. RFC 5591 Report (MG-SOFT - Net-SNMP / SNMP Research) . . . . . 13 65 8. RFC 5953 Report (Net-SNMP - SNMP Research) . . . . . . . . . . 15 66 9. RFC 5953 Report (MG-SOFT - Net-SNMP / SNMP Research) . . . . . 16 67 10. Security Considerations . . . . . . . . . . . . . . . . . . . 19 68 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 69 12. Informative References . . . . . . . . . . . . . . . . . . . . 19 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 72 1. Introduction 74 This document provides the interoperability report for SNMP Context 75 EngineID Discovery [RFC5343], the Transport Subsystem for SNMP 76 [RFC5590], the Transport Security Model for SNMP [RFC5591], and the 77 Transport Layer Security (TLS) Transport Model for SNMP [RFC5953]. 79 2. RFC 5343 Report (Net-SNMP - SNMP Research) 81 Summary 83 Two independent implementations of SNMP Context EngineID 84 Discovery have been developed, tested, and found to be 85 interoperable. The developers of both implementation agree that 86 RFC 5343 is sufficiently clear to allow for interoperable 87 implementations. 89 The two implementations which have been tested for 90 interoperability are Net-SNMP release 5.6 and SNMP Research 91 DR-Web EMANATE/Lite Agent Version 17.1.1.3. 93 Methodology 95 Each implementation provided remote access to running command 96 responders and tested the other implementation using their own 97 command generators. Packet captures were used to verify data 98 sent/received on the wire. 100 Exceptions 102 The list of untestable requirements are listed below in this 103 document. Initially one implementation was erroneously 104 performing discovery for all PDUs, including traps. This was 105 quickly fixed when discovered. 107 Testable Requirements 109 There were no testable requirements, as all requirements were 110 internal implementation details. 112 Packet sniffing was use to determine that implementations were 113 sending the correct localEngineID during discovery. 115 Untestable Requirements 117 3.1. Local EngineID 118 An SNMP command responder implementing this specification MUST 119 register their pduTypes using the localEngineID snmpEngineID 120 value (defined below) by invoking the 121 registerContextEngineID() Abstract Service Interface (ASI) 122 defined in RFC 3412 [RFC3412]. 124 Note that the localEngineID value is intended to be used as a 125 special value for the contextEngineID field in the ScopedPDU. 126 It MUST NOT be used as a value to identify an SNMP engine; 127 that is, this value MUST NOT be used in the snmpEngineID.0 128 scalar [RFC3418] or in the msgAuthoritativeEngineID field in 129 the securityParameters of the User-based Security Model (USM) 130 [RFC3414]. 132 3.2. EngineID Discovery 134 Discovery of the snmpEngineID is done by sending a Read Class 135 protocol operation (see Section 2.8 of [RFC3411]) to retrieve 136 the snmpEngineID scalar using the localEngineID defined above 137 as a contextEngineID value. Implementations SHOULD only 138 perform this discovery step when it is needed. 140 3. RFC 5343 Report (MG-SOFT - Net-SNMP / SNMP Research) 142 Summary 144 MG-SOFT's SNMP management utility built on top of MG-SOFT's 145 WinSNMP API version 8.0.500 (www.mg-soft.com), acting as a 146 command generator application, has been successfully tested over 147 the Internet against two other command responder applications: 149 1. Net-SNMP release 5.6 (www.net-snmp.org) 150 2. SMMP Research agent (www.snmp.com) 152 With both of these two independent implementations we have 153 successfully utilized the Context EngineID discovery mechanism 154 as defined in RFC 5343 and successfully passed the 155 interoperability tests. Both TLS and DTLS transport domains have 156 been tested. The SNMP Get and Get-Next operations have been 157 tested. 159 MG-SOFT provided for interoperability testing purposes a 160 publicly accessible SNMP agent that acts as command responder 161 application. So far, MG-SOFT's SNMP agent supporting SNMP over 162 TLS/DTLS has been successfully tested both by Net-SNMP release 163 5.6 tools and SNMP Research's tools. Both TLS and DTLS domains 164 have been tested successfully from both independent 165 implementations. The Context EngineID discovery mechanism has 166 been successfully utilized when (D)TLS sessions have been 167 successfully established. 169 In all tests the authPriv session has been successfully 170 negotiated. MG-SOFT's implementation does not implement the 171 optional mapping between TLS algorithms and SNMP security 172 levels. 174 In all cases, testing has been performed with 'interoperability 175 test' command-generator.crt and command-receiver.crt X.509 176 certificates as they were generated and prepared by the Net-SNMP 177 team. 179 MG-SOFT's WinSNMP API is utilizing the most recent openSSL 180 library (as of these tests, version 1.0.0d) for supporting the 181 underlying TLS and DTLS functionality. 183 MG-SOFT's developers believe that RFC 5343 is clear and exact 184 enough to allow a successful implementation. 186 Tested Requirements 188 - 3.1 Local EngineID 190 Usage of Local Engine ID has been successfully tested. Command 191 generator application successfully read snmpEngineID.0 by using 192 the Local Engine ID. 194 - 3.2 EngineID Discovery 196 The EngineID Discovery procedure has successfully been tested. 198 4. RFC 5590 Report (Net-SNMP - SNMP Research) 200 Summary 202 Two independent implementations of the Transport Subsystem have 203 been developed, tested, and found to be interoperable. The 204 developers of both implementation agree that RFC 5590 is 205 sufficiently clear to allow for interoperable implementations. 207 The two implementations which have been tested for 208 interoperability are Net-SNMP release 5.6 and SNMP Research 209 EMANATE/Lite Agent Version 17.1.1.3. 211 Methodology 213 As the Transport Subsystem is a framework on top of which new 214 transports can be defined, interoperability cannot be tested 215 directly. For this report, the Transport Subsystem 216 interoperability was tested during the interoperability testing 217 for the TLS security model defined in RFC 5953, for which a 218 separate interoperability report was submitted. 220 Exceptions 222 Most of the requirements in 5590 are requirements for future 223 transport protocols, and as such are not testable. The list of 224 untestable requirements is provided below as well. 226 Tested Requirements 228 - 3.3.4. Message Security versus Session Security 230 A Transport Model MAY upgrade the security level requested by 231 a transport-aware Security Model, i.e., noAuthNoPriv and 232 authNoPriv might be sent over an authenticated and encrypted 233 session. 235 To test this requirement a client established an authPriv session 236 and sent an authNoPriv message. 238 - 3.1.1. Security Protocol Requirements 240 Since multiple Transport Models can exist simultaneously within 241 the Transport Subsystem, Transport Models MUST be able to 242 coexist with each other. 244 Net-SNMP has implemented both the DTLS and SSH transports, with no 245 conflicts. 247 Untestable Requirements 249 - 3.1 Message Security Requirements 251 Transport security protocols SHOULD provide protection against 252 the following message-oriented threats: 254 1. modification of information 255 2. masquerade 256 3. message stream modification 257 4. disclosure 259 - 3.1.1. Security Protocol Requirements 261 A Transport Model SHOULD NOT require modifications to the 262 underlying protocol. Modifying the protocol might change its 263 security characteristics in ways that could impact other 264 existing usages. If a change is necessary, the change SHOULD 265 be an extension that has no impact on the existing usages. 267 Since multiple Transport Models can exist simultaneously within 268 the Transport Subsystem, Transport Models MUST be able to 269 coexist with each other. 271 - 3.2.2.1. securityName and securityLevel Mapping 273 Documents defining a new transport domain MUST define a prefix 274 that MAY be prepended to all securityNames passed by the 275 Security Model. The prefix MUST include one to four US-ASCII 276 alpha-numeric characters, not including a ":" (US-ASCII 0x3a) 277 character. 279 - 3.3.3. Session Maintenance Requirements 281 If a Transport Model defines MIB module objects to maintain 282 session state information, then the Transport Model MUST define 283 what happens to the objects when a related session is torn 284 down, since this will impact the interoperability of the MIB 285 module. 287 - 3.3.4. Message Security versus Session Security 289 Cryptographic keys associated with the transport session SHOULD 290 be used to provide authentication, integrity checking, and 291 encryption services, as needed, for data that is communicated 292 during the session. The cryptographic protocols used to 293 establish keys for a Transport Model session SHOULD ensure that 294 fresh new session keys are generated for each session. 296 - 3.3.4. Message Security versus Session Security 298 A Transport Model MUST NOT downgrade the security level 299 requested by a transport-aware Security Model, and SHOULD 300 discard any message where this would occur. 302 - 5.2. tmStateReference 304 For architectural modularity between Transport Models and 305 transport-aware Security Models, a fully-defined tmState MUST 306 conceptually include at least the following fields: 308 tmTransportDomain 309 tmTransportAddress 310 tmSecurityName 311 tmRequestedSecurityLevel 312 tmTransportSecurityLevel 313 tmSameSecurity 314 tmSessionID 316 - 5.2.4. Session Information 318 For security reasons, if a secure transport session is closed 319 between the time a request message is received and the 320 corresponding response message is sent, then the response 321 message SHOULD be discarded, even if a new session has been 322 established. 324 o tmSameSecurity: this flag is used by a transport-aware 325 Security Model to indicate whether the Transport Model MUST 326 enforce this restriction. 328 o tmSessionID: in order to verify whether the session has 329 changed, the Transport Model must be able to compare the 330 session used to receive the original request with the one to 331 be used to send the response 333 When processing an outgoing message, if tmSameSecurity is true, 334 then the tmSessionID MUST match the current transport session; 335 otherwise, the message MUST be discarded and the Dispatcher 336 notified that sending the message failed. 338 - 7. Security Considerations 340 Since the cache will contain security-related parameters, 341 implementers SHOULD store this information (in memory or in 342 persistent storage) in a manner to protect it from unauthorized 343 disclosure and/or modification. 345 - 7.1. Coexistence, Security Parameters, and Access Control 347 o For outgoing messages, if a Secure Transport Model is 348 selected in combination with a Security Model that does not 349 populate a tmStateReference, the Secure Transport Model 350 SHOULD detect the lack of a valid tmStateReference and fail. 352 5. RFC 5590 Report (MG-SOFT - Net-SNMP / SNMP Research) 354 Summary 356 MG-SOFT's SNMP management utility built on top of MG-SOFT's 357 WinSNMP API version 8.0.500 (www.mg-soft.com), acting as a 358 command generator application, has been successfully tested over 359 the Internet against two other command responder applications: 361 1. Net-SNMP release 5.6 (www.net-snmp.org) 362 2. SNMP Research agent (www.snmp.com) 364 With both of these two independent implementations we have 365 successfully passed the interoperability tests. 367 MG-SOFT provided for interoperability testing purposes a 368 publicly accessible SNMP agent that acts as command responder 369 application. So far, the MG-SOFT's SNMP agent supporting SNMP 370 over TLS/DTLS has been successfully tested both by Net-SNMP 371 release 5.6 tools and SNMP Research's tools. Both TLS and DTLS 372 domains have been tested successfully from both independent 373 implementations. 375 In all cases, testing has been performed with 'interoperability 376 test' command-generator.crt and command-receiver.crt X.509 377 certificates as they were generated and prepared by the Net-SNMP 378 team. 380 MG-SOFT's WinSNMP API is utilizing the most recent openSSL 381 library (as of these tests, version 1.0.0d) for supporting the 382 underlying TLS and DTLS functionality. 384 RFC 5590 defines a transport subsystem that extends Simple 385 Network Management Protocol (SNMP) architecture defined in RFC 386 3411. As RFC 5590 defines a framework for the coexistence of 387 multiple different transport models and MG-SOFT's WinSNMP API 388 version 8.0.500 implements only the Transport Layer Security 389 (TLS) Transport Model defined in RFC 5953, the requirements 390 defined in RFC 5590 could not be tested directly. The 391 interoperability of the framework defined in RFC 5590 has been 392 confirmed indirectly while testing interoperability of the RFC 393 5953. 395 MG-SOFT's developers believe that RFC 5590 is clear and exact 396 enough to allow a successful implementation. 398 Tested Requirements 399 - 3.3.4. Message Security versus Session Security 401 A Transport Model MAY upgrade the security level requested by a 402 transport-aware Security Model, i.e., noAuthNoPriv and 403 authNoPriv might be sent over an authenticated and encrypted 404 session. 406 MG-SOFT command generator application sends noAuthNoPriv message 407 for ContextEngineId discovery over previously established 408 authPriv session. 410 Untested Requirements 412 - 3.1 Message security requirements 414 Protection against message-oriented threads: modification of 415 information, masquerade, message stream modification and 416 disclosure have not been tested. 418 - 3.1.1 Security protocol requirements 420 As MG-SOFT has implemented only the TLS transport model, the 421 coexistence of multiple transport models could not be tested. 423 - 3.2.1 Architectural Modularity Requirements 425 These requirements could not be tested directly. However, MG-SOFT 426 followed these requirements when extending MG-SOFT WinSNMP API. 428 - 3.2.2 Access Control Requirements 430 Access control requirements have not been tested. 432 - 3.3.1 No SNMP Session 434 Maintenance of multiple transport sessions has not been tested. 436 - 3.3.2 Session Establishment Requirements 438 These requirements have not been tested directly. 440 - 3.3.3. Session Maintenance Requirements 442 Session maintenance requirements have not been tested. 444 - 3.3.4. Message Security versus Session Security 446 These requirements have not been completely tested. 448 - 5.2 tmStateReference 450 These requirements have not been tested directly. 452 - 5.2.4 Session Information 454 These requirements have not been tested. 456 - 7 Security Considerations 458 These requirements have not been tested. 460 - 7 Coexistence, Security Parameters, and Access Control 462 These requirements have not been tested. 464 6. RFC 5591 Report (Net-SNMP - SNMP Research) 466 Summary 468 Two independent implementations of the Transport Security Model 469 (TSM) have been developed, tested, and found to be 470 interoperable. The developers of both implementation agree that 471 RFC 5591 is sufficiently clear to allow for interoperable 472 implementations. 474 The two implementations which have been tested for 475 interoperability are Net-SNMP release 5.6 and SNMP Research 476 DR-Web EMANATE/Lite Agent Version 17.1.1.3. 478 Methodology 480 As the TSM is a framework security model to be used with other 481 secure transports, interoperability cannot be tested 482 directly. For this report, TSM interoperability was tested 483 during the interoperability testing for the TLS security model 484 defined in RFC 5953. 486 Exceptions 488 The list of untestable requirements are listed below in this 489 document. 491 Initially one implementation was erroneously setting the security 492 level for response packets to match the security level asserted 493 by the transport layer. This caused the other implementation to 494 drop the response when it was received. The ASI in section 495 4.1.2, Sending a Response to the Network, has a comment 496 associated with the securityLevel passed to returnResponsePdu 497 which indicates that the value should match the value from the 498 incoming packet. This is consistent with how the SNMPv3 standard 499 specifies handling of the securityLevel, thus the implementation 500 was in error. 502 Testable Requirements 504 - 1.1 Mandatory MIB objects 506 snmpTsmCompliance MODULE-COMPLIANCE 507 MANDATORY-GROUPS { snmpTsmGroup } 508 snmpTsmGroup OBJECT-GROUP 509 snmpTsmInvalidCaches, 510 snmpTsmInadequateSecurityLevels, 511 snmpTsmUnknownPrefixes, 512 snmpTsmInvalidPrefixes, 513 snmpTsmConfigurationUsePrefix 515 Client side tests 516 o verify each object can be queried 517 o verify that snmpTsmConfigurationUsePrefix is writable 519 Exceptions 520 o Both existing implementations of RFC 5953 chose to always 521 negotiate authPriv sessions and did not implement the optional 522 mapping of TLS algorithms to SNMP security levels. This made it 523 impossible to send an authPriv message over a transport with an 524 inadequate security level. Net-SNMP plans on implementing 525 mapping in a future release, and SNMP Research has indicated 526 that it will implement it given sufficient customer demand. 528 Untestable Requirements 530 - 3.1.2. tmStateReference 532 For the Transport Security Model, the security parameters used 533 for a response MUST be the same as those used for the 534 corresponding request. 536 - 3.1.3. Prefixes and securityNames 538 If snmpTsmConfigurationUsePrefix is set to true, then all 539 securityNames provided by, or provided to, the Transport 540 Security Model MUST include a valid transport domain prefix. 542 If snmpTsmConfigurationUsePrefix is set to false, then all 543 securityNames provided by, or provided to, the Transport 544 Security Model MUST NOT include a transport domain prefix. 546 - 8. Security Considerations 548 This Security Model SHOULD always be used with Transport Models 549 that provide adequate security, but "adequate security" is a 550 configuration and/or run-time decision of the operator or 551 management application. 553 7. RFC 5591 Report (MG-SOFT - Net-SNMP / SNMP Research) 555 Summary 557 MG-SOFT's SNMP management utility built on top of MG-SOFT's 558 WinSNMP API version 8.0.500 (www.mg-soft.com), acting as a 559 command generator application, has been successfully tested over 560 the Internet against two other command responder applications: 562 1. Net-SNMP release 5.6 (www.net-snmp.org) 563 2. SNMP Research agent (www.snmp.com) 565 With both of these two independent implementations we have 566 successfully passed the interoperability tests. Both the TLS 567 and the DTLS transport domain have been tested. The SNMP Get and 568 Get-Next operations have been tested. 570 MG-SOFT provided for interoperablility testing purposes a 571 publicly accessible SNMP agent that acts as command responder 572 application. So far, the MG-SOFT's SNMP agent supporting SNMP 573 over TLS/DTLS has been sucesfully tested both by Net-SNMP 574 release 5.6 tools and SNMP Research's tools. Both TLS and DTLS 575 domains have been tested successfully from both independent 576 implementations. 578 In all cases, testing has been performed with 'interoperability 579 test' command-generator.crt and command-receiver.crt X.509 580 certificates as they were generated and prepared by the Net-SNMP 581 team. 583 MG-SOFT's implementation does not implement the optional mapping 584 between TLS algorithms and SNMP security levels. 586 MG-SOFT's WinSNMP API is utilizing the most recent openSSL 587 library (as of these tests, version 1.0.0d) for supporting the 588 underlying TLS and DTLS functionality. 590 MG-SOFT's developers believe that RFC 5591 is clear and exact 591 enough to allow a successful implementation. 593 Tested Requirements 595 - 2.3.1 Coexistence with Message Processing Models 597 Coexistence with SNMPv1 and SNMPv2c message processing models 598 has been successfully tested in the command generator role. The 599 MG-SOFT SNMP management utility application has been 600 successfully performing SNMP operation against different SNMP 601 agents by using SNMPv1, SNMPv2c and SNMPv3-USM over unencrypted 602 UDP (SNMP agents in MG-SOFT lab) and SNMPv3-TSM over TSLTM 603 (Net-SNMP's and SNMP Research's publicly accessible test SNMP 604 agent). 606 - 2.3.2 Coexistence with Other Security Models 608 Coexistence with the SNMPv3-USM security model has been 609 successfully tested in the command generator role. The MG-SOFT 610 SNMP management utility application has been successfully 611 performing SNMP operation against different SNMP agents by using 612 SNMPv3-USM over unencrypted UDP (SNMP agents in MG-SOFT lab) and 613 SNMPv3-TSM over TSLTM (Net-SNMP's and SNMP Research's publicly 614 accessible test SNMP agent). 616 - 8. Security Considerations 618 Usage of TSM without TLSTM is disabled in MG-SOFT's WinSNMP API, 619 so it can not be used with a transport model without adequate 620 security. 622 Untested Requirements 624 - 2.3.3 Coexistence with Transport Models 626 Coexistence with transport models has not been tested. 628 - 3.1.3 Prefixes and securityNames 630 Usage of SNMP transport domain prefixes and the configuration of 631 its usage in the SNMP-TSM-MIB have not been tested. 633 - 6. MIB Module Overview 635 The implementation of SNMP-TSM-MIB has not been tested. 637 8. RFC 5953 Report (Net-SNMP - SNMP Research) 639 Summary 641 Two independent implementations of the Transport Layer Security 642 (TLS) Transport Model been developed, tested, and found to be 643 interoperable. The developers of both implementation agree that 644 RFC 5953 is sufficiently clear to allow for interoperable 645 implementations. 647 The two implementations which have been tested for 648 interoperability are Net-SNMP version 5.6 and SNMP Research 649 EMANATE/Lite Agent Version 17.1.1.3. Although the SNMP code for 650 each is independent, both use the (D)TLS libraries from 651 OpenSSL. However, each used a different approach for using the 652 (D)TLS API. 654 The Net-SNMP project has deployed a publicly available test 655 server to allow for continued interoperability testing with new 656 or existing implementations. 658 Methodology 660 Each implementation provided remote access to running command 661 responders and trap receivers, and tested the other 662 implementation using their own command generators. In addition 663 to basic object comparisons, stimulus/response testing was 664 conducted. 666 Exceptions 668 Both existing implementations of RFC 5953 chose to always 669 negotiate authPriv sessions and did not implement the optional 670 mapping of TLS algorithms to SNMP security levels. This made it 671 impossible to test sending an authPriv message over a transport 672 with an inadequate security level. (Net-SNMP plans to add 673 security level mapping in a future release, and SNMP Research 674 indicates that they will implement the feature if there is 675 sufficient customer demand.) 677 Implementations that do choose to implement mapping of TLS 678 algorithms to SNMP security levels should provide clear 679 documentation to their users about the implications of mapping 680 algorithms to security levels other than authPriv. Consider the 681 following scenario: Client A maps MD5/RC4 to authPriv and 682 negotiates a TLS session with Agent B, who maps md5/rc4 to 683 authNoPriv. Packets from Client A that are marked authPriv will 684 be silently dropped, even though (D)TLS negotiations succeeded. 686 Details 688 The short version, for the impatient, is that "it works." Basic 689 interoperability between the Net-SNMP and SNMP Research 690 implementations has been demonstrated for all the core protocol 691 operations (e.g. Get, Get-Next, Set, Trap, Inform). 693 Neither implementation claims to be a complete, bug-free 694 production ready implementation, and occasional differences have 695 been found noted between the implementations. To date, however, 696 all the differences have fallen into one of these categories: 698 - object not implemented yet 699 - corner cases not handled yet 700 - code needs to be refactored to meet requirement 702 In other words, so far all issues are with a particular 703 implementation, not with the specification. 705 Testing has been performed for various certificate 706 configurations, include self-signed certificate and certificates 707 signed by a trusted certificate authority. 709 Security name mappings have been made by directly specifying the 710 security name for a certificate, and by mapping the common name 711 or subject alt names (including email addresses, dns addresses 712 and IP addresses). 714 It may be helpful to add text clarifying that the security level 715 associated with a (D)TLS session is only used for ensuring that 716 a session has sufficient security for a packet. The security 717 level in outgoing/incoming packets continue to function per the 718 SNMPv3 standard. In other words, the security level in outgoing 719 packets is not modified to match the security level of the 720 session, and response packets copy the security level from the 721 original packet. 723 9. RFC 5953 Report (MG-SOFT - Net-SNMP / SNMP Research) 725 Summary 727 MG-SOFT's SNMP management utility built on top of MG-SOFT's 728 WinSNMP API version 8.0.500 (www.mg-soft.com), acting as a 729 command generator application, has been successfully tested over 730 the Internet against two other command responder applications: 732 1. Net-SNMP release 5.6 (www.net-snmp.org) 733 2. SNMP Research agent (www.snmp.com) 735 With both of these two independent implementations we have 736 successfully communicated using TLSTM and so passed the basic 737 interoperability tests. Both TLS and DTLS transport domain have 738 been been tested. The SNMP Get and Get-Next operations have been 739 tested. In all tests an authPriv session has been negotiated. 740 MG-SOFT's implementation does not implement the optional 741 mapping between TLS algorithms and SNMP security levels. 743 MG-SOFT provided for interoperability testing purposes a 744 publicly accessible SNMP agent that acts as command responder 745 application. So far, MG-SOFT's SNMP agent supporting SNMP over 746 TLS/DTLS has been successfully tested both by Net-SNMP release 747 5.6 tools and SNMP Research's tools. Both TLS and DTLS domains 748 have been tested successfully from both independent 749 implementations. 751 In all cases, testing has been performed with 'interoperability 752 test' command-generator.crt and command-receiver.crt X.509 753 certificates as they were generated and prepared by the Net-SNMP 754 team. 756 MG-SOFT's WinSNMP API is utilizing the most recent openSSL 757 library (as of these tests, version 1.0.0d) for supporting the 758 underlying TLS and DTLS functionality. 760 MG-SOFT's developers believe that RFC 5953 is clear and exact 761 enough to allow a successful implementation. 763 Tested Requirements 765 - 3.1.2 Message Protection 767 In all tests the authPriv session has been negotiated. MG-SOFT's 768 implementation does not implement the optional mapping of TLS 769 security algorithms to SNMP security levels. 771 - 3.1.3 (D)TLS Connections 773 MG-SOFT implementation opens a (D)TLS connection when an SNMP 774 message needs to be sent. The connection remains opened until 775 the user or application decides to close it. Sending and 776 receiving multiple SNMP messages over a single (D)TLS connection 777 has been successfully tested. 779 - 4.1 X.509 Certificates 781 Both entities have used X.509 certificates for authentication. 783 - 4.1.1 Provisioning for the Certificate 785 Usage of a root certificate for certificate verification has 786 also been tested. 788 - 4.2 (D)TLS Usage 790 Both, client and server side have been authenticated by X.509 791 certificates. For DTLS (over UDP), each SNMP message is placed 792 in a single UDP datagram. Packet fragmentation/concatenation has 793 been enabled. 795 - 8.3 contextEngineID Discovery 797 ContextEngineID Discovery as defined in RFC 5343 has been 798 successfully tested, for which a separate interoperability 799 report was submitted. 801 - 9.3 Use with SNMPv1/SNMPv2c Messages 803 Usage of SNMPv1, SNMPv2c and SNMPv3 with USM security model over 804 (D)TSL is disabled in MG-SOFT's WinSNMP API implementation. 806 Untested Requirements 808 - 3.1.2 Message Protection 810 MG-SOFT's WinSNMP API implementation does not implement the 811 optional mapping between TLS security algorithms and SNMP 812 security levels. 814 - 3.1.3 (D)TLS Connections 816 Coexistence and operation of multiple (D)TLS connections has not 817 been tested. 819 - 3.3 Notification and Proxy 821 These requirements have not been tested since only a command 822 generator was available at the time of testing. 824 - 4.1.1 Provisioning for the Certificate 826 Mapping of incoming message to tmSecurityName has not been 827 tested. Mapping of a certificate's fingerprint value to a 828 tmSecurityName has not been tested. 830 - 4.4.1.1 tmSecurityName 832 Mapping from certificate to tmSecurityName has not been tested. 834 - 8.1 Sessions 836 Lifetime limitation of established sessions has not been tested. 838 - 8.2 Notification Receiver Credential Selection 840 Notifications have not been tested. 842 - 9.1 Certificates, Authentication and Authorization 844 Implementation of the SNMP-TLS-TM-MIB has not been tested. 846 10. Security Considerations 848 The interoperability testing did not identify any security issues 849 that are not covered in the security considerations of the relevant 850 specifications. 852 11. IANA Considerations 854 This document has no IANA actions. 856 12. Informative References 858 [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An 859 Architecture for Describing Simple Network Management 860 Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, 861 December 2002. 863 [RFC3412] Case, J., Harrington, D., Presuhn, R., and B. Wijnen, 864 "Message Processing and Dispatching for the Simple Network 865 Management Protocol (SNMP)", STD 62, RFC 3412, 866 December 2002. 868 [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model 869 (USM) for version 3 of the Simple Network Management 870 Protocol (SNMPv3)", STD 62, RFC 3414, December 2002. 872 [RFC3418] Presuhn, R., "Management Information Base (MIB) for the 873 Simple Network Management Protocol (SNMP)", STD 62, 874 RFC 3418, December 2002. 876 [RFC5343] Schoenwaelder, J., "Simple Network Management Protocol 877 (SNMP) Context EngineID Discovery", RFC 5343, 878 September 2008. 880 [RFC5590] Harrington, D. and J. Schoenwaelder, "Transport Subsystem 881 for the Simple Network Management Protocol (SNMP)", 882 RFC 5590, June 2009. 884 [RFC5591] Harrington, D. and W. Hardaker, "Transport Security Model 885 for the Simple Network Management Protocol (SNMP)", 886 RFC 5591, June 2009. 888 [RFC5953] Hardaker, W., "Transport Layer Security (TLS) Transport 889 Model for the Simple Network Management Protocol (SNMP)", 890 RFC 5953, August 2010. 892 Authors' Addresses 894 Juergen Schoenwaelder (editor) 895 Jacobs University Bremen 897 Email: j.schoenwaelder@jacobs-university.de 899 Robert Story 900 SPARTA/Cobham 902 Email: robert.story@cobham.com 904 Matjaz Vrecko 905 MG-SOFT 907 Email: matjaz@mg-soft.si