One document matched: draft-iab-identifier-comparison-00.txt
Network Working Group D. Thaler, Ed.
Internet-Draft July 2, 2011
Intended status: Informational
Expires: January 3, 2012
Issues in Identifier Comparison for Security Purposes
draft-iab-identifier-comparison-00.txt
Abstract
Identifiers such as hostnames, URIs/IRIs, and email addresses are
often used in security contexts to identify security principals and
resources. In such contexts, an identifier supplied via some
protocol is often compared against some policy to make security
decisions such as whether the principal may access the resource, what
level of authentication or encryption is required, etc. If the
parties involved in a security decision use different algorithms to
compare identifiers, then failure scenarios ranging from denial of
service to elevation of privilege can result.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 3, 2012.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
Thaler Expires January 3, 2012 [Page 1]
Internet-Draft Identifier Comparison July 2011
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Security Uses . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Types of Identifiers . . . . . . . . . . . . . . . . . . . 6
2.2. False Positives and Negatives . . . . . . . . . . . . . . 6
2.3. Hypothetical Example . . . . . . . . . . . . . . . . . . . 7
3. Common Identifiers . . . . . . . . . . . . . . . . . . . . . . 8
3.1. Hostnames . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1.1. IPv4 Literals . . . . . . . . . . . . . . . . . . . . 8
3.1.2. IPv6 Literals . . . . . . . . . . . . . . . . . . . . 10
3.1.3. Internationalization . . . . . . . . . . . . . . . . . 10
3.1.4. Resolution for comparison . . . . . . . . . . . . . . 12
3.2. Ports and Service Names . . . . . . . . . . . . . . . . . 12
3.3. URIs and IRIs . . . . . . . . . . . . . . . . . . . . . . 12
3.3.1. Scheme component . . . . . . . . . . . . . . . . . . . 13
3.3.2. Authority component . . . . . . . . . . . . . . . . . 13
3.3.3. Path component . . . . . . . . . . . . . . . . . . . . 14
3.3.4. Query component . . . . . . . . . . . . . . . . . . . 14
3.3.5. Fragment component . . . . . . . . . . . . . . . . . . 14
3.4. Email Address-like Identifiers . . . . . . . . . . . . . . 15
4. General Internationalization Issues . . . . . . . . . . . . . 16
5. Security Considerations . . . . . . . . . . . . . . . . . . . 16
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
8. Informative References . . . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19
Thaler Expires January 3, 2012 [Page 2]
Internet-Draft Identifier Comparison July 2011
1. Introduction
In computing and the Internet, various types of "identifiers" are
used to identify humans, devices, content, etc. Before discussing
security issues, we first give some background on the typical
processes involving identifiers.
As depicted in Figure 1, there are multiple processes relevant to our
discussion.
1. An identifier must first be generated. If the identifier is
intended to be unique, the generation process includes some
mechanism, such as allocation by a central authority, to help
ensure uniqueness. However the notion of "unique" involves
determining whether a putative identifier matches other already-
allocated identifiers. As we will see, for many types of
identifiers, this is not simply an exact binary match.
As a result of generating the identifier, it is typically stored
in two locations: with the requester or "holder" of the
identifier, and with some repository of identifiers. For
example, if the identifier was allocated by a central authority,
the repository might be that authority. If the identifier
identifies a device or content on a device, the repository might
be that device.
2. The identifier must be distributed, either by the holder of the
identifier or by a repository of identifiers, to others who could
use the identifier. This distribution might be electronic, but
sometimes it is via other channels such as voice, business card,
billboard, or other form of advertisement. The identifier itself
might be distributed directly, or it might be used to generate a
portion of another type of identifier that is then distributed.
For example, a URI or email address might include a server name,
and hence distributing the URI or email address also inherently
distributes the server name.
3. The identifier must be used by some party. Generally the user
supplies the identifier which is (directly or indirectly) sent to
the repository of identifiers. For example, using an email
address to send email to the holder of an identifier may result
in the email arriving at the holder's email server which has the
repository of all email accounts on that server.
The repository of identifiers must then attempt to match the
user-supplied identifier with an identifier in its repository.
Thaler Expires January 3, 2012 [Page 3]
Internet-Draft Identifier Comparison July 2011
+------------+
| Holder of | 1. Generation
| identifier +<---------+
+----+-------+ |
| | Match
| v/
| +-------+-------+
+----------+ Repository of |
| | identifiers |
| +-------+-------+
2. Distribution | ^\
| | Match
v |
+---------+-------+ |
| User of | |
| identifier +----------+
+-----------------+ 3. Use
Typical Identifier Processes
Figure 1
One key aspect is that the identifier values passed in generation,
distribution, and use, may all be different. For example, generation
might be exchanged in printed form, distribution done via voice, and
use done electronically. As such, the match process can be
complicated.
Furthermore, in many uses, the relationship between holder,
repositories, and users may be more involved. For example, when a
hierarchy of caches exist (as with web pages for example), each cache
is itself a repository of a sort, and the match process should be the
same as on the authoritative web server.
2. Security Uses
Identifiers such as hostnames, URIs/IRIs, and email addresses are
used in security contexts to identify principals and resources as
well as other security parameters such as types and values of claims.
Those identifiers are then used to make security decisions based on
an identifier supplied via some protocol. For example:
o Authentication: a protocol might match a security principal
identifier to look up expected keying material, and then match
keying material.
o Authorization: a protocol might match a resource name to look up
an access control list (ACL), and then look up the security
principal identifier in that ACL.
Thaler Expires January 3, 2012 [Page 4]
Internet-Draft Identifier Comparison July 2011
If the parties involved in a security decision use different matching
algorithms for the same identifiers, then failure scenarios ranging
from denial of service to elevation of privilege can result, as we
will see.
This is especially complicated in cases involving multiple parties
and multiple protocols. For example, there are many scenarios where
some form of "security token service" is used to grant to a requester
permission to access a resource, where the resource is held by a
third party that relies on the security token service. The protocol
used to request permission (e.g., Kerberos or OAuth) may be different
from the protocol used to access the resource (e.g., HTTP).
Opportunities for security problems arise when two protocols define
different comparison algorithms for the same type of identifier, or
when a protocol is ambiguously specified and two endpoints (e.g., a
security token service and a resource holder) implement different
algorithms within the same protocol.
+----------+
| security |
| token |
| service |
+----------+
^
| 1. supply credentials and
| get token for resource
| +--------+
+----------+ 2. supply token and access resource |resource|
|requester |=------------------------------------->| holder |
+----------+ +--------+
Simple Security Exchange
Figure 2
In many cases the situation is more complex. With certificates, the
name in a certificate gets compared to ACLs or other things. In the
case of web site security, the name in the certificate gets compared
to a portion of the URI that a user may have typed into a browser.
The fact that many different people are doing the typing, on many
different types of systems, complicates the problem since it is not
just an administrator that is typing an ACL entry.
Add to this the certificate enrollment step, and the certificate
issuance step, and two more parties have an opportunity to adjust the
encoding or worse, the software that supports them might make changes
that the parties are unaware are happening.
Thaler Expires January 3, 2012 [Page 5]
Internet-Draft Identifier Comparison July 2011
2.1. Types of Identifiers
In this document we will refer to the following types of identifiers:
o Absolute: identifiers that can be compared byte-by-byte for
equality. Two identifiers that have different bytes are defined
to be different. For example, binary IP addresses are in this
class.
o Definite: identifiers that have a well-defined comparison
algorithm on which all parties agree. For example, URI scheme
names are defined to be a case-insensitive match, where the set of
permitted characters results in an unambiguous definition of case-
insensitive match since non-ASCII characters are not permitted.
o Indefinite: identifiers that have no single comparison algorithm
on which all parties agree. For example, human names are in this
class. Everyone might want the comparison to be tailored for
their locale, for some definition of locale. In some cases, there
may be limited subsets of parties that might be able to agree
(e.g., US-ASCII users might all agree on a comparison algorithm
whereas US-ASCII and Turkish users may not), but identifiers often
tend to leak out of such limited environments.
2.2. False Positives and Negatives
Perhaps the most common algorithm for comparison involves
"canonicalization", or converting each identifier to a canonical
form, and then testing the canonical representations for bitwise
equality. In so doing, it is thus critical that all entities
involved agree on the same canonical form and use the same
canonicalization algorithm so that the overall comparison process is
also the same.
It is first worth discussing in more detail the effects of errors in
the comparison algorithm. A "false positive" results when two
identifiers compare as if they were equal, but in reality refer to
two different things (e.g., security principals or resources). When
privilege is granted on a match, a false positive thus results in an
elevation of privilege, for example allowing execution of an
operation that should not have been permitted. When privilege is
denied on a match (e.g., matching an entry in a block/deny list or a
revocation list), a permissable operation is denied. At best, this
can cause worse performance (e.g., a cache miss, or forcing redundant
authentication), and at worst can result in a denial of service.
A "false negative" results when two identifiers that in reality refer
to the same thing compare as if they were different, and the effects
are the reverse of those for false positives. That is, when
privilege is granted on a match, the result is at best worse
Thaler Expires January 3, 2012 [Page 6]
Internet-Draft Identifier Comparison July 2011
performance and at worst a denial of service; when privilege is
denied on a match, elevation of privilege results.
Elevation of privilege is almost always seen as far worse than denial
of service. Hence, for URIs for example, Section 6.1 of [RFC3986]
states: "comparison methods are designed to minimize false negatives
while strictly avoiding false positives".
Thus URIs were defined with a "grant privilege on match" paradigm in
mind, where it is critical to prevent elevation of privilege while
minimizing denial of service. Using URIs in a "deny privilege on
match" system can thus be problematic.
2.3. Hypothetical Example
In this example, both security principals and resources are
identified using URIs. Foo Corp has paid example.com for access to
the stuff service. Foo Corp allows its employees to create accounts
on the stuff service. Alice gets the account
"http://example.com/stuff/FooCorp/alice" and Bob gets
"http://example.com/stuff/FooCorp/bob". It turns out, however, that
Foo Corp's URI canonicalizer includes URI fragment components in
comparisons whereas example.com's does not, and Foo Corp does not
disallow the # character in the account name. So Chuck, who is a
malicious employee of Foo Corp, asks to create an account at
example.com with the name alice#stuff. Foo Corp's URI logic checks
its records for accounts it has created with stuff and sees that
there is no account with the name alice#stuff. Hence, in its
records, it associates the account alice#stuff with Chuck and will
only issue tokens good for use with
"http://example.com/stuff/FooCorp/alice#stuff" to Chuck.
Chuck, the attacker, goes to a security token service at Foo Corp and
asks for a security token good for
"http://example.com/stuff/FooCorp/alice#stuff". Foo Corp issues the
token since Chuck is the legitimate owner (in Foo Corp's view) of the
alice#stuff account. Chuck then submits the security token in a
request to "http://example.com/stuff/FooCorp/alice".
But example.com uses a URI canonicalizer that, for the purposes of
checking equality, ignores fragments. So when example.com looks in
the security token to see if the requester has permission from Foo
Corp to access the given account it successfully matches the URI in
the security token, "http://example.com/stuff/FooCorp/alice#stuff",
with the requested resource name
"http://example.com/stuff/FooCorp/alice".
Leveraging the inconsistencies in the canonicalizers used by Foo Corp
Thaler Expires January 3, 2012 [Page 7]
Internet-Draft Identifier Comparison July 2011
and example.com, Chuck is able to successfully launch an elevation of
privilege attack and access Alice's resource.
3. Common Identifiers
In this section, we walk through a number of common types of
identifiers and discuss various issues related to comparison that may
affect security whenever they are used to identify security
principals or resources. These examples illustrate common patterns
that may arise with other types of identifiers.
3.1. Hostnames
Hostnames are commonly used either directly as identifiers, or as
components in identifiers such as in URIs and email addresses.
Another example is in [RFC5280], sections 7.2 and 7.3 (and updated in
section 3 of [I-D.ietf-pkix-rfc5280-clarifications]), which specify
use in certificates.
In this section we discuss a number of issues in comparing strings
that appear to be some form of hostname.
Section 3 of [RFC6055] discusses "hostname" vs "DNS name". [[anchor6:
TODO: add some discussion here of security impact of names simply
being invalid vs valid-but-different. Failing security checks for
invalid names means that treating a name as invalid can cause a false
negative but not a false positive.]]
3.1.1. IPv4 Literals
[RFC0952] defined an entry in the "Internet host table" as follows:
A "name" (Net, Host, Gateway, or Domain name) is a text string up
to 24 characters drawn from the alphabet (A-Z), digits (0-9),
minus sign (-), and period (.). Note that periods are only
allowed when they serve to delimit components of "domain style
names". [...] No blank or space characters are permitted as part
of a name. No distinction is made between upper and lower case.
The first character must be an alpha character. The last
character must not be a minus sign or period. [...] Single
character names or nicknames are not allowed.
[RFC1123] section 2.1 then updates the definition with:
The syntax of a legal Internet host name was specified in RFC-952
[DNS:4]. One aspect of host name syntax is hereby changed: the
restriction on the first character is relaxed to allow either a
Thaler Expires January 3, 2012 [Page 8]
Internet-Draft Identifier Comparison July 2011
letter or a digit. Host software MUST support this more liberal
syntax.
and
Whenever a user inputs the identity of an Internet host, it SHOULD
be possible to enter either (1) a host domain name or (2) an IP
address in dotted-decimal ("#.#.#.#") form. The host SHOULD check
the string syntactically for a dotted-decimal number before
looking it up in the Domain Name System.
and
This last requirement is not intended to specify the complete
syntactic form for entering a dotted-decimal host number; that is
considered to be a user-interface issue.
In specifying the inet_addr() API, the POSIX standard [IEEE-1003.1]
defines "IPv4 dotted decimal notation" as allowing not only strings
of the form "10.0.1.2", but also allows octal and hexadecimal, and
addresses with less than four parts. For example, "10.0.258",
"0xA000001", and "012.0x102" all represent the same IPv4 address in
standard "IPv4 dotted decimal" notation. We will refer to this as
the "loose" syntax of an IPv4 address literal.
In section 6.1 of [RFC3493] getaddrinfo() is defined to support the
same (loose) syntax as inet_addr():
If the specified address family is AF_INET or AF_UNSPEC, address
strings using Internet standard dot notation as specified in
inet_addr() are valid.
In contrast, section 6.3 of the same RFC states, specifying
inet_pton():
If the af argument of inet_pton() is AF_INET, the src string shall
be in the standard IPv4 dotted-decimal form: ddd.ddd.ddd.ddd where
"ddd" is a one to three digit decimal number between 0 and 255.
The inet_pton() function does not accept other formats (such as
the octal numbers, hexadecimal numbers, and fewer than four
numbers that inet_addr() accepts).
As shown above, inet_pton() uses what we will refer to as the
"strict" form of an IPv4 address literal. Some platforms also use
the strict form with getaddrinfo() when the AI_NUMERICHOST flag is
passed to it.
Both the strict and loose forms are standard forms, and hence a
Thaler Expires January 3, 2012 [Page 9]
Internet-Draft Identifier Comparison July 2011
protocol specification is still ambiguous if it simply defines a
string to be in the "standard IPv4 dotted decimal form". And, as a
result of these differences, names like "10.11.12" are ambiguous as
to whether they are an IP address or a hostname, and even
"10.11.12.13" can be ambiguous because of the "SHOULD" in RFC 1123
above making it optional whether to treat it as an address or a name.
Protocols and data formats that can use addreses in string form for
security purposes need to resolve these ambiguities. For example,
for the host component of URIs, section 3.2.2 of [RFC3986] resolves
the first ambiguity by only allowing the strict form, and the second
ambiguity by specifying that it is considered an IPv4 address
literal. We recommend that new protocols and data formats similarly
use the strict form rather than the loose form.
Thus, whereas (binary) IPv4 addresses are Absolute identifiers, IPv4
address literals are at best Definite identifiers, and often turn out
to be Indefinite identifiers.
Furthermore, when strings can contain non-ASCII characters, they can
contain other characters that may look like dots or digits to a human
viewing and/or entering the identifier, especially to one who might
expect digits to appear in his or her native script.
3.1.2. IPv6 Literals
IPv6 addresses similarly have a wide variety of alternate but
semantically identical string representations, as defined in section
2.2 of [RFC4291]. As discussed in section 3.2.5 of [RFC5952], this
fact causes problems in security contexts if comparison (such as in
X.509 certificates), is done between strings rather than between the
binary representations of addresses.
[RFC5952] recently specified a recommended canonical string format as
an attempt to solve this problem, but it may not be ubiquitously
supported at present. And, when strings can contain non-ASCII
characters, the same issues (and more, since hexadecimal and colons
are allowed) arise as with IPv4 literals.
Whereas (binary) IPv6 addresses are Absolute identifiers, IPv6
address literals are Definite identifiers, since string-to-address
conversion for IPv6 address literals is unambiguous.
3.1.3. Internationalization
The IETF policy on character sets and languages [RFC2277] requires
support for UTF-8 in protocols, and as a result many protocols now do
support non-ASCII characters. When a hostname is sent in a UTF-8
Thaler Expires January 3, 2012 [Page 10]
Internet-Draft Identifier Comparison July 2011
field, there are a number of ways it may be encoded. For example,
labels might encoded directly in UTF-8, or might first be Punycode-
encoded or percent-encoded and then encoded in UTF-8.
For example, in URIs, [RFC3986] section 3.2.2 specifically allows for
the use of percent-encoded UTF-8 characters in the hostname, as well
as the use of IDNA encoding using the Punycode algorithm.
Percent-encoding is unambiguous for hostnames since the percent
character cannot appear in the strict definition of a "hostname",
though it can appear in a DNS name.
Punycode-encoded labels (or "A-labels") on the other hand can be
ambiguous if hosts are actually allowed to be named with a name
starting with "xn--", and false positives can result. While this may
be extremely unlikely for normal scenarios, it nevertheless provides
a possible vector for an attacker.
A hostname comparator used with non-ASCII strings thus needs to
decide whether a Punycode-encoded string should or should not be
considered a valid hostname label, and if so, then whether it should
match the equivalent Unicode string ("U-label").
For example, Section 3.1 of "Transport Layer Security (TLS)
Extensions" [RFC3546], states:
If the hostname labels contain only US-ASCII characters, then the
client MUST ensure that labels are separated only by the byte
0x2E, representing the dot character U+002E (requirement 1 in
section 3.1 of [IDNA] notwithstanding). If the server needs to
match the HostName against names that contain non-US-ASCII
characters, it MUST perform the conversion operation described in
section 4 of [IDNA], treating the HostName as a "query string"
(i.e. the AllowUnassigned flag MUST be set). Note that IDNA
allows labels to be separated by any of the Unicode characters
U+002E, U+3002, U+FF0E, and U+FF61, therefore servers MUST accept
any of these characters as a label separator. If the server only
needs to match the HostName against names containing exclusively
ASCII characters, it MUST compare ASCII names case-insensitively.
[[anchor9: TODO: add observations based on the above text. The text
in RFC 3546 now obsolete since IDNA2008 is much more restrictive
about the use of dot-oids in IDNs. In addition, conversion between
A-labels and Unicode strings that claim to be labels (but not vice
versa) turns slightly ambiguous if mapping is permitted and pre-
mapping strings may appear.]]
For some additional discussion of security issues that arise with
Thaler Expires January 3, 2012 [Page 11]
Internet-Draft Identifier Comparison July 2011
internationalization, see [TR36].
3.1.4. Resolution for comparison
Some systems (specifically Java) used to follow the rule that if two
hostnames resolved to the same IP address then the hostnames were
considered equal. That is, the canonicalization algorithm involved
name resolution with an IP address being the canonical form.
However, with the introduction of dynamic IP addresses, private IP
addresses, multiple IP addresses per name, etc., this method of
comparison cannot be relied upon. There is no guarantee that two
endpoints will resolve the name to the same IP addresses, nor that
the addresses resolved refer to the same entity.
In addition, a comparison mechanism that relies on the ability to
resolve identifiers such as hostnames to other identifies such as IP
addresses leaks information about security decisions to outsiders if
these queries are publicly observable.
3.2. Ports and Service Names
Port numbers and service names are discussed in depth in
[I-D.ietf-tsvwg-iana-ports]. Historically, there were port numbers,
service names used in SRV records, and mnemonic identifiers for
assigned port numbers (known as port "keywords" at [IANA-PORT]). The
latter two are now unified, and various protocols use one or more of
these types in strings. For example, the common syntax used by many
URI schemes allows port numbers but not service names. Some
implementations of the getaddrinfo() API support strings that can be
either port numbers or port keywords (but not service names).
For protocols that use service names that must be resolved, the
issues are the same as those for resolution of addresses in
Section 3.1.4. In addition, Section 5.1 of
[I-D.ietf-tsvwg-iana-ports] clarifies that service names/port
keywords must contain at least one letter. This prevents confusion
with port numbers in strings where both are allowed.
3.3. URIs and IRIs
This section looks at issues related to using URIs for security
purposes. For example, [RFC5280], section 7.4, specifies comparison
of URIs in certificates. Examples of URIs in security token-based
access control systems include WS-*, SAML-P and OAuth WRAP. In such
systems, a variety of participants in the security infrastructure are
identified by URIs. For example, requesters of security tokens are
sometimes identified with URIs. The issuers of security tokens and
the relying parties who are intended to consume security tokens are
Thaler Expires January 3, 2012 [Page 12]
Internet-Draft Identifier Comparison July 2011
frequently identified by URIs. Claims in security tokens often have
their types defined using URIs and the values of the claims can also
be URIs.
Also, when a URI is embedded in plain text (e.g., an email message),
there is an additional concern because there is no termination
criterion for a URL. For example, consider
http://unicode.org/cldr/utility/list-unicodeset.jsp?a=a&g=gc. Some
email clients will stop before the ; while others go to the . As
another point of comparison, Section 2.37 of [EE] (a standard for
history citations) specifies the use of a space after a URI and
before the punctuation.
URIs are defined with multiple components, each of which has their
own rules. We cover each in turn.
3.3.1. Scheme component
[RFC3986] defines URI schemes as being case-insensitive and in
section 6.2.2.1 specifies that scheme names should be normalized to
lower-case characters.
New schemes can be defined over time. In general two URIs with an
unrecognized scheme cannot be safely compared, however. This is
because the canonicalization and comparison rules for the other
components may vary by scheme. For example, a new URI scheme might
have a default port of X, and without that knowledge, a comparison
algorithm cannot know whether "example.com" and "example.com:X"
should be considered to match in the authority component. Hence for
security purposes, it is safest for unrecognized schemes to be
treated as invalid identifiers. However, if the URIs are only used
with a "grant access on match" paradigm then unrecognized schemes can
be supported by doing a generic case-sensitive comparison, at the
expense of some false negatives.
3.3.2. Authority component
The authority component is scheme-specific, but many schemes follow a
common syntax that allows for userinfo, host, and port.
3.3.2.1. Host
Section 3.1 discussed issues with hostnames in general. In addition,
[RFC3986] section 3.2.2 allows future changes using the IPvFuture
production. As with IPv4 and IPv6 literals, IPvFuture formats may
have issues with multiple semantically identical string
representations, and may also be semantically identical to an IPv4 or
IPv6 address. As such, false negatives may be common if IPvFuture is
Thaler Expires January 3, 2012 [Page 13]
Internet-Draft Identifier Comparison July 2011
used.
3.3.2.2. Port
See discussion in Section 3.2.
3.3.2.3. Userinfo
[RFC3986] defines the userinfo production that allows arbitrary data
about the user of the URI to be placed before '@' signs in URIs (see
also Section 3.4. For example:
"http://alice:bob:chuck@example.com/bar" has the value "alice:bob:
chuck" as its userinfo. When comparing URIs in a security context,
one must decide whether to treat the userinfo as being significant or
not. Some URI comparison services for example treat
"http://alice:ick@example.com" and "http://example.com" as being
equal.
3.3.3. Path component
[RFC3986] supports the use of path segment values such as "./" or
"../" for relative URLs. Strictly speaking, including such path
segment values in a fully qualified URI is syntactically illegal but
[RFC3986] section 4.1 nevertheless defines an algorithm to remove
them.
Unless a scheme states otherwise, the path component is defined to be
case-sensitive. However, if the resource is stored and accessed
using a filesystem using case-insensitive paths, there will be many
paths that refer to the same resource. As such, false negatives can
be common in this case.
3.3.4. Query component
There is the question as to whether "http://example.com/foo",
"http://example.com/foo?", and "http://example.com/foo?bar" are each
considered equal or different.
Similarly, it is unspecified whether the order of values matters.
For example, should "http://example.com/blah?ick=bick&foo=bar" be
considered equal to "http://example.com/blah?foo=bar&ick=bick"? And
if a domain name is permitted to appear in a query component (e.g.,
in a reference to another URI), the same issues in Section 3.1 apply.
3.3.5. Fragment component
Some URI formats include fragment identifiers. These are typically
handles to locations within a resource and are used for local
Thaler Expires January 3, 2012 [Page 14]
Internet-Draft Identifier Comparison July 2011
reference. A classic example is the use of fragments in HTTP URLs
where a URL of the form "http://example.com/blah.html#ick" means
retrieve the resource "http://example.com/blah.html" and, once it has
arrived locally, find the HTML anchor named ick and display that.
So, for example, when a user clicks on the link
"http://example.com/blah.html#baz" a browser will check its cache by
doing a URI comparison for "http://example.com/blah.html" and, if the
resource is present in the cache, a match is declared.
Hence comparisons for security purposes should typically ignore the
fragment component and treat all fragments as equal to the full
resource.
3.4. Email Address-like Identifiers
[[anchor19: TODO: this section needs work and will need to be tracked
as EAI WG opinions about the permissibility of A-labels in the domain
part evolves.]]
Section 4.4 of [I-D.ietf-eai-rfc5335bis] defines the encoding for an
internationalized email address, and [RFC5280], section 7.5,
discusses the use of internationalized email addresses in
certificates.
[I-D.ietf-eai-rfc5335bis] use in certificates points to
[I-D.ietf-eai-frmwrk-4952bis] section 9, which contains a discussion
of many issues resulting from internationalization (though no
normative text).
Email address-like identifiers have a local part and a domain part.
The issues with the domain part are essentially the same as with
hostnames, covered earlier.
The local part is left for each domain to define. People quite
commonly use email addresses as usernames with web sites like banks
or shopping sites, but the site doesn't know whether foo@example.com
is the same person as FOO@example.com. Thus email-like identifiers
are typically Indefinite identifiers.
To avoid false positives, some security mechanisms (such as
[RFC5280]) compare the local part using an exact match. Hence, like
URIs, email address-like identifiers are designed for use in grant-
on-match security schemes, not in deny-on-match schemes.
Thaler Expires January 3, 2012 [Page 15]
Internet-Draft Identifier Comparison July 2011
4. General Internationalization Issues
In addition to the issues with hostnames discussed in Section 3.1.3,
there are a number of internationalization issues that apply to many
types of Definite and Indefinite identifiers.
Some strings are visually confusable with others, and hence if a
security decision is made by a user based on visual inspection, many
opportunities for false positives exist. As such, highly secure
systems should not rely on visual inspection.
Determining whether a string is a valid identifier should typically
be done after, or as part of, canonicalization. Otherwise an
attacker might us the canonicalization algorithm to inject (e.g., via
percent encoding, NFKC, or non-shortest-form UTF-8) delimeters such
as '@' in an email address-like identifier, or a '.' in a hostname.
Any case-insensitive comparisons need to define how comparison is
done, since such comparisons may vary by locale of the endpoint. As
such, using case-insensitive comparisons in general often result in
identifiers being either Indefinite or, if the legal character set is
restricted (e.g. to ASCII), then Definite.
See also [WEBER] for a more visual discussion of many of these
issues.
5. Security Considerations
This entire document is about security considerations.
To minimize elevation of privilege issues, for any system that
requires the ability to use both deny and allow operations within the
same identifier space, we recommend the use of Absolute or Definite
identifiers. Use of Absolute identifiers typically provides the
least chance of issues due to bugs.
Perhaps the hardest issues arise when multiple protocols are used
together, such as in the figure in Section 2, where the two protocols
are defined or implemented using different comparison algorithms.
For security protocols (such as security token services) designed to
be used in conjunction with other protocols that access resources,
either:
a. the security protocol should specify the identifier comparison
algorithm, and the security protocol should only be used by
protocols that use the same algorithm; or
Thaler Expires January 3, 2012 [Page 16]
Internet-Draft Identifier Comparison July 2011
b. the security protocol should be capable of supporting multiple
comparison algorithms, and use the one indicated by the using
protocol.
For any new identifiers being designed, we recommend that the
definition specify an Absolute or Definite comparison algorithm, and
if extensibility is allowed (e.g., as new schemes in URIs allow) then
the comparison algorithm should remain invariant so that unrecognized
extensions can be compared.
Some issues (such as unrecognized extensions) can be mitigated by
treating such identifiers as invalid. Validity checking of
identifiers is further discussed in [RFC3696].
6. Acknowledgements
Yaron Goland contributed to much of the discussion on URIs. Patrick
Faltstrom contributed to the background on identifiers. Additional
helpful feedback and suggestions came from Magnus Nystrom, Bernard
Aboba, Mark Davis, John Klensin, and Russ Housley.
7. IANA Considerations
This document requires no actions by the IANA.
8. Informative References
[EE] Mills, E., "Evidence Explained: Citing History Sources
from Artifacts to Cyberspace", 2007.
[I-D.ietf-eai-frmwrk-4952bis]
Klensin, J. and Y. Ko, "Overview and Framework for
Internationalized Email", draft-ietf-eai-frmwrk-4952bis-10
(work in progress), September 2010.
[I-D.ietf-eai-rfc5335bis]
Yang, A. and S. Steele, "Internationalized Email Headers",
draft-ietf-eai-rfc5335bis-10 (work in progress),
March 2011.
[I-D.ietf-pkix-rfc5280-clarifications]
Cooper, D., "Clarifications to the Internet X.509 Public
Key Infrastructure Certificate and Certificate Revocation
List (CRL) Profile",
draft-ietf-pkix-rfc5280-clarifications-02 (work in
Thaler Expires January 3, 2012 [Page 17]
Internet-Draft Identifier Comparison July 2011
progress), March 2011.
[I-D.ietf-tsvwg-iana-ports]
Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
Cheshire, "Internet Assigned Numbers Authority (IANA)
Procedures for the Management of the Service Name and
Transport Protocol Port Number Registry",
draft-ietf-tsvwg-iana-ports-10 (work in progress),
February 2011.
[IANA-PORT]
IANA, "PORT NUMBERS", June 2011,
<http://www.iana.org/assignments/port-numbers>.
[IEEE-1003.1]
IEEE and The Open Group, "The Open Group Base
Specifications, Issue 6 IEEE Std 1003.1, 2004 Edition",
IEEE Std 1003.1, 2004.
[RFC0952] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet
host table specification", RFC 952, October 1985.
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application
and Support", STD 3, RFC 1123, October 1989.
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
Languages", BCP 18, RFC 2277, January 1998.
[RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W.
Stevens, "Basic Socket Interface Extensions for IPv6",
RFC 3493, February 2003.
[RFC3546] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
and T. Wright, "Transport Layer Security (TLS)
Extensions", RFC 3546, June 2003.
[RFC3696] Klensin, J., "Application Techniques for Checking and
Transformation of Names", RFC 3696, February 2004.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Thaler Expires January 3, 2012 [Page 18]
Internet-Draft Identifier Comparison July 2011
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008.
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
Address Text Representation", RFC 5952, August 2010.
[RFC6055] Thaler, D., Klensin, J., and S. Cheshire, "IAB Thoughts on
Encodings for Internationalized Domain Names", RFC 6055,
February 2011.
[TR36] Unicode Consortium, "Unicode Security Considerations",
Unicode Technical Report 36, August 2004.
[WEBER] Weber, C., "Attacking Software Globalization", March 2010,
<http://www.casabasecurity.com/files/
Chris_Weber_Character%20Transformations%20v1.7_IUC33.pdf>.
Author's Address
Dave Thaler (editor)
One Microsoft Way
Redmond, WA 98052
USA
Phone: +1 425 703 8835
Email: dthaler@microsoft.com
Thaler Expires January 3, 2012 [Page 19]
| PAFTECH AB 2003-2026 | 2026-04-23 03:44:25 |