N/RFCNET
← Карточка документаEnglish original ↗

RFC 7542 · май 2015

Идентификатор сетевого доступа

Автор: A. DeKok, FreeRADIUS. Категория: процесс стандартизации. ISSN 2070-1721. Май 2015. Заменяет RFC 4282.

Аннотация

Для предоставления услуг аутентификации между доменами необходим стандартизованный способ, позволяющий доменам идентифицировать пользователей друг друга. Документ определяет синтаксис идентификатора сетевого доступа (Network Access Identifier, NAI) — идентификатора пользователя, передаваемого клиентом до доступа к ресурсам. Это переработанная версия RFC 4282. Она устраняет проблемы с международными наборами символов и вносит ряд других исправлений в RFC 4282.

Статус документа

Это документ процесса стандартизации Интернета.

Документ подготовлен Инженерной группой Интернета (IETF). Он отражает консенсус сообщества IETF, прошёл публичное обсуждение и одобрен к публикации Руководящей группой инженерных работ Интернета (IESG). Дополнительные сведения о стандартах Интернета приведены в разделе 2 RFC 5741.

Информация о текущем статусе документа, исправлениях и порядке отправки отзывов доступна по адресу http://www.rfc-editor.org/info/rfc7542.

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

Copyright (c) 2015 IETF Trust и лица, указанные в качестве авторов документа. Все права защищены.

