Network Working Group K. Narayan Internet-Draft Cisco Systems Expires: January 9, 2006 E. Lear Cisco Systems GmbH J. Salowey Cisco Systems July 8, 2005 A BEEP Profile for SNMPv3 PDUs draft-kaushik-tsms-beep-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 9, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract The Transport Mapping Security Model (TSMS) describes a framework to provide a security for SNMPv3 by an underlying transport protocol. This document leverages the TMSM framework and describes the use of the Block Extensible Exchange Protocol (BEEP) for securing SNMPv3. This specification describes BEEP Transport Mapping Security Model. This document specifies the use of BEEP combined with SASL and TLS as transport for SNMP requests and responses. We define a URI and specify a BEEP profile to be used. Narayan et al. Expires January 9, 2006 [Page 1] Internet-Draft BEEP-TSMS July 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Design Considerations . . . . . . . . . . . . . . . . . . 3 2. The BEEP Transport Mapping . . . . . . . . . . . . . . . . . . 3 2.1 Session Establishment . . . . . . . . . . . . . . . . . . 3 2.2 Greeting(s) . . . . . . . . . . . . . . . . . . . . . . . 4 2.3 SASL . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.4 SNMP Channel Initiation . . . . . . . . . . . . . . . . . 4 2.5 Use of the SNMP channel . . . . . . . . . . . . . . . . . 5 2.6 SNMP Notifications . . . . . . . . . . . . . . . . . . . . 5 2.7 Authentication Model . . . . . . . . . . . . . . . . . . . 5 3. Identities used for authentication . . . . . . . . . . . . . . 6 4. BEEP Transport Mapping Security Model . . . . . . . . . . . . 7 4.1 TSMS Security Protocol Requirements . . . . . . . . . . . . 7 4.2 Passing Parameters between TMSP and MPSP . . . . . . . . . 7 5. Re-use of BEEP substrate . . . . . . . . . . . . . . . . . . . 7 5.1 Considerations for Substrate Re-use . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 8.1 Normative References . . . . . . . . . . . . . . . . . . . 8 8.2 Informational References . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 9 A. BEEP Profile for SNMP . . . . . . . . . . . . . . . . . . . . 9 Intellectual Property and Copyright Statements . . . . . . . . 10 Narayan et al. Expires January 9, 2006 [Page 2] Internet-Draft BEEP-TSMS July 2005 1. Introduction The current SNMPv3 security model USM does not integrate well with other authentication and access controls on devices.[8]. 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 NATs in order to properly process requests. The TSMS framework allows the use of a transport protocol such as TLS, D-TLS etc. to provide integration with authentication systems such as RADIUS, X.509 certificates, Local Accounts etc. This document describes a BEEP Transport Mapping Security Model that enables the use of BEEP as the transport protocol for SNMPv3, the considerations for BEEP to be used as a TSMS protocol are described below. 1.1 Design Considerations There are several substantial benefits for 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] Network management opeations typically happens via a variety of managament protocols (NetConf, SNMP, Syslog) and in quite a few cases involves more than one management protocol as part of the same operation.Even if all management protocols were able to use common authentication systems, it solves only part of the problem. Each of these protocols will require independent authentication transactions which may involve the same principal and credentials to be authenticated repeatedly. The use of BEEP will potentially allow a single BEEP session for all management protocols and will require only one authentication transaction. BEEP is ideal as a transport protocol for peer to peer communication model, which is similar to the one described for SNMP in RFC3411 [7], 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. Narayan et al. Expires January 9, 2006 [Page 3] Internet-Draft BEEP-TSMS July 2005 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: 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 Narayan et al. Expires January 9, 2006 [Page 4] Internet-Draft BEEP-TSMS July 2005 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: 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 [TBD] 2.7 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. Narayan et al. Expires January 9, 2006 [Page 5] Internet-Draft BEEP-TSMS July 2005 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 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 implement MUST have to deal with mapping 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. Narayan et al. Expires January 9, 2006 [Page 6] Internet-Draft BEEP-TSMS July 2005 4. BEEP Transport Mapping Security Model 4.1. TSMS Security Protocol Requirements Section 3.1.1 of [TSMS] specifies the requirements for a protocol to be used part of the TSMS framework. This section we look at whether BEEP meets those requirements 1. BEEP was designed for the purpose it's use is being described in this document. The primary objective of BEEP is provide a framework to build application layer protocols. 2. BEEP requires no changes to work as part of the TSMS framework. BEEP allows various protocol bindings to be described as BEEP profiles and the BEEP profile for SNMP is described in the above sections. 4.2. Passing parameters between TMSP and MPSP [TBD] 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 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.[6] In this example we will look at the NETCONF over BEEP mapping as the other application running on top of the substrate.[9] 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 [10]. 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 [TBD] Narayan et al. Expires January 9, 2006 [Page 7] Internet-Draft BEEP-TSMS July 2005 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] D. Harrington and J. Schoenwaelder, "Transport Mapping Security Model (TMSM) for the Simple Network Management Protocol version 3 (SNMPv3)", draft-schoenw-snmp-tlsm-02.txt (work in progress), November 2005. [6] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 3080, 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. [10] Lear, E. and K. Crozier, "Using the NETCONF Protocol over Blocks Extensible Exchange Protocol (BEEP)", draft-ietf-netconf-beep-03 (work in progress), November 2004. 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. Narayan et al. Expires January 9, 2006 [Page 8] Internet-Draft BEEP-TSMS July 2005 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 2901 3rd Ave Seattle, WA 98121 USA 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??? 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 9, 2006 [Page 9] Internet-Draft BEEP-TSMS 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 9, 2006 [Page 10]