idnits 2.17.1 draft-ietf-hip-applications-01.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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 447. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 458. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 465. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 471. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. 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 (April 9, 2007) is 6221 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-10) exists of draft-ietf-hip-base-07 == Outdated reference: A later version (-08) exists of draft-iab-dns-choices-04 == Outdated reference: A later version (-12) exists of draft-ietf-shim6-proto-07 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Henderson 3 Internet-Draft The Boeing Company 4 Intended status: Informational P. Nikander 5 Expires: October 11, 2007 Ericsson Research NomadicLab 6 April 9, 2007 8 Using the Host Identity Protocol with Legacy Applications 9 draft-ietf-hip-applications-01 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on October 11, 2007. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 The Host Identity Protocol (HIP) and architecture proposes to add a 43 cryptographic name space for network stack names. From an 44 application viewpoint, HIP-enabled systems support a new address 45 family of host identifiers, but it may be a long time until such HIP- 46 aware applications are widely deployed even if host systems are 47 upgraded. This informational document discusses implementation and 48 API issues relating to using HIP in situations in which the system is 49 HIP-aware but the applications are not. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 3. Approaches for supporting legacy applications . . . . . . . . 5 56 3.1. Using IP addresses in applications . . . . . . . . . . . . 5 57 3.2. Using DNS to map domain names to HIs . . . . . . . . . . . 6 58 3.3. Connecting directly to a HIT . . . . . . . . . . . . . . . 8 59 3.4. Local address management . . . . . . . . . . . . . . . . . 8 60 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 61 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 62 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 63 7. Informative References . . . . . . . . . . . . . . . . . . . . 13 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 65 Intellectual Property and Copyright Statements . . . . . . . . . . 15 67 1. Introduction 69 The Host Identity Protocol (HIP) [1] is an experimental effort in the 70 IETF and IRTF to study a new public-key-based name space for use as 71 host identifiers in Internet protocols. Fully deployed, the HIP 72 architecture will permit applications to explicitly request the 73 system to send packets to another named host by expressing a 74 location-independent name of the host when the system call to send 75 packets is performed. However, there will be a transition period 76 during which systems become HIP-enabled but applications are not. 78 When applications and systems are both HIP-aware, the coordination 79 between the application and the system can be straightforward. For 80 example, using the terminology of the widely used sockets Application 81 Programming Interface (API), the application can issue a system call 82 to send packets to another host by naming it explicitly, and the 83 system can perform the necessary name-to-address mapping to assign 84 appropriate routable addresses to the packets. To enable this, a new 85 address family for hosts could be defined, and additional API 86 extensions could be defined (such as allowing IP addresses to be 87 passed in the system call, along with the host name, as hints of 88 where to initially try to reach the host). 90 This note does not define a native HIP API such as described above. 91 Rather, this note is concerned with the scenario in which the 92 application is not HIP-aware and a traditional IP-address-based API 93 is used by the application. To use HIP in such a situation, there 94 are a few basic possibilities: i) allow applications to use IP 95 addresses as before, and provide a mapping from IP address to host 96 identifier (and back to IP address) within the system, ii) take 97 advantage of domain name resolution to provide the application with 98 either an alias for the host identifier or (in the case of IPv6) the 99 host identity tag (HIT) itself, and iii) support the use of HITs 100 directly (without prior DNS resolution) in place of IPv6 addresses. 101 This note describes several variations of the above strategies and 102 suggests some pros and cons to each approach. 104 When HITs are used (rather than IP addresses) as peer names at the 105 system API level, they can provide a type of "channel binding" 106 (Section 1.1.6 of [2]) in that the ESP association formed by HIP is 107 cryptographically bound to the name (HIT) invoked by the calling 108 application. 110 2. Terminology 112 Host Identity: An abstract concept applied to a computing platform. 114 Host Identifier (HI): A public key of an asymmetric key pair used as 115 a name for a Host Identity. More details are available in [1]. 117 Host Identity Tag (HIT): A 128-bit quantity composed with the hash 118 of a Host Identity. More details are available in [3] and [1]. 120 Local Scope Identifier (LSI): A 32- or 128-bit quantity locally 121 representing the Host Identity at the IPv4 or IPv6 API. 123 Referral: An event when the application passes what it believes to 124 be an IP address to another application instance on another host, 125 within its application data stream. An example is the FTP PORT 126 command. 128 Resolver: The system function used by applications to resolve domain 129 names to IP addresses. 131 3. Approaches for supporting legacy applications 133 This section provides examples of how legacy applications, using 134 legacy APIs, can operate over a HIP-enabled system and use HIP. The 135 examples are organized by the name used by an application (or 136 application user) to name the peer system: an IP address, a domain 137 name, or a HIT. Finally, some local address management issues are 138 discussed. 140 While the text below concentrates on the use of the sockets connect 141 system call, the same argument is also valid for other system calls 142 using socket addresses. 144 Recent work in the shim6 group has categorized the ways in which 145 current applications use IP addresses [4]. These uses include short- 146 lived local handles, long-lived application associations, callbacks, 147 referrals, and identity comparisons. Each of the below mechanisms 148 has implications on these different uses of IP addresses by legacy 149 applications. 151 3.1. Using IP addresses in applications 153 Consider the case in which an application issues a "connect(ip)" 154 system call to set the default destination to a system named by 155 address "ip", but for which we would like to enable HIP to protect 156 the communications. Since the application or user does not (can not) 157 indicate a desire to use HIP through the standard sockets API, the 158 decision to invoke HIP must be done on the basis of host policy. For 159 example, if an IPsec-like implementation of HIP is being used, a 160 policy may be entered into the security policy database that mandates 161 to use or try HIP based on a match on the source or destination IP 162 address, or other factors. The mapping of IP address to host 163 identifier may be implemented by modifying the host operating system 164 or by wrapping the existings sockets API, such as in the TESLA 165 approach [5]. 167 There are a number of ways that HIP could be used in such a scenario. 169 Manual configuration: 171 Pre-existing SAs may be available due to previous administrative 172 action. 174 Opportunistically: 176 The system could send an I1 to the Responder with an empty value 177 for Responder HIT. 179 Using DNS to map IP addresses to HIs: 181 If the responder has host identifiers registered in the forward 182 DNS zone and has a PTR record in the reverse zone, the initiating 183 system could perform a reverse+forward lookup to learn the HIT 184 associated with the address. Alternatively, the HIT could be 185 stored in some type of HIP name service such as a distributed hash 186 table (DHT), keyed by IP address. Unless secured with DNS 187 security extensions, the use of the reverse DNS map is subject to 188 well-known security limitations (an attacker may cause an 189 incorrect IP address to domain name binding to occur). 191 These types of solutions have the benefit of better supporting 192 applications that use IP addresses for long-lived application 193 associations, callbacks, and referrals. They have weaker security 194 properties than the approaches outlined in Section 3.2 and 195 Section 3.3, however, because the binding between host identifier and 196 address is weak and not visible to the application or user. In fact, 197 the semantics of the application's "connect(ip)" call may be 198 interpreted as "connect me to the system reachable at IP address ip" 199 but perhaps no stronger semantics than that. HIP can be used in this 200 case to provide perfect forward secrecy and authentication, but not 201 to strongly authenticate the peer at the onset of communications. 202 DNS with security extensions (DNSSEC) [6], if trusted, may be able to 203 provide some additional initial authentication, but at a cost of 204 initial resolution latency. Note that this usage does not 205 necessarily reveal to the user of the legacy application that HIP is 206 being used. 208 Using IP addresses at the application layer may not provide the full 209 potential benefits of HIP mobility support. It allows for mobility 210 if one is able to readdress the existing sockets upon a HIP readdress 211 event. However, mobility will break in the connectionless case when 212 an application caches the IP address and repeatedly calls sendto(). 214 3.2. Using DNS to map domain names to HIs 216 In the previous section, it was pointed out that a HIP-enabled system 217 might make use of DNS to transparently fetch host identifiers prior 218 to the onset of communication. For applications that make use of 219 DNS, the name resolution process is another opportunity to use HIP. 220 If host identifiers are bound to domain names (with a trusted DNS) 221 the following are possible: 223 Return HIP LSIs and HITs instead of IP addresses: 225 The system resolver could be configured to return a Local Scope 226 Identifier (LSI) or HIT rather than an IP address, if HIP 227 information is available in the DNS that binds a particular domain 228 name to a host identifier, and otherwise to return an IP address 229 as usual. The system can then maintain a mapping between LSI and 230 host identifier and perform the appropriate conversion at the 231 system call interface or below. The application uses the LSI or 232 HIT as it would an IP address. 234 Locally use a HIP-specific domain name suffix: 236 One drawback to spoofing the DNS resolution is that some 237 applications actually may want to fetch IP addresses (e.g., 238 diagnostic applications such as ping). One way to provide finer 239 granularity on whether the resolver returns an IP address or an 240 LSI is to distinguish by the presence of a domain name suffix. 241 Specifically, if the application requests to resolve 242 "www.example.com.hip" (or some similar suffix), then the system 243 returns an LSI, while if the application requests to resolve 244 "www.example.com", IP address(es) are returned as usual. Caution 245 against the use of domain name suffixes is discussed in [7]. 247 Since the LSI or HIT is non-routable, a couple of potential hazards 248 arise, in the case of referrals, callbacks, and long-lived 249 application associations. First, applications that perform referrals 250 may pass the LSI to another system that has no system context to 251 resolve the LSI back to a host identifier or an IP address. Note 252 that these are the same type of applications that will likely break 253 if used over certain types of network address translators (NATs). 254 Second, applications may cache the results of DNS queries for a long 255 time, and it may be hard for a HIP system to determine when to 256 perform garbage collection on the LSI bindings. However, when using 257 HITs, the security of using the HITs for identity comparison may be 258 stronger than in the case of using IP addresses. 260 It may be possible for an LSI or HIT to be routable or resolvable, 261 either directly or on an overlay. For example, a special IP address 262 that has some location invariance is the identifier-address discussed 263 in [8]. A term other than LSI may be needed for these routable 264 identifiers, since they would no longer be locally scoped. When 265 using DNS, returning a routable identifier would avoid the 266 aforementioned problems with referrals. However, the cost of 267 routability may be that the hash binding between the routable 268 identifier and the host identifier would be weakened, since more bits 269 may be allocated to the hierarchical part. 271 3.3. Connecting directly to a HIT 273 The previous two sections describe the use of IP addresses and LSIs 274 as local handles to a host identifier. A third approach, for IPv6 275 applications, is to configure the application to connect directly to 276 a HIT (e.g., "connect(HIT)" as a socket call). Although more 277 cumbersome for human users (due to the flat HIT name space) than 278 using either IPv6 addresses or domain names, this scenario has 279 stronger security semantics, because the application is asking the 280 system to send packets specifically to the named peer system. HITs 281 have been defined as Overlay Routable Cryptographic Hash Identifiers 282 (ORCHIDs) such that they cannot be confused with routable IP 283 addresses; see [3]. 285 Another challenge with this approach is in actually finding the IP 286 addresses to use, based on the HIT. Some type of HIT resolution 287 service would be needed in this case. 289 A third challenge of this approach is in supporting callbacks and 290 referrals to possibly non-HIP-aware hosts. However, since most 291 communications in this case would likely be to other HIP-aware hosts 292 (else the initial HIP associations would fail to establish), the 293 problem may otherwise be that the peer host supports HIP but is not 294 able to perform HIT resolution for some reason. 296 3.4. Local address management 298 The previous sections focused mainly on client behavior (HIP 299 initiator). We must also consider the behavior for servers. 300 Typically, a server may bind to a wildcard IP address and well-known 301 port. In the case of HIP use with legacy server implementations, 302 there are again a few options. As in Section 3.1 above, the system 303 may be configured manually to always, optionally (depending on the 304 client behavior), or never use HIP with a particular service, as a 305 matter of policy, when the server specifies a wildcard (IP) address. 307 When a system API call such as getaddrinfo [9] is used for resolving 308 local addresses, it may also return HITs or LSIs, if the system has 309 assigned HITs or LSIs to internal virtual interfaces (common in many 310 HIP implementations). The application may use such identifiers as 311 addresses in subsequent socket calls. 313 Some applications may try to bind a socket to a specific local 314 address. If the local address specified is an IP address, again, the 315 underlying system may be configured to still use HIP. If the local 316 address specified is a HIT (Section 3.3), the system should enforce 317 that connections can only come to the specified HIT. If a system has 318 many HITs, an application that binds to a single HIT cannot accept 319 connections to the other HITs in the system. It may be possible for 320 a system to specify a special ORCHID value as a local HIT wildcard 321 value, if such wildcarding among local HIs is desired. 323 When a host has multiple HIs and the socket behavior does not 324 prescribe the use of any particular HI as a source identifier, it is 325 a matter of local policy as to how to select a HI to serve as a 326 source identifier. 328 4. Security Considerations 330 In this section we discuss the security of the system in general 331 terms, outlining some of the security properties. However, this 332 section is not intended to provide a complete risk analysis. Such an 333 analysis would, in any case, be dependent on the actual application 334 using HIP, and is therefore considered out of scope. 336 The three outlined scenarios differ considerably in their security 337 properties. There are further differences related to whether DNSSEC 338 is used or not, and whether the DNSSEC zones are considered 339 trustworthy enough from an application point of view. 341 When IP addresses are used to represent the peer system, the security 342 properties depend on the the configuration method. With manual 343 configuration, the security of the system is comparable to a non-HIP 344 system with similar IPsec policies. The security semantics of an 345 opportunistic key exchange are roughly equal to current non-secured 346 IP; the exchange is vulnerable to man-in-the-middle attacks. 347 However, the system is less vulnerable to connection hijacking 348 attacks. If the DNS is used, if both maps are secured (or the HITs 349 stored in the reverse DNS record) and the client trusts the DNSSEC 350 signatures, the system may provide a fairly high security level. 351 However, much depends on the details of the implementation, the 352 security and administrative practises used when signing the DNS 353 zones, and other factors. 355 Using the forward DNS to map a domain name into an LSI is a case that 356 is closest to the most typical use scenarios today. If DNSSEC is 357 used, the result is fairly similar to the current use of certificates 358 with TLS. If DNSSEC is not used, the result is fairly similar to the 359 current use of plain IP, with the exception that HIP provides 360 protection against connection hijacking attacks. 362 If the application is basing its operations on HITs, the connections 363 become automatically secured due to the implicit channel bindings in 364 HIP. That is, when the application makes a connect(HIT) system call, 365 the resulting packets will either be sent to a node possessing the 366 corresponding private key or the security association will fail to be 367 established. 369 5. IANA Considerations 371 This document has no actions for IANA. 373 6. Acknowledgments 375 Jeff Ahrenholz, Gonzalo Camarillo, Alberto Garcia, Miika Komu, Teemu 376 Koponen, Julien Laganier, and Jukka Ylitalo have provided comments on 377 different versions of this draft. 379 7. Informative References 381 [1] Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-base-07 382 (work in progress), February 2007. 384 [2] Linn, J., "Generic Security Service Application Program 385 Interface Version 2, Update 1", RFC 2743, January 2000. 387 [3] Nikander, P., "An IPv6 Prefix for Overlay Routable Cryptographic 388 Hash Identifiers (ORCHID)", draft-laganier-ipv6-khi-07 (work in 389 progress), February 2007. 391 [4] Nordmark, E., "Shim6 Application Referral Issues", 392 draft-ietf-shim6-app-refer-00 (work in progress), July 2005. 394 [5] Salz, J., Balakrishnan, H., and A. Snoeren, "TESLA: A 395 Transparent, Extensible Session-Layer Architecture for End-to- 396 end Network Services", Proceedings of USENIX Symposium on 397 Internet Technologies and Systems (USITS), pages 211-224, 398 March 2003. 400 [6] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, 401 "DNS Security Introduction and Requirements", RFC 4033, 402 March 2005. 404 [7] Faltstrom, P., "Design Choices When Expanding DNS", 405 draft-iab-dns-choices-04 (work in progress), October 2006. 407 [8] Bagnulo, M. and E. Nordmark, "Level 3 multihoming shim 408 protocol", draft-ietf-shim6-proto-07 (work in progress), 409 December 2006. 411 [9] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. 412 Stevens, "Basic Socket Interface Extensions for IPv6", RFC 3493, 413 February 2003. 415 Authors' Addresses 417 Tom Henderson 418 The Boeing Company 419 P.O. Box 3707 420 Seattle, WA 421 USA 423 Email: thomas.r.henderson@boeing.com 425 Pekka Nikander 426 Ericsson Research NomadicLab 427 JORVAS FIN-02420 428 FINLAND 430 Phone: +358 9 299 1 431 Email: pekka.nikander@nomadiclab.com 433 Full Copyright Statement 435 Copyright (C) The IETF Trust (2007). 437 This document is subject to the rights, licenses and restrictions 438 contained in BCP 78, and except as set forth therein, the authors 439 retain all their rights. 441 This document and the information contained herein are provided on an 442 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 443 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 444 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 445 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 446 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 447 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 449 Intellectual Property 451 The IETF takes no position regarding the validity or scope of any 452 Intellectual Property Rights or other rights that might be claimed to 453 pertain to the implementation or use of the technology described in 454 this document or the extent to which any license under such rights 455 might or might not be available; nor does it represent that it has 456 made any independent effort to identify any such rights. Information 457 on the procedures with respect to rights in RFC documents can be 458 found in BCP 78 and BCP 79. 460 Copies of IPR disclosures made to the IETF Secretariat and any 461 assurances of licenses to be made available, or the result of an 462 attempt made to obtain a general license or permission for the use of 463 such proprietary rights by implementers or users of this 464 specification can be obtained from the IETF on-line IPR repository at 465 http://www.ietf.org/ipr. 467 The IETF invites any interested party to bring to its attention any 468 copyrights, patents or patent applications, or other proprietary 469 rights that may cover technology that may be required to implement 470 this standard. Please address the information to the IETF at 471 ietf-ipr@ietf.org. 473 Acknowledgment 475 Funding for the RFC Editor function is provided by the IETF 476 Administrative Support Activity (IASA).