IP Security Policy M. Richardson Internet-Draft SSW Expires: August 30, 2007 B. Sommerfeld Sun February 26, 2007 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 (C) 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 Richardson & Sommerfeld Expires August 30, 2007 [Page 1] Internet-Draft IPsec API requirements February 2007 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 . . . . . . . . . . . . . . . . . . . . . . . 5 7. HOW . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 8. WHO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 8.1. OPAQUE IDENTITY . . . . . . . . . . . . . . . . . . . . . . 6 8.2. AUDITING . . . . . . . . . . . . . . . . . . . . . . . . . . 6 8.3. ACCESS CONTROL . . . . . . . . . . . . . . . . . . . . . . . 6 9. Error reporting . . . . . . . . . . . . . . . . . . . . . . 6 10. Security Guarantees . . . . . . . . . . . . . . . . . . . . 7 10.1. Connection-oriented communication . . . . . . . . . . . . . 7 10.2. Connectionless communication . . . . . . . . . . . . . . . . 7 11. Non-goals And Bad Ideas . . . . . . . . . . . . . . . . . . 8 11.1. Exposure of keys . . . . . . . . . . . . . . . . . . . . . . 8 11.2. Exposure of IPsec SPI values . . . . . . . . . . . . . . . . 8 12. Other issues . . . . . . . . . . . . . . . . . . . . . . . . 9 13. Security Considerations . . . . . . . . . . . . . . . . . . 9 14. Document TODO . . . . . . . . . . . . . . . . . . . . . . . 9 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 15.1. Normative References . . . . . . . . . . . . . . . . . . . . 9 15.2. Informative References . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . 12 Richardson & Sommerfeld Expires August 30, 2007 [Page 2] Internet-Draft IPsec API requirements February 2007 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]). 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] 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 [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 Richardson & Sommerfeld Expires August 30, 2007 [Page 3] Internet-Draft IPsec API requirements February 2007 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 [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. Richardson & Sommerfeld Expires August 30, 2007 [Page 4] Internet-Draft IPsec API requirements February 2007 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 Richardson & Sommerfeld Expires August 30, 2007 [Page 5] Internet-Draft IPsec API requirements February 2007 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 Richardson & Sommerfeld Expires August 30, 2007 [Page 6] Internet-Draft IPsec API requirements February 2007 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] 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 [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 Richardson & Sommerfeld Expires August 30, 2007 [Page 7] Internet-Draft IPsec API requirements February 2007 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. Richardson & Sommerfeld Expires August 30, 2007 [Page 8] Internet-Draft IPsec API requirements February 2007 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 [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] Richardson & Sommerfeld Expires August 30, 2007 [Page 9] Internet-Draft IPsec API requirements February 2007 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. [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. [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. Authors' Addresses Michael C. Richardson Sandelman Software Works Richardson & Sommerfeld Expires August 30, 2007 [Page 10] Internet-Draft IPsec API requirements February 2007 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 August 30, 2007 [Page 11] Internet-Draft IPsec API requirements February 2007 Full Copyright Statement Copyright (C) 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). Richardson & Sommerfeld Expires August 30, 2007 [Page 12]