IP Security Policy W. Sommerfeld
Internet-Draft Sun Microsystems
Expires: December 16, 2003 June 17, 2003
Requirements for an IPsec API
draft-ietf-ipsp-ipsec-apireq-00
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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 December 16, 2003.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
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.
1. Motivation for this work
Many protocols under development are considering the use of IPsec for
Sommerfeld Expires December 16, 2003 [Page 1]
Internet-Draft IPsec API requirements June 2003
security. Unfortunately, most existing IPsec implementations 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
[2][3][4]).
2. Terminology
The term "socket" will be used here to identify an application-layer
communications endpoint; it does imply any specific API is to be
used. For the purposes of this discussion, a socket may include:
A communications endpoint for a connectionless protocol
One end of an established connection for a connection-oriented
protocol
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. Goals
Separate policy and mechanism
4. Requirements
Here are some basic requirements for an IPsec application API:
An application should be able to determine HOW a communication was
protected (or not).
An application should be able to determine WHO it is talking to.
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.
An application should be able to influence HOW a communication is
Sommerfeld Expires December 16, 2003 [Page 2]
Internet-Draft IPsec API requirements June 2003
protected, subject to override or modification by system policy.
An application should be able to indicate WHO it wishes to talk
to, again subject to override or modification by system policy.
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.,
5. System policy
Interactions with system policy:
System-level policy trumps all
By default, applications should be able to ask for *more*
protection.
Applications wishing *less* protection may need appropriate local
privileges. (example: ike bypass of UDP port 500; DHCP lease
renewals...)
6. 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; perhaps there should be
generic "weak" or "strong" indications instead of specific algorithm
identifiers.
7. 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:
7.1 OPAQUE IDENTITY
It should be possible to determine that two IPsec-protected
Sommerfeld Expires December 16, 2003 [Page 3]
Internet-Draft IPsec API requirements June 2003
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 be able to determine if two identities are
equal.
7.2 AUDITING
It should be possible for an application to construct a log entry
naming the peer.
7.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.
7.4 ATTRIBUTES/CREDENTIALS
[Mission Creep Alert] In many cases, an application is not so much
interested in the peer's name, but rather in some other attribute of
the peer. Exactly where and how to map from long-term keys to these
attributes needs to be nailed down; it may well be that this is best
left as a local issue.
Some of this is probably out of scope for the working group; however,
we should not preclude others from building on this.
8. 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:
Blocked by local or peer SPD.
Local or peer key management protocols cannot establish an SA.
Sommerfeld Expires December 16, 2003 [Page 4]
Internet-Draft IPsec API requirements June 2003
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.
9. 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.
9.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; 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.
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.
9.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
Sommerfeld Expires December 16, 2003 [Page 5]
Internet-Draft IPsec API requirements June 2003
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.
10. 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.
10.1 Exposure of keys
There is absolutely no reason for applications to see the underlying
encryption keys.
10.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.
Since both IKE and IPsec SA's may be short-lived, it is plausible
that:
an application connection or association will outlive any given
IPsec SA.
an application connection or association will outlive any given
IKE SA.
an application connection may be idle for extended periods, during
which time there is no IKE or IPsec SA state between the peers.
It should 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.
11. Other issues
Interface-specific vs. application-specific policy; deal with
this as separate layers of filtering/intersections/etc?
Sommerfeld Expires December 16, 2003 [Page 6]
Internet-Draft IPsec API requirements June 2003
Real-time notifications of both ends that rekey, etc., is having
trouble (highly desirable for VoIP-type applications).
Balancing keeping full certificate handling out of applications
while still providing full access to certificate attributes.
12. Security Considerations
13. Document TODO
Flesh out Other Issues section.
Flesh out Informative References with references to existing
IPsec-related API's
Improve security considerations section.
Normative References
[1] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[2] Piper, D., "The Internet IP Security Domain of Interpretation
for ISAKMP", RFC 2407, November 1998.
[3] Maughan, D., Schneider, M. and M. Schertler, "Internet Security
Association and Key Management Protocol (ISAKMP)", RFC 2408,
November 1998.
[4] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
RFC 2409, November 1998.
Informative References
Author's Address
Bill Sommerfeld
Sun Microsystems
1 Network Drive
UBUR02-212
Burlington, MA 01803
US
Phone: +1 781 442 3458
EMail: sommerfeld@sun.com
Sommerfeld Expires December 16, 2003 [Page 7]
Internet-Draft IPsec API requirements June 2003
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Sommerfeld Expires December 16, 2003 [Page 8]
