NETWORK WORKING GROUP N. Williams Internet-Draft Sun Expires: August 26, 2006 February 22, 2006 IPsec Channels: Connection Latching draft-ietf-btns-connection-latching-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 August 26, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document specifies, abstractly, how to interface applications and transport protocols with IPsec so as to create "channels" by "latching" connections to certain IPsec Security Association (SA) parameters for their lifetime. This can be used to protect applications against accidental reconfiguration of IPsec that might expose live packet flows to unintended peers, such as might happen with Better Than Nothing Security (BTNS). Latched connections represent IPsec channels, and as such, allow for channel binding to IPsec. Williams Expires August 26, 2006 [Page 1] Internet-Draft IPsec Connection Latching February 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Conventions used in this document . . . . . . . . . . . . . . 3 2. Connection Latching . . . . . . . . . . . . . . . . . . . . . 4 3. Security Considerations . . . . . . . . . . . . . . . . . . . 6 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 5. Normative . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . 8 Intellectual Property and Copyright Statements . . . . . . . 9 Williams Expires August 26, 2006 [Page 2] Internet-Draft IPsec Connection Latching February 2006 1. Introduction IPsec protects packets with little or no regard for stateful packet flows associated with upper layer protocols (ULPs). This limits the usefulness of application interfaces to IPsec and exposes applications that rely on IPsec for session protection to risks associated with changing IPsec configurations and weak association of peers and their addresses. 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 BTNS [I-D.ietf-btns-prob-and-applic] [BTNS]. The method outlined below achieves this by interfacing ULPs and applications to IPsec and using these interfaces to bind ("latch") connections to certain IPsec 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 August 26, 2006 [Page 3] Internet-Draft IPsec Connection Latching February 2006 2. Connection Latching Applications 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 provided that Peer Authentication Database (PAD) entries exist to authenticate peers. 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 sent/received protected by IPsec. 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. This requires certain logical 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. o That ULPs be able to request that IPsec protect outgoing packets, including specific SA parameters. Williams Expires August 26, 2006 [Page 4] Internet-Draft IPsec Connection Latching February 2006 The set of SA parameters that applications may wish to latch connections to, and which ULPs MUST allow latching to, includes, but is not limited to: o Type of protection: confidentiality and/or integrity protection (e.g., ESP vs. AH). o Quality of protection (e.g., algorithms and key sizes, replay protection). o Encapsulation. 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 ID types values, and, where nodes are authenticated using public keys, the local node and remote peer public key values and signature or encryption algorithm identifiers. ULPs MUST allow applications to specify all SA parameters other than node/peer ID types and values. ULPs MAY allow applications to specify peer ID types and values. This method of connection latching works generally for both, connection-oriented ULPs (e.g., TCP), and connection-less ULPs (UDP). It also works for ULPs that support multi-homing (e.g., SCTP), provided that a node has the same ID for all of its addresses that may be referenced by an SCTP connection and that its peers' PAD configurations reflect this. For connection-less ULPs connection latching requires keeping a virtual connection (e.g., as in connected UDP sockets in the BSD sockets API). However, it is not necessarily the case that existing application interfaces to connection-less ULPs can support implicit connection latching. This method of connection latching also works generally with key exchange protocols, such as IKEv1 [RFC2409] and IKEv2 [RFC4306], as well as manual SA keying, and with a variety of peer authentication mechanisms (e.g., pre-shared keys, certified public keys, etc...). It does not work for multi-casting however. Inability to establish an SA with parameters that match a connection latch is akin to inability to communicate with the peer; normal ULP timeout handling and considerations apply. Williams Expires August 26, 2006 [Page 5] Internet-Draft IPsec Connection Latching February 2006 3. 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. Williams Expires August 26, 2006 [Page 6] Internet-Draft IPsec Connection Latching February 2006 4. IANA Considerations There are not IANA considerations for this document. 5. Normative [BTNS] Williams, N., "Better-Than-Nothing-Security: An Unauthenticated Mode of IPsec", draft-btns-btns-00.txt (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-00 (work in progress), July 2005. [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. Williams Expires August 26, 2006 [Page 7] Internet-Draft IPsec Connection Latching February 2006 Author's Address Nicolas Williams Sun Microsystems 5300 Riata Trace Ct Austin, TX 78727 US Email: Nicolas.Williams@sun.com Williams Expires August 26, 2006 [Page 8] Internet-Draft IPsec Connection Latching February 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. Williams Expires August 26, 2006 [Page 9]