RFC 3846 Mobile IPv4 Extension for Carrying Network Access Identifiers

Network Working Group                                   F. Johansson
Request for Comments: 3846                               ipUnplugged
Category: Standards Track                               T. Johansson
                                                          Bytemobile
                                                           June 2004

Расширение Mobile IPv4 для передачи идентификаторов доступа

Mobile IPv4 Extension for Carrying Network Access Identifiers

PDF

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

Данный документ содержит спецификацию стандартного протокола Internet, предложенного сообществу Internet, и является приглашением к дискуссии в целях развития этого протокола. Сведения о текущем состоянии стандартизации протокола вы найдете в документе Internet Official Protocol Standards (STD 1). Документ можно распространять без ограничений.

Авторские права

Copyright (C) The Internet Society (2004).

Тезисы

При перемещении мобильного узла из одной сети в другую требуется повторная аутентификация этого узла. Если в домашней сети используется множество серверов AAA1 и агентов HA2 у сервера Home AAA может отсутствовать достаточная для корректной повторной аутентификации узла информация, что может привести к необходимости смены HA для узла. В настоящем документе определено расширение Mobile IP, используемое для передачи идентификаторов серверам Home AAA и HA в форме NAI3. Это расширение позволяет агентам HA передавать свою идентификационную информацию, а также данные о сервере Home AAA мобильному узлу, который может передать ее на локальный сервер AAA при изменении точки подключения. Это расширение может также использоваться в других ситуациях, требующих обмена NAI между узлами Mobile IP.

Оглавление

Исключено из версии HTML

1. Введение

При создании сетей одним из требованием является обеспечение резервирования. Для решения этой задачи в одном домене может использоваться множество серверов AAA. Когда мобильный узел регистрируется в сети, процедура аутентификации выполняется с использованием одного из серверов AAA в домашнем домене пользователя. При последующей регистрации пользователя в другом домене процедура аутентификации должна повторяться. Однако избыточность, обеспечиваемая протоколом AAA, может привести к тому, что повторная аутентификация будет выполняться с использованием другого сервера AAAH, который может не иметь информации о присвоенной сессии HA. В этом документе определяется расширение протокола Mobile IP, которое может использоваться для распространения данных, позволяющих решить эту проблему. Более того, обычно единственной информацией о домашнем агенте (HA) в регистрационном запросе является адрес IP, как определено в RFC 3344 [5]. К сожалению этого может оказаться недостаточно для некоторых инфраструктур AAA (таких, как Diameter [6]), использующих маршрутизацию на базе областей (realm); таким инфраструктурам AAA требуется знать полное имя FQDN4 для домашнего агента, чтобы обеспечить корректную обработку. Просмотр обратной зоны DNS5 позволяет идентифицировать лишь интерфейс Mobile IP для IP-адреса HA, который может не обеспечивать взаимно-однозначного соответствия с именем FQDN данного домашнего агента. Это является для HA основанием включать свою идентификацию в регистрационный отклик. Определенное в этом документе расширение MIP v4 включает также субтип, показывающий, как это можно сделать. Идентификация HA тогда может быть включена мобильным узлом в последующие регистрационные запросы через другие точки подключения.

