idnits 2.17.1 draft-ietf-hip-applications-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 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 405. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 382. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 389. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 395. ** 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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. 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 (November 22, 2006) is 6365 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) == Outdated reference: A later version (-10) exists of draft-ietf-hip-base-06 ** Downref: Normative reference to an Experimental draft: draft-ietf-hip-base (ref. '1') -- Possible downref: Normative reference to a draft: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' == Outdated reference: A later version (-08) exists of draft-iab-dns-choices-04 ** Downref: Normative reference to an Informational draft: draft-iab-dns-choices (ref. '5') == Outdated reference: A later version (-12) exists of draft-ietf-shim6-proto-06 == Outdated reference: A later version (-07) exists of draft-laganier-ipv6-khi-05 ** Downref: Normative reference to an Experimental draft: draft-laganier-ipv6-khi (ref. '7') Summary: 8 errors (**), 0 flaws (~~), 6 warnings (==), 9 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 Expires: May 26, 2007 P. Nikander 5 Ericsson Research NomadicLab 6 November 22, 2006 8 Using HIP with Legacy Applications 9 draft-ietf-hip-applications-00.txt 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 May 26, 2007. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 The Host Identity Protocol and architecture (HIP) 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 (e.g., AF_HOST), 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 . . . . . . . . . . . . . . . . . . . . . . . . 6 58 3.3. Connecting directly to a HIT . . . . . . . . . . . . . . . 7 59 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 60 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 61 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 63 Intellectual Property and Copyright Statements . . . . . . . . . . 12 65 1. Introduction 67 The Host Identity Protocol (HIP) [1] is an experimental effort in the 68 IETF and IRTF to study a new public-key-based name space for use as 69 host identifiers in Internet protocols. Fully deployed, the HIP 70 architecture will permit applications to explicitly request the 71 system to connect to another named host by expressing a location- 72 independent name of the host when the system call to connect is 73 performed. However, there will be a transition period during which 74 systems become HIP-enabled but applications are not. 76 When applications and systems are both HIP-aware, the coordination 77 between the application and the system can be straightforward. For 78 example, using the terminology of the widely used sockets API, the 79 application can issue a system call to connect to another host by 80 naming it explicitly, and the system can perform the necessary name- 81 to-address mapping to assign appropriate routable addresses to the 82 packets. To enable this, a new address family (e.g., AF_HOST) could 83 be defined, and additional API extensions could be defined (such as 84 allowing IP addresses to be passed in the system call, along with the 85 host name, as hints of where to initially try to reach the host). 87 This note does not define a native HIP API such as described above. 88 Rather, this note is concerned with the scenario in which the 89 application is not HIP-aware and a traditional IP-address-based API 90 is used by the application. To use HIP in such a situation, there 91 are a few basic possibilities: i) allow applications to use IP 92 addresses as before, and provide a mapping from IP address to host 93 identity (and back to IP address) within the system, ii) take 94 advantage of domain name resolution to provide the application with 95 either an alias for the host identifier or (in the case of IPv6) the 96 host identity tag (HIT) itself, and iii) support the use of HITs 97 directly (without prior DNS resolution) in place of IPv6 addresses. 98 This note describes several variations of the above strategies and 99 suggests some pros and cons to each approach. 101 When HITs are used (rather than IP addresses) as peer names at the 102 system API, they can provide a type of "channel binding" (Section 103 1.1.6 of [2]) in that the ESP association formed by HIP is 104 cryptographically bound to the name (HIT) invoked by the calling 105 application. 107 2. Terminology 109 Host Identity Tag: A 128-bit quantity formed by the hash of a Host 110 Identity. More details are available in [1]. 112 Local Scope Identifier: A 32- or 128-bit quantity locally 113 representing the Host Identity at the IPv4 or IPv6 API. 115 Referral: An event when the application passes what it believes to 116 be an IP address to another application instance on another host, 117 within its application data stream. An example is the FTP PORT 118 command. 120 Resolver: The system function used by applications to resolve domain 121 names to IP addresses. 123 3. Approaches for supporting legacy applications 125 This section provides examples of how legacy applications, using 126 legacy APIs, can operate over a HIP-enabled system and use HIP. The 127 examples are organized by the name used by an application (or 128 application user) to name the peer system: an IP address, a domain 129 name, or a HIT. 131 While the text below concentrates on the use of the connect system 132 call, the same argument can also be applied to datagram-based system 133 calls. 135 Recent work in the shim6 group has categorized the ways in which 136 current applications use IP addresses [3]. These uses include short- 137 lived local handles, long-lived application associations, callbacks, 138 referrals, and identity comparisons. Each of the below mechanisms 139 has implications on these different uses of IP addresses by legacy 140 applications. 142 3.1. Using IP addresses in applications 144 Consider the case in which an application issues a "connect(ip)" 145 system call to connect to a system named by address "ip", but for 146 which we would like to enable HIP to protect the communications. 147 Since the application or user does not (can not) indicate a desire to 148 use HIP through the standard sockets API, the decision to invoke HIP 149 must be done on the basis of host policy. For example, if an IPsec- 150 like implementation of HIP is being used, a policy may be entered 151 into the security policy database that mandates to use or try HIP 152 based on a match on the source or destination IP address, or other 153 factors. The mapping of IP address to host identity may be 154 implemented by modifying the host operating system or by wrapping the 155 existings sockets API, such as in the TESLA approach [4]. 157 There are a number of ways that HIP could be used in such a scenario. 159 Manual configuration: 161 Pre-existing SAs may be available due to previous administrative 162 action. 164 Opportunistically: 166 The system could send an I1 to the Responder with an empty value 167 for Responder HIT. 169 Using DNS: 171 If the responder has host identities registered in the forward DNS 172 zone and has a PTR record in the reverse zone, the initiating 173 system could perform a reverse+forward lookup to learn the HIT 174 associated with the address. Alternatively, the HIT could be 175 stored in some type of HIP name service such as a DHT, keyed by IP 176 address. Unless secured with DNSSEC, the use of the reverse DNS 177 map is subject to well-known security limitations (an attacker may 178 cause an incorrect IP address to FQDN binding to occur). 180 These types of solutions have the benefit of better supporting 181 applications that use IP addresses for long-lived application 182 associations, callbacks, and referrals. They have weaker security 183 properties than the approaches outlined in Section 3.2 and 184 Section 3.3, however, because the binding between host identity and 185 address is weak and not visible to the application or user. In fact, 186 the semantics of the application's "connect(ip)" call may be 187 interpreted as "connect me to the system reachable at IP address ip" 188 but perhaps no stronger semantics than that. HIP can be used in this 189 case to provide perfect forward secrecy and authentication, but not 190 to strongly authenticate the peer at the onset of communications. 191 DNS with DNSSEC, if trusted, may be able to provide some additional 192 initial authentication, but at a cost of initial resolution latency. 194 Using IP addresses at the application layer may not provide the full 195 potential benefits of HIP mobility support. It allows for mobility 196 if one is able to readdress the existing sockets upon a HIP readdress 197 event. However, mobility will break in the connectionless case when 198 an application caches the IP address and repeatedly calls sendto(). 200 3.2. Using DNS 202 In the previous section, it was pointed out that a HIP-enabled system 203 might make use of DNS to transparently fetch host identifiers prior 204 to the onset of communication. For applications that make use of 205 DNS, the name resolution process is another opportunity to use HIP. 206 If host identities are bound to domain names (with a trusted DNS) the 207 following are possible: 209 Return HIP LSIs and HITs instead of IP addresses: 211 The system resolver could be configured to return a Local Scope 212 Identifier (LSI) or Host Identity Tag (HIT) rather than an IP 213 address, if HIP information is available in the DNS that binds a 214 particular domain name to a host identity, and otherwise to return 215 an IP address as usual. The system can then maintain a mapping 216 between LSI and host identity and perform the appropriate 217 conversion at the system call interface or below. The application 218 uses the LSI or HIT as it would an IP address. 220 Locally use a HIP-specific domain name suffix: 222 One drawback to spoofing the DNS resolution is that some 223 applications actually may want to fetch IP addresses (e.g., 224 diagnostic applications such as ping). One way to provide finer 225 granularity on whether the resolver returns an IP address or an 226 LSI is to distinguish by the presence of a domain name suffix. 227 Specifically, if the application requests to resolve 228 "www.example.com.hip" (or some similar suffix), then the system 229 returns an LSI, while if the application requests to resolve 230 "www.example.com", IP address(es) are returned as usual. Caution 231 against the use of FQDN suffixes is discussed in [5]. 233 Since the LSI or HIT is non-routable, a couple of potential hazards 234 arise, in the case of referrals, callbacks, and long-lived 235 application associations. First, applications that perform referrals 236 may pass the LSI to another system that has no system context to 237 resolve the LSI back to a host identity or an IP address. Note that 238 these are the same type of applications that will likely break if 239 used over certain types of NATs. Second, applications may cache the 240 results of DNS queries for a long time, and it may be hard for a HIP 241 system to determine when to perform garbage collection on the LSI 242 bindings. However, when using HITs, the security of using the HITs 243 for identity comparison may be stronger than in the case of using IP 244 addresses. 246 It may be possible for an LSI or HIT to be routable or resolvable, 247 but such a case may not have the level of security in the binding to 248 host identity that a HIT has with the host identity. For example, a 249 special IP address that has some location invariance is the 250 identifier-address discussed in [6]. In general, LSIs and HITs 251 considered to date for HIP have been non-routable. 253 3.3. Connecting directly to a HIT 255 The previous two sections describe the use of IP addresses and and 256 LSIs as local handles to a host identity. A third approach, for IPv6 257 applications, is to configure the application to connect directly to 258 a HIT (e.g., "connect(HIT)" as a socket call). Although more 259 cumbersome for human users (due to the flat HIT name space) than 260 using either IPv6 addresses or domain names, this scenario has 261 stronger security semantics, because the application is asking the 262 system to connect specifically to the named peer system. 264 Depending on how HITs are ultimately defined, it may be hard for a 265 system to distinguish between a HIT and a routable IPv6 address. 266 Elsewhere it has been proposed [7] that HITs be precluded from using 267 highest-ordered bits that correspond to IPv6 addresses, so that at 268 least in the near term, a system could differentiate between a HIT 269 and an IPv6 address by inspection. 271 Another challenge with this approach is in actually finding the IP 272 addresses to use, based on the HIT. Some type of HIT resolution 273 service would be needed in this case. 275 A third challenge of this approach is in supporting callbacks and 276 referrals to possibly non-HIP-aware hosts. However, since most 277 communications in this case would likely be to other HIP-aware hosts 278 (else the initial connect() would fail), the problem may be instead 279 if the peer host supports HIP but is not able to perform HIT 280 resolution for some reason. 282 4. Security Considerations 284 In this section we discuss the security of the system in general 285 terms, outlining some of the security properties. However, this 286 section is not intended to provide a complete risk analysis. Such an 287 analysis would, in any case, be dependent on the actual application 288 using HIP, and is therefore considered out of scope. 290 The three outlined scenarios differ considerably in their security 291 properties. There are further differences related to whether DNSSEC 292 is used or not, and whether the DNSSEC zones are considered 293 trustworthy enough from an application point of view. 295 When IP addresses are used to represent the peer system, the security 296 properties depend on the the configuration method. With manual 297 configuration, the system's security is comparable to a non-HIP 298 system with similar IPsec policies. The security semantics of an 299 opportunistic key exchange are roughly equal to current non-secured 300 IP; the exchange is vulnerable to man-in-the-middle attacks. 301 However, the system is less vulnerable to connection hijacking 302 attacks. If the DNS is used, if both maps are secured (or the HITs 303 stored in the reverse MAP) and the client trusts the DNSSEC 304 signatures, the system may provide a fairly high security level. 305 However, much depends on the details of the implementation, the 306 security and administrative practises used when signing the DNS 307 zones, and other factors. 309 Using the forward DNS to map a DNS name into an LSI is a case that is 310 closest to the most typical use scenarios today. If DNSSEC is used, 311 the result is fairly similar to the current use of certificates with 312 TLS. If DNSSEC is not used, the result is fairly similar to the 313 current use of plain IP, with the exception that HIP provides 314 protection against connection hijacking attacks. 316 If the application is basing its operations on HITs, the connections 317 become automatically secured due to the implicit channel bindings in 318 HIP. That is, when the application makes a connect(HIT) system call, 319 the resulting connection will either be connected to a node 320 possessing the corresponding private key or the connection attempt 321 will fail. 323 5. Acknowledgments 325 Jeff Ahrenholz, Miika Komu, Teemu Koponen, and Jukka Ylitalo have 326 provided comments on different versions of this draft. 328 6. References 330 [1] Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-base-06 331 (work in progress), June 2006. 333 [2] Linn, J., "Generic Security Service Application Program 334 Interface Version 2, Update 1", RFC 2743, January 2000. 336 [3] Nordmark, E., "Shim6 Application Referral Issues", 337 draft-ietf-shim6-app-refer-00 (work in progress), July 2005. 339 [4] Salz, J., Balakrishnan, H., and A. Snoeren, "TESLA: A 340 Transparent, Extensible Session-Layer Architecture for End-to- 341 end Network Services", Proceedings of USENIX Symposium on 342 Internet Technologies and Systems (USITS), December 2003. 344 [5] Faltstrom, P., "Design Choices When Expanding DNS", 345 draft-iab-dns-choices-04 (work in progress), October 2006. 347 [6] Bagnulo, M. and E. Nordmark, "Level 3 multihoming shim 348 protocol", draft-ietf-shim6-proto-06 (work in progress), 349 October 2006. 351 [7] Nikander, P., "An IPv6 Prefix for Overlay Routable Cryptographic 352 Hash Identifiers (ORCHID)", draft-laganier-ipv6-khi-05 (work in 353 progress), September 2006. 355 Authors' Addresses 357 Tom Henderson 358 The Boeing Company 359 P.O. Box 3707 360 Seattle, WA 361 USA 363 Email: thomas.r.henderson@boeing.com 365 Pekka Nikander 366 Ericsson Research NomadicLab 367 JORVAS FIN-02420 368 FINLAND 370 Phone: +358 9 299 1 371 Email: pekka.nikander@nomadiclab.com 373 Intellectual Property Statement 375 The IETF takes no position regarding the validity or scope of any 376 Intellectual Property Rights or other rights that might be claimed to 377 pertain to the implementation or use of the technology described in 378 this document or the extent to which any license under such rights 379 might or might not be available; nor does it represent that it has 380 made any independent effort to identify any such rights. Information 381 on the procedures with respect to rights in RFC documents can be 382 found in BCP 78 and BCP 79. 384 Copies of IPR disclosures made to the IETF Secretariat and any 385 assurances of licenses to be made available, or the result of an 386 attempt made to obtain a general license or permission for the use of 387 such proprietary rights by implementers or users of this 388 specification can be obtained from the IETF on-line IPR repository at 389 http://www.ietf.org/ipr. 391 The IETF invites any interested party to bring to its attention any 392 copyrights, patents or patent applications, or other proprietary 393 rights that may cover technology that may be required to implement 394 this standard. Please address the information to the IETF at 395 ietf-ipr@ietf.org. 397 Disclaimer of Validity 399 This document and the information contained herein are provided on an 400 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 401 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 402 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 403 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 404 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 405 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 407 Copyright Statement 409 Copyright (C) The Internet Society (2006). This document is subject 410 to the rights, licenses and restrictions contained in BCP 78, and 411 except as set forth therein, the authors retain all their rights. 413 Acknowledgment 415 Funding for the RFC Editor function is currently provided by the 416 Internet Society.