idnits 2.17.1 draft-iab-identifier-comparison-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. == There are 2 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 476: '...dentity of an Internet host, it SHOULD...' RFC 2119 keyword, line 478: '...#.#.#.#") form. The host SHOULD check...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 10, 2013) is 4065 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC5890' is mentioned on line 601, but not defined == Outdated reference: A later version (-09) exists of draft-iab-privacy-considerations-03 -- Obsolete informational reference (is this intentional?): RFC 3490 (Obsoleted by RFC 5890, RFC 5891) -- Obsolete informational reference (is this intentional?): RFC 6125 (Obsoleted by RFC 9525) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Thaler, Ed. 3 Internet-Draft Microsoft 4 Intended status: Informational March 10, 2013 5 Expires: September 11, 2013 7 Issues in Identifier Comparison for Security Purposes 8 draft-iab-identifier-comparison-09.txt 10 Abstract 12 Identifiers such as hostnames, URIs, IP addresses, and email 13 addresses are often used in security contexts to identify security 14 principals and resources. In such contexts, an identifier presented 15 via some protocol is often compared using some policy to make 16 security decisions such as whether the security principal may access 17 the resource, what level of authentication or encryption is required, 18 etc. If the parties involved in a security decision use different 19 algorithms to compare identifiers, then failure scenarios ranging 20 from denial of service to elevation of privilege can result. This 21 document provides a discussion of these issues that designers should 22 consider when defining identifiers and protocols, and when 23 constructing architectures that use multiple protocols. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on September 11, 2013. 42 Copyright Notice 44 Copyright (c) 2013 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Classes of Identifiers . . . . . . . . . . . . . . . . . 5 61 1.2. Canonicalization . . . . . . . . . . . . . . . . . . . . 5 62 2. Identifier Use in Security Policies and Decisions . . . . . . 6 63 2.1. False Positives and Negatives . . . . . . . . . . . . . . 7 64 2.2. Hypothetical Example . . . . . . . . . . . . . . . . . . 8 65 3. Comparison Issues With Common Identifiers . . . . . . . . . . 9 66 3.1. Hostnames . . . . . . . . . . . . . . . . . . . . . . . . 9 67 3.1.1. IPv4 Literals . . . . . . . . . . . . . . . . . . . . 10 68 3.1.2. IPv6 Literals . . . . . . . . . . . . . . . . . . . . 12 69 3.1.3. Internationalization . . . . . . . . . . . . . . . . 12 70 3.1.4. Resolution for comparison . . . . . . . . . . . . . . 13 71 3.2. Ports and Service Names . . . . . . . . . . . . . . . . . 14 72 3.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 15 73 3.3.1. Scheme component . . . . . . . . . . . . . . . . . . 16 74 3.3.2. Authority component . . . . . . . . . . . . . . . . . 16 75 3.3.3. Path component . . . . . . . . . . . . . . . . . . . 17 76 3.3.4. Query component . . . . . . . . . . . . . . . . . . . 17 77 3.3.5. Fragment component . . . . . . . . . . . . . . . . . 17 78 3.3.6. Resolution for comparison . . . . . . . . . . . . . . 18 79 3.4. Email Address-like Identifiers . . . . . . . . . . . . . 18 80 4. General Issues . . . . . . . . . . . . . . . . . . . . . . . 19 81 4.1. Conflation . . . . . . . . . . . . . . . . . . . . . . . 19 82 4.2. Internationalization . . . . . . . . . . . . . . . . . . 19 83 4.3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 21 84 4.4. Temporality . . . . . . . . . . . . . . . . . . . . . . . 21 85 5. Security Considerations . . . . . . . . . . . . . . . . . . . 21 86 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 87 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 88 8. IAB Members at the Time of This Writing . . . . . . . . . . . 23 89 9. Informative References . . . . . . . . . . . . . . . . . . . 23 90 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 26 92 1. Introduction 94 In computing and the Internet, various types of "identifiers" are 95 used to identify humans, devices, content, etc. This document 96 provides a discussion of some security issues that designers should 97 consider when defining identifiers and protocols, and when 98 constructing architectures that use multiple protocols. Before 99 discussing these security issues, we first give some background on 100 some typical processes involving identifiers. Terms such as 101 identifier, identity, and principal are used as defined in [RFC4949]. 103 As depicted in Figure 1, there are multiple processes relevant to our 104 discussion. 106 1. An identifier is first generated. If the identifier is intended 107 to be unique, the generation process must include some mechanism, 108 such as allocation by a central authority or verification among 109 the members of a distributed authority, to help ensure 110 uniqueness. However the notion of "unique" involves determining 111 whether a putative identifier matches any other already-allocated 112 identifier. As we will see, for many types of identifiers, this 113 is not simply an exact binary match. 115 After generating the identifier, it is often stored in two 116 locations: with the requester or "holder" of the identifier, and 117 with some repository of identifiers (e.g., DNS). For example, if 118 the identifier was allocated by a central authority, the 119 repository might be that authority. If the identifier identifies 120 a device or content on a device, the repository might be that 121 device. 123 2. The identifier is distributed, either by the holder of the 124 identifier or by a repository of identifiers, to others who could 125 use the identifier. This distribution might be electronic, but 126 sometimes it is via other channels such as voice, business card, 127 billboard, or other form of advertisement. The identifier itself 128 might be distributed directly, or it might be used to generate a 129 portion of another type of identifier that is then distributed. 130 For example, a URI or email address might include a server name, 131 and hence distributing the URI or email address also inherently 132 distributes the server name. 134 3. The identifier is used by some party. Generally the user 135 supplies the identifier which is (directly or indirectly) sent to 136 the repository of identifiers. The repository of identifiers 137 must then attempt to match the user-supplied identifier with an 138 identifier in its repository. 140 For example, using an email address to send email to the holder 141 of an identifier may result in the email arriving at the holder's 142 email server which has access to the mail stores. 144 +------------+ 145 | Holder of | 1. Generation 146 | identifier +<---------+ 147 +----+-------+ | 148 | | Match 149 | v/ 150 | +-------+-------+ 151 +----------+ Repository of | 152 | | identifiers | 153 | +-------+-------+ 154 2. Distribution | ^\ 155 | | Match 156 v | 157 +---------+-------+ | 158 | User of | | 159 | identifier +----------+ 160 +-----------------+ 3. Use 162 Typical Identifier Processes 164 Figure 1 166 Another variation is where a user is given the identifier of a 167 resource (e.g., a web site) to access securely, sometimes known as a 168 "reference identifier" [RFC6125], and the server hosting the resource 169 then presents its identity at the time of use. In this case the user 170 application attempts to match the presented identity against the 171 reference identifier. 173 One key aspect is that the identifier values passed in generation, 174 distribution, and use, may all be in different forms. For example, 175 an identifier might be exchanged in printed form at generation time, 176 distributed to a user via voice, and then used electronically. As 177 such, the match process can be complicated. 179 Furthermore, in many cases, the relationship between holder, 180 repositories, and users may be more involved. For example, when a 181 hierarchy of web caches exist, each cache is itself a repository of a 182 sort, and the match process is usually intended to be the same as on 183 the origin server. 185 Another aspect to keep in mind is that there can be multiple 186 identifiers that refer to the same object (i.e., resource, human, 187 device, etc.). For example, a human might have a passport number and 188 a drivers license number, and an RFC might be available at multiple 189 locations (rfc-editor.org and ietf.org). In this document we focus 190 on comparing two identifiers to see whether they are the same 191 identifier, rather than comparing two different identifiers to see 192 whether they refer to the same entity (although a few issues with the 193 latter are touched on in several places such as Section 3.1.4 and 194 Section 3.3.6). 196 1.1. Classes of Identifiers 198 In this document we will refer to the following classes of 199 identifiers: 201 o Absolute: identifiers that can be compared byte-by-byte for 202 equality. Two identifiers that have different bytes are defined 203 to be different. For example, binary IP addresses are in this 204 class. 206 o Definite: identifiers that have a single well-defined comparison 207 algorithm. For example, URI scheme names are required to be US- 208 ASCII [USASCII] and are defined to match in a case-insensitive 209 way; the comparison is thus definite since there is a well- 210 specified algorithm (Section 9.2.1 of [RFC4790]) on how to do a 211 case-insensitive match among ASCII strings. 213 o Indefinite: identifiers that have no single well-defined 214 comparison algorithm. For example, human names are in this class. 215 Everyone might want the comparison to be tailored for their 216 locale, for some definition of locale. In some cases, there may 217 be limited subsets of parties that might be able to agree (e.g., 218 ASCII users might all agree on a common comparison algorithm 219 whereas users of other Roman-derived scripts, such as Turkish, may 220 not), but identifiers often tend to leak out of such limited 221 environments. 223 1.2. Canonicalization 225 Perhaps the most common algorithm for comparison involves first 226 converting each identifier to a canonical form (a process known as 227 "canonicalization" or "normalization"), and then testing the 228 resulting canonical representations for bitwise equality. In so 229 doing, it is thus critical that all entities involved agree on the 230 same canonical form and use the same canonicalization algorithm so 231 that the overall comparison process is also the same. 233 Note that in some contexts, such as in internationalization, the 234 terms "canonicalization" and "normalization" have a precise meaning. 235 In this document, however, we use these terms synonymously in their 236 more generic form, to mean conversion to some standard form. 238 While the most common method of comparison includes canonicalization, 239 comparison can also be done by defining an equivalence algorithm, 240 where no single form is canonical. However in most cases, a 241 canonical form is useful for other purposes, such as output, and so 242 in such cases defining a canonical form suffices to define a 243 comparison method. 245 2. Identifier Use in Security Policies and Decisions 247 Identifiers such as hostnames, URIs, and email addresses are used in 248 security contexts to identify security principals (i.e., entities 249 that can be authenticated) and resources as well as other security 250 parameters such as types and values of claims. Those identifiers are 251 then used to make security decisions based on an identifier presented 252 via some protocol. For example: 254 o Authentication: a protocol might match a security principal's 255 identifier to look up expected keying material, and then match 256 keying material. 258 o Authorization: a protocol might match a resource name against some 259 policy. For example, it might look up an access control list 260 (ACL), and then look up the security principal's identifier (or a 261 surrogate for it) in that ACL. 263 o Accounting: a system might create an accounting record for a 264 security principal's identifier or resource name, and then might 265 later need to match a presented identifier to (for example) add 266 new filtering rules based on the records in order to stop an 267 attack. 269 If the parties involved in a security decision use different matching 270 algorithms for the same identifiers, then failure scenarios ranging 271 from denial of service to elevation of privilege can result, as we 272 will see. 274 This is especially complicated in cases involving multiple parties 275 and multiple protocols. For example, there are many scenarios where 276 some form of "security token service" is used to grant to a requester 277 permission to access a resource, where the resource is held by a 278 third party that relies on the security token service (see Figure 2). 279 The protocol used to request permission (e.g., Kerberos or OAuth) may 280 be different from the protocol used to access the resource (e.g., 281 HTTP). Opportunities for security problems arise when two protocols 282 define different comparison algorithms for the same type of 283 identifier, or when a protocol is ambiguously specified and two 284 endpoints (e.g., a security token service and a resource holder) 285 implement different algorithms within the same protocol. 287 +----------+ 288 | security | 289 | token | 290 | service | 291 +----------+ 292 ^ 293 | 1. supply credentials and 294 | get token for resource 295 | +--------+ 296 +----------+ 2. supply token and access resource |resource| 297 |requester |=------------------------------------->| holder | 298 +----------+ +--------+ 300 Simple Security Exchange 302 Figure 2 304 In many cases the situation is more complex. With X.509 Public Key 305 Infrastructure (PKIX) certificates [RFC6125] for example, the name in 306 a certificate gets compared against names in ACLs or other things. 307 In the case of web site security, the name in the certificate gets 308 compared to a portion of the URI that a user may have typed into a 309 browser. The fact that many different people are doing the typing, 310 on many different types of systems, complicates the problem. 312 Add to this the certificate enrollment step, and the certificate 313 issuance step, and two more parties have an opportunity to adjust the 314 encoding or worse, the software that supports them might make changes 315 that the parties are unaware are happening. 317 2.1. False Positives and Negatives 319 It is first worth discussing in more detail the effects of errors in 320 the comparison algorithm. A "false positive" results when two 321 identifiers compare as if they were equal, but in reality refer to 322 two different objects (e.g., security principals or resources). When 323 privilege is granted on a match, a false positive thus results in an 324 elevation of privilege, for example allowing execution of an 325 operation that should not have been permitted otherwise. When 326 privilege is denied on a match (e.g., matching an entry in a block/ 327 deny list or a revocation list), a permissible operation is denied. 328 At best, this can cause worse performance (e.g., a cache miss, or 329 forcing redundant authentication), and at worst can result in a 330 denial of service. 332 A "false negative" results when two identifiers that in reality refer 333 to the same thing compare as if they were different, and the effects 334 are the reverse of those for false positives. That is, when 335 privilege is granted on a match, the result is at best worse 336 performance and at worst a denial of service; when privilege is 337 denied on a match, elevation of privilege results. 339 Figure 3 summarizes these effects. 341 | "Grant on match" | "Deny on match" 342 ---------------+------------------------+----------------------- 343 False positive | Elevation of privilege | Denial of service 344 ---------------+------------------------+----------------------- 345 False negative | Denial of service | Elevation of privilege 346 ---------------+------------------------+----------------------- 348 Worst Effects of False Positives/Negatives 350 Figure 3 352 When designing a comparison algorithm, one can typically modify it to 353 increase the likelihood of false positives and decrease the 354 likelihood of false negatives, or vice versa. Which outcome is 355 better depends on the context. 357 Elevation of privilege is almost always seen as far worse than denial 358 of service. Hence, for URIs for example, Section 6.1 of [RFC3986] 359 states: "comparison methods are designed to minimize false negatives 360 while strictly avoiding false positives". 362 Thus URIs were defined with a "grant privilege on match" paradigm in 363 mind, where it is critical to prevent elevation of privilege while 364 minimizing denial of service. Using URIs in a "deny privilege on 365 match" system can thus be problematic. 367 2.2. Hypothetical Example 369 In this example, both security principals and resources are 370 identified using URIs. Foo Corp has paid example.com for access to 371 the Stuff service. Foo Corp allows its employees to create accounts 372 on the Stuff service. Alice gets the account "http://example.com/ 373 Stuff/FooCorp/alice" and Bob gets "http://example.com/Stuff/FooCorp/ 374 bob". It turns out, however, that Foo Corp's URI canonicalizer 375 includes URI fragment components in comparisons whereas example.com's 376 does not, and Foo Corp does not disallow the # character in the 377 account name. So Chuck, who is a malicious employee of Foo Corp, 378 asks to create an account at example.com with the name alice#stuff. 379 Foo Corp's URI logic checks its records for accounts it has created 380 with stuff and sees that there is no account with the name 381 alice#stuff. Hence, in its records, it associates the account 382 alice#stuff with Chuck and will only issue tokens good for use with 383 "http://example.com/Stuff/FooCorp/alice#stuff" to Chuck. 385 Chuck, the attacker, goes to a security token service at Foo Corp and 386 asks for a security token good for "http://example.com/Stuff/FooCorp/ 387 alice#stuff". Foo Corp issues the token since Chuck is the 388 legitimate owner (in Foo Corp's view) of the alice#stuff account. 389 Chuck then submits the security token in a request to "http:// 390 example.com/Stuff/FooCorp/alice". 392 But example.com uses a URI canonicalizer that, for the purposes of 393 checking equality, ignores fragments. So when example.com looks in 394 the security token to see if the requester has permission from Foo 395 Corp to access the given account it successfully matches the URI in 396 the security token, "http://example.com/Stuff/FooCorp/alice#stuff", 397 with the requested resource name "http://example.com/Stuff/FooCorp/ 398 alice". 400 Leveraging the inconsistencies in the canonicalizers used by Foo Corp 401 and example.com, Chuck is able to successfully launch an elevation of 402 privilege attack and access Alice's resource. 404 Furthermore, consider an attacker using a similar corporation such as 405 "foocorp" (or any variation containing a non-ASCII character that 406 some humans might expect to represent the same corporation). If the 407 resource holder treats them as different, but the security token 408 service treats them as the same, then again elevation of privilege 409 can occur. 411 3. Comparison Issues With Common Identifiers 413 In this section, we walk through a number of common types of 414 identifiers and discuss various issues related to comparison that may 415 affect security whenever they are used to identify security 416 principals or resources. These examples illustrate common patterns 417 that may arise with other types of identifiers. 419 3.1. Hostnames 421 Hostnames (composed of dot-separated labels) are commonly used either 422 directly as identifiers, or as components in identifiers such as in 423 URIs and email addresses. Another example is in [RFC5280], sections 424 7.2 and 7.3 (and updated in section 3 of 426 [I-D.ietf-pkix-rfc5280-clarifications]), which specify use in PKIX 427 certificates. 429 In this section we discuss a number of issues in comparing strings 430 that appear to be some form of hostname. 432 It is first worth pointing out that the term "hostname" itself is 433 often ambiguous, and hence it is important that any use clarify which 434 definition is intended. Some examples of definitions include: 436 a. A Fully-Qualified Domain Name (FQDN), 438 b. An FQDN that is associated with address records in the DNS, 440 c. The leftmost label in an FQDN, or 442 d. The leftmost label in an FQDN that is associated with address 443 records. 445 The use of different definitions in different places results in 446 questions such as whether "example" and "example.com" are considered 447 equal or not, and hence it is important when writing new 448 specifications to be clear about which definition is meant. 450 Section 3 of [RFC6055] discusses the differences between a "hostname" 451 vs. a "DNS name", where the former is a subset of the latter by 452 using a restricted set of characters (letters, digits, and hyphens). 453 If one canonicalizer uses the "DNS name" definition whereas another 454 uses a "hostname" definition, a name might be valid in the former but 455 invalid in the latter. As long as invalid identifiers are denied 456 privilege, this difference will not result in elevation of privilege. 458 Section 3.1 of [RFC1034] discusses the difference between a 459 "complete" domain name which ends with a dot (such as 460 "example.com."), vs. a multi-label relative name such as 461 "example.com" that assumes the root (".") is in the suffix search 462 list. In most contexts these are considered equal, but there may be 463 issues if different entities in a security architecture have 464 different interpretations of a relative domain name. 466 [IAB1123] briefly discusses issues with the ambiguity around whether 467 a label will be "alphabetic", including among other issues, how 468 "alphabetic" should be interpreted in an internationalized 469 environment, and whether a hostname can be interpreted as an IP 470 address. We explore this last issue in more detail below. 472 3.1.1. IPv4 Literals 474 [RFC1123] section 2.1 states: 476 Whenever a user inputs the identity of an Internet host, it SHOULD 477 be possible to enter either (1) a host domain name or (2) an IP 478 address in dotted-decimal ("#.#.#.#") form. The host SHOULD check 479 the string syntactically for a dotted-decimal number before 480 looking it up in the Domain Name System. 482 and 484 This last requirement is not intended to specify the complete 485 syntactic form for entering a dotted-decimal host number; that is 486 considered to be a user-interface issue. 488 In specifying the inet_addr() API, the POSIX standard [IEEE-1003.1] 489 defines "IPv4 dotted decimal notation" as allowing not only strings 490 of the form "10.0.1.2", but also allows octal and hexadecimal, and 491 addresses with less than four parts. For example, "10.0.258", 492 "0xA000001", and "012.0x102" all represent the same IPv4 address in 493 standard "IPv4 dotted decimal" notation. We will refer to this as 494 the "loose" syntax of an IPv4 address literal. 496 In section 6.1 of [RFC3493] getaddrinfo() is defined to support the 497 same (loose) syntax as inet_addr(): 499 If the specified address family is AF_INET or AF_UNSPEC, address 500 strings using Internet standard dot notation as specified in 501 inet_addr() are valid. 503 In contrast, section 6.3 of the same RFC states, specifying 504 inet_pton(): 506 If the af argument of inet_pton() is AF_INET, the src string shall 507 be in the standard IPv4 dotted-decimal form: ddd.ddd.ddd.ddd where 508 "ddd" is a one to three digit decimal number between 0 and 255. 509 The inet_pton() function does not accept other formats (such as 510 the octal numbers, hexadecimal numbers, and fewer than four 511 numbers that inet_addr() accepts). 513 As shown above, inet_pton() uses what we will refer to as the 514 "strict" form of an IPv4 address literal. Some platforms also use 515 the strict form with getaddrinfo() when the AI_NUMERICHOST flag is 516 passed to it. 518 Both the strict and loose forms are standard forms, and hence a 519 protocol specification is still ambiguous if it simply defines a 520 string to be in the "standard IPv4 dotted decimal form". And, as a 521 result of these differences, names such as "10.11.12" are ambiguous 522 as to whether they are an IP address or a hostname, and even 523 "10.11.12.13" can be ambiguous because of the "SHOULD" in RFC 1123 524 above making it optional whether to treat it as an address or a DNS 525 name. 527 Protocols and data formats that can use addresses in string form for 528 security purposes need to resolve these ambiguities. For example, 529 for the host component of URIs, section 3.2.2 of [RFC3986] resolves 530 the first ambiguity by only allowing the strict form, and the second 531 ambiguity by specifying that it is considered an IPv4 address 532 literal. New protocols and data formats should similarly consider 533 using the strict form rather than the loose form in order to better 534 match user expectations. 536 A string might be valid under the "loose" definition, but invalid 537 under the "strict" definition. As long as invalid identifiers are 538 denied privilege, this difference will not result in elevation of 539 privilege. Some protocols, however, use strings that can be either 540 an IP address literal or a hostname. Such strings are at best 541 Definite identifiers, and often turn out to be Indefinite 542 identifiers. (See Section 4.1 for more discussion.) 544 3.1.2. IPv6 Literals 546 IPv6 addresses similarly have a wide variety of alternate but 547 semantically identical string representations, as defined in section 548 2.2 of [RFC4291] and section 2 of [I-D.ietf-6man-uri-zoneid]. As 549 discussed in section 3.2.5 of [RFC5952], this fact causes problems in 550 security contexts if comparison (such as in PKIX certificates), is 551 done between strings rather than between the binary representations 552 of addresses. 554 [RFC5952] recently specified a recommended canonical string format as 555 an attempt to solve this problem, but it may not be ubiquitously 556 supported at present. And, when strings can contain non-ASCII 557 characters, the same issues (and more, since hexadecimal and colons 558 are allowed) arise as with IPv4 literals. 560 Whereas (binary) IPv6 addresses are Absolute identifiers, IPv6 561 address literals are Definite identifiers, since string-to-address 562 conversion for IPv6 address literals is unambiguous. 564 3.1.3. Internationalization 566 The IETF policy on character sets and languages [RFC2277] requires 567 support for UTF-8 in protocols, and as a result many protocols now do 568 support non-ASCII characters. When a hostname is sent in a UTF-8 569 field, there are a number of ways it may be encoded. For example, 570 hostname labels might be encoded directly in UTF-8, or might first be 571 Punycode-encoded [RFC3492] or even percent-encoded from UTF-8. 573 For example, in URIs, [RFC3986] section 3.2.2 specifically allows for 574 the use of percent-encoded UTF-8 characters in the hostname, as well 575 as the use of IDNA encoding [RFC3490] using the Punycode algorithm. 577 Percent-encoding is unambiguous for hostnames since the percent 578 character cannot appear in the strict definition of a "hostname", 579 though it can appear in a DNS name. 581 Punycode-encoded labels (or "A-labels") on the other hand can be 582 ambiguous if hosts are actually allowed to be named with a name 583 starting with "xn--", and false positives can result. While this may 584 be extremely unlikely for normal scenarios, it nevertheless provides 585 a possible vector for an attacker. 587 A hostname comparator thus needs to decide whether a Punycode-encoded 588 label should or should not be considered a valid hostname label, and 589 if so, then whether it should match a label encoded in some other 590 form such as a percent-encoded Unicode label (U-label). 592 For example, Section 3 of "Transport Layer Security (TLS) Extensions" 593 [RFC6066], states: 595 "HostName" contains the fully qualified DNS hostname of the 596 server, as understood by the client. The hostname is represented 597 as a byte string using ASCII encoding without a trailing dot. 598 This allows the support of internationalized domain names through 599 the use of A-labels defined in [RFC5890]. DNS hostnames are case- 600 insensitive. The algorithm to compare hostnames is described in 601 [RFC5890], Section 2.3.2.4. 603 For some additional discussion of security issues that arise with 604 internationalization, see Section 4.2 and [TR36]. 606 3.1.4. Resolution for comparison 608 Some systems (specifically Java URLs [JAVAURL]) use the rule that if 609 two hostnames resolve to the same IP address(es) then the hostnames 610 are considered equal. That is, the canonicalization algorithm 611 involves name resolution with an IP address being the canonical form. 613 For example, if resolution was done via DNS, and DNS contained: 615 example.com. IN A 10.0.0.6 616 example.net. CNAME example.com. 617 example.org. IN A 10.0.0.6 619 then the algorithm might treat all three names as equal, even though 620 the third name might refer to a different entity. 622 With the introduction of dynamic IP addresses, private IP addresses, 623 multiple IP addresses per name, multiple address families (e.g., IPv4 624 vs. IPv6), devices that roam to new locations, commonly deployed DNS 625 tricks that result in the answer depending on factors such as the 626 requester's location and the load on the server whose address is 627 returned, etc., this method of comparison cannot be relied upon. 628 There is no guarantee that two names for the same host will resolve 629 the name to the same IP addresses, nor that the addresses resolved 630 refer to the same entity such as when the names resolve to private IP 631 addresses, nor even that the system has connectivity (and the 632 willingness to wait for the delay) to resolve names at the time the 633 answer is needed. The lifetime of the identifier, and of any cached 634 state from a previous resolution, also affects security (see 635 Section 4.4). 637 In addition, a comparison mechanism that relies on the ability to 638 resolve identifiers such as hostnames to other identifies such as IP 639 addresses leaks information about security decisions to outsiders if 640 these queries are publicly observable. (See 641 [I-D.iab-privacy-considerations] for a deeper discussion of 642 information disclosure.) 644 Finally, it is worth noting that resolving two identifiers to 645 determine if they refer to the same entity can be thought of as a use 646 of such identifiers, as opposed to actually comparing the identifiers 647 themselves, which is the focus of this document. 649 3.2. Ports and Service Names 651 Port numbers and service names are discussed in depth in [RFC6335]. 652 Historically, there were port numbers, service names used in SRV 653 records, and mnemonic identifiers for assigned port numbers (known as 654 port "keywords" at [IANA-PORT]). The latter two are now unified, and 655 various protocols use one or more of these types in strings. For 656 example, the common syntax used by many URI schemes allows port 657 numbers but not service names. Some implementations of the 658 getaddrinfo() API support strings that can be either port numbers or 659 port keywords (but not service names). 661 For protocols that use service names that must be resolved, the 662 issues are the same as those for resolution of addresses in 663 Section 3.1.4. In addition, Section 5.1 of [RFC6335] clarifies that 664 service names/port keywords must contain at least one letter. This 665 prevents confusion with port numbers in strings where both are 666 allowed. 668 3.3. URIs 670 This section looks at issues related to using URIs for security 671 purposes. For example, [RFC5280], section 7.4, specifies comparison 672 of URIs in certificates. Examples of URIs in security token-based 673 access control systems include WS-*, SAML-P and OAuth WRAP. In such 674 systems, a variety of participants in the security infrastructure are 675 identified by URIs. For example, requesters of security tokens are 676 sometimes identified with URIs. The issuers of security tokens and 677 the relying parties who are intended to consume security tokens are 678 frequently identified by URIs. Claims in security tokens often have 679 their types defined using URIs and the values of the claims can also 680 be URIs. 682 URIs are defined with multiple components, each of which has its own 683 rules. We cover each in turn below. However, it is also important 684 to note that there exist multiple comparison algorithms. [RFC3986] 685 section 6.2 states: 687 A variety of methods are used in practice to test URI equivalence. 688 These methods fall into a range, distinguished by the amount of 689 processing required and the degree to which the probability of 690 false negatives is reduced. As noted above, false negatives 691 cannot be eliminated. In practice, their probability can be 692 reduced, but this reduction requires more processing and is not 693 cost-effective for all applications. 695 If this range of comparison practices is considered as a ladder, 696 the following discussion will climb the ladder, starting with 697 practices that are cheap but have a relatively higher chance of 698 producing false negatives, and proceeding to those that have 699 higher computational cost and lower risk of false negatives. 701 The ladder approach has both pros and cons. On the pro side, it 702 allows some uses to optimize for security, and other uses to optimize 703 for cost, thus allowing URIs to be applicable to a wide range of 704 uses. A disadvantage is that when different approaches are taken by 705 different components in the same system using the same identifiers, 706 the inconsistencies can result in security issues. 708 3.3.1. Scheme component 710 [RFC3986] defines URI schemes as being case-insensitive US-ASCII and 711 in section 6.2.2.1 specifies that scheme names should be normalized 712 to lower-case characters. 714 New schemes can be defined over time. In general two URIs with an 715 unrecognized scheme cannot be safely compared, however. This is 716 because the canonicalization and comparison rules for the other 717 components may vary by scheme. For example, a new URI scheme might 718 have a default port of X, and without that knowledge, a comparison 719 algorithm cannot know whether "example.com" and "example.com:X" 720 should be considered to match in the authority component. Hence for 721 security purposes, it is safest for unrecognized schemes to be 722 treated as invalid identifiers. However, if the URIs are only used 723 with a "grant access on match" paradigm then unrecognized schemes can 724 be supported by doing a generic case-sensitive comparison, at the 725 expense of some false negatives. 727 3.3.2. Authority component 729 The authority component is scheme-specific, but many schemes follow a 730 common syntax that allows for userinfo, host, and port. 732 3.3.2.1. Host 734 Section 3.1 discussed issues with hostnames in general. In addition, 735 [RFC3986] section 3.2.2 allows future changes using the IPvFuture 736 production. As with IPv4 and IPv6 literals, IPvFuture formats may 737 have issues with multiple semantically identical string 738 representations, and may also be semantically identical to an IPv4 or 739 IPv6 address. As such, false negatives may be common if IPvFuture is 740 used. 742 3.3.2.2. Port 744 See discussion in Section 3.2. 746 3.3.2.3. Userinfo 748 [RFC3986] defines the userinfo production that allows arbitrary data 749 about the user of the URI to be placed before '@' signs in URIs. For 750 example: "ftp://alice:bob@example.com/bar" has the value "alice:bob" 751 as its userinfo. When comparing URIs in a security context, one must 752 decide whether to treat the userinfo as being significant or not. 753 Some URI comparison services for example treat "ftp:// 754 alice:ick@example.com" and "ftp://example.com" as being equal. 756 When the userinfo is treated as being significant, it has additional 757 considerations (e.g., whether it is case-sensitive or not) which we 758 cover in Section 3.4. 760 3.3.3. Path component 762 [RFC3986] supports the use of path segment values such as "./" or ".. 763 /" for relative URIs. As discussed in section 6.2.2.3 of [RFC3986], 764 they are intended only for use within a reference relative to some 765 other base URI, but [RFC3986] section 5.2.4 nevertheless defines an 766 algorithm to remove them as part of URI normalization. 768 Unless a scheme states otherwise, the path component is defined to be 769 case-sensitive. However, if the resource is stored and accessed 770 using a filesystem using case-insensitive paths, there will be many 771 paths that refer to the same resource. As such, false negatives can 772 be common in this case. 774 3.3.4. Query component 776 There is the question as to whether "http://example.com/foo", "http:/ 777 /example.com/foo?", and "http://example.com/foo?bar" are each 778 considered equal or different. 780 Similarly, it is unspecified whether the order of values matters. 781 For example, should "http://example.com/blah?ick=bick&foo=bar" be 782 considered equal to "http://example.com/blah?foo=bar&ick=bick"? And 783 if a domain name is permitted to appear in a query component (e.g., 784 in a reference to another URI), the same issues in Section 3.1 apply. 786 3.3.5. Fragment component 788 Some URI formats include fragment identifiers. These are typically 789 handles to locations within a resource and are used for local 790 reference. A classic example is the use of fragments in HTTP URIs 791 where a URI of the form "http://example.com/blah.html#ick" means 792 retrieve the resource "http://example.com/blah.html" and, once it has 793 arrived locally, find the HTML anchor named ick and display that. 795 So, for example, when a user clicks on the link "http://example.com/ 796 blah.html#baz" a browser will check its cache by doing a URI 797 comparison for "http://example.com/blah.html" and, if the resource is 798 present in the cache, a match is declared. 800 Hence comparisons for security purposes typically ignore the fragment 801 component and treat all fragments as equal to the full resource. 802 However, if one were actually trying to compare the piece of a 803 resource that was identified by the fragment identifier, ignoring it 804 would result in potential false positives. 806 3.3.6. Resolution for comparison 808 As with Section 3.1.4 for hostnames, it may be tempting to define a 809 URI comparison algorithm based on whether they resolve to the same 810 content. Similar problems exist, however, including content that 811 dynamically changes over time or based on factors such as the 812 requester's location, potential lack of external connectivity at the 813 time/place comparison is done, potentially undesirable delay 814 introduced, etc. 816 In addition, as noted in Section 3.1.4, resolution leaks information 817 about security decisions to outsiders if the queries are publicly 818 observable. 820 3.4. Email Address-like Identifiers 822 Section 3.4.1 of [RFC5322] defines the syntax of an email address- 823 like identifier, and Section 3.2 of [RFC6532] updates it to support 824 internationalization. [RFC5280], section 7.5, further discusses the 825 use of internationalized email addresses in certificates. 827 [RFC6532] use in certificates points to [RFC6530], where Section 13 828 of that document contains a discussion of many issues resulting from 829 internationalization. 831 Email address-like identifiers have a local part and a domain part. 832 The issues with the domain part are essentially the same as with 833 hostnames, covered earlier in Section 3.1. 835 The local part is left for each domain to define. People quite 836 commonly use email addresses as usernames with web sites such as 837 banks or shopping sites, but the site doesn't know whether 838 foo@example.com is the same person as FOO@example.com. Thus email 839 address-like identifiers are typically Indefinite identifiers. 841 To avoid false positives, some security mechanisms (such as 842 [RFC5280]) compare the local part using an exact match. Hence, like 843 URIs, email address-like identifiers are designed for use in grant- 844 on-match security schemes, not in deny-on-match schemes. 846 Furthermore, when such identifiers are actually used as email 847 addresses, Section 2.4 of [RFC5321] states that the local part of a 848 mailbox must be treated as case sensitive, but if a mailbox is stored 849 and accessed using a fileystem using case-insensitive paths, there 850 may be many paths that refer to the same mailbox. As such, false 851 negatives can be common in this case. 853 4. General Issues 855 4.1. Conflation 857 There are a number of examples (some in the preceding sections) of 858 strings that conflate two types of identifiers, using some heuristic 859 to try to determine which type of identifier is given. Similarly, 860 two ways of encoding the same type of identifier might be conflated 861 within the same string. 863 Some examples include: 865 1. A string that might be an IPv4 address literal or an IPv6 address 866 literal 868 2. A string that might be an IP address literal or a hostname 870 3. A string that might be a port number or a service name 872 4. A DNS label that might be literal or be Punycode-encoded 874 Strings that allow such conflation can only be considered Definite if 875 there exists a well-defined rule to determine which identifier type 876 is meant. One way to do so is to ensure that the valid syntax for 877 the two is disjoint (e.g., distinguishing IPv4 vs. IPv6 address 878 literals by the use of colons in the latter). A second way to do so 879 is to define a precedence rule that results in some identifiers being 880 inaccessible via a conflated string (e.g., a host literally named "xn 881 --de-jg4avhby1noc0d" may be inaccessible due to the "xn--" prefix 882 denoting the use of Punycode encoding). In some cases, such 883 inaccessible space may be reserved so that the actual set of 884 identifiers in use are unambiguous. For example, Section 2.5.5.2 of 885 [RFC4291] defines a range of the IPv6 address space for representing 886 IPv4 addresses. 888 4.2. Internationalization 890 In addition to the issues with hostnames discussed in Section 3.1.3, 891 there are a number of internationalization issues that apply to many 892 types of Definite and Indefinite identifiers. 894 First, there is no DNS mechanism for identifying whether non- 895 identical strings would be seen by a human as being equivalent. 897 There are problematic examples even with US-ASCII (Basic Latin) 898 strings including regional spelling variations such as "color" and 899 "colour" and many non-English cases including partially-numeric 900 strings in Arabic script contexts, Chinese strings in Simplified and 901 Traditional forms, and so on. Attempts to produce such alternate 902 forms algorithmically could produce false positives and hence have an 903 adverse affect on security. 905 Second, some strings are visually confusable with others, and hence 906 if a security decision is made by a user based on visual inspection, 907 many opportunities for false positives exist. As such, using visual 908 inspection for security is unreliable. In addition to the security 909 issues, visual confusability also adversely affects the usability of 910 identifiers distributed via visual mediums. Similar issues can arise 911 with audible confusability when using audio (e.g., for radio 912 distribution, accessibility to the blind, etc.) in place of a visual 913 medium. Furthermore, when strings conflate two types of identifiers 914 as discussed in Section 4.1, allowing non-ASCII characters can cause 915 one type of identifier to appear to a human as another type of 916 identifier. For example, characters that may look like digits and 917 dots may appear to be an IPv4 Literal to a human (especially to one 918 who might expect digits to appear in his or her native script). 919 Hence conflation often increases the chance of confusability. 921 Determining whether a string is a valid identifier should typically 922 be done after, or as part of, canonicalization. Otherwise an 923 attacker might use the canonicalization algorithm to inject (e.g., 924 via percent encoding, NFKC, or non-shortest-form UTF-8) delimiters 925 such as '@' in an email address-like identifier, or a '.' in a 926 hostname. 928 Any case-insensitive comparisons need to define how comparison is 929 done, since such comparisons may vary by locale of the endpoint. As 930 such, using case-insensitive comparisons in general often result in 931 identifiers being either Indefinite or, if the legal character set is 932 restricted (e.g., to US-ASCII), then Definite. 934 See also [WEBER] for a more visual discussion of many of these 935 issues. 937 Finally, the set of permitted characters and the canonical form of 938 the characters (and hence the canonicalization algorithm) sometimes 939 varies by protocol today, even when the intent is to use the same 940 identifier, such as when one protocol passes identifiers to the 941 other. See [I-D.ietf-precis-problem-statement] for further 942 discussion. 944 4.3. Scope 946 Another issue arises when an identifier (e.g., "localhost", 947 "10.11.12.13", etc.) is not globally unique. [RFC3986] Section 1.1 948 states: 950 URIs have a global scope and are interpreted consistently 951 regardless of context, though the result of that interpretation 952 may be in relation to the end-user's context. For example, "http: 953 //localhost/" has the same interpretation for every user of that 954 reference, even though the network interface corresponding to 955 "localhost" may be different for each end-user: interpretation is 956 independent of access. 958 Whenever a non-globally-unique identifier is passed to another entity 959 outside of the scope of uniqueness, it will refer to a different 960 resource, and can result in a false positive. This problem is often 961 addressed by using the identifier together with some other unique 962 identifier of the context. For example "alice" may uniquely identify 963 a user within a system, but must be used with "example.com" (as in 964 "alice@example.com") to uniquely identify the context outside of that 965 system. 967 It is also worth noting that non-globally-scoped IPv6 addresses can 968 be written with, or otherwise associated with, a "zone ID" to 969 identify the context (see [RFC4007] for more information). However, 970 zone IDs are only unique within a host, so they typically narrow, 971 rather than expand, the scope of uniqueness of the resulting 972 identifier. 974 4.4. Temporality 976 Often identifiers are not unique across all time, but have some 977 lifetime associated with them after which they may be reassigned to 978 another entity. For example, bob@example.com might be assigned to an 979 employee of the Example company, but if he leaves and another Bob is 980 later hired, the same identifier might be reused. As another 981 example, IP address 203.0.113.1 might be assigned to one subscriber, 982 and then later reassigned to another subscriber. Security issues can 983 arise if updates are not made in all entities that store the 984 identifier (e.g., in an access control list as discussed in 985 Section 2, or in a resolution cache as discussed in Section 3.1.4). 986 This issue is similar to the issue of scope discussed in Section 4.3, 987 except that the scope of uniqueness is temporal rather than 988 topological. 990 5. Security Considerations 991 This entire document is about security considerations. 993 To minimize elevation of privilege issues, any system that requires 994 the ability to use both deny and allow operations within the same 995 identifier space should avoid the use of Indefinite identifiers in 996 security comparisons. 998 To minimize future security risks, any new identifiers being designed 999 should specify an Absolute or Definite comparison algorithm, and if 1000 extensibility is allowed (e.g., as new schemes in URIs allow) then 1001 the comparison algorithm should remain invariant so that unrecognized 1002 extensions can be compared. That is, security risks can be reduced 1003 by specifying the comparison algorithm, making sure to resolve any 1004 ambiguities pointed out in this document (e.g., "standard dotted 1005 decimal"). 1007 Some issues (such as unrecognized extensions) can be mitigated by 1008 treating such identifiers as invalid. Validity checking of 1009 identifiers is further discussed in [RFC3696]. 1011 Perhaps the hardest issues arise when multiple protocols are used 1012 together, such as in the figure in Section 2, where the two protocols 1013 are defined or implemented using different comparison algorithms. 1014 When constructing an architecture that uses multiple such protocols, 1015 designers should pay attention to any differences in comparison 1016 algorithms among the protocols, in order to fully understand the 1017 security risks. An area for future work is how to deal with such 1018 security risks in current systems. 1020 6. IANA Considerations 1022 This document requires no actions by the IANA. 1024 7. Acknowledgements 1026 Yaron Goland contributed to the discussion on URIs. Patrik Faltstrom 1027 contributed to the background on identifiers. John Klensin 1028 contributed text in a number of different sections. Additional 1029 helpful feedback and suggestions came from Bernard Aboba, Fred Baker, 1030 Leslie Daigle, Mark Davis, Jeff Hodges, Bjoern Hoehrmann, Russ 1031 Housley, Christian Huitema, Magnus Nystrom, Tom Petch, and Chris 1032 Weber. 1034 8. IAB Members at the Time of This Writing 1036 Bernard Aboba 1037 Jari Arkko 1038 Marc Blanchet 1039 Ross Callon 1040 Alissa Cooper 1041 Spencer Dawkins 1042 Joel Halpern 1043 Russ Housley 1044 David Kessens 1045 Danny McPherson 1046 Jon Peterson 1047 Dave Thaler 1048 Hannes Tschofenig 1050 9. Informative References 1052 [I-D.iab-privacy-considerations] 1053 Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 1054 Morris, J., Hansen, M., and R. Smith, "Privacy 1055 Considerations for Internet Protocols", draft-iab-privacy- 1056 considerations-03 (work in progress), July 2012. 1058 [I-D.ietf-6man-uri-zoneid] 1059 Carpenter, B., Cheshire, S., and R. Hinden, "Representing 1060 IPv6 Zone Identifiers in Address Literals and Uniform 1061 Resource Identifiers", draft-ietf-6man-uri-zoneid-06 (work 1062 in progress), December 2012. 1064 [I-D.ietf-pkix-rfc5280-clarifications] 1065 Yee, P., "Updates to the Internet X.509 Public Key 1066 Infrastructure Certificate and Certificate Revocation List 1067 (CRL) Profile", draft-ietf-pkix-rfc5280-clarifications-11 1068 (work in progress), November 2012. 1070 [I-D.ietf-precis-problem-statement] 1071 Blanchet, M. and A. Sullivan, "Stringprep Revision and 1072 PRECIS Problem Statement", draft-ietf-precis-problem- 1073 statement-09 (work in progress), January 2013. 1075 [IAB1123] IAB, , "The interpretation of rules in the ICANN gTLD 1076 Applicant Guidebook", February 2012, . 1081 [IANA-PORT] 1082 IANA, , "PORT NUMBERS", June 2011, 1083 . 1085 [IEEE-1003.1] 1086 IEEE and The Open Group, "The Open Group Base 1087 Specifications, Issue 6 IEEE Std 1003.1, 2004 Edition", 1088 IEEE Std 1003.1, 2004. 1090 [JAVAURL] Oracle, , "Class URL, Java(TM) Platform, Standard Ed. 7", 1091 2011, . 1094 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1095 STD 13, RFC 1034, November 1987. 1097 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application 1098 and Support", STD 3, RFC 1123, October 1989. 1100 [RFC2277] Alvestrand, H.T., "IETF Policy on Character Sets and 1101 Languages", BCP 18, RFC 2277, January 1998. 1103 [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, 1104 "Internationalizing Domain Names in Applications (IDNA)", 1105 RFC 3490, March 2003. 1107 [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode 1108 for Internationalized Domain Names in Applications 1109 (IDNA)", RFC 3492, March 2003. 1111 [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. 1112 Stevens, "Basic Socket Interface Extensions for IPv6", RFC 1113 3493, February 2003. 1115 [RFC3696] Klensin, J., "Application Techniques for Checking and 1116 Transformation of Names", RFC 3696, February 2004. 1118 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1119 Resource Identifier (URI): Generic Syntax", STD 66, RFC 1120 3986, January 2005. 1122 [RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and 1123 B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, 1124 March 2005. 1126 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1127 Architecture", RFC 4291, February 2006. 1129 [RFC4790] Newman, C., Duerst, M., and A. Gulbrandsen, "Internet 1130 Application Protocol Collation Registry", RFC 4790, March 1131 2007. 1133 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 1134 4949, August 2007. 1136 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1137 Housley, R., and W. Polk, "Internet X.509 Public Key 1138 Infrastructure Certificate and Certificate Revocation List 1139 (CRL) Profile", RFC 5280, May 2008. 1141 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 1142 October 2008. 1144 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 1145 October 2008. 1147 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 1148 Address Text Representation", RFC 5952, August 2010. 1150 [RFC6055] Thaler, D., Klensin, J., and S. Cheshire, "IAB Thoughts on 1151 Encodings for Internationalized Domain Names", RFC 6055, 1152 February 2011. 1154 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: 1155 Extension Definitions", RFC 6066, January 2011. 1157 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 1158 Verification of Domain-Based Application Service Identity 1159 within Internet Public Key Infrastructure Using X.509 1160 (PKIX) Certificates in the Context of Transport Layer 1161 Security (TLS)", RFC 6125, March 2011. 1163 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 1164 Cheshire, "Internet Assigned Numbers Authority (IANA) 1165 Procedures for the Management of the Service Name and 1166 Transport Protocol Port Number Registry", BCP 165, RFC 1167 6335, August 2011. 1169 [RFC6530] Klensin, J. and Y. Ko, "Overview and Framework for 1170 Internationalized Email", RFC 6530, February 2012. 1172 [RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized 1173 Email Headers", RFC 6532, February 2012. 1175 [TR36] Unicode Consortium, "Unicode Security Considerations", 1176 Unicode Technical Report 36, August 2004, 1177 . 1179 [USASCII] American National Standards Institute, , "Coded Character 1180 Set -- 7-bit American Standard Code for Information 1181 Interchange", ANSI X3.4, 1986. 1183 [WEBER] Weber, C., "Attacking Software Globalization", March 2010, 1184 . 1187 Author's Address 1189 Dave Thaler (editor) 1190 Microsoft Corporation 1191 One Microsoft Way 1192 Redmond, WA 98052 1193 USA 1195 Phone: +1 425 703 8835 1196 Email: dthaler@microsoft.com