2. Спецификация требований

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не следует (SHALL NOT), следует (SHOULD), не нужно (SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе должны интерпретироваться в соответствии с BCP 14, RFC 2119 [1].

Используемая в документе терминология, связанная с Mobile IP, описана в RFC 3344 [5]. В дополнение здесь определено еще несколько используемых в данном документе терминов:

AAAH

Один из нескольких серверов AAA в домашней сети

FQDN

Fully Qualified Domain Name – полное доменное имя, включающее имя хоста в домене и имя самого домена.

Identity

Идентификация узла, определяемая его FQDN.

NAI

Network Access Identifier – идентификатор доступа в сеть [2].

3. Расширение для передачи NAI

В этом документе описывается расширение NAI Carrying Extension, которое может использоваться в запросах и откликах Mobile IP Registration, а также в анонсах Mobile IP Agent [5]. Расширение может быть использовано любым узлом, которых хочет передать идентификацию в форме NAI [4]. В этом документе определены также несколько номеров субтипов, которые идентифицируют конкретные типы передаваемых NAI (главы 4 и 5). Предполагается, что дополнительные типы NAI будут определяться в последующих документах.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |   Length      |   Sub-Type    |    NAI ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type (тип) — 136 (может быть опущен) [5].

Length (размер) – 8-битовое целое число без знака. Задает размер расширения в октетах с учетом полей Type и Length. В это поле должно помещаться значение, на 1 превышающее общий размер поля NAI.

Sub-Type (субтип) – это поле показывает конкретный тип NAI, передаваемый в поле NAI.

NAI – значение NAI [2] в форме строки (string).

3.1. Обработка NAI Carrying Extension

Когда мобильный узел или домашний агент добавляет NAI Carrying Extension в регистрационное сообщение, это расширение должно размещяться до любых расширений, связанных с аутентификацией.

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

Если агент HA добавил NAI Carrying Extension в отклик Registration Reply для MN, и не получил расширение NAI в последующих сообщениях Registration Request от MN, этот агент HA может предполагать, что MN не понимает расширение NAI. В таких случаях агенту HA не нужно добавлять это расширение NAI в конце последующих сообщений Registration Reply, передаваемых MN.

4. Субтип HA Identity

Для HA Identity используется субтип 1 расширения NAI Carrying Extension. Идентификация содержит значение NAI для HA в форме hostname@realm. Имя хоста вместе с областью формируют полное имя FQDN (hostname.realm) для HA.

Домашний агент, использующий это расширение, должен обеспечить его присутствие в первом сообщении Registration Reply, передаваемом мобильному узлу MN7, который в настоящее время не зарегистрирован. Расширение требуется включать в последующие сообщения Registration Reply лишь в тех случаях, когда это же было расширение включено в сообщение Registration Request, полученное от того же узла MN.

Мобильный узел, использующий это расширение, должен (если он получает это расширение в сообщении Registration Reply) включать его в каждый последующий регистрационный запрос, когда требуется повторная аутентификация. Отказ в повторной аутентификации (например, по причине недоступности AAAH) может приводить к прерыванию сеанса Mobile IP. При инициировании новой сессии мобильному узлу может передаваться новое значение HA Identity NAI и приведенные выше требования будут относиться к полученному в этом случае NAI.

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

Чужому агенту, который получил HA NAI с этим расширением в регистрационном запросе, следует включить HA NAI при запросе аутентификации MN через инфраструктуру AAA, если используемый протокол AAA способен передать эту информацию.

5. Субтип AAAH Identity

Для AAAH Identity используется субтип 2 расширения NAI Carrying Extension. Идентификация содержит NAI домашнего сервера AAA в формате hostname@realm. Имя хоста вместе с областью формируют полное имя FQDN (hostname.realm) для домашнего сервера AAA.

Если в домашней сети имеется несколько серверов AAA, домашний агент, обеспечивающий поддержку выбора AAAH, в соответствии с данным документом должен обеспечивать AAAH identity в первом сообщении Registration Reply, передаваемом мобильному узлу MN. Расширение требуется включать в последующие сообщения Registration Reply лишь в тех случаях, когда это же расширение было включено в сообщение Registration Request, полученное от того же узла MN.

Мобильному узлу следует сохранять последнюю идентификацию AAAH Identity, полученную в сообщении Registration Reply, а также следует включать AAAH Identity в каждое последующее сообщение Registration Request при повторной аутентификации в целях повышения эффективности. Невозможность доступа к указанному серверу AAAH при повторной аутентификации будет приводить к возврату нового значения AAAH Identity NAI (которое следует сохранить и включать в последующие регистрационные запросы). Отказ при аутентификации (например, в результате недоступности AAAH) будет приводить к разрыву сессии Mobile IP; при инициировании нового сеанса мобильному узлу может указываться новое значение AAAH для его использования после новой регистрации.

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

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

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

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

7. Согласование с IANA

В этом документе определены новое расширение Mobile IP и новое пространство кодов субтипа расширений Mobile IP для управления IANA.

В главе 3 определено новое расширение Mobile IP — Mobile IP NAI Carrying Extension. Код типа для этого расширения — 136. Данное расширение добавляет новое пространство кодов субтипа, в котором значения 1 и 2 выделены настоящим документом. Рассмотрение новых кодов субтипа для Mobile IP NAI Carrying Extension выполняется в соответствии с процедурой Expert Review8, и описывается при необходимости, как указано в документе [3].

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

Для расширений NAI Carrying Extension следует выделять значения кодов типа одновременно из пространства IANA для необязательных (skippable) расширений Mobile IPv4 и пространства IANA для анонсов Mobile IPv4. В идеальном случае выделяемые из этих пространств значения должны совпадать.

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

Спасибо авторам исходного документа GNAIE — Mohamed M Khalil, Emad Qaddoura, Haseeb Akhtar и Pat R. Calhoun. Исходный документ был удален из “сферы влияния” рабочей группы MIP, поскольку она не использовала данное расширение. Идеи этого документа использованы здесь. Благодарим также Henrik Levkowetz и Kevin Purser за их полезные отклики и помощь в написании этого документа.

9. Нормативные документы

[1] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, March 1997.

[2] Aboba, B. and M. Beadles, «The Network Access Identifier», RFC 2486, January 1999.

[3] Narten, T. and H. Alvestrand, «Guidelines for Writing an IANA Considerations Section in RFCs», BCP 26, RFC 2434, October 1998.

[4] Calhoun, P. and C. Perkins, «Mobile IP Network Access Identifier Extension for IPv4», RFC 2794, March 2000.

[5] Perkins, C., «IP Mobility Support for IPv4», RFC 3344, August 2002.

[6] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. Arkko, «Diameter Base Protocol», RFC 3588, September 2003.

10. Адреса авторов

Fredrik Johansson

ipUnplugged AB

Arenavagen 23

Stockholm S-121 28

SWEDEN

Phone: +46 8 725 5916

EMail: fredrik@ipunplugged.com

Tony Johansson

Bytemobile Inc

2029 Stierlin Court

Mountain View, CA 94043

USA

Phone: +1 650 862 0523

EMail: tony.johansson@bytemobile.com


Перевод на русский язык

Николай Малых

EMail: nmalykh@gmail.com

11. Полное заявление авторских прав

Copyright (C) The Internet Society (2004).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an «AS IS» basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Интеллектуальная собственность

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF’s procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

Подтверждение

Финансирование функций RFC Editor обеспечено Internet Society.

1Authentication Authorization and Accounting – аутентификация, авторизация (предоставление полномочий) и учет.

2Home Agent – домашний агент.

3Network Access Identifier – идентификатор доступа в сеть.

4Fully Qualified Domain Name.

5Reverse DNS lookup.

6Foreign Agent.

7Mobile Node.

8Рецензия эксперта.




RFC 3748 Extensible Authentication Protocol (EAP)

Network Working Group                                       B. Aboba
Request for Comments: 3748                                 Microsoft
Obsoletes: 2284                                             L. Blunk
Category: Standards Track                         Merit Network, Inc
                                                       J. Vollbrecht
                                           Vollbrecht Consulting LLC
                                                          J. Carlson
                                                                 Sun
                                                   H. Levkowetz, Ed.
                                                         ipUnplugged
                                                           June 2004

Расширяемый протокол аутентификации (EAP)

Extensible Authentication Protocol (EAP)

PDF

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

В этом документе содержится спецификация протокола, предложенного сообществу Internet. Документ служит приглашением к дискуссии в целях развития и совершенствования протокола. Текущее состояние стандартизации протокола вы можете узнать из документа Internet Official Protocol Standards (STD 1). Документ может распространяться без ограничений.

Авторские права

Copyright (C) The Internet Society (2004).

Тезисы

В этом документе определен расширяемый протокол аутентификации (EAP1) — модель проверки подлинности, которая поддерживает множество методов проверки. EAP обычно работает непосредственно на базе протоколов канального уровня типа PPP2 или IEEE 802 и не требует использования протокола IP. EAP обеспечивает собственную поддержку повторов передачи и избавления от дубликатов, основанную на гарантированном порядке доставки нижележащего уровня. Фрагментация в EAP не поддерживается, однако отдельные методы EAP могут реализовать свои средства фрагментации.

Этот документ отменяет действие RFC 2284. Перечень отличий от RFC 2284 приведен в Приложении A.

Оглавление

Исключено в версии HTML.

1. Введение

В этом документе определен расширяемый протокол аутентицикации (EAP) — модель проверки подлинности, которая поддерживает множество методов проверки. EAP обычно работает непосредственно на базе протоколов канального уровня типа PPP или IEEE 802 и не требует использования протокола IP. EAP обеспечивает собственную поддержку повторов передачи и избавления от дубликатов, но она основана на гарантированном порядке доставки нижележащего уровня. Фрагментация в EAP не поддерживается, однако отдельные методы EAP могут реализовать свои средства фрагментации.

EAP может использоваться на выделенных каналах и в коммутируемых устройствах как в проводных, так и в беспроводных средах. В настоящее время протокол EAP реализован на хостах и маршрутизаторах, которые соединены через устройства коммутации или по телефонным линиям с использованием протокола PPP [RFC1661]. Протокол также может быть реализован в коммутаторах и точках доступа, использующих протоколы IEEE 802 [IEEE-802]. Инкапсуляция EAP в проводных средах IEEE 802 описана в стандарте [IEEE-802.1X], а инкапсуляция в беспроводных ЛВС — в стандарте [IEEE-802.11i].

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

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

1.1. Спецификация требований

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не следует (SHALL NOT), следует (SHOULD), не нужно (SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с [RFC2119].

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

Ниже определены часто используемые в этом документе термины.

Authenticator — проверяющая сторона (аутентификатор)

Инициирующая аутентификацию EAP сторона соединения. Термин authenticator используется в стандарте [IEEE-802.1X] и в данном документе его трактовка совпадает с принятой в этом стандарте.

Peer — партнер

Сторона соединения, отвечающая на запрос аутентификации. В стандарте [IEEE-802.1X] для обозначения этой стороны соединения используется термин Supplicant.

Supplicant — проверяемая сторона

Сторона соединения, отвечающая на запрос аутентификации. Трактовка этого термина в данном документе совпадает с трактовкой в стандарте [IEEE-802.1X]. Кроме того, в этом документе для обозначения отвечающей на запрос аутентификации стороны используется термин peer (партнер).

Backend authentication server — внутренний сервер аутентификации

Внутренний сервер аутентификации представляет собой объект, обеспечивающий услуги аутентификации для проверяющей стороны. При использовании этого сервера он обычно выполняет методы EAP для проверяющей стороны. Такая же терминология применяется в стандарте [IEEE-802.1X].

AAA

Проерка подлинности (Authentication), полномочий (Authorization) и учет (Accounting). Протоколы AAA для работы с EAP включают RADIUS [RFC3579] и Diameter [DIAM-EAP]. В этом документе термины «сервер AAA» и «внутренний сервер аутентификации» используются, как синонимы.

Displayable Message — отображаемое сообщение

Понятная человеку строка символов. Кодирование сообщений должно следовать формату преобразований UTF-8 [RFC2279].

EAP server — сервер EAP

Объект, завершающий использование метода аутентификации EAP с проверяемой стороной. При использовании внутреннего сервера аутентификации сервер EAP является частью проверяющей стороны. При работе проверяющей стороны в проходном (pass-through) режиме сервер EAP размещается на внутреннем сервере аутентификации.

Silently Discard — отбрасывание без уведомления

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

Successful Authentication — успешная аутентификация

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

Message Integrity Check (MIC) — проверка целостности сообщения

Функция хэширования (с ключом), используемая для аутентификации и защиты целостности данных. Обычно используется термин MAC3, но в спецификациях IEEE 802 и в данном документе применяется акроним MIC во избежание путаницы с контролем доступа к среде — Medium Access Control.

Cryptographic Separation — криптографическое разделение

Два ключа (x и y) считаются «криптографически разделенными», если наличие всех сообщений, переданных с использованием протокола, не позволяет определить x по y или y по x без «взлома» некоторых криптографических докущений. В частности, это определение допускает наличие у злоумышленника информации о всех nonce, переданных открытым текстом, а также всех предсказуемых значених счетчиков, используемых протоколом. Криптографический взлом будет обычно требовать обращения необратимой (one-way) функции или предсказания значения криптографического генератора псевдослучайных чисел без знания секрета. Иными словами, если ключи разделены криптографически, не существует способа сокращения расчета x из y или y из x и противник должен выполнить расчет, эквивалентный по объему полному поиску значения секретного ключа.

Master Session Key (MSK) — основной ключ сеанса

Ключевой материал, создаваемый сервером и проверяемой стороной EAP, который экспортируется методом EAP. MSK имеет размер не менее 64 октетов. В существующих реализациях сервер AAA, действующий в качестве сервера EAP, доставляет MSK проверяющей стороне.

Extended Master Session Key (EMSK) — расширенный основной ключ сеанса

Дополнительный ключевой материал, создаваемый клиентом и сервером EAP, который экспортируется методом EAP. Размер EMSK составляет не менее 64 октетов. EMSK не используется совместно с проверяющей стороной или третьими сторонами. EMSK зарезервирован на будущее и в настоящее время не используется.

Result indications — индикация результата

Метод обеспечивает индикацию результата, если после передачи и получения последнего сообщения:

  1. проверяемая сторона понимает была ли она аутентифицирована сервером и был ли сервер аутентифицирован ею;

  2. сервер понимает аутентифицировал ли он другую сторону и был ли аутентифицирован ею.

В случаях, когда успешной аутентификации достаточно для предоставления доступа, стороны будут также знать о желании другой стороны предоставить доступ. Это бывает не всегда и доступ проверяемой стороны может быть отвергнут по причине отсутствия нужных полномочий (например, ограничение сессии) или по иным причинам. Поскольку обмен EAP осуществляется между проверяемой стороной и сервером, на решение о предоставлении доступа могут влиять и друге узлы (например, AAA-прокси). Более подробное обсуждение этого вопроса содержится в параграфе 7.16.

1.3. Применимость

Протокол EAP был разработан для аутентификации в системах доступа, где недоступен уровень IP. Использование EAP для иных целей (например, для передачи больших объемов данных) не рекомендуется.

Поскольку EAP не требует связности IP, этот протокол лишь обеспечивает гарантированный транспорт для протоколов аутентификации и не более того.

EAP является пошаговым протоколом и в каждый момент в сети находится только один пакет. В результате протокол EAP не обеспечивает эффективной передачи больших объемов данных, в отличие от транспортных протоколов типа TCP [RFC793] или SCTP [RFC2960].

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

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

Хотя методы аутентификации типа EAP-TLS [RFC2716] обеспечивают поддержку фрагментации и сборки, определенные в этом документе методы EAP не поддерживают этого. В результате при превышении пакетом EAP размера MTU для канала, эти методы сталкиваются с проблемами.

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

При поддержке аутентификации на основе сертификатов число дополнительных периодов кругового обхода может многократно возрасти по причине фрагментации цепочек сертификатов. В общем случае фрагментированный пакет EAP будет требовать для передачи столько периодов кругового обхода, сколько было создано фрагментов. Например, цепочка сертификатов размером 14960 октетов будет требовать 10 периодов кругового обхода при передаче 1496-октетных EAP MTU.

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

2. Расширяемый протокол аутентификации (EAP)

Аутентификационный обмен EAP осуществляется в описанном ниже порядке.

  1. Проверяющая сторона передает пакет запроса (Request) на аутентификацию партнера. Пакет имеет поле Type для указания запрашиваемой информации. Примерами типов запроса могут служить Identity, MD5-challenge, и т. П. Тип MD5-Challenge близко соответствует протоколу аутентификации CHAP [RFC1994]. Обычно, проверяющая сторона будет передавать начальный запрос Identity, однако этот запрос не является обязательным и может быть пропущен. Например, такой запрос может не потребоваться, когда аутентификация определяется портом, к которому подключен партнер (выделенная линия, выделенное устройство или коммутируемая линия), или аутентификация выполняется иным путем (по отождествления вызывающей станции или MAC-адресу, в поле Name отклика MD5-Challenge и т. П.).

  2. Проверяемая сторона передает пакет отклика (Response) в ответ на пригодный запрос. Как и пакет запроса, отклик имеет поле Type с аналогичным назначением и применением.

  3. Проверяющая сторона передает дополнительный пакет Request, а партнер отвечает на него пакетом Response. Последовательность запросов и откликов повторяется, пока это требуется. Протокол EAP работает в «пошаговом» режиме, поэтому новый запрос не может быть передан до получения пригодного отклика. Проверяющая сторона отвечает за повторную передачу запросов, как описано в параграфе 4.1. После заданного числа повторов передачи проверяющей стороне следует завершить EAP-транзакцию. Проверяющей стороне недопустимо передавать пакет Success или Failure при повторе передачи или отсутствии отклика от партнера.

  4. Транзакция продолжается, пока не станет ясно, что проверяющая сторона не может аутентифицировать партнера (неприемлемые отклики на один или множество запросов) и в результате она должна передать пакет EAP Failure (код 4). Транзакция может также продолжаться, пока проверяющая сторона не решит, что она успешно завершила аутентификацию. В этом случае аутентификатор должен передать пакет EAP Success (код 3).

Преимущества

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

  • Серверы доступа NAS4 (например, коммутатор с портом доступа) не обязаны понимать каждый метод доступа и могут действовать как проходные агенты для внутреннего сервера аутентификации. Поддержка проходного режима является необязательной. Проверяющая сторона может аутентифицировать локальных партнеров и в то же время работать в проходном режиме для нелокальных партнеров и непонятных методов аутентификации.

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

Недостатки

  • При использовании с PPP протокол EAP требует добавления нового типа аутентификации в PPP LCP5, что ведет к необходимости обновления реализаций протокола PPP. Это также является отклонением от предыдущей модели аутентификации в PPP с согласованием конкретного механизма аутентификации в процессе LCP. Аналогично, реализациям коммутаторов и точек доступа требуется поддержка [IEEE-802.1X] для использования EAP.

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

2.1. Поддержка последовательности методов

Транзакция EAP может использовать последовательность методов. Типичным примером является запрос Identity, за которым следует один метод аутентификации EAP (например, MD5-Challenge). Однако проверяющая сторона и ее партнер должны использовать только один метод аутентификации (тип 4 или выше) в транзакции EAP, после чего проверяющая сторона должна передать пакет Success или Failure.

После того, как партнер передал пакет Response того же типа, который был указан в изначальном запросе, проверяющей стороне недопустимо передавать запросы других типов (за исключением Notification-Request) до завершения финального цикла данного метода и недопустимо передавать запрос любого типа для дополнительного метода после завершения работы исходного метода аутентификации. Партнер, получивший такой запрос, должен трактовать его как непригодный и отбрасывать без уведомления. В результате повторные запросы Identity не поддерживаются.

Проверяемой стороне недопустимо передавать пакет Nak (обычный или расширенный) в ответ на запрос после того, как был передан изначальный отклик, отличный от Nak. Поскольку атакующий может предавать обманные пакеты EAP Request, проверяющей стороне при получении неожиданного пакета Nak следует отбрасывать его, делая запись в журнал событий.

Множество методов аутентификации в одной транзакции EAP не поддерживается по причине уязвимости для MITM6-атак (см. Параграф 7.4) и несовместимости с существующими реализациями.

Когда используется один метод аутентификации EAP, но внутри него применяются другие методы («туннелирование» методов), запрет на использование множества методов аутентификации не применим. Такие «туннелированные» методы выглядят с точки зрения EAP, как один метод. Совместимость с ранними версиями может быть обеспечена за счет того, что партнер, не понимающий «туннелированный» метод, может ответить на начальный запрос EAP пакетом Nak (обычным или расширенным). Для предотвращения уязвимостей «туннелированные» методы должны поддерживать защиту от MITM-атак.

2.2. Модель мультиплексирования EAP

Концептуально реализация EAP состоит из перечисленных ниже компонент.

  1. Нижележащий уровень отвечает за передачу кадров EAP между проверяющей стороной и ее партнером. EAP работает на основе множества протоколов, включая PPP, проводные ЛВС IEEE 802 [IEEE-802.1X], беспроводные ЛВС IEEE 802.11 [IEEE-802.11], UDP (L2TP [RFC2661] и IKEv2 [IKEv2]) и TCP [PIC]. Поведение протоколов нижележащего уровня рассматривается в разделе 3.

  2. Уровень EAP получает и передает пакеты EAP через нижележащий уровень, обеспечивает детектирование дубликатов и повторную передачу, а также доставляет и принимает сообщения EAP между уровнями проверяющей и проверяемой сторон EAP.

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

  4. Уровень методов EAP реализует алгоритмы аутентификации, принимает и передает сообщения EAP через уровни проверяющей и проверяемой сторон EAP. Поскольку сам протокол не обеспечивает поддержки фрагментации, эта задача возлагается на методы EAP, как описано в разделе 5.

+-+-+-+-+-+-+-+-+-+-+-+-+  +-+-+-+-+-+-+-+-+-+-+-+-+
|           |           |  |           |           |
| EAP method| EAP method|  | EAP method| EAP method|
| Type = X  | Type = Y  |  | Type = X  | Type = Y  |
|       V   |           |  |       ^   |           |
+-+-+-+-!-+-+-+-+-+-+-+-+  +-+-+-+-!-+-+-+-+-+-+-+-+
|       !               |  |       !               |
|  EAP  ! Peer layer    |  |  EAP  ! Auth. layer   |
|       !               |  |       !               |
+-+-+-+-!-+-+-+-+-+-+-+-+  +-+-+-+-!-+-+-+-+-+-+-+-+
|       !               |  |       !               |
|  EAP  ! layer         |  |  EAP  ! layer         |
|       !               |  |       !               |
+-+-+-+-!-+-+-+-+-+-+-+-+  +-+-+-+-!-+-+-+-+-+-+-+-+
|       !               |  |       !               |
| Lower ! layer         |  | Lower ! layer         |
|       !               |  |       !               |
+-+-+-+-!-+-+-+-+-+-+-+-+  +-+-+-+-!-+-+-+-+-+-+-+-+
        !                          !
        !   Peer                   ! Authenticator
        +------------>-------------+

Рисунок 1. Модель мультиплексирования EAP.


Рисунок 1 иллюстрирует модель мультиплексирования EAP. Отметим, что реализация не обязана строго следовать этой модели — важно, чтобы поведение «в проводе» соответствовало модели.

В EAP поле Code используется подобно номеру протокола в IP. Предполагается, что уровень EAP демультиплексирует входящие пакеты EAP по значению поля Code. Принятые пакеты EAP с кодами 1 (Request), 3 (Success) и 4 (Failure) доставляются уровнем EAP на уровень партнера EAP, если тот реализован. Пакеты EAP с кодом 2 (Response) доставляются уровню проверяющей стороны EAP, если он реализован.

Поле Type используется подобно номеру порта в UDP или TCP. Предполагается, что уровни проверяющей стороны и ее партнера демультиплексируют входящие пакеты EAP по значению типа и доставляют их только методу EAP, соответствующему данному типу. Реализация метода EAP на хосте может регистрировать принятые пакеты от уровня проверяющей стороны или ее партнера, а также от обоих уровней в зависимости от поддерживаемой роли.

Поскольку для методов аутентификации EAP может оказаться желательным доступ к Identity, реализациям следует делать запросы и отклики Identity доступными для методов аутентификации (типа 4 и выше), а не только методу Identity. Тип Identity рассматривается в параграфе 5.1.

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

Методы Nak (тип 3) и Expanded Nak (тип 254) используются для согласования метода. Партнеры отвечают на начальный запрос EAP для неприемлемого типа откликом Nak (тип 3) или Expanded Nak (тип 254). Не следует предполагать, что содержимое откликов Nak доступно другим методам. Типы Nak рассмотрены в параграфе 5.3.

Пакеты EAP с кодами Success и Failure не включают поля Type и не доставляются методам EAP. Коды Success и Failure рассматриваются в параграфе 4.2.

С учетом сказанного здесь сообщения Success, Failure, отклики Nak Response, запросы и отклики Notification недопустимо использовать для передачи данных, адресованных методам EAP.

2.3. Проходной режим

При работе в проходном режиме7 проверяющая сторона просматривает поля Code, Identifier и Length, как описано в параграфе 4.1. Полученные от партнера пакеты EAP пересылаются уровню аутентификации внутреннего сервера аутентификации, а пакеты от этого сервера, предназначенные партнеру, пересылаются последнему.

Хост, получивший пакет EAP, может выполнить по отношению к пакету только одну из трех операций — обработать, отбросить или переслать пакет. Решение о пересылке обычно принимается по результатам проверки полей Code, Identifier и Length. Работающая в проходном режиме реализация должна быть способна пересылать пакеты, полученные от партнера с кодом 2 (Response), внутреннему серверу аутентификации. Она также должна быть способна принимать пакеты EAP от внутреннего сервера и пересылать партнеру пакеты EAP с кодами 1 (Request), 3 (Success) и 4 (Failure).

Если проверяющая сторона не поддерживает локально один или несколько методов аутентификации, способных проверять подлинность партнера, поля заголовка уровня методов EAP (Type, Type-Data) не проверяются в процессе принятия решения о пересылке. Когда проверяющая сторона поддерживает локальные методы аутентификации, она может проверять поле Type, чтобы определить необходимость обработки или пересыли пакета. Соответствующие этой спецификации реализации проходного режима должны по умолчанию пересылать пакеты EAP любого типа.

     Peer         Pass-through Authenticator   Authentication
                                                   Server
+-+-+-+-+-+-+                                   +-+-+-+-+-+-+
|           |                                   |           |
|EAP method |                                   |EAP method |
|     V     |                                   |     ^     |
+-+-+-!-+-+-+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+   +-+-+-!-+-+-+
|     !     |   |EAP  |  EAP  |             |   |     !     |
|     !     |   |Peer |  Auth.| EAP Auth.   |   |     !     |
|EAP  ! peer|   |     | +-----------+       |   |EAP  !Auth.|
|     !     |   |     | !     |     !       |   |     !     |
+-+-+-!-+-+-+   +-+-+-+-!-+-+-+-+-+-!-+-+-+-+   +-+-+-!-+-+-+
|     !     |   |       !     |     !       |   |     !     |
|EAP  !layer|   |   EAP !layer| EAP !layer  |   |EAP  !layer|
|     !     |   |       !     |     !       |   |     !     |
+-+-+-!-+-+-+   +-+-+-+-!-+-+-+-+-+-!-+-+-+-+   +-+-+-!-+-+-+
|     !     |   |       !     |     !       |   |     !     |
|Lower!layer|   |  Lower!layer| AAA ! /IP   |   | AAA ! /IP |
|     !     |   |       !     |     !       |   |     !     |
+-+-+-!-+-+-+   +-+-+-+-!-+-+-+-+-+-!-+-+-+-+   +-+-+-!-+-+-+
      !                 !           !                 !
      !                 !           !                 !
      +-------->--------+           +--------->-------+

Рисунок 2. Проверяющая сторона в проходном режиме.


Пакеты EAP с кодами 1 (Request), 3 (Success) и 4 (Failure) демультиплексируются уровнем EAP и доставляются уровню партнера. Поэтому если хост не реализует уровень партнера EAP, эти пакеты отбрасываются без уведомления. Аналогично пакеты EAP с кодом 2 (Response) демультиплексируются уровнем EAP и доставляются уровню проверяющей стороны. Если хост не реализует уровень проверяющей стороны EAP, пакеты отбрасываются без уведомления. Поведение проверяемого узла в проходном режиме не рассматривается в спецификации и не поддерживается протоколами AAA типа RADIUS [RFC3579] и Diameter [DIAM-EAP].

Рисунок 2 иллюстрирует модель пересылки.

Для сессий, где проверяющая сторона работает в прозрачном режиме, результат аутентификации должен определяться только на основе индикации Accept/Reject, переданной внутренним сервером аутентификации. Недопустимо определять результат по содержимому пакета EAP, переданного с индикацией Accept/Reject, или отсутствию такой индикации в инкапсулированном пакете EAP.

2.4. Взаимная аутентификация

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

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

Например, EAP-TLS [RFC2716] представляет собой протокол «клиент-сервер», в котором для клиента и сервера обычно используются разные профили сертификатов. Это предполагает для хоста, поддерживающего взаимную аутентификацию с использованием EAP-TLS, необходимость реализовать уровни проверяющей и проверяемой стороны EAP, поддерживать роли обеих сторон в реализации EAP-TLS и обеспечивать подходящие сертификаты для каждой роли.

Протоколы AAA типа RADIUS/EAP [RFC3579] и Diameter EAP [DIAM-EAP] поддерживают только работу в режиме проходной проверяющей стороны. Как было отмечено в параграфе 2.6.2 [RFC3579], сервер RADIUS отвечает на Access-Request, инкапсулированный в пакет EAP-Request, Success или Failure откликом Access-Reject. Следовательно, он не поддерживает работы в режиме проходного партнера.

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

  1. Поддержка двухстороннего создания ключей на нижележащем уровне. Нижележащие уровни типа IEEE 802.11 могут обеспечивать лишь одностороннюю генерацию и доставку временных сеансовых ключей. Например, согласование ключа группы, определенное в [IEEE-802.11i], является односторонним, поскольку в режиме инфраструктуры IEEE 802.11 только точки доступа (AP9) передают групповой и широковещательный трафик. В специальном10 режиме IEEE 802.11, где любой из партнеров может передавать групповой/широковещательный трафик, требуется два односторонних обмена ключами групп. Вследствие присущих архитектуре ограничений это также ведет к необходимости использования индивидуальной адресации при создании ключей и обмена EAP в каждом направлении.

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

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

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

3. Поведение нижележащего уровня

3.1. Требования к нижележащему уровню

Ниже перечислены допущения EAP о нижележащем уровне.

  1. Транспорт без гарантии доставки. В EAP проверяющая сторона продолжает передавать запросы, пока на них не получено откликов, так что EAP не полагается на гарантию доставки на нижележащем уровне. Поскольку EAP определяет свое поведение для повторов передачи, возможно (хотя и не желательно) повторение передачи на уровне EAP и на нижележащем уровне при обеспечении тем гарантий доставки.

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

  1. Детектирование ошибок. Хотя EAP не предполагает гарантированной доставки на нижележащем уровне, протокол опирается на детектирование ошибок этого уровня (например, CRC, Checksum, MIC и т. П.). Методы EAP могут не включать MIC или рассчитывать контрольную сумму не для всех полей пакета EAP (таких, как Code, Identifier, Length или Type). В результате без детектирования ошибок на нижележащем уровне незамеченные ошибки могут попадать в поля заголовков уровня EAP или уровня методов EAP, приводя к отказам при аутентификации.

    Например, метод EAP TLS [RFC2716] рассчитывает значение MIC только для поля Type-Data и трактует несовпадение MIC, как критическую ошибку. Без детектирования ошибок на нижележащем уровне этот метод и аналогичные ему методы не смогут работать надежно.

  2. Защита. EAP не требует от нижележащего уровня поддержки услуг защиты типа конфиденциальности пакетов, аутентификации, целостности и защиты от повторного использования пакетов. Однако при доступности таких услуг для динамического получения ключевого материала могут использоваться методы EAP, поддерживающие Key Derivation (см. Параграф 7.2.1). Это позволяет связать аутентификацию EAP с последующими данными и обеспечить защиту от изменения данных, повторного использования пакетов или использования ложных пакетов (spoofing). Более подробное рассмотрение приведено в параграфе 7.1.

  3. Минимальное значение MTU. EAP может работать с нижележащими уровнями, которые обеспечивают размер EAP MTU не менее 1020 октетов.

    EAP не поддерживает определение MTU для пути, а фрагментация и сборка не поддерживаются ни EAP, ни определенными в этой спецификации методами Identity (1), Notification (2), Nak Response (3), MD5-Challenge (4), One Time Password (5), Generic Token Card (6) и расширенным Nak (254).

    Обычно партнер EAP получает информацию о EAP MTU от нижележащего уровня и устанавливат подходящее значение для размера кадров EAP. Когда проверяющая сторона работает в проходном режиме, у сервера аутентификации нет прямого пути определения EAP MTU и поэтому он полагается на получение информации от проверяющей стороны (например, с помощью атрибута Framed-MTU, описанного в параграфе 2.4 [RFC3579]). Тогда как методы типа EAP-TLS [RFC2716] поддерживают фрагментацию и сборку, методы EAP, изначально разработанные для использования с протоколом PPP, где гарантируется поддержка MTU размером 1500 октетов для кадров управления (см. Параграф 6.1 [RFC1661]), могут не поддерживать функций фрагментации и сборки.

    Методы EAP могут предполагать по умолчанию минимальное значение EAP MTU в 1020 октетов. Методам EAP следует включать поддержку фрагментации и сборки, если размер их элементов данных превышает указанное минимальное значение EAP MTU.

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

  4. Возможность дублирования пакетов. Нижележащий уровень с гарантированной доставкой будет обеспечивать уровню EAP поток пакетов, не содержащий дубликатов. Отсутствие дубликатов на нижележащем уровне желательно, но не требуется. Поле Identifier позволяет проверяющей стороне и ее партнеру обнаруживать дубликаты пакетов.

  5. Гарантии порядка доставки. EAP не требует монотонного роста значения поля Identifier и для корректной работы ему нужно сохранение порядка доставки на нижележащем уровне. Изначально протокол EAP разрабатывался для использования с протоколом PPP, в спецификации которого [RFC1661] (раздел 1) сказано:

    «Протокол PPP предназначен для простых каналов, передающих пакеты между двумя партнерами. Эти каналы обеспечивают полнодуплексную двухстороннюю передачу и предполагается, что порядок доставки пакетов сохраняется.»

    Нижележащий транспорт для EAP должен сохранять порядок доставки между отправителем и получателем для заданного уровня приоритета (гарантии сохранения порядка в [IEEE-802]).

    Нарушение порядка доставки обычно будет приводить к отказу аутентификации EAP и необходимости повторного запуска процедур аутентификации. В среде, где нарушение порядка является обычным делом, столь же обычными будут и отказы при аутентификации EAP. Рекомендуется использовать EAP только с нижележащими уровнями, обеспечивающими сохранение порядка доставки. Использование EAP с транспортом raw IP или UDP не рекомендуется. Инкапсуляция EAP в RADIUS [RFC3579] удовлетворяет требованиям по сохранению порядка, поскольку протокол RADIUS гарантирует такое сохранение.

3.2. Использование EAP с протоколом PPP

При организации связи через канал PPP каждая из сторон соединения сначала передает пакеты LCP для настройки канала передачи данных в фазе Link Establishment. После того как канал будет организован, PPP может использовать необязательную фазу аутентификации (Authentication) перед переходом в фазу Network-Layer Protocol.

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

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

При реализации с PPP протокол EAP не выбирает конкретный механизм аутентификации в фазе PPP Link Control, а оставляет этот выбор для фазы Authentication. Это позволяет проверяющей стороне запросить больше информации перед определением конкретного механизма аутентификации. Кроме того, это позволяет использовать «внутренний» сервер, который реально поддерживает различные механизмы, тогда как проверяющая сторона PPP просто передает через себя аутентификационный обмен. Фазы организации канала и аутентификации PPP, а также опция Authentication Protocol Configuration определены в спецификации протокола PPP [RFC1661].

3.2.1. Формат опции настройки протокола аутентификации для PPP

Формат опции PPP Authentication Protocol Configuration для согласования EAP показан на рисунке. Поля опции передаются слева направо.

В поле Information кадра PPP Data Link Layer, где поле протокола имеет шестнадцатеричное значение C227 (PPP EAP), инкапсулируется один пакет EAP.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |    Length     |     Authentication Protocol   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Type

3

Length

4

Authentication Protocol

Шестнадцатеричное значение C227 показывает протокол EAP.

3.3. Использование EAP с протоколами IEEE 802

Инкапсуляция EAP в кадры IEEE 802 определена в стандарте [IEEE-802.1X]. Инкапсуляция IEEE 802 для EAP не включает PPP и протокол IEEE 802.1X не поддерживает согласований для канального или сетевого уровня. В результате этого при использовании IEEE 802.1X нет возможности согласования не входящих в EAP механизмов аутентификации типа PAP или CHAP [RFC1994].

3.4. Индикация нижележащего уровня

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

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

Обсуждение некоторых вопросов надежности и безопасности индикации нижележащего уровня в PPP, проводных сетях IEEE 802 и беспроводных сетях IEEE 802.11 приведено в параграфе 7.12. Канальный уровень.

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

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

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

4. Формат пакетов EAP

В этом разделе описан формат пакетов EAP. Поля передаются слева направо.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Code      |  Identifier   |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Data ...
+-+-+-+-+


Code

Однооктетное поле Code показывает тип пакета EAP и может принимать значения:

1 Request — запрос;

2 Response — отклик;

3 Success — успех;

4 Failure — отказ.

Поскольку в EAP определены только коды 1-4, пакеты EAP с другими значениями кода должны отбрасываться обеими сторонами без уведомелния.

Identifier

Однооктетное поле Identifier используется для обеспечения соответствия между запросами и откликами.

Length

Двухоктетное поле Length показывает размер (в октетах) пакета EAP с учетом полей Code, Identifier, Length и Data. Октеты, выходящие за пределы указанного размера, следует трактовать, как заполнение канального уровня — на приеме эти данные должны игнорироваться. Сообщения, в которых значение поля Length превышает размер полученного пакета, должны отбрасываться без уведомления.

Data

Поле Data не является обязательным, а его формат зависит от типа пакета (значения поля Code).

4.1. Запросы и отклики

Описание

Пакеты Request (запрос, код 1) передаются партнеру проверяющей стороной. Каждый пакет Request имеет поле Type, которое показывает тип запрашиваемой информации. Дополнительные пакеты Request должны передаваться, пока не будет получен пригодный отклик, не завершится отсчет числа попыток или нижележащий уровень не сообщит об отказе.

Повторные запросы должны передаваться с тем же значением поля Identifier, чтобы их можно было отличить от новых запросов. Содержимое поля данных зависит от типа запроса. Партнер должен передавать пакет Response в ответ на корректный запрос. Отклики должны передаваться только в ответ на корректные пакеты Request и никогда не должны повторяться по таймеру.

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

Ниже приводится описание полей пакетов Request и Response. Поля передаются слева направо.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Code      |  Identifier   |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |  Type-Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-


Code

1 для Request;

2 для Response.

Identifier

Поле Identifier занимает 1 октет. Значения идентификатора в передаваемых повторно (по атйм-ауту в ожидании отклика) пакетах запросов должны совпадать со значением поля в исходном пакете Request. В новых (не повторных) запросах значение поля Identifier должно меняться.

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

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

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

Примечание для разработчиков. Проверяющая сторона несет ответственность за повторную передачу пакетов Request. Если сообщение Request получено из некого источника (например, от внутреннего сервера аутентификации), проверяющая сторона должна сохранить копию такого запроса на случай возможного повтора передачи. Партнер отвечает за детектирование и обслуживание дубликатов запросов до начала какой-либо их обработки, включая передачу третьей стороне. Проверяющая сторона отвечает также за отбрасывание сообщений Response с непригодным значением поля Identifier до какой-либо их обработки, включая пересылку внутреннему аутентификационному серверу для проверки. Поскольку проверяющая сторона может повторить передачу до получения от партнера отклика, она может получить множество пакетов Response с одним идентификатором. Пока проверяющей стороной не будет принят новый запрос, значение поля Identifier не изменяется, поэтому проверяющая сторона пересылает отклики внутреннему серверу аутентификации по одному.

Length

Двухоктетное поле Length показывает размер пакета EAP с учетом полей Code, Identifier, Length, Type и Type-Data. Октеты, выходящие за пределы указанного размера, следует трактовать, как заполнение канального уровня — на приеме эти данные должны игнорироваться. Сообщения, в которых значение поля Length превышает размер полученного пакета, должны отбрасываться без уведомления.

Type

Поле Type занимает 1 октет и показывает тип запроса или отклика. В каждом пакете EAP Request или Response должно быть указано одно значение Type. Исходные спецификации типов описаны в разделе 5 данного документа.

Поле Type в отклике должно соответствовать полю типа в запросе или обычному/расширенному Nak (см. Параграф 5.3), показывающему неприемлемость типа запроса для партнера. Партнеру недопустимо слать пакет Nak (обычный или расширенный) в ответ на запрос после того, как был передан исходный отклик без Nak. Сервер EAP, получивший пакет Response, который не удовлетворяет перечисленным здесь требованиям, должен отбросить его.

Type-Data

Поле Type-Data зависит от типа запроса и отклика.

4.2. Пакеты Success и Failure

Пакет Success передается проверяющей стороной партнеру после завершения метода EAP (тип 4 или выше) для индикации успешно завершенной аутентификации партнера. Проверяющая сторона должна передать пакет EAP с Code = 3 (Success). Если партнера аутентифицировать не удается (непригодные отклики на один или множество запросов), после неудачного завершения метода EAP реализация должна передать пакет EAP с кодом 4 (Failure). Проверяющая сторона может ввести множество запросов до передачи отклика Failure, чтобы предотвратить влияние ошибок (опечаток) пользователя. В пакеты Success и Failure недопустимо включать дополнительные данные.

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

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

Как было отмечено в параграфе 2.1, для транзакции EAP разрешается использовать только один метод аутентификации EAP. Методы EAP могут использовать разные способы индикации. После того, как проверяющая сторона передаст партнеру индикацию отказа, она должна передать вслед пакет Failure, независимо от отклика партнера. После того, как проверяющая сторона передаст партнеру индикацию успеха и получит индикацию успеха от того, она должна передать вслед пакет Success.

Проверяемая сторона после неудачного завершения метода аутентификации (индикация отказа от проверяющей стороны или нежелание партнера продолжать транзакцию — возможно после передачи индикации негативного результата) должна прервать транзакцию и передать индикацию отказа на нижележащий уровень. Проверяемая сторона должна отбрасывать без уведомления пакеты Success и может отбрасывать без уведомления пакеты Failure. В результате потеря пакета Failure не будет приводить к тайм-ауту.

Проверяемая сторона после обмена индикаторами успешного завершения с обеих сторон, должна без уведомления отбрасывать пакеты Failure. Если пакет EAP Success не был получен, проверяемая сторона может предположить потерю пакета.

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

Если партнер сталкивается с отказом при попытке аутентифицировать проверяющую сторону, последняя должна передать пакет Failure. Недопустимо в таких случаях предоставлять доступ, передавая пакет Success. Однако проверяющая сторона может опускать аутентификацию партнера в случаях предоставления ограниченного доступа (например, гостевого). В таком случае проверяющая сторона должна передать пакет Success.

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

Ниже показан формат пакетов Success и Failure. Поля передаются слева направо.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Code      |  Identifier   |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Code

3 для Success;

4 для Failure.

Identifier

Поле Identifier занимает 1 октет и служит для сопоставления с откликами. Значение поля Identifier должно соответствовать значению аутентификатора в пакете Response, на который передается ответ.

Length

4

4.3. Поведение при повторе передачи

Поскольку процесс аутентификации часто включает ввод данных пользователем, следует принимать меры предосторожности при выборе стратегии повторной передачи и тайм-аутов. По умолчанию, когда EAP работает с нижележащим уровнем без гарантированной доставки, значение таймера повторной передачи EAP следует оценивать динамически. Предлагается повторять передачу не более 3 — 5 раз.

При работе с нижележащим уровнем, обеспечивающим гарантии доставки (например, EAP на основе ISAKMP/TCP, как описано в [PIC]), для таймера повторной передачи на проверяющей стороне следует устанавливать бесконечное значение, чтобы на уровне EAP повторной передачи не происходило. Партнер может поддерживать свое значение тайм-аута, чтобы предотвратить бесконечное ожидание запроса.

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

Рекомендации по выбору значения тайм-аута для проверяющей стороны может дать внутренний сервер аутентификации (например, через атрибут RADIUS Session-Timeout).

Для динамической оценки таймера повтора передачи в EAP рекомендуется применять алгоритмы оценки SRTT, RTTVAR и RTO, описанные в [RFC2988], включая алгоритм Karn с описанными ниже возможными изменениями.

  1. Для предотвращения одновременной синхронизации множества распределенных систем таймеры повтора передачи задаются с флуктуациями на основе значения RTO с добавлением случайной величины из диапазона -RTOmin/2 — RTOmin/2. Могут использоваться и другие способы задания флуктуаций, однако значения должны быть псевдослучайными. Обсуждение генерации псевдослучайных значений приведено в работе [RFC1750].

  2. При работе EAP по одному каналу (а не через Internet) можно использовать меньшие значения RTOinitial, RTOmin и RTOmax. Рекомендуется задавать значения RTOinitial=1 сек., RTOmin=200 мсек. И RTOmax=20 сек.

  3. При работе EAP по одному каналу (а не через Internet) можно сделать оценки для проверяющей стороны, а не для сессии. Это позволяет при оценке более полно использовать информацию о поведении нижележащего уровня.

  4. 1

    Identity

    2

    Notification

    3

    Nak (только в Response)

    4

    MD5-Challenge

    5

    Однократный пароль (OTP)

    6

    Базовая карточка доступа (GTC)

    254

    Расширенные типы

    255

    Для экспериментов

    Реализация EAP может сбросить значения SRTT и RTTVAR после многократного снижения значения таймера, поскольку очевидно, что эти значения в такой ситуации не отражают реальность. После сброса SRTT и RTTVAR их следует инициализировать следующим значением RTT12, полученным в соответствии с уравнением 2.2 в [RFC2988].

5. Типы начальных запросов и откликов EAP

В этом параграфе определен начальный набор типов EAP, используемых в обменах Request/Response. В будущих документах могут быть определены новые типы. Поле Type занимает 1 октет и определяет структуру пакета с запросом или откликом EAP. Первые три типа имеют специальное значение.

Оставшиеся типы определяют аутентификационные обмены. Типы Nak (3) и Expanded Nak (254) применимы только для откликов и их недопустимо использовать в запросах.

Все реализации EAP должны поддерживать типы 1-4, определенные в данном документе, следует поддерживать также тип 254. Реализации могут поддерживать другие типы, определенные здесь или в будущих RFC.

Методы EAP могут поддерживать аутентификацию на основе общего секрета. Если таким секретом является вводимая пользователем комбинация символов, реализация может поддерживать кодировки символов, отличные от ASCII. В таких случаях обработку ввода следует выполнять с использованием подходящего профиля stringprep [RFC3454] и переводить введенные пользователем данные в строку октетов с использованием кодировки UTF-8 [RFC2279]. Предварительная версия возможного профиля stringprep описана в [SASLPREP].

5.1. Identity

Описание

Тип Identity используется для запроса отождествления партнера. В общем случае проверяющая сторона может ввести запрос этого типа в качестве стартового. В тех случаях, когда предполагается взаимодействие с пользователем на стороне партнера, может включаться дополнительное отображаемое сообщение. В ответ на запрос типа 1 (Identity) следует передавать отклик типа 1 (Identity).

Некоторые реализации EAP включают различные опции в запрос типа Identity после NUL-символа. По умолчанию реализации EAP не следует предполагать, что запрос или отклик типа Identity может быть больше 1020 октетов.

Рекомендуется использовать отклики Identity прежде всего в целях маршрутизации и выбора используемого метода EAP. Методам EAP следует включать механизм получения отождествления, чтобы не возникало необходимости опираться на отклик Identity. Запросы и отклики Identity передаются в открытом виде, поэтому атакующий может увидеть отождествление и даже изменить его. Для предотвращения такой угрозы предпочтительно включать в аутентификационный обмен метод EAP, который поддерживает аутентификацию на уровне пакетов, а также обеспечивает защиту целостности, конфиденциальность и предотвращение повторного использования пакетов. Отклик Identity может оказаться непригодным для такого метода — он может быть усеченным или затуманенным для сохранения тайны, а также «декорированным» для маршрутизации. Когда партнер настроен на восприятие только методов аутентификации, поддерживающих защищенные обмен отождествлениями, этот партнер может предоставлять сокращенный отклик Identity (например без своего имени в NAI [RFC2486]). Дополнительное рассмотрение этого вопроса содержится в параграфе 7.3.

Механизм аутентификации

Нет

Согласование шифронабора

Нет

Взаимная аутентификация

Нет

Защита целостности

Нет

Защита от повторов

Нет

Конфиденциальность

Нет

Создание ключей

Нет

Стойкость ключей

Устойчивость к атакам по словарю

Быстрый повтор соединения

Нет

Криптографическая привязка

Независимость сессий

Фрагментация

Нет

Связывание каналов

Нет

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

Type

1

Type-Data

Это поле может содержать отображаемое сообщение, представленное символами ISO 10646 с кодировкой UTF-8 [RFC2279]. Если Request содержит null-символ, выводиться будет только часть этого поля до символа null. Если значение Identity неизвестно, в отклик Identity следует включать поле нулевого размера. В откликах Identity недопустимо завершать поле null-символом. В любом случае размер поля Type-Data определяется из значения поля Length в пакете Request/Response.

Параметры защиты (параграф 7.2) показаны в таблице.

5.2. Notification

Описание

Необязательный тип Notification используется для передачи отображаемых сообщений партнеру от проверяющей стороны. Проверяющая сторона может передать партнеру Notification Request в любой момент, когда нет незавершенных запросов, до окончания метода аутентификации EAP. Партнер должен ответить на запрос Notification пакетом Notification Response, если спецификация метода аутентификации EAP не запрещает использовать сообщения Notification. В любом случае недопустимо передавать пакет Nak Response в ответ на запрос Notification. Отметим, что по умолчанию максимальный размер Notification Request составляет 1020 октетов, что оставляет не более 1015 октетов для выводимого пользователю сообщения.

Метод EAP может запрещать передачу сообщений Notification при работе этого метода. В таких случаях партнер должен отбрасывать запросы Notification без уведомления с момента, когда на начальный запрос для данного типа был передан отклик того же типа.

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

Type

2

Type-Data

Поле Type-Data в запросе содержит непустое отображаемое сообщение из символов ISO 10646 в кодировке UTF-8 [RFC2279]. Размер сообщения определяется значением поля Length в пакете Request. Недопустимо завершать сообщение null-символом. В ответ на запрос с полем типа, имеющим значение 2 (Notification) должен передаваться отклик. Поле Type-Data в отклике является пустым. Отклик следует передавать незамедлительно (независимо от отображения или записи сообщения в системный журнал).

Параметры защиты (см. Параграф 7.2) показаны в таблице.

Механизм аутентификации

Нет

Согласование шифронабора

Нет

Взаимная аутентификация

Нет

Защита целостности

Нет

Защита от повторов

Нет

Конфиденциальность

Нет

Создание ключей

Нет

Стойкость ключей

Устойчивость к атакам по словарю

Быстрый повтор соединения

Нет

Криптографическая привязка

Независимость сессий

Фрагментация

Нет

Связывание каналов

Нет


5.3. Nak

5.3.1. Обычный тип Nak

Описание

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

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

Code

2 для Response.

Identifier

Поле Identifier занимает 1 октет и служит для сопоставления откликов с запросами. Значение поля Identifier в обычном отклике Nak должно соответствовать значению Identifier в пакете Request, на который передается отклик.

Length

>=6

Type

3

Type-Data

Когда проверяемая сторона получает запрос для неподходящего типа аутентификации (4-253, 255) или запрос для типа 254 при отсутствии поддержки расширенных типов, должен передаваться пакет Nak Response (тип 3). Поле Type-Data отклика Nak (тип 3) должно содержать один или множество октетов (по одному октету на тип), показывающих желаемые типы аутентификации, или 0 для индикации отсутствия предложений. Партнер, поддерживающий расширенные типы при получении запроса для неподходящего типа аутентификации (4-253, 255), может включить в отклик Nak (тип 3) значение 254 для индикации желания использовать расширенный тип. Если проверяющая сторона может принять это предложение, она будет отвечать на него сообщением Expanded Type Request (тип 254).

Механизм аутентификации

Нет

Согласование шифронабора

Нет

Взаимная аутентификация

Нет

Защита целостности

Нет

Защита от повторов

Нет

Конфиденциальность

Нет

Создание ключей

Нет

Стойкость ключей

Устойчивость к атакам по словарю

Быстрый повтор соединения

Нет

Криптографическая привязка

Независимость сессий

Фрагментация

Нет

Связывание каналов

Нет


Параметры защиты (параграф 7.2) показаны в таблице.

5.3.2. Expanded Nak

Описание

Расширенный тип Nak применим только к откликам. Этот тип должен передаваться только в откликах на запросы типа 254 (Expanded Type), когда тип аутентификации не приемлем. Expanded Nak Type использует формат Expanded Type, а отклик содержит один или множество типов аутентификации, желательных для проверяемой стороны (все в формате Expanded Type). Нулевое значение служит для индикации отсутствия предложений. Общий формат расширенного типа описан в параграфе 5.7. Поскольку тип Expanded Nak пригоден только для откликов и имеет очень ограниченную функциональность, его недопустимо использовать для индикации ошибок общего плана типа передачи сообщений об ошибках или согласования специфических параметров конкретного метода EAP.

Code

2 для Response.

Identifier

Поле Identifier занимает 1 октет и служит для сопоставления откликов с запросами. Значение поля Identifier в отклике Expanded Nak должно соответствовать значению Identifier в пакете Request, на который передается отклик.

Length

>=20

Type

254

Vendor-Id

0 (IETF)

Vendor-Type

3 (Nak)

Vendor-Data

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     2         |  Identifier   |           Length=28           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Type=254    |                0 (IETF)                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                3 (Nak)                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Type=254    |                0 (IETF)                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                5 (OTP)                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Type=254    |                20 (MIT)                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                6                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Тип Expanded Nak передается только в том случае, когда запрос содержит расширенный тип (254), как определено в параграфе 5.7. Поле Vendor-Data отклика13 Nak должно содержать один или множество типов аутентификации (4 и выше) в расширенном формате (8 октетов на тип) или 0 (также в расширенном формате) для индикации отсутствия предложений. Желаемые типы аутентификации могут включать комбинацию типов Vendor-Specific и IETF. Например, расширенный отклик Nak, показывающий предпочтение для OTP (тип 5) и MIT (Vendor-Id=20) расширенного типа 6 будет иметь вид, приведенный на рисунке.

Отклик Expanded Nak, показывающий отсутствие желаемых типов, приведен на рисунке.

Механизм аутентификации

Нет

Согласование шифронабора

Нет

Взаимная аутентификация

Нет

Защита целостности

Нет

Защита от повторов

Нет

Конфиденциальность

Нет

Создание ключей

Нет

Стойкость ключей

Устойчивость к атакам по словарю

Быстрый повтор соединения

Нет

Криптографическая привязка

Независимость сессий

Фрагментация

Нет

Связывание каналов

Нет

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     2         |  Identifier   |           Length=20           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Type=254    |                0 (IETF)                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                3 (Nak)                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Type=254    |                0 (IETF)                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                0 (No alternative)             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Параметры защиты (см. Параграф 7.2) показаны в таблице.

5.4. MD5-Challenge

Описание

Тип MD5-Challenge аналогичен протоколу PPP CHAP [RFC1994] (с MD5 в качестве алгоритма). Запрос содержит сообщение с «вызовом» партнеру. В ответ на запрос должен передаваться отклик, который может иметь тип 4 (MD5-Challenge), 3 (Nak) или 254 (Expanded Nak). Отклик Nak показывает желаемые партнером типы аутентификации. Реализации проверяемой стороны и сервера должны поддерживать механизм MD5-Challenge. Проверяющая сторона, которая работает только в проходном режиме, должна разрешать обмен информацией с внутренним сервером аутентификации, который поддерживает MD5-Challenge, хотя сама реализация проверяющей стороны EAP не обязана поддерживать MD5-Challenge. Однако, если проверяющая сторона может быть настроена на аутентификацию партнеров локально (например, не работать в проходном режиме), требование поддержки механизма MD5-Challenge становится актуальным.

Отметим, что использование поля Identifier для типа MD5-Challenge отличается от описанного в [RFC1994]. EAP позволяет повторять передачу запросов MD5-Challenge, тогда как в [RFC1994] сказано, что оба поля Identifier и Challenge должны изменяться при каждой передаче Challenge (эквивалент пакета с запросом MD5-Challenge в CHAP14).

Примечание. [RFC1994] трактует разделяемый секрет, как строку октетов и не задает способы ввода этой строки в систему (или управляется пользователем). Реализация EAP MD5-Challenge может поддерживать ввод парольных фраз, содержащих отличные от ASCII символы. Инструкции по обработке ввода и кодированию в октеты приведены в разделе 5.

Type

4

Type-Data

Содержимое поля Type-Data кратко описано ниже. Информацию по использованию этих полей можно найти в спецификации протокола PPP CHAP [RFC1994].

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Value-Size   |  Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Name ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Параметры защиты (параграф 7.2) показаны в таблице.

Механизм аутентификации

Пароль или общий ключ

Согласование шифронабора

Нет

Взаимная аутентификация

Нет

Защита целостности

Нет

Защита от повторов

Нет

Конфиденциальность

Нет

Создание ключей

Нет

Стойкость ключей

Устойчивость к атакам по словарю

Нет

Быстрый повтор соединения

Нет

Криптографическая привязка

Независимость сессий

Фрагментация

Нет

Связывание каналов

Нет


5.5. Одноразовый пароль (OTP)

Описание

Система одноразовых паролей (OTP15) определена в документах «A One-Time Password System16» [RFC2289] и «OTP Extended Responses17» [RFC2243]. Запрос содержит вызов OTP в формате, описанном в [RFC2289]. В ответ на запрос должен передаваться отклик, типа 5 (OTP), 3 (Nak) или 254 (Expanded Nak). Отклик Nak показывает желаемые партнером типы аутентификации. Метод EAP OTP предназначен для использования только в системе с одноразовыми паролями и его недопустимо применять для передачи паролей в открытом виде.

Механизм аутентификации

Одноразовый пароль

Согласование шифронабора

Нет

Взаимная аутентификация

Нет

Защита целостности

Нет

Защита от повторов

Да

Конфиденциальность

Нет

Создание ключей

Нет

Стойкость ключей

Устойчивость к атакам по словарю

Нет

Быстрый повтор соединения

Нет

Криптографическая привязка

Независимость сессий

Фрагментация

Нет

Связывание каналов

Нет

Type

5

Type-Data

Поле Type-Data содержит в запросе «вызов» OTP, как отображаемое сообщение. В откликах это поле используется для 6 слов из словаря OTP [RFC2289]. Недопустимо завершать сообщения null-символом. Размер поля определяется из значения поля Length в пакете Request/Reply.

Примечание. [RFC2289] не задает способ ввода пароля пользователем и преобразования пароля в октеты. Реализации EAP OTP могут поддерживать пароли с отличными от ASCII символами. Инструкции по обработке ввода и преобразования в октеты содержатся в разделе 5.

Параметры защиты (параграф 7.2) показаны в таблице.

5.6. Маркерные карты (GTC)

Описание

Тип GTC18 определен для использования с различными реализациями маркерных карточек, которые требуют пользовательского ввода. Запрос содержит отображаемое сообщение, а отклик — информацию Token Card, требуемую для аутентификации. Обычно эта информация считывается пользователем с устройства для работы с картами и вводится в форме текста ASCII. В ответ на запрос должен передаваться отклик. В отклике должен указываться тип 6 (GTC), 3 (Nak) или 254 (Expanded Nak). Отклик Nak показывает желаемые партнером типы аутентификации. Метод EAP GTC предназначен для использования с картами, поддерживающими аутентификацию «запрос — отклик», и его недопустимо использовать с открытыми паролями в отсутствие защищенного туннеля с аутентификацией сервера.

Type

6

Type-Data

Поле Type-Data в запросах содержит непустое отображаемое сообщение (размер определяется значением поля Length в пакете Request). Недопустимо завершать сообщение null-символом. В ответ на запрос должен передаваться отклик типа 6 (GTC). Отклик содержит данные из карты, нужные для аутентификации.

Механизм аутентификации

Аппаратный маркер

Согласование шифронабора

Нет

Взаимная аутентификация

Нет

Защита целостности

Нет

Защита от повторов

Нет

Конфиденциальность

Нет

Создание ключей

Нет

Стойкость ключей

Устойчивость к атакам по словарю

Нет

Быстрый повтор соединения

Нет

Криптографическая привязка

Независимость сессий

Фрагментация

Нет

Связывание каналов

Нет

Реализации EAP GTC могут поддерживать отклики с символами, отличными от ASCII. Инструкции по обработке ввода и преобразованию его в октеты приведены в разделе 5.

Параметры защиты (параграф 7.2) показаны в таблице.

5.7. Расширенные типы

Описание

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

Expanded Type служит также для расширения глобального пространства типов методов за пределы исходных 255 значений. Значение Vendor-Id = 0 отображает исходные 255 возможных типов в пространство из 232-1 возможных типов (тип 0 используется только в отклике Nak для индикации отсутствия предложений).

Поддерживающие атрибут Expanded реализации должны трактовать типы EAP со значением меньше 256 одинаково, независимо от формы их представления — один октет или 32-битовое значение Vendor-Type в Expanded Type с Vendor-Id = 0. Партнеры, не поддерживающие Expanded Type, должны передать отклик Nak, как описано в параграфе 5.3.1 и согласовать более подходящий метод аутентификации.

Формат и описание полей Expanded Type показаны ниже. Поля передаются слева направо.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |               Vendor-Id                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Vendor-Type                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              Vendor data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Type

254 для Expanded Type

Vendor-Id

Трехоктетное значение Vendor-Id представляет код SMI Network Management Private Enterprise Code для производителя с использованием сетевого порядка байтов (как выделено IANA). Нулевое значение Vendor-Id зарезервировано для использования IETF с целью расширения глобального пространства типов EAP.

Vendor-Type

Четырехоктетное поле Vendor-Type представляет фирменный тип метода от указанного производителя.

Если Vendor-Id = 0, поле Vendor-Type является расширением и надмножеством существующего пространства типов EAP. Первые 256 типов зарезервированы для совместимости с однооктетными типами EAP, которые уже определены или могут быть определены в будущем. Таким образом, типы EAP от 0 до 255 семантически одинаковы при их указании в однооктетных полях EAP Type или в полях Vendor-Type при Vendor-Id = 0. Из этого правила есть одно исключение — обычные и расширенные пакеты Nak относятся к одному типу, но должны трактоваться по-разному, поскольку имеют различные форматы.

Vendor-Data

Поле Vendor-Data определяется производителем. При Vendor-Id = 0 поле Vendor-Data будет использоваться для доставки содержимого методов EAP с определенными IETF типами.

5.8. Experimental

Описание

Тип Experimental не имеет фиксированного формата и содержимого. Этот тип предназначен для экспериментов с новыми типами EAP и тестов. При использовании этого типа нет никаких гарантий интероперабельности, как отмечено в [RFC3692].

Type

255

Type-Data

Не определено.

6. Взаимодействие с IANA

В этом разделе приведено руководство для агентства IANA19 в части регистрации значений, связанных с протоколом EAP, в соответствии с BCP 26 [RFC2434].

В EAP имеется два пространства имен, требующих регистрации — коды пакетов и типы методов.

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

Термины «пространство имен» (name space), «выделенное значение» (assigned value), «регистрация» (registration) трактуются здесь в соответствии с BCP 26.

При выделении значений используются определенные в BCP 26 правила и процедуры: «для частного применения» (Private Use), «обслуживание в порядке очереди» (First Come First Served), «экспертиза» (Expert Review), «требуется спецификация» (Specification Required), «с согласия IETF» (IETF Consensus), «стандартизация» (Standards Action).

Для регистрационных запросов, где следует консультироваться с указанными экспертами, ответственность за выбор таких экспертов ложится на руководителя направления IESG. Смысл заключается в том, что любое выделение значений должно сопровождаться публикацией RFC. Но для выделения значений до публикации RFC может использоваться заключение указанного эксперта, который может одобрить выделение значений, когда станет ясно, что RFC будет публиковаться. Эксперт будет направлять запрос в рассылку рабочей группы EAP (или ее преемника, заданного руководителем направления) для обзора и комментариев, включая Internet-Draft. До истечения 30 дней эксперту следует принять или отвергнуть регистрационный запрос и опубликовать свое решение в рассылке EAP WG20 или ее преемника, а также проинформировать IANA. Отказ должен быть мотивирован и по возможности в него следует включать конкретные предложения по изменению запроса для того, чтобы он был удовлетворен.

6.1. Коды пакетов

Коды пакетов (Packet Codes) имеют диапазон от 1 до 255, из которого уже выделены значения 1 — 4. Поскольку коды оказывают существенное влияние на интероперабельность, для выделения нового кода требуется стандартизация (Standards Action). Начинать выделение новых кодов следует со значения 5.

6.2. Типы методов

Исходное пространство типов методов EAP имеет диапазон от 1 до 255 и является наиболее дефицитным ресурсом EAP, поэтому выделять новые значения следует осторожно. Типы методов 1 — 45 уже распределены, при этом значение 20 доступно для переопределения. Типы 20 и 46 — 191 могут быть выделены с одобрения указанного эксперта при наличии спецификации (Specification Required).

Выделение блоков типов (более одного типа для данной цели) требует согласия IETF (IETF Consensus). Значения типов методов EAP от 192 до 253 зарезервированы и для их распределения требуется стандартизация.

Тип 254 выделен для Expanded Type. Если Vendor-Id = 0, значение Expanded Type служит для специфических целей данной реализации EAP, когда интероперабельность не имеет значения. При использовании с Vendor-Id = 0 тип метода 254 может также служить для поддержки расширенного пространства типов методов. Значения типов в диапазоне от 256 до 4294967295 могут распределяться после того, как будут распределены все типы 1 — 191, с одобрения указанного эксперта при наличии спецификации.

Тип 255 выделен для экспериментов типа тестирования новых методов EAP перед выделением постоянного типа.

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

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

Предполагается, что базовая модель угроз и параметры защиты будут применяться для определения требований к методам EAP при использовании в конкретных средах. Пример такого анализа требований имеется в стандарте [IEEE-802.11i-req]. Раздел описания параметров защиты является обязательным в спецификации метода EAP и требования для некоторых методов могут просто совпадать.

7.1. Модель угроз

Протокол EAP был разработан для использования с PPP [RFC1661], а позднее его адаптировали для проводных сетей IEEE 802 [IEEE-802] в стандарте [IEEE-802.1X]. Впоследствии EAP было предложено использовать в беспроводных ЛВС и Internet. Во всех случаях применения протокола атакующий может получить доступ к каналу, по которому передаются пакеты EAP. Например, атаки на телефонную инфраструктуру описаны в работе [DECEPTION].

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

  1. Попытка раскрытия идентификационных данных пользователей путем перлюстрации трафика.

  2. Попытка изменения или подмены пакетов EAP.

  3. Атаки на отказ служб за счет подмены индикации нижележащего уровня или пакетов Success/Failure, повторного использования пакетов EAP или генерации пакетов с перекрывающимися идентификаторами.

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

  5. Попытка убедить проверяемый узел присоединиться к сети без доверия путем организации MITM-атаки.

  6. Попытка нарушения процесса согласования EAP для принуждения к выбору более слабого метода аутентификации.

  7. Попытка восстановления ключей при использовании недостаточно стойких способов создания ключей в методах EAP.

  8. Попытка воспользоваться слабостью шифронабора после завершения транзакции EAP.

  9. Попытка снизить уровень стойкости при согласовании шифронабора, используемого для аутентификации EAP.

  10. Предоставление некорректной информации партнеру и/или серверу EAP от имени «проверяющей стороны» за счет использования сторонних механизмов (например, через AAA или протокол нижележащего уровня). К таким атакам относятся также «подмена» проверяющей стороны или предоставление противоречивой информации партнеру или серверу EAP.

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

7.2. Параметры защиты

Для четкой формулировки защиты, обеспечиваемой методом EAP, спецификации методов EAP должны включать раздел Security Claims (Параметры защиты), содержащий перечисленные ниже описания.

  1. Механизм — указание технологии аутентификации, сертификатов, общих ключей, паролей, карт и т. п.

  2. Параметры защиты — параметры защиты, обеспечиваемые методом, с использованием терминов, определенных в параграфе 7.2.1 — взаимная аутентификация, защита целостности, предотвращение повторного использования, конфиденциальность, создание ключей, стойкость к атакам по словарю, быстрое повторное соединение, криптографическое связывание. В разделе «Параметры защиты» спецификации метода EAP следует включать описания заявленных параметров. Это может обеспечиваться путем включения обоснования в приложение или указания ссылки на такие обоснования.

  3. Стойкость ключей — если метод создает ключи, должна быть оценена их стойкость. Эта оценка позволяет потенциальным пользователям метода определить достаточна ли стойкость ключей для планируемых приложений.

    Эффективную стойкость ключа следует оценивать числом битов следующим образом — если эффективная стойкость ключа составляет N битов, лучшие современные методы восстановления ключей (с вероятностью, которая не пренебрежимо мала) требуют в среднем усилий, сравнимых с выполнением 2N-1 операций типового блочного шифрования21. Данные о стойкости ключа следует сопроводить кратким обоснованием полученного числа битов. В это объяснение следует включать параметры, требуемые для достижения заявленной стойкости ключа, основанные на текущем понимании алгоритмов.

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

  4. Описание иерархии ключей. Методы EAP, создающие ключи, должны включать ссылку на спецификацию иерархии ключей или описывать создание ключей MSK и EMSK.

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

7.2.1. Терминология, связанная с параметрами защиты для методов EAP

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

Protected ciphersuite negotiation — защищенное согласование шифронабора

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

Mutual authentication — взаимная аутентификация

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

Integrity protection — защита целостности

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

Replay protection — защита от повторного использования пакетов

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

Confidentiality — конфиденциальность

Шифрование сообщений EAP, включая запросы и отклики EAP, индикацию успешного завершения или отказа. При поддержке такой защиты должна также обеспечиваться защита целостности (см. Параграф 7.3).

Key derivation — создание ключей из чего-либо

Способность метода EAP создавать экспортируемый ключевой материал типа MSK и EMSK. MSK служит лишь для создания ключей, но не для защиты транзакции EAP и последующих данных. EMSK пока служат резервом.

Key strength — стойкость ключа

Если эффективная стойкость ключа составляет N битов, лучшие современные методы восстановления ключей (с вероятностью, которая не пренебрежимо мала) требуют в среднем усилий, сравнимых с выполнением 2N-1 операций типового блочного шифрования.

Dictionary attack resistance — устойчивость к атакам по словарю

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

Fast reconnect — быстрое повторное соединение

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

Cryptographic binding — криптографическая связка

Демонстрация серверу EAP того, что один объект действует в качестве проверяемой стороны EAP для всех методов, выполняемых в рамках туннельного метода. Связка может также означать, что сервер EAP демонстрирует партнеру один объект, который действует в качестве сервера EAP для всех методов, выполняемых в рамках туннельного метода. При корректном выполнении связка снижает уязвимость к MITM-атакам.

Session independence — независимость сеансов

Демонстрация того, что пассивные (типа захвата данных транзакции EAP) или активные (включая компрометацию MSK или EMSK) не приводят к компрометации последующих или предшествующих ключей MSK или EMSK.

Fragmentation — фрагментация

Способность метода EAP поддерживать фрагментацию и сборку пакетов. Как отмечено в параграфе 3.1, методам EAP следует поддерживать фрагментацию и сборку, если размер пакетов EAP превышает минимальное значение MTU (1020 октетов).

Channel binding — связывание каналов

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

Примечание. Приведенный список не является исчерпывающим. Могут включаться и другие свойства типа дополнительной защиты от атак на службы.

7.3. Защита Identity

Обмен Identity является в транзакции EAP необязательным. Поэтому можно опустить этот обмен целиком или использовать предлагаемый применяемым методом обмен идентификационными данными после организации защищенного канала.

Однако при поддержке роуминга в соответствии с [RFC2607] может потребоваться нахождение подходящего внутреннего сервера аутентификации до выполнения аутентификационной транзакции. Связанная с областью часть NAI22 [RFC2486] обычно включается в отклик EAP Identity, чтобы разрешить маршрутизацию аутентификационного обмена на подходящий внутренний сервер. Поэтому, хотя связанная с партнером часть NAI может быть опущена в отклике EAP Identity при наличии прокси или трансляторов, связанная с областью часть может требоваться.

Возможно, что идентификационные данные в отклике Identity будут отличаться от данных, аутентифицированных методом EAP. Такое отличие может быть преднамеренным для сокрытия идентификационной информации. Методу EAP при решении вопроса о предоставлении доступа следует использовать аутентифицированное отождествление.

7.4. MITM-атаки

При туннелировании EAP с использованием протокола, опускающего аутентификацию партнера, возникает потенциальная уязвимость к MITM-атакам, более подробно описанная в работах [BINDING] и [MITM].

Как было отмечено в параграфе 2.1, EAP не позволяет использовать нетуннелированые последовательности методов аутентификации. Когда последовательность методов EAP разрешена, партнер может не иметь уверенности в том, что один объект действует в качестве проверяющей стороны во всех методах EAP данной последовательности. Например, проверяющая сторона может завершить метод EAP, а потом передать следующий метод (в последовательности) другому объекту без согласия партнера и даже не информируя его. Аналогично, проверяющая сторона может не иметь подтверждения того, что во всех методах EAP данной последовательности проверяется один партнер.

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

Для ослабления таких атак возможен ряд мер, перечисленных ниже.

  1. Требование взаимной аутентификации в механизмах туннелирования EAP.

  2. Требование криптографического связывания между протоколом туннелирования EAP и туннелируемыми методами EAP. При поддержке криптографической связки требуется также механизм для защиты от атак на снижение уровня, позволяющих обойти такую связку. Дополнительную информацию о криптографических связках можно найти в работе [BINDING].

  3. Ограничение методов EAP, которые разрешено использовать без защиты, на основе политики проверяющей стороны и ее партнера.

  4. Отказ от использования туннелей при доступности одного стойкого метода.

7.5. Атаки с изменением пакетов

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

Поскольку Поле Identifier занимает 1 октет, значение этого поля легко угадать, что дает атакующему возможность инжектировать или повторно использовать пакеты EAP. Атакующий может также изменять заголовки EAP (поля Code, Identifier, Length, Type) в пакетах, где нет защиты заголовков. Это может вести к отбрасыванию пакетов или некорректной их интерпретации.

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

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

Для методов, обеспечивающих защиту целостности пакетов EAP, рекомендуется включать в расчет контрольной суммы все поля заголовка EAP (Code, Identifier, Length, Type, Type-Data).

Поскольку сообщения EAP типов Identity, Notification и Nak не включают своего MIC, может оказаться желательным покрытие MIC метода EAP содержащейся в сообщении информации, а также заголовка каждого сообщения EAP.

Для обеспечения защиты EAP можно также инкапсулировать в защищенный канал, созданный протоколами типа ISAKMP [RFC2408], как делается в [IKEv2] или в TLS [RFC2246]. Однако, как было отмечено в параграфе 7.4, туннелирование EAP может приводить к уязвимости для MITM-атак.

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

В EAP-TLS [RFC2716] негативный результат проверки MIC считается критической ошибкой в соответствии со спецификацией TLS [RFC2246]. Однако возможна разработка методов EAP, которые будут поддерживать MIC на уровне пакетов и реагировать на негативный результат проверки целостности простым отбрасыванием пакетов.

В этом документе при описании обработки сообщений EAP предполагается, что проверка MIC на уровне пакетов (если она используется) выполняется до передачи каких-либо откликов и смены состояния хоста, принявшего пакет.

7.6. Атаки по словарю

Парольные механизмы аутентификации типа EAP-MD5, MS-CHAPv1 [RFC2433] и Kerberos V [RFC1510] известны уязвимостями к атакам по словарю. Уязвимости MS-CHAPv1 описаны в [PPTPv1], MS-CHAPv2 — в [PPTPv2], Kerberos — в [KRBATTACK], [KRBLIM] и [KERB4WEAK].

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

Если известно, что используемый алгоритм аутентификации уязвим к атакам по словарю, транзакцию можно туннелировать в защищенный канал. Однако туннелирование EAP может приводить к уязвимости для MITM-атак (см. параграф 7.4) и поэтому предпочтительно использовать методы, устойчивые к атакам по словарю.

7.7. Подключение к сети без доверия

В методах EAP, использующих одностороннюю аутентификацию (например, EAP-MD5), партнер не проверяет другую сторону, что делает этого партнера уязвимым для атак с использованием подставных проверяющих узлов. Для устранения этой уязвимости служат методы, поддерживающие взаимную аутентификацию (см. определение в параграфе 7.2.1).

В EAP не требуется выполнения аутентификации в полнодуплексном режиме или использования одного протокола для обоих направлений. Использование своего протокола для каждого направления является совершенно нормальной ситуацией и будет зависеть от согласованного протокола. Однако в общем случае выполнение одной взаимной аутентификации более предпочтительно, нежели проведение двух односторонних проверок (для каждого направления). Это связано с тем, что процедуры односторонней аутентификации, которые не связаны криптографически так, что указывается их принадлежность к одной сессии, могут быть объектом MITM-атак, как описано в параграфе 7.4.

7.8. Атаки на согласование

В таких атаках злоумышленник пытается принудить проверяющую сторону и ее партнера к согласованию менее защищенного метода EAP. Протокол EAP не обеспечивает защиты для откликов Nak, хотя методы могут включать отклики Nak в свои проверки MIC.

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

7.9. Поведение при отказе в аутентификации

Взаимодействие EAP с нижележащим уровнем типа PPP и IEEE 802 сильно зависит от реализации.

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

В EAP не предусматривается попыток повтора аутентификации. Однако в PPP машина состояний LCP может заново согласовать протокол аутентификации в любой момент, что позволяет повторить попытку. Аналогично, в IEEE 802.1X проверяемая (Supplicant) или проверяющая (Authenticator) сторона могут повторить аутентификацию в любой момент. Рекомендуется не сбрасывать значения счетчиков неудачных попыток, пока аутентификация не завершится успешно или в результате отказа канала.

7.10. Создание ключей

Для сервера EAP и его партнера возможна взаимная аутентификация и создание ключей. Для обеспечения ключевого материала, который будет впоследствии использоваться согласованным шифром, поддерживающий создание ключей метод EAP должен экспортировать основной ключ сеанса (MSK) размером не менее 64 октетов и расширенный основной ключ сеанса (EMSK) размером не менее 64 октетов. Методы EAP, создающие ключи, должны поддерживать взаимную аутентификацию между сервером EAP и его партнером.

Ключи MSK и EMSK недопустимо использовать напрямую для защиты данных их размер достаточен для создания ключа AAA, который впоследствии служит для создания временных сеансовых ключей (TSK23), используемых с выбранным шифронабором. Каждый шифр отвечает за спецификацию создания ключей TSK по ключу AAA.

Ключ AAA создается из материала, экспортируемого методом EAP (MSK и EMSK). Процедура создания ключа выполняется на сервере AAA. Во многих протоколах, использующих EAP, ключи AAA и MSK эквивалентны, но возможны и более сложные механизмы (см. [KEYFRAME]).

Методам EAP следует поддерживать «свежесть» ключей MSK и EMSK даже в тех случаях, когда одна из сторон может не иметь высококачественного генератора случайных чисел. Рекомендуется каждой стороне передавать значение nonce размером не менее 128 битов, используемое для создания ключей MSK и EMSK.

Методы EAP экспортируют ключи MSK и EMSK, но не TSK, чтобы обеспечить независимость методов EAP от шифра и среды. Ключевой материал, экспортируемый методами EAP, должен быть независимым от шифронабора, согласованного для защиты данных.

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

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

Стойкость ключей TSK, используемых для защиты данных, в конечном итоге зависит от стойкости ключей, созданных методом EAP. Если этот метод не может обеспечивать достаточно стойкий ключевой материал, ключи TSK могут взломаны методом тупого перебора (Brute force). Для поддержки систем, требующих стойких ключей, поддерживающим генерацию ключей методам EAP следует обеспечивать возможность генерации ключей MSK и EMSK с эффективной стойкостью не менее 128 битов.

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

Не перекрывающиеся подстроки MSK должны быть криптографически отделены одна от другой, как определено в параграфе 7.2.1. Т. е. знание одной подстроки не должно помогать в раскрытии других подстрок без нарушения фундаментальных криптографических допущений. Это требование обусловлено тем, что некоторые шифры создают ключи TSK простым разбиением ключа AAA на части подходящего размера. Подобно этому, не перекрывающиеся подстроки EMSK должны быть криптографически отделены одна от другой, как и подстроки MSK.

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

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

В данной спецификации не содержится подробного руководства по созданию методами EAP ключей MSK и EMSK, генерации AAA-Key из MSK и/или EMSK и генерации TSK из AAA-Key.

Разработка и проверка алгоритмов генерации ключей сложна, поэтому методам EAP следует пользоваться хорошо известными и проверенными механизмами создания ключей (например, указанными в спецификациях IKE [RFC2409] или TLS [RFC2246]) вместо разработки новых. Методам EAP также следует использовать хорошо известные и проверенные механизмы генерации ключей MSK и EMSK. Дополнительные сведения о генерации ключей EAP приведены в работе [KEYFRAME].

7.11. Слабость шифров

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

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

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

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

7.12. Канальный уровень

Существует ряд вопросов надежности и безопасности индикации нижележащего уровня в PPP, ЛВС IEEE 802 и беспроводных ЛВС IEEE 802.11:

  1. PPP. Индикация канального уровня типа LCP-Terminate (индикация отказа в канале) и NCP (индикация успешного создания канала) не аутентифицируются и не защищаются в плане целостности. Следовательно, атакующий с доступом к каналу может использовать обманную индикацию.

  2. IEEE 802. Кадры IEEE 802.1X EAPOL-Start и EAPOL-Logoff не аутентифицируются и целостность их не защищена. Следовательно, атакующий с доступом к каналу может использовать обманную индикацию.

  3. IEEE 802.11. В IEEE 802.11 индикация канального уровня включает кадры Disassociate и Deauthenticate (индикация отказов в канале), а также первое сообщение 4-этапного согласования (успешная организация канала). Для этих сообщений не обеспечивается аутентификация и защита целостности и хотя они не являются пересылаемыми, атакующий может использовать обманную индикацию, находясь в зоне доступа.

В IEEE 802.11 кадры данных IEEE 802.1X могут передаваться как кадры класса 3 с индивидуальной адресацией, и поэтому такие кадры можно пересылать. Это ведет к тому, что кадры EAPOL-Start и EAPOL-Logoff могут быть подменены аутентифицированным атакующим при включенном режиме предварительной аутентификации, несмотря на использование аутентификации и защиты целостности.

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

7.13. Разделение проверяющей стороны и внутреннего сервера

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

Однако при размещении проверяющей стороны и сервера аутентификации в разных местах возникает ряд вопросов.

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

  2. Как обсуждалось в [RFC3579], проверяющая сторона зависит от протокола AAA в плане получения информации о результатах аутентификационной транзакции и не видит инкапсулированный пакет EAP (если он присутствует) для определения результата. На практике это означает, что протокол AAA, используемый для обмена между проверяющей стороной и сервером, должен поддерживать аутентификацию, защиту целостности и предотвращение повторного использования на уровне отдельных пакетов.

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

  4. Ключ AAA созданный на основе MSK и/или EMSK, согласованный между сервером аутентификации и партнером, может быть передан проверяющей стороне. Поэтому требуется механизм передачи ключа AAA от сервера проверяющей стороне, которой этот ключ нужен. Спецификация механизмов создания, транспортировки и «заворачивания25» ключа AAA-key выходит за пределы этого документа. Информация о создании AAA-Key имеется в документе [KEYFRAME].

7.14. Открытые пароли

Данная спецификация не определяет механизм аутентификации открытых (не зашифрованных) паролей. Это сделано преднамеренно. Использование открытых паролей позволит атакующим перехватывать их при наличии доступа к каналу, через который передаются пакеты EAP.

Поскольку инкапсулирующие EAP протоколы (типа RADIUS [RFC3579]) могут не обеспечивать конфиденциальности, пакеты EAP могут быть перехвачены при передаче информации через Internet.

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

7.15. Связывание каналов

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

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

В параграфе 4.3.7 документа [RFC3579] описано, как может быть обнаружена проверяющая сторона EAP в проходном режиме, которая, действуя в качестве клиента AAA, пытается представить себя другим проверяющим узлом (например, путем передач некорректных атрибутов NAS-Identifier [RFC2865], NAS-IP-Address [RFC2865] или NAS-IPv6-Address [RFC3162] через протокол AAA). Однако проходная проверяющая сторона, действуя в качестве клиента AAA, может может предоставлять корректную информацию серверу AAA и в то же время передавать искаженные данные партнеру EAP по протоколу нижележащего уровня.

Например, скомпрометированная проверяющая сторона может использовать значения Called-Station-Id или NAS-Identifier другой проверяющей стороны при обмене с партнером EAP по протоколу нижележащего уровня или проходной проверяющий узел, действующий в качестве клиента AAA, может передать некорректное значение Calling-Station-Id партнера [RFC2865][RFC3580] серверу AAA по протоколу AAA.

Для устранения этой уязвимости методы EAP могут поддерживать защищенный обмен параметрами канала типа идентификаторов конечных точек, включая (но не ограничиваясь) Called-Station-Id [RFC2865][RFC3580], Calling-Station-Id [RFC2865][RFC3580], NAS-Identifier [RFC2865], NAS-IP-Address [RFC2865], NAS-IPv6-Address [RFC3162].

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

7.16. Защищенная индикация результатов

В EAP пакеты Success и Failure не подтверждаются и целостность их не защищена. Индикация результатов повышает устойчивость к потере пакетов Success и Failure при работе EAP с протоколами нижележащего уровня, которые не поддерживают повторной передачи или синхронизации состояния аутентификации. В средах типа IEEE 802.11, которые поддерживают повтор передачи и синхронизацию состояния аутентификации за счет 4-этапного согласования, определенного в стандарте [IEEE-802.11i], дополнительная устойчивость обычно не дает заметного преимущества.

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

Защищенная индикация результатов не требуется для защиты от поддельных проверяющих узлов. В методах с взаимной аутентификацией требование аутентификации сервера со стороны партнера до восприятия последним пакета Success не позволяет атакующему прикинуться проверяющей стороной.

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

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

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

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

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

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

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

Защищенная индикация результатов устраняет некоторые уязвимости к атакам на службы с использованием обманных пакетов Success и Failure. Обычно методы EAP могут обеспечивать защищенную индикацию результатов лишь в некоторых случаях. Например, ошибка может произойти до создания ключа, поэтому такую индикацию защитить не удастся. Возможны случаи, когда индикация результатов не может поддерживаться в обоих направлениях или синхронизация возможна не во всех режимах работы.

Например, в EAP-TLS [RFC2716] при согласовании аутентификации клиента сервер аутентифицирует партнера, но не получает защищенной индикации от него в части аутентификации тем сервера. Напротив, партнер аутентифицирует сервер и знает, что сервер аутентифицировал его. При согласовании восстановления сессии партнер аутентифицирует сервер, но не получает защищенной индикации того, что сервер аутентифицировал его. В этом режиме сервер аутентифицирует партнера и знает, что тот аутентифицировал его.

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

В этом протоколе много заимствований из документа AHA (Dave Carrel), а также из протокола PPP CHAP [RFC1994]. Значимые отклики прислали Yoshihiro Ohba из Toshiba America Research, Jari Arkko из Ericsson, Sachin Seth из Microsoft, Glen Zorn из Cisco Systems, Jesse Walker из Intel, Bill Arbaugh, Nick Petroni и Bryan Payne из университета штата Мэрилэнд, Steve Bellovin из AT&T Research, Paul Funk из Funk Software, Pasi Eronen из Nokia, Joseph Salowey из Cisco, Paul Congdon из HP, а также члены рабочей группы EAP.

Использование для методов EAP раздела «Параметры защиты», как требует параграф 7.2 и задано для каждого описанного здесь метода EAP, было предложено Glen Zorn в [EAP-EVAL].

9. Литература

9.1. Нормативные документы

[RFC1661] Simpson, W., «The Point-to-Point Protocol (PPP)», STD 51, RFC 1661, July 1994.

[RFC1994] Simpson, W., «PPP Challenge Handshake Authentication Protocol (CHAP)», RFC 1994, August 1996.

[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, March 1997.

[RFC2243] Metz, C., «OTP Extended Responses», RFC 2243, November 1997.

[RFC2279] Yergeau, F., «UTF-8, a transformation format of ISO 10646», RFC 2279, January 1998.

[RFC2289] Haller, N., Metz, C., Nesser, P. and M. Straw, «A One-Time Password System», RFC 2289, February 1998.

[RFC2434] Narten, T. and H. Alvestrand, «Guidelines for Writing an IANA Considerations Section in RFCs», BCP 26, RFC 2434, October 1998.

[RFC2988] Paxson, V. and M. Allman, «Computing TCP’s Retransmission Timer», RFC 2988, November 2000.

[IEEE-802] Institute of Electrical and Electronics Engineers, «Local and Metropolitan Area Networks: Overview and Architecture», IEEE Standard 80226, 1990.

[IEEE-802.1X] Institute of Electrical and Electronics Engineers, «Local and Metropolitan Area Networks: Port-Based Network Access Control», IEEE Standard 802.1X1, September 2001.

9.2. Дополнительная литература

[RFC793] Postel, J., «Transmission Control Protocol», STD 7, RFC 793, September 1981.

[RFC1510] Kohl, J. and B. Neuman, «The Kerberos Network Authentication Service (V5)», RFC 1510, September 1993.

[RFC1750] Eastlake, D., Crocker, S. and J. Schiller, «Randomness Recommendations for Security», RFC 175027, December 1994.

[RFC2246] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and P. Kocher, «The TLS Protocol Version 1.0», RFC 2246, January 1999.

[RFC2284] Blunk, L. and J. Vollbrecht, «PPP Extensible Authentication Protocol (EAP)», RFC 2284, March 1998.

[RFC2486] Aboba, B. and M. Beadles, «The Network Access Identifier», RFC 2486, January 1999.

[RFC2408] Maughan, D., Schneider, M. and M. Schertler, «Internet Security Association and Key Management Protocol (ISAKMP)», RFC 2408, November 1998.

[RFC2409] Harkins, D. and D. Carrel, «The Internet Key Exchange (IKE)», RFC 240928, November 1998.

[RFC2433] Zorn, G. and S. Cobb, «Microsoft PPP CHAP Extensions», RFC 2433, October 1998.

[RFC2607] Aboba, B. and J. Vollbrecht, «Proxy Chaining and Policy Implementation in Roaming», RFC 2607, June 1999.

[RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G. and B. Palter, «Layer Two Tunneling Protocol «L2TP»», RFC 2661, August 1999.

[RFC2716] Aboba, B. and D. Simon, «PPP EAP TLS Authentication Protocol», RFC 2716, October 1999.

[RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, «Remote Authentication Dial In User Service (RADIUS)», RFC 2865, June 2000.

[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, «Stream Control Transmission Protocol», RFC 296029, October 2000.

[RFC3162] Aboba, B., Zorn, G. and D. Mitton, «RADIUS and IPv6», RFC 3162, August 2001.

[RFC3454] Hoffman, P. and M. Blanchet, «Preparation of Internationalized Strings («stringprep»)», RFC 3454, December 2002.

[RFC3579] Aboba, B. and P. Calhoun, «RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)», RFC 3579, September 2003.

[RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G. and J. Roese, «IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) Usage Guidelines», RFC 3580, September 2003.

[RFC3692] Narten, T., «Assigning Experimental and Testing Numbers Considered Useful», BCP 82, RFC 3692, January 2004.

[DECEPTION] Slatalla, M. and J. Quittner, «Masters of Deception», Harper-Collins, New York, 1995.

[KRBATTACK] Wu, T., «A Real-World Analysis of Kerberos Password Security», Proceedings of the 1999 ISOC Network and Distributed System Security Symposium, http://www.isoc.org/isoc/conferences/ndss/99/proceedings/papers/wu.pdf.

[KRBLIM] Bellovin, S. and M. Merrit, «Limitations of the Kerberos authentication system», Proceedings of the 1991 Winter USENIX Conference, pp. 253-267, 1991.

[KERB4WEAK] Dole, B., Lodin, S. and E. Spafford, «Misplaced trust: Kerberos 4 session keys», Proceedings of the Internet Society Network and Distributed System Security Symposium, pp. 60-70, March 1997.

[PIC] Aboba, B., Krawczyk, H. and Y. Sheffer, «PIC, A Pre-IKE Credential Provisioning Protocol», Work in Progress, October 2002.

[IKEv2] Kaufman, C., «Internet Key Exchange (IKEv2) Protocol», Work in Progress30, January 2004.

[PPTPv1] Schneier, B. and Mudge, «Cryptanalysis of Microsoft’s Point-to- Point Tunneling Protocol», Proceedings of the 5th ACM Conference on Communications and Computer Security, ACM Press, November 1998.

[IEEE-802.11] Institute of Electrical and Electronics Engineers, «Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications», IEEE Standard 802.1131, 1999.

[SILVERMAN] Silverman, Robert D., «A Cost-Based Security Analysis of Symmetric and Asymmetric Key Lengths», RSA Laboratories Bulletin 13, April 2000 (Revised November 2001), http://www.rsasecurity.com/rsalabs/bulletins/bulletin13.html.

[KEYFRAME] Aboba, B., «EAP Key Management Framework», Work in Progress32, October 2003.

[SASLPREP] Zeilenga, K., «SASLprep: Stringprep profile for user names and passwords», Work in Progress33, March 2004.

[IEEE-802.11i] Institute of Electrical and Electronics Engineers, «Unapproved Draft Supplement to Standard for Telecommunications and Information Exchange Between Systems — LAN/MAN Specific Requirements — Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications: Specification for Enhanced Security», IEEE Draft 802.11i (work in progress)34, 2003.

[DIAM-EAP] Eronen, P., Hiller, T. and G. Zorn, «Diameter Extensible Authentication Protocol (EAP) Application», Work in Progress35, February 2004.

[EAP-EVAL] Zorn, G., «Specifying Security Claims for EAP Authentication Types», Work in Progress, October 2002.

[BINDING] Puthenkulam, J., «The Compound Authentication Binding Problem», Work in Progress, October 2003.

[MITM] Asokan, N., Niemi, V. and K. Nyberg, «Man-in-the-Middle in Tunneled Authentication Protocols», IACR ePrint Archive Report 2002/163, October 2002, <http://eprint.iacr.org/2002/163>.

[IEEE-802.11i-req] Stanley, D., «EAP Method Requirements for Wireless LANs», Work in Progress36, February 2004.

[PPTPv2] Schneier, B. and Mudge, «Cryptanalysis of Microsoft’s PPTP Authentication Extensions (MS-CHAPv2)», CQRE 99, Springer-Verlag, 1999, pp. 192-20337.

Приложения A. Отличия от RFC 2284

В этом разделе перечислены основные различия между [RFC2284] и данным документом. Мелкие отличия, включая стили, грамматику, опечатки и редакторские правки не упомянуты в списке.

  • Раздел, посвященный терминологии (параграф 1.2) был расширен, определены концепции и даны более точные определения.

  • Введены и рассмотрены в документе концепции взаимной аутентификации (Mutual Authentication), создания ключей (Key Derivation) и индикации результатов (Result Indication).

  • В разделе 2 явно указано что в аутентификационном обмене EAP может происходить множество обменов пакетами Request и Response. Возможности использования этого подробно описаны в параграфе 2.1.

  • В разделе 2 явно приведены некоторые требования к проверяющей стороне в проходном режиме.

  • Добавлена модель мультиплексирования EAP (параграф 2.2) для иллюстрации типового применения EAP. Реализации не обязаны точно следовать этой модели, достаточно совместимого с ней поведения.

  • Описана работа EAP с различными протоколами нижележащего уровня в дополнение к протоколу PPP, для которого разрабатывался EAP. Добавлен раздел 3, посвященный поведению нижележащего уровня.

  • При описании взаимодействия запросов и откликов EAP (параграф 4.1) более точно описано поведение в случае получения дубликатов запроса и отбрасывание пакетов без уведомления.

  • В параграфе 4.2 разъяснено, что пакеты Success и Failure не должны содержать дополнительных данных и расширены примечания для разработчиков. Добавлен параграф с требованиями по обработке пакетов Success и Failure.

  • В разделе 5 описаны два новых типа EAP — Expanded (параграф 5.7), который используется для расширения пространства типов, и Experimental. В пространстве Expanded Type добавлен новый тип Expanded Nak (параграф 5.3.2). Приведены дополнительные разъяснения для большинства существующих типов. Добавлены описания параметров защиты для методов аутентификации.

  • В параграфах 5, 5.1 и 5.2 добавлены требования к отображаемым полям по использованию символов ISO 10646 в кодировке UTF-8.

  • В параграфе 5.1 сказано, что при наличии в поле Type-Data запроса Identity символа NUL отображается только часть сообщения до этого символа. RFC 2284 запрещает использование null-символов в поле Type-Data сообщений Identity. Это правило смягчает требования к запросам Identity и поле Type-Data в них может включать null-символы.

  • В параграфе 5.5 добавлена поддержка откликов OTP Extended [RFC2243] в EAP OTP.

  • Добавлен раздел «6. Взаимодействие с IANA» с правилами регистрации имен для EAP.

  • Раздел «7. Вопросы безопасности» был существенно расширен и включает в настоящем документе более полное описание возможных угроз и других вопросов безопасности.

  • В параграф 7.5 был добавлен текст, описывающий конкретное поведение методов EAP в плане проверки целостности. При наличии возможности желательно рассчитывать специфическое для метода значение MIC с покрытием всего пакета EAP, включая заголовок уровня EAP (поля Code, Identifier, Length) и заголовок уровня метода EAP (поля Type, Type-Data).

  • В параграфе 7.14 описаны риски, связанные с использованием открытых паролей в EAP.

  • В параграф 7.15 добавлен текст, посвященный детектированию подставных NAS.

Адреса авторов

Bernard Aboba

Microsoft Corporation

One Microsoft Way

Redmond, WA 98052

USA

Phone: +1 425 706 6605

Fax: +1 425 936 6605

EMail: bernarda@microsoft.com

Larry J. Blunk

Merit Network, Inc

4251 Plymouth Rd., Suite 2000

Ann Arbor, MI 48105-2785

USA

Phone: +1 734-647-9563

Fax: +1 734-647-3185

EMail: ljb@merit.edu

John R. Vollbrecht

Vollbrecht Consulting LLC

9682 Alice Hill Drive

Dexter, MI 48130

USA

EMail: jrv@umich.edu

James Carlson

Sun Microsystems, Inc

1 Network Drive

Burlington, MA 01803-2757

USA

Phone: +1 781 442 2084

Fax: +1 781 442 1677

EMail: james.d.carlson@sun.com

Henrik Levkowetz

ipUnplugged AB

Arenavagen 33

Stockholm S-121 28

SWEDEN

Phone: +46 708 32 16 08

EMail: henrik@levkowetz.com

Перевод на русский язык

Николай Малых

nmalykh@gmail.com

Полное заявление авторских прав

Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an «AS IS» basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Интеллектуальная собственность

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

Подтверждение

Финансирование функций RFC Editor обеспечено Internet Society.

1Extensible Authentication Protocol

2Point-to-Point Protocol

3Message Authentication Code — код аутентификации сообщения.

4Network Access Server — сервер доступа в сеть.

5Link Control Protocol — протокол управления каналом. Прим. Перев.

6Man-in-the-Middle – перехват и изменение пакетов с участием человека в точке перехвата. Прим. Перев.

7Pass-through authenticator.

8В оригинале используется термин «peer-to-peer operation». Прим. Перев.

9Access Point.

10Ad hoc.

11Authentication Protocol Configuration Option

12Round-Trip Time время кругового обхода. Прим. Перев.

13Расширенного отклика. Прим. Перев.

14Challenge Handshake Authentication Protocol.

15One-Time Password.

16Система с однократным паролем.

17Расширенные отклики OTP.

18Generic Token Card — маркерные карты базового типа.

19Internet Assigned Numbers Authority.

20Working Group – рабочая группа. Прим. Перев.

21Понятия «сравнимых усилий» и «типового блочного шифрования» сложно определить точно, однако здесь достаточно разумных предположений. Дополнительную информацию можно найти в работе [SILVERMAN].

22Network Access Identifier — аутентификатор доступа в сеть.

23Transient Session Key.

24Это ограничение будет смягчено в новых документах, определяющих использование EMSK.

25Wrapping.

26Этот стандарт доступен на сайте http://standards.ieee.org. Прим. перев.

27Документ заменен RFC 4086. Прим. перев.

28Этот документ заменен RFC 4306. Прим. перев.

29Этот документ заменен RFC 4960. Прим. перев.

30Эта работа завершена и опубликована в RFC 4306. Прим. перев.

31Этот стандарт доступен на сайте http://standards.ieee.org. Прим. перев.

32Эта работа завершена и опубликована в RFC 5247. Прим. перев.

33Эта работа завершена и опубликована в RFC 4013. Прим. перев.

34Этот стандарт завершен и доступен на сайте http://standards.ieee.org. Прим. перев.

35Эта работа завершена и опубликована в RFC 4072. Прим. перев.

36Эта работа завершена и опубликована в RFC 4017. Прим. перев.

37Эта статья доступна на сайте http://www.schneier.com/paper-pptpv2.html. Прим. перев.

 




RFC 3779 X.509 Extensions for IP Addresses and AS Identifiers

Network Working Group                                            C. Lynn
Request for Comments: 3779                                       S. Kent
Category: Standards Track                                         K. Seo
                                                        BBN Technologies
                                                               June 2004

Расширения X.509 для адресов IP и номеров AS

X.509 Extensions for IP Addresses and AS Identifiers

PDF

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

Этот документ задает проект стандартного протокола Internet для сообщества Internet и служит приглашением к дискуссии в целях развития этого протокола. Текущий статус стандартизации протокола можно узнать из документа Internet Official Protocol Standards (STD 1). Распространение документа не ограничивается.

Авторские права

Copyright (C) The Internet Society (2004).

Тезисы

Этот документ определяет два расширения для сертификатов X.509 v3. Первое расширение привязывает список адресных блоков IP или префиксов к субъекту сертификата. Второе привязывает к субъекту сертификата список идентификаторов автономных систем. Эти расширения могут служить для передачи полномочий субъекта на использование содержащихся в расширениях адресов IP и идентификаторов автономных систем.

Оглавление

Исключено в версии HTML.

1. Введение

В этом документе описаны два расширения сертификатов X.509 v3, которые подтверждают передачу прав на использование адресов IP и номеров автономных систем от IANA через региональных регистраторов (RIR1) провайдерам Internet (ISP2) и организациям-пользователям. Первое расширение связывает список адресных блоков IP, зачастую представленных адресными префиксами IP, с субъектом (держателю секретного ключа) сертификата. Второе расширение связывает список идентификаторов автономных систем (AS3) с субъектом (держателю секретного ключа) сертификата. Эмитентом сертификата является организация (например, IANA, региональный регистратор Internet или ISP), которая имеет полномочия передавать право использования (выделять) наборов адресных блоков IP и номеров AS субъектам сертификатов. Эти сертификаты обеспечивают расширяемую систему проверки прав на использование (right-to-use) для наборов адресных префиксов IP и номеров AS. Это может применяться протоколами маршрутизации (например, Secure BGP [S-BGP]) для проверки правомочности и корректности маршрутной информации или реестрами маршрутизации Internet для проверки получаемых данных.

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

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

Предполагается знакомство читателя с терминами и концепциями, описанными в документах «Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile» [RFC3280], «INTERNET PROTOCOL» [RFC791], «Internet Protocol Version 6 (IPv6) Addressing Architecture» [RFC3513], «INTERNET REGISTRY IP ALLOCATION GUIDELINES» [RFC2050] и связанных с ними документах в части политики распределения адресов региональными регистраторами Internet. Ниже приведены определения некоторых терминов.

Allocate — выделение, распределение

Передача хранения (содержания) ресурса промежуточной организации (см. [RFC2050]).

Assign — назначение, присвоение

Передача хранения (содержания) ресурса конечному владельцу (см. [RFC2050]).

Autonomous System (AS) — автономная система

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

Autonomous System number — номер автономной системы

32-битовое значение, идентифицирующее автономную систему.

Delegate — передача полномочий, делегирование

Передача хранения (т. е. права использования) блока адресов IP или идентификатора AS путем выпуска сертификата для объекта.

initial octet — начальный октет

Первый октет битовой строки (BIT STRING) в представлении DER [X.690].

IP v4 address — адрес IPv4

32-битовый идентификатор, записываемый в форме четырех десятичных чисел из диапазона 0 — 255, разделенных точками. Примером адреса IPv4 может служить 10.5.0.5.

IP v6 address — адрес IPv6

128-битовый идентификатор, записываемый в форме восьми шестнадцатеричных чисел от 0 до ffff, разделенных двоеточиями (:). Примером адреса IPv6 может служить 2001:0:200:3:0:0:0:1. Последовательность :0: может быть заменена двумя символами двоеточия (::) и запись 2001:0:200:3::1 эквивалентна приведенному выше примеру адреса (см. [RFC3513]).

Prefix — префикс

Битовая строка, содержащая некоторое число начальных битов адреса и записанная в форме адреса, за которым следует символ дробной черты (/) и число начальных битов. Примерами префиксов могут служить 10.5.0.0/16 и 2001:0:200:3:0:0:0:0/64 (или 2001:0:200:3::/64). Префиксы часто сокращают, отбрасывая нули в младших полях так, чтобы число оставшихся битов было не меньше размера префикса. 10.5/16 и 2001:0:200:3/64 являются сокращенными записями приведенных выше префиксов.

Regional Internet Registry (RIR) — региональный регистратор Internet

Любая организация, признанная IANA в качестве регионального уполномоченного по управлению адресами IP и номерами AS. На момент подготовки документа их было 5 — AfriNIC, APNIC, ARIN, LACNIC и RIPE NCC.

Right-to-use — право использования

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

subsequent octets — последующие октеты

Октеты со второго и до последнего в форме битовой строки (BIT STRING) с представлением DER [X.690].

trust anchor — доверенная привязка

Сертификат, которому доверяют при проверке пригодности пути сертификации (см. [RFC3280]).

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не нужно (SHALL NOT), следует (SHOULD), не следует (SHOULD NOT), рекомендуется (RECOMMENDED), не рекомендуется (NOT RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе должны интерпретироваться в соответствии с [RFC2119].

2. Расширение IP Address Delegation

Это расширение показывает выделение адресов IP объекту путем привязки адресов к открытому ключу объекта.

2.1. Контекст

Адресное пространство IP в настоящее время поддерживается иерархией с номинальным корнем в IANA, но реально обслуживается RIR. IANA выделяет блоки адресов RIR, а те, в свою очередь, распределяют их между провайдерами (ISP), которые могут выделять адреса IP нижестоящим провайдерам, заказчикам и т. п. RIR также могут выделять адреса организациям, являющимся конечными абонентами, т. е. не распределяют полученных адресов между другими организациями (см. [RFC2050] и соответствующие документы RIR с рекомендациями и описанием процесса выделения адресов.

Расширение IP Address Delegation предназначено для обеспечения возможности проверки корректности передачи полномочий на блоки адресов IP (т. е. полномочий на использование или последующее выделение адресных блоков IP). Соответственно, имеет смысл использовать преимущества имеющейся административной модели распределения адресного пространства IP. Как описано выше в разделе 1, это может быть реализовано путем выпуска сертификатов, сопровождающих описанное в разделе 1 выделение адресов. Примером использования информации из этого расширения может служить объект, применяющий эти данные для проверки полномочий организации в части создания сообщений BGP UPDATE, анонсирующих путь к конкретному блоку адресов IP (см., например, [RFC1771], [S-BGP]).

2.1.1. Представление адресов и префиксов IP

Имеется два семейства адресов IP — IPv4 и IPv6.

Адрес IPv4 представляет собой 32-битовое значение, которое записывается в форме 4 десятичных чисел от 0 до 255, разделенных точками. Примером адреса IPv4 может служить 10.5.0.5.

Адрес IPv6 представляет собой 128-битовое значение, которое записывается в форме 8 шестнадцатеричных значений от 0 до ffff, разделенных двоеточием (:). Примером адреса IPv6 может служить 2001:0:200:3:0:0:0:1. В адресах IPv6 часто встречаются смежные поля со значением 0. Группу таких полей можно обозначить последовательностью «::». Приведенный выше пример адреса можно представить в виде 2001:0:200:3::1.

Адресный префикс представляет собой блок из 2k адресов, образующих непрерывную последовательность, в которой старшие биты адресов одинаковы. Например, 512 адресов IPv4 от 10.5.0.0 до 10.5.1.255 будут иметь одинаковые значений 23 старших битов. Блок адресов указывается путем добавления символа дробной черты (/) и числа неизменных старших битов. Префикс из приведенного выше примера имеет вид 10.5.0.0/23 и содержит 2(32-23) = 29 адресов. Блок адресов IPv6 от 2001:0:200:0:0:0:0:0 до 2001:0:3ff:ffff:ffff:ffff:ffff:ffff (289 адресов) представляется в виде 2001:0:200:0:0:0:0:0/39 или 2001:0:200::/39. Префиксы можно сократить, опуская нули в младших полях, не входящих в число неизменных. Сокращенные формы приведенных выше префиксов имеют вид 10.5.0/23 и 2001:0:200/39.

Адрес или префикс IP кодируется в расширении IP Address Delegation как DER-представление ASN.1 BIT STRING, содержащие неизменные старшие биты. В соответствии с [X.690] DER-представление битовой строки состоит из типа BIT STRING (0x03), за которым следует представление числа октетов значения и само значение. Это значение состоит из «начального октета», который указывает число неиспользуемых битов с последнем октете, и «последующих октетов», содержащих саму строку (для адресов IP представление размера совпадает с размером).

Для одного адреса неизменны все биты и битовая строка для адреса IPv4 содержит 32 бита. Последующие октеты в DER-представлении адреса 10.5.0.4 будут иметь значения 0x0a 0x05 0x00 0x04. Поскольку в последнем октете используются все биты, начальный октет имеет значение 0x00. Октеты DER-представления BIT STRING показаны ниже

         Тип  Разм. Неисп. битов ...
         0x03 0x05  0x00  0x0a 0x05 0x00 0x04

DER-представление префикса 10.5.0/23 будет иметь вид

         Тип  Разм. Неисп. битов ...
         0x03 0x04  0x01  0x0a 0x05 0x00

В этом случае три последующих октета включают 24 бита, но префикс имеет размер 23, поэтому в последнем октете 1 бит не используется и начальный октет имеет значение 1 (в соответствии с DER все неиспользуемые биты должны иметь значение 0).

DER-представление адреса IPv6 2001:0:200:3:0:0:0:1 будет иметь вид

         Тип  Разм. Неисп. битов ...
         0x03 0x11  0x00  0x20 0x01 0x00 0x00 0x02 0x00 0x00 0x03
                          0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x01

DER-представление префикса 2001:0:200/39 с одним неиспользуемым битом в последнем октете будет иметь вид

         Тип  Разм. Неисп. битов ...
         0x03 0x06  0x01  0x20 0x01 0x00 0x00 0x02

2.1.2. Представление диапазонов адресов IP

Хотя любой непрерывный диапазон адресов IP можно представить набором смежных префиксов, более компактным будет представление диапазона в форме SEQUENCE (последовательность) с указанием младшего и старшего адреса в форме BIT STRING. В SEQUENCE битовая строка с младшим адресом формируется путем удаления всех младших битов со значением 0, а строка со старшим адресом путем удаления всех младших битов со значением 1. в DER-представлении BIT STRING все неиспользуемые биты последнего октета должны иметь значение 0. Отметим, что префикс всегда можно выразить в форме диапазона, но диапазон не всегда выражается одним префиксом.

Диапазон адресов префикса 10.5.0/23 будет от 10.5.0.0 до 10.5.1.255. Младший адрес содержит 16 младших битов со значением 0 и DER-представление 16-битовой строки будет иметь вид

         Тип  Разм. Неисп. битов ...
         0x03 0x03  0x00  0x0a 0x05

Старший адрес завершается 9 единицами, которые удаляются. DER-представление оставшейся 23-битовой строки имеет вид

         Тип  Разм. Неисп. битов ...
         0x03 0x04  0x01  0x0a 0x05 0x00

Префикс 2001:0:200/39 можно представить диапазоном и DER-представлением младшего адреса (2001:0:200::) будет

         Тип  Разм. Неисп. битов ...
         0x03 0x06  0x01  0x20 0x01 0x00 0x00 0x02

Старший адрес 2001:0:3ff:ffff:ffff:ffff:ffff:ffff после удаления 90 младших битов со значением 1 будет включать 38 битов с представлением

         Тип  Разм. Неисп. битов ...
         0x03 0x06  0x02  0x20 0x01 0x00 0x00 0x00

Специальный случай «всех адресов IP» (префикс 0/0) должен кодироваться в DER с октетом размера 1, начальным октетом 0 и без последующих октетов

         Тип  Разм. Неисп. битов ...
         0x03 0x01  0x00

Отметим, что для адресов IP число нулей в конце имеет значение. Например DER-представлением 10.64/12 будет

         Тип  Разм. Неисп. битов ...
         0x03 0x03  0x04  0x0a 0x40

А DER-представлением 10.64.0/20 будет

         Тип  Разм. Неисп. битов ...
         0x03 0x04  0x04  0x0a 0x40 0x00

2.2. Спецификация

2.2.1. OID

Идентификатор OID для этого расширения имеет значение id-pe-ipAddrBlocks.

      id-pe-ipAddrBlocks  OBJECT IDENTIFIER ::= { id-pe 7 }

В [RFC3280] дано определение

      id-pkix  OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
               dod(6) internet(1) security(5) mechanisms(5) pkix(7) }

      id-pe    OBJECT IDENTIFIER ::= { id-pkix 1 }

2.2.2. Критичность

Расширение следует обозначать критическим (CRITICAL). Предназначение этого расширения является обозначение права использования указанных в нем блоков адресов IP. CA помечает это расширение критическим для уведомления зависимых сторон о том, что они должны понимать семантику расширения для использования сертификата в целях, для которых он был выпущен. Предполагается, что новые приложения, использующие сертификаты с таким расширением, будут понимать его.

2.2.3. Синтаксис

   id-pe-ipAddrBlocks      OBJECT IDENTIFIER ::= { id-pe 7 }

   IPAddrBlocks        ::= SEQUENCE OF IPAddressFamily

   IPAddressFamily     ::= SEQUENCE {    -- AFI и необязательный SAFI --
      addressFamily        OCTET STRING (SIZE (2..3)),
      ipAddressChoice      IPAddressChoice }

   IPAddressChoice     ::= CHOICE {
      inherit              NULL, -- наследуется от эмитента --
      addressesOrRanges    SEQUENCE OF IPAddressOrRange }

   IPAddressOrRange    ::= CHOICE {
      addressPrefix        IPAddress,
      addressRange         IPAddressRange }

   IPAddressRange      ::= SEQUENCE {
      min                  IPAddress,
      max                  IPAddress }

   IPAddress           ::= BIT STRING
2.2.3.1. Тип IPAddrBlocks

Тип IPAddrBlocks представляет собой последовательность (SEQUENCE OF) типов IPAddressFamily.

2.2.3.2. Тип IPAddressFamily

Тип IPAddressFamily представляет собой последовательность (SEQUENCE), содержащую элементы addressFamily и ipAddressChoice.

2.2.3.3. Элемент addressFamily

Элемент addressFamily представляет собой строку октетов (OCTET STRING) содержащую 2-октетный идентификатор семейства адресов (AFI4) с сетевым порядком байтов, за которым может следовать октет идентификатора последующего семейства адресов (SAFI5). AFI и SAFI определены в [IANA-AFI] и [IANA-SAFI], соответственно.

Если не было предоставлено полномочий для конкретного AFI и дополнительного SAFI, недопустимо включать IPAddressFamily для этого AFI/SAFI в последовательность IPAddrBlocks.

Должна присутствовать только одна последовательность IPAddressFamily для уникальной комбинации AFI и SAFI. Каждая последовательность (SEQUENCE) должна быть упорядочена по возрастанию значений addressFamily (октеты считаются значениями без знака). addressFamily без SAFI должны предшествовать элементам, включающим SAFI. При указании обоих типов адресов IPv4 и IPv6 адреса IPv4 должны предшествовать адресам IPv6 (поскольку IPv4 AFI имеет значеение 0001, которое меньше IPv6 AFI — 0002).

2.2.3.4. Элемент ipAddressChoice и тип IPAddressChoice

Элемент ipAddressChoice имеет тип IPAddressChoice, который представляет собой выбор (CHOICE) одного из элементов inherit или addressesOrRanges.

2.2.3.5. Элемент inherit

Если выбор IPAddressChoice содержит элемент inherit, набор адресов IP (на которые распространяются полномочия) для указанного AFI и дополнительного SAFI берется из сертификата эмитента (или сертификата эмитента сертификата эмитента и т. д. рекурсивно, пока не будет найден сертификат, содержащий IPAddressChoice и с элементом addressesOrRanges).

2.2.3.6. Элемент addressesOrRanges

Элемент addressesOrRanges является последовательностью (SEQUENCE OF) типов IPAddressOrRange. Элементы addressPrefix и addressRange должны сортироваться с использованием двоичного представления

      <lowest IP address in range> | <prefix length>

где | означает конкатенацию. Отметим, что октеты в этом представлении (a.b.c.d | размер для IPv4 или s:t:u:v:w:x:y:z | размер IPv6) не являются октетами DER-представления битовой строки (BIT STRING). Например, для двух addressPrefix

      Адрес IP  | разм. DER-представление
      ----------------  ------------------------
                        Тип  Разм. Неисп. битов ...
      10.32.0.0 | 12     03   03    04   0a 20
      10.64.0.0 | 16     03   03    00   0a 40

префикс 10.32.0.0/12 должен быть впереди префикса 10.64.0.0/16, поскольку 32 меньше 64, тогда как при сортировке по DER-представлениям битовых строк порядок был бы обратным, за счет октета неиспользуемых битов. Любой паре вариантов IPAddressOrRange в расширении недопустимо перекрываться с другой парой. Любые непрерывные префикса или диапазоны должны объединяться в один диапазон или (если возможно) в один префикс.

2.2.3.7. Тип IPAddressOrRange

Тип IPAddressOrRange представляет собой выбор (CHOICE) одного из элементов addressPrefix (префикс или адрес IP) или addressRange (диапазон адресов IP).

В соответствии с данной спецификацией любой диапазон адресов, который может быть выражен префиксом, должен кодироваться с использованием элемента IPAddress (BIT STRING), а любой диапазон, который невозможно выразить префиксом, должен кодироваться с использованием IPAddressRange (SEQUENCE из двух BIT STRING). Приведенный ниже псевдокод иллюстрирует выбор способа кодирования диапазона адресов.

         LET  N = число совпадающих старших битов в младшем и старшем адресе диапазона
         IF   все оставшиеся биты младшего адреса имеют значения 0
          AND все оставшиеся биты старшего адреса имеют значения 1
         THEN диапазон ДОЛЖЕН кодироваться как IPAddress размером N битов
         ELSE диапазон ДОЛЖЕН кодироваться как IPAddressRange.
2.2.3.8. Элемент addressPrefix и тип IPAddress

Элемент addressPrefix имеет тип IPAddress. Этот тип определяет диапазон адресов IP, в котором N старших (слева) битов сохраняется неизменным, а оставшиеся биты (32 — N для IPv4, 128 — N для IPv6) могут принимать разные значения. Например, префикс IPv4 10.64/12 соответствует адресам с 10.64.0.0 до 10.79.255.255, а 10.64/11 — адресам с 10.64.0.0 до 10.95.255.255. Префикс IPv6 2001:0:2/48 представляет адреса 2001:0:2:: — 2001:0:2:ffff:ffff:ffff:ffff:ffff.

Адресный префикс IP представляется в форме строки битов (BIT STRING). DER-представление BIT STRING использует начальный октет строки для указания числа младших битов в младшем октете, которые не используются. В DER-представлении эти биты должны иметь значение 0.

Пример

             128.0.0.0       = 1000 0000.0000 0000.0000 0000.0000 0000
           - 143.255 255 255 = 1000 1111.1111 1111.1111 1111.1111 1111
        битовая строка для кодирования = 1000
              Тип  Разм. Неисп. битов ...
Кодирование = 0x03 0x02  0x04  0x80
2.2.3.9. Элемент addressRange и тип IPAddressRange

Элемент addressRange имеет тип IPAddressRange, который представляет собой последовательность (SEQUENCE), включающую младший (элемент min) и старший (элемент max) IP-адрес диапазона. Кажду из этох адресов представляется строкой битов (BIT STRING). Все не указанные биты младшего адреса в IPAddressRange (до размера полного адреса) считаются установленными в 0, а для старшего — в 1. Битовая строка младшего адреса образуется путем удаления всех младших битов со значением 0 из младшего адреса, BIT STRING старшего адреса образуется удалением единиц из младших битов старшего адреса.

Example:

             129.64.0.0       = 1000 0001.0100 0000.0000 0000.0000 0000
           - 143.255.255.255  = 1000 1111.1111 1111.1111 1111.1111 1111
          мин. битов. строка  = 1000 0001.01
          макс. битов. строка = 1000
   Кодирование = SEQUENCE {
               Тип  Разм. Неисп. битов ...
        min    0x03 0x03  0x06  0x81      0x40
        max    0x03 0x02  0x04  0x80
              }

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

2.3. Проверка пути сертификации расширения IP Address Delegation

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

3. Расширение AS Identifier Delegation

Это расширение показывает выделение номеров AS объекту путем привязки этих номеров к открытому ключу объекта.

3.1. Контекст

Расширение AS Identifier Delegation в настоящее время поддерживается иерархией с номинальным корнем в IANA, но реально обслуживается RIR. IANA выделяет номера AS регистраторам RIR, которые, в свою очередь, назначают номера AS организациям, являющимся конечными объектами (не распределяющими эти номера между другими организациями). Расширение AS Identifier Delegation предназначено для обеспечения возможности проверки полномочий для идентификаторов AS (т. е. прав объекта на использование данного номера AS). Соответственно, имеет смысл воспользоваться преимуществами имеющейся инфраструктуры поддержки идентификаторов AS. Как описано выше в разделе 1, это реализуется путем выпуска сертификатов, включающих описанное в этом разделе расширение. Примером использования информации из таких расширений может служить объект, применяющий расширение для проверки полномочий организации на управление AS, указанной идентификатором AS в расширении. Применение этого расширения для представления назначений идентификаторов AS не означает изменения процедур поддержки идентификаторов AS или условий, в которых следует использовать AS [RFC1930].

3.2. Спецификация

3.2.1. OID

Идентификатор OID для этого расширения имеет значение id-pe-autonomousSysIds.

      id-pe-autonomousSysIds  OBJECT IDENTIFIER ::= { id-pe 8 }

для которого [RFC3280] определяет

      id-pkix  OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
               dod(6) internet(1) security(5) mechanisms(5) pkix(7) }

      id-pe    OBJECT IDENTIFIER ::= { id-pkix 1 }

3.2.2. Критичность

Это расширение следует объявлять критичным (CRITICAL). Предполагаемое использование этого расширения состоит в обозначении права использования идентификаторов AS, указанных в нем. CA помечает это расширение как критическое (CRITICAL) для обозначения того, что зависимая сторона должна понимать семантику расширения для того, чтобы использовать сертификат по назначению. Предполагается, что новые приложения, которые используют сертификаты с таким расширением, будут его понимать.

3.2.3. Синтаксис

   id-pe-autonomousSysIds  OBJECT IDENTIFIER ::= { id-pe 8 }

   ASIdentifiers       ::= SEQUENCE {
       asnum               [0] EXPLICIT ASIdentifierChoice OPTIONAL,
       rdi                 [1] EXPLICIT ASIdentifierChoice OPTIONAL}
   ASIdentifierChoice  ::= CHOICE {
      inherit              NULL, -- наследуется от эмитента --
      asIdsOrRanges        SEQUENCE OF ASIdOrRange }

   ASIdOrRange         ::= CHOICE {
       id                  ASId,
       range               ASRange }

   ASRange             ::= SEQUENCE {
       min                 ASId,
       max                 ASId }

   ASId                ::= INTEGER
3.2.3.1. Тип ASIdentifiers

Тип ASIdentifiers представляет собой последовательность (SEQUENCE), содержащую одну или множество форм идентификаторов автономных систем — номеров AS (в элементах asnum) или идентификаторов доменов маршрутизации (в элементах rdi). Если ASIdentifiers модержит множество форм идентификаторов, элемент asnum должен предшествовать элементу rdi. Номера AS используются BGP, а идентификаторы доменов маршрутизации заданы в IDRP [RFC1142]7.

3.2.3.2. Элементы asnum, rdi и тип ASIdentifierChoice

Элементы asnum и rdi имеют тип ASIdentifierChoice, который представляет собой выбор (CHOICE) из элементов inherit и asIdsOrRanges.

3.2.3.3. Элемент inherit

Если выбор ASIdentifierChoice содержит элемент inherit, множество полномочных идентификаторов AS берется из сертификата эмитента или эмитента сертификата эмитента (рекурсивно, пока не будет найден сертификат с ASIdentifierChoice, содержащим элемент asIdsOrRanges). Если для конкретной формы идентификатора AS не было предоставлено полномочий, недопустимо присутствие соответствующего элемента asnum/rdi в последовательности ASIdentifiers.

3.2.3.4. Элемент asIdsOrRanges

Элемент asIdsOrRanges представляет собой последовательность (SEQUENCE) типов ASIdOrRange. Недопустимо перекрытие любой пары элементов в последовательности asIdsOrRanges. Все непрерывные последовательности идентификаторов AS должны по возможности объединяться в один диапазон. Идентификаторы AS в элементе asIdsOrRanges должны сортироваться в порядке роста числовых значений.

3.2.3.5. Тип ASIdOrRange

Тип ASIdOrRange представляет собой выбор (CHOICE) из одиночного целого числа (ASId) или одиночной последовательности (ASRange).

3.2.3.6. Элемент id

Элемент id имеет тип ASId.

3.2.3.7. Элемент range

Элемент range имеет тип ASRange.

3.2.3.8. Тип ASRange

Тип ASRange представляет собой последовательность (SEQUENCE), содержащую элементы min и max, которые служат для указания диапазона значений идентификаторов AS.

3.2.3.9. Элементы min и max

Элементы min и max относятся к типу ASId. Элемент min служит для задания минимального идентификатора AS в диапазоне, а элемент max — для задания максимального идентификатора AS.

3.2.3.10. Тип ASId

ASId имеет тип INTEGER (целое число).

3.3. Проверка пути сертификации расширения AS Identifier Delegation

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

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

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

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

Эти расширения предоставляют информацию о полномочиях, т. е. праве использовать адреса IP или идентификаторы AS. Расширения разработаны для поддержки защищенной версии протокола BGP [S-BGP], но могут применяться и в другом контексте. В среде защищенного BGP сертификаты с такими расширениями служат возможностями (capability) — сертификат подтверждает, что владелец секретного ключа (Subject) уполномочен использовать адреса IP или идентификаторы AS, представленные в расширениях. По этой причине поле Subject значительно меньше относится к защите, нежели в обычных инфраструктурах PKI.

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

Авторы признательны Charles Gardiner, Russ Housley, James Manger и Jim Schaad за их вклад в подготовку документа.

Приложение A. Модуль ASN.1

Это нормативное приложение описывает расширения, используемые соответствующими спецификации компонентами PKI в синтаксисе ASN.1.

   IPAddrAndASCertExtn { iso(1) identified-organization(3) dod(6)
            internet(1) security(5) mechanisms(5) pkix(7) mod(0)
            id-mod-ip-addr-and-as-ident(30) }
       DEFINITIONS EXPLICIT TAGS ::=
   BEGIN
        -- Copyright (C) The Internet Society (2004). Эта        --
        -- версия данного модуля ASN.1 является частью RFC 3779. --
        -- Авторские права полностью указаны в этом документе.   --
   -- EXPORTS ALL --

   IMPORTS
   -- специфические для PKIX значения OID и arc --
       id-pe FROM PKIX1Explicit88 { iso(1) identified-organization(3)
                  dod(6) internet(1) security(5) mechanisms(5) pkix(7)
                  id-mod(0) id-pkix1-explicit(18) };

   -- OID расширения IP Address Delegation --
   id-pe-ipAddrBlocks  OBJECT IDENTIFIER ::= { id-pe 7 }

   -- Синтаксис расширения IP Address Delegation --
   IPAddrBlocks        ::= SEQUENCE OF IPAddressFamily

   IPAddressFamily     ::= SEQUENCE { -- AFI и необязательный SAFI --
      addressFamily        OCTET STRING (SIZE (2..3)),
      ipAddressChoice      IPAddressChoice }

   IPAddressChoice     ::= CHOICE {
      inherit              NULL, -- наследуется от эмитента --
      addressesOrRanges    SEQUENCE OF IPAddressOrRange }

   IPAddressOrRange    ::= CHOICE {
      addressPrefix        IPAddress,
      addressRange         IPAddressRange }

   IPAddressRange      ::= SEQUENCE {
      min                  IPAddress,
      max                  IPAddress }

   IPAddress           ::= BIT STRING

   -- OID расширения ASystem Identifier Delegation --
   id-pe-autonomousSysIds  OBJECT IDENTIFIER ::= { id-pe 8 }

   -- Синтаксис расширения ASystem Identifier Delegation --
   ASIdentifiers       ::= SEQUENCE {
       asnum               [0] ASIdentifierChoice OPTIONAL,
       rdi                 [1] ASIdentifierChoice OPTIONAL }

   ASIdentifierChoice  ::= CHOICE {
      inherit              NULL, -- наследуется от эмитента --
      asIdsOrRanges        SEQUENCE OF ASIdOrRange }

   ASIdOrRange         ::= CHOICE {
       id                  ASId,
       range               ASRange }

   ASRange             ::= SEQUENCE {
       min                 ASId,
       max                 ASId }

   ASId                ::= INTEGER
   END

Приложение B. Примеры расширения IP Address Delegation

Критическое расширение сертификата X.509 v3, которое задает перечисленные ниже адреса.

   Префиксы индивидуальных адресов IPv4
       1) 10.0.32/20     т. е.  10.0.32.0 - 10.0.47.255
       2) 10.0.64/24     т. е.  10.0.64.0 - 10.0.64.255
       3) 10.1/16        т. е.  10.1.0.0  - 10.1.255.255
       4) 10.2.48/20     т. е.  10.2.48.0 - 10.2.63.255
       5) 10.2.64/24     т. е.  10.2.64.0 - 10.2.64.255
       6) 10.3/16        т. е.  10.3.0.0  - 10.3.255.255, and
       7) наследуются все адреса IPv6 от эмитента сертификата

