idnits 2.17.1 draft-henderson-hip-applications-02.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 377. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 354. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 361. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 367. ** 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 (February 24, 2006) is 6628 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-04 ** Downref: Normative reference to an Experimental draft: draft-ietf-hip-base (ref. '1') == Outdated reference: A later version (-08) exists of draft-iab-dns-choices-03 ** Downref: Normative reference to an Informational draft: draft-iab-dns-choices (ref. '3') == Outdated reference: A later version (-12) exists of draft-ietf-shim6-proto-03 == Outdated reference: A later version (-07) exists of draft-laganier-ipv6-khi-01 ** Downref: Normative reference to an Experimental draft: draft-laganier-ipv6-khi (ref. '5') Summary: 8 errors (**), 0 flaws (~~), 6 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 Expires: August 28, 2006 P. Nikander 5 Ericsson Research NomadicLab 6 February 24, 2006 8 Using HIP with Legacy Applications 9 draft-henderson-hip-applications-02 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 August 28, 2006. 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. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 62 Intellectual Property and Copyright Statements . . . . . . . . . . 12 64 1. Introduction 66 The Host Identity Protocol (HIP) [1] is an experimental effort in the 67 IETF and IRTF to study a new public-key-based name space for use as 68 host identifiers in Internet protocols. Fully deployed, the HIP 69 architecture will permit applications to explicitly request the 70 system to connect to another named host by expressing a location- 71 independent name of the host when the system call to connect is 72 performed. However, there will be a transition period during which 73 systems become HIP-enabled but applications are not. 75 When applications and systems are both HIP-aware, the coordination 76 between the application and the system can be straightforward. For 77 example, using the terminology of the widely used sockets API, the 78 application can issue a system call to connect to another host by 79 naming it explicitly, and the system can perform the necessary name- 80 to-address mapping to assign appropriate routable addresses to the 81 packets. To enable this, a new address family (e.g., AF_HOST) could 82 be defined, and additional API extensions could be defined (such as 83 allowing IP addresses to be passed in the system call, along with the 84 host name, as hints of where to initially try to reach the host). 86 This note does not define a native HIP API such as described above. 87 Rather, this note is concerned with the scenario in which the 88 application is not HIP-aware and a traditional IP-address-based API 89 is used by the application. To use HIP in such a situation, there 90 are a few basic possibilities: i) allow applications to use IP 91 addresses as before, and provide a mapping from IP address to host 92 identity (and back to IP address) within the system, ii) take 93 advantage of domain name resolution to provide the application with 94 either an alias for the host identifier or (in the case of IPv6) the 95 host identity tag (HIT) itself, and iii) support the use of HITs 96 directly (without prior DNS resolution) in place of IPv6 addresses. 97 This note describes several variations of the above strategies and 98 suggests some pros and cons to each approach. 100 When HITs are used (rather than IP addresses) as peer names at the 101 system API, they can provide a type of "channel binding" (Section 102 1.1.6 of [2]) in that the ESP association formed by HIP is 103 cryptographically bound to the name (HIT) invoked by the calling 104 application. 106 2. Terminology 108 Host Identity Tag: A 128-bit quantity formed by the hash of a Host 109 Identity. More details are available in [1]. 111 Local Scope Identifier: A 32- or 128-bit quantity locally 112 representing the Host Identity at the IPv4 or IPv6 API. 114 Referral: An event when the application passes what it believes to 115 be an IP address to another application instance on another host, 116 within its application data stream. An example is the FTP PORT 117 command. 119 Resolver: The system function used by applications to resolve domain 120 names to IP addresses. 122 3. Approaches for supporting legacy applications 124 This section provides examples of how legacy applications, using 125 legacy APIs, can operate over a HIP-enabled system and use HIP. The 126 examples are organized by the name used by an application (or 127 application user) to name the peer system: an IP address, a domain 128 name, or a HIT. 130 While the text below concentrates on the use of the connect system 131 call, the same argumentation can be applied to the unconnected 132 (datagram based) system calls, too. 134 3.1. Using IP addresses in applications 136 Consider the case in which an application issues a "connect(ip)" 137 system call to connect to a system named by address "ip", but for 138 which we would like to enable HIP to protect the communications. 139 Since the application or user does not (can not) indicate a desire to 140 use HIP through the standard sockets API, the decision to invoke HIP 141 must be done on the basis of host policy. For example, if an IPsec- 142 like implementation of HIP is being used, a policy may be entered 143 into the security policy database that mandates to use or try HIP 144 based on a match on the source or destination IP address, or other 145 factors. 147 There are a number of ways that HIP could be used in such a scenario. 149 Manual configuration: 151 Pre-existing SAs may be available due to previous administrative 152 action. 154 Opportunistically: 156 The system could send an I1 to the Responder with an empty value 157 for Responder HIT. 159 Using DNS: 161 If the responder has host identities registered in the forward DNS 162 zone and has a PTR record in the reverse zone, the initiating 163 system could perform a reverse+forward lookup to learn the HIT 164 associated with the address. Alternatively, the HIT could be 165 stored in the reverse DNS map. However, compared to the 166 opportunistic use, there is no benefit of storing the HIT into the 167 reverse DNS map unless the reverse map is secured with DNSSEC. 169 These types of solutions have the benefit of naturally supporting 170 application-level referrals, since the applications always use IP 171 addresses. They have weaker security properties than the approaches 172 outlined in Section 3.2 and Section 3.3, however, because the binding 173 between host identity and address is weak and not visible to the 174 application or user. In fact, the semantics of the application's 175 "connect(ip)" call may be interpreted as "connect me to the system 176 reachable at IP address ip" but perhaps no stronger semantics than 177 that. HIP can be used in this case to provide perfect forward 178 secrecy and authentication, but not to strongly authenticate the peer 179 at the onset of communications. DNS with DNSSEC, if trusted, may be 180 able to provide some additional initial authentication, but at a cost 181 of initial resolution latency. 183 Using IP addresses at the application layer may not provide the full 184 potential benefits of HIP mobility support. It allows for mobility 185 if one is able to readdress the existing sockets upon a HIP readdress 186 event. However, mobility will break in the connectionless case when 187 an application caches the IP address and repeatedly calls sendto(). 189 3.2. Using DNS 191 In the previous section, it was pointed out that a HIP-enabled system 192 might make use of DNS to transparently fetch host identifiers prior 193 to the onset of communication. For applications that make use of 194 DNS, the name resolution process is another opportunity to use HIP. 195 If host identities are bound to domain names (with a trusted DNS) the 196 following are possible: 198 Return HIP LSIs instead of IP addresses: 200 The system resolver could be configured to return a Local Scope 201 Identifier (LSI) rather than an IP address, if HIP information is 202 available in the DNS that binds a particular domain name to a host 203 identity, and otherwise to return an IP address as usual. The 204 system can then maintain a mapping between LSI and host identity 205 and perform the appropriate conversion at the system call 206 interface or below. The application uses the LSI as it would an 207 IP address. 209 Locally use a HIP-specific domain name suffix: 211 One drawback to spoofing the DNS resolution is that some 212 applications actually may want to fetch IP addresses (e.g., 213 diagnostic applications such as ping). One way to provide finer 214 granularity on whether the resolver returns an IP address or an 215 LSI is to distinguish by the presence of a domain name suffix. 216 Specifically, if the application requests to resolve 217 "www.example.com.hip" (or some similar suffix), then the system 218 returns an LSI, while if the application requests to resolve 219 "www.example.com", IP address(es) are returned as usual. Caution 220 against the use of FQDN suffixes is discussed in [3]. 222 If the LSI is non-routable, a couple of potential hazards arise. 223 First, applications that perform referrals may pass the LSI to 224 another system that has no system context to resolve the LSI back to 225 a host identity or an IP address. Note that these are the same type 226 of applications that will likely break if used over certain types of 227 NATs. Second, applications may cache the results of DNS queries for 228 a long time, and it may be hard for a HIP system to determine when to 229 perform garbage collection on the LSI bindings. 231 It may be possible for an LSI to be routable, but such a case may not 232 have the level of security in the binding to host identity that a HIT 233 has with the host identity. For example, a special IP address that 234 has some location invariance is the identifier-address discussed in 235 [4]. In general, LSIs considered to date for HIP have been non- 236 routable. 238 3.3. Connecting directly to a HIT 240 The previous two sections describe the use of IP addresses and and 241 LSIs as "handles" to a host identity. A third approach, for IPv6 242 applications, is to configure the application to connect directly to 243 a HIT (e.g., "connect(HIT)" as a socket call). Although more 244 cumbersome for human users (due to the flat HIT name space) than 245 using either IPv6 addresses or domain names, this scenario has 246 stronger security semantics, because the application is asking the 247 system to connect specifically to the named peer system. 249 It may be hard in this case for a system to distinguish between a HIT 250 and a routable IPv6 address. Elsewhere it has been proposed [5] that 251 HITs be precluded (temporarily) from using highest-ordered bits that 252 correspond to IPv6 addresses, so that at least in the near term, a 253 system could differentiate between a HIT and an IPv6 address by 254 inspection. 256 Another challenge with this approach is in actually finding the IP 257 addresses to use, based on the HIT. Some type of HIT resolution 258 service would be needed in this case. 260 A third challenge of this approach is in supporting referrals to 261 possibly non-HIP-aware hosts. However, since most communications in 262 this case would likely be to other HIP-aware hosts (else the initial 263 connect() would fail), the problem may be instead if the peer host 264 supports HIP but is not able to perform HIT resolution for some 265 reason. 267 4. Security Considerations 269 In this section we discuss the security of the system in general 270 terms, outlining some of the security properties. However, this 271 section is not intended to provide a complete risk analysis. Such an 272 analysis would, in any case, be dependent on the actual application 273 using HIP, and is therefore considered out of scope. 275 The three outlined scenarios differ considerably in their security 276 properties. There are further differences related to whether DNSSEC 277 is used or not, and whether the DNSSEC zones are considered 278 trustworthy enough from an application point of view. 280 When IP addresses are used to represent the peer system, the security 281 properties depend on the the configuration method. With manual 282 configuration, the system's security is comparable to a non-HIP 283 system with similar IPsec policies. The security semantics of an 284 opportunistic key exchange are roughly equal to current non-secured 285 IP; the exchange is vulnerable to man-in-the-middle attacks. 286 However, the system is less vulnerable to connection hijacking 287 attacks. If the DNS is used, if both maps are secured (or the HITs 288 stored in the reverse MAP) and the client trusts the DNSSEC 289 signatures, the system may provide a fairly high security level. 290 However, much depends on the details of the implementation, the 291 security and administrative practises used when signing the DNS 292 zones, and other factors. 294 Using the forward DNS to map a DNS name into an LSI is a case that is 295 closest to the most typical use scenarios today. If DNSSEC is used, 296 the result is fairly similar to the current use of certificates with 297 TLS. If DNSSEC is not used, the result is fairly similar to the 298 current use of plain IP, with the exception that HIP provides 299 protection against connection hijacking attacks. 301 If the application is basing its operations on HITs, the connections 302 become automatically secured due to the implicit channel bindings in 303 HIP. That is, when the application makes a connect(HIT) system call, 304 the resulting connection will either be connected to a node 305 possessing the corresponding private key or the connection attempt 306 will fail. 308 5. References 310 [1] Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-base-04 311 (work in progress), October 2005. 313 [2] Linn, J., "Generic Security Service Application Program 314 Interface Version 2, Update 1", RFC 2743, January 2000. 316 [3] Faltstrom, P., "Design Choices When Expanding DNS", 317 draft-iab-dns-choices-03 (work in progress), February 2006. 319 [4] Bagnulo, M. and E. Nordmark, "Level 3 multihoming shim 320 protocol", draft-ietf-shim6-proto-03 (work in progress), 321 December 2005. 323 [5] Nikander, P., Laganier, J., and F. Dupont, "An IPv6 Prefix for 324 Overlay Routable Keyed Hash Identifiers (KHI)", 325 draft-laganier-ipv6-khi-01 (work in progress), February 2006. 327 Authors' Addresses 329 Tom Henderson 330 The Boeing Company 331 P.O. Box 3707 332 Seattle, WA 333 USA 335 Email: thomas.r.henderson@boeing.com 337 Pekka Nikander 338 Ericsson Research NomadicLab 339 JORVAS FIN-02420 340 FINLAND 342 Phone: +358 9 299 1 343 Email: pekka.nikander@nomadiclab.com 345 Intellectual Property Statement 347 The IETF takes no position regarding the validity or scope of any 348 Intellectual Property Rights or other rights that might be claimed to 349 pertain to the implementation or use of the technology described in 350 this document or the extent to which any license under such rights 351 might or might not be available; nor does it represent that it has 352 made any independent effort to identify any such rights. Information 353 on the procedures with respect to rights in RFC documents can be 354 found in BCP 78 and BCP 79. 356 Copies of IPR disclosures made to the IETF Secretariat and any 357 assurances of licenses to be made available, or the result of an 358 attempt made to obtain a general license or permission for the use of 359 such proprietary rights by implementers or users of this 360 specification can be obtained from the IETF on-line IPR repository at 361 http://www.ietf.org/ipr. 363 The IETF invites any interested party to bring to its attention any 364 copyrights, patents or patent applications, or other proprietary 365 rights that may cover technology that may be required to implement 366 this standard. Please address the information to the IETF at 367 ietf-ipr@ietf.org. 369 Disclaimer of Validity 371 This document and the information contained herein are provided on an 372 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 373 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 374 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 375 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 376 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 377 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 379 Copyright Statement 381 Copyright (C) The Internet Society (2006). This document is subject 382 to the rights, licenses and restrictions contained in BCP 78, and 383 except as set forth therein, the authors retain all their rights. 385 Acknowledgment 387 Funding for the RFC Editor function is currently provided by the 388 Internet Society.