NETWORK WORKING GROUP N. Williams Internet-Draft Sun Expires: September 1, 2007 February 28, 2007 IPsec Channels: Connection Latching draft-ietf-btns-connection-latching-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 September 1, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Williams Expires September 1, 2007 [Page 1] Internet-Draft IPsec Connection Latching February 2007 Abstract This document specifies, abstractly, how to interface applications and transport protocols with IPsec so as to create "channels" by "latching" "connections" (packet flows) to certain IPsec Security Association (SA) parameters for their lifetime. This can be used to protect applications against accidentally exposing live packet flows to unintended peers, whether as the result of a reconfiguration of IPsec or as the result of using weak peer identity to peer address associations. Weak association of peer ID and peer addresses is at the core of Better Than Nothing Security (BTNS), thus connection latching can add a significant measure of protection to BTNS IPsec nodes. Latched connections also represent IPsec channels, a building block for channel binding to IPsec; channel binding adds an additional level of protection to applications using BTNS IPsec, and IPsec in general. Williams Expires September 1, 2007 [Page 2] Internet-Draft IPsec Connection Latching February 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Conventions used in this document . . . . . . . . . . . . . 4 2. Connection Latching . . . . . . . . . . . . . . . . . . . . 5 2.1. Using Intimate Interfaces Between ULPs and IPsec . . . . . . 6 2.2. Latching through PAD manipulations (and extensions) . . . . 7 3. BYPASS OR PROTECT . . . . . . . . . . . . . . . . . . . . . 9 4. Security Considerations . . . . . . . . . . . . . . . . . . 10 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 11 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.1. Normative References . . . . . . . . . . . . . . . . . . . . 12 6.2. Informative References . . . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . 14 Williams Expires September 1, 2007 [Page 3] Internet-Draft IPsec Connection Latching February 2007 1. Introduction IPsec protects packets with little or no regard for stateful packet flows associated with upper layer protocols (ULPs). This exposes applications that rely on IPsec for session protection to risks associated with changing IPsec configurations and/or weak association of peer IDs and their addresses. The latter can occur as a result of "wildcard" matching inthe IPsec Peer Authorization Database (PAD), particularly when BTNS [I-D.ietf-btns-prob-and-applic] is used. A method is desired for creating "IPsec channels," that is, packet flows predictably protected for their duration, even in the face of IPsec reconfiguration or weak association of peer IDs and addresses. The methods outlined below achieve this by interfacing ULPs and applications to IPsec and using these interfaces to bind ("latch") connections to peer IDs and SA parameters. 1.1. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Williams Expires September 1, 2007 [Page 4] Internet-Draft IPsec Connection Latching February 2007 2. Connection Latching Applications can create latched connections implicitly by creating connections with the ULPs' default latching policy; alternatively, applications MAY request IPsec protection of connections, prior to establishment, even when the Security Policy Database (SPD) would bypass protection. ULPs MUST default to latching the set of SA parameters given below when applications do not specify any and when a connection's initiating packet is protected by IPsec. Latches are created when "connections" (packet flows) are established. These may be connections in the TCP sense, but they may also be logical (to an application) UDP "connections." The set of SA parameters that applications may wish to latch connections to includes: o Type of protection: confidentiality and/or integrity protection (e.g., ESP vs. AH, ESP algorithms). o Quality of protection (e.g., algorithms and key sizes, replay protection). o Transport mode vs. end-to-end tunnel mode. o Peer identity (i.e., peers' asserted and authorized IDs, as per the IPsec processing model [RFC4301]. This item, in particular, is necessary to protect applications from weak peer ID<->address binding in IPsec configurations. ULPs MUST make available to applications the latched SA parameters, including node/peer IDs and associated authentication information (e.g., certificates, trust anchors, etcetera). ULPs MUST allow applications to specify all SA parameters listed above other than node/peer ID types and values. ULPs MAY allow applications to specify peer ID. Inability to establish an SA with parameters that match a connection latch is akin to inability to communicate with the peer; normal ULP or application timeout handling and considerations apply. The following two sub-sections are informative; they describe possible implementation designs for connection latching. One method works by interfacing IPsec and ULPs "natively," that is, as packets move up and down the stack. The other works by interfacing ULPs and IPsec through the key exchange protocol and the PAD. Both methods should work with any IPsec Key Exchange (KE) protocol, such as IKE Williams Expires September 1, 2007 [Page 5] Internet-Draft IPsec Connection Latching February 2007 [RFC2409] or IKEv2 [RFC4306], though the method in Section 2.2 is described in terms of the new Security Architecture for the Internet Protocol [RFC4301]. Both methods should also work for connection- oriented and connection-less transport protocols, though in the latter case it APIs are required that support a notion of connections when the transport protocol does not. 2.1. Using Intimate Interfaces Between ULPs and IPsec In this section we describe connection latching in terms of intimate interfaces between ULPs and IPsec. This section is INFORMATIVE. ULPs create latched connections by interfacing with IPsec below as follows: o When the ULP passes a connection's initiating packet to IP the ULP requests feedback about the SA used to protect the outgoing packet, if any. If the application requested IPsec protection, then the ULP passes this request down to IPsec with the initial packet. If the packet is protected by IPsec then the ULP records certain parameters of the SA used to protect it in the connection's transmission control block (TCB). o When a ULP receives a connection's initiating packet it should obtain, from IP/IPsec, information about how the packet was protected; the ULP then records certain parameters of the SA used to protect the incoming packet in the connection's TCB. Once SA parameters are recorded in a connection's TCB the ULP enforces the connection's latch, or binding, to these parameters as follows: o The ULP inspects the SA used to protect input packets and drops packets which are either protected by SAs whose parameters do not match the latched parameters or which are not protected at all. o The ULP always requests that outgoing packets be protected by SAs with the latched parameters. All this requires intimate interfaces between ULPs and the IP/IPsec layer, namely: o That IPsec be able to pass up to ULPs information about how each incoming packets was protected, if at all, including specific SA parameters. Williams Expires September 1, 2007 [Page 6] Internet-Draft IPsec Connection Latching February 2007 o That ULPs be able to request that IPsec protect outgoing packets, including specific SA parameters, and that they get feedback from IPsec. 2.2. Latching through PAD manipulations (and extensions) In this section we describe connection latching in terms ULP queries and manipulations of the IPsec PAD database. This section is INFORMATIVE. We imagine interfaces to the IPsec PAD database: o Create a "template" PAD entry, and insert it into the PAD at an appropriate insertion point, whose child SA traffic selector contraints are exactly those of a specific packet flow (i.e., a five-tuple) such that: if a child SA exists or when one is created whose traffic selectors encompass that packet flow's selectors then the template will be "cloned" such that the clone entry matches only the peer ID of that SA. o Create a template PAD entry, and insert it into the PAD at an appropriate insertion point, whose child SA traffic selector contraints correspond to a local listener (i.e., a three-tuple) such that when a child SA is created with traffic selectors encompassing template entry's then the template PAD entry is cloned such that: if a child SA exists or when one is created whose traffic selectors encompass that packet flow's selectors then the template will be "cloned" such that the clone entry matches only the peer ID of that SA. o Search the PAD for a cloned PAD entry (and associated cloned SPD entries) matching a given packet flow's traffic selectors. o Release a template PAD entry. o Release a cloned PAD entry given the traffic selectors of the packet flow that should have given rise to the clone entry being deleted. This will also release associated cloned SPD entries. Cloned and template PAD entries would have to be inserted ahead of any PAD entries that use wildcards or address/port ranges. It is crucial that once a cloned PAD entry exists no SAs can be created for a different peer whose traffic selectors match or emcopass those of the cloned entry. This can be accomplished by searching the PAD at child SA creation time to look for conflicting cloned PAD entries. Williams Expires September 1, 2007 [Page 7] Internet-Draft IPsec Connection Latching February 2007 ULPs create latched connections by interfacing with IPsec below as follows: o For listening end-points the ULP will create a template PAD entry with the listener's 3-tuple as child SA traffic selector constraints. o When initiating a "connection" the ULP will create a template PAD entry with the packet flow's 5-tuple as child SA traffic selector constraints. o When tearing down a "connection" the ULP will release any cloned PAD entry that matches the connection's 5-tuple. o When tearing down a listener the ULP will release any template PAD entry matching the listener's 3-tuple. Any cloned entries that were created as a result of this template entry are not released. o When a ULP rejects connections or packets for non-existent connections the ULP has to release any cloned PAD entries that may have been created by IPsec processing of the rejected packet. One benefit of this method of connection latching is that it may be possible to implement connection latching in bump-in-the-stack (BITS) IPsec implementations. For example, a network interface may provide ESP/AH offload capabilities and may hold subset of the SAD and the SPDs, but may not support tagging packets with information about the SA used or to be used. In such a case the native interface method of connection latching may not be workable, but this method should be. Note that there is a race condition in this method of connection latching: ULPs may not be able to determine how connection-initiating packets were protected that arrive between the time a connection is closed and the time all associated PAD/SADB state is cleaned up. For this reason ULPs should discard all connection-initiating packets arriving within some time of closing a connection; this time should based on a multiple of the maximum time to flush cloned PAD entries, associated SADB entries and the time it takes for a packet to move up the stack from ESP to the ULP. Williams Expires September 1, 2007 [Page 8] Internet-Draft IPsec Connection Latching February 2007 3. BYPASS OR PROTECT For some applications it may be useful to support both, protected and bypassed connections -- as long as the application knows whether a given connection is protected then it may take appropriate actions with respect to unprotected ones (e.g., require use of an application-layer security framework or mechanism, such as SASL [RFC4322]). The native method of connection latching described in Section 2.1 can be easily adapted to support this concept. But the method for connection latching through PAD extensions would require a similar extension to the SPD: the ability to create template SPD entries to "BYPASS OR PROTECT" such that: when an SA is created for a packet flow that would match such a template SPD entry, then the template entry will be cloned as a PROTECT entry (note: use Populate From Packet (PFP) flags), but until then unprotected packets will be allowed to bypass IPsec protection. BYPASS OR PROTECT SPD entries are particularly useful in the context of IPsec-aware applications that can check for IPsec protection and act accordingly, but they may also be useful in the context of Stand- Alone BTNS (SAB). BYPASS OR PROTECT SPD entries SHOULD only be allowed in the context of SAB or IPsec-aware applications. Williams Expires September 1, 2007 [Page 9] Internet-Draft IPsec Connection Latching February 2007 4. Security Considerations Connection latching protects only individual connections from weak peer ID<->address binding or changing IPsec configurations, but it does not ensure that any two connections with the same end-point addresses, even if one established while the other is alive, will have the same latched peer IDs. In other words, applications that use multiple connections between two given nodes are not protected any more or less by use of IPsec connection latching than by use of IPsec alone. Such multi-connection applications can, however, examine the latched SA parameters of each connection to ensure that each every connection with the same end-point addresses also has the same end-point IPsec IDs. IPsec channels are a pre-requisite for channel binding to IPsec. Connection latching provides such channels, but the process of binding IPsec channels (latched connections) to authentication at application layers is not specified herein. Implementors should beware of potential race conditions in connection latching and defend against them, particularly with respect to connection latch tear down. Connection latching provides marginal security benefits over traditional IPsec without IPsec-specific APIs between applications and ULPs. Such APIs are not described herein. Williams Expires September 1, 2007 [Page 10] Internet-Draft IPsec Connection Latching February 2007 5. IANA Considerations There are not IANA considerations for this document. Williams Expires September 1, 2007 [Page 11] Internet-Draft IPsec Connection Latching February 2007 6. References 6.1. Normative References [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-05 (work in progress), February 2007. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [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. [RFC4322] Richardson, M. and D. Redelmeier, "Opportunistic Encryption using the Internet Key Exchange (IKE)", RFC 4322, December 2005. 6.2. Informative References [I-D.bellovin-useipsec] Bellovin, S., "Guidelines for Mandating the Use of IPsec", draft-bellovin-useipsec-06 (work in progress), February 2007. Williams Expires September 1, 2007 [Page 12] Internet-Draft IPsec Connection Latching February 2007 Author's Address Nicolas Williams Sun Microsystems 5300 Riata Trace Ct Austin, TX 78727 US Email: Nicolas.Williams@sun.com Williams Expires September 1, 2007 [Page 13] Internet-Draft IPsec Connection Latching 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). Williams Expires September 1, 2007 [Page 14]