Будет иметь шестнадцатеричное представление

   30 46                       Extension {
      06 08 2b06010505070107     extnID        1.3.6.1.5.5.7.1.7
      01 01 ff                   critical
      04 37                      extnValue {
         30 35                     IPAddrBlocks {
            30 2b                    IPAddressFamily {
               04 03 0001  01          addressFamily: IPv4 Unicast
                                       IPAddressChoice
               30 24                     addressesOrRanges {
                                           IPAddressOrRange
                  03 04 04 0a0020            addressPrefix 10.0.32/20
                                           IPAddressOrRange
                  03 04 00 0a0040            addressPrefix 10.0.64/24
                                           IPAddressOrRange
                  03 03 00 0a01              addressPrefix    10.1/16
                                           IPAddressOrRange
                  30 0c                      addressRange {
                     03 04 04 0a0230           min        10.2.48.0
                     03 04 00 0a0240           max        10.2.64.255
                                             } -- addressRange
                                           IPAddressOrRange
                  03 03 00 0a03              addressPrefix    10.3/16
                                         } -- addressesOrRanges
                                     } -- IPAddressFamily
            30 06                    IPAddressFamily {
               04 02 0002              addressFamily: IPv6
                                       IPAddressChoice
               05 00                     наследуется от эмитента
                                     } -- IPAddressFamily
                                   } -- IPAddrBlocks
                                 } -- extnValue
                               } -- расширение

