[要約] RFC 6943は、セキュリティ目的のための識別子比較に関する問題を取り上げたものであり、識別子の比較に関連する課題と解決策を提供しています。このRFCの目的は、セキュリティ上の問題を理解し、識別子の比較に関するベストプラクティスを確立することです。
Internet Architecture Board (IAB) D. Thaler, Ed.
Request for Comments: 6943 Microsoft
Category: Informational May 2013
ISSN: 2070-1721
Issues in Identifier Comparison for Security Purposes
セキュリティを目的とした識別子比較の問題
Abstract
概要
Identifiers such as hostnames, URIs, IP addresses, and email addresses are often used in security contexts to identify security principals and resources. In such contexts, an identifier presented via some protocol is often compared using some policy to make security decisions such as whether the security 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. This document provides a discussion of these issues that designers should consider when defining identifiers and protocols, and when constructing architectures that use multiple protocols.
ホスト名、URI、IPアドレス、電子メールアドレスなどの識別子は、セキュリティプリンシパルとリソースを識別するためにセキュリティコンテキストでよく使用されます。このようなコンテキストでは、セキュリティプリンシパルがリソースにアクセスできるかどうか、必要な認証または暗号化のレベルなどのセキュリティ決定を行うために、いくつかのプロトコルを介して提示される識別子がいくつかのポリシーを使用して比較されることがよくあります。さまざまなアルゴリズムを使用して識別子を比較すると、サービス拒否から特権の昇格までの障害シナリオが発生する可能性があります。このドキュメントでは、識別子とプロトコルを定義するとき、および複数のプロトコルを使用するアーキテクチャを構築するときに設計者が考慮すべきこれらの問題について説明します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Architecture Board (IAB) and represents information that the IAB has deemed valuable to provide for permanent record. It represents the consensus of the Internet Architecture Board (IAB). Documents approved for publication by the IAB are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、インターネットアーキテクチャボード（IAB）の製品であり、IABが永続的な記録を提供するために価値があると見なした情報を表しています。これは、インターネットアーキテクチャボード（IAB）のコンセンサスを表しています。 IABによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6943.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6943で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2013 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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 to this document.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Classes of Identifiers .....................................5
1.2. Canonicalization ...........................................5
2. Identifier Use in Security Policies and Decisions ...............6
2.1. False Positives and Negatives ..............................7
2.2. Hypothetical Example .......................................8
3. Comparison Issues with Common Identifiers .......................9
3.1. Hostnames ..................................................9
3.1.1. IPv4 Literals ......................................11
3.1.2. IPv6 Literals ......................................12
3.1.3. Internationalization ...............................13
3.1.4. Resolution for Comparison ..........................14
3.2. Port Numbers and Service Names ............................14
3.3. URIs ......................................................15
3.3.1. Scheme Component ...................................16
3.3.2. Authority Component ................................16
3.3.3. Path Component .....................................17
3.3.4. Query Component ....................................17
3.3.5. Fragment Component .................................17
3.3.6. Resolution for Comparison ..........................18
3.4. Email Address-Like Identifiers ............................18
4. General Issues .................................................19
4.1. Conflation ................................................19
4.2. Internationalization ......................................20
4.3. Scope .....................................................21
4.4. Temporality ...............................................21
5. Security Considerations ........................................22
6. Acknowledgements ...............................................22
7. IAB Members at the Time of Approval ............................23
8. Informative References .........................................23
In computing and the Internet, various types of "identifiers" are used to identify humans, devices, content, etc. This document provides a discussion of some security issues that designers should consider when defining identifiers and protocols, and when constructing architectures that use multiple protocols. Before discussing these security issues, we first give some background on some typical processes involving identifiers. Terms such as "identifier", "identity", and "principal" are used as defined in [RFC4949].
コンピューティングとインターネットでは、人間、デバイス、コンテンツなどを識別するためにさまざまなタイプの「識別子」が使用されます。このドキュメントでは、識別子とプロトコルを定義するとき、および複数のアーキテクチャを構築するときに設計者が考慮すべきいくつかのセキュリティ問題について説明しますプロトコル。これらのセキュリティ問題を説明する前に、識別子を含むいくつかの典型的なプロセスの背景について説明します。 「identifier」、「identity」、「principal」などの用語は、[RFC4949]で定義されているように使用されます。
As depicted in Figure 1, there are multiple processes relevant to our discussion.
図1に示すように、ここでの説明に関連するプロセスは複数あります。
1. An identifier is first generated. If the identifier is intended to be unique, the generation process must include some mechanism, such as allocation by a central authority or verification among the members of a distributed authority, to help ensure uniqueness. However, the notion of "unique" involves determining whether a putative identifier matches any other identifier that has already been allocated. As we will see, for many types of identifiers, this is not simply an exact binary match.
1. 識別子が最初に生成されます。識別子が一意であることを意図している場合、生成プロセスには、中央機関による割り当てや分散された機関のメンバー間の検証など、一意性を確保するためのメカニズムが含まれている必要があります。ただし、「一意」の概念には、推定識別子がすでに割り当てられている他の識別子と一致するかどうかを判断することが含まれます。後で説明するように、多くのタイプの識別子では、これは単なる正確なバイナリの一致ではありません。
After generating the identifier, it is often stored in two locations: with the requester or "holder" of the identifier, and with some repository of identifiers (e.g., DNS). 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つの場所に格納されます。識別子の要求者または「所有者」と、識別子のリポジトリ（DNSなど）です。たとえば、識別子が中央機関によって割り当てられた場合、リポジトリはその機関である可能性があります。識別子がデバイスまたはデバイス上のコンテンツを識別する場合、リポジトリはそのデバイスである可能性があります。
2. The identifier is 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.
2. 識別子は、識別子の所有者または識別子のリポジトリのいずれかによって、その識別子を使用できる他の人に配布されます。この配布は電子的である場合がありますが、音声、名刺、看板、または他の形式の広告などの他のチャネルを介して行われることもあります。識別子自体を直接配布することも、別の種類の識別子の一部を生成して配布するために使用することもできます。たとえば、URIまたは電子メールアドレスにサーバー名が含まれている可能性があるため、URIまたは電子メールアドレスを配布すると、本質的にサーバー名も配布されます。
3. The identifier is used by some party. Generally, the user supplies the identifier, which is (directly or indirectly) sent to the repository of identifiers. The repository of identifiers must then attempt to match the user-supplied identifier with an identifier in its repository.
3. 識別子は、一部の当事者によって使用されます。一般に、ユーザーは識別子を指定します。これは（直接的または間接的に）識別子のリポジトリに送信されます。次に、識別子のリポジトリは、ユーザーが指定した識別子とそのリポジトリ内の識別子を照合する必要があります。
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 access to the mail stores.
たとえば、メールアドレスを使用して識別子の所有者にメールを送信すると、メールストアにアクセスできる所有者のメールサーバーにメールが届く場合があります。
+------------+
| Holder of | 1. Generation
| identifier +<---------+
+----+-------+ |
| | Match
| v/
| +-------+-------+
+----------+ Repository of |
| | identifiers |
| +-------+-------+
2. Distribution | ^\
| | Match
v |
+---------+-------+ |
| User of | |
| identifier +----------+
+-----------------+ 3. Use
Figure 1: Typical Identifier Processes
図1：一般的な識別子プロセス
Another variation is where a user is given the identifier of a resource (e.g., a web site) to access securely, sometimes known as a "reference identifier" [RFC6125], and the server hosting the resource then presents its identity at the time of use. In this case, the user application attempts to match the presented identity against the reference identifier.
別のバリエーションは、安全にアクセスするためのリソース（Webサイトなど）の識別子（「参照識別子」[RFC6125]と呼ばれることもある）がユーザーに与えられ、リソースをホストするサーバーがその時点でそのIDを提示する場合です。使用する。この場合、ユーザーアプリケーションは、提示されたIDを参照識別子と照合しようとします。
One key aspect is that the identifier values passed in generation, distribution, and use may all be in different forms. For example, an identifier might be exchanged in printed form at generation time, distributed to a user via voice, and then used electronically. As such, the match process can be complicated.
重要な点の1つは、生成、配布、および使用で渡される識別子の値がすべて異なる形式であることです。たとえば、識別子は生成時に印刷された形式で交換され、音声を介してユーザーに配布され、電子的に使用されます。そのため、照合プロセスは複雑になる可能性があります。
Furthermore, in many cases, the relationship between holder, repositories, and users may be more involved. For example, when a hierarchy of web caches exists, each cache is itself a repository of a sort, and the match process is usually intended to be the same as on the origin server.
さらに、多くの場合、所有者、リポジトリ、およびユーザー間の関係がより複雑になる可能性があります。たとえば、Webキャッシュの階層が存在する場合、各キャッシュはそれ自体が一種のリポジトリであり、照合プロセスは通常、元のサーバーと同じであることが意図されています。
Another aspect to keep in mind is that there can be multiple identifiers that refer to the same object (i.e., resource, human, device, etc.). For example, a human might have a passport number and a drivers license number, and an RFC might be available at multiple locations (rfc-editor.org and ietf.org). In this document, we focus on comparing two identifiers to see whether they are the same identifier, rather than comparing two different identifiers to see whether they refer to the same entity (although a few issues with the latter are touched on in several places, such as Sections 3.1.4 and 3.3.6).
留意すべきもう1つの側面は、同じオブジェクト（リソース、人、デバイスなど）を参照する識別子が複数存在する可能性があることです。たとえば、人間にはパスポート番号と運転免許証番号があり、RFCは複数の場所（rfc-editor.orgおよびietf.org）で利用できる場合があります。このドキュメントでは、2つの異なる識別子を比較して同じエンティティを参照しているかどうかを確認するのではなく、2つの識別子を比較して同じ識別子であるかどうかを確認することに重点を置いています（後者に関するいくつかの問題については、いくつかの場所で触れていますが、セクション3.1.4および3.3.6として）。
In this document, we will refer to the following classes 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 絶対：バイトごとに等しいかどうかを比較できる識別子。異なるバイトを持つ2つの識別子は異なるものとして定義されます。たとえば、バイナリIPアドレスはこのクラスにあります。
o Definite: identifiers that have a single well-defined comparison algorithm. For example, URI scheme names are required to be US-ASCII [USASCII] and are defined to match in a case-insensitive way; the comparison is thus definite, since there is a well-specified algorithm (Section 9.2.1 of [RFC4790]) on how to do a case-insensitive match among ASCII strings.
o 明確：明確に定義された単一の比較アルゴリズムを持つ識別子。たとえば、URIスキーム名はUS-ASCII [USASCII]である必要があり、大文字と小文字を区別しない方法で一致するように定義されています。したがって、ASCII文字列間で大文字と小文字を区別しない一致を行う方法については、十分に指定されたアルゴリズム（[RFC4790]のセクション9.2.1）があるため、比較は明確です。
o Indefinite: identifiers that have no single well-defined comparison algorithm. 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., ASCII users might all agree on a common comparison algorithm, whereas users of other Roman-derived scripts, such as Turkish, may not), but identifiers often tend to leak out of such limited environments.
o 不定：明確に定義された単一の比較アルゴリズムを持たない識別子。たとえば、人間の名前はこのクラスにあります。だれもが「ロケール」の定義のために、比較を自分のロケールに合わせて調整したいと思うかもしれません。場合によっては、同意できる当事者のサブセットが限られている可能性があります（たとえば、ASCIIユーザーはすべて共通の比較アルゴリズムに同意する可能性がありますが、トルコ語などの他のローマ語由来のスクリプトのユーザーは同意しない可能性があります）。多くの場合、そのような限られた環境から漏れがちです。
Perhaps the most common algorithm for comparison involves first converting each identifier to a canonical form (a process known as "canonicalization" or "normalization") and then testing the resulting 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.
おそらく最も一般的な比較アルゴリズムは、最初に各識別子を正規形（「正規化」または「正規化」として知られているプロセス）に変換し、次にビットごとの等価性について結果の正規表現をテストすることを含みます。したがって、そうすることで、関係するすべてのエンティティが同じ正規形に同意し、同じ正規化アルゴリズムを使用して、全体的な比較プロセスも同じになることが重要です。
Note that in some contexts, such as in internationalization, the terms "canonicalization" and "normalization" have a precise meaning. In this document, however, we use these terms synonymously in their more generic form, to mean conversion to some standard form.
国際化などの一部のコンテキストでは、「正規化」および「正規化」という用語は正確な意味を持っていることに注意してください。ただし、このドキュメントでは、これらの用語をより一般的な形式で同義に使用して、標準形式への変換を意味します。
While the most common method of comparison includes canonicalization, comparison can also be done by defining an equivalence algorithm, where no single form is canonical. However, in most cases, a canonical form is useful for other purposes, such as output, and so in such cases defining a canonical form suffices to define a comparison method.
最も一般的な比較方法には正規化が含まれますが、単一形式が正規化されていない等価アルゴリズムを定義することで比較を行うこともできます。ただし、ほとんどの場合、標準形式は出力などの他の目的に役立ちます。そのため、このような場合、標準形式を定義するだけで、比較方法を定義できます。
Identifiers such as hostnames, URIs, and email addresses are used in security contexts to identify security principals (i.e., entities that can be authenticated) 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 presented via some protocol. For example:
ホスト名、URI、電子メールアドレスなどの識別子は、セキュリティコンテキストで使用され、セキュリティプリンシパル（つまり、認証可能なエンティティ）とリソース、およびクレームのタイプや値などの他のセキュリティパラメータを識別します。これらの識別子は、いくつかのプロトコルを介して提示された識別子に基づいてセキュリティの決定を行うために使用されます。例えば：
o Authentication: a protocol might match a security principal's identifier to look up expected keying material and then match keying material.
o 認証：プロトコルは、セキュリティプリンシパルの識別子と一致して、予期されるキー情報を検索し、キー情報と一致する場合があります。
o Authorization: a protocol might match a resource name against some policy. For example, it might look up an access control list (ACL) and then look up the security principal's identifier (or a surrogate for it) in that ACL.
o 許可：プロトコルは、リソース名をポリシーと照合する場合があります。たとえば、アクセス制御リスト（ACL）を検索し、そのACLでセキュリティプリンシパルの識別子（またはその代理）を検索する場合があります。
o Accounting: a system might create an accounting record for a security principal's identifier or resource name, and then might later need to match a presented identifier to (for example) add new filtering rules based on the records in order to stop an attack.
o アカウンティング：システムは、セキュリティプリンシパルの識別子またはリソース名のアカウンティングレコードを作成し、後で提示された識別子と照合して、たとえば、攻撃を阻止するために、レコードに基づいて新しいフィルタリングルールを追加する必要がある場合があります。
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 (see Figure 2). 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.
これは、複数の当事者と複数のプロトコルが関係する場合には特に複雑です。たとえば、リクエスタにリソースへのアクセス許可を付与するために「セキュリティトークンサービス」の何らかの形式が使用される多くのシナリオがあり、リソースはセキュリティトークンサービスに依存するサードパーティによって保持されます（図2を参照） 。権限の要求に使用されるプロトコル（KerberosまたはOAuthなど）は、リソースへのアクセスに使用されるプロトコル（HTTPなど）とは異なる場合があります。 2つのプロトコルが同じタイプの識別子に対して異なる比較アルゴリズムを定義している場合、またはプロトコルが曖昧に指定されており、2つのエンドポイント（セキュリティトークンサービスとリソースホルダーなど）が同じプロトコル内で異なるアルゴリズムを実装している場合、セキュリティ上の問題が発生する可能性があります。
+----------+
| security |
| token |
| service |
+----------+
^
| 1. supply credentials and
| get token for resource
| +--------+
+----------+ 2. supply token and access resource |resource|
|requester |=------------------------------------->| holder |
+----------+ +--------+
Figure 2: Simple Security Exchange
図2：単純なセキュリティ交換
In many cases, the situation is more complex. With X.509 Public Key Infrastructure (PKIX) certificates [RFC6125], for example, the name in a certificate gets compared against names in 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.
多くの場合、状況はより複雑です。たとえば、X.509公開鍵インフラストラクチャ（PKIX）証明書[RFC6125]を使用すると、証明書の名前がACLなどの名前と比較されます。 Webサイトのセキュリティの場合、証明書の名前は、ユーザーがブラウザに入力したURIの一部と比較されます。多くの異なるタイプのシステムで多くの異なる人々がタイピングを行っているという事実が問題を複雑にしています。
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.
これに証明書の登録手順と証明書の発行手順を追加します。さらに2人の当事者がエンコードを調整する機会を得ます。さらに悪いことに、それらをサポートするソフトウェアは、当事者が気付いていない変更を加える可能性があります。
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 objects (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 otherwise. When privilege is denied on a match (e.g., matching an entry in a block/deny list or a revocation list), a permissible 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.
最初に、比較アルゴリズムのエラーの影響について詳しく説明します。 2つの識別子が等しいかのように比較するが、実際には2つの異なるオブジェクト（セキュリティプリンシパルやリソースなど）を参照すると、「誤検出」が発生します。したがって、一致に対して特権が付与されると、誤検知によって特権が昇格します。たとえば、本来は許可されていないはずの操作の実行が許可されます。一致に対して特権が拒否された場合（ブロック/拒否リストまたは失効リストのエントリの一致など）、許可される操作は拒否されます。せいぜい、これはパフォーマンスの低下（キャッシュミスや冗長認証の強制など）を引き起こす可能性があり、最悪の場合、サービス拒否を引き起こす可能性があります。
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 performance and at worst a denial of service; when privilege is denied on a match, elevation of privilege results.
「偽陰性」は、実際には同じものを参照する2つの識別子が異なるかのように比較され、その結果が偽陽性の場合と逆になる場合に発生します。つまり、試合で特権が付与された場合、結果はせいぜいパフォーマンスが低下し、最悪の場合はサービス拒否になります。一致で特権が拒否されると、特権の昇格が発生します。
Figure 3 summarizes these effects.
図3は、これらの影響をまとめたものです。
| "Grant on match" | "Deny on match"
---------------+------------------------+-----------------------
False positive | Elevation of privilege | Denial of service
---------------+------------------------+-----------------------
False negative | Denial of service | Elevation of privilege
---------------+------------------------+-----------------------
Figure 3: Worst Effects of False Positives/Negatives
図3：偽陽性/陰性の最悪の影響
When designing a comparison algorithm, one can typically modify it to increase the likelihood of false positives and decrease the likelihood of false negatives, or vice versa. Which outcome is better depends on the context.
比較アルゴリズムを設計する場合、通常はそれを変更して、誤検知の可能性を高め、誤検知の可能性を減らすか、またはその逆を行うことができます。どの結果がより良いかは、状況に依存します。
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 that "comparison methods are designed to minimize false negatives while strictly avoiding false positives".
特権の昇格は、ほとんどの場合、サービス拒否よりもはるかに悪いと見なされています。したがって、たとえば、URIの場合、[RFC3986]のセクション6.1は、「比較手法は、誤検知を最小限に抑えながら、誤検知を最小限に抑えるように設計されている」と述べています。
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.
したがって、URIは「一致時に特権を付与する」パラダイムを念頭に置いて定義されました。サービス拒否を最小限に抑えながら特権の昇格を防ぐことが重要です。したがって、「一致に対する特権の拒否」システムでURIを使用すると問題が発生する可能性があります。
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.
この例では、セキュリティプリンシパルとリソースの両方がURIを使用して識別されます。 Foo Corpは、Stuffサービスへのアクセスに対してexample.comに支払いました。 Foo Corpは、スタッフがStuffサービスでアカウントを作成することを許可しています。アリスはアカウント「http://example.com/Stuff/FooCorp/alice」を取得し、ボブは「http://example.com/Stuff/FooCorp/bob」を取得します。ただし、Foo CorpのURI canonicalizerには比較でURIフラグメントコンポーネントが含まれていますが、example.comには含まれておらず、Foo Corpではアカウント名に＃文字を使用できません。したがって、Foo Corpの悪意のある従業員であるChuckは、example.comにalice＃stuffという名前のアカウントを作成するように依頼します。 Foo CorpのURIロジックは、stuffで作成したアカウントのレコードをチェックし、alice＃stuffという名前のアカウントがないことを確認します。したがって、そのレコードでは、アカウントalice＃stuffをChuckに関連付け、「http://example.com/Stuff/FooCorp/alice#stuff」での使用に適したトークンのみを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".
攻撃者のチャックは、Foo Corpのセキュリティトークンサービスにアクセスし、「http://example.com/Stuff/FooCorp/alice#stuff」に適したセキュリティトークンを要求します。 Foo Corpがトークンを発行します。これは、Chuckがalice＃stuffアカウントの正当な所有者（Foo Corpから見た場合）であるためです。その後、チャックは「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".
しかし、example.comは、等価性をチェックする目的でフラグメントを無視するURI正規化子を使用します。したがって、example.comがセキュリティトークンを調べて、リクエスタがFoo Corpから特定のアカウントにアクセスする権限を持っているかどうかを確認すると、セキュリティトークンのURI「http://example.com/Stuff/FooCorp/alice」と正常に一致します。 #stuff "、リクエストされたリソース名は" http://example.com/Stuff/FooCorp/alice "。
Leveraging the inconsistencies in the canonicalizers used by Foo Corp and example.com, Chuck is able to successfully launch an elevation-of-privilege attack and access Alice's resource.
Foo Corpとexample.comで使用されている正規化子の不整合を利用して、チャックは特権の昇格攻撃を開始し、アリスのリソースにアクセスできます。
Furthermore, consider an attacker using a similar corporation, such as "foocorp" (or any variation containing a non-ASCII character that some humans might expect to represent the same corporation). If the resource holder treats them as different but the security token service treats them as the same, then elevation of privilege can occur in this scenario as well.
さらに、 "foocorp"（または一部の人間が同じ企業を表すと期待する可能性のある非ASCII文字を含むすべてのバリエーション）などの同様の企業を使用する攻撃者を検討してください。リソースホルダーがそれらを異なるものとして扱い、セキュリティトークンサービスが同じものとして扱う場合、このシナリオでも特権の昇格が発生する可能性があります。
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.
このセクションでは、いくつかの一般的な種類の識別子について説明し、セキュリティプリンシパルまたはリソースの識別に使用される場合にセキュリティに影響を与える可能性がある比較に関連するさまざまな問題について説明します。これらの例は、他のタイプの識別子で発生する可能性のある一般的なパターンを示しています。
Hostnames (composed of dot-separated labels) are commonly used either directly as identifiers, or as components in identifiers such as in URIs and email addresses. Another example is in Sections 7.2 and 7.3 of [RFC5280] (and updated in Section 3 of [RFC6818]), which specify use in PKIX certificates.
ホスト名（ドットで区切られたラベルで構成される）は、通常、識別子として直接使用されるか、URIや電子メールアドレスなどの識別子のコンポーネントとして使用されます。別の例は、[RFC5280]のセクション7.2と7.3であり（[RFC6818]のセクション3で更新されています）、PKIX証明書での使用を指定しています。
In this section, we discuss a number of issues in comparing strings that appear to be some form of hostname.
このセクションでは、何らかの形式のホスト名のように見える文字列を比較する際のいくつかの問題について説明します。
It is first worth pointing out that the term "hostname" itself is often ambiguous, and hence it is important that any use clarify which definition is intended. Some examples of definitions include:
「ホスト名」という用語自体はあいまいであることが多いので、最初に指摘しておく必要があります。したがって、どの定義でも、意図する定義を明確にすることが重要です。定義の例には次のものがあります。
a. A Fully Qualified Domain Name (FQDN),
a. 完全修飾ドメイン名（FQDN）、
b. An FQDN that is associated with address records in the DNS,
b. DNSのアドレスレコードに関連付けられているFQDN、
c. The leftmost label in an FQDN, or
c. FQDNの左端のラベル、または
d. The leftmost label in an FQDN that is associated with address records.
d. アドレスレコードに関連付けられているFQDNの左端のラベル。
The use of different definitions in different places results in questions such as whether "example" and "example.com" are considered equal or not, and hence it is important when writing new specifications to be clear about which definition is meant.
異なる場所で異なる定義を使用すると、「example」と「example.com」が等しいと見なされるかどうかなどの問題が発生するため、新しい定義を作成するときは、どの定義が意味されるかを明確にすることが重要です。
Section 3 of [RFC6055] discusses the differences between a "hostname" and a "DNS name", where the former is a subset of the latter by using a restricted set of characters (letters, digits, and hyphens). If one canonicalizer uses the "DNS name" definition whereas another uses a "hostname" definition, a name might be valid in the former but invalid in the latter. As long as invalid identifiers are denied privilege, this difference will not result in elevation of privilege.
[RFC6055]のセクション3では、「ホスト名」と「DNS名」の違いについて説明します。前者は制限された文字のセット（文字、数字、ハイフン）を使用することによる後者のサブセットです。あるカノニカライザが「DNS名」定義を使用し、別のカノニカライザが「ホスト名」定義を使用する場合、名前は前者では有効であるが、後者では無効である可能性があります。無効な識別子が特権を拒否されている限り、この違いによって特権が昇格されることはありません。
Section 3.1 of [RFC1034] discusses the difference between a "complete" domain name, which ends with a dot (such as "example.com."), and a multi-label relative name such as "example.com" that assumes the root (".") is in the suffix search list. In most contexts, these are considered equal, but there may be issues if different entities in a security architecture have different interpretations of a relative domain name.
[RFC1034]のセクション3.1は、ドットで終わる「完全な」ドメイン名（「example.com。」など）と、「example.com」などのマルチラベル相対名の違いを説明しています。ルート（ "。"）はサフィックス検索リストにあります。ほとんどのコンテキストでは、これらは等しいと見なされますが、セキュリティアーキテクチャの異なるエンティティが相対ドメイン名の異なる解釈を持っている場合、問題が発生する可能性があります。
[IAB1123] briefly discusses issues with the ambiguity around whether a label will be "alphabetic" -- including, among other issues, how "alphabetic" should be interpreted in an internationalized environment -- and whether a hostname can be interpreted as an IP address. We explore this last issue in more detail below.
[IAB1123]は、ラベルが「アルファベット」になるかどうかのあいまいさの問題、特に国際化された環境で「アルファベット」をどのように解釈すべきか、およびホスト名をIPアドレスとして解釈できるかどうかについて簡単に説明します。この最後の問題については、以下で詳しく説明します。
Section 2.1 of [RFC1123] states:
[RFC1123]のセクション2.1には次のように記載されています。
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.
ユーザーがインターネットホストのIDを入力するときは常に、（1）ホストドメイン名または（2）IPアドレスをドット付き10進数（ "＃。＃。＃。＃"）形式で入力できるようにする必要があります。ホストは、ドメインネームシステムで検索する前に、ドットで区切られた10進数の文字列を構文的にチェックする必要があります（SHOULD）。
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.
この最後の要件は、小数点付き10進数のホスト番号を入力するための完全な構文形式を指定することを意図したものではありません。これはユーザーインターフェイスの問題と見なされます。
In specifying the inet_addr() API, the Portable Operating System Interface (POSIX) standard [IEEE-1003.1] defines "IPv4 dotted decimal notation" as allowing not only strings of the form "10.0.1.2" but also allowing octal and hexadecimal, and addresses with less than four parts. For example, "10.0.258", "0xA000102", 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.
inet_addr()APIを指定する際、Portable Operating System Interface（POSIX）標準[IEEE-1003.1]は、「IPv4ドット10進表記」を「10.0.1.2」形式の文字列だけでなく、8進数および16進数も許可するものとして定義しています。パーツが4つ未満のアドレス。たとえば、「10.0.258」、「0xA000102」、および「012.0x102」はすべて、標準の「IPv4ドット10進」表記で同じIPv4アドレスを表します。これをIPv4アドレスリテラルの「緩い」構文と呼びます。
In Section 6.1 of [RFC3493], getaddrinfo() is defined to support the same (loose) syntax as inet_addr():
[RFC3493]のセクション6.1では、getaddrinfo()は、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.
指定されたアドレスファミリーがAF_INETまたはAF_UNSPECの場合、inet_addr()で指定されたインターネット標準ドット表記を使用したアドレス文字列が有効です。
In contrast, Section 6.3 of the same RFC states, specifying inet_pton():
対照的に、同じRFCのセクション6.3では、inet_pton()を指定しています。
If the af argument of inet_pton() is AF_INET, the src string shall be in the standard IPv4 dotted-decimal form:
inet_pton()のaf引数がAF_INETの場合、src文字列は標準のIPv4ドット付き10進形式でなければなりません。
ddd.ddd.ddd.ddd
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).
ここで、「ddd」は0から255までの1から3桁の10進数です。inet_pton()関数は、他の形式（8進数、16進数、およびinet_addr()が受け入れる4未満の数値など）を受け入れません。
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.
上記のように、inet_pton()は、IPv4アドレスリテラルの「厳密な」形式と呼ばれるものを使用します。一部のプラットフォームでは、AI_NUMERICHOSTフラグが渡されたときにgetaddrinfo()で厳密な形式も使用します。
Both the strict and loose forms are standard forms, and hence a 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 such as "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 the above text from RFC 1123, making it optional whether to treat it as an address or a DNS name.
厳密な形式とルーズな形式の両方が標準形式であるため、「標準のIPv4ドット10進形式」の文字列を定義するだけでは、プロトコル仕様はあいまいです。そして、これらの違いの結果として、「10.11.12」などの名前は、IPアドレスであるかホスト名であるかについてあいまいであり、「10.11.12.13」でさえ、上記の「SHOULD」のためにあいまいになる可能性があります。 RFC 1123からのテキスト。アドレスとして処理するかDNS名として処理するかをオプションにします。
Protocols and data formats that can use addresses 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 resolves the second ambiguity by specifying that it is considered an IPv4 address literal. New protocols and data formats should similarly consider using the strict form rather than the loose form in order to better match user expectations.
セキュリティ上の目的で文字列形式のアドレスを使用できるプロトコルとデータ形式は、これらのあいまいさを解決する必要があります。たとえば、URIのホストコンポーネントの場合、[RFC3986]のセクション3.2.2は、厳密な形式のみを許可することで最初のあいまいさを解決し、IPv4アドレスリテラルと見なされることを指定することで2番目のあいまいさを解決します。新しいプロトコルとデータ形式も同様に、ユーザーの期待によりよく一致させるために、ルーズフォームではなくストリクトフォームの使用を検討する必要があります。
A string might be valid under the "loose" definition but invalid under the "strict" definition. As long as invalid identifiers are denied privilege, this difference will not result in elevation of privilege. Some protocols, however, use strings that can be either an IP address literal or a hostname. Such strings are at best Definite identifiers, and often turn out to be Indefinite identifiers. (See Section 4.1 for more discussion.)
文字列は、「緩い」定義では有効ですが、「厳密な」定義では無効です。無効な識別子が特権を拒否されている限り、この違いによって特権が昇格されることはありません。ただし、一部のプロトコルは、IPアドレスリテラルまたはホスト名のいずれかになる文字列を使用します。このような文字列はせいぜい明確な識別子であり、多くの場合、不明確な識別子になります。 （詳細については、セクション4.1を参照してください。）
IPv6 addresses similarly have a wide variety of alternate but semantically identical string representations, as defined in Section 2.2 of [RFC4291] and Section 2 of [RFC6874]. As discussed in Section 3.2.5 of [RFC5952], this fact causes problems in security contexts if comparison (such as in PKIX certificates) is done between strings rather than between the binary representations of addresses.
[RFC4291]のセクション2.2と[RFC6874]のセクション2で定義されているように、IPv6アドレスも同様に、多種多様な代替ですが意味的に同一の文字列表現を持っています。 [RFC5952]のセクション3.2.5で説明されているように、アドレスのバイナリ表現間ではなく文字列間で比較（PKIX証明書など）が行われる場合、この事実によりセキュリティコンテキストで問題が発生します。
[RFC5952] 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.
[RFC5952]は、この問題を解決するための試みとして、推奨される正規の文字列形式を指定しましたが、現時点では広くサポートされていない可能性があります。また、文字列に非ASCII文字を含めることができる場合、IPv4リテラルと同じ問題（16進数とコロンを使用できるため、さらに多くの問題）が発生します。
Whereas (binary) IPv6 addresses are Absolute identifiers, IPv6 address literals are Definite identifiers, since string-to-address conversion for IPv6 address literals is unambiguous.
（バイナリ）IPv6アドレスは絶対識別子ですが、IPv6アドレスリテラルの文字列からアドレスへの変換は明確であるため、IPv6アドレスリテラルは明確な識別子です。
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 field, there are a number of ways it may be encoded. For example, hostname labels might be encoded directly in UTF-8, or they might first be Punycode-encoded [RFC3492] or even percent-encoded from UTF-8.
文字セットと言語に関するIETFポリシー[RFC2277]では、プロトコルでUTF-8をサポートする必要があるため、多くのプロトコルで非ASCII文字がサポートされるようになりました。ホスト名がUTF-8フィールドで送信される場合、エンコードされる方法はいくつかあります。たとえば、ホスト名ラベルはUTF-8で直接エンコードされる場合もあれば、最初にPunycodeエンコード[RFC3492]される場合や、UTF-8からパーセントエンコードされる場合もあります。
For example, in URIs, Section 3.2.2 of [RFC3986] specifically allows for the use of percent-encoded UTF-8 characters in the hostname as well as the use of Internationalized Domain Names in Applications (IDNA) encoding [RFC3490] using the Punycode algorithm.
たとえば、URIの場合、[RFC3986]のセクション3.2.2では、ホスト名にパーセントエンコードされたUTF-8文字を使用できるほか、アプリケーションで国際化ドメイン名（IDNA）を使用して[RFC3490]を使用できます。 Punycodeアルゴリズム。
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.
パーセントエンコーディングは、ホスト名の明確な定義では使用できませんが、DNS名では使用できます。
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.
一方、Punycodeでエンコードされたラベル（または「Aラベル」）は、ホストに「xn--」で始まる名前を実際に付けることが許可されている場合、あいまいになる可能性があり、誤検出が発生する可能性があります。これは通常のシナリオでは非常にありそうもないことですが、それでも攻撃者に可能なベクターを提供します。
A hostname comparator thus needs to decide whether a Punycode-encoded label should or should not be considered a valid hostname label, and if so, then whether it should match a label encoded in some other form such as a percent-encoded Unicode label (U-label).
したがって、ホスト名コンパレータは、Punycodeでエンコードされたラベルを有効なホスト名ラベルと見なすかどうかを判断する必要があり、そうである場合は、パーセントエンコードされたUnicodeラベル（U -ラベル）。
For example, Section 3 of "Transport Layer Security (TLS) Extensions: Extension Definitions" [RFC6066] states:
たとえば、「Transport Layer Security（TLS）Extensions：Extension Definitions」[RFC6066]のセクション3には、次のように記載されています。
"HostName" contains the fully qualified DNS hostname of the server, as understood by the client. The hostname is represented as a byte string using ASCII encoding without a trailing dot. This allows the support of internationalized domain names through the use of A-labels defined in [RFC5890]. DNS hostnames are case-insensitive. The algorithm to compare hostnames is described in [RFC5890], Section 2.3.2.4.
「HostName」には、クライアントが理解できるサーバーの完全修飾DNSホスト名が含まれています。ホスト名は、末尾にドットがないASCIIエンコーディングを使用したバイト文字列として表されます。これにより、[RFC5890]で定義されているAラベルを使用して、国際化ドメイン名をサポートできます。 DNSホスト名は大文字と小文字を区別しません。ホスト名を比較するアルゴリズムは、[RFC5890]のセクション2.3.2.4で説明されています。
For some additional discussion of security issues that arise with internationalization, see Section 4.2 and [TR36].
国際化に伴って発生するセキュリティ問題の追加の説明については、セクション4.2と[TR36]を参照してください。
Some systems (specifically Java URLs [JAVAURL]) use the rule that if two hostnames resolve to the same IP address(es) then the hostnames are considered equal. That is, the canonicalization algorithm involves name resolution with an IP address being the canonical form.
一部のシステム（特にJava URL [JAVAURL]）は、2つのホスト名が同じIPアドレスに解決される場合、ホスト名は等しいと見なされるというルールを使用します。つまり、正規化アルゴリズムには名前解決が含まれ、IPアドレスは正規形式です。
For example, if resolution was done via DNS, and DNS contained:
たとえば、解決がDNSを介して行われ、DNSに次のものが含まれている場合：
example.com. IN A 10.0.0.6 example.net. CNAME example.com. example.org. IN A 10.0.0.6
example.com。 IN A 10.0.0.6 example.net。 CNAME example.com。 example.org。 IN A 10.0.0.6
then the algorithm might treat all three names as equal, even though the third name might refer to a different entity.
次に、3番目の名前が別のエンティティを参照している場合でも、アルゴリズムは3つの名前すべてを等しいものとして処理します。
With the introduction of dynamic IP addresses; private IP addresses; multiple IP addresses per name; multiple address families (e.g., IPv4 vs. IPv6); devices that roam to new locations; commonly deployed DNS tricks that result in the answer depending on factors such as the requester's location and the load on the server whose address is returned; etc., this method of comparison cannot be relied upon. There is no guarantee that two names for the same host will resolve the name to the same IP addresses; nor that the addresses resolved refer to the same entity, such as when the names resolve to private IP addresses; nor even that the system has connectivity (and the willingness to wait for the delay) to resolve names at the time the answer is needed. The lifetime of the identifier, and of any cached state from a previous resolution, also affects security (see Section 4.4).
動的IPアドレスの導入。プライベートIPアドレス。名前ごとに複数のIPアドレス。複数のアドレスファミリ（IPv4とIPv6など）。新しい場所にローミングするデバイス。リクエスターの場所やアドレスが返されるサーバーの負荷などの要因に応じて回答が得られる、一般的に展開されているDNSトリック。など、この比較方法は信頼できません。同じホストの2つの名前が同じIPアドレスに名前を解決するという保証はありません。また、名前がプライベートIPアドレスに解決される場合など、解決されるアドレスが同じエンティティを参照することもありません。答えが必要なときにシステムが名前を解決するための接続性（および遅延を待つ意思）も持っていません。識別子の有効期間、および以前の解決策のキャッシュされた状態の有効期間も、セキュリティに影響します（セクション4.4を参照）。
In addition, a comparison mechanism that relies on the ability to resolve identifiers such as hostnames to other identifiers such as IP addresses leaks information about security decisions to outsiders if these queries are publicly observable. (See [PRIVACY-CONS] for a deeper discussion of information disclosure.)
さらに、ホスト名などの識別子をIPアドレスなどの他の識別子に解決する機能に依存する比較メカニズムは、これらのクエリが公に監視可能である場合、セキュリティ決定に関する情報を部外者に漏らします。 （情報開示の詳細については、[プライバシー]をご覧ください）。
Finally, it is worth noting that resolving two identifiers to determine if they refer to the same entity can be thought of as a use of such identifiers, as opposed to actually comparing the identifiers themselves, which is the focus of this document.
最後に、2つの識別子を解決して同じエンティティを参照しているかどうかを判断することは、このドキュメントの焦点である実際に識別子自体を比較するのではなく、そのような識別子の使用と考えることができることに注意してください。
Port numbers and service names are discussed in depth in [RFC6335]. 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
ポート番号とサービス名は[RFC6335]で詳細に議論されています。歴史的には、ポート番号、SRVレコードで使用されるサービス名、割り当てられたポート番号のニーモニック識別子（[IANA-PORT]ではポート "キーワード"として知られていました）がありました。後者の2つは統合され、
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).
さまざまなプロトコルは、これらのタイプの1つ以上を文字列で使用します。たとえば、多くのURIスキームで使用される一般的な構文では、ポート番号は許可されますが、サービス名は許可されません。 getaddrinfo()APIの一部の実装では、ポート番号またはポートキーワード（サービス名ではない）のいずれかになる文字列をサポートしています。
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 [RFC6335] 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.1.4のアドレス解決の問題と同じです。さらに、[RFC6335]のセクション5.1は、サービス名/ポートのキーワードに少なくとも1つの文字が含まれている必要があることを明確にしています。これにより、両方が許可されている文字列のポート番号との混同が防止されます。
This section looks at issues related to using URIs for security purposes. For example, Section 7.4 of [RFC5280] specifies comparison of URIs in certificates. Examples of URIs in security-token-based access control systems include WS-*, SAML 2.0 [OASIS-SAMLv2-CORE], and OAuth Web Resource Authorization Profiles (WRAP) [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 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.
このセクションでは、セキュリティ上の目的でのURIの使用に関連する問題について説明します。たとえば、[RFC5280]のセクション7.4は、証明書のURIの比較を指定しています。セキュリティトークンベースのアクセス制御システムのURIの例には、WS-*、SAML 2.0 [OASIS-SAMLv2-CORE]、およびOAuth Webリソース許可プロファイル（WRAP）[OAuth-WRAP]が含まれます。このようなシステムでは、セキュリティインフラストラクチャのさまざまな参加者がURIによって識別されます。たとえば、セキュリティトークンの要求者はURIで識別されることがあります。セキュリティトークンの発行者と、セキュリティトークンを使用することを目的とした証明書利用者は、URIによって識別されることがよくあります。セキュリティトークンのクレームは、多くの場合、URIを使用して定義されたタイプを持ち、クレームの値はURIにすることもできます。
URIs are defined with multiple components, each of which has its own rules. We cover each in turn below. However, it is also important to note that there exist multiple comparison algorithms. Section 6.2 of [RFC3986] states:
URIは複数のコンポーネントで定義され、それぞれに独自のルールがあります。以下、それぞれについて順に説明します。ただし、複数の比較アルゴリズムが存在することに注意することも重要です。 [RFC3986]のセクション6.2には次のように記載されています。
A variety of methods are used in practice to test URI equivalence. These methods fall into a range, distinguished by the amount of processing required and the degree to which the probability of false negatives is reduced. As noted above, false negatives cannot be eliminated. In practice, their probability can be reduced, but this reduction requires more processing and is not cost-effective for all applications.
実際には、URIの同等性をテストするためにさまざまな方法が使用されています。これらの方法は、必要な処理の量と偽陰性の確率が低減される度合いによって区別される範囲に分類されます。上記のように、偽陰性は排除できません。実際には、それらの確率を減らすことができますが、この削減はより多くの処理を必要とし、すべてのアプリケーションに対して費用効果が高いわけではありません。
If this range of comparison practices is considered as a ladder, the following discussion will climb the ladder, starting with practices that are cheap but have a relatively higher chance of producing false negatives, and proceeding to those that have higher computational cost and lower risk of false negatives.
この比較手法の範囲をはしごと見なす場合、以下の説明では、はしごを登っていきます。安価であるが、偽陰性を生成する可能性が比較的高い手法から始め、計算コストが高く、リスクが低い手法に進みます。偽陰性。
The ladder approach has both pros and cons. On the pro side, it allows some uses to optimize for security, and other uses to optimize for cost, thus allowing URIs to be applicable to a wide range of uses. A disadvantage is that when different approaches are taken by different components in the same system using the same identifiers, the inconsistencies can result in security issues.
ラダーアプローチには長所と短所があります。プロ側では、セキュリティを最適化するための一部の用途と、コストを最適化するためのその他の用途を可能にするため、URIを幅広い用途に適用できます。不利な点は、同じシステム内の同じコンポーネントを使用して、同じ識別子を使用して異なるアプローチをとると、不整合が原因でセキュリティの問題が発生する可能性があることです。
[RFC3986] defines URI schemes as being case-insensitive US-ASCII and in Section 6.2.2.1 specifies that scheme names should be normalized to lowercase characters.
[RFC3986]は、URIスキームを大文字と小文字を区別しないUS-ASCIIとして定義し、セクション6.2.2.1でスキーム名を小文字に正規化する必要があることを指定しています。
New schemes can be defined over time. In general, however, two URIs with an unrecognized scheme cannot be safely compared. 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.
時間の経過とともに新しいスキームを定義できます。ただし、一般に、認識されないスキームを持つ2つのURIを安全に比較することはできません。これは、他のコンポーネントの正規化と比較の規則がスキームによって異なる場合があるためです。たとえば、新しいURIスキームにはデフォルトのポートXがあり、その知識がないと、比較アルゴリズムは「example.com」と「example.com:X」が機関コンポーネントで一致すると見なすべきかどうかを知ることができません。したがって、セキュリティ上の理由から、認識されないスキームを無効な識別子として扱うのが最も安全です。ただし、URIが「一致時にアクセスを許可する」パラダイムでのみ使用される場合、いくつかの偽陰性を犠牲にして、大文字と小文字を区別する一般的な比較を行うことで、認識されないスキームをサポートできます。
The authority component is scheme-specific, but many schemes follow a common syntax that allows for userinfo, host, and port.
権限コンポーネントはスキーム固有ですが、多くのスキームは、userinfo、host、およびportを許可する共通の構文に従います。
Section 3.1 discusses issues with hostnames in general. In addition, Section 3.2.2 of [RFC3986] 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 used.
セクション3.1では、ホスト名に関する一般的な問題について説明します。さらに、[RFC3986]のセクション3.2.2では、IPvFutureプロダクションを使用して将来の変更が可能です。 IPv4およびIPv6リテラルと同様に、IPvFuture形式では、複数の意味的に同一の文字列表現に問題があり、IPv4またはIPv6アドレスと意味的に同一である場合があります。そのため、IPvFutureが使用されている場合、誤検知が一般的になる可能性があります。
See discussion in Section 3.2.
セクション3.2の説明を参照してください。
[RFC3986] defines the userinfo production that allows arbitrary data about the user of the URI to be placed before '@' signs in URIs. For example, "ftp://alice:bob@example.com/bar" has the value "alice:bob" 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 "ftp://alice:ick@example.com" and "ftp://example.com" as being equal.
[RFC3986]は、URIの「@」サインの前にURIのユーザーに関する任意のデータを配置できるようにするuserinfo生成を定義します。たとえば、「ftp：// alice：bob@example.com/bar」には、ユーザー情報として「alice：bob」という値があります。セキュリティコンテキストでURIを比較する場合、userinfoを重要なものとして扱うかどうかを決定する必要があります。たとえば、一部のURI比較サービスは、「ftp：// alice：ick@example.com」と「ftp://example.com」を同じものとして扱います。
When the userinfo is treated as being significant, it has additional considerations (e.g., whether or not it is case sensitive), which we cover in Section 3.4.
userinfoが重要なものとして扱われる場合、3.4で説明する追加の考慮事項（大文字と小文字が区別されるかどうかなど）があります。
[RFC3986] supports the use of path segment values such as "./" or "../" for relative URIs. As discussed in Section 6.2.2.3 of [RFC3986], they are intended only for use within a reference relative to some other base URI, but Section 5.2.4 of [RFC3986] nevertheless defines an algorithm to remove them as part of URI normalization.
[RFC3986]は、相対URIの「./」や「../」などのパスセグメント値の使用をサポートしています。 [RFC3986]のセクション6.2.2.3で説明したように、これらは他のベースURIに関連する参照内での使用のみを目的としていますが、[RFC3986]のセクション5.2.4は、それらをURI正規化の一部として削除するアルゴリズムを定義しています。
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.
スキームで特に明記されていない限り、パスコンポーネントは大文字と小文字を区別するように定義されています。ただし、大文字と小文字を区別しないパスを使用するファイルシステムを使用してリソースが保存およびアクセスされる場合、同じリソースを参照するパスが多数存在します。そのため、この場合、偽陰性は一般的です。
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.
「http://example.com/foo」、「http://example.com/foo？」、および「http://example.com/foo?bar」がそれぞれ等しいと見なされるかどうかについての質問がありますまたは異なる。
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.
同様に、値の順序が重要かどうかは指定されていません。たとえば、「http://example.com/blah?ick=bick&foo=bar」は「http://example.com/blah?foo=bar&ick=bick」と等しいと見なす必要がありますか？また、ドメイン名がクエリコンポーネント（別のURIへの参照など）に表示されることが許可されている場合、セクション3.1と同じ問題が適用されます。
Some URI formats include fragment identifiers. These are typically handles to locations within a resource and are used for local reference. A classic example is the use of fragments in HTTP URIs where a URI 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.
一部のURI形式にはフラグメント識別子が含まれています。これらは通常、リソース内の場所へのハンドルであり、ローカル参照に使用されます。古典的な例は、HTTP URIでのフラグメントの使用です。「http://example.com/blah.html#ick」の形式のURIは、リソース「http://example.com/blah.html」を取得することを意味し、 、ローカルに到着したら、「ick」という名前のHTMLアンカーを見つけて表示します。
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.
したがって、たとえば、ユーザーがリンク "http://example.com/blah.html#baz"をクリックすると、ブラウザは "http://example.com/blah"のURI比較を実行してキャッシュをチェックします.html "、およびリソースがキャッシュに存在する場合、一致が宣言されます。
Hence, comparisons for security purposes typically ignore the fragment component and treat all fragments as equal to the full resource. However, if one were actually trying to compare the piece of a resource that was identified by the fragment identifier, ignoring it would result in potential false positives.
したがって、セキュリティ上の目的での比較では、通常、フラグメントコンポーネントは無視され、すべてのフラグメントが完全なリソースと同等として扱われます。ただし、フラグメント識別子によって識別されたリソースの一部を実際に比較しようとした場合、それを無視すると、誤検出が発生する可能性があります。
It may be tempting to define a URI comparison algorithm based on whether URIs resolve to the same content, along the lines of resolving hostnames as described in Section 3.1.4. However, such an algorithm would result in similar problems, including content that dynamically changes over time or that is based on factors such as the requester's location, potential lack of external connectivity at the time or place that comparison is done, introduction of potentially undesirable delay, etc.
セクション3.1.4で説明されているように、ホスト名の解決の行に沿って、URIが同じコンテンツに解決されるかどうかに基づいてURI比較アルゴリズムを定義するのは魅力的です。ただし、このようなアルゴリズムでは、時間の経過とともに動的に変化するコンテンツや、要求者の場所、比較が行われる時間または場所での外部接続の潜在的な欠如、望ましくない可能性のある遅延の導入などのコンテンツに基づいて、同様の問題が発生します。 、など
In addition, as noted in Section 3.1.4, resolution leaks information about security decisions to outsiders if the queries are publicly observable.
さらに、セクション3.1.4で述べたように、クエリが公に監視可能である場合、解決策はセキュリティ決定に関する情報を部外者に漏らします。
Section 3.4.1 of [RFC5322] defines the syntax of an email address-like identifier, and Section 3.2 of [RFC6532] updates it to support internationalization. Section 7.5 of [RFC5280] further discusses the use of internationalized email addresses in certificates.
[RFC5322]のセクション3.4.1はメールアドレスのような識別子の構文を定義し、[RFC6532]のセクション3.2は国際化をサポートするようにそれを更新します。 [RFC5280]のセクション7.5では、証明書での国際化されたメールアドレスの使用についてさらに説明しています。
Regarding the security impact of internationalized email headers, [RFC6532] points to Section 14 of [RFC6530], which contains a discussion of many issues resulting from internationalization.
国際化された電子メールヘッダーのセキュリティへの影響に関して、[RFC6532]は、[RFC6530]のセクション14を指しています。このセクションには、国際化に起因する多くの問題についての議論が含まれています。
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, as covered earlier in Section 3.1.
メールアドレスのような識別子には、ローカル部分とドメイン部分があります。セクション3.1で前述したように、ドメイン部分の問題はホスト名の場合と本質的に同じです。
The local part is left for each domain to define. People quite commonly use email addresses as usernames with web sites such as banks or shopping sites, but the site doesn't know whether foo@example.com is the same person as FOO@example.com. Thus, email address-like identifiers are typically Indefinite identifiers.
ローカル部分は、定義するドメインごとに残されます。銀行やショッピングサイトなどのWebサイトでは、ユーザー名としてメールアドレスを使用することがよくありますが、サイトではfoo@example.comがFOO@example.comと同じ人物であるかどうかはわかりません。したがって、電子メールアドレスのような識別子は、通常、無期限の識別子です。
To avoid false positives, some security mechanisms (such as those described in [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.
誤検知を回避するために、一部のセキュリティメカニズム（[RFC5280]で説明されているものなど）は、完全一致を使用してローカルパーツを比較します。したがって、URIと同様に、電子メールアドレスのような識別子は、一致時拒否スキームではなく、一致時付与セキュリティスキームで使用するように設計されています。
Furthermore, when such identifiers are actually used as email addresses, Section 2.4 of [RFC5321] states that the local part of a mailbox must be treated as case sensitive, but if a mailbox is stored and accessed using a filesystem using case-insensitive paths, there may be many paths that refer to the same mailbox. As such, false negatives can be common in this case.
さらに、そのような識別子が実際にメールアドレスとして使用される場合、[RFC5321]のセクション2.4は、メールボックスのローカル部分は大文字と小文字を区別する必要があると述べていますが、メールボックスが格納され、大文字と小文字を区別しないパスを使用するファイルシステムを使用してアクセスする場合、同じメールボックスを参照する多くのパスがあるかもしれません。そのため、この場合、偽陰性は一般的です。
There are a number of examples (some in the preceding sections) of strings that conflate two types of identifiers, using some heuristic to try to determine which type of identifier is given. Similarly, two ways of encoding the same type of identifier might be conflated within the same string.
2つのタイプの識別子を混同する文字列の例（前のセクションの一部）がいくつかあり、特定のヒューリスティックを使用して、どのタイプの識別子が指定されているかを判断しようとします。同様に、同じタイプの識別子をエンコードする2つの方法が、同じ文字列内で統合される場合があります。
Some examples include:
いくつかの例は次のとおりです。
1. A string that might be an IPv4 address literal or an IPv6 address literal
1. IPv4アドレスリテラルまたはIPv6アドレスリテラルである可能性がある文字列
2. A string that might be an IP address literal or a hostname
2. IPアドレスリテラルまたはホスト名である可能性がある文字列
3. A string that might be a port number or a service name
3. ポート番号またはサービス名の可能性がある文字列
4. A DNS label that might be literal or be Punycode-encoded
4. リテラルまたはPunycodeエンコードされたDNSラベル
Strings that allow such conflation can only be considered Definite if there exists a well-defined rule to determine which identifier type is meant. One way to do so is to ensure that the valid syntax for the two is disjoint (e.g., distinguishing IPv4 vs. IPv6 address literals by the use of colons in the latter). A second way to do so is to define a precedence rule that results in some identifiers being inaccessible via a conflated string (e.g., a host literally named "xn--de-jg4avhby1noc0d" may be inaccessible due to the "xn--" prefix denoting the use of Punycode encoding). In some cases, such inaccessible space may be reserved so that the actual set of identifiers in use is unambiguous. For example, Section 2.5.5.2 of [RFC4291] defines a range of the IPv6 address space for representing IPv4 addresses.
そのような融合を可能にする文字列は、どの識別子タイプが意図されているかを決定する明確に定義されたルールが存在する場合にのみ、確定と見なすことができます。そのための1つの方法は、2つの有効な構文が互いに素であることを確認することです（たとえば、IPv4とIPv6のアドレスリテラルを、コロンを使用して区別します）。これを行う2番目の方法は、優先文字列を定義することです。これにより、一部の識別子は統合された文字列を介してアクセスできなくなります（たとえば、「xn--de-jg4avhby1noc0d」という名前のホストは、「xn--」接頭辞が原因でアクセスできない場合があります） Punycodeエンコーディングの使用を示します）。場合によっては、そのようなアクセスできないスペースが予約されるため、使用中の実際の識別子のセットが明確になります。たとえば、[RFC4291]のセクション2.5.5.2は、IPv4アドレスを表すためのIPv6アドレス空間の範囲を定義しています。
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.
セクション3.1.3で説明したホスト名の問題に加えて、多くのタイプの確定および不確定識別子に適用される多くの国際化の問題があります。
First, there is no DNS mechanism for identifying whether non-identical strings would be seen by a human as being equivalent. There are problematic examples even with US-ASCII (Basic Latin) strings, including regional spelling variations such as "color" and "colour", and with many non-English cases, including partially numeric strings in Arabic script contexts, Chinese strings in Simplified and Traditional forms, and so on. Attempts to produce such alternate forms algorithmically could produce false positives and hence have an adverse effect on security.
第1に、同一でない文字列が人間によって同等であると見なされるかどうかを識別するDNSメカニズムはありません。 US-ASCII（Basic Latin）文字列でも問題のある例があります。これには、「color」や「color」などの地域のスペルのバリエーションが含まれます。また、アラビア語のスクリプトコンテキストの部分的に数値の文字列、Simplifiedの中国語の文字列など、英語以外の多くのケースで発生します。そして伝統的な形など。このような代替フォームをアルゴリズムで作成しようとすると、誤検知が発生し、セキュリティに悪影響を与える可能性があります。
Second, 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, using visual inspection for security is unreliable. In addition to the security issues, visual confusability also adversely affects the usability of identifiers distributed via visual media. Similar issues can arise with audible confusability when using audio (e.g., for radio distribution, accessibility to the blind, etc.) in place of a visual medium. Furthermore, when strings conflate two types of identifiers as discussed in Section 4.1, allowing non-ASCII characters can cause one type of identifier to appear to a human as another type of identifier. For example, characters that may look like digits and dots may appear to be an IPv4 literal to a human (especially to one who might expect digits to appear in his or her native script). Hence, conflation often increases the chance of confusability.
第2に、一部の文字列は他の文字列と視覚的に混同されやすいため、ユーザーがセキュリティ検査を目視検査に基づいて行うと、誤検知の可能性が多数存在します。そのため、セキュリティのために目視検査を使用することは信頼できません。セキュリティの問題に加えて、視覚的な混乱は、視覚的なメディアを介して配布される識別子の使いやすさに悪影響を及ぼします。同様の問題は、視覚媒体の代わりにオーディオを使用する場合（たとえば、ラジオ配信、ブラインドへのアクセス可能性など）の可聴混同性で発生する可能性があります。さらに、セクション4.1で説明したように、文字列が2種類の識別子を融合する場合、非ASCII文字を許可すると、あるタイプの識別子が別のタイプの識別子として人間に表示される可能性があります。たとえば、数字やドットのように見える文字は、人間（特に、数字が自分のネイティブスクリプトに表示されることを期待する人）にとってはIPv4リテラルのように見えます。したがって、融合はしばしば混乱の可能性を高めます。
Determining whether a string is a valid identifier should typically be done after, or as part of, canonicalization. Otherwise, an attacker might use the canonicalization algorithm to inject (e.g., via percent encoding, Normalization Form KC (NFKC), or non-shortest-form UTF-8) delimiters such as '@' in an email address-like identifier, or a '.' in a hostname.
文字列が有効な識別子であるかどうかの判断は、通常、正規化の後に、または正規化の一部として行う必要があります。それ以外の場合、攻撃者は正規化アルゴリズムを使用して（たとえば、パーセントエンコーディング、正規化形式KC（NFKC）、または非最短形式のUTF-8を介して）、電子メールアドレスのような識別子に '@'などの区切り文字を挿入する可能性があります。 「。」ホスト名で。
Any case-insensitive comparisons need to define how comparison is done, since such comparisons may vary by the locale of the endpoint. As such, using case-insensitive comparisons in general often results in identifiers being either Indefinite or, if the legal character set is restricted (e.g., to US-ASCII), Definite.
大文字と小文字を区別しない比較では、エンドポイントのロケールによって異なる場合があるため、比較の方法を定義する必要があります。そのため、通常、大文字と小文字を区別しない比較を使用すると、識別子が不明確になるか、有効な文字セットが（たとえば、US-ASCIIに）制限されている場合は、確定になります。
See also [WEBER] for a more visual discussion of many of these issues.
これらの問題の多くのより視覚的な説明については、[WEBER]も参照してください。
Finally, the set of permitted characters and the canonical form of the characters (and hence the canonicalization algorithm) sometimes vary by protocol today, even when the intent is to use the same identifier, such as when one protocol passes identifiers to the other. See [RFC6885] for further discussion.
最後に、許可された文字のセットと文字の正規形式（したがって正規化アルゴリズム）は、1つのプロトコルが別のプロトコルに識別子を渡す場合など、同じ識別子を使用する場合でも、プロトコルによって異なる場合があります。詳細については、[RFC6885]を参照してください。
Another issue arises when an identifier (e.g., "localhost", "10.11.12.13", etc.) is not globally unique. Section 1.1 of [RFC3986] states:
別の問題は、識別子（「localhost」、「10.11.12.13」など）がグローバルに一意でない場合に発生します。 [RFC3986]のセクション1.1は次のように述べています。
URIs have a global scope and are interpreted consistently regardless of context, though the result of that interpretation may be in relation to the end-user's context. For example, "http://localhost/" has the same interpretation for every user of that reference, even though the network interface corresponding to "localhost" may be different for each end-user: interpretation is independent of access.
URIにはグローバルスコープがあり、コンテキストに関係なく一貫して解釈されますが、その解釈の結果はエンドユーザーのコンテキストに関連している可能性があります。たとえば、「http：// localhost /」は、「localhost」に対応するネットワークインターフェイスがエンドユーザーごとに異なる場合でも、その参照のすべてのユーザーに対して同じ解釈を持ちます。解釈はアクセスとは無関係です。
Whenever an identifier that is not globally unique is passed to another entity outside of the scope of uniqueness, it will refer to a different resource and can result in a false positive. This problem is often addressed by using the identifier together with some other unique identifier of the context. For example, "alice" may uniquely identify a user within a system but must be used with "example.com" (as in "alice@example.com") to uniquely identify the context outside of that system.
グローバルに一意ではない識別子が一意性の範囲外の別のエンティティに渡されると、それは別のリソースを参照し、誤検知が発生する可能性があります。この問題は、多くの場合、識別子をコンテキストの他の一意の識別子と一緒に使用することで解決されます。たとえば、「alice」はシステム内のユーザーを一意に識別できますが、「alice@example.com」のように「example.com」とともに使用して、そのシステム外のコンテキストを一意に識別する必要があります。
It is also worth noting that IPv6 addresses that are not globally scoped can be written with, or otherwise associated with, a "zone ID" to identify the context (see [RFC4007] for more information). However, zone IDs are only unique within a host, so they typically narrow, rather than expand, the scope of uniqueness of the resulting identifier.
また、グローバルにスコープされていないIPv6アドレスは、「ゾーンID」を使用して書き込むか、または関連付けて、コンテキストを識別することができます（詳細については、[RFC4007]を参照してください）。ただし、ゾーンIDはホスト内でのみ一意であるため、通常、結果の識別子の一意性の範囲を拡張するのではなく、狭めます。
Often, identifiers are not unique across all time but have some lifetime associated with them after which they may be reassigned to another entity. For example, bob@example.com might be assigned to an employee of the Example company, but if he leaves and another Bob is later hired, the same identifier might be reused. As another example, IP address 203.0.113.1 might be assigned to one subscriber and then later reassigned to another subscriber. Security issues can arise if updates are not made in all entities that store the identifier (e.g., in an access control list as discussed in Section 2, or in a resolution cache as discussed in Section 3.1.4).
多くの場合、識別子は常に一意ではありませんが、それに関連付けられた有効期間があり、その後、別のエンティティに再割り当てされる場合があります。たとえば、bob @ example.comがExample社の従業員に割り当てられた場合、彼が退職して別のボブが後で雇用された場合、同じ識別子が再利用される可能性があります。別の例として、IPアドレス203.0.113.1が1つのサブスクライバーに割り当てられ、後で別のサブスクライバーに再割り当てされる場合があります。識別子を格納するすべてのエンティティ（たとえば、セクション2で説明したアクセス制御リスト、またはセクション3.1.4で説明した解決キャッシュ）で更新が行われない場合、セキュリティの問題が発生する可能性があります。
This issue is similar to the issue of scope discussed in Section 4.3, except that the scope of uniqueness is temporal rather than topological.
この問題は、一意性の範囲がトポロジーではなく時間的であることを除いて、セクション4.3で説明した範囲の問題に似ています。
This entire document is about security considerations.
このドキュメント全体は、セキュリティの考慮事項に関するものです。
To minimize issues related to elevation of privilege, any system that requires the ability to use both deny and allow operations within the same identifier space should avoid the use of Indefinite identifiers in security comparisons.
特権の昇格に関連する問題を最小限に抑えるために、同じ識別子スペース内で拒否と許可の両方の操作を使用する機能を必要とするシステムでは、セキュリティ比較での無期限識別子の使用を避けてください。
To minimize future security risks, any new identifiers being designed should 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. That is, security risks can be reduced by specifying the comparison algorithm, making sure to resolve any ambiguities pointed out in this document (e.g., "standard dotted decimal").
将来のセキュリティリスクを最小限に抑えるために、設計されている新しい識別子は絶対または明確な比較アルゴリズムを指定する必要があり、拡張性が許可されている場合（たとえば、URIの新しいスキームが許可する場合）、比較アルゴリズムは不変のままであるので、認識されない拡張を比較できます。 。つまり、比較アルゴリズムを指定して、このドキュメントで指摘されているあいまいさを確実に解決することで、セキュリティリスクを軽減できます（たとえば、「標準のドット付き10進数」）。
Some issues (such as unrecognized extensions) can be mitigated by treating such identifiers as invalid. Validity checking of identifiers is further discussed in [RFC3696].
一部の問題（認識されない拡張子など）は、このような識別子を無効として扱うことで軽減できます。識別子の妥当性チェックについては、[RFC3696]でさらに説明されています。
Perhaps the hardest issues arise when multiple protocols are used together, such as in Figure 2, where the two protocols are defined or implemented using different comparison algorithms. When constructing an architecture that uses multiple such protocols, designers should pay attention to any differences in comparison algorithms among the protocols in order to fully understand the security risks. How to deal with such security risks in current systems is an area for future work.
おそらく、最も困難な問題は、図2のように複数のプロトコルが一緒に使用されるときに発生します。図2では、2つのプロトコルが異なる比較アルゴリズムを使用して定義または実装されています。このような複数のプロトコルを使用するアーキテクチャを構築する場合、設計者は、セキュリティリスクを完全に理解するために、プロトコル間の比較アルゴリズムの違いに注意を払う必要があります。現在のシステムでこのようなセキュリティリスクに対処する方法は、今後の作業の領域です。
Yaron Goland contributed to the discussion on URIs. Patrik Faltstrom contributed to the background on identifiers. John Klensin contributed text in a number of different sections. Additional helpful feedback and suggestions came from Bernard Aboba, Fred Baker, Leslie Daigle, Mark Davis, Jeff Hodges, Bjoern Hoehrmann, Russ Housley, Christian Huitema, Magnus Nystrom, Tom Petch, and Chris Weber.
Yaron GolandがURIに関する議論に貢献しました。 Patrik Faltstromが識別子の背景に貢献しました。 John Klensinは、さまざまなセクションでテキストを寄稿しました。追加の役立つフィードバックと提案は、バーナードアボバ、フレッドベイカー、レスリーデイグル、マークデイビス、ジェフホッジス、ビアンエアマン、ラスハウズリー、クリスチャンウイテマ、マグナスニストロム、トムペッチ、クリスウェーバーから寄せられました。
Bernard Aboba Jari Arkko Marc Blanchet Ross Callon Alissa Cooper Spencer Dawkins Joel Halpern Russ Housley David Kessens Danny McPherson Jon Peterson Dave Thaler Hannes Tschofenig
バーナードアボバジャリアルコマルクブランシェロスカロンアリッサクーパースペンサードーキンスジョエルハルパーンラスハウズリーデビッドケセンスダニーマクファーソンジョンピーターソンデイブターラーハネスチョーフェニグ
[IAB1123] Internet Architecture Board, "IAB Statement: 'The interpretation of rules in the ICANN gTLD Applicant Guidebook'", February 2012, <http://www.iab.org/documents/ correspondence-reports-documents/2012-2/iab-statement-the-interpretation-of-rules-in-the-icann-gtld-applicant-guidebook>.
[IAB1123] Internet Architecture Board、「IAB Statement： 'The解釈of rules in the ICANN gTLD Applicant Guidebook'」、2012年2月、<http://www.iab.org/documents/communication-reports-documents/2012-2 / iab-statement-the-interpretation-of-rules-in-the-icann-gtld-applicant-guidebook>。
[IANA-PORT] IANA, "Service Name and Transport Protocol Port Number Registry", March 2013, <http://www.iana.org/assignments/service-names-port-numbers/>.
[IANA-PORT] IANA、「Service Name and Transport Protocol Port Number Registry」、2013年3月、<http://www.iana.org/assignments/service-names-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.
[IEEE-1003.1] IEEEおよびThe Open Group、「The Open Group Base Specifications、Issue 6、IEEE Std 1003.1、2004 Edition」、IEEE Std 1003.1、2004。
[JAVAURL] Oracle, "Class URL", Java(TM) Platform Standard Ed. 7, 2013, <http://docs.oracle.com/javase/7/docs/api/java/net/ URL.html>.
[JAVAURL] Oracle、「Class URL」、Java（TM）Platform Standard Ed。 2013年7月<http://docs.oracle.com/javase/7/docs/api/java/net/ URL.html>
[OASIS-SAMLv2-CORE] Cantor, S., Ed., Kemp, J., Ed., Philpott, R., Ed., and E. Maler, Ed., "Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0", OASIS Standard saml-core-2.0-os, March 2005, <http://docs.oasis-open.org/security/saml/v2.0/ saml-core-2.0-os.pdf>.
[OASIS-SAMLv2-CORE] Cantor、S.、Ed。、Kemp、J.、Ed。、Philpott、R.、Ed。、and E. Maler、Ed。、「OASIS Security Assertion Markup Languageのアサーションとプロトコル（SAML）V2.0」、OASIS標準saml-core-2.0-os、2005年3月、<http://docs.oasis-open.org/security/saml/v2.0/ saml-core-2.0-os。 pdf>。
[OAuth-WRAP] Hardt, D., Ed., Tom, A., Eaton, B., and Y. Goland, "OAuth Web Resource Authorization Profiles", Work in Progress, January 2010.
[OAuth-WRAP] Hardt、D.、Ed。、Tom、A.、Eaton、B。、およびY. Goland、「OAuth Web Resource Authorization Profiles」、Work in Progress、2010年1月。
[PRIVACY-CONS] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", Work in Progress, April 2013.
[プライバシーコンス]クーパー、A。、ツコフェニグ、H。、アボバ、B。、ピーターソン、J。、モリス、J。、ハンセン、M。、およびR.スミス、「インターネットプロトコルのプライバシーに関する考慮事項」、Work in進捗状況、2013年4月。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[RFC1034] Mockapetris、P。、「ドメイン名-概念と機能」、STD 13、RFC 1034、1987年11月。
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989.
[RFC1123] Braden、R。、「インターネットホストの要件-アプリケーションとサポート」、STD 3、RFC 1123、1989年10月。
[RFC2277] Alvestrand, H.T., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998.
[RFC2277] Alvestrand、H.T。、「IETF Policy on Character Sets and Languages」、BCP 18、RFC 2277、1998年1月。
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.
[RFC3490] Faltstrom、P.、Hoffman、P。、およびA. Costello、「Internationalizing Domain Names in Applications（IDNA）」、RFC 3490、2003年3月。
[RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)", RFC 3492, March 2003.
[RFC3492] Costello、A。、「Punycode：A Bootstring encoding for Unicode for Internationalized Domain Names in Applications（IDNA）」、RFC 3492、2003年3月。
[RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. Stevens, "Basic Socket Interface Extensions for IPv6", RFC 3493, February 2003.
[RFC3493] Gilligan、R.、Thomson、S.、Bound、J.、McCann、J.、and W. Stevens、 "Basic Socket Interface Extensions for IPv6"、RFC 3493、2003年2月。
[RFC3696] Klensin, J., "Application Techniques for Checking and Transformation of Names", RFC 3696, February 2004.
[RFC3696] Klensin、J。、「名前のチェックと変換のアプリケーションテクニック」、RFC 3696、2004年2月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、STD 66、RFC 3986、2005年1月。
[RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, March 2005.
[RFC4007] Deering、S.、Haberman、B.、Jinmei、T.、Nordmark、E。、およびB. Zill、「IPv6 Scoped Address Architecture」、RFC 4007、2005年3月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291] Hinden、R。およびS. Deering、「IPバージョン6アドレッシングアーキテクチャ」、RFC 4291、2006年2月。
[RFC4790] Newman, C., Duerst, M., and A. Gulbrandsen, "Internet Application Protocol Collation Registry", RFC 4790, March 2007.
[RFC4790]ニューマン、C。、デュエルスト、M。、およびA.グルブランドセン、「インターネットアプリケーションプロトコル照合レジストリ」、RFC 4790、2007年3月。
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 4949, August 2007.
[RFC4949] Shirey、R。、「インターネットセキュリティ用語集、バージョン2」、RFC 4949、2007年8月。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[RFC5280] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R。、およびW. Polk、「Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List（CRL）Profile "、RFC 5280、2008年5月。
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.
[RFC5321] Klensin、J。、「Simple Mail Transfer Protocol」、RFC 5321、2008年10月。
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.
[RFC5322] Resnick、P。、編、「インターネットメッセージ形式」、RFC 5322、2008年10月。
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, August 2010.
[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.
[RFC6055] Thaler、D.、Klensin、J。、およびS. Cheshire、「IAB Thoughts on Encodings for Internationalized Domain Names」、RFC 6055、2011年2月。
[RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, January 2011.
[RFC6066] Eastlake、D。、「Transport Layer Security（TLS）Extensions：Extension Definitions」、RFC 6066、2011年1月。
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, March 2011.
[RFC6125] Saint-Andre、P。およびJ. Hodges、「トランスポート層セキュリティ（TLS）のコンテキストでX.509（PKIX）証明書を使用したインターネット公開鍵インフラストラクチャ内のドメインベースのアプリケーションサービスIDの表現と検証」、 RFC 6125、2011年3月。
[RFC6335] 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", BCP 165, RFC 6335, August 2011.
[RFC6335]綿、M。、エガート、L。、タッチ、J。、ウェスターランド、M。、およびS.チェシャー、「サービス名とトランスポートプロトコルのポート番号レジストリの管理のためのInternet Assigned Numbers Authority（IANA）手順"、BCP 165、RFC 6335、2011年8月。
[RFC6530] Klensin, J. and Y. Ko, "Overview and Framework for Internationalized Email", RFC 6530, February 2012.
[RFC6530] Klensin、J。およびY. Ko、「Overview and Framework for Internationalized Email」、RFC 6530、2012年2月。
[RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized Email Headers", RFC 6532, February 2012.
[RFC6532] Yang、A.、Steele、S。、およびN. Freed、「Internationalized Email Headers」、RFC 6532、2012年2月。
[RFC6818] Yee, P., "Updates to the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 6818, January 2013.
[RFC6818] Yee、P。、「インターネットX.509公開鍵インフラストラクチャ証明書および証明書失効リスト（CRL）プロファイルの更新」、RFC 6818、2013年1月。
[RFC6874] Carpenter, B., Cheshire, S., and R. Hinden, "Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers", RFC 6874, February 2013.
[RFC6874] Carpenter、B.、Cheshire、S。、およびR. Hinden、「Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers」、RFC 6874、2013年2月。
[RFC6885] Blanchet, M. and A. Sullivan, "Stringprep Revision and Problem Statement for the Preparation and Comparison of Internationalized Strings (PRECIS)", RFC 6885, March 2013.
[RFC6885]ブランシェM.およびA.サリバン、「国際化された文字列（PRECIS）の準備と比較のためのStringprepの改訂と問題の説明」、RFC 6885、2013年3月。
[TR36] Unicode Consortium, "Unicode Security Considerations", Unicode Technical Report #36, Revision 11, July 2012, <http://www.unicode.org/reports/tr36/>.
[TR36] Unicodeコンソーシアム、「Unicodeのセキュリティに関する考慮事項」、Unicodeテクニカルレポート＃36、リビジョン11、2012年7月、<http://www.unicode.org/reports/tr36/>。
[USASCII] American National Standards Institute, "Coded Character Sets -- 7-bit American Standard Code for Information Interchange (7-bit ASCII)", ANSI X3.4, 1986.
[USASCII] American National Standards Institute、「Coded Character Sets-7-bit American Standard Code for Information Interchange（7-bit ASCII）」、ANSI X3.4、1986。
[WEBER] Weber, C., "Attacking Software Globalization", March 2010, <http://www.lookout.net/files/ Chris_Weber_Character%20Transformations%20v1.7_IUC33.pdf>.
[WEBER] Weber、C。、「攻撃ソフトウェアのグローバリゼーション」、2010年3月、<http://www.lookout.net/files/ Chris_Weber_Character％20Transformations％20v1.7_IUC33.pdf>。
Author's Address
著者のアドレス
Dave Thaler (editor) Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA
だゔぇ てゃぇｒ （えぢとｒ） みｃろそｆｔ こｒぽらちおん おね みｃろそｆｔ わｙ れｄもんｄ、 わ ９８０５２ うさ
Phone: +1 425 703 8835
EMail: dthaler@microsoft.com