idnits 2.17.1 draft-ietf-btns-connection-latching-03.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, updated by RFC 4748 on line 626. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 637. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 644. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 650. 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 IETF Trust 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 (September 17, 2007) is 6038 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) == Unused Reference: 'RFC4322' is defined on line 586, but no explicit reference was found in the text == Unused Reference: 'I-D.bellovin-useipsec' is defined on line 592, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-ietf-btns-abstract-api-00 -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-btns-abstract-api' == Outdated reference: A later version (-07) exists of draft-ietf-btns-core-05 == Outdated reference: A later version (-07) exists of draft-ietf-btns-prob-and-applic-05 ** Downref: Normative reference to an Informational draft: draft-ietf-btns-prob-and-applic (ref. 'I-D.ietf-btns-prob-and-applic') ** Downref: Normative reference to an Informational RFC: RFC 2367 ** Obsolete normative reference: RFC 4306 (Obsoleted by RFC 5996) ** Downref: Normative reference to an Informational RFC: RFC 4322 == Outdated reference: A later version (-10) exists of draft-bellovin-useipsec-06 Summary: 5 errors (**), 0 flaws (~~), 8 warnings (==), 8 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: March 20, 2008 September 17, 2007 6 IPsec Channels: Connection Latching 7 draft-ietf-btns-connection-latching-03.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 March 20, 2008. 34 Copyright Notice 36 Copyright (C) The IETF Trust (2007). 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" (packet flows) to certain IPsec Security 43 Association (SA) parameters for the lifetime of the connections. 44 This can be used to protect applications against accidentally 45 exposing live packet flows to unintended peers, whether as the result 46 of a reconfiguration of IPsec or as the result of using weak peer 47 identity to peer address associations. 49 Weak association of peer ID and peer addresses is at the core of 50 Better Than Nothing Security (BTNS), thus connection latching can add 51 a significant measure of protection to BTNS IPsec nodes. A model of 52 of connection latching based on a modification to the child SA 53 authorization process is given. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 58 1.1. Conventions used in this document . . . . . . . . . . . . . 4 59 2. Connection Latching . . . . . . . . . . . . . . . . . . . . 5 60 2.1. Normative Model: ULP interfaces to the key manager and 61 child SA authorization process extensions . . . . . . . . . 7 62 2.2. Using Intimate Interfaces Between ULPs and IPsec . . . . . . 10 63 2.3. Non-native mode IPsec . . . . . . . . . . . . . . . . . . . 12 64 2.4. Conflict Resolution . . . . . . . . . . . . . . . . . . . . 12 65 3. Optional protection . . . . . . . . . . . . . . . . . . . . 14 66 4. Security Considerations . . . . . . . . . . . . . . . . . . 15 67 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 16 68 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 69 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 70 7.1. Normative References . . . . . . . . . . . . . . . . . . . . 18 71 7.2. Informative References . . . . . . . . . . . . . . . . . . . 18 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . 19 73 Intellectual Property and Copyright Statements . . . . . . . 20 75 1. Introduction 77 IPsec protects packets with little or no regard for stateful packet 78 flows associated with upper layer protocols (ULPs). This exposes 79 applications that rely on IPsec for session protection to risks 80 associated with changing IPsec configurations, configurations that 81 allow multiple peers access to the same addresses, and/or weak 82 association of peer IDs and their addresses. The latter can occur as 83 a result of "wildcard" matching in the IPsec Peer Authorization 84 Database (PAD), particularly when BTNS 85 [I-D.ietf-btns-prob-and-applic] is used. 87 A method is desired for creating "IPsec channels," that is, packet 88 flows predictably protected for their duration, even in the face of 89 IPsec reconfiguration or weak association of peer IDs and addresses. 90 The methods outlined below achieve this by interfacing ULPs and 91 applications to IPsec and using these interfaces to bind ("latch") 92 connections to peer IDs and SA parameters. 94 1.1. Conventions used in this document 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 98 document are to be interpreted as described in [RFC2119]. 100 2. Connection Latching 102 An "IPsec channel" is a packet flow associated with a ULP control 103 block, such as a TCP connection, where all the packets are protected 104 by IPsec SAs such that: 106 o the peer's identity is the same for the lifetime of the packet 107 flow 109 o the quality of IPsec protection used for the packet flow's 110 individual packets is the same for all of them for the lifetime of 111 the packet flow 113 An IPsec channel is created when the associated packet flow is 114 created. This can be the result of a local operation (e.g., a 115 connect()) that causes the initial outgoing packet for that flow to 116 be sent, or it can be the result of receiving the first/initiating 117 packet for that flow (e.g., a TCP SYN packet). 119 IPsec channels are created by "latching" various parameters listed 120 below to a ULP connection when the connections are created. The 121 REQUIRED set of parameters bound in IPsec channels is: 123 o Type of protection: confidentiality and/or integrity protection; 125 o Transport mode vs. tunnel mode; 127 o Quality of protection: cryptographic algorithm suites, key 128 lengths, and replay protection; 130 o Peer identity: peers' asserted and authorized IDs, as per the 131 IPsec processing model [RFC4301] and BTNS [I-D.ietf-btns-core]. 133 Implementations SHOULD provide applications with APIs for inquiring 134 whether a connection is latched and what the latched parameters are. 135 Implementations SHOULD provide applications with some control, 136 through application programming interfaces (APIs) 137 [I-D.ietf-btns-abstract-api], over what quality of protection, or the 138 expected identity of a peer. If an application does not use such 139 interfaces then it will obtain default quality of protection derived 140 from system policy. Implementations MAY create IPsec channels 141 automatically by default when the application does not request an 142 IPsec channel. 144 IPsec channels have the following states: 146 o Listener 147 o Larval (in the process of being established) 149 o Established 151 o Failed 153 Requirements and recommendations: 155 o If an IPsec channel is desired then packets for a given connection 156 MUST NOT be sent until the channel is established. 158 o If an IPsec channel is desired then inbound packets for a given 159 connection MUST NOT be accepted (they MUST be dropped) until the 160 channel is established. 162 o Once an IPsec channel is established packets for the latched 163 connection MUST NOT be sent unprotected nor protected by an SA 164 that does not match the latched parameters. 166 o Once an IPsec channel is established packets for the latched 167 connection MUST NOT be accepted unprotected nor protected by an SA 168 that does not match the latched parameters (i.e., such packets 169 MUST be dropped). 171 o Native implementations SHOULD provide programming interfaces for 172 inquiring the values of the parameters latched in a connection. 174 o Implementations that provide such programming interfaces MUST make 175 available to applications all relevant information about a peer's 176 ID, including authentication information. This includes the peer 177 certificate, when one is used, and the trust anchor that it was 178 validated to. 180 o Implementations that provide such programming interfaces MUST make 181 available to applications NAT-related information about the peer: 182 whether it is behind a NAT and, if it is, the inner and outer 183 tunnel addresses of the peer. 185 o Native implementations SHOULD provide programming interfaces for 186 setting the values of the parameters to be latched in a connection 187 that will be initiated or accepted, but these interfaces MUST 188 limit what values applications may request according to system 189 policy (i.e., the IPsec PAD and SPD) and the application's 190 privilege. 192 (Typical system policy may not allow applications any freedom 193 here. Policy extensions allowing for optional protection are 194 described in Section 3.) 196 o The parameters latched in an IPsec channel MUST remain unchanged 197 once the channel is established. 199 o Timeouts while establishing an SA with parameters that match a 200 those latched into an IPsec channel MUST be treated as packet loss 201 (as happens, for example, when a network partitions); normal ULP 202 and/or application timeout handling and retransmission 203 considerations apply. Failure to establish an appropriate SA for 204 an IPsec channel MAY be communicated to the ULP and application 205 (e.g., as though the connection had been reset) 207 o Implementations that have a restartable key management process (or 208 "daemon") MUST arrange for existing latched connections to either 209 be reset and disconnected, or for them to survive the restart of 210 key exchange processes. (This is implied by the above 211 requirements.) IPsec state related to connection latches MUST be 212 torn down when latched connections are torn down, even when the 213 latter is implied, such as at crash/halt/reboot time. 215 o Any IPsec channel created with a given peer while another 216 distinct, established IPsec channel exists with the same source 217 and destination addresses SHOULD be bound to the same peer. 219 We describe two models (one normative) of IPsec channels for native 220 IPsec implementations. Both models should suffice for all-software 221 native implementations of IPsec. One, the other or both models 222 should be workable for most native implementations where part of the 223 IPsec stack is implemented in hardware. The normative model is based 224 on abstract programming interfaces between ULPs and the key 225 management component of IPsec, plus a modification to the child SA 226 authorization process. The second model is based on abstract 227 programming interfaces between ULPs and the IPsec (ESP/AH) layer in 228 the IP stack. Both models imply extensions to any PF_KEY-like 229 protocols [RFC2367] that may be used internally by the 230 implementation. 232 We also provide a model for non-native implementations, such as bump- 233 in-the-stack (BITS) and SG implementations. The connection latching 234 model for non-native implementations is not full-featured as it 235 depends on estimating packet flow state, which may not always be 236 possible. Nor can non-native IPsec implementations be expected to 237 provide APIs related to connection latching. As such this third 238 model is not suitable for channel binding applications 239 [I-D.williams-on-channel-binding]. 241 2.1. Normative Model: ULP interfaces to the key manager and child SA 242 authorization process extensions 244 This section is NORMATIVE. 246 In this section we describe connection latching in terms of an 247 interface between ULPs and the key manager component of a native 248 IPsec implementation. Abstract interfaces for creating, inquiring 249 about, and releasing IPsec channels are described. 251 This model adds a service to the IPsec key manager: management of 252 connection latches. 254 The traditional IPsec processing model allows the concurrent 255 existence of SAs with different peers but overlapping traffic 256 selectors. Such behaviour, in this model, directly violates the 257 requirements for connection latching. We address this problem by 258 requiring that either such conflicts be avoided or that connection 259 latches be broken (and holders informed) when such conflicts arise. 261 The ULP interfaces to the IPsec PAD database are as follows: 263 o Create a connection latch listener object for a ULP 3-tuple (local 264 address, protocol and local port number). This operation succeeds 265 whenever there are no other connection latch listeners for the 266 same 3-tuple. Connection latch listener objects can result in 267 connection latch objects when a child SA is created whose traffic 268 selectors encompass the given 3-tuple. 270 o Create a connection latch object for a ULP 5-tuple (local and 271 remote address, protocol and local and remote port numbers). This 272 operation succeeds when no conflicting connection latch objects 273 exist and when there exist no child SAs encompassing the given 274 5-tuple or when all such SAs are with the same peer and equal 275 quality of protection. The key manager SHOULD attempt to create a 276 suitable SA pair if one does not already exist; if it does then it 277 MUST use the 5-tuple as the initial traffic selectors of the 278 proposed child SAs. 280 o Destroy a connection latch listener object. 282 o Destroy a connection latch object. 284 o Inquire whether a connection latch exists for a given 5-tuple, its 285 state, and its latched parameters. 287 The API described above is a new service of the IPsec key manager. 288 In particular the IPsec key manager MUST prevent conflicts between 289 latches and SAs as follows: 291 o connection latches MUST NOT be created if there exist conflicting 292 SAs in the SAD at the time the connection latch is requested or 293 would be created (from a listener latch); 295 o child SA proposals that would conflict with an extant connection 296 latch and whose traffic selectors can be narrowed to avoid the 297 conflict MUST be narrowed (see section 2.9 of [RFC4306]); 299 o where child SA proposals that would conflict with an extant 300 connection latch cannot be narrowed to avoid the conflict the key 301 manager MUST either reject such proposals or it MUST break the 302 connection latch and inform the holder (the ULP) prior to 303 accepting the conflicting SAs. 305 Additionally, the key manager MUST protect latched connections 306 against SPD changes that would change the quality of protection 307 afforded to a latched connection's traffic, or which would bypass it. 308 When such a configuration change takes place the key manager MUST 309 eithe preserve a logical SPD entry such that the latched connection 310 continues to obtain protection, or the key manager MUST inform the 311 latch holder (ULP) that the latch is no longer in force before the 312 change takes place. To do this the key manager can logically update 313 the SPD as if a PROTECT entry had been added at the head of the SPD-S 314 with traffic selectors matching only the latched connection's 315 5-tuple, and with processing information taken from the actual SPD 316 entry matched by the connection (possibly augmented by the 317 application's request for additional protection). Such updates of 318 the SPD MUST NOT survive system crashes or reboots. 320 ULPs create latched connections by interfacing with IPsec below as 321 follows: 323 o For listening end-points the ULP will request a connection latch 324 listener object for the ULP listener's 3-tuple. Any latching 325 parameters requested by the application should be passed along. 327 o When the ULP receives a packet initiating a connection for a 328 5-tuple matching a 3-tuple listener latch, then the ULP will ask 329 the key manager whether a 5-tuple connection latch was created. 330 If not then the ULP will either reject the new connection or 331 accept it and inform the application that the new connection is 332 not latched (that it does not represent an IPsec channel). 334 o When initiating a connection the ULP will request a connection 335 latch object for the connection's 5-tuple. Any latching 336 parameters requested by the application should be passed along. 337 If no latch can be created then the ULP will either return an 338 error to the application or continue with the new connection and 339 inform the application that the new connection is not latched. 341 o When a latched connection is torn down and no further packets are 342 expected for it then the ULP will request that the connection 343 latch object be destroyed. 345 o When tearing down a listener the ULP will request that the 346 connection latch listener object be destroyed. 348 o When a ULP listener rejects connections the ULP will request the 349 destruction of any connection latch objects that may have been 350 created as a result of the peer's attempt to open the connection. 352 o When the key manager informs a ULP that a connection latch is no 353 longer valid then the ULP will reset or otherwise terminate the 354 connection and inform the application. 356 Note that initiating a connection should result in creation of a 357 suitable SA pair in the same manner as described in Section 2.1. 359 The main benefit of this model of connection latching is that it 360 accommodates IPsec implementations where ESP/AH handling is 361 implemented in hardware (for all or a subset of the host's SAD), but 362 where the hardware does not support tagging inbound packets with the 363 indexes of SAD entries corresponding to the SAs that protected them. 365 Note that there is a race condition in this method of connection 366 latching: packets may race with the ULP and the IPsec key manager's 367 manipulation of connection latch objects and SAD entries. As a 368 result ULPs may not be able to trust some packets even though a 369 suitable connection latch object may exist. Implementations MUST 370 prevent such races. One method to prevent these races is to tag 371 packets passed up by the ESP/AH layer with a key manager state 372 version number that is monotonically incremented every time that 373 connection latching state changes; this version number must be 374 incremented atomically relative to the SAD, including SAD subsets 375 stored on IPsec offload hardware. Other methods may be possible, 376 including dropping packets that arrive within a certain amount of 377 time since the creation/destruction of connection latch objects 378 (e.g., if the maximum latency within the key manager and IP stack is 379 known and guaranteed). 381 2.2. Using Intimate Interfaces Between ULPs and IPsec 383 In this section we describe connection latching in terms of 384 interfaces between ULPs and IPsec based on tagging packets as they go 385 up and down the IP stack. 387 This section is INFORMATIVE. 389 The ULPs and IPsec interface through a local packet tagging scheme 390 (the tags don't appear on the wire): 392 o The IPsec layer tags all inbound protected packets addressed to 393 the host with the index of the SAD entry corresponding to the SA 394 that protected the packet. 396 o The IPsec layer understands two types of tags on outbound packets: 398 * a tag specifying a set of latched parameters (peer ID, quality 399 of protection, etc...) that the IPsec layer will use to find or 400 acquire an appropriate SA for protecting the outbound packet 401 (else IPsec will drop the packet; 403 * a tag requesting feedback about the SA used to protect the 404 outgoing packet, if any. 406 ULPs create latched connections by interfacing with IPsec below as 407 follows: 409 o When the ULP passes a connection's initiating packet to IP the ULP 410 requests feedback about the SA used to protect the outgoing 411 packet, if any, and may specify latching parameters requested by 412 the application. If the packet is protected by IPsec then the ULP 413 records certain parameters of the SA used to protect it in the 414 connection's transmission control block (TCB). 416 o When a ULP receives a connection's initiating packet it processes 417 the IPsec tag of the packet, and it records in the connection's 418 TCB the parameters of the SA that should be latched. 420 Once SA parameters are recorded in a connection's TCB the ULP 421 enforces the connection's latch, or binding, to these parameters as 422 follows: 424 o The ULP processes the IPsec tag of all inbound packets for a given 425 connection and checks that the SAs used to protect input packets 426 match the connection latches recorded in the TCBs; packets which 427 are not so protected are dropped. 429 o The ULP always requests that outgoing packets be protected by SAs 430 that match the latched connection by appropriately tagging 431 outbound packets. 433 The receipt of a packet matching a latched connection's 5-tuple, but 434 protected by an SA with an inappropriate peer, should be taken as an 435 indication that the original peer is no longer at the original 436 address and that the connection should be reset, the application 437 informed, and the connection latch removed. 439 The main benefit of this model of connection latching is its 440 simplicity. For example, no changes need be made to the child SA 441 authorization process. However, this model of connection latching is 442 not workable with ESP/AH offload hardware that does not support the 443 packet tagging scheme described above. 445 2.3. Non-native mode IPsec 447 [Fill this out. Basically, for non-native (BITS/BITW/SG, though BITW 448 probably need not apply) implementations, connection latching 449 requires inspecting packets to discern ULP connection state, 450 recording and tracking such state. Like all stateful middle-boxes 451 this suffers from the inability of the middle-box to interact with 452 the applications. For example, connection death may be difficult to 453 ascertain. Nor can channel binding applications work with channels 454 maintained by proxy without being able to communicate (securely) 455 about it with the proxy.] 457 [Sam requested this section offline, and believe we need a PAD entry 458 flag to indicate which PAD entries' addresses (child SA constraints) 459 are subject to connection latching, and which are not. Sam believes 460 this is needed in the native IPsec model based on extending the child 461 SA authorization process; I disagree. -Nico] 463 2.4. Conflict Resolution 465 Consider a system, say, an IMAP server, with an IPsec policy allowing 466 all peers with certificates issued by some CA to claim any 467 dynamically allocated address in a local network. 469 In such an environment a peer might appear using some address, then 470 disappear (e.g., a laptop whose battery runs out) and another peer 471 might later (after the first peer's DHCP lease expires) appear using 472 the same IP address as the first peer. The first peer might have had 473 a long-lived TCP connection open with the server. The new peer might 474 try to open a connection with the same server and with the same 475 5-tuple as the first peer. The new peer's TCP SYN packet will fail 476 to match the existing connection's latch. 478 In such cases implementations based on Section 2.1 and Section 2.3 479 will be unable to narrow the new peer's child SA proposals to avoid a 480 conflict, and must either reject them or terminate the existing 481 connection. Implementations based on Section 2.2 must either drop 482 the new peer's TCP SYN packet, respond with a TCP RST packet, or 483 terminate the existing connection. 485 Implementors MUST provide termination of the existing connection as 486 the default behaviour in such cases. Implementors MAY provide a 487 configuration option for selecting the other behaviours. 489 3. Optional protection 491 Given IPsec APIs an application could request that a connection's 492 packets be protected where they would otherwise be bypassed; that is, 493 applications could override BYPASS policy. Locally privileged 494 applications could request that their connections' packets be 495 bypassed rather than protected; that is, privileged applications 496 could override PROTECT policy. We call this "optional protection." 498 Both native IPsec models of connection latching can be extended to 499 support optional protection. With the model described in Section 2.2 500 optional protection comes naturally: the IPsec layer need only check 501 that the protection requested for outbound packets meets or exceeds 502 the quality of protection, if any, required by the SPD. Similarly, 503 for the model described in Section 2.1 the check that requested 504 protection meets or exceeds that required by the SPD is performed by 505 the IPsec key manager when creating connection latch and connection 506 latch listener objects. 508 When an application requests, and IPsec permits, either additional 509 protection, or bypassing protection, then the SPD MUST be logically 510 updated such that there exists a suitable SPD entry protecting or 511 bypassing the exact 5-tuple recorded by the corresponding connection 512 latch. Note connection latching must be used to represent bypassed 513 connections too where such connection override system policy. Such 514 updates of the SPD MUST NOT survive system crashes or reboots. See 515 Section 2.1. 517 4. Security Considerations 519 Connection latching protects only individual connections from weak 520 peer ID<->address binding, IPsec configuration changes, and from 521 configurations that allow multiple peers to assert the same 522 addresses. But connection latching does not ensure that any two 523 connections with the same end-point addresses will have the same 524 latched peer IDs. In other words, applications that use multiple 525 concurrent connections between two given nodes are not protected any 526 more or less by use of IPsec connection latching than by use of IPsec 527 alone. Such multi-connection applications can, however, examine the 528 latched SA parameters of each connection to ensure that all 529 concurrent connections with the same end-point addresses also have 530 the same end-point IPsec IDs. 532 IPsec channels are a pre-requisite for channel binding 533 [I-D.williams-on-channel-binding] to IPsec. Connection latching 534 provides such channels, but the process of binding IPsec channels 535 (latched connections) to authentication at application layers is not 536 specified herein. 538 Without IPsec APIs connection latching provides marginal security 539 benefits over traditional IPsec. Such APIs are not described herein; 540 see [I-D.ietf-btns-abstract-api]. 542 5. IANA Considerations 544 There are not IANA considerations for this document. 546 6. Acknowledgements 548 The author thanks Michael Richardson for all his help, as well as 549 Stephen Kent, Sam Hartman, Bill Sommerfeld, Dan McDonald, and many 550 others who've participated in the BTNS WG or who've answered 551 questions about IPsec, connection latching implementations, etc... 553 7. References 555 7.1. Normative References 557 [I-D.ietf-btns-abstract-api] 558 Richardson, M., "An interface between applications and 559 keying systems", draft-ietf-btns-abstract-api-00 (work in 560 progress), June 2007. 562 [I-D.ietf-btns-core] 563 Williams, N. and M. Richardson, "Better-Than-Nothing- 564 Security: An Unauthenticated Mode of IPsec", 565 draft-ietf-btns-core-05 (work in progress), 566 September 2007. 568 [I-D.ietf-btns-prob-and-applic] 569 Touch, J., "Problem and Applicability Statement for Better 570 Than Nothing Security (BTNS)", 571 draft-ietf-btns-prob-and-applic-05 (work in progress), 572 February 2007. 574 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 575 Requirement Levels", BCP 14, RFC 2119, March 1997. 577 [RFC2367] McDonald, D., Metz, C., and B. Phan, "PF_KEY Key 578 Management API, Version 2", RFC 2367, July 1998. 580 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 581 Internet Protocol", RFC 4301, December 2005. 583 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 584 RFC 4306, December 2005. 586 [RFC4322] Richardson, M. and D. Redelmeier, "Opportunistic 587 Encryption using the Internet Key Exchange (IKE)", 588 RFC 4322, December 2005. 590 7.2. Informative References 592 [I-D.bellovin-useipsec] 593 Bellovin, S., "Guidelines for Mandating the Use of IPsec", 594 draft-bellovin-useipsec-06 (work in progress), 595 February 2007. 597 [I-D.williams-on-channel-binding] 598 Williams, N., "On the Use of Channel Bindings to Secure 599 Channels", draft-williams-on-channel-binding-04 (work in 600 progress), August 2007. 602 Author's Address 604 Nicolas Williams 605 Sun Microsystems 606 5300 Riata Trace Ct 607 Austin, TX 78727 608 US 610 Email: Nicolas.Williams@sun.com 612 Full Copyright Statement 614 Copyright (C) The IETF Trust (2007). 616 This document is subject to the rights, licenses and restrictions 617 contained in BCP 78, and except as set forth therein, the authors 618 retain all their rights. 620 This document and the information contained herein are provided on an 621 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 622 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 623 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 624 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 625 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 626 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 628 Intellectual Property 630 The IETF takes no position regarding the validity or scope of any 631 Intellectual Property Rights or other rights that might be claimed to 632 pertain to the implementation or use of the technology described in 633 this document or the extent to which any license under such rights 634 might or might not be available; nor does it represent that it has 635 made any independent effort to identify any such rights. Information 636 on the procedures with respect to rights in RFC documents can be 637 found in BCP 78 and BCP 79. 639 Copies of IPR disclosures made to the IETF Secretariat and any 640 assurances of licenses to be made available, or the result of an 641 attempt made to obtain a general license or permission for the use of 642 such proprietary rights by implementers or users of this 643 specification can be obtained from the IETF on-line IPR repository at 644 http://www.ietf.org/ipr. 646 The IETF invites any interested party to bring to its attention any 647 copyrights, patents or patent applications, or other proprietary 648 rights that may cover technology that may be required to implement 649 this standard. Please address the information to the IETF at 650 ietf-ipr@ietf.org. 652 Acknowledgment 654 Funding for the RFC Editor function is provided by the IETF 655 Administrative Support Activity (IASA).