Этот пример показывает сортировку префиксов и диапазонов.

  • Префикс 1 должен предшествовать префиксу 2, хотя число неиспользуемых битов (4) в префиксе 1 больше числа неиспользуемых битов (0) в префиксе 2.

  • Префикс 2 должен предшествовать префиксу 3, хотя число октетов (4) в представлении BIT STRING для префикса 2 больше числа октетов (3) в BIT STRING префикса 3.

  • Префиксы 4 и 5 являются смежными (представляют диапазон адресов 10.2.48.0 — 10.2.64.255), поэтому они должны объединяться в диапазон (поскольку одним префиксом выразить из невозможно).

  • Отметим, что 6 нулей в конце элемента max значимы для интерпретации значения (поскольку все неиспользуемые биты интерпретируются 1, а не 0). Четыре нуля в конце элемента min не являются значимыми и должны быть удалены (это дает 4 неиспользуемых бита в представлении элемента min). DER-представление требует устанавливать значение 0 для всех неиспользуемых битов в последнем из последующих октетов.

  • Диапазон, формируемый префиксами 4 и 5, должен предшествовать префиксу 6, хотя тег SEQUENCE для представления диапазона (30) больше тега BIT STRING (03) для представления префикса 6.

  • Данные IPv4 должны предшествовать информации IPv6, поскольку идентификатор семейства адресов для IPv4 (0001) меньше идентификатора для IPv6 (0002).

