One document matched: draft-komu-btns-api-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-23 03:32:34 |