Requirements for an IPsec API
draft-ietf-btns-ipsec-apireq-01.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 August 30, 2007.

Copyright Notice

Copyright © The IETF Trust (2007).

Abstract

Given the open nature of the Internet today, application protocols require strong security. IPsec's wire protocols appear to meet the requirements of many protocols. The lack of a common model for application-layer interfaces has complicated use of IPsec by upper-layer protocols. This document provides an overview of facilities which a host IPsec implementation should provide to applications to allow them to both observe and influence how IPsec protects their communications.

Table of Contents

1.  Motivation for this work
2.  Terminology
3.  Motivations for this work
4.  Goals
5.  Requirements
6.  System policy
7.  HOW
8.  WHO
8.1.  OPAQUE IDENTITY
8.2.  AUDITING
8.3.  ACCESS CONTROL
9.  Error reporting
10.  Security Guarantees
10.1.  Connection-oriented communication
10.2.  Connectionless communication
11.  Non-goals And Bad Ideas
11.1.  Exposure of keys
11.2.  Exposure of IPsec SPI values
12.  Other issues
13.  Security Considerations
14.  Document TODO
15.  References
15.1.  Normative References
15.2.  Informative References
§  Authors' Addresses
§  Intellectual Property and Copyright Statements

1.  Motivation for this work

Many protocols under development are considering the use of IPsec for security. Unfortunately, most existing IPsec implementations ([RFC2401] (Kent, S. and R. Atkinson, “Security Architecture for the Internet Protocol,” November 1998.) and [RFC4301] (Kent, S. and K. Seo, “Security Architecture for the Internet Protocol,” December 2005.)) do not give applications any visibility into what, if anything, they are doing on behalf of an application. This limitation only allows IPsec to do all-or-nothing access control, and requires two levels of authentication, with one within the application, and a second level within an IPsec key management protocol (most typically IKE (Piper, D., “The Internet IP Security Domain of Interpretation for ISAKMP,” November 1998.) [RFC2407][RFC2408] (Maughan, D., Schneider, M., and M. Schertler, “Internet Security Association and Key Management Protocol (ISAKMP),” November 1998.)[RFC2409] (Harkins, D. and D. Carrel, “The Internet Key Exchange (IKE),” November 1998.) and IKEv2 (Kaufman, C., “Internet Key Exchange (IKEv2) Protocol,” December 2005.) [RFC4306][RFC4307] (Schiller, J., “Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2),” December 2005.)).

There are also cases where an application would like to cooperate with the IPsec key management system: the application has a way to authenticate the end-user, and if it can be assured that the IPsec channel extends intact, all the way to the end user, the application would be happy to have the IPsec system handle all privacy and integrity functions. This may also simplify the IPsec authentication case, permitting mechanisms such as BTNS [I‑D.ietf‑btns‑core] (Williams, N., “Better-Than-Nothing-Security: An Unauthenticated Mode of IPsec,” February 2006.) to be used.

2.  Terminology

The term "socket" will be used here to identify an application-layer communications endpoint; it does not imply any specific API is to be used. For the purposes of this discussion, a socket may include:

1. A communications endpoint for a connectionless protocol
2. One end of an established connection for a connection-oriented protocol
3. A listening endpoint for a connection-oriented protocol

For the purposes of this document, the term "application" refers to programs implementing any client protocol using either IP or a transport protocol such as TCP or UDP running over IP. Note that this is in many ways somewhat broader than the traditional use of "application" within the IETF, as it may also include "infrastructure" protocols built on top of IP and IPsec, including routing, ICMP, etc.

3.  Motivations for this work

Most protocols for application security, such as TLS (Dierks, T. and C. Allen, “The TLS Protocol Version 1.0,” January 1999.) [RFC2246] and SSH (Ylonen, T. and C. Lonvick, “The Secure Shell (SSH) Protocol Architecture,” January 2006.) [RFC4251] operate at or above the transport layer. This renders the underlying transport connections vulnerable to denial of service attacks, including connection assassination (Rescorla, E. and B. Korver, “Guidelines for Writing RFC Text on Security Considerations,” July 2003.) [RFC3552]. IPsec offers the promise of protecting against many of these denial of service attacks.