Ниже показано расширение, задающее префикс IPv6 2001:0:2/48 и префиксы IPv4 10/8 и 172.16/12, а также наследование всех групповых адресов IPv4 из сертификата эмитента (в шестнадцатеричной форме).

   30 3d                       Extension {
      06 08 2b06010505070107     extnID        1.3.6.1.5.5.7.1.7
      01 01 ff                   critical
      04 2e                      extnValue {
         30 2c                     IPAddrBlocks {
            30 10                    IPAddressFamily {
               04 03 0001 01           addressFamily: IPv4 Unicast
                                       IPAddressChoice
               30 09                     addressesOrRanges {
                                           IPAddressOrRange
                  03 02 00 0a                addressPrefix    10/8
                                           IPAddressOrRange
                  03 03 04 b010              addressPrefix    172.16/12
                                         } -- addressesOrRanges
                                     } -- IPAddressFamily
            30 07                    IPAddressFamily {
               04 03 0001 02           addressFamily: IPv4 Multicast
                                       IPAddressChoice
               05 00                     наследуется от эмитента
                                     } -- IPAddressFamily
            30 0f                    IPAddressFamily {
               04 02 0002              addressFamily: IPv6
                                       IPAddressChoice
               30 09                     addressesOrRanges {
                                           IPAddressOrRange
                  03 07 00 200100000002      addressPrefix   2001:0:2/47
                                         } -- addressesOrRanges
                                     } -- IPAddressFamily
                                   } -- IPAddrBlocks
                                 } -- extnValue
                                  } -- расширение