На документ распространяются BCP 78 и Правовые положения IETF Trust, относящиеся к документам IETF (http://trustee.ietf.org/license-info), действовавшие на дату публикации. Внимательно ознакомьтесь с ними: они описывают ваши права и ограничения в отношении документа. Компоненты кода, извлечённые из документа, должны включать текст Упрощённой лицензии BSD, как описано в разделе 4.e Правовых положений Trust, и предоставляются без гарантий согласно Упрощённой лицензии BSD.

Документ может содержать материалы из документов или вкладов IETF, опубликованных либо предоставленных для публичного доступа до 10 ноября 2008 года. Лица, обладающие авторскими правами на некоторые из этих материалов, могли не предоставить IETF Trust право разрешать изменения таких материалов вне процесса стандартизации IETF. Без получения надлежащей лицензии от обладателей авторских прав на такие материалы документ нельзя изменять вне процесса стандартизации IETF или создавать на его основе производные произведения вне этого процесса, кроме форматирования для публикации в качестве RFC или перевода на другие языки.

1. Введение

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

Под междоменной аутентификацией документ понимает ситуации, когда пользователь имеет учётные данные для аутентификации в одном «домашнем» домене, но может предъявить их во втором, «посещаемом» домене, чтобы получить доступ к определённым услугам последнего. Как правило, между доменами уже существуют отношения, позволяющие передать учётные данные из посещаемого домена в домашний для проверки. Домашний домен обычно отвечает разрешением или отказом; ответ может также содержать параметры авторизации, которые посещаемый домен должен применять к пользователю.

Иными словами, сценарий роуминга предполагает, что пользователь посещает не домашний домен, или перемещается в него, и запрашивает использование услуг этого посещаемого домена.

Заинтересованные стороны включают:

— региональных интернет-провайдеров, работающих в определённом штате или провинции и желающих объединить усилия с другими региональными провайдерами, чтобы предоставлять коммутируемый доступ на большей территории;
— телекоммуникационные компании, желающие объединить деятельность с одной или несколькими компаниями в других регионах или странах, чтобы предоставлять более полный сетевой доступ там, где собственной услуги нет, например в другой стране;
— точки доступа беспроводной локальной сети, обслуживающие одного или нескольких интернет-провайдеров;
— организации, желающие предложить сотрудникам полный пакет услуг коммутируемого доступа по всему миру. Эти услуги могут включать доступ в Интернет и защищённый доступ к корпоративным внутренним сетям через VPN с использованием протоколов туннелирования, таких как Point-to-Point Tunneling Protocol (PPTP) [RFC2637], Layer 2 Forwarding (L2F) [RFC2341], Layer 2 Tunneling Protocol (L2TP) [RFC2661] и туннельный режим IPsec [RFC4301];
— другие протоколы, заинтересованные в использовании учётных данных пользователей для применения существующей инфраструктуры аутентификации.

Для повышения совместимости этих услуг необходим стандартизованный способ идентификации пользователей. Документ определяет синтаксис идентификатора сетевого доступа NAI. Примеры реализаций, использующих NAI, и описание его семантики приведены в [RFC2194].

Определение NAI для сетевого доступа также привело к появлению идентификатора, который можно использовать в системах вне AAA. Некоторые такие системы определили совместимые с NAI идентификаторы, а в развёрнутых системах применялся NAI. Повторное использование одних учётных данных в нескольких ситуациях упростило управление ими. Протоколы, повторно использующие одни учётные данные или один формат идентификатора, могут воспользоваться этим упрощением. Альтернатива — отдельные учётные данные или форматы идентификаторов для каждого протокола, что увеличивает затраты пользователей и администраторов.

Использование одного идентификатора в нескольких протоколах влияет на конфиденциальность. Подробное обсуждение приведено в разделах 2.7 и 4.

Цель документа — определить формат идентификатора, который можно использовать во многих протоколах. Протокол может передавать закодированную версию NAI, например точку как %2E. Однако определение NAI не зависит от протокола. Документ призван содействовать широкому применению формата NAI. Это сократит работу, необходимую для использования идентификации и аутентификации в других протоколах, и уменьшит сложность систем вне AAA для конечных пользователей и администраторов.

Документ лишь предлагает использовать формат NAI и не требует этого. Многие протоколы уже определяют собственные форматы идентификаторов. Некоторые несовместимы с NAI, другие допускают NAI наряду с идентификаторами другого вида. Определение NAI в документе не предъявляет требований к спецификациям протоколов, реализациям или развёрнутым системам.

Однако документ предполагает, что использование одного стандартного формата идентификатора предпочтительнее множества несовместимых форматов. Если идентификаторы необходимы в новых протоколах и/или спецификациях, РЕКОМЕНДУЕТСЯ (RECOMMENDED) использовать формат NAI. При этом толкование идентификатора зависит от контекста, а его формат остаётся неизменным. Подробнее эти вопросы рассмотрены в разделе 2.8.

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

Документ представляет собой переработанную версию [RFC4282], в которой впервые были определены интернационализированные NAI. Отличия и улучшения перечислены в приложении A.

1.1. Терминология

В документе часто используются следующие термины.

«Локальный» или «локализованный» текст: текст, представленный не в UTF-8 либо не в нормализованной форме. Набор символов, кодировка и локаль, как правило, неизвестны сетевым протоколам аутентификации, авторизации и учёта (AAA). Клиент, которому локаль «известна», может иначе понимать этот текст, чем другие компоненты AAA, которым локаль неизвестна.

Идентификатор сетевого доступа (Network Access Identifier, NAI): общий формат идентификаторов пользователя, передаваемых клиентом при аутентификации. NAI позволяет связать пользователя с именем учётной записи и помогает маршрутизировать запрос аутентификации через несколько доменов. NAI не обязательно совпадает с адресом электронной почты пользователя или идентификатором, передаваемым при аутентификации на прикладном уровне.

Сервер сетевого доступа (Network Access Server, NAS): устройство, к которому клиенты подключаются для доступа к сети. В терминологии PPTP оно называется концентратором доступа PPTP (PAC), в терминологии L2TP — концентратором доступа L2TP (LAC), а в IEEE 802.11 — точкой доступа.

Возможность роуминга: в общем смысле возможность пользоваться любым из нескольких интернет-провайдеров, сохраняя формальные отношения клиента и поставщика только с одним. Примеры, где она может потребоваться, — объединения провайдеров и предоставляемая провайдером поддержка доступа к корпоративной сети.

Нормализация или каноникализация: термины определены в разделе 4 [RFC6365]; эти определения включены сюда посредством ссылки.

Локаль: термин определён в разделе 8 [RFC6365]; это определение включено сюда посредством ссылки.

Услуга туннелирования: любая сетевая услуга, обеспечиваемая протоколами туннелирования, такими как PPTP, L2F, L2TP и туннельный режим IPsec. Пример — защищённый доступ к корпоративным внутренним сетям через виртуальную частную сеть VPN.

1.2. Язык требований

Ключевые слова MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY и OPTIONAL следует толковать согласно [RFC2119].

1.3. Назначение

Как описано в [RFC2194], сетевой доступ предоставляют многочисленные провайдеры, и практически все интернет-провайдеры участвуют в роуминговых объединениях.

Одно из требований для предоставления роуминга — возможность определить домашний сервер аутентификации пользователя. В роуминге эта функция выполняется посредством идентификатора сетевого доступа NAI, который пользователь передаёт NAS при первоначальной сетевой аутентификации. Также ожидается, что NAS будет использовать NAI в процессе открытия нового туннеля для определения его конечной точки.

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

Хотя NAI определяется здесь, существующие протоколы и развёрнутые системы не всегда используют его. Поэтому системы AAA ОБЯЗАНЫ (MUST) уметь обрабатывать идентификаторы пользователей не в формате NAI. Способ такой обработки выходит за рамки документа.

Системы вне AAA могут принимать идентификаторы пользователей не в формате NAI. Спецификация не запрещает такую практику: она лишь закрепляет формат и толкование NAI. Документ не может изменить существующие протоколы или практики, но может предложить сообществу преимущество единообразной формы идентификатора пользователя.

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

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

Иными словами, наличие стандарта лучше его отсутствия.

1.4. Мотивация

Отличия от [RFC4282] подробно перечислены в приложении A; однако целесообразно дополнительно обсудить их причины.

Пересмотр [RFC4282] начался с вопросов интернационализации, возникших в контексте [EDUROAM]. Раздел 2.1 [RFC4282] определяет ABNF для областей аутентификации realm и ограничивает грамматику realm английскими буквами, цифрами и дефисом. По-видимому, предполагалось кодировать, сравнивать и передавать realm в кодировке Punycode [RFC3492], как описано в [RFC5891]. У этого подхода есть ряд проблем:

— ABNF в [RFC4282] не согласована с интернационализацией DNS;
— требование раздела 2.1 [RFC4282], чтобы realm состояли из ASCII, противоречит Extensible Authentication Protocol (EAP), определённому в [RFC3748], и RADIUS: оба протокола корректно передают восьмибитовые данные и рекомендуют UTF-8 для идентификаторов;
— раздел 2.4 [RFC4282] требовал специфичных для языка преобразований, которые промежуточным узлам почти невозможно правильно выполнять без сведений об этом языке;
— раздел 2.4 [RFC4282] требует нормализации имён пользователей, что может противоречить требованиям локальной системы или администрации;
— рекомендации раздела 2.4 [RFC4282] по обработке двунаправленных символов оказались невыполнимыми;
— запрет неназначенных кодовых точек в разделе 2.4 [RFC4282] фактически запрещает поддержку новых письменностей;
— ни один клиент, прокси или сервер AAA не реализовал ни одного требования раздела 2.4 [RFC4282], среди прочих разделов.

По мере роста популярности международного роуминга важно исправить эти проблемы для надёжных и совместимых сетевых услуг.

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

2. Определение NAI

2.1. Синтаксис UTF-8 и нормализация

Символы UTF-8 можно определить через октеты следующей грамматикой ABNF [RFC5234], взятой из [RFC3629]:

UTF8-xtra-char  =   UTF8-2 / UTF8-3 / UTF8-4
UTF8-2          =   %xC2-DF UTF8-tail
UTF8-3          =   %xE0 %xA0-BF UTF8-tail /
                    %xE1-EC 2( UTF8-tail ) /
                    %xED %x80-9F UTF8-tail /
                    %xEE-EF 2( UTF8-tail )
UTF8-4          =   %xF0 %x90-BF 2( UTF8-tail ) /
                    %xF1-F3 3( UTF8-tail ) /
                    %xF4 %x80-8F 2( UTF8-tail )
UTF8-tail       =   %x80-BF

Эти правила нормативно определены в [RFC3629] и повторены здесь для удобства.

Нормализация обсуждается в [RFC5198] и разделе 2.6 настоящей спецификации. Строки, не находящиеся в нормальной композиционной форме NFC, не являются действительными NAI, и их НЕ СЛЕДУЕТ (SHOULD NOT) считать таковыми. Реализациям, ожидающим NAI, но получающим ненормализованные, хотя в остальном корректные строки UTF-8, СЛЕДУЕТ (SHOULD) пытаться создать локальную версию NAI путём нормализации входного идентификатора. Её можно использовать для локальной обработки. Эта локальная версия идентификатора НЕ ДОЛЖНА (MUST NOT) использоваться за пределами локального контекста.

Если протоколы передают идентификаторы, которые предполагается транспортировать через протокол AAA, РЕКОМЕНДУЕТСЯ (RECOMMENDED) использовать формат NAI. Если идентификаторы не соответствуют формату NAI, системы AAA сами должны это обнаружить и обработать их. Документ не предлагает способа такой обработки, но существующая практика показывает, что она возможна.

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

2.2. Формальный синтаксис

Грамматика NAI приведена ниже в расширенной форме Бэкуса — Наура (ABNF), описанной в [RFC5234].

   nai            =   utf8-username
   nai            =/  "@" utf8-realm
   nai            =/  utf8-username "@" utf8-realm

   utf8-username  =  dot-string

   dot-string     = string *("." string)
   string         = 1*utf8-atext

   utf8-atext     =  ALPHA / DIGIT /
                     "!" / "#" /
                     "$" / "%" /
                     "&" / "'" /
                     "*" / "+" /
                     "-" / "/" /
                     "=" / "?" /
                     "^" / "_" /
                     "`" / "{" /
                     "|" / "}" /
                     "~" /
                     UTF8-xtra-char

   utf8-realm     =  1*( label "." ) label

   label          =  utf8-rtext *(ldh-str)
   ldh-str        =  *( utf8-rtext / "-" ) utf8-rtext
   utf8-rtext     =  ALPHA / DIGIT / UTF8-xtra-char

2.3. Длина NAI

Устройства, обрабатывающие NAI, ОБЯЗАНЫ (MUST) поддерживать длину не менее 72 октетов. Им СЛЕДУЕТ (SHOULD) поддерживать длину NAI 253 октета. При этом следует учитывать следующие особенности реализации:

— ограничения длины NAI в октетах могут сильнее ограничивать число символов UTF-8;
— NAI часто передаются в атрибуте User-Name протокола Remote Authentication Dial-In User Service (RADIUS). К сожалению, в разделе 5.1 [RFC2865] сказано: «рекомендуется возможность обработки как минимум 63 октетов». Поэтому NAI длиннее 63 октетов могут не проходить через некоторые устройства. Кроме того, сообщение RADIUS может содержать только один атрибут User-Name, а максимальная длина атрибута составляет 253 октета; следовательно, RADIUS не поддерживает NAI длиннее 253 октетов;
— NAI также могут передаваться в атрибуте User-Name протокола Diameter [RFC6733], поддерживающем длину содержимого до 2^24 − 9 октетов. Поэтому NAI, обрабатываемые только узлами Diameter, могут быть очень длинными. Однако передаваемый через Diameter NAI может впоследствии преобразовываться для RADIUS, и тогда применяются приведённые выше ограничения;
— NAI могут передаваться в других протоколах, каждый из которых может иметь собственные ограничения максимальной длины.

Эти критерии должны обеспечивать наиболее широкое применение и максимально возможную совместимость NAI.

2.4. Поддержка конфиденциальности имени пользователя

Толкование части NAI с именем пользователя зависит от соответствующей области realm. Поэтому узлам, не входящим в домашний домен этой области, СЛЕДУЕТ (SHOULD) рассматривать часть utf8-username как непрозрачные данные.

Иными словами, только домашний домен способен толковать значение части utf8-username в NAI. Сторонние домены не могут делать выводы об utf8-username и разбивать её на подполя. Например, она может иметь вид firstname.lastname, состоять только из цифр или быть случайным шестнадцатеричным идентификатором. У другого домена нет ни способа, ни причины придавать полю utf8-username какой-либо смысл.

В некоторых случаях NAI используется вместе с отдельным методом аутентификации, способным передавать часть с именем пользователя более защищённым способом для повышения конфиденциальности. Тогда NAI МОЖНО (MAY) предоставить в сокращённой форме, опустив имя пользователя. Опускать его РЕКОМЕНДУЕТСЯ (RECOMMENDED) вместо использования фиксированного имени, например anonymous, поскольку фиксированная часть создаёт неоднозначность: непонятно, относится ли NAI к одному пользователю. Однако текущая практика — использовать имя anonymous вместо пропуска; это также допускается.

Самый распространённый сценарий пропуска или сокрытия имени пользователя — методы EAP на основе TLS, например Tunneled Transport Layer Security (TTLS) [RFC5281]. Они предусматривают «внешний» идентификатор, обычно анонимный @realm. Он позволяет направить запрос аутентификации из посещаемого домена в домашний, сохраняя имя пользователя конфиденциальным для посещаемой сети. Протокол предусматривает «внутренний» обмен аутентификации, при котором для аутентификации пользователя применяется полный идентификатор.

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

Однако некоторые протоколы не поддерживают методы аутентификации с «внутренним» и «внешним» обменом и ограничены публично видимым идентификатором. Поэтому таким протоколам РЕКОМЕНДУЕТСЯ (RECOMMENDED) использовать временные идентификаторы. Авторы признают, что сейчас эта практика не применяется и её реализация, вероятно, будет сложной.

Подобно анонимному пользователю, возможны ситуации, когда конфиденциальны части области realm. В таких ситуациях РЕКОМЕНДУЕТСЯ (RECOMMENDED) также опускать конфиденциальную часть realm, например использовать @example.com вместо @sensitive.example.com или anonymous@sensitive.example.com. Домашний домен является авторитетным для пользователей всех своих поддоменов и при необходимости может направить запрос аутентификации соответствующей подсистеме внутри домашнего домена.

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

2.5. Международные наборы символов

Спецификация допускает как международные имена пользователей, так и международные области realm. Международные имена пользователей основаны на символах Unicode, закодированных в UTF-8. Интернационализация части NAI с именем пользователя основана на расширениях «Internationalized Email Headers» [RFC6532] для части local-part адресов электронной почты [RFC5322].

Для обеспечения канонического представления символы части realm в NAI ОБЯЗАНЫ (MUST) соответствовать ABNF настоящей спецификации и требованиям [RFC5891]. На практике требования сводятся к следующему: области realm ОБЯЗАНЫ (MUST) иметь форму, которую можно зарегистрировать в DNS как полностью определённое доменное имя (FQDN).

Этот список существенно короче и проще списка раздела 2.4 [RFC4282]. Предложенная в [RFC4282] форма зависела от выполнения каноникализации промежуточными узлами на основе недостаточной информации, поэтому не была канонической.

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

Оговорка к приведённой рекомендации связана с вопросами, отмеченными в [RFC6912]: дополнительные ограничения регистрации DNS запрещают некоторым кодовым точкам быть допустимыми в DNS U-label. Эти ограничения нельзя выразить алгоритмически.

Для настоящей спецификации это означает следующее. Области realm, не соответствующие приведённой ABNF, не являются действительными NAI. Однако некоторые области realm, соответствующие ABNF, также являются недействительными NAI. Соответствие ABNF — необходимое, но недостаточное условие для NAI.

В общем случае это требование означает соблюдение требований [RFC5891].

2.6. Процесс нормализации

Преобразование в Unicode и нормализацию СЛЕДУЕТ (SHOULD) выполнять на конечных системах, например ноутбуках, настольных компьютерах и смартфонах, принимающих на вход «локальный» текст. Они лучше всего способны определить намерение пользователя и преобразовать локальный текст в нормализованную форму.

Другие системы AAA, например прокси, не имеют доступа к сведениям о локали и наборе символов, доступным конечным системам. Поэтому они не всегда могут преобразовать локальный ввод в Unicode.

Иными словами, всю обработку NAI из «локальных» наборов символов и локалей в UTF-8 СЛЕДУЕТ (SHOULD) выполнять на конечных системах до поступления NAI в систему AAA. Внутри системы AAA NAI передаются по сети в канонической форме, и эта форма используется для всех сравнений NAI и/или realm.

Копирование локализованного текста в поля, которые позднее могут быть помещены в атрибут RADIUS User-Name, проблематично. В результате прокси AAA может встретить символы, не являющиеся UTF-8, в данных, которые он ожидает как NAI. Примером такого требования является раздел 2.1 [RFC3579]:

«NAS ОБЯЗАН (MUST) скопировать содержимое поля Type-Data сообщения EAP-Response/Identity, полученного от однорангового узла, в атрибут User-Name».

Поэтому прокси AAA ожидают, что EAP-Response/Identity, отправленный клиентом EAP, состоит из символов UTF-8, а не локализованного текста. Применение локализованного текста в полях имени пользователя или идентичности AAA затрудняет или делает невозможной маршрутизацию по realm.

В отличие от раздела 2.4 [RFC4282], теперь предполагается, что системы AAA сравнивают и сопоставляют NAI и выполняют маршрутизацию AAA по NAI в полученном виде. Спецификация обеспечивает каноническое представление, устраняет требование к промежуточным системам AAA, таким как прокси, выполнять преобразования, и должна работать через системы AAA, не знающие о международных наборах символов.

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

— конечным системам, использующим «локализованный» текст, СЛЕДУЕТ (SHOULD) нормализовать NAI до его использования как идентификатора в протоколе аутентификации;
— системам AAA НЕ СЛЕДУЕТ (SHOULD NOT) нормализовать NAI, поскольку у них может не быть достаточной информации для этого.

Однако у этого подхода есть проблемы.

2.6.1. Проблемы процесса нормализации

Требования предыдущего раздела сегодня не реализованы. Например, большинство реализаций EAP использует идентификатор пользователя, переданный другой локальной системой. Он рассматривается как непрозрачный блок данных и без изменений помещается в поле EAP Identity. Предполагается, что любая последующая система, получающая идентификатор, способна его понять и обработать.

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

Эти ограничения имеют следующие теоретические и практические последствия:

— используемые сегодня конечные системы обычно не нормализуют NAI;
— следовательно, системам AAA СЛЕДУЕТ (SHOULD) пытаться нормализовать NAI.

Эти рекомендации противоречат рекомендациям предыдущего раздела. Такова реальность несовершенных протоколов.

Если идентификатор пользователя можно нормализовать или установить, что он уже находится в нормальной форме, нормальная форма ОБЯЗАТЕЛЬНО (MUST) используется в качестве NAI. Во всех остальных случаях идентификатор пользователя НЕ ДОЛЖЕН (MUST NOT) считаться NAI. Тем не менее эти данные остаются идентификатором пользователя. Системы AAA НЕ ДОЛЖНЫ (MUST NOT) отклонять аутентификацию только потому, что идентификатор пользователя не является NAI.

Иными словами, если сервер AAA не распознаёт часть realm в NAI, ему СЛЕДУЕТ (SHOULD) попытаться нормализовать NAI в NFC. Затем нормализованную форму можно использовать для поиска совпадения с известной областью realm. Если совпадение не найдено, при всей последующей обработке СЛЕДУЕТ (SHOULD) использовать первоначальную форму NAI.

Сервер AAA также может преобразовать области realm в Punycode и выполнять все сравнения по полученным строкам Punycode. Это преобразование соответствует приведённым рекомендациям, но может иметь другие эксплуатационные последствия и режимы отказа.

2.7. Использование в других протоколах

Как отмечалось, формат NAI можно применять в других протоколах вне AAA. РЕКОМЕНДУЕТСЯ (RECOMMENDED) использовать приведённое здесь определение без изменений. Другие определения идентификаторов пользователя могут ухудшать совместимость и способность пользователя успешно аутентифицироваться. Протоколам, которым необходим идентификатор пользователя, РЕКОМЕНДУЕТСЯ (RECOMMENDED) использовать формат NAI.

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

Протокол, корректно передающий восьмибитовые данные, вероятно, способен передавать NAI без изменений.

Если протокол не передаёт восьмибитовые данные корректно, он не может передавать NAI без изменений. Предполагается, что специфичный для протокола транспортный уровень кодирует NAI на входе в протокол и декодирует на выходе. Закодированная или экранированная версия NAI не является действительным NAI и НЕ ДОЛЖНА (MUST NOT) передаваться системе AAA.

Например, HTTP переносит идентификаторы пользователей, но экранирует, среди прочих, символ точки как %2E. Если HTTP используется для передачи NAI fred@example.com, передаваемые данные будут иметь вид fred@example%2Ecom. Эти данные существуют только внутри HTTP и не имеют отношения к какой-либо системе AAA.

Любое сравнение, проверка или использование NAI ОБЯЗАТЕЛЬНО (MUST) выполняется для его неэкранированной формы, то есть корректной UTF-8.

2.8. Использование формата NAI для других идентификаторов

Как отмечено в разделе 1, формат NAI РЕКОМЕНДУЕТСЯ (RECOMMENDED) использовать как стандартный формат идентификаторов пользователя. В этом разделе такое применение рассматривается подробнее.

Для определённых контекстов часто полезно создавать новые идентификаторы. Они могут иметь различные свойства, большая часть которых несущественна для документа. Цель — создать идентификаторы общеизвестного формата с пространствами имён. Формат NAI удовлетворяет этим требованиям.

Один из примеров — private user identity, идентификатор, определённый 3rd Generation Partnership Project (3GPP). Он однозначно идентифицирует пользователя для сети и используется для авторизации, аутентификации, учёта, администрирования и других целей. Этот идентификатор глобально уникален и определяется оператором домашней сети. Его формат явно определён как NAI в разделе 13.3 [3GPP]:

«Частный идентификатор пользователя должен иметь форму NAI, а именно username@realm, как указано в разделе 2.1 IETF RFC 4282».

В 3GPP часть username — уникальный идентификатор, полученный из сведений, специфичных для устройства. Часть realm состоит из сведений о домашней сети и базовой строки 3gppnetwork.org, например 234150999999999@ims.mnc015.mcc234.3gppnetwork.org.

Определённый 3GPP формат обеспечивает глобальную уникальность идентификатора, поскольку основан на домене 3gppnetwork.org. Префикс ims.mnc015.mcc234 обеспечивает привязку части realm к конкретной домашней сети или организации. Наконец, обеспечивается общеизвестный формат части username.

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

3. Маршрутизация внутри систем AAA

Многие системы AAA используют часть utf8-realm идентификатора NAI для маршрутизации запросов в сети прокси AAA. Семантика операции предполагает логическую таблицу маршрутизации AAA, где utf8-realm служит ключом, а значениями являются один или несколько серверов AAA «следующего перехода».

Промежуточные узлы ОБЯЗАНЫ (MUST) использовать utf8-realm NAI для поиска без изменений. Как отмечалось, они могут не иметь тех же сведений о локали, что и система, передавшая NAI в систему маршрутизации AAA. Поэтому почти все сравнения «без учёта регистра» могут быть ошибочными. Если utf8-realm целиком состоит из ASCII, существующие системы AAA иногда сопоставляют realm без учёта регистра. Такую практику МОЖНО (MAY) продолжать, поскольку она доказала работоспособность.

Во многих существующих системах вне AAA идентификаторы пользователей похожи по формату на NAI, но не соответствуют спецификации. Например, они могут быть не в форме NFC или содержать несколько символов @. Промежуточным узлам СЛЕДУЕТ (SHOULD) нормализовать идентификаторы не в NFC перед поиском utf8-realm в логической таблице маршрутизации. Промежуточные узлы НЕ ДОЛЖНЫ (MUST NOT) изменять пересылаемые идентификаторы. Данные в том виде, в каком их ввёл пользователь, неприкосновенны.

Значение utf8-realm в логической таблице маршрутизации AAA СЛЕДУЕТ (SHOULD) предоставлять прокси до получения им какого-либо трафика AAA. Значение utf8-realm СЛЕДУЕТ (SHOULD) получать от системы «следующего перехода» или «домашней» системы, которая также предоставляет сведения маршрутизации, необходимые пакетам для достижения следующего перехода.

Такие сведения могут включать любую комбинацию следующего: IP-адрес, порт, общий секрет RADIUS, сертификат TLS, имя хоста DNS или указание применять динамическое обнаружение DNS, то есть искать запись в домене utf8-realm. Список не является исчерпывающим и может расширяться будущими спецификациями.

Для решений о маршрутизации РЕКОМЕНДУЕТСЯ (RECOMMENDED) использовать utf8-realm целиком. Однако системы AAA МОГУТ (MAY) использовать часть utf8-realm при условии, что она сама является действительным utf8-realm и обрабатывается указанным выше способом. Например, направлять fred@example.com в пункт назначения com запрещено, поскольку com не является действительным utf8-realm. Но направлять fred@sales.example.com в example.com допустимо.

Другая причина запрета одной метки, например fred@sales, заключается в том, что многие системы вне AAA считают одну метку локальным идентификатором внутри своей области. Так, пользователь, входящий как fred@sales в домен example.com, рассматривался бы так, будто его NAI — fred@sales.example.com. Разрешение одной метки изменило бы её толкование и смысл, что невозможно.

3.1. Совместимость с именами пользователей электронной почты

Предлагаемый в документе NAI имеет форму user@realm. Хотя часть пользователя основана на local-part адреса электронной почты из Internet Message Format [RFC5322] с расширениями Internationalized Email Headers [RFC6532], она изменена для целей раздела 2.2. В ней не допускаются заключённый в кавычки текст и пробельные символы с переносами или без переносов, обычно используемые в адресах электронной почты. Поэтому NAI не обязательно эквивалентен именам пользователей электронной почты.

Однако использование адресов электронной почты как идентификаторов пользователей в системах AAA распространено. ABNF раздела 2.2 определена близкой к части addr-spec из [RFC5322] с расширениями [RFC6532] и при этом совместимой с [RFC4282].

В отличие от раздела 2.5 [RFC4282], документ утверждает, что требования интернационализации NAI и адресов электронной почты существенно схожи. NAI и почтовые идентификаторы могут совпадать; оба должны вводиться пользователем и/или оператором, предоставляющим ему сетевой доступ. Поэтому существуют веские основания для сходства требований интернационализации.

3.2. Совместимость с DNS

Часть utf8-realm NAI предназначена для совместимости с интернационализированными доменными именами (IDN) [RFC5890]. Как определено выше, при передаче через протокол, корректно поддерживающий восьмибитовые данные, например RADIUS или EAP, utf8-realm может содержать любой действительный символ UTF-8. Поэтому NAS нет необходимости преобразовывать часть utf8-realm идентификатора NAI в Punycode [RFC3492] перед помещением NAI в атрибут RADIUS User-Name.

NAI не различает A-label и U-label, поскольку эти термины специфичны для DNS. Вместо этого используется метка, допустимая в IDNA согласно первому пункту раздела 2.3.2.1 [RFC5890]. Как там отмечено, понятие IDNA-valid label охватывает и A-label, и U-label.

Когда часть realm NAI используется как основа разрешения имён, может потребоваться преобразование интернационализированных имён realm в Punycode [RFC3492] согласно [RFC5891]. Как отмечено в разделе 2 [RFC6055], программные интерфейсы разрешителей имён не обязательно специфичны для DNS, поэтому преобразование в Punycode нужно выполнять осторожно:

Приложения, преобразующие IDN в форму A-label перед вызовом, например, getaddrinfo(), вызовут ошибки разрешения имён, если имя Punycode непосредственно используется в таких протоколах. Преобразование библиотеками или протоколами из A-label в кодировку, определённую протоколом, например UTF-8, потребовало бы изменений API и/или серверов, чего Internationalized Domain Names for Applications (IDNA) был призван избежать.

Поэтому приложениям НЕ СЛЕДУЕТ (SHOULD NOT) предполагать, что имена вне ASCII разрешаются через публичный DNS, и автоматически преобразовывать их в A-label, не зная, какой протокол выберет библиотека разрешения имён.

3.3. Построение области realm

Домашняя область обычно присутствует в части utf8-realm идентификатора NAI, но иногда можно использовать другую область. Это может быть полезно, например, если домашняя область достижима только через промежуточные прокси.

Такое использование может препятствовать совместимости, если участвующие стороны взаимно не согласовали его допустимость. В частности, в NAI НЕ ДОЛЖНА (MUST NOT) использоваться область, отличная от домашней, если отправитель явно не знает, что (a) указанная другая область доступна и (b) она поддерживает такое использование. Отправитель может определить выполнение этих условий с помощью базы данных, динамического обнаружения или иных не определённых здесь средств. На первое условие влияет роуминг: доступность другой области может зависеть от местоположения пользователя или требуемого приложения.

По умолчанию ОБЯЗАТЕЛЬНО (MUST) используется домашняя область, если не настроено иное.

3.3.1. Исторические практики

Некоторые системы AAA исторически использовали модификации NAI с несколькими «префиксами» и «суффиксами» для явной маршрутизации через несколько прокси внутри сети AAA.

В средах на основе RADIUS использование дополненного NAI НЕ РЕКОМЕНДУЕТСЯ (NOT RECOMMENDED) по следующим причинам:

— явные пути маршрутизации ненадёжны и не реагируют на изменения сети при появлении или отключении серверов либо изменении деловых отношений;
— протокол маршрутизации RADIUS отсутствует, поэтому пути необходимо сообщать «по внешнему каналу» всем промежуточным узлам AAA, а также всем конечным системам, например клиентам аутентификации, ожидающим получить доступ к сети;
— при изменении маршрута AAA необходимо обновить сведения о пути в тысячах, если не миллионах конечных систем. Это ведёт к огромным расходам на обновления, которые лучше выполнить лишь в нескольких системах AAA сети;
— ручное обновление путей RADIUS дорого, длительно и подвержено ошибкам;
— создавать совместимые форматы NAI трудно, если локально определённые «префиксы» и «суффиксы» конфликтуют с аналогичными практиками в других частях сети. В некоторых случаях такие конфликты делают соединение двух сетей невозможным, поскольку пакеты невозможно правильно маршрутизировать с соблюдением требований всех промежуточных прокси;
— использование системы имён DNS для имён realm обеспечивает глобально уникальное пространство имён областей.

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

Несмотря на эти рекомендации, описанная практика широко используется для маршрутизации Diameter [RFC5729]. Описанные там маршруты управляются автоматически как при предоставлении учётных данных, так и при обновлении маршрутизации. Они существуют внутри определённой системы, обычно 3G, с контролируемым участием и стандартизованным поведением. Проблем использования явной маршрутизации в такой среде не известно.

Однако если используются дополненные идентификаторы, например:

homerealm.example.org!user@otherrealm.example.net

то часть перед неэкранированным ! ОБЯЗАНА (MUST) быть utf8-realm согласно ABNF раздела 2.2. При получении такого идентификатора система otherrealm.example.net ОБЯЗАНА (MUST) преобразовать его в user@homerealm.example.org до пересылки запроса. Пересылающая система затем ОБЯЗАНА (MUST) применить обычную маршрутизацию AAA для транзакции по обновлённому идентификатору.

3.4. Примеры

Примеры действительных идентификаторов сетевого доступа:

bob
joe@example.com
fred@foo-9.example.com
jack@3rd.depts.example.com
fred.smith@example.com
fred_smith@example.com
fred$@example.com
fred=?#$&*+-/^smith@example.com
nancy@eng.example.net
eng.example.net!nancy@example.net
eng%nancy@example.net
@privatecorp.example.net
\(user\)@example.net

Ещё один действительный NAI показан шестнадцатеричной строкой, поскольку документ может содержать только символы ASCII:

626f 6240 ceb4 cebf ceba ceb9 cebc ceae 2e63 6f6d

Примеры недействительных идентификаторов сетевого доступа:

fred@example
fred@example_9.com
fred@example.net@example.net
fred.@example.net
eng:nancy@example.net
eng;nancy@example.net
(user)@example.net
<nancy>@example.net

Один пример из [RFC4282] по-прежнему допускается ABNF, но НЕ РЕКОМЕНДУЕТСЯ (NOT RECOMMENDED), поскольку использует кодировку Punycode [RFC3492] для строки, которая теперь является допустимой UTF-8:

alice@xn--tmonesimerkki-bfbb.example.net

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

Поскольку NAI раскрывает домашнюю принадлежность пользователя, он может помочь злоумышленнику при дальнейшем исследовании пространства имён пользователей. Обычно эта проблема наиболее существенна для протоколов, передающих имя пользователя через Интернет открытым текстом, например RADIUS [RFC2865] [RFC2866]. Чтобы предотвратить прослушивание имени пользователя, протоколы могут использовать средства конфиденциальности транспортирующих их протоколов, например RADIUS, защищённый IPsec [RFC3579], или Diameter, защищённый TLS [RFC6733].

Спецификация добавляет возможность скрыть часть NAI с именем пользователя, опустив её. Как обсуждается в разделе 2.4, это возможно только при использовании NAI вместе с отдельным методом аутентификации, способным безопасно передать имя пользователя. В некоторых случаях с NAI также применялись механизмы конфиденциальности, специфичные для приложения. Например, некоторые методы EAP применяют специфичные для метода псевдонимы в части имени пользователя NAI [RFC3748]. Хотя ни один из этих подходов не защищает часть realm, их преимущество перед транспортной защитой в том, что конфиденциальность имени пользователя сохраняется даже для промежуточных узлов, например NAS.

4.1. Сопоставление идентичностей во времени и между протоколами

Рекомендации разделов 2.7 и 2.8 по использованию NAI в других протоколах влияют на конфиденциальность. Любой злоумышленник, способный наблюдать трафик с NAI, может отслеживать пользователя и сопоставлять его действия во времени и между несколькими протоколами. Поэтому учётные данные аутентификации СЛЕДУЕТ (SHOULD) передавать через каналы, допускающие конфиденциальную связь, либо СЛЕДУЕТ (SHOULD) использовать несколько идентификаторов, чтобы исключить отслеживание пользователя.

Для повышения конфиденциальности пользователя РЕКОМЕНДУЕТСЯ (RECOMMENDED) настраивать несколько идентификаторов на одного пользователя. Их можно менять со временем, затрудняя отслеживание злонамеренным наблюдателем. Однако предоставление идентификаторов и управление ими могут быть сложны на практике — вероятно, поэтому несколько идентификаторов сегодня используются редко.

4.2. Несколько идентификаторов

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

В разделе 2.4 обсуждались «внутренние» и «внешние» идентификаторы в контексте TTLS [RFC5281]. Внимательное чтение спецификации показывает, что внутренний и внешний идентификаторы никак не обязаны быть связаны. Совершенно допустимо использовать @example.com как внешний идентификатор, а user@example.org — как внутренний. Запрос аутентификации будет направлен в example.com, который, вероятно, не сможет аутентифицировать user@example.org.

Хуже того, из-за ошибки настройки example.com может переслать внутренний запрос аутентификации в домен example.org. Такая междоменная аутентификация весьма проблематична; веских причин разрешать её немного.

Поэтому системам, допускающим анонимные «внешние» идентификаторы, РЕКОМЕНДУЕТСЯ (RECOMMENDED) требовать, чтобы «внутренний» домен совпадал с «внешним» или был его поддоменом. Запрос аутентификации с различными областями realm является нарушением безопасности, и его СЛЕДУЕТ (SHOULD) отклонять.

При участии нескольких протоколов ситуация ухудшается. TTLS допускает передачу Microsoft CHAP (MS-CHAP) [RFC2433] внутри TLS-туннеля. MS-CHAP определяет собственный идентификатор, инкапсулированный в обмен MS-CHAP. Он не обязан иметь определённый формат или кодировку UTF-8 и на практике может использовать один из многих неизвестных наборов символов. Практического способа определить использованный набор символов нет.

В результате «внешний» EAP Identity, переносимый TTLS, вероятно, даже не использует тот же набор символов, что и «внутренний» идентификатор MS-CHAP. Эти два идентификатора полностью независимы и принципиально несопоставимы.

Такая конструкция протокола НЕ РЕКОМЕНДУЕТСЯ (NOT RECOMMENDED).

5. Администрирование имён

Чтобы избежать новых административных процедур, администрирование пространства имён realm для NAI опирается на администрирование пространства имён DNS.

Имена NAI realm должны быть уникальны; право использовать конкретную область NAI для роуминга приобретается одновременно с правом использовать соответствующее полностью определённое доменное имя (FQDN). Желающим использовать имя NAI realm следует сначала получить право на соответствующее FQDN. Администраторы НЕ ДОЛЖНЫ (MUST NOT) публично использовать NAI realm, предварительно не владея соответствующим FQDN. Частное использование областей NAI без владения ими внутри административного домена допускается, хотя РЕКОМЕНДУЕТСЯ (RECOMMENDED) использовать имена для примеров, например example.com.

Использование FQDN как имени realm не требует применения DNS для поиска сервера аутентификации. Хотя Diameter [RFC6733] поддерживает поиск серверов аутентификации через DNS, существующие реализации RADIUS обычно используют файлы конфигурации прокси для поиска серверов аутентификации внутри домена и маршрутизации аутентификации. Реализации, описанные в [RFC2194], не использовали DNS для поиска сервера аутентификации внутри домена. Аналогично существующие реализации не обнаружили необходимости в динамических протоколах маршрутизации или распространении глобальных сведений о маршрутизации. Также NAI не обязан представлять действительный адрес электронной почты.

6. Ссылки

6.1. Нормативные ссылки

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.
[RFC3629]  Yergeau, F., "UTF-8, a transformation format of
              ISO 10646", STD 63, RFC 3629, November 2003,
              <http://www.rfc-editor.org/info/rfc3629>.
[RFC5198]  Klensin, J. and M. Padlipsky, "Unicode Format for Network
              Interchange", RFC 5198, March 2008,
              <http://www.rfc-editor.org/info/rfc5198>.
[RFC5234]  Crocker, D., Ed., and P. Overell, "Augmented BNF for
              Syntax Specifications: ABNF", STD 68, RFC 5234,
              January 2008, <http://www.rfc-editor.org/info/rfc5234>.
[RFC5890]  Klensin, J., "Internationalized Domain Names for
              Applications (IDNA): Definitions and Document Framework",
              RFC 5890, August 2010,
              <http://www.rfc-editor.org/info/rfc5890>.
[RFC5891]  Klensin, J., "Internationalized Domain Names in
              Applications (IDNA): Protocol", RFC 5891, August 2010,
              <http://www.rfc-editor.org/info/rfc5891>.
[RFC6365]  Hoffman, P. and J. Klensin, "Terminology Used in
              Internationalization in the IETF", BCP 166, RFC 6365,
              September 2011, <http://www.rfc-editor.org/info/rfc6365>.

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

[RFC2194]  Aboba, B., Lu, J., Alsop, J., Ding, J., and W. Wang,
              "Review of Roaming Implementations", RFC 2194,
              September 1997, <http://www.rfc-editor.org/info/rfc2194>.
[RFC2341]  Valencia, A., Littlewood, M., and T. Kolar, "Cisco
              Layer Two Forwarding (Protocol) "L2F"", RFC 2341,
              May 1998, <http://www.rfc-editor.org/info/rfc2341>.
[RFC2433]  Zorn, G. and S. Cobb, "Microsoft PPP CHAP Extensions",
              RFC 2433, October 1998,
              <http://www.rfc-editor.org/info/rfc2433>.
[RFC2637]  Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little,
              W., and G. Zorn, "Point-to-Point Tunneling Protocol
              (PPTP)", RFC 2637, July 1999,
              <http://www.rfc-editor.org/info/rfc2637>.
[RFC2661]  Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn,
              G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"",
              RFC 2661, August 1999,
              <http://www.rfc-editor.org/info/rfc2661>.
[RFC2865]  Rigney, C., Willens, S., Rubens, A., and W. Simpson,
              "Remote Authentication Dial In User Service (RADIUS)",
              RFC 2865, June 2000,
              <http://www.rfc-editor.org/info/rfc2865>.
[RFC2866]  Rigney, C., "RADIUS Accounting", RFC 2866, June 2000,
              <http://www.rfc-editor.org/info/rfc2866>.
[RFC3492]  Costello, A., "Punycode: A Bootstring encoding of Unicode
              for Internationalized Domain Names in Applications
              (IDNA)", RFC 3492, March 2003,
              <http://www.rfc-editor.org/info/rfc3492>.
[RFC3579]  Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication
              Dial In User Service) Support For Extensible
              Authentication Protocol (EAP)", RFC 3579, September 2003,
              <http://www.rfc-editor.org/info/rfc3579>.
[RFC3748]  Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
              Levkowetz, Ed., "Extensible Authentication Protocol
              (EAP)", RFC 3748, June 2004,
              <http://www.rfc-editor.org/info/rfc3748>.
[RFC4282]  Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
              Network Access Identifier", RFC 4282, December 2005,
              <http://www.rfc-editor.org/info/rfc4282>.
[RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", RFC 4301, December 2005,
              <http://www.rfc-editor.org/info/rfc4301>.
[RFC5281]  Funk, P. and S. Blake-Wilson, "Extensible Authentication
              Protocol Tunneled Transport Layer Security Authenticated
              Protocol Version 0 (EAP-TTLSv0)", RFC 5281, August 2008,
              <http://www.rfc-editor.org/info/rfc5281>.
[RFC5322]  Resnick, P., Ed., "Internet Message Format", RFC 5322,
              October 2008, <http://www.rfc-editor.org/info/rfc5322>.
[RFC5335]  Yang, A., Ed., "Internationalized Email Headers",
              RFC 5335, September 2008,
              <http://www.rfc-editor.org/info/rfc5335>.
[RFC5729]  Korhonen, J., Ed., Jones, M., Morand, L., and T. Tsou,
              "Clarifications on the Routing of Diameter Requests Based
              on the Username and the Realm", RFC 5729, December 2009,
              <http://www.rfc-editor.org/info/rfc5729>.
[RFC6055]  Thaler, D., Klensin, J., and S. Cheshire, "IAB Thoughts on
              Encodings for Internationalized Domain Names", RFC 6055,
              February 2011, <http://www.rfc-editor.org/info/rfc6055>.
[RFC6532]  Yang, A., Steele, S., and N. Freed, "Internationalized
              Email Headers", RFC 6532, February 2012,
              <http://www.rfc-editor.org/info/rfc6532>.
[RFC6733]  Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn,
              Ed., "Diameter Base Protocol", RFC 6733, October 2012,
              <http://www.rfc-editor.org/info/rfc6733>.
[RFC6912]  Sullivan, A., Thaler, D., Klensin, J., and O. Kolkman,
              "Principles for Unicode Code Point Inclusion in Labels in
              the DNS", RFC 6912, April 2013,
              <http://www.rfc-editor.org/info/rfc6912>.

[EDUROAM] "eduroam (EDUcation ROAMing)", <http://eduroam.org>.

[3GPP]     3GPP, "Numbering, addressing and Identification", 3GPP TS
              23.003, Release 12, July 2014,
              <ftp://ftp.3gpp.org/Specs/archive/23_series/23.003/>.

Приложение A. Изменения относительно RFC 4282

В документ внесены следующие обновления предыдущего определения NAI в RFC 4282 [RFC4282]:

— формальный синтаксис раздела 2.1 обновлён и запрещает символы вне UTF-8, например символы с установленным старшим битом;
— формальный синтаксис раздела 2.1 [RFC4282] обновлён и допускает UTF-8 в части realm NAI;
— формальный синтаксис раздела 2.1 [RFC4282] применялся к NAI после «интернационализации» функцией ToAscii, а содержимое до этого оставалось неопределённым. Настоящий документ определяет интернационализированную форму NAI и запрещает использовать ToAscii для его «интернационализации»;
— грамматика частей пользователя и realm основана на сочетании nai из раздела 2.1 [RFC4282] и utf8-addr-spec из раздела 4.4 [RFC5335];
— всё применение ToAscii перенесено в обычные требования к реализациям DNS, когда realm используется для DNS-поиска. Это не требует изменений существующей инфраструктуры DNS;
— обсуждение международных наборов символов раздела 2.4 [RFC4282] обновлено; предложение использовать ToAscii для сравнения realm удалено. Ни одна система AAA не реализовала эти предложения, поэтому изменение не должно влиять на эксплуатацию;
— раздел «Маршрутизация внутри систем AAA» является новым. Понятие «локальной таблицы маршрутизации AAA» тоже новое, хотя точно описывает функциональность распространённых реализаций;
— разделы «Совместимость с именами пользователей электронной почты» и «Совместимость с DNS» пересмотрены и обновлены. Преобразование Punycode предлагается использовать только когда имя realm применяется для DNS-поиска; даже тогда функция используется только локальным API разрешителя имён, и рекомендуется, чтобы это преобразование выполняла только домашняя сеть;
— раздел «Построение области realm» обновлён: изменение NAI НЕ РЕКОМЕНДУЕТСЯ (NOT RECOMMENDED);
— из раздела «Примеры» удалён пример преобразования IDN в ASCII. Теперь такое поведение запрещено.

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

Исходным текстом документа был [RFC4282], затем значительно переработанный. Авторами [RFC4282] были Bernard Aboba, Mark A. Beadles, Jari Arkko и Pasi Eronen.

Адрес автора

Alan DeKok
   The FreeRADIUS Server Project

EMail: aland@freeradius.org

Перевод: RFCNET · rfcnet.ru

Original copyright notice
Copyright Notice

   Copyright (c) 2015 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

























DeKok                        Standards Track                    [Page 2]

RFC 7542              The Network Access Identifier             May 2015

Неофициальный перевод. При расхождениях см. оригинал.