NMRG D. Harrington Internet-Draft Independent Expires: April 19, 2005 J. Schoenwaelder International University Bremen October 19, 2004 Transport Layer Security Model (TLSM) for the Simple Network Management Protocol version 3 (SNMPv3) draft-schoenw-snmp-tlsm-00.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with RFC 3668. 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 April 19, 2005. Copyright Notice Copyright (C) The Internet Society (2004). Abstract This document describes the Transport Layer Security Model (TLSM) for the Simple Network Management Protocol (SNMP) version 3 for use in the SNMP architecture. At this stage, this document does not provide a complete solution - it rather identifies and discusses some key aspects that need discussion and future work. Harrington & Schoenwaelder Expires April 19, 2005 [Page 1] Internet-Draft SNMPv3 Transport Layer Security Model October 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. TLS/TCP and DTLS/UDP . . . . . . . . . . . . . . . . . . . . . 4 4. SASL Authentication for SNMP . . . . . . . . . . . . . . . . . 4 5. Architectural Considerations . . . . . . . . . . . . . . . . . 5 5.1 An Architecture Extension for Transport Security Models . 5 5.1.1 Cached Security Data . . . . . . . . . . . . . . . . . 6 5.2 TLS Transport Security Model . . . . . . . . . . . . . . . 7 5.2.1 TLS Cached Security Data . . . . . . . . . . . . . . . 8 5.3 Message Processing Model for TLS Security . . . . . . . . 8 5.4 MP Security Model for TLS Security . . . . . . . . . . . . 9 5.5 MIB Module for TLS Security . . . . . . . . . . . . . . . 9 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.1 Normative References . . . . . . . . . . . . . . . . . . . . 9 7.2 Informative References . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . . 11 Harrington & Schoenwaelder Expires April 19, 2005 [Page 2] Internet-Draft SNMPv3 Transport Layer Security Model October 2004 1. Introduction The standard SNMPv3 protocol [RFC3410] supports the User-based Security Model (USM) as defined [RFC3414]. The USM security model was designed to work with any transports and to be independent of other existing security infrastructures. USM therefore requires a separate user and key management infrastructure. Operators have reported that deploying another user and key management infrastructure in order to use SNMPv3 is a reason for not deploying SNMPv3 at this point in time. This document proposes to introduce a Transport Layer Security Model (TLSM) as an extension of the SNMPv3 architecture which allows security to be provided by an SNMP transport system. Such a TLSM would then enable to use existing security mechanism such as (TLS) [RFC2246], Kerberos [RFC1510] or SASL [RFC2222] within the SNMPv3 architecture. This document provides the motivation for leveraging transport layer security mechanisms for secure SNMP communication, identifies some key issues and provides some proposals for design choices that may be made to provide a workable solution that meets operational requirements and fits into the SNMP architecture defined in [RFC3411] 2. Motivation There are a number of Internet security protocols and mechanisms that are in wide spread use. Many of them try provide a generic infrastructure to be used by many different application layer protocols. The motivation of behind TSLM is to leverage these protocols where it seems useful. The key challenge to be solved is to map the security provided by a secure transport into the SNMP architecture so that SNMP continues to work without any surprises. Transport layer security protocols SHOULD ideally provide the protection against the following threads [RFC3411]: 1. modification of information 2. masquerade 3. message stream modification 4. disclosure Accoring to [RFC3411], it is not required to protect against denial of service or traffic analysis. For SNMP access control to function properly, the security mechanism must establish a securityName, which is the security model independent identifier for a principal, and a securityLevel. The Harrington & Schoenwaelder Expires April 19, 2005 [Page 3] Internet-Draft SNMPv3 Transport Layer Security Model October 2004 SNMP architecture distinguishes between no authentication and no privacy (noAuthNoPriv), authentication without privacy (authNoPriv) and authentication with privacy (authPriv). Hence, the authentication of a securityName plays an important role and must be considered by any transport layer security mechanism. 3. TLS/TCP and DTLS/UDP SNMP supports multiple transports. The preferred transport for SNMP over IP is UDP [RFC3417]. An experimental transport for SNMP over TCP is defined in [RFC3430]. Transport Layer Security (TLS) [RFC2246] traditionally requires a connection-oriented transport and is usually used over TCP. Datagram Transport Layer Security (DTLS) [DTLS] provides security services equivalent to TLS for connection-less transports such as UDP. [D]TLS provides all the security services needed from an SNMP architectural point of view. Although it is possible to derive a securityName from the public key certificates (e.g. the subject field), this approach requires to install certificates on agents and as well as managers, leading to a certificate management problem which again does not integrate well with established AAA systems. Another option is to run an authentication exchange which is integrated with TLS, such as Secure Remote Password with TLS [SRP-TLS]. A similar option would be to use Kerberos authentication with TLS as defined in [RFC2712]. It is important to stress that the authentication exchange must be integrated into the TLS mechanism to prevent man-in-the-middle attacks. While SASL [RFC2222] is often used on top of a TLS encrypted channel to authenticate users, this choice seems to be problematic until the mechanism to cryptographically bind SASL into the TLS mechanism has been defined. TODO: Need to discuss to what extend DTLS is a reasonable choice for SNMP interactions. TODO: What is the status of the work to cryptographically bind SASL to [D]TLS? TODO: More details need to be worked out... 4. SASL Authentication for SNMP The Simple Authentication and Security Layer (SASL) [RFC2222] provides a hook for authentication and security mechanisms to be used Harrington & Schoenwaelder Expires April 19, 2005 [Page 4] Internet-Draft SNMPv3 Transport Layer Security Model October 2004 in application protocols. SASL supports a number of authentication and security mechanisms, among them Kerberos via the GSSAPI mechanism. TODO: More details need to be worked out ... 5. Architectural Considerations The SNMP management framework has a well defined modular architecture [RFC 3411] to allow the evolution of the SNMP protocol standards over time. This architecture provides a Security Subsystem which is responsible for realizing security services. Transport layer security is by its very nature a security layer which is plugged in between the transport layer and an application protocol. Hence, it is important to describe how transport security fits into the SNMP architecture. 5.1 An Architecture Extension for Transport Security Models Transport security protocols will be called from the Transport Mapping portion of an SNMP engine. This proposed architecture extension is meant to serve as a template for others who wish to connect transport security models to the SNMPv3 administrative architecture. The transport mapping provides only some aspects of security. Transport mapping security may provide privacy and data integrity and authentication and authorization policy retrievals, or some subset of these features, but, as with USM, the messaging model includes a security model which ties various security models for the same principal to a securityName which can be used for subsequent processing. These two separate security models will be referred to here as a TM-security model and a MP-security model. This document proposed a solution illustrated by the following diagram, which is a modified version of the diagram taken from the SNMP architecture document. TODO: Insert drawing here... The RFC3411 architecture has no ASI parameters for passing security information between the transport mapping and the dispatcher, and between the dispatcher and the message processing model. Since the TM-security model and MP-security model are co-resident within an implementation, it is assumed there is a trust relationship that exists within the implementation. There are three approaches that could be used for passing information between the TM-securitymodel and the MP-security model. Harrington & Schoenwaelder Expires April 19, 2005 [Page 5] Internet-Draft SNMPv3 Transport Layer Security Model October 2004 RFC3411 discusses the purpose, and an explicit non-purpose, of the ASI approach: "This modularity of specification is not meant to be interpreted as imposing any specific requirements on implementation." The ISMS WG should discuss which is the preferred approach to use in the specification, although the ASI is not an API, and following the ASI is not required for interoperability, so implementors are really free to use any method they choose. A cache mechanism could be used, in which the TM-security model puts information about the security applied to an incoming message, and an MP-security model extracts that information from the cache. The cache is not passed in the ASI. Given that there may be multiple TM-security caches, a cache-ID probably needs to be passed in the message in the ASI so the MP-security model knows which cache to consult. This approach would be consistent with the securityStateReference cache already being passed around in the ASI. The cache could be thought of as an additional parameter in the ASI. The ASI would not need to be changed since the designers expected that additional parameters could be passed for value-add features of specific implementations. Alternatively, a header could encapsulate the SNMP message to pass necessary information from the TM-security model to the dispatcher and then to the MP-security model. The message header would be included in the wholeMessage ASI parameter, and would be removed by a corresponding messaging model. This would imply a new messaging model would need to be specified as well. The other approaches may be able to use the standard SNMPv3 messaging model, with a new MP-security model. 5.1.1 Cached Security Data From RFC3411: "For each message received, the Security Model caches the state information such that a Response message can be generated using the same security information, even if the Local Configuration Datastore is altered between the time of the incoming request and the outgoing response. A Message Processing Model has the responsibility for explicitly releasing the cached data if such data is no longer needed. To enable this, an abstract securityStateReference data element is passed from the Security Model to the Message Processing Model. The cached security data may be implicitly released via the generation of a response, or explicitly released by using the stateRelease primitive, as described in section 4.5.1." The cache may need to contain the following information: Harrington & Schoenwaelder Expires April 19, 2005 [Page 6] Internet-Draft SNMPv3 Transport Layer Security Model October 2004 securityStateReference - a unique identifier for the saved information transportDomain transportAddress TM-securityModel - an indicator of which mechanisms were used TM-securityName - a model-specific identifier of the security principal TM-securityLevel - an indicator of which security services were provide by the transport security model The following are determined by the Message Processing Model: msgID, contextEngineID contextName securityModel securityName securityLevel reportableFlag 5.2 TLS Transport Security Model DTLS has been proposed as a UDP-based TLS. In the following discussion of the architectural requirements, the term TLS is used, but DTLS is implied as well. Assuming TLS and DTLS provide comparable security, the choice should have little impact on SNMP architectural considerations. TLS will create an association between the transport mapping of one SNMP entity and the transport mapping of another SNMP entity. The tunnel may provide encryption and data integrity. Both encryption and data integrity are optional features in TLS. The TLS TM-security model MUST specify that the TLS Handshake Protocol provide authentication if auth is requested in the SecurityLevel of the SNMP message request (RFC3412 4.1.1). The authentication SHOULD be mutual authentication. The TLS TM-security model MUST specify that the messages be encrypted if priv is requested in the SecurityLevel parameter of the SNMP message request (RFC3412 4.1.1). More details are provided below. The transport mapping establishes the private tunnel without passing anything to the SNMP dispatcher. After the tunnel is established, then SNMP messages can be sent through the tunnel to the dispatcher. SNMP messages sent through the tunnel are decrypted by the TLS security model and presented unencrypted to the SNMP dispatcher. Given this, flags in the SNMPv3 message header could be manipulated by the TLS security model if necessary, but my tendency is to try to leave these alone and favor wrapping the normal SNMPv3 message in a Harrington & Schoenwaelder Expires April 19, 2005 [Page 7] Internet-Draft SNMPv3 Transport Layer Security Model October 2004 transport-security-model header, thus requiring a new messaging model document as well. Once the tunnel is established, multiple SNMP messages can be passed through the same tunnel. 5.2.1 TLS Cached Security Data Upon establishment of a TLS/DTLS session, the TM-security model will cache the state information. A securityStateReference that is unique within the SNMP entity will be stored in the cache, and passed to the corresponding MP-security model, to enable lookup. The MP security model will pass the securityStateReference to the Message Processing Model for memory management. securityStateReference - a unique identifier for the saved information transportDomain transportAddress. TM-securityModel - an indicator of which mechanisms were used TM-securityName - a model-specific identifier of the security principal TM-securityLevel - an indicator of which security services were provided by the transport security model For notifications, if the cache has been released and then session closed, then the MP-security model will request the TM-security model to establish a session, populate the cache, and pass the securityStateReference to the MP-security model. TODO: We need to determine what state needs to be saved here. 5.3 Message Processing Model for TLS Security Messages should be handled identically to the RFC3412 procedures. Are there any differences other than the MP-security model processing? ReportPDU should be identical, so discovery is the same. a new security model enumeration is needed Harrington & Schoenwaelder Expires April 19, 2005 [Page 8] Internet-Draft SNMPv3 Transport Layer Security Model October 2004 5.4 MP Security Model for TLS Security Document what comes from the state passed in from the TM-security model. Document how the mapping from model-specific principal to the model-independent securityName is handled. 5.5 MIB Module for TLS Security Each security model should use its own mib module, rather than utilizing the USM MIB, to eliminate dependencies on a model that could be replaced some day. See RFC3411 section 4.1.1. The TLS mib module needs to provide the mapping from model-specific identity to a model-independent securityName. TODO: Module needs to be worked out once things become stable... 6. Acknowledgments The authors would like to thank Ira McDonald, Ken Hornstein, Nagendra Modadugu, for their comments and suggestions. 7. References 7.1 Normative 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. [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. [RFC3417] Presuhn (Editor), R., "Transport Mappings for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3417, December 2002. [RFC3430] Schoenwaelder, J., "Simple Network Management Protocol (SNMP) over Transmission Control Protocol (TCP) Transport Mapping", RFC 3430, December 2002. [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. Harrington & Schoenwaelder Expires April 19, 2005 [Page 9] Internet-Draft SNMPv3 Transport Layer Security Model October 2004 [RFC1510] Kohl, J. and B. Neuman, "The Kerberos Network Authentication Service (V5)", RFC 1510, September 1993. [RFC2222] Myers, J., "Simple Authentication and Security Layer (SASL)", STD 62, RFC RFC2222, October 1997. [DTLS] Rescola, E. and N. Modadugu, "Datagram Transport Layer Security", ID draft-rescorla-dtls-01.txt, July 2004. 7.2 Informative References [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002. [RFC2712] Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher Suites to Transport Layer Security (TLS)", RFC 2712, October 1999. [SRP-TLS] Taylor, D., Wu, T., Mavroyanopoulos, M. and T. Perrin, "Using SRP for TLS Authentication", ID draft-ietf-tls-srp-08.txt, August 2004. Authors' Addresses David Harrington Independent Harding Rd Portsmouth NH USA Phone: +1 603 436 8634 EMail: dbharrington@comcast.net Juergen Schoenwaelder International University Bremen Campus Ring 1 28725 Bremen Germany Phone: +49 421 200-3587 EMail: j.schoenwaelder@iu-bremen.de Harrington & Schoenwaelder Expires April 19, 2005 [Page 10] Internet-Draft SNMPv3 Transport Layer Security Model October 2004 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 (2004). 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. Harrington & Schoenwaelder Expires April 19, 2005 [Page 11]