Приложение C. Пример расширения AS Identifier Delegation

Ниже приведено расширение, задающее номера AS 135, 3000 — 3999 и 5001, а также наследующее все идентификаторы rdi из сертификата эмитента (в шестнадцатеричной форме).

   30 2b                       Extension {
      06 08 2b06010505070108     extnID        1.3.6.1.5.5.7.1.8
      01 01 ff                   critical
      04 1c                      extnValue {
         30 1a                     ASIdentifiers {
            a0 14                    asnum
                                       ASIdentifierChoice
               30 12                     asIdsOrRanges {
                                           ASIdOrRange
                  02 02 0087                 ASId
                                           ASIdOrRange
                  30 08                      ASRange {
                     02 02 0bb8                min
                     02 02 0f9f                max
                                             } -- ASRange
                                           ASIdOrRange
                  02 02 1389                 ASId
                                         } -- asIdsOrRanges
                                     } -- asnum
            a1 02                    rdi {
                                       ASIdentifierChoice
               05 00                     наследуется от эмитента
                                     } -- rdi
                                   } -- ASIdentifiers
                                 } -- extnValue
                               } -- расширение

Приложение D. Использование сертификатов атрибутов X.509

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

Ресурсы идентификаторов AS и адресных блоков IP в настоящее время поддерживаются раздельно. Все организации, имеющие право использовать идентификаторы AS, получают эти полномочия напрямую от RIR. Организации, имеющие право использовать блоки адресов IP, получают свои полномочия напрямую от RIR или опосредованно через сервис-провайдеров, которые могут получить свои полномочия от ISP, а те, в свою очередь, от RIR. Отметим, что в будущем для идентификаторов AS также может возникнуть многоуровневое распределение, поэтому механизм не следует строить на базе лишь трех уровней.

