Better than Nothing Security M. Komu Internet-Draft Helsinki Institute for Information Expires: April 11, 2007 Technology October 8, 2006 IPsec Application Programming Interfaces draft-komu-btns-api-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. This document may not be modified, and derivative works of it may not be created, except to publish it as an RFC and to translate it into languages other than English. 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 11, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract Usually network layer security through IPsec is transparent for applications. Usually, they cannot detect the presence of IPsec or affect its security properties. This document specifies extensions to increase the visibility of IPsec to applications through a low level sockets API. In addition, a higher layer APIs based on GSS is Komu Expires April 11, 2007 [Page 1] Internet-Draft IPsec APIs October 2006 also defined. The GSS based APIs increase security level of the application through the dual use of both transport and network layer security. It can be also used to improve protocol performance by reducing redundant authentications. Komu Expires April 11, 2007 [Page 2] Internet-Draft IPsec APIs October 2006 1. Introduction The network communications of applications are usually secured explicitly with TLS [4] or using even higher layer interfaces such as GSS [3]. However, such interfaces do not exist for IPsec because it operates on lower layers and is mostly transparent for applications. Applying of IPsec to existing applications is therefor easier than with e.g. TLS because IPsec does not require changes in the application. However, it is difficult for the application to detect whether network connections are secured or not using IPsec. In this document, we attempt to increase the visibility of the IPsec layer to the applications by introducing an API to IPsec based applications. The interface is an extension to the standard sockets API [1], similarly as with non-secured network applications. The benefit of this interface is that it does not require completely rewriting the networking part of an existing application as in GSS or TLS. We also introduce an explicit way of enabling IPsec in applications that is based on the GSS API. This API allows the dual use of both IPsec and higher layer security mechanisms simultaneously which the following security and perfomance related benefits (as described in more detail in [11]): o Robust security for application data through the use of dual-layer security mechanisms o Performance optimization and reduced number of authorization configurations by removing unnecessarily redundant security features at different layers Figure Figure 1 illustrates three different applications, one of which uses GSS APIs, second which use the socket based IPsec APIs and a third which relies on transparent IPsec security. Komu Expires April 11, 2007 [Page 3] Internet-Draft IPsec APIs October 2006 +---------------------+--------+-----------+ Appl. Layer | Application #1 | App #2 | App #3 | +------+------+---+---+---+----+----+------+ | | | +------+------+---v---+ | | | SPKM | KERB | IPsec | | | Session +------+------+-------+ | | Security | GSS | | | Layer +---------------------+ | | | TLS etc | | | +----------------+----+ | | | | | +-------------+--v----+---v----+----v------+ Socket Layer | IPv4 APIs | IPsec APIs | IPv6 APIs | +-----------+-+-------------+--+-----------+ Transport Layer | SCTP | TCP | UDP | +-----------+---------------+--------------+ IPsec Layer | IPsec | +--------------------+---------------------+ Network Layer | IPv4 | IPv6 | +--------------------+---------------------+ Link Layer | Ethernet | Etc | +--------------------+---------------------+ Figure 1: Security API Layering This document is an attempt to fulfil the BTNS requirements in [5]. Currently, it contains also some references to other similar work to provide a slightly broader view. Komu Expires April 11, 2007 [Page 4] Internet-Draft IPsec APIs October 2006 2. Sockets Layer API The sockets API IPsec APIs are currently defined in [6]. The defitions consist of three main extensions to the standard sockets API which are summarized in this section briefly. First, IPsec based socket APIs can only be used by an application only when it opens a socket with the protocol family (domain) set to PF_SHIM instead of AF_INET or AF_INET6. The new family enables the following new properties in an application: Protocol independent sockets for applications Detection of IPsec API support on the localhost Enables application to use sockets API based communication interface with key management daemons and possibly IPsec modules. Allows querying of IPsec security properties using getsockopt interface. Setting of security properties is also possible, but should require access privileges verification because it can affect also the communications of other processes. Second, the API proposes an abstraction mechanism that avoids exposing IPv4 and IPv6 addresses directly to the applications. Instead, application identifier is a "handle" (socket descriptor) which refers the actual transport layer identifier. The socket descriptors can used through the standard hostname-to-address resolver interface [2] with the use of a special flag. When the flag is set in the resolver arguments, the resolver returns socket address structures specific to socket descriptors instead of IPv4 or IPv6 socket structures. Some of the possible use cases for the socket descriptor abstraction mechanism are listed below: When transport layer identifiers are public keys, they may not fit into socket address structures. The constant-size socket descriptor is a convinient replacement for the public key. System access control mechanism for user specific identifiers (such as private keys) may be easier to implement using the socket descriptors as they resemble file descriptors May ease the implementation of various security and mobility features to protocols, such as opportunistic HIP mode [9], and maybe SHIM6 context forking [10]. Isolates transport layer identifier changes from applications for future extensions. Might also benefit multicast APIs Komu Expires April 11, 2007 [Page 5] Internet-Draft IPsec APIs October 2006 Third, applications are allowed to listen for events reported by the key and mobility management daemons. The event interface is similar as in SCTP [8] that operates events through the sendmsg/recvmsg interfaces [2]. These interfaces allow sending and receiving regular networking data in an datagram oriented way, but also facilitate the use of ancillary data. For example, application can register to listen for events that are related to locator changes. The notification to the application arrives in a sendmsg/recvmsg call. The application can differentiate a notification from regular network data by examining a flag in the message structures. Please refer to [7] for a more detailed description of this. Komu Expires April 11, 2007 [Page 6] Internet-Draft IPsec APIs October 2006 3. Session Layer API The GSS API for IPsec can make use the IPsec sockets API as depicted in figure Figure 1. The exact definitions are still TBD. Komu Expires April 11, 2007 [Page 7] Internet-Draft IPsec APIs October 2006 4. IANA Considerations TBD Komu Expires April 11, 2007 [Page 8] Internet-Draft IPsec APIs October 2006 5. Security Considerations TBD Komu Expires April 11, 2007 [Page 9] Internet-Draft IPsec APIs October 2006 6. Acknowledgements Thanks for Michael Richardson and Love Hoernquist Aestrand for discussion on the topic. Komu Expires April 11, 2007 [Page 10] Internet-Draft IPsec APIs October 2006 7. References 7.1. Normative References [1] Institute of Electrical and Electronics Engineers, "IEEE Std. 1003.1-2001 Standard for Information Technology - Portable Operating System Interface (POSIX)", Dec 2001. [2] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. Stevens, "Basic Socket Interface Extensions for IPv6", RFC 3493, February 2003. [3] Linn, J., "Generic Security Service Application Program Interface Version 2, Update 1", RFC 2743, January 2000. [4] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006. 7.2. Informative References [5] Richardson, M. and B. Sommerfeld, "Requirements for an IPsec API", draft-ietf-btns-ipsec-apireq-00 (work in progress), April 2006. [6] Komu, M., "Native Application Programming Interfaces for SHIM Layer Prococols", draft-komu-shim-native-api-00 (work in progress), June 2006. [7] Komu, M., "Socket Application Program Interface (API) for Multihoming Shim", draft-sugimoto-multihome-shim-api-00 (work in progress), June 2006. [8] Stewart, R., "Sockets API Extensions for Stream Control Transmission Protocol (SCTP)", draft-ietf-tsvwg-sctpsocket-13 (work in progress), June 2006. [9] Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-base-06 (work in progress), June 2006. [10] Bagnulo, M. and E. Nordmark, "Level 3 multihoming shim protocol", draft-ietf-shim6-proto-05 (work in progress), May 2006. [11] Touch, J., "Problem and Applicability Statement for Better Than Nothing Security (BTNS)", draft-ietf-btns-prob-and-applic-04 (work in progress), September 2006. Komu Expires April 11, 2007 [Page 11] Internet-Draft IPsec APIs October 2006 Author's Address Miika Komu Helsinki Institute for Information Technology Tammasaarenkatu 3 Helsinki Finland Phone: +358503841531 Fax: +35896949768 Email: miika@iki.fi URI: http://www.iki.fi/miika/ Komu Expires April 11, 2007 [Page 12] Internet-Draft IPsec APIs October 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). 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. 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. Intellectual Property 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Komu Expires April 11, 2007 [Page 13]