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 © The IETF Trust (2007).
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.
Motivation for this work
3. Motivations for this work
6. System policy
8.1. OPAQUE IDENTITY
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.1. Normative References
15.2. Informative References
§ Authors' Addresses
§ Intellectual Property and Copyright Statements
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.
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:
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.
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")
Separate policy and mechanism
Here are some basic requirements for an IPsec application API:
Interactions with system policy:
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.
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:
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.
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().
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.
There are a number of reasons why a communication may fail because of IPsec configuration mismatches..
These include, but are not limited to:
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.
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.
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.
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.
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.
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.
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:
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.
There are a number of other issues that an API must resolve:
|[I-D.ietf-btns-connection-latching]||Williams, N., “IPsec Channels: Connection Latching,” draft-ietf-btns-connection-latching-00 (work in progress), February 2006.|
|[I-D.ietf-btns-core]||Williams, N., “Better-Than-Nothing-Security: An Unauthenticated Mode of IPsec,” draft-ietf-btns-core-00 (work in progress), February 2006.|
|[I-D.ietf-btns-prob-and-applic]||Touch, J., “Problem and Applicability Statement for Better Than Nothing Security (BTNS),” draft-ietf-btns-prob-and-applic-03 (work in progress), June 2006.|
|[I-D.ietf-kitten-gssapi-channel-bindings]||Williams, N., “Clarifications and Extensions to the GSS-API for the Use of Channel Bindings,” draft-ietf-kitten-gssapi-channel-bindings-01 (work in progress), October 2005.|
|[I-D.ietf-nfsv4-channel-bindings]||Williams, N., “On the Use of Channel Bindings to Secure Channels,” draft-ietf-nfsv4-channel-bindings-03 (work in progress), February 2005.|
|[RFC2407]||Piper, D., “The Internet IP Security Domain of Interpretation for ISAKMP,” RFC 2407, November 1998 (HTML, XML).|
|[RFC2408]||Maughan, D., Schneider, M., and M. Schertler, “Internet Security Association and Key Management Protocol (ISAKMP),” RFC 2408, November 1998 (HTML, XML).|
|[RFC2409]||Harkins, D. and D. Carrel, “The Internet Key Exchange (IKE),” RFC 2409, November 1998 (HTML, XML).|
|[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.|
|[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 (HTML, XML).|
|[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.|
|Michael C. Richardson|
|Sandelman Software Works|
|470 Dawson Avenue|
|Ottawa, ON K1Z 5V7|
|1 Network Drive|
|Burlington, MA 01803|
|Phone:||+1 781 442 3458|
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.
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 firstname.lastname@example.org.
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).