В разделе 1 RFC 3281 приведены две причины, по которым использование AC может быть предпочтительней применения сертификатов открытых ключей (PKC9) в расширениях, передающих информацию о полномочиях.

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

«По этим причинам зачастую лучше отделить информацию о полномочиях от PKC. Эта информация все равно должна быть привязана к объекту и AC обеспечивает такую привязку — это просто цифровая подпись (или сертификат) для объекта и набор атрибутов.»

В случае адресов IP и идентификаторов AS приведенные выше соображения не применимы. Во-первых, сертификаты открытых ключей выпускаются исключительно в целях предоставления полномочий, поэтому срок их действия в точности совпадает со сроком действия полномочий, который часто привязан к контрактным отношениям между эмитентом и организацией, получившей полномочия. Имена субъекта (Subject) и эмитента (Issuer) нужны лишь для создания цепочек при проверке путей сертификации, поэтому не требуется какого-либо соответствия имен физическим объектам. Значение Subject в PKC может быть произвольно выбранным выпускающим сертификат CA, что позволяет частично скрыть владельца ресурса. Во-вторых, иерархия сертификатов организована так, что эмитент сертификата обладает информацией о полномочиях.

Таким образом, два пункта из первой цитаты не являются корректными для случая распределения номеров AS и адресных блоков IP. Указанное во второй цитате также не применимо, поскольку ресурсы привязываются не к объекту, а к владельцу секретного ключа, соответствующего открытому ключу в PKC.

