Internet DRAFT - draft-ietf-btns-ipsec-apireq
draft-ietf-btns-ipsec-apireq
IP Security Policy M. Richardson
Internet-Draft SSW
Expires: October 15, 2006 B. Sommerfeld
Sun
April 13, 2006
Requirements for an IPsec API
draft-ietf-btns-ipsec-apireq-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.
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 October 15, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
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
Richardson & Sommerfeld Expires October 15, 2006 [Page 1]
Internet-Draft IPsec API requirements April 2006
communications.
Table of Contents
1. Motivation for this work . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Motivations for this work . . . . . . . . . . . . . . . . . 3
4. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4
6. System policy . . . . . . . . . . . . . . . . . . . . . . . 4
7. HOW . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
8. WHO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
8.1. OPAQUE IDENTITY . . . . . . . . . . . . . . . . . . . . . . 5
8.2. AUDITING . . . . . . . . . . . . . . . . . . . . . . . . . . 5
8.3. ACCESS CONTROL . . . . . . . . . . . . . . . . . . . . . . . 5
8.4. ATTRIBUTES/CREDENTIALS . . . . . . . . . . . . . . . . . . . 5
9. Error reporting . . . . . . . . . . . . . . . . . . . . . . 6
10. Security Guarantees . . . . . . . . . . . . . . . . . . . . 6
10.1. Connection-oriented communication . . . . . . . . . . . . . 6
10.2. Connectionless communication . . . . . . . . . . . . . . . . 7
11. Non-goals And Bad Ideas . . . . . . . . . . . . . . . . . . 7
11.1. Exposure of keys . . . . . . . . . . . . . . . . . . . . . . 7
11.2. Exposure of IPsec SPI values . . . . . . . . . . . . . . . . 7
12. Other issues . . . . . . . . . . . . . . . . . . . . . . . . 8
13. Security Considerations . . . . . . . . . . . . . . . . . . 8
14. Document TODO . . . . . . . . . . . . . . . . . . . . . . . 8
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
15.1. Normative References . . . . . . . . . . . . . . . . . . . . 8
15.2. Informative References . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . 11
Richardson & Sommerfeld Expires October 15, 2006 [Page 2]
Internet-Draft IPsec API requirements April 2006
1. Motivation for this work
Many protocols under development are considering the use of IPsec for
security. Unfortunately, most existing IPsec implementations
([RFC2401] and [RFC4301]) 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 [RFC2407][RFC2408][RFC2409] and IKEv2
[RFC4306][RFC4307]).
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. Motivations for this work
Most protocols for application security, such as TLS [RFC2246] and
SSH [RFC4251] operate at or above the transport layer. This renders
the underlying transport connections vulnerable to denial of service
attacks, including connection assassination [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.
Richardson & Sommerfeld Expires October 15, 2006 [Page 3]
Internet-Draft IPsec API requirements April 2006
Areas where this is currently under active discussion include the set
of block storage protocols being developed by the IP Storage working
group [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:
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
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.,
6. 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...)
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
Richardson & Sommerfeld Expires October 15, 2006 [Page 4]
Internet-Draft IPsec API requirements April 2006
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.
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 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.
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.
8.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
Richardson & Sommerfeld Expires October 15, 2006 [Page 5]
Internet-Draft IPsec API requirements April 2006
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.
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:
Blocked by local or peer SPD.
Local or peer key management protocols cannot establish an SA.
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; it should also be
possible for an application to ensure that all traffic to a socket
originates from the same authenticated identity.
Richardson & Sommerfeld Expires October 15, 2006 [Page 6]
Internet-Draft IPsec API requirements April 2006
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.
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.
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
Richardson & Sommerfeld Expires October 15, 2006 [Page 7]
Internet-Draft IPsec API requirements April 2006
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.
12. Other issues
Interface-specific vs. application-specific policy; deal with this
as separate layers of filtering/intersections/etc?
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.
13. Security Considerations
14. Document TODO
Flesh out Other Issues section.
Flesh out Informative References with references to existing
IPsec-related API's
Improve security considerations section.
15. References
15.1. Normative References
[RFC2407] Piper, D., "The Internet IP Security Domain of
Interpretation for ISAKMP", RFC 2407, November 1998.
[RFC2408] Maughan, D., Schneider, M., and M. Schertler, "Internet
Security Association and Key Management Protocol
(ISAKMP)", RFC 2408, November 1998.
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
Richardson & Sommerfeld Expires October 15, 2006 [Page 8]
Internet-Draft IPsec API requirements April 2006
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005.
[RFC4307] Schiller, J., "Cryptographic Algorithms for Use in the
Internet Key Exchange Version 2 (IKEv2)", RFC 4307,
December 2005.
15.2. Informative References
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552,
July 2003.
[RFC3723] Aboba, B., Tseng, J., Walker, J., Rangan, V., and F.
Travostino, "Securing Block Storage Protocols over IP",
RFC 3723, April 2004.
[RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
Protocol Architecture", RFC 4251, January 2006.
Richardson & Sommerfeld Expires October 15, 2006 [Page 9]
Internet-Draft IPsec API requirements April 2006
Authors' Addresses
Michael C. Richardson
Sandelman Software Works
470 Dawson Avenue
Ottawa, ON K1Z 5V7
CA
Email: mcr@sandelman.ottawa.on.ca
URI: http://www.sandelman.ottawa.on.ca/
Bill Sommerfeld
Sun Microsystems
1 Network Drive
Burlington, MA 01803
US
Phone: +1 781 442 3458
Email: somerfeld@sun.com
Richardson & Sommerfeld Expires October 15, 2006 [Page 10]
Internet-Draft IPsec API requirements April 2006
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 (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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Richardson & Sommerfeld Expires October 15, 2006 [Page 11]
