idnits 2.17.1 draft-ietf-btns-connection-latching-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 270. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 247. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 254. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 260. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 22, 2006) is 6637 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'I-D.ietf-btns-prob-and-applic' on line 210 looks like a reference -- Missing reference section? 'BTNS' on line 206 looks like a reference -- Missing reference section? 'RFC2119' on line 216 looks like a reference -- Missing reference section? 'RFC4301' on line 222 looks like a reference -- Missing reference section? 'RFC2409' on line 219 looks like a reference -- Missing reference section? 'RFC4306' on line 225 looks like a reference Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETWORK WORKING GROUP N. Williams 3 Internet-Draft Sun 4 Expires: August 26, 2006 February 22, 2006 6 IPsec Channels: Connection Latching 7 draft-ietf-btns-connection-latching-00.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on August 26, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2006). 38 Abstract 40 This document specifies, abstractly, how to interface applications 41 and transport protocols with IPsec so as to create "channels" by 42 "latching" connections to certain IPsec Security Association (SA) 43 parameters for their lifetime. This can be used to protect 44 applications against accidental reconfiguration of IPsec that might 45 expose live packet flows to unintended peers, such as might happen 46 with Better Than Nothing Security (BTNS). Latched connections 47 represent IPsec channels, and as such, allow for channel binding to 48 IPsec. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.1. Conventions used in this document . . . . . . . . . . . . . . 3 54 2. Connection Latching . . . . . . . . . . . . . . . . . . . . . 4 55 3. Security Considerations . . . . . . . . . . . . . . . . . . . 6 56 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 57 5. Normative . . . . . . . . . . . . . . . . . . . . . . . . . . 7 58 Author's Address . . . . . . . . . . . . . . . . . . . . . . 8 59 Intellectual Property and Copyright Statements . . . . . . . 9 61 1. Introduction 63 IPsec protects packets with little or no regard for stateful packet 64 flows associated with upper layer protocols (ULPs). This limits the 65 usefulness of application interfaces to IPsec and exposes 66 applications that rely on IPsec for session protection to risks 67 associated with changing IPsec configurations and weak association of 68 peers and their addresses. 70 A method is desired for creating "IPsec channels," that is, packet 71 flows predictably protected for their duration, even in the face of 72 IPsec reconfiguration or BTNS [I-D.ietf-btns-prob-and-applic] [BTNS]. 73 The method outlined below achieves this by interfacing ULPs and 74 applications to IPsec and using these interfaces to bind ("latch") 75 connections to certain IPsec SA parameters. 77 1.1. Conventions used in this document 79 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 80 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 81 document are to be interpreted as described in [RFC2119]. 83 2. Connection Latching 85 Applications create latched connections implicitly by creating 86 connections with the ULPs' default latching policy; alternatively, 87 applications MAY request IPsec protection of connections, prior to 88 establishment, even when the Security Policy Database (SPD) would 89 bypass protection provided that Peer Authentication Database (PAD) 90 entries exist to authenticate peers. ULPs MUST default to latching 91 the set of SA parameters given below when applications do not specify 92 any and when a connection's initiating packet is sent/received 93 protected by IPsec. 95 ULPs create latched connections by interfacing with IPsec below as 96 follows: 98 o When the ULP passes a connection's initiating packet to IP the ULP 99 requests feedback about the SA used to protect the outgoing 100 packet, if any. If the application requested IPsec protection, 101 then the ULP passes this request down to IPsec with the initial 102 packet. If the packet is protected by IPsec then the ULP records 103 certain parameters of the SA used to protect it in the 104 connection's transmission control block (TCB). 106 o When a ULP receives a connection's initiating packet it should 107 obtain, from IP/IPsec, information about how the packet was 108 protected; the ULP then records certain parameters of the SA used 109 to protect the incoming packet in the connection's TCB. 111 Once SA parameters are recorded in a connection's TCB the ULP 112 enforces the connection's latch, or binding, to these parameters as 113 follows: 115 o The ULP inspects the SA used to protect input packets and drops 116 packets which are either protected by SAs whose parameters do not 117 match the latched parameters or which are not protected at all. 119 o The ULP always requests that outgoing packets be protected by SAs 120 with the latched parameters. 122 This requires certain logical interfaces between ULPs and the IP/ 123 IPsec layer, namely: 125 o That IPsec be able to pass up to ULPs information about how each 126 incoming packets was protected, if at all, including specific SA 127 parameters. 129 o That ULPs be able to request that IPsec protect outgoing packets, 130 including specific SA parameters. 132 The set of SA parameters that applications may wish to latch 133 connections to, and which ULPs MUST allow latching to, includes, but 134 is not limited to: 136 o Type of protection: confidentiality and/or integrity protection 137 (e.g., ESP vs. AH). 139 o Quality of protection (e.g., algorithms and key sizes, replay 140 protection). 142 o Encapsulation. 144 o Peer identity (i.e., peers' asserted and authorized IDs, as per 145 the IPsec processing model [RFC4301]. This item, in particular, 146 is necessary to protect applications from weak peer ID<->address 147 binding in IPsec configurations. 149 ULPs MUST make available to applications the latched SA parameters, 150 including node/peer ID types values, and, where nodes are 151 authenticated using public keys, the local node and remote peer 152 public key values and signature or encryption algorithm identifiers. 154 ULPs MUST allow applications to specify all SA parameters other than 155 node/peer ID types and values. ULPs MAY allow applications to 156 specify peer ID types and values. 158 This method of connection latching works generally for both, 159 connection-oriented ULPs (e.g., TCP), and connection-less ULPs (UDP). 160 It also works for ULPs that support multi-homing (e.g., SCTP), 161 provided that a node has the same ID for all of its addresses that 162 may be referenced by an SCTP connection and that its peers' PAD 163 configurations reflect this. 165 For connection-less ULPs connection latching requires keeping a 166 virtual connection (e.g., as in connected UDP sockets in the BSD 167 sockets API). However, it is not necessarily the case that existing 168 application interfaces to connection-less ULPs can support implicit 169 connection latching. 171 This method of connection latching also works generally with key 172 exchange protocols, such as IKEv1 [RFC2409] and IKEv2 [RFC4306], as 173 well as manual SA keying, and with a variety of peer authentication 174 mechanisms (e.g., pre-shared keys, certified public keys, etc...). 175 It does not work for multi-casting however. 177 Inability to establish an SA with parameters that match a connection 178 latch is akin to inability to communicate with the peer; normal ULP 179 timeout handling and considerations apply. 181 3. Security Considerations 183 Connection latching protects only individual connections from weak 184 peer ID<->address binding or changing IPsec configurations, but it 185 does not ensure that any two connections with the same end-point 186 addresses, even if one established while the other is alive, will 187 have the same latched peer IDs. In other words, applications that 188 use multiple connections between two given nodes are not protected 189 any more or less by use of IPsec connection latching than by use of 190 IPsec alone. Such multi-connection applications can, however, 191 examine the latched SA parameters of each connection to ensure that 192 each every connection with the same end-point addresses also has the 193 same end-point IPsec IDs. 195 IPsec channels are a pre-requisite for channel binding to IPsec. 196 Connection latching provides such channels, but the process of 197 binding IPsec channels (latched connections) to authentication at 198 application layers is not specified herein. 200 4. IANA Considerations 202 There are not IANA considerations for this document. 204 5. Normative 206 [BTNS] Williams, N., "Better-Than-Nothing-Security: An 207 Unauthenticated Mode of IPsec", draft-btns-btns-00.txt 208 (work in progress), February 2006. 210 [I-D.ietf-btns-prob-and-applic] 211 Touch, J., "Problem and Applicability Statement for Better 212 Than Nothing Security (BTNS)", 213 draft-ietf-btns-prob-and-applic-00 (work in progress), 214 July 2005. 216 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 217 Requirement Levels", BCP 14, RFC 2119, March 1997. 219 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 220 (IKE)", RFC 2409, November 1998. 222 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 223 Internet Protocol", RFC 4301, December 2005. 225 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 226 RFC 4306, December 2005. 228 Author's Address 230 Nicolas Williams 231 Sun Microsystems 232 5300 Riata Trace Ct 233 Austin, TX 78727 234 US 236 Email: Nicolas.Williams@sun.com 238 Intellectual Property Statement 240 The IETF takes no position regarding the validity or scope of any 241 Intellectual Property Rights or other rights that might be claimed to 242 pertain to the implementation or use of the technology described in 243 this document or the extent to which any license under such rights 244 might or might not be available; nor does it represent that it has 245 made any independent effort to identify any such rights. Information 246 on the procedures with respect to rights in RFC documents can be 247 found in BCP 78 and BCP 79. 249 Copies of IPR disclosures made to the IETF Secretariat and any 250 assurances of licenses to be made available, or the result of an 251 attempt made to obtain a general license or permission for the use of 252 such proprietary rights by implementers or users of this 253 specification can be obtained from the IETF on-line IPR repository at 254 http://www.ietf.org/ipr. 256 The IETF invites any interested party to bring to its attention any 257 copyrights, patents or patent applications, or other proprietary 258 rights that may cover technology that may be required to implement 259 this standard. Please address the information to the IETF at 260 ietf-ipr@ietf.org. 262 Disclaimer of Validity 264 This document and the information contained herein are provided on an 265 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 266 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 267 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 268 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 269 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 270 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 272 Copyright Statement 274 Copyright (C) The Internet Society (2006). This document is subject 275 to the rights, licenses and restrictions contained in BCP 78, and 276 except as set forth therein, the authors retain all their rights. 278 Acknowledgment 280 Funding for the RFC Editor function is currently provided by the 281 Internet Society.