Network Working Group K. Narayan Internet-Draft Cisco Systems Expires: January 12, 2006 E. Lear Cisco Systems GmbH J. Salowey Cisco Systems July 11, 2005 A BEEP Profile for SNMPv3 PDUs draft-kaushik-isms-btsm-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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 January 12, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract In response to the need for a security model for SNMP that integrates with other device security models, we specify the use of BEEP combined with SASL and TLS as a transport for SNMP requests and responses. We define a URI and specify a BEEP profile to be used. Narayan, et al. Expires January 12, 2006 [Page 1] Internet-Draft BTSM July 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Authentication Design Considerations . . . . . . . . . . . 3 1.2 Transport Design Decisions . . . . . . . . . . . . . . . . 3 1.3 Choice of BEEP . . . . . . . . . . . . . . . . . . . . . . 4 2. The BEEP Transport Mapping . . . . . . . . . . . . . . . . . . 4 2.1 Session Establishment . . . . . . . . . . . . . . . . . . 4 2.2 Greeting(s) . . . . . . . . . . . . . . . . . . . . . . . 4 2.3 SASL . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.4 SNMP Channel Initiation . . . . . . . . . . . . . . . . . 5 2.5 Use of the SNMP channel . . . . . . . . . . . . . . . . . 6 2.6 SNMP Notifications . . . . . . . . . . . . . . . . . . . . 6 2.7 Passing Security Parameters from SNMPv3 . . . . . . . . . 6 2.8 Authentication Model . . . . . . . . . . . . . . . . . . . 6 3. Identities used for authentication . . . . . . . . . . . . . . 7 4. SNMPv3 Security Model Requirements . . . . . . . . . . . . . . 7 5. Re-use of BEEP substrate . . . . . . . . . . . . . . . . . . . 7 5.1 Considerations for Substrate Re-use . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 8.1 Normative References . . . . . . . . . . . . . . . . . . . 9 8.2 Informational References . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10 A. BEEP Profile for SNMP . . . . . . . . . . . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . . 12 Narayan, et al. Expires January 12, 2006 [Page 2] Internet-Draft BTSM July 2005 1. Introduction [EDITOR NOTE: This is a drafty draft.] The current SNMPv3 security model USM does not integrate well with other authentication and access controls on devices.[9]. For example, it is impossible to integrate USM with RADIUS.[4] In addition, SNMP's UDP transport poses certain limitations, such as the need for application awareness at firewalls and network address translators (NATs) in order to properly process requests. 1.1 Authentication Design Considerations No new authentication mechanism is needed for SNMP. Instead, integration with the existing approaches is appropriate. Hence, an approach that makes use of general authentication mechanisms that can in turn call more specific functions will provide the most flexibility to meeting end user requirements. 1.2 Transport Design Decisions SNMP has traditionally been transported over UDP. There are good reasons for this approach. Because SNMP is a network management protocol, if a network failure occurs it may prove difficult to impossible to establish a TCP connection. In addition, the cost of connection state on both the network element and the network management station has been viewed as concern. For those uses where these concern remains SNMP over UDP remains a viable alternative. However, since the time SNMP was first designed the network architecture has shifted substantially. Two critical components, firewalls and NATs have become prevalent. Both NATs and firewalls make UDP communication anywhere from spotty to impossible, depending on as much implementation as policy, where it would be clearly more desirable for the limitation to be solely based on policy. Because connection state is available for all to inspect, NATs and firewalls have an easy time of determining who initiated a communication and on what port. Hence, a policy decision is easier than it would be in UDP where state must be maintained within the application. Use of transport layer security allows connection state state to remain out in the open, even when the application protocol is encrypted. Finally, many firealls and NATs will allow communiations only in a single direction - outbound from the device being protected or being "NATted", and so a "call-home" function is desirable. Narayan, et al. Expires January 12, 2006 [Page 3] Internet-Draft BTSM July 2005 1.3 Choice of BEEP There are several substantial benefits for Block Extensible Exchange Protocol (BEEP).[5] First, it meets the fundamental need of operators to integrate with existing authentication infrastructure. It can do this through the use of SASL, which can invoke Radius or other centralized password verification mechanisms to authenticate sessions.[2] BEEP uses SASL for authentication and TLS to provide confidentiality and integrity protection.[3] A TCP transport mapping is defined for BEEP.[6]. This combined with its peer to peer approach allows for TCP connections to originate in either direction independently of whether an end plays the role of the manager or the managed element. In addition network management operations typically happen via a variety of managament protocols (e.g., NETCONF, SNMP, SYSLOG) and in The use of BEEP will potentially allow a single BEEP session for all management protocols and will require only one authentication transaction per pair of devices. As mentioned earlier, BEEP is an ideal as a transport protocol for peer to peer communication model, which is similar to the one described for SNMP in RFC3411 [8]. The fact that any peer can initiate a connection simplifies NAT and firewall traversal. 2. The BEEP Transport Mapping All SNMP over BEEP implementations MUST implement the profile and functional mapping between SNMP and BEEP as described below. 2.1 Session Establishment Either device at the end of a BEEP connection may play the role of an initiator. Devices MUST be configured to listen to or connect using a specific BEEP transport connection. Port XXX is assigned for BEEP over SNMP. Alternatively, the SNMP profile may be announced on any BEEP transport connection where the security policies match. 2.2 Greeting(s) After a transport connection is established, as greetings are exchanged, devices SHOULD each announce support for TLS, and optionally SASL. For instance: Narayan, et al. Expires January 12, 2006 [Page 4] Internet-Draft BTSM July 2005 L: RPY 0 0 . 0 110 L: Content-Type: application/beep+xml L: L: L: L: Once greetings are exchanged, if TLS is announced as above, the listener STARTs a channel with the TLS profile. Once TLS has been successfully negotiated a new greeting is sent by both initiator and listener. This new greeting will contain any available SASL profiles along with the SNMP profile, http://iana.org/beep/snmp. 2.3 SASL If SASL profiles are specified, a channel is started by either or both sides with the list of SASL profiles available. An answer is then supplied indicating which profile is to be used for authentication. For examples, see RFC-3080. 2.4 SNMP Channel Initiation Either initiator or listner MAY advertise the SNMP profile. If neither advertises the profile or if the initiator advertises the profile but the listener is not configured to use it or any other profile, the listener should shutdown the BEEP connection (see below) and log an error that indicates that nobody wanted to actually use the BEEP connection for anything. For example: I: MSG 0 1 . 52 116 I: Content-Type: application/beep+xml I: I: I: I: I: END In this case the initiator has started the SNMP channel. If it is successful, the other end will respond with a positive RPY. For example: Narayan, et al. Expires January 12, 2006 [Page 5] Internet-Draft BTSM July 2005 L: RPY 0 1 . 221 83 L: Content-Type: application/beep+xml L: L: L: END Conversely if the channel cannot be created, an ERR response is sent. 2.5 Use of the SNMP channel The SNMP channel is used to transmit complete SNMP PDUs encoded in ASN.1. 2.6 SNMP Notifications 2.7 Passing Security Parameters from SNMPv3 2.8 Authentication Model Authentication will occur at two places. One is where transport layer security such as TLS is provided and the other is at the application layer where a mechanism such as SASL can be used. Both of these mechanisms can support a variety of credentials and both can provide a security layer. In cases where the participants have different types of credentials then it is likely that both will be needed. This specification makes the following recommendations: 1. The TLS channel used to provide channel protection. At the very least the BEEP listener MUST provide an X.509 certificate and each side that side (listener or initiator) MUST have a reliable trust anchor with appropriate policies to handle a network failure. 2. If both parties are authenticated during the TLS conversation then SASL EXTERNAL method is used. 3. If one party is not authenticated during the TLS conversation then an appropriate SASL mechanism is invoked to authenticate the un-authenticated party. It is RECOMMENDED to implement SASL- DIGEST mechanism. Other SASL mechanisms may be supported. SASL PLAIN MAY be used if the back-end authentication mechanism does not support digests AND TLS is used. PLAIN MUST NOT be used if TLS is not used. 4. In some cases it is possible that the side that is accepting the initial connection does not have the credentials to act as a TLS server. The may happen when an SNMP engine is initiating a connection to send a notification and it has public key based credentials and the notification receiver is expected to use Narayan, et al. Expires January 12, 2006 [Page 6] Internet-Draft BTSM July 2005 password based credentials. In this case TLS may be proceed with the connection initiator acting as the TLS server and the connection acceptor acting as TLS client. The capability to act as a TLS server with an entity is advertised through the BEEP channel negotiation. If both sides indicate they can act as a TLS server that the entity accepting the connection assumes the server role. It is expected that Recipient SNMP engines will be authenticated through TLS and must either have a public/private key pair and certificate or share a key with the command generator or notification receiver. Originator SNMP engines will be authenticated through TLS or a SASL mechanism. This allows them to use a wide variety of credentials such as passwords, public key certificates, Kerberos tickets, and shared keys. 3. Identities used for authentication As described in the previous section, the specification deals will authentication at two levels, i.e. authentication of the end points to setup the channel and authentication of the application principal. RFC3411 does have a notion of two separate identities, the SNMP engines are identified by thier engineID, i.e. the snmpEngineID and client principal is identified by the securityName. The SNMP securityName MUST be used in all cases to represent the authenticated name of the client principal but the snmpEngineID may not be used to represent the authenticated name of the SNMP engine. SNMP engine implementations MUST provide a mapping from the authenticated name to an engineID. Recipient SNMP engines may authenticate using a X.509 certificate, the snmpEngineID may be used as the subject Name within the X.509 certificate. In case a different entity is used as subject Name, the Recipient SNMP engines MUST be able to map the authenticated entity to the engineID. Implementations may have this mapping configured as part of SNMPv3 engine configuration. Originator SNMP engines MUST authenticate with the SNMP securityName and the securityName MUST be defined as the subject Name within the X.509 certificate in case of PKI authentication of the client principal. 4. SNMPv3 Security Model Requirements 5. Re-use of BEEP substrate BEEP is designed to allow multiple independent subsystems communicate over a single transport stream. This is appropriate under certain Narayan, et al. Expires January 12, 2006 [Page 7] Internet-Draft BTSM July 2005 circumstances. In those cases where an appropriate transport connection already exists, the SNMP profile is simply announced as part of the greeting by one side of the connection and invoked by the other. 5.1 Considerations for Substrate Re-use We consider the question of whether re-use of a particular substrate is appropriate based on RFC-3205 (BCP-56) Section 3.[7] In this example we will look at the NETCONF over BEEP mapping as the other application running on top of the substrate.[10] The principle question from BCP-56 is this: does addition of one of the two protocols in question represent a substantially new service? The answer is clearly not. We know this because the whole point of SNMP over BEEP with SASL/TLS is to integrate the security model with that of the rest of the administrative model on the device, which is what NETCONF is expected to use. We further know this because the sort of data the protocols are meant to carry are substantially similar. What's more, there are two substantial benefits of combining the two: o Improved network performance and fairness through the use of a shared TCP window as discussed in [11]. This may be a minor or major point, but it's a bit early to say. o Simplified configuration and improved performance on firewalls, and potentially on end devices as well. It's one less port to have to keep track of, and it's one less port check to have to process. For these reasons it is reasonable to consider using SNMP and NETCONF on the same BEEP channel. A similar analysis should be done with other potential applications. For instance, it is unlikely that one would make use of an insecure channel for SNMP, such as what might be found with instant messaging protocols. 6. Security Considerations This BEEP profile marks a departure from USM in several respects. First, the localization algorithm is not used. Instead, authentication occurs through TLS and/or SASL. It is therefore possible and indeed likely that a system will be configured to use a centralized password database. USM prevents compromised of such databases when a network element is compromised. If an attacker has full access to the network element that includes what code is running, such attacks may again be possible. The level of protocol security through the approach in this Narayan, et al. Expires January 12, 2006 [Page 8] Internet-Draft BTSM July 2005 specification is extremely flexible, and is as much a choice of deployment as it is implementation. For instance, MD5-DIGEST can only be used if the back-end store supports it. As of this writing most RADIUS implemetnations do not. So long the underlying transport is encrypted, the risk is limited to an attack on the encryption method, the device, or the radius server itself. 7. IANA Considerations The IANA will assign a TCP port for this specification. The IANA will register "http://iana.org/BEEP/SNMP" as a BEEP profile. 8. References 8.1 Normative References [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [2] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997. [3] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A., and P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [4] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [5] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 3080, March 2001. [6] Rose, M., "Mapping the BEEP Core onto TCP", RFC 3081, March 2001. [7] Moore, K., "On the use of HTTP as a Substrate", BCP 56, RFC 3205, February 2002. [8] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. [9] 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. Narayan, et al. Expires January 12, 2006 [Page 9] Internet-Draft BTSM July 2005 [10] Lear, E. and K. Crozier, "Using the NETCONF Protocol over Blocks Extensible Exchange Protocol (BEEP)", draft-ietf-netconf-beep-05 (work in progress), April 2005. 8.2 Informational References [11] Nielson, H., Gettys, J., Baird-Smith, A., Prud'hommeaux, E., Lee, H., and C. Lilley, "Network performance effects of HTTP/1.1, CSS1, and PNG", Proceedings of the ACM SIGCOMM 1997, October 1997. Authors' Addresses Kaushik Narayan Cisco Systems 170 W. Tasman Dr. San Jose 95134 US Email: kaushik@cisco.com Eliot Lear Cisco Systems GmbH Glatt-com Glattzentrum, ZH CH-8301 Switzerland Phone: +41 1 878 7525 Email: lear@cisco.com Joseph Salowey Cisco Systems 170 W. Tasman Dr. San Jose 95134 US Email: jsalowey@cisco.com Appendix A. BEEP Profile for SNMP Profile Identification: http://iana.org/BEEP/snmp Message Exhanged during Channel Creation: none Messages starting one-to-one exhanges: as defined in RFC341??? Narayan, et al. Expires January 12, 2006 [Page 10] Internet-Draft BTSM July 2005 Messages in positive replies: as defined in RFC341??? Messages in negative replies: none Messages in one-to-many exchanges: none message Semantics: as specified by RFC341X??? Contact: As listed in authors section of this document Narayan, et al. Expires January 12, 2006 [Page 11] Internet-Draft BTSM July 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Narayan, et al. Expires January 12, 2006 [Page 12]