There are other potential benefits. Conventional software-based IPsec implementations isolate applications from the cryptographic keys, improving security by making inadvertant or malicious key exposure more difficult. In addition, specialized hardware may allow encryption keys protected from disclosure within trusted cryptographic units. Also, custom hardware units may well allow for higher performance.

Areas where this is currently under active discussion include the set of block storage protocols being developed by the IP Storage working group (Aboba, B., Tseng, J., Walker, J., Rangan, V., and F. Travostino, “Securing Block Storage Protocols over IP,” April 2004.) [RFC3723] and NFS version 4 (XXX: need newer reference than target="I-D.ietf-nfsv4-ccm")

4.  Goals

Separate policy and mechanism

5.  Requirements

Here are some basic requirements for an IPsec application API:

1. An application SHOULD be able to determine HOW a communication was protected (or not).
2. An application SHOULD be able to determine WHO it is talking to. The most basic version of WHO, is a public key, in it's most basic form.
3. If a communication is nominally authorized but fails, an application should be able to get an indication of WHY it failed, to help identify the configuration error causing the spurious failure. This is also important as the application may be able to notify the end user that this occured, as there may be some middlebox that is preventing establishment of an IPsec connection.
4. An application SHOULD be able to influence HOW a communication is protected, subject to override or modification by system policy. As a part of this, an application MAY be able to ask for specific Quality of Service (QoS) on the resulting IPsec packets. The interface to the QoS system SHOULD be done by the key management system, as it is aware of the details of the resulting packet, and is aware of all rekeys.
5. An application SHOULD be able to indicate WHO it wishes to talk to, again subject to override or modification by system policy. In particular an application SHOULD be able to express a desire to communicate with an end-point that it has previously communicated with in the past.
6. These interfaces SHOULD be as independant as possible of the key management protocol being used; it should be possible to implement this with IKEv1, IKEv2, KINK, etc.,
7. It is desired that the interface be sufficiently abstracted that a non-BSD sockets system can implement the API. Further, an IPsec stack that is a Bump-in-the-Stack implementation SHOULD be supported without extensive modifications to the host kernel.

6.  System policy

Interactions with system policy:

1. System-level policy trumps all
2. By default, applications SHOULD be able to ask for *more* protection.
3. Applications wishing *less* protection may need appropriate local privileges. (example: ike bypass of UDP port 500; DHCP lease renewals...)

7.  HOW

An application may have requirements for confidentiality and/or integrity; it should be able to determine if an inbound communication was protected and whether an outbound communication will be protected.

In addition, there may well be a desire to express preferences for relative strength of algorithms, or specify the specific algorithm to be used.

Hard-coding algorithm names into applications should be actively discouraged; there SHOULD be generic "weak" or "strong" indications instead of specific algorithm identifiers. These identifiers can be mapped by the system to appropriate actual algorithms, and can be adjusted as relative strengths of algorithms become more understood.

8.  WHO

This is perhaps the most tricky part of the problem. Existing IPsec key management protocols provide a wide variety of authentication methods -- preshared secrets, public key, Kerberos, X.509 certificates, etc.,

There are several potential uses for names provided by IPsec:

8.1.  OPAQUE IDENTITY

It should be possible to determine that two IPsec-protected communications conducted within a short to medium time frame were with the same authenticated peer; it should be possible to use a received identity to initiate a communication back to that identity.

Example cases: connectionless replies; linking ftp control and data connections.

The application need only to be able to determine if two identities are equal.

8.2.  AUDITING

It should be possible for an application to construct a log entry naming the peer. This is slightly at odds with the desire to keep the identities OPAQUE. The solution here is to make it clear that two identities may be equivalent, but may not have the same audit string. In the parlance of LISP, the identities may be equal(), but might not be eq().

8.3.  ACCESS CONTROL

While policy rules may allow traffic to be blocked entirely, it's often necessary for a program to provide services to mutually suspicious clients. It should be possible for a service to make appropriate access control decisions based on the identity of the peer; in addition, the peer's certificate may contain interesting SubjectAltName or other attributes which may have relevance for the application; it may also be possible for the system to derive other attributes from the peer's identity.

9.  Error reporting

There are a number of reasons why a communication may fail because of IPsec configuration mismatches..

These include, but are not limited to:

