RFC 6943 | Проблемы сравнения идентификаторов в целях безопасности

Аннотация

Такие идентификаторы, как имена хостов, URI, IP-адреса и адреса электронной почты, часто используются в контексте безопасности для идентификации участников и ресурсов безопасности. В таких контекстах идентификатор, представленный через некоторый протокол, часто сравнивается с использованием некоторой политики для принятия решений по безопасности, таких как, может ли участник безопасности получать доступ к ресурсу, какой уровень аутентификации или шифрования требуется, и т. д.

Если стороны, участвующие в решении по безопасности, используют разные алгоритмы для сравнения идентификаторов, в результате чего могут возникнуть сценарии сбоев, начиная от отказа в обслуживании и заканчивая повышением привилегий. Этот документ предоставляет обсуждение этих проблем, которые дизайнеры должны учитывать при определении идентификаторов и протоколов, а также при построении архитектур, использующих несколько протоколов.

Скачать оригинальный документ на английском языке RFC 6943 PDF

 

Оглавление

1. Введение
1.1. Классы Идентификаторов
1.2. Канонизация
2. Использование идентификатора в политиках и решениях безопасности
2.1. Ложные позитивы и негативы
2.2. Гипотетический пример
3. Проблемы сравнения с общими идентификаторами
3.1. Имена хостов
3.1.1. Литералы IPv4
3.1.2. Литералы IPv6
3.1.3. Интернационализация
3.1.4. Разрешение для сравнения
3.2. Номера портов и сервисные имена
3.3. URIs
3.3.1. Компонент схемы
3.3.2. Компонент полномочий
3.3.2.1. Хост
3.3.2.2. Порт
3.3.2.3. Информация о пользователе
3.3.3. Компонент пути
3.3.4. Компонент запроса
3.3.5. Компонент фрагмента
3.3.6. Разрешение для сравнения
3.4. Идентификаторы адресов электронной почты
4. Общие вопросы
4.1. Объединение
4.2. Интернационализация
4.3. Объем
4.4. Временный характер
5. Вопросы безопасности
6. Благодарности
7. Члены IAB на момент утверждения
8. Информационные ссылки
Адрес автора

 

Статус этой заметки

Этот документ не является спецификацией Internet Standards Track; опубликовано в ознакомительных целях.

Этот документ является продуктом Совета по архитектуре Интернета (IAB) и представляет информацию, которую IAB посчитал ценным для постоянной записи. Он представляет собой консенсус Совета по архитектуре Интернета (IAB). Документы, одобренные для публикации IAB, не являются кандидатами на какой-либо уровень Интернет-стандарта; см. раздел 2 RFC 5741.

Информацию о текущем статусе этого документа, любых ошибках и способах предоставления отзывов о нем можно получить по адресу http://www.rfc-editor.org/info/rfc6943.

 

Уведомление об авторских правах

