| < draft-schoenw-isms-interoperability-report-00.txt | draft-schoenw-isms-interoperability-report-01.txt > | |||
|---|---|---|---|---|
| ISMS J. Schoenwaelder, Ed. | ISMS J. Schoenwaelder, Ed. | |||
| Internet-Draft Jacobs University Bremen | Internet-Draft Jacobs University Bremen | |||
| Intended status: Informational R. Story | Intended status: Informational R. Story | |||
| Expires: September 8, 2011 SPARTA/Cobham | Expires: October 6, 2011 SPARTA/Cobham | |||
| M. Vrecko | M. Vrecko | |||
| MG-SOFT | MG-SOFT | |||
| March 7, 2011 | April 4, 2011 | |||
| Interoperability Report for RFC 5343, RFC 5590, RFC 5591, and RFC 5953 | Interoperability Report for RFC 5343, RFC 5590, RFC 5591, and RFC 5953 | |||
| draft-schoenw-isms-interoperability-report-00 | draft-schoenw-isms-interoperability-report-01 | |||
| Abstract | Abstract | |||
| This document provides the interoperability report for RFC 5343, RFC | This document provides the interoperability report for RFC 5343, RFC | |||
| 5590, RFC 5591, and RFC 5953. | 5590, RFC 5591, and RFC 5953. | |||
| Status of this Memo | Status of this Memo | |||
| This Internet-Draft is submitted to IETF in full conformance with the | This Internet-Draft is submitted to IETF in full conformance with the | |||
| provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
| skipping to change at page 1, line 40 ¶ | skipping to change at page 1, line 40 ¶ | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| The list of current Internet-Drafts can be accessed at | The list of current Internet-Drafts can be accessed at | |||
| http://www.ietf.org/ietf/1id-abstracts.txt. | http://www.ietf.org/ietf/1id-abstracts.txt. | |||
| The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||
| http://www.ietf.org/shadow.html. | http://www.ietf.org/shadow.html. | |||
| This Internet-Draft will expire on September 8, 2011. | This Internet-Draft will expire on October 6, 2011. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2011 IETF Trust and the persons identified as the | Copyright (c) 2011 IETF Trust and the persons identified as the | |||
| document authors. All rights reserved. | document authors. All rights reserved. | |||
| This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
| Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
| (http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | |||
| publication of this document. Please review these documents | publication of this document. Please review these documents | |||
| carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
| to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
| include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
| the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
| described in the BSD License. | described in the BSD License. | |||
| Table of Contents | Table of Contents | |||
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
| 2. RFC 5343 Report (Net-SNMP - SNMP Research) . . . . . . . . . . 3 | 2. RFC 5343 Report (Net-SNMP - SNMP Research) . . . . . . . . . . 3 | |||
| 3. RFC 5343 Report (MG-SOFT - Net-SNMP) . . . . . . . . . . . . . 4 | 3. RFC 5343 Report (MG-SOFT - Net-SNMP / SNMP Research) . . . . . 4 | |||
| 4. RFC 5590 Report (Net-SNMP - SNMP Research) . . . . . . . . . . 5 | 4. RFC 5590 Report (Net-SNMP - SNMP Research) . . . . . . . . . . 5 | |||
| 5. RFC 5590 Report (MG-SOFT - Net-SNMP) . . . . . . . . . . . . . 9 | 5. RFC 5590 Report (MG-SOFT - Net-SNMP / SNMP Research) . . . . . 9 | |||
| 6. RFC 5591 Report (Net-SNMP - SNMP Research) . . . . . . . . . . 11 | 6. RFC 5591 Report (Net-SNMP - SNMP Research) . . . . . . . . . . 11 | |||
| 7. RFC 5591 Report (MG-SOFT - Net-SNMP) . . . . . . . . . . . . . 12 | 7. RFC 5591 Report (MG-SOFT - Net-SNMP / SNMP Research) . . . . . 13 | |||
| 8. RFC 5953 Report (Net-SNMP - SNMP Research) . . . . . . . . . . 14 | 8. RFC 5953 Report (Net-SNMP - SNMP Research) . . . . . . . . . . 15 | |||
| 9. RFC 5953 Report (MG-SOFT - Net-SNMP) . . . . . . . . . . . . . 16 | 9. RFC 5953 Report (MG-SOFT - Net-SNMP / SNMP Research) . . . . . 16 | |||
| 10. Security Considerations . . . . . . . . . . . . . . . . . . . 18 | 10. Security Considerations . . . . . . . . . . . . . . . . . . . 19 | |||
| 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 | 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 | |||
| 12. Informative References . . . . . . . . . . . . . . . . . . . . 18 | 12. Informative References . . . . . . . . . . . . . . . . . . . . 19 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 | |||
| 1. Introduction | 1. Introduction | |||
| This document provides the interoperability report for SNMP Context | This document provides the interoperability report for SNMP Context | |||
| EngineID Discovery [RFC5343], the Transport Subsystem for SNMP | EngineID Discovery [RFC5343], the Transport Subsystem for SNMP | |||
| [RFC5590], the Transport Security Model for SNMP [RFC5591], and the | [RFC5590], the Transport Security Model for SNMP [RFC5591], and the | |||
| Transport Layer Security (TLS) Transport Model for SNMP [RFC5953]. | Transport Layer Security (TLS) Transport Model for SNMP [RFC5953]. | |||
| 2. RFC 5343 Report (Net-SNMP - SNMP Research) | 2. RFC 5343 Report (Net-SNMP - SNMP Research) | |||
| skipping to change at page 3, line 36 ¶ | skipping to change at page 3, line 36 ¶ | |||
| Methodology | Methodology | |||
| Each implementation provided remote access to running command | Each implementation provided remote access to running command | |||
| responders and tested the other implementation using their own | responders and tested the other implementation using their own | |||
| command generators. Packet captures were used to verify data | command generators. Packet captures were used to verify data | |||
| sent/received on the wire. | sent/received on the wire. | |||
| Exceptions | Exceptions | |||
| The list of untestable requirements are listed below in this | The list of untestable requirements are listed below in this | |||
| document. Initially one implementation was erronously | document. Initially one implementation was erroneously | |||
| performing discovery for all PDUs, including traps. This was | performing discovery for all PDUs, including traps. This was | |||
| quickly fixed when discovered. | quickly fixed when discovered. | |||
| Testable Requirements | Testable Requirements | |||
| There were no testable requirements, as all requirements were | There were no testable requirements, as all requirements were | |||
| internal implementation details. | internal implementation details. | |||
| Packet sniffing was use to determine that implementations were | Packet sniffing was use to determine that implementations were | |||
| sending the correct localEngineID during discovery. | sending the correct localEngineID during discovery. | |||
| skipping to change at page 4, line 26 ¶ | skipping to change at page 4, line 26 ¶ | |||
| [RFC3414]. | [RFC3414]. | |||
| 3.2. EngineID Discovery | 3.2. EngineID Discovery | |||
| Discovery of the snmpEngineID is done by sending a Read Class | Discovery of the snmpEngineID is done by sending a Read Class | |||
| protocol operation (see Section 2.8 of [RFC3411]) to retrieve | protocol operation (see Section 2.8 of [RFC3411]) to retrieve | |||
| the snmpEngineID scalar using the localEngineID defined above | the snmpEngineID scalar using the localEngineID defined above | |||
| as a contextEngineID value. Implementations SHOULD only | as a contextEngineID value. Implementations SHOULD only | |||
| perform this discovery step when it is needed. | perform this discovery step when it is needed. | |||
| 3. RFC 5343 Report (MG-SOFT - Net-SNMP) | 3. RFC 5343 Report (MG-SOFT - Net-SNMP / SNMP Research) | |||
| Summary | Summary | |||
| MG-SOFT Micro MIB Browser utilizing MG-SOFT's own WinSNMP API | MG-SOFT's SNMP management utility built on top of MG-SOFT's | |||
| version 8.0.500, as a command generator application, has been | WinSNMP API version 8.0.500 (www.mg-soft.com), acting as a | |||
| tested against Net-SNMP release 5.6, as a command responder | command generator application, has been successfully tested over | |||
| application. These two independent implementations have | 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 | successfully utilized the Context EngineID discovery mechanism | |||
| as defined in RFC 5343 and successfully passed the | as defined in RFC 5343 and successfully passed the | |||
| interoperability tests. | interoperability tests. Both TLS and DTLS transport domains have | |||
| been tested. The SNMP Get and Get-Next operations have been | ||||
| tested. | ||||
| MG-SOFT WinSNMP API is utilizing the most recent openSSL library | MG-SOFT provided for interoperability testing purposes a | |||
| (as of these tests, version 1.0.0d) for supporting the | publicly accessible SNMP agent that acts as command responder | |||
| underlying TLS and DTLS functionality. | 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. The Context EngineID discovery mechanism has | ||||
| been successfully utilized when (D)TLS sessions have been | ||||
| successfully established. | ||||
| Net-SNMP provides a publicly accessible test SNMP agent | In all tests the authPriv session has been successfully | |||
| (test.net-snmp.org). Testing has been performed with X.509 | negotiated. MG-SOFT's implementation does not implement the | |||
| certificates signed by a trusted certificate authority. Both TLS | optional mapping between TLS algorithms and SNMP security | |||
| and DTLS transport domains have been tested. The SNMP Get and | levels. | |||
| Get-Next operations have been tested. In all tests the authPriv | ||||
| session has been successfully negotiated. MG-SOFT's | In all cases, testing has been performed with 'interoperability | |||
| implementation does not implement optional mapping between TLS | test' command-generator.crt and command-receiver.crt X.509 | |||
| algorithms and SNMP security levels. | 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 | MG-SOFT's developers believe that RFC 5343 is clear and exact | |||
| enough to allow a successful implementation. | enough to allow a successful implementation. | |||
| Tested Requirements | Tested Requirements | |||
| - 3.1 Local EngineID | - 3.1 Local EngineID | |||
| Usage of Local Engine ID has been successfully tested. Command | Usage of Local Engine ID has been successfully tested. Command | |||
| generator application successfully read snmpEngineID.0 by using | generator application successfully read snmpEngineID.0 by using | |||
| skipping to change at page 6, line 11 ¶ | skipping to change at page 6, line 7 ¶ | |||
| been developed, tested, and found to be interoperable. The | been developed, tested, and found to be interoperable. The | |||
| developers of both implementation agree that RFC 5590 is | developers of both implementation agree that RFC 5590 is | |||
| sufficiently clear to allow for interoperable implementations. | sufficiently clear to allow for interoperable implementations. | |||
| The two implementations which have been tested for | The two implementations which have been tested for | |||
| interoperability are Net-SNMP release 5.6 and SNMP Research | interoperability are Net-SNMP release 5.6 and SNMP Research | |||
| EMANATE/Lite Agent Version 17.1.1.3. | EMANATE/Lite Agent Version 17.1.1.3. | |||
| Methodology | Methodology | |||
| As the Transport Subsytem is a framework on top of which new | As the Transport Subsystem is a framework on top of which new | |||
| transports can be defined, interoperability cannot be tested | transports can be defined, interoperability cannot be tested | |||
| directly. For this report, the Transport Subsystem | directly. For this report, the Transport Subsystem | |||
| interoperability was tested during the interoperability testing | interoperability was tested during the interoperability testing | |||
| for the TLS security model defined in RFC 5953, for which a | for the TLS security model defined in RFC 5953, for which a | |||
| separate interoperability report was submitted. | separate interoperability report was submitted. | |||
| Exceptions | Exceptions | |||
| Most of the requirements in 5590 are requirements for future | Most of the requirements in 5590 are requirements for future | |||
| transport protocols, and as such are not testable. The list of | transport protocols, and as such are not testable. The list of | |||
| skipping to change at page 9, line 5 ¶ | skipping to change at page 9, line 5 ¶ | |||
| persistent storage) in a manner to protect it from unauthorized | persistent storage) in a manner to protect it from unauthorized | |||
| disclosure and/or modification. | disclosure and/or modification. | |||
| - 7.1. Coexistence, Security Parameters, and Access Control | - 7.1. Coexistence, Security Parameters, and Access Control | |||
| o For outgoing messages, if a Secure Transport Model is | o For outgoing messages, if a Secure Transport Model is | |||
| selected in combination with a Security Model that does not | selected in combination with a Security Model that does not | |||
| populate a tmStateReference, the Secure Transport Model | populate a tmStateReference, the Secure Transport Model | |||
| SHOULD detect the lack of a valid tmStateReference and fail. | SHOULD detect the lack of a valid tmStateReference and fail. | |||
| 5. RFC 5590 Report (MG-SOFT - Net-SNMP) | 5. RFC 5590 Report (MG-SOFT - Net-SNMP / SNMP Research) | |||
| Summary | Summary | |||
| MG-SOFT Micro MIB Browser utilizing MG-SOFT's own WinSNMP API | MG-SOFT's SNMP management utility built on top of MG-SOFT's | |||
| version 8.0.500, as a command generator application, has been | WinSNMP API version 8.0.500 (www.mg-soft.com), acting as a | |||
| tested against Net-SNMP release 5.6, as a command responder | command generator application, has been successfully tested over | |||
| application. These two independent implementations have | 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. | successfully passed the interoperability tests. | |||
| MG-SOFT WinSNMP API is utilizing the most recent openSSL library | MG-SOFT provided for interoperability testing purposes a | |||
| (as of these tests, version 1.0.0d) for supporting the | 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. | underlying TLS and DTLS functionality. | |||
| RFC 5590 defines the transport subsystem that extends the Simple | RFC 5590 defines a transport subsystem that extends Simple | |||
| Network Management Protocol (SNMP) architecture defined in RFC | Network Management Protocol (SNMP) architecture defined in RFC | |||
| 3411. As RFC 5590 defines framework for coexistence of multiple | 3411. As RFC 5590 defines a framework for the coexistence of | |||
| different transport models and MG-SOFT's WinSNMP API version | multiple different transport models and MG-SOFT's WinSNMP API | |||
| 8.0.500 implements only the Transport Layer Security (TLS) | version 8.0.500 implements only the Transport Layer Security | |||
| Transport Model defined in RFC 5953, the requirements defined in | (TLS) Transport Model defined in RFC 5953, the requirements | |||
| RFC 5590 could not be tested directly. The interoperability of | defined in RFC 5590 could not be tested directly. The | |||
| the framework defined in RFC 5590 has been confirmed indirectly | interoperability of the framework defined in RFC 5590 has been | |||
| while testing interoperability of RFC 5953. | confirmed indirectly while testing interoperability of the RFC | |||
| 5953. | ||||
| MG-SOFT's developers believe that RFC 5590 is clear and exact | MG-SOFT's developers believe that RFC 5590 is clear and exact | |||
| enough to allow a successful implementation. | enough to allow a successful implementation. | |||
| Tested Requirements | Tested Requirements | |||
| - 3.3.4. Message Security versus Session Security | - 3.3.4. Message Security versus Session Security | |||
| A Transport Model MAY upgrade the security level requested by a | A Transport Model MAY upgrade the security level requested by a | |||
| transport-aware Security Model, i.e., noAuthNoPriv and | transport-aware Security Model, i.e., noAuthNoPriv and | |||
| authNoPriv might be sent over an authenticated and encrypted | authNoPriv might be sent over an authenticated and encrypted | |||
| session. | session. | |||
| MG-SOFT command generator application sends noAuthNoPriv message | MG-SOFT command generator application sends noAuthNoPriv message | |||
| for ContextEngineId discovery over previously established | for ContextEngineId discovery over previously established | |||
| authPriv session. | authPriv session. | |||
| skipping to change at page 11, line 7 ¶ | skipping to change at page 11, line 23 ¶ | |||
| - 7 Security Considerations | - 7 Security Considerations | |||
| These requirements have not been tested. | These requirements have not been tested. | |||
| - 7 Coexistence, Security Parameters, and Access Control | - 7 Coexistence, Security Parameters, and Access Control | |||
| These requirements have not been tested. | These requirements have not been tested. | |||
| 6. RFC 5591 Report (Net-SNMP - SNMP Research) | 6. RFC 5591 Report (Net-SNMP - SNMP Research) | |||
| Summary | Summary | |||
| Two independent implementations of the Transport Security Model | Two independent implementations of the Transport Security Model | |||
| (TSM) have been developed, tested, and found to be | (TSM) have been developed, tested, and found to be | |||
| interoperable. The developers of both implementation agree that | interoperable. The developers of both implementation agree that | |||
| RFC 5591 is sufficiently clear to allow for interoperable | RFC 5591 is sufficiently clear to allow for interoperable | |||
| implementations. | implementations. | |||
| The two implementations which have been tested for | The two implementations which have been tested for | |||
| interoperability are Net-SNMP release 5.6 and SNMP Research | interoperability are Net-SNMP release 5.6 and SNMP Research | |||
| DR-Web EMANATE/Lite Agent Version 17.1.1.3. | DR-Web EMANATE/Lite Agent Version 17.1.1.3. | |||
| Methodology | Methodology | |||
| As the TSM is a framework security model to be used with other | As the TSM is a framework security model to be used with other | |||
| secure transports, interoperability cannot be tested | secure transports, interoperability cannot be tested | |||
| directly. For this report, TSM interoperability was tested | directly. For this report, TSM interoperability was tested | |||
| during the interoperability testing for the TLS security model | during the interoperability testing for the TLS security model | |||
| defined in RFC 5953. | defined in RFC 5953. | |||
| Exceptions | Exceptions | |||
| The list of untestable requirements are listed below in this | The list of untestable requirements are listed below in this | |||
| document. | document. | |||
| Initially one implementation was erronously setting the security | Initially one implementation was erroneously setting the security | |||
| level for response packets to match the security level asserted | level for response packets to match the security level asserted | |||
| by the transport layer. This caused the other implementation to | by the transport layer. This caused the other implementation to | |||
| drop the response when it was received. The ASI in section | drop the response when it was received. The ASI in section | |||
| 4.1.2, Sending a Response to the Network, has a comment | 4.1.2, Sending a Response to the Network, has a comment | |||
| associated with the securityLevel passed to returnResponsePdu | associated with the securityLevel passed to returnResponsePdu | |||
| which indicates that the value should match the value from the | which indicates that the value should match the value from the | |||
| incoming packet. This is consistent with how the SNMPv3 standard | incoming packet. This is consistent with how the SNMPv3 standard | |||
| specifies handling of the securityLevel, thus the implementation | specifies handling of the securityLevel, thus the implementation | |||
| was in error. | was in error. | |||
| Testable Requirements | Testable Requirements | |||
| - 1.1 Mandatory MIB objects | - 1.1 Mandatory MIB objects | |||
| snmpTsmCompliance MODULE-COMPLIANCE | snmpTsmCompliance MODULE-COMPLIANCE | |||
| MANDATORY-GROUPS { snmpTsmGroup } | MANDATORY-GROUPS { snmpTsmGroup } | |||
| snmpTsmGroup OBJECT-GROUP | snmpTsmGroup OBJECT-GROUP | |||
| snmpTsmInvalidCaches, | snmpTsmInvalidCaches, | |||
| snmpTsmInadequateSecurityLevels, | snmpTsmInadequateSecurityLevels, | |||
| snmpTsmUnknownPrefixes, | snmpTsmUnknownPrefixes, | |||
| snmpTsmInvalidPrefixes, | snmpTsmInvalidPrefixes, | |||
| snmpTsmConfigurationUsePrefix | snmpTsmConfigurationUsePrefix | |||
| Client side tests | Client side tests | |||
| o verify each object can be queried | o verify each object can be queried | |||
| o verify that snmpTsmConfigurationUsePrefix is writable | o verify that snmpTsmConfigurationUsePrefix is writable | |||
| Exceptions | Exceptions | |||
| o Both existing implementations of RFC 5953 chose to always | o Both existing implementations of RFC 5953 chose to always | |||
| negotiate authPriv sessions and did not implement the optional | negotiate authPriv sessions and did not implement the optional | |||
| mapping of TLS algorithms to SNMP security levels. This made it | mapping of TLS algorithms to SNMP security levels. This made it | |||
| impossible to send an authPriv message over a transport with an | impossible to send an authPriv message over a transport with an | |||
| inadequate security level. Net-SNMP plans on implementing | inadequate security level. Net-SNMP plans on implementing | |||
| mapping in a future release, and SNMP Research has indicated | mapping in a future release, and SNMP Research has indicated | |||
| that it will implement it given sufficient customer demand. | that it will implement it given sufficient customer demand. | |||
| Untestable Requirements | Untestable Requirements | |||
| - 3.1.2. tmStateReference | - 3.1.2. tmStateReference | |||
| For the Transport Security Model, the security parameters used | For the Transport Security Model, the security parameters used | |||
| for a response MUST be the same as those used for the | for a response MUST be the same as those used for the | |||
| corresponding request. | corresponding request. | |||
| - 3.1.3. Prefixes and securityNames | - 3.1.3. Prefixes and securityNames | |||
| If snmpTsmConfigurationUsePrefix is set to true, then all | If snmpTsmConfigurationUsePrefix is set to true, then all | |||
| securityNames provided by, or provided to, the Transport | securityNames provided by, or provided to, the Transport | |||
| Security Model MUST include a valid transport domain prefix. | Security Model MUST include a valid transport domain prefix. | |||
| If snmpTsmConfigurationUsePrefix is set to false, then all | If snmpTsmConfigurationUsePrefix is set to false, then all | |||
| securityNames provided by, or provided to, the Transport | securityNames provided by, or provided to, the Transport | |||
| Security Model MUST NOT include a transport domain prefix. | Security Model MUST NOT include a transport domain prefix. | |||
| - 8. Security Considerations | - 8. Security Considerations | |||
| This Security Model SHOULD always be used with Transport Models | This Security Model SHOULD always be used with Transport Models | |||
| that provide adequate security, but "adequate security" is a | that provide adequate security, but "adequate security" is a | |||
| configuration and/or run-time decision of the operator or | configuration and/or run-time decision of the operator or | |||
| management application. | management application. | |||
| 7. RFC 5591 Report (MG-SOFT - Net-SNMP) | 7. RFC 5591 Report (MG-SOFT - Net-SNMP / SNMP Research) | |||
| Summary | Summary | |||
| MG-SOFT Micro MIB Browser utilizing MG-SOFT's own WinSNMP API | ||||
| version 8.0.500, as a command generator application, has been | ||||
| tested against Net-SNMP release 5.6, as a command responder | ||||
| application. These two independent implementations have | ||||
| successfully communicated using TSM and so passed the basic | ||||
| interoperability tests. | ||||
| MG-SOFT WinSNMP API is utilizing the most recent openSSL library | MG-SOFT's SNMP management utility built on top of MG-SOFT's | |||
| (as of these tests, version 1.0.0d) for supporting the | WinSNMP API version 8.0.500 (www.mg-soft.com), acting as a | |||
| underlying TLS and DTLS functionality. | command generator application, has been successfully tested over | |||
| the Internet against two other command responder applications: | ||||
| Net-SNMP provides a publicly accessible test SNMP agent | 1. Net-SNMP release 5.6 (www.net-snmp.org) | |||
| (test.net-snmp.org). Testing has been performed with X.509 | 2. SNMP Research agent (www.snmp.com) | |||
| certificates signed by a trusted certificate authority. Both TLS | ||||
| and DTLS transport domain have been tested. The SNMP Get and | With both of these two independent implementations we have | |||
| Get-Next operations have been tested. In all tests the authPriv | successfully passed the interoperability tests. Both the TLS | |||
| session has been successfully negotiated. MG-SOFT implementation | and the DTLS transport domain have been tested. The SNMP Get and | |||
| does not implement optional mapping between TLS algorithms and | Get-Next operations have been tested. | |||
| SNMP security levels. | ||||
| 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 | ||||
| underlying TLS and DTLS functionality. | ||||
| MG-SOFT's developers believe that RFC 5591 is clear and exact | MG-SOFT's developers believe that RFC 5591 is clear and exact | |||
| enough to allow a successful implementation. | enough to allow a successful implementation. | |||
| Tested Requirements | Tested Requirements | |||
| - 2.3.1 Coexistence with Message Processing Models | - 2.3.1 Coexistence with Message Processing Models | |||
| Coexistence with SNMPv1 and SNMPv2c message processing models | Coexistence with SNMPv1 and SNMPv2c message processing models | |||
| has been successfully tested in the command generator | has been successfully tested in the command generator role. The | |||
| role. The MG-SOFT Micro MIB Browser application has been | MG-SOFT SNMP management utility application has been | |||
| successfully performing SNMP operation against different SNMP | successfully performing SNMP operation against different SNMP | |||
| agents by using SNMPv1, SNMPv2c and SNMPv3-USM over unencrypted | agents by using SNMPv1, SNMPv2c and SNMPv3-USM over unencrypted | |||
| UDP (SNMP agents in MG-SOFT lab) and SNMPv3-TSM over TSLTM | UDP (SNMP agents in MG-SOFT lab) and SNMPv3-TSM over TSLTM | |||
| (Net-SNMP's publicly accessible test SNMP agent). | (Net-SNMP's and SNMP Research's publicly accessible test SNMP | |||
| agent). | ||||
| Coexistence with SNMPv3-USM security model has been successfully | - 2.3.2 Coexistence with Other Security Models | |||
| tested in the command generator role. The MG-SOFT Micro MIB | ||||
| Browser application has been successfully performing SNMP | Coexistence with the SNMPv3-USM security model has been | |||
| operation against different SNMP agents by using SNMPv3-USM over | successfully tested in the command generator role. The MG-SOFT | |||
| unencrypted UDP (SNMP agents in MG-SOFT lab) and SNMPv3-TSM over | SNMP management utility application has been successfully | |||
| TSLTM (Net- SNMP's publicly accessible test SNMP agent). | 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 | - 8. Security Considerations | |||
| Usage of TSM without TLSTM is disabled in MG-SOFT's WinSNMP API, | 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 | so it can not be used with a transport model without adequate | |||
| security. | security. | |||
| Untested Requirements | Untested Requirements | |||
| - 2.3.3 Coexistence with Transport Models | - 2.3.3 Coexistence with Transport Models | |||
| skipping to change at page 14, line 46 ¶ | skipping to change at page 15, line 31 ¶ | |||
| The Net-SNMP project has deployed a publicly available test | The Net-SNMP project has deployed a publicly available test | |||
| server to allow for continued interoperability testing with new | server to allow for continued interoperability testing with new | |||
| or existing implementations. | or existing implementations. | |||
| Methodology | Methodology | |||
| Each implementation provided remote access to running command | Each implementation provided remote access to running command | |||
| responders and trap receivers, and tested the other | responders and trap receivers, and tested the other | |||
| implementation using their own command generators. In addition | implementation using their own command generators. In addition | |||
| to basic object comparisons, stimulus/reponse testing was | to basic object comparisons, stimulus/response testing was | |||
| conducted. | conducted. | |||
| Exceptions | Exceptions | |||
| Both existing implementations of RFC 5953 chose to always | Both existing implementations of RFC 5953 chose to always | |||
| negotiate authPriv sessions and did not implement the optional | negotiate authPriv sessions and did not implement the optional | |||
| mapping of TLS algorithms to SNMP security levels. This made it | mapping of TLS algorithms to SNMP security levels. This made it | |||
| impossible to test sending an authPriv message over a transport | impossible to test sending an authPriv message over a transport | |||
| with an inadequate security level. (Net-SNMP plans to add | with an inadequate security level. (Net-SNMP plans to add | |||
| security level mapping in a future release, and SNMP Research | security level mapping in a future release, and SNMP Research | |||
| indicates that they will implement the feature if there is | indicates that they will implement the feature if there is | |||
| sufficient customer demand.) | sufficient customer demand.) | |||
| Implementations that do choose to implement mapping of TLS | Implementations that do choose to implement mapping of TLS | |||
| skipping to change at page 16, line 11 ¶ | skipping to change at page 16, line 43 ¶ | |||
| It may be helpful to add text clarifying that the security level | It may be helpful to add text clarifying that the security level | |||
| associated with a (D)TLS session is only used for ensuring that | associated with a (D)TLS session is only used for ensuring that | |||
| a session has sufficient security for a packet. The security | a session has sufficient security for a packet. The security | |||
| level in outgoing/incoming packets continue to function per the | level in outgoing/incoming packets continue to function per the | |||
| SNMPv3 standard. In other words, the security level in outgoing | SNMPv3 standard. In other words, the security level in outgoing | |||
| packets is not modified to match the security level of the | packets is not modified to match the security level of the | |||
| session, and response packets copy the security level from the | session, and response packets copy the security level from the | |||
| original packet. | original packet. | |||
| 9. RFC 5953 Report (MG-SOFT - Net-SNMP) | 9. RFC 5953 Report (MG-SOFT - Net-SNMP / SNMP Research) | |||
| Summary | Summary | |||
| MG-SOFT Micro MIB Browser utilizing MG-SOFT's own WinSNMP API | MG-SOFT's SNMP management utility built on top of MG-SOFT's | |||
| version 8.0.500, as a command generator application, has been | WinSNMP API version 8.0.500 (www.mg-soft.com), acting as a | |||
| tested against Net-SNMP release 5.6, as a command responder | command generator application, has been successfully tested over | |||
| application. These two independent implementations have | 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 | successfully communicated using TLSTM and so passed the basic | |||
| interoperability tests. | 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 WinSNMP API is utilizing the most recent openSSL library | MG-SOFT provided for interoperability testing purposes a | |||
| (as of these tests, version 1.0.0d) for supporting the | publicly accessible SNMP agent that acts as command responder | |||
| underlying TLS and DTLS functionality. | 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. | ||||
| Net-SNMP provides a publicly accessible test SNMP agent | In all cases, testing has been performed with 'interoperability | |||
| (test.net-snmp.org). Testing has been performed with X.509 | test' command-generator.crt and command-receiver.crt X.509 | |||
| certificates signed by a trusted certificate authority. Both TLS | certificates as they were generated and prepared by the Net-SNMP | |||
| and DTLS transport domain have been been tested. The SNMP Get | team. | |||
| and Get-Next operations have been tested. In all tests the | ||||
| authPriv session has been negotiated. MG-SOFT implementation | MG-SOFT's WinSNMP API is utilizing the most recent openSSL | |||
| does not implement optional mapping between TLS algorithms and | library (as of these tests, version 1.0.0d) for supporting the | |||
| SNMP security levels. | underlying TLS and DTLS functionality. | |||
| MG-SOFT's developers believe that RFC 5953 is clear and exact | MG-SOFT's developers believe that RFC 5953 is clear and exact | |||
| enough to allow a successful implementation. | enough to allow a successful implementation. | |||
| Tested Requirements | Tested Requirements | |||
| - 3.1.2 Message Protection | - 3.1.2 Message Protection | |||
| In all tests the authPriv session has been negotiated. MG-SOFT's | In all tests the authPriv session has been negotiated. MG-SOFT's | |||
| implementation does not implement the optional mapping of TLS | implementation does not implement the optional mapping of TLS | |||
| skipping to change at page 18, line 39 ¶ | skipping to change at page 19, line 35 ¶ | |||
| The interoperability testing did not identify any security issues | The interoperability testing did not identify any security issues | |||
| that are not covered in the security considerations of the relevant | that are not covered in the security considerations of the relevant | |||
| specifications. | specifications. | |||
| 11. IANA Considerations | 11. IANA Considerations | |||
| This document has no IANA actions. | This document has no IANA actions. | |||
| 12. Informative References | 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. | ||||
| [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 | [RFC5343] Schoenwaelder, J., "Simple Network Management Protocol | |||
| (SNMP) Context EngineID Discovery", RFC 5343, | (SNMP) Context EngineID Discovery", RFC 5343, | |||
| September 2008. | September 2008. | |||
| [RFC5590] Harrington, D. and J. Schoenwaelder, "Transport Subsystem | [RFC5590] Harrington, D. and J. Schoenwaelder, "Transport Subsystem | |||
| for the Simple Network Management Protocol (SNMP)", | for the Simple Network Management Protocol (SNMP)", | |||
| RFC 5590, June 2009. | RFC 5590, June 2009. | |||
| [RFC5591] Harrington, D. and W. Hardaker, "Transport Security Model | [RFC5591] Harrington, D. and W. Hardaker, "Transport Security Model | |||
| for the Simple Network Management Protocol (SNMP)", | for the Simple Network Management Protocol (SNMP)", | |||
| End of changes. 56 change blocks. | ||||
| 159 lines changed or deleted | 246 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||