1. Blocked by local or peer SPD.
2. Local or peer key management protocols cannot establish an SA.
3. Local or peer key management protocols cannot authenticate to each other.

It MAY be appropriate to map IPsec failures into existing error codes (e.g., "connection refused", "connection timed out"), so that existing applications use appropriate error recovery strategies; however, this does result in a loss of information. It SHOULD be possible for an IPsec-aware application to get additional information about the reasons that a communications failed.

10.  Security Guarantees

Connection-oriented and connectionless communication often require different application structure. In many case, it will often be most convenient to do security checks once per connection, while for connectionless communications, per-message operations will be needed.

10.1.  Connection-oriented communication

Packet boundaries are not, in general, visible to clients of stream protocols such as TCP, while IPsec protection is provided (or not) on a packet-by-packet basis,

In addition, it would be an unreasonable burden on applications to force them to continuously inquire about each individual packet.

It should be possible for an application to ensure that all traffic to a particular socket is protected appropriately; this is often called [I‑D.ietf‑btns‑connection‑latching] (Williams, N., “IPsec Channels: Connection Latching,” February 2006.) it should also be possible for an application to ensure that all traffic to a socket originates from the same authenticated identity.

A pair of communicating applications should be able to determine that the ipsec protection on a connection between them is end-to-end. This will generally require an interaction between the session layer protocol (such as GSSAPI, or TLS) and the IPsec layer. Linking these two thing together is called channel binding (Williams, N., “On the Use of Channel Bindings to Secure Channels,” February 2005.) [I‑D.ietf‑nfsv4‑channel‑bindings].

Note that it is common for datagram socket API's to allow a "connect" operation which sets a default destination and filters inbound packets based on source address; it should similarly be possible for the connection-oriented security guarantees to be applied to datagram sockets being used for 1:1 communications.

10.2.  Connectionless communication

It is also common to use datagram sockets for many-to-many communication; it should be possible to get and set identity information on a packet-by-packet basis.

It may well be the case that a datagram-oriented client application will use the connection-oriented part of this API (because it is using a given datagram socket to talk to a specific server) while the server it is talking to use the connectionless API because it is using a single socket to receive requests from and send replies to a large number of clients.

11.  Non-goals And Bad Ideas

Here are a few ideas which have popped up every so often which really seem to be bad ideas.. in other words, things which should not be exposed to applications because they can't be used reliably or which cause active harm.

11.1.  Exposure of keys

There is absolutely no reason for applications to see the underlying encryption keys, or influence the choice of keys. This is to allow an IPsec implementation to have a clear boundary around its cryptographic components.

11.2.  Exposure of IPsec SPI values

In general, there is no need for applications to see SPI values or keys; it's also the case that in many cases the exact algorithm used may not be of interest as long as it is appropriately strong.

An argument can be made that these values are necessary in order to configure appropriate QoS filters, such as via RSVP. Rather than have the application do this the creation of QoS filters should be done by the key management daemon (e.g. IKE), at the request of the application. The communication of the desired QoS is therefore within the purvue of the IPsec API.

Since both IKE and IPsec SA's may be short-lived, it is plausible that:

1. an application connection or association will outlive any given IPsec SA.
2. an application connection or association will outlive any given IKE SA.
3. an application connection may be idle for extended periods, during which time there is no IKE or IPsec SA state between the peers.

It MUST be the case that any properties provided to applications regarding peer identity, protection, etc., should be able to survive rekeying.

It may be appropriate to use SPI values as temporary handles, but applications may last much longer than SA's, and SPI values may be recycled over time; it would be better for there to be a separate, local-use-only, space for (identity, params) pairs.

12.  Other issues

There are a number of other issues that an API must resolve:

1. Interface-specific vs. application-specific policy;
2. Real-time notifications of both ends that rekey, etc., is having trouble. A VoIP application may desire this.
3. A balance must be found between providing full certificate handling to the application, and sufficient access to certificate attributes.

13.  Security Considerations

14.  Document TODO

1. Flesh out Informative References with references to existing IPsec-related API's
2. Improve security considerations section.

15.  References

15.1. Normative References

15.2. Informative References

Authors' Addresses

Full Copyright Statement

Copyright © The IETF Trust (2007).

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, THE IETF TRUST 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 provided by the IETF Administrative Support Activity (IASA).