Copyright (c) 2013 IETF Trust и лица, указанные в качестве авторов документа. Все права защищены.
На данный документ распространяется действие ПП 78 и Правовые положения IETF Trust, относящиеся к документам IETF (http://trustee.ietf.org/license-info), действующие на дату публикации этого документа. Пожалуйста, внимательно ознакомьтесь с этими документами, так как они описывают ваши права и ограничения в отношении этого документа.

 

1. Введение

В вычислениях и Интернете различные типы «идентификаторов» используются для идентификации людей, устройств, контента и т. Д. В этом документе обсуждаются некоторые проблемы безопасности, которые разработчики должны учитывать при определении идентификаторов и протоколов, а также при построении архитектур, использующих несколько протоколы. Прежде чем обсуждать эти проблемы безопасности, мы сначала расскажем о некоторых типичных процессах, связанных с идентификаторами. Такие термины, как «идентификатор», «личность» и «принципал», используются, как определено в [RFC4949].

Как показано на рисунке 1, есть несколько процессов, имеющих отношение к нашему обсуждению.

Процесс № 1

Идентификатор генерируется первым. Если идентификатор должен быть уникальным, процесс генерации должен включать в себя некоторый механизм, такой как распределение центральным органом или проверка среди членов распределенного органа, чтобы помочь обеспечить уникальность. Однако понятие «уникальный» включает в себя определение, соответствует ли предполагаемый идентификатор любому другому идентификатору, который уже был выделен. Как мы увидим, для многих типов идентификаторов это не просто точное двоичное совпадение.

После генерации идентификатора он часто сохраняется в двух местах: с запросчиком или «держателем» идентификатора и с некоторым хранилищем идентификаторов (например, DNS). Например, если идентификатор был назначен центральным органом, хранилище может быть этим органом. Если идентификатор идентифицирует устройство или контент на устройстве, хранилище может быть этим устройством.

Процесс № 2

Идентификатор передается либо держателем идентификатора, либо хранилищем идентификаторов другим лицам, которые могут использовать этот идентификатор. Это распространение может быть электронным, но иногда оно осуществляется через другие каналы, такие как голос, визитная карточка, рекламный щит или другая форма рекламы. Сам идентификатор может распространяться напрямую или использоваться для генерации части идентификатора другого типа, который затем распространяется. Например, URI или адрес электронной почты могут включать имя сервера, и, следовательно, распространение URI или адреса электронной почты также по своей природе распространяет имя сервера.

Процесс № 3

Идентификатор используется какой-либо стороной. Как правило, пользователь предоставляет идентификатор, который (прямо или косвенно) отправляется в хранилище идентификаторов. Затем хранилище идентификаторов должно попытаться сопоставить предоставленный пользователем идентификатор с идентификатором в своем хранилище.

Например, использование адреса электронной почты для отправки электронной почты владельцу идентификатора может привести к тому, что электронная почта поступит на сервер электронной почты владельца, который имеет доступ к почтовым хранилищам.

В другом варианте пользователю дается идентификатор ресурса (например, веб-сайта) для безопасного доступа, иногда называемого «ссылочным идентификатором» [RFC6125], и сервер, на котором размещается ресурс, затем представляет свою идентичность во время использовать. В этом случае пользовательское приложение пытается сопоставить представленный идентификатор с идентификатором ссылки.

Одним из ключевых аспектов является то, что значения идентификаторов, передаваемые при генерации, распределении и использовании, могут быть в разных формах. Например, идентификатор может быть обменен в печатном виде во время генерации, передан пользователю через голос, а затем использован в электронном виде. Таким образом, процесс сопоставления может быть сложным.

Кроме того, во многих случаях отношения между держателем, хранилищами и пользователями могут быть более вовлеченными. Например, когда существует иерархия веб-кешей, каждый кеш сам является своего рода репозиторием, и процесс сопоставления обычно предполагается таким же, как на исходном сервере.

Другой аспект, который следует иметь в виду, состоит в том, что может быть несколько идентификаторов, которые ссылаются на один и тот же объект (т.е. ресурс, человек, устройство и т. Д.). Например, человек может иметь номер паспорта и номер водительского удостоверения, а RFC может быть доступен в нескольких местах (rfc-editor.org и ietf.org). В этом документе мы фокусируемся на сравнении двух идентификаторов, чтобы увидеть, являются ли они одним и тем же идентификатором, а не на сравнении двух разных идентификаторов, чтобы увидеть, относятся ли они к одному и тому же объекту (хотя некоторые проблемы с последним затрагиваются в нескольких местах, например, как разделы 3.1.4 и 3.3.6).

 

1.1. Классы Идентификаторов

В этом документе мы будем ссылаться на следующие классы идентификаторов:

• Absolute (Абсолютные): идентификаторы, которые можно сравнивать побайтно для равенства. Два идентификатора, которые имеют разные байты, определены как разные. Например, двоичные IP-адреса находятся в этом классе.
• Definite (Определенные): идентификаторы, которые имеют один четко определенный алгоритм сравнения. Например, имена схем URI должны быть US-ASCII [USASCII] и определены для соответствия без учета регистра; сравнение, таким образом, является определенным, поскольку существует определенный алгоритм (Раздел 9.2.1 [RFC4790]) о том, как выполнить регистронезависимое сопоставление между строками ASCII.
• Indefinite (Неопределенные): идентификаторы, которые не имеют единого четко определенного алгоритма сравнения. Например, человеческие имена в этом классе. Каждый может захотеть, чтобы сравнение было адаптировано для его локали, для некоторого определения «локали». В некоторых случаях могут быть ограниченные подмножества сторон, которые могут быть в состоянии договориться (например, все пользователи ASCII могут договориться о едином алгоритме сравнения, тогда как пользователи других сценариев, основанных на римском языке, таких как турецкий, могут не соглашаться), но идентификаторы часто имеют тенденцию вытекать из таких ограниченных сред.

1.2. Канонизация

Возможно, наиболее распространенный алгоритм сравнения включает в себя сначала преобразование каждого идентификатора в каноническую форму (процесс, известный как «канонизация» или «нормализация»), а затем проверка результирующих канонических представлений на побитовое равенство. При этом очень важно, чтобы все участвующие субъекты согласовали одну и ту же каноническую форму и использовали один и тот же алгоритм канонизации, чтобы общий процесс сравнения также был одинаковым.

Обратите внимание, что в некоторых контекстах, таких как интернационализация, термины «канонизация» и «нормализация» имеют точное значение. В этом документе, однако, мы используем эти термины как синонимы в их более общей форме, чтобы означать преобразование в некоторую стандартную форму.

Хотя наиболее распространенный метод сравнения включает в себя канонизацию, сравнение также может быть выполнено путем определения алгоритма эквивалентности, где ни одна форма не является канонической. Однако в большинстве случаев каноническая форма полезна для других целей, таких как вывод, и поэтому в таких случаях достаточно определения канонической формы для определения метода сравнения.

 

2. Использование идентификатора в политиках и решениях безопасности

Идентификаторы, такие как имена хостов, URI и адреса электронной почты, используются в контекстах безопасности для идентификации участников безопасности (то есть объектов, которые могут быть аутентифицированы) и ресурсов, а также других параметров безопасности, таких как типы и значения утверждений. Эти идентификаторы затем используются для принятия решений по безопасности на основе идентификатора, представленного через некоторый протокол. Например:

• Аутентификация (Authentication): протокол может соответствовать идентификатору участника безопасности для поиска ожидаемого материала ключа и затем соответствия материала ключа.
• Авторизация (Authorization): протокол может сопоставлять имя ресурса с определенной политикой. Например, он может найти список контроля доступа (ACL) и затем найти идентификатор участника безопасности (или его заменитель) в этом ACL.
• Учет (Accounting): система может создать учетную запись для идентификатора участника безопасности или имени ресурса, а затем может потребоваться позднее сопоставить представленный идентификатор, чтобы (например) добавить новые правила фильтрации на основе записей, чтобы остановить атаку.

Если стороны, участвующие в принятии решения о безопасности, используют разные алгоритмы сопоставления для одних и тех же идентификаторов, то, как мы увидим, могут возникнуть сценарии сбоев, начиная от отказа в обслуживании до повышения привилегий.

Это особенно сложно в случаях, когда участвуют несколько сторон и несколько протоколов. Например, существует много сценариев, в которых некоторая форма «службы маркеров безопасности» используется для предоставления запрашивающей стороне разрешения на доступ к ресурсу, когда ресурс удерживается третьей стороной, которая полагается на службу маркеров безопасности (см. Рисунок 2). , Протокол, используемый для запроса разрешения (например, Kerberos или OAuth), может отличаться от протокола, используемого для доступа к ресурсу (например, HTTP). Возможности для проблем безопасности возникают, когда два протокола определяют разные алгоритмы сравнения для идентичного идентификатора или когда протокол задан неоднозначно, и две конечные точки (например, служба маркеров безопасности и держатель ресурса) реализуют разные алгоритмы в одном и том же протоколе.

Во многих случаях ситуация более сложная. Например, при использовании сертификатов инфраструктуры открытого ключа (PKIX) X.509 [RFC6125] имя в сертификате сравнивается с именами в списках ACL или другими вещами. В случае безопасности веб-сайта имя в сертификате сравнивается с частью URI, которую пользователь, возможно, набрал в браузере. Тот факт, что многие люди делают набор текста на разных типах систем, усложняет проблему.

Добавьте к этому этап регистрации сертификата и этап выдачи сертификата, и еще две стороны имеют возможность настроить кодировку, или, что еще хуже, программное обеспечение, которое их поддерживает, может вносить изменения, о которых стороны не знают.

2.1. Ложные позитивы и негативы

Сначала стоит обсудить более подробно влияние ошибок в алгоритме сравнения. «Ложный положительный результат» возникает, когда два идентификатора сравниваются, как если бы они были равны, но в действительности ссылаются на два разных объекта (например, субъекты безопасности или ресурсы). Когда привилегия предоставляется на совпадение, ложный положительный результат, таким образом, приводит к повышению привилегии — например, разрешает выполнение операции, которая не должна была быть разрешена иначе. Когда в сопоставлении отказано в привилегии (например, при сопоставлении записи в списке блокировки / запрета или списке отзыва), разрешенная операция отклоняется. В лучшем случае это может привести к ухудшению производительности (например, кешу или принудительной избыточной аутентификации), а в худшем — к отказу в обслуживании.

«Ложноотрицательный» результат возникает, когда два идентификатора, которые на самом деле относятся к одной и той же вещи, сравниваются, как если бы они были разными, а эффекты противоположны таковым для ложных срабатываний. То есть, когда привилегия предоставляется на совпадение, результат в лучшем случае ухудшает производительность, а в худшем — отказ в обслуживании; когда в матче отказано в привилегии, повышается привилегия.

Рисунок 3 суммирует эти эффекты.

При разработке алгоритма сравнения обычно можно изменить его, чтобы увеличить вероятность ложных срабатываний и уменьшить вероятность ложных срабатываний, или наоборот. Какой результат лучше, зависит от контекста.

Повышение привилегий почти всегда рассматривается как гораздо худшее, чем отказ в обслуживании. Следовательно, для URI, например, в разделе 6.1 [RFC3986] говорится, что «методы сравнения предназначены для минимизации ложных срабатываний при строгом избегании ложных срабатываний».

Таким образом, URI были определены с учетом парадигмы «Предоставление привилегий по совпадению», где важно предотвратить повышение привилегий при минимальном отказе в обслуживании. Таким образом, использование URI в системе «запретить привилегию при совпадении» может быть проблематичным.

2.2. Гипотетический пример

В этом примере и участники безопасности, и ресурсы идентифицируются с помощью URI. Foo Corp заплатила example.com за доступ к сервису Stuff. Foo Corp позволяет своим сотрудникам создавать учетные записи в сервисе Stuff. Алиса получает учетную запись «http://example.com/Stuff/FooCorp/alice», а Боб получает «http://example.com/Stuff/FooCorp/bob». Однако оказывается, что канонизатор URI Foo Corp. включает в себя компоненты фрагментов URI в сравнениях, тогда как example.com этого не делает, а Foo Corp не запрещает символ # в имени учетной записи.

Поэтому Чак, злонамеренный сотрудник Foo Corp., просит создать учетную запись на example.com с именем alice#stuff. URI-логика Foo Corp проверяет свои записи на наличие учетных записей, созданных с помощью stuff, и обнаруживает, что учетной записи с именем alice#stuff нет. Следовательно, в своих записях он связывает alice#stuff с Чаком и будет выдавать только те токены, которые можно использовать с «http://example.com/Stuff/FooCorp/alice#stuff» для Чака.

Злоумышленник Чак отправляется в службу токенов безопасности в Foo Corp и запрашивает токен безопасности, подходящий для «http://example.com/Stuff/FooCorp/alice#stuff». Foo Corp выдает токен, поскольку Чак является законным владельцем (по мнению Foo Corp) учетной записи alice#stuff. Затем Чак отправляет маркер безопасности в запросе на «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».

Используя несоответствия в канонизаторах, используемых Foo Corp и example.com, Чак может успешно начать атаку с повышением привилегий и получить доступ к ресурсу Алисы.

Кроме того, рассмотрим злоумышленника, использующего похожую корпорацию, такую как «foocorp» (или любой вариант, содержащий не-ASCII символ, который некоторые люди могут ожидать представлять ту же корпорацию). Если владелец ресурса рассматривает их как разные, а служба маркеров безопасности рассматривает их как одинаковые, то и в этом сценарии может произойти повышение привилегий.

 

3. Проблемы сравнения с общими идентификаторами

В этом разделе мы рассмотрим ряд общих типов идентификаторов и обсудим различные вопросы, связанные со сравнением, которые могут влиять на безопасность всякий раз, когда они используются для идентификации участников или ресурсов безопасности. Эти примеры иллюстрируют общие шаблоны, которые могут возникнуть с другими типами идентификаторов.

3.1. Имена хостов

Имена хостов (состоящие из меток, разделенных точками) обычно используются либо непосредственно в качестве идентификаторов, либо в качестве компонентов в идентификаторах, таких как URI и адреса электронной почты. Другой пример приведен в разделах 7.2 и 7.3 [RFC5280] (и обновлен в разделе 3 [RFC6818]), в которых указано использование в сертификатах PKIX.

В этом разделе мы обсуждаем ряд проблем при сравнении строк, которые выглядят как форма имени хоста.

Во-первых, стоит отметить, что сам термин «имя хоста» часто является неоднозначным, и, следовательно, важно, чтобы любое использование уточняло, какое определение предназначено. Некоторые примеры определений включают в себя:

• а. Полное доменное имя (FQDN),
• б. Полное доменное имя, связанное с адресными записями в DNS,
• в. Самая левая метка в FQDN
• г. Крайняя левая метка в полном доменном имени, связанная с адресными записями.

Использование разных определений в разных местах приводит к таким вопросам, как, например, «example» и «example.com» считаются равными или нет, и поэтому важно при написании новых спецификаций уточнить, какое определение имеется в виду.

В разделе 3 [RFC6055] обсуждаются различия между «именем хоста» и «именем DNS», где первый является подмножеством последнего с использованием ограниченного набора символов (букв, цифр и дефисов). Если один канонизатор использует определение «DNS-имя», тогда как другой использует определение «имя хоста», имя может быть действительным в первом, но недействительным во втором. Пока недействительным идентификаторам отказано в привилегии, это различие не приведет к повышению привилегий.

В разделе 3.1 [RFC1034] обсуждается различие между «полным» доменным именем, которое заканчивается точкой (например, «example.com.»), И относительным именем с несколькими метками, например «example.com», которое предполагает root («.») находится в списке поиска суффиксов. В большинстве случаев они считаются равными, но могут возникнуть проблемы, если разные объекты в архитектуре безопасности имеют разные интерпретации относительного доменного имени.

[IAB1123] кратко обсуждает проблемы с неоднозначностью относительно того, будет ли метка «алфавитной», включая, помимо прочего, то, как «алфавитная» должна интерпретироваться в интернационализированной среде, и может ли имя хоста интерпретироваться как IP-адрес , Мы рассмотрим этот последний вопрос более подробно ниже.

3.1.1. Литералы IPv4

В разделе 2.1 [RFC1123] говорится:

• Всякий раз, когда пользователь вводит идентификатор хоста в Интернете, СЛЕДУЕТ вводить либо (1) имя домена хоста, либо (2) IP-адрес в десятичном виде с разделительными точками («#. #. #. #»). Хост ДОЛЖЕН проверять строку синтаксически на наличие десятичного числа с точками, прежде чем искать ее в системе доменных имен.
• Последнее требование не предназначено для указания полной синтаксической формы для ввода десятичного числа хоста с точками; это считается проблемой пользовательского интерфейса.

При определении API inet_addr () стандарт переносимого интерфейса операционной системы (POSIX) [IEEE-1003.1] определяет «десятичную нотацию IPv4 с точками» как разрешающую не только строки вида «10.0.1.2», но также допускающую восьмеричное и шестнадцатеричное, адреса с менее чем четырьмя частями. Например, «10.0.258», «0xA000102» и «012.0×102» представляют один и тот же IPv4-адрес в стандартной нотации «IPv4 с точками после запятой». Мы будем называть это «свободным — loose» синтаксисом литерала адреса IPv4.

В Разделе 6.1 [RFC3493], getaddrinfo () определено для поддержки того же (свободного) синтаксиса, что и inet_addr ():

• Если указанным семейством адресов является AF_INET или AF_UNSPEC, строки адреса, использующие стандартную нотацию Интернета, как указано в inet_addr (), действительны.

Напротив, в разделе 6.3 того же RFC говорится, что inet_pton ():

• Если аргумент af inet_pton () равен AF_INET, строка src должна быть в стандартной десятичной форме IPv4: ddd.ddd.ddd.ddd
• где «ddd» — это десятичное число от 1 до 3 цифр от 0 до 255. Функция inet_pton () не принимает другие форматы (такие как восьмеричные числа, шестнадцатеричные числа и менее четырех чисел, которые принимает inet_addr ()).

Как показано выше, inet_pton () использует то, что мы будем называть «строгой» формой литерала адреса IPv4. Некоторые платформы также используют строгую форму с getaddrinfo (), когда ему передается флаг AI_NUMERICHOST.

Как строгая, так и произвольная формы являются стандартными формами, и, следовательно, спецификация протокола все еще неоднозначна, если она просто определяет строку в «стандартной десятичной форме с точками IPv4». И, в результате этих различий, имена, такие как «10.11.12», являются неоднозначными относительно того, являются ли они IP-адресом или именем хоста, и даже «10.11.12.13» может быть неоднозначным из-за «СЛЕДУЕТ» в вышеупомянутом текст из RFC 1123, что делает его необязательным, рассматривать ли его как адрес или имя DNS.

Протоколы и форматы данных, которые могут использовать адреса в строковой форме в целях безопасности, должны разрешать эти неоднозначности. Например, для хост-компонента URI раздел 3.2.2 [RFC3986] разрешает первую неоднозначность, разрешая только строгую форму, и разрешает вторую неоднозначность, указав, что она считается литералом адреса IPv4. Новые протоколы и форматы данных должны аналогичным образом рассмотреть возможность использования строгой формы, а не свободной формы, чтобы лучше соответствовать ожиданиям пользователей.

Строка может быть допустимой в «свободном» определении, но недопустимой в «строгом» определении. Пока недействительным идентификаторам отказано в привилегии, это различие не приведет к повышению привилегий. Однако в некоторых протоколах используются строки, которые могут быть либо литералом IP-адреса, либо именем хоста. Такие строки в лучшем случае являются определенными идентификаторами и часто оказываются неопределенными идентификаторами. (См. Раздел 4.1 для дальнейшего обсуждения.)

 

3.1.2. Литералы IPv6

Адреса IPv6 также имеют большое разнообразие альтернативных, но семантически идентичных строковых представлений, как определено в Разделе 2.2 [RFC4291] и Разделе 2 [RFC6874]. Как обсуждалось в разделе 3.2.5 [RFC5952], этот факт вызывает проблемы в контексте безопасности, если сравнение (например, в сертификатах PKIX) выполняется между строками, а не между двоичными представлениями адресов.

[RFC5952] указал рекомендуемый формат канонической строки как попытку решить эту проблему, но в настоящее время он не может быть широко распространен. И когда строки могут содержать не-ASCII-символы, возникают те же проблемы (и даже больше, поскольку допускаются шестнадцатеричные и двоеточия), как и с литералами IPv4.

Принимая во внимание, что (двоичные) адреса IPv6 являются абсолютными идентификаторами, литералы адресов IPv6 являются определенными идентификаторами, поскольку преобразование строки в адрес для литералов адресов IPv6 является однозначным.

3.1.3. Интернационализация

Политика IETF для наборов символов и языков [RFC2277] требует поддержки UTF-8 в протоколах, и в результате многие протоколы теперь поддерживают символы не ASCII. Когда имя хоста отправляется в поле UTF-8, существует несколько способов его кодирования. Например, метки имени хоста могут быть закодированы непосредственно в UTF-8, или они могут сначала кодироваться в Punycode [RFC3492] или даже кодироваться в процентах из UTF-8.

Например, в URI, раздел 3.2.2 [RFC3986] специально разрешает использование кодированных в процентах символов UTF-8 в имени хоста, а также использование кодирования интернационализированных доменных имен в приложениях (IDNA) [RFC3490] с использованием Алгоритм Punycode.

Кодировка процента однозначна для имен хостов, поскольку символ процента не может отображаться в строгом определении «имени хоста», хотя он может присутствовать в имени DNS.

С другой стороны, метки с кодировкой Punycode (или «A-метки») могут быть неоднозначными, если на самом деле разрешено именовать хосты с именем, начинающимся с «xn--», и в результате могут получаться ложные срабатывания. Хотя это может быть крайне маловероятным для нормальных сценариев, тем не менее это обеспечивает возможный вектор для атакующего.

Компаратор имени хоста, таким образом, должен решить, должна ли метка в кодировке Punycode считаться или не должна считаться допустимой меткой имени хоста, и если да, то должна ли она совпадать с меткой, закодированной в какой-либо другой форме, такой как метка в кодировке Unicode в процентах (U -этикетка).

Например, раздел 3 «Расширения безопасности транспортного уровня (TLS)»:

«Определения расширений» [RFC6066] гласит:

• «HostName» содержит полное имя DNS-узла сервера, понятное клиенту. Имя хоста представляется в виде байтовой строки с использованием кодировки ASCII без конечной точки. Это позволяет поддерживать интернационализированные доменные имена посредством использования A-меток, определенных в [RFC5890]. DNS-имена хостов нечувствительны к регистру. Алгоритм сравнения имен хостов описан в [RFC5890], раздел 2.3.2.4.

Дополнительное обсуждение вопросов безопасности, возникающих при интернационализации, см. В разделе 4.2 и [TR36].

 

3.1.4. Разрешение для сравнения

Некоторые системы (в частности, URL-адреса Java [JAVAURL]) используют правило, согласно которому, если два имени хоста разрешают один и тот же IP-адрес (-ы), имена хостов считаются равными. То есть алгоритм канонизации включает в себя разрешение имен, причем IP-адрес является канонической формой.

Например, если разрешение было выполнено через DNS, а DNS содержал:

example.com. IN A 10.0.0.6
example.net. CNAME example.com.
example.org. IN A 10.0.0.6

тогда алгоритм может рассматривать все три имени как равные, даже если третье имя может относиться к другому объекту.

С введением динамических IP-адресов; частные IP-адреса; несколько IP-адресов на имя; многоадресные семейства (например, IPv4 против IPv6); устройства, которые перемещаются в новые места; часто используемые уловки DNS, которые приводят к ответу в зависимости от таких факторов, как местоположение запрашивающей стороны и нагрузка на сервер, адрес которого возвращается; и т.д., на этот метод сравнения нельзя положиться.

Нет гарантии, что два имени для одного и того же хоста будут преобразовывать имя в один и тот же IP-адрес; или что разрешенные адреса ссылаются на один и тот же объект, например, когда имена разрешаются на частные IP-адреса; и даже то, что система имеет возможность подключения (и готовность ждать задержки) для разрешения имен в момент, когда необходим ответ. Время жизни идентификатора и любого кэшированного состояния из предыдущего разрешения также влияет на безопасность (см. Раздел 4.4).
Кроме того, механизм сравнения, основанный на способности разрешать идентификаторы, такие как имена хостов, к другим идентификаторам, таким как IP-адреса, передает информацию о решениях по безопасности сторонним лицам, если эти запросы общедоступны. (См. [КОНФИДЕНЦИАЛЬНОСТЬ] для более глубокого обсуждения раскрытия информации.)

Наконец, стоит отметить, что разрешение двух идентификаторов для определения того, относятся ли они к одному и тому же объекту, может рассматриваться как использование таких идентификаторов, а не как фактическое сравнение самих идентификаторов, что является предметом данного документа.

 

3.2. Номера портов и сервисные имена

Номера портов и названия сервисов подробно обсуждаются в [RFC6335]. Исторически существовали номера портов, имена служб, используемые в записях SRV, и мнемонические идентификаторы для назначенных номеров портов (известные как «ключевые слова» порта в [IANA-PORT]). Последние два теперь унифицированы, и различные протоколы используют один или несколько из этих типов в строках. Например, общий синтаксис, используемый многими схемами URI, позволяет использовать номера портов, но не имена служб. Некоторые реализации API-интерфейса getaddrinfo () поддерживают строки, которые могут быть номерами портов или ключевыми словами порта (но не именами служб).

Для протоколов, которые используют имена служб, которые должны быть решены, проблемы такие же, как и для разрешения адресов в Разделе 3.1.4. Кроме того, в разделе 5.1 [RFC6335] разъясняется, что имена служб / ключевые слова портов должны содержать хотя бы одну букву. Это предотвращает путаницу с номерами портов в строках, где разрешены оба.

3.3. URIs

В этом разделе рассматриваются проблемы, связанные с использованием URI в целях безопасности. Например, Раздел 7.4 [RFC5280] определяет сравнение URI в сертификатах. Примеры URI в системах управления доступом на основе маркеров безопасности включают WS- *, SAML 2.0 [OASIS-SAMLv2-CORE] и профили авторизации веб-ресурсов OAuth (WRAP) [OAuth-WRAP]. В таких системах различные участники инфраструктуры безопасности идентифицируются посредством URI. Например, запрашивающие токены безопасности иногда идентифицируются с помощью URI. Источники токенов безопасности и проверяющие стороны, которые должны использовать токены безопасности, часто идентифицируются с помощью URI. Утверждения в токенах безопасности часто имеют свои типы, определенные с помощью URI, и значениями утверждений также могут быть URI.

URI определяются с несколькими компонентами, каждый из которых имеет свои правила. Мы рассмотрим каждый по очереди ниже. Тем не менее, также важно отметить, что существует несколько алгоритмов сравнения. Раздел 6.2 [RFC3986] гласит:

• На практике используются различные методы для проверки эквивалентности URI. Эти методы попадают в диапазон, различающийся объемом требуемой обработки и степенью снижения вероятности ложных негативов. Как отмечено выше, ложные негативы не могут быть устранены. На практике их вероятность может быть уменьшена, но это сокращение требует большей обработки и не является экономически эффективным для всех приложений.
• Если этот диапазон методов сравнения рассматривается как лестница, последующее обсуждение будет подниматься по лестнице, начиная с методов, которые дешевы, но имеют относительно более высокий шанс получения ложных негативов, и переходя к тем, которые имеют более высокую вычислительную стоимость и меньший риск ложные негативы.

Лестничный подход имеет как плюсы, так и минусы. С другой стороны, это позволяет некоторым пользователям оптимизировать безопасность, а другим — оптимизировать расходы, что позволяет применять URI для широкого спектра применений. Недостатком является то, что, когда разные компоненты в одной и той же системе используют разные подходы с использованием одинаковых идентификаторов, несоответствия могут привести к проблемам безопасности.

3.3.1. Компонент схемы

[RFC3986] определяет схемы URI как регистрозависимые US-ASCII и в Разделе 6.2.2.1 указывает, что имена схем должны быть нормализованы к строчным буквам.

Новые схемы могут быть определены с течением времени. В целом, однако, два URI с нераспознанной схемой нельзя сравнивать безопасно. Это связано с тем, что правила канонизации и сравнения для других компонентов могут различаться в зависимости от схемы. Например, новая схема URI может иметь порт по умолчанию X, и без этого знания алгоритм сравнения не может знать, следует ли считать «example.com» и «example.com:X» в компоненте полномочий. Следовательно, в целях безопасности наиболее безопасно, чтобы нераспознанные схемы рассматривались как недействительные идентификаторы. Однако, если URI используются только с парадигмой «предоставить доступ при совпадении», то нераспознанные схемы могут быть поддержаны путем общего сравнения с учетом регистра за счет некоторых ложных отрицаний.

3.3.2. Компонент полномочий

Компонент полномочий зависит от схемы, но многие схемы следуют общему синтаксису, который учитывает информацию пользователя, хост и порт.

3.3.2.1. Хост

Раздел 3.1 обсуждает проблемы с именами хостов в целом. Кроме того, в разделе 3.2.2 [RFC3986] разрешены будущие изменения с использованием продукции IPvFuture. Как и в случае литералов IPv4 и IPv6, форматы IPvFuture могут иметь проблемы с несколькими семантически идентичными строковыми представлениями, а также могут быть семантически идентичными адресам IPv4 или IPv6. Таким образом, ложные негативы могут быть распространены, если используется IPvFuture.

3.3.2.2. Порт

Смотрите обсуждение в разделе 3.2.

3.3.2.3. Информация о пользователе

[RFC3986] определяет создание пользовательской информации, которая позволяет размещать произвольные данные о пользователе URI перед знаками «@» в URI. Например, «ftp://alice: bob@example.com/bar» имеет значение «alice:bob» в качестве своей пользовательской информации. При сравнении URI в контексте безопасности необходимо решить, следует ли рассматривать информацию пользователя как значимую или нет. Например, некоторые службы сравнения URI рассматривают «ftp://alice:ick@example.com» и «ftp://example.com» как равные.

Когда пользовательская информация рассматривается как значимая, она имеет дополнительные соображения (например, учитывает ли она регистр или нет), которые мы рассмотрим в разделе 3.4.

3.3.3. Компонент пути

[RFC3986] поддерживает использование значений сегмента пути, таких как «./» или «../» для относительных URI. Как обсуждалось в разделе 6.2.2.3 [RFC3986], они предназначены только для использования в пределах ссылки относительно некоторого другого базового URI, но в разделе 5.2.4 [RFC3986] тем не менее определяется алгоритм для их удаления как часть нормализации URI.

Если в схеме не указано иное, компонент пути определяется с учетом регистра. Однако если ресурс хранится и доступен с помощью файловой системы с использованием нечувствительных к регистру путей, будет много путей, которые ссылаются на один и тот же ресурс. Таким образом, ложные негативы могут быть распространены в этом случае.

3.3.4. Компонент запроса

Возникает вопрос о том, считаются ли «http://example.com/foo», «http://example.com/foo?» и «http://example.com/foo?bar» одинаковыми или разными.

Точно так же не определено, имеет ли значение порядок ценностей. Например, следует ли считать http://example.com/blah?ick=bick&foo=bar равным http://example.com/blah?foo=bar&ick=bick? И если доменному имени разрешено появляться в компоненте запроса (например, в ссылке на другой URI), применяются те же проблемы в Разделе 3.1.

3.3.5. Компонент фрагмента

Некоторые форматы URI включают идентификаторы фрагментов. Обычно это дескрипторы местоположений внутри ресурса и используются для локальной ссылки. Классическим примером является использование фрагментов в HTTP URI, где URI в форме «http://example.com/blah.html#ick» означает получение ресурса «http://example.com/blah.html» и когда он прибудет локально, найдите HTML-якорь с именем «ick» и отобразите его.

Так, например, когда пользователь нажимает на ссылку «http://example.com/blah.html#baz», браузер проверяет свой кэш, выполняя сравнение URI для «http://example.com/blah». .html «и, если ресурс присутствует в кеше, объявление объявляется.

Следовательно, сравнения в целях безопасности обычно игнорируют фрагментный компонент и рассматривают все фрагменты как равные полному ресурсу. Однако, если бы кто-то действительно пытался сравнить часть ресурса, которая была идентифицирована идентификатором фрагмента, игнорирование этого привело бы к потенциальным ложным срабатываниям.

3.3.6. Разрешение для сравнения

Может возникнуть соблазн определить алгоритм сравнения URI на основе того, разрешают ли URI одно и то же содержимое, в соответствии с разрешением имен хостов, как описано в разделе 3.1.4. Однако такой алгоритм может привести к аналогичным проблемам, в том числе к содержимому, которое динамически изменяется со временем или основано на таких факторах, как местоположение запрашивающей стороны, потенциальное отсутствие внешних подключений во время или в месте, где выполняется сравнение, введение потенциально нежелательной задержки. , так далее.

Кроме того, как отмечено в Разделе 3.1.4, разрешение передает информацию о решениях по безопасности сторонним лицам, если запросы общедоступны.

 

3.4. Идентификаторы адресов электронной почты

Раздел 3.4.1 [RFC5322] определяет синтаксис идентификатора, подобного адресу электронной почты, а раздел 3.2 [RFC6532] обновляет его для поддержки интернационализации. Раздел 7.5 [RFC5280] далее обсуждает использование интернационализированных адресов электронной почты в сертификатах.

Что касается влияния на безопасность интернационализированных заголовков электронной почты, [RFC6532] указывает на раздел 14 [RFC6530], в котором содержится обсуждение многих вопросов, возникающих в результате интернационализации.

Подобные адресам электронной почты идентификаторы имеют локальную часть и доменную часть. Проблемы с доменной частью, по сути, такие же, как и с именами хостов, как описано ранее в разделе 3.1.

Локальная часть оставлена для определения каждого домена. Люди довольно часто используют адреса электронной почты в качестве имен пользователей на веб-сайтах, таких как банки или магазины, но сайт не знает, является ли foo@example.com тем же лицом, что и FOO@example.com. Таким образом, идентификаторы, подобные адресам электронной почты, обычно являются неопределенными идентификаторами.

Чтобы избежать ложных срабатываний, некоторые механизмы безопасности (например, описанные в [RFC5280]) сравнивают локальную часть, используя точное совпадение. Следовательно, как и URI, идентификаторы, подобные адресам электронной почты, предназначены для использования в схемах безопасности предоставления по совпадению, а не в схемах отказа в сопоставлении.

Кроме того, когда такие идентификаторы фактически используются в качестве адресов электронной почты, в разделе 2.4 [RFC5321] говорится, что локальная часть почтового ящика должна рассматриваться как чувствительная к регистру, но если почтовый ящик хранится и доступен с использованием файловой системы с использованием нечувствительных к регистру путей, может быть много путей, которые ссылаются на один и тот же почтовый ящик. Таким образом, ложные негативы могут быть распространены в этом случае.

4. Общие вопросы

4.1. Объединение

Существует ряд примеров (некоторые в предыдущих разделах) строк, которые связывают два типа идентификаторов, используя некоторую эвристику, чтобы попытаться определить, какой тип идентификатора задан. Аналогично, два способа кодирования идентичного идентификатора могут быть объединены в одной и той же строке.
Вот некоторые примеры:

1. Строка, которая может быть литералом адреса IPv4 или литералом адреса IPv6
2. Строка, которая может быть литералом IP-адреса или именем хоста
3. Строка, которая может быть номером порта или именем службы
4. Метка DNS, которая может быть буквальной или иметь кодировку Punycode

Строки, которые допускают такое сопоставление, могут считаться определенными, только если существует четко определенное правило для определения того, какой тип идентификатора подразумевается. Один из способов сделать это состоит в том, чтобы гарантировать, что действительный синтаксис для этих двух типов не пересекается (например, различая литералы адресов IPv4 и IPv6 с помощью двоеточий в последнем). Второй способ сделать это — определить правило приоритета, которое приводит к тому, что некоторые идентификаторы становятся недоступными через связанную строку (например, хост с буквальным именем «xn — de-jg4avhby1noc0d» может быть недоступен из-за префикса «xn--»). обозначает использование кодировки Punycode). В некоторых случаях такое недоступное пространство может быть зарезервировано, чтобы фактический набор используемых идентификаторов был однозначным. Например, раздел 2.5.5.2 [RFC4291] определяет диапазон адресного пространства IPv6 для представления адресов IPv4.

4.2. Интернационализация

В дополнение к проблемам с именами хостов, которые обсуждались в разделе 3.1.3, существует ряд проблем интернационализации, которые применяются ко многим типам определенных и неопределенных идентификаторов.

Во-первых, не существует механизма DNS, позволяющего определить, будут ли неидентичные строки рассматриваться человеком как эквивалентные. Есть проблемные примеры даже со строками US-ASCII (Basic Latin), включая региональные варианты написания, такие как «цвет» и «цвет», и со многими неанглийскими падежами, включая частично числовые строки в контексте арабского алфавита, китайские строки в упрощенном и традиционные формы и т. д. Попытки произвести такие альтернативные формы алгоритмически могут привести к ложным срабатываниям и, следовательно, негативно повлиять на безопасность.

Во-вторых, некоторые строки визуально смешиваются с другими, и, следовательно, если решение о безопасности принимается пользователем на основе визуального осмотра, существует много возможностей для ложных срабатываний. Таким образом, использование визуального контроля в целях безопасности ненадежно. В дополнение к проблемам безопасности визуальная путаница также отрицательно влияет на удобство использования идентификаторов, распространяемых через визуальные носители. Подобные проблемы могут возникать с слышимой путаницей при использовании аудио (например, для распространения по радио, доступа для слепых и т. Д.) Вместо визуального носителя. Кроме того, когда строки связывают два типа идентификаторов, как обсуждалось в Разделе 4.1, разрешение символов, не относящихся к ASCII, может привести к тому, что один тип идентификатора будет казаться человеку как другой тип идентификатора. Например, символы, которые могут выглядеть как цифры и точки, могут казаться литералом IPv4 для человека (особенно для того, кто может ожидать, что цифры появятся в его или ее родном скрипте). Следовательно, слияние часто увеличивает вероятность путаницы.

Определение того, является ли строка допустимым идентификатором, обычно следует выполнять после или в качестве части канонизации. В противном случае злоумышленник может использовать алгоритм канонизации для внедрения (например, с помощью процентного кодирования, KC (NFKC) формы нормализации или UTF-8 не-кратчайшей формы), таких как ‘@’ в идентификаторе, подобном адресу электронной почты, или ‘ . ‘в имени хоста.

Любые сравнения без учета регистра должны определять, как выполняется сравнение, поскольку такие сравнения могут варьироваться в зависимости от локали конечной точки. Таким образом, использование сравнения без учета регистра в общем случае часто приводит к тому, что идентификаторы являются либо неопределенными, либо, если допустимый набор символов ограничен (например, US-ASCII), определенным.

Смотрите также [WEBER] для более наглядного обсуждения многих из этих проблем.

Наконец, набор разрешенных символов и каноническая форма символов (и, следовательно, алгоритм канонизации) иногда варьируются в зависимости от протокола сегодня, даже когда предполагается использовать один и тот же идентификатор, например, когда один протокол передает идентификаторы другому. См. [RFC6885] для дальнейшего обсуждения.

4.3. Объем

Другая проблема возникает, когда идентификатор (например, «localhost», «10.11.12.13» и т. Д.) Не является глобально уникальным. В разделе 1.1 [RFC3986] говорится:

• URI имеют глобальную область и интерпретируются последовательно независимо от контекста, хотя результат такой интерпретации может быть связан с контекстом конечного пользователя. Например, «http: // localhost /» имеет одинаковую интерпретацию для каждого пользователя этой ссылки, даже если сетевой интерфейс, соответствующий «localhost», может отличаться для каждого конечного пользователя: интерпретация не зависит от доступа.

Всякий раз, когда идентификатор, который не является глобально уникальным, передается другому объекту за пределами области уникальности, он ссылается на другой ресурс и может привести к ложному срабатыванию. Эта проблема часто решается путем использования идентификатора вместе с другим уникальным идентификатором контекста. Например, «Алиса» может однозначно идентифицировать пользователя в системе, но должна использоваться с «example.com» (как в «alice@example.com»), чтобы однозначно идентифицировать контекст вне этой системы.

Также стоит отметить, что адреса IPv6, которые не имеют глобальной области видимости, могут быть записаны или идентифицированы как-либо иначе с «идентификатором зоны» для идентификации контекста (см. [RFC4007] для получения дополнительной информации). Однако идентификаторы зон являются уникальными только для хоста, поэтому они обычно сужают, а не расширяют область уникальности получаемого идентификатора.

4.4. Временный характер

Зачастую идентификаторы не являются уникальными во все времена, но имеют некоторое время жизни, связанное с ними, после чего они могут быть переназначены другому объекту. Например, bob@example.com может быть назначен сотруднику компании в Примере, но если он уйдет, а другой Боб будет нанят позже, тот же идентификатор может быть использован повторно. В качестве другого примера, IP-адрес 203.0.113.1 может быть назначен одному подписчику, а затем переназначен другому подписчику. Проблемы безопасности могут возникать, если обновления выполняются не во всех объектах, в которых хранится идентификатор (например, в списке управления доступом, как описано в разделе 2, или в кэше разрешения, как описано в разделе 3.1.4).

Эта проблема аналогична проблеме области, обсуждаемой в разделе 4.3, за исключением того, что область уникальности является временной, а не топологической.

5. Вопросы безопасности

Весь этот документ о соображениях безопасности.

Чтобы свести к минимуму проблемы, связанные с повышением привилегий, любая система, которой требуется возможность как запретить, так и разрешить операции в одном и том же пространстве идентификаторов, должна избегать использования неопределенных идентификаторов в сравнениях безопасности.

Чтобы минимизировать будущие риски безопасности, любые новые разрабатываемые идентификаторы должны указывать абсолютный или определенный алгоритм сравнения, и если расширяемость разрешена (например, как позволяют новые схемы в URI), то алгоритм сравнения должен оставаться инвариантным, чтобы можно было сравнивать нераспознанные расширения. , То есть риски безопасности могут быть уменьшены путем указания алгоритма сравнения, позволяющего устранить любые неопределенности, указанные в этом документе (например, «стандартное десятичное число с точками»).

Некоторые проблемы (такие как нераспознанные расширения) могут быть смягчены, если рассматривать такие идентификаторы как недействительные. Проверка правильности идентификаторов дополнительно обсуждается в [RFC3696].

Возможно, самые сложные проблемы возникают, когда несколько протоколов используются вместе, например, на рисунке 2, где два протокола определены или реализованы с использованием разных алгоритмов сравнения. При построении архитектуры, которая использует несколько таких протоколов, разработчики должны обращать внимание на любые различия в алгоритмах сравнения между протоколами, чтобы полностью понять риски безопасности. Как бороться с такими угрозами безопасности в существующих системах — это область для будущей работы.

6. Благодарности

Ярон Голанд участвовал в обсуждении URI. Патрик Фальтстром внес свой вклад в фон на идентификаторах. Джон Кленсин внес текст в несколько различных разделов. Дополнительные полезные отзывы и предложения поступили от Бернарда Абобы, Фреда Бейкера, Лесли Дейгла, Марка Дэвиса, Джеффа Ходжеса, Бьорна Хёрмана, Расса Хоусли, Кристиана Уитема, Магнуса Нистрома, Тома Петча и Криса Вебера.

7. Члены IAB на момент утверждения

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

8. Информационные ссылки

[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-theinterpretation-of-rules-in-the-icann-gtld-applicantguidebook>.

[IANA-PORT] IANA, «Service Name and Transport Protocol Port Number Registry», March 2013,
<http://www.iana.org/assignments/service-names-portnumbers/>.

[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.

[JAVAURL] Oracle, «Class URL», Java(TM) Platform Standard Ed. 7, 2013, <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>.

[OAuth-WRAP] Hardt, D., Ed., Tom, A., Eaton, B., and Y. Goland, «OAuth Web Resource Authorization Profiles», Work in Progress, January 2010.

[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.

[RFC1034] Mockapetris, P., «Domain names — concepts and facilities», STD 13, RFC 1034, November 1987.

[RFC1123] Braden, R., «Requirements for Internet Hosts — Application and Support», STD 3, RFC 1123, October 1989.

[RFC2277] Alvestrand, H.T., «IETF Policy on Character Sets and Languages», BCP 18, RFC 2277, January 1998.

[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, «Internationalizing Domain Names in Applications (IDNA)», RFC 3490, March 2003.

[RFC3492] Costello, A., «Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)», RFC 3492, March 2003.

[RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. Stevens, «Basic Socket Interface Extensions for IPv6», RFC 3493, February 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.

[RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and B. Zill, «IPv6 Scoped Address Architecture», RFC 4007, March 2005.

[RFC4291] Hinden, R. and S. Deering, «IP Version 6 Addressing Architecture», RFC 4291, February 2006.

[RFC4790] Newman, C., Duerst, M., and A. Gulbrandsen, «Internet Application Protocol Collation Registry», RFC 4790, March 2007.

[RFC4949] Shirey, R., «Internet Security Glossary, Version 2», RFC 4949, August 2007.

[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.

[RFC5321] Klensin, J., «Simple Mail Transfer Protocol», RFC 5321, October 2008.

[RFC5322] Resnick, P., Ed., «Internet Message Format», RFC 5322, October 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.

[RFC6066] Eastlake, D., «Transport Layer Security (TLS) Extensions: Extension Definitions», RFC 6066, January 2011.

[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.

[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.

[RFC6530] Klensin, J. and Y. Ko, «Overview and Framework for Internationalized Email», RFC 6530, February 2012.

[RFC6532] Yang, A., Steele, S., and N. Freed, «Internationalized Email Headers», RFC 6532, February 2012.

[RFC6818] Yee, P., «Updates to the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile», RFC 6818, January 2013.

[RFC6874] Carpenter, B., Cheshire, S., and R. Hinden, «Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers», RFC 6874, February 2013.

[RFC6885] Blanchet, M. and A. Sullivan, «Stringprep Revision and Problem Statement for the Preparation and Comparison of Internationalized Strings (PRECIS)», RFC 6885, March 2013.

[TR36] Unicode Consortium, «Unicode Security Considerations», Unicode Technical Report #36, Revision 11, July 2012, <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.

[WEBER] Weber, C., «Attacking Software Globalization», March 2010, <http://www.lookout.net/files/Chris_Weber_Character%20Transformations%20v1.7_IUC33.pdf>.

Адрес автора

Dave Thaler (editor)
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
USA

Phone: +1 425 703 8835
EMail: dthaler@microsoft.com