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]