В RFC 3281 указано несколько требований, которым должны соответствовать сертификаты атрибутов (AC). Применительно к S-BGP наиболее важные требования перечислены ниже.

  1. Раздел 1: «данная спецификация не рекомендует использовать цепочки AC. Другие (будущие) спецификации могут включать вопросы использования цепочек AC.»

    Распределение ресурсов от IANA через RIR, ISP, DSP и присвоение конечным пользователям (организациям) требует использования цепочек по крайней мере для адресных блоков IP. Требуется описание расположения вышестоящего AC и способа обработки. Читатели могут подумать сами о способах избавления от цепочек.

  2. Параграф 4.2.9: «в параграфе 4.3 определены расширения, которые могут использоваться с этим профилем, и критерии указания уровня критичности таких расширений. При использовании любых других критических расширений AC не будет соответствовать профилю. Однако использование других некритических расширений не нарушает соответствия AC данному профилю.»

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

  3. Параграф 4.5: «эмитенту AC недопустимо быть также эмитентом PKC. Т. е. эмитент AC не может быть CA.»

    Это означает, что каждому эмитенту AC потребуется отдельный CA для выпуска PKC с открытым ключом держателя AC. Эмитент AC не может выпустить PKC для держателя, а эмитент PKC не может подписывать AC. Таким образом, каждому объекту в PKI потребуется поддерживать эмитента AC в дополнение к CA. Это будет удваивать число эмитентов при использовании сертификатов атрибутов по сравнению с числом эмитентов сертификатов и CRL при использовании PKC. При выдаче сертификатов разными органами возрастает также вероятность несогласованности.

    Модель AC из RFC 3281 предполагает, что держатель AC представляет AC проверяющей стороне, когда та желает получить обоснование атрибута или полномочий. Предполагаемое использование определенных здесь расширений не включает прямого взаимодействия между проверяющей AC стороной (NOC10) и эмитентами AC (все RIR и NOC). На основе подписи в заявляющем право использования объекте «проверяющая AC сторона» может получить PKC держателя AC, но нет прямого пути для определения субъектов AC.

  4. Параграф 5: «4. Эмитент AC должен быть непосредственно доверенным издателем AC (по конфигурации или иным способом).»

    Это не справедливо для случая прав на использование адресных блоков IP, которые выделяются через иерархию. Проверка пути сертификации AC будет требовать организации цепочек через иерархию передачи полномочий (делегирования). Организация для каждой зависимой от инфраструктуры стороны (NOC) «доверия» к каждому другому NOC не обеспечивает масштабируемости и такое «доверие» приведет в результате к отказам, которые предлагаемые механизмы должны были предотвращать. В предлагаемой здесь модели используется одна PKI с доверенным корнем, а не тысячи отдельных доверительных отношений между ISP, выпускающими AC.

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

Литература

Нормативные документы

[IANA-AFI] http://www.iana.org/assignments/address-family-numbers.

[IANA-SAFI] http://www.iana.org/assignments/safi-namespace.

[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Level», BCP 14, RFC 2119, March 1997.

[RFC3280] Housley, R., Polk, W., Ford, W. and D. Solo, «Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile», RFC 3280, April 2002.

[X.690] ITU-T Recommendation X.690 (1997) | ISO/IEC 8825-1:1998, «Information Technology — ASN.1 Encoding Rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)».

Дополнительная литература

[RFC791] Postel, J., «Internet Protocol — DARPA Internet Program Protocol Specification», RFC 791, September 1981.

[RFC1142] D. Oran, Ed., «OSI IS-IS Intra-domain Routing Protocol», RFC 1142, February 1990.

[RFC1771] Rekhter, Y. and T. Li, Eds., «A Border Gateway Protocol 4 (BGP-4)», RFC 1771, March 1995.

[RFC1930] Hawkinson, J. and T. Bates, «Guidelines for creation, selection, and registration of an Autonomous System (AS)», BCP 6, RFC 1930, March 1996.

[RFC2050] Hubbard, K., Kosters, M., Conrad, D., Karrenberg, D. And J. Postel, «Internet Registry IP Allocation Guidelines», BCP 12, RFC 2050, November 1996.

[RFC3513] Hinden, R. and S. Deering, «Internet Protocol Version 6 (IPv6) Addressing Architecture», RFC 3513, April 2003.

[RFC3281] Farrell, S. and R. Housley, «An Internet Attribute Certificate Profile for Authorization», RFC 3281, April 2002.

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

[S-BGP] S. Kent, C. Lynn, and K. Seo, «Secure Border Gateway Protocol (S-BGP),» IEEE JSAC Special Issue on Network Security, April 2000.

Адреса авторов

Charles Lynn

BBN Technologies

10 Moulton St.

Cambridge, MA 02138

USA

Phone: +1 (617) 873-3367

EMail: CLynn@BBN.Com

Stephen Kent

BBN Technologies

10 Moulton St.

Cambridge, MA 02138

USA

Phone: +1 (617) 873-3988

EMail: Kent@BBN.Com

Karen Seo

BBN Technologies

10 Moulton St.

Cambridge, MA 02138

USA

Phone: +1 (617) 873-3152

EMail: KSeo@BBN.Com


Перевод на русский язык

Николай Малых

nmalykh@gmail.com

Полное заявление авторских прав

Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an «AS IS» basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Интеллектуальная собственность

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

Подтверждение

Финансирование функций RFC Editor обеспечено Internet Society.


1Regional Internet registry.

2Internet service provider.

3Autonomous system.

4Address Family Identifier.

5Subsequent Address Family Identifier

6Этот абзац предложено исключить из спецификации. См. https://www.rfc-editor.org/errata/eid2537. Прим. перев.

7RFC 1142 не содержит спецификации IDRP, она задана в ISO 10747. См. https://www.rfc-editor.org/errata/eid836. Прим. перев.

8Regional Internet Registry.

9Public key certificate.

10Network operations center. Прим. перев.

11В оригинале эта ссылка отсутствует (документа еще не было). См. https://www.rfc-editor.org/errata/eid1887. Прим. перев.