AAA

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

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

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

Тезисы

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

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

Оглавление

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. Спецификация требований

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

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 размера 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).

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

Недостатки:

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

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

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

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

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

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

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

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

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

+-+-+-+-+-+-+-+-+-+-+-+-+  +-+-+-+-+-+-+-+-+-+-+-+-+
|           |           |  |           |           |
| 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

В 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. Проходной режим

При работе в проходном режиме идентифицирующая сторона проверяет поля 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 любого типа.

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

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

     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: Идентифицирующая сторона в проходном режиме

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

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

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

Хотя EAP поддерживает взаимную идентификацию сторон, некоторые реализации 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 только точки доступа (AP) передают групповой и широковещательный трафик. В специальном режиме 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.

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

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

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

  4. Минимальное значение 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, что приведет к использованию фрагментации и сборки на нижележащем уровне.

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

  6. Гарантии порядка доставки. 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.

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

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

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

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

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

Exactly one EAP packet is encapsulated in the Information field of a PPP Data Link Layer frame where the protocol field indicates type hex C227 (PPP 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   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

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

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             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

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

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

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

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

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

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

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

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

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

1Identity
2Notification
3Nak (только в Response)
4MD5-Challenge
5Однократный пароль (OTP)
6Базовая карточка доступа (GTC)
254Расширенные типы
255Для экспериментов

Методы 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.

Параметры защиты (см. параграф 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, неудачной sequence integer which is nearing 0, an authentication failure warning, etc. In most circumstances, Notification should not be required.

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

Механизм идентификацииНет
Согласование криптографического набораНет
Взаимная идентификацияНет
Защита целостностиНет
Защита от повторовНет
КонфиденциальностьНет
Создание ключейНет
Стойкость ключей-
Устойчивость к атакам по словарю-
Быстрый повтор соединенияНет
Криптографическая привязка-
Независимость сессий-
ФрагментацияНет
Связывание каналовНет

5.3. Nak

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

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

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

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

Механизм идентификацииНет
Согласование криптографического набораНет
Взаимная идентификацияНет
Защита целостностиНет
Защита от повторовНет
КонфиденциальностьНет
Создание ключейНет
Стойкость ключей-
Устойчивость к атакам по словарю-
Быстрый повтор соединенияНет
Криптографическая привязка-
Независимость сессий-
ФрагментацияНет
Связывание каналовНет

5.3.2. Expanded Nak

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

Параметры защиты (см. параграф 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 в CHAP).

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

 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)

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

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

Механизм идентификацииОдноразовый пароль
Согласование криптографического набораНет
Взаимная идентификацияНет
Защита целостностиНет
Защита от повторовДа
КонфиденциальностьНет
Создание ключейНет
Стойкость ключей-
Устойчивость к атакам по словарюНет
Быстрый повтор соединенияНет
Криптографическая привязка-
Независимость сессий-
ФрагментацияНет
Связывание каналовНет

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

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

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

Механизм идентификацииАппаратный маркер
Согласование криптографического набораНет
Взаимная идентификацияНет
Защита целостностиНет
Защита от повторовНет
КонфиденциальностьНет
Создание ключейНет
Стойкость ключей-
Устойчивость к атакам по словарюНет
Быстрый повтор соединенияНет
Криптографическая привязка-
Независимость сессий-
ФрагментацияНет
Связывание каналовНет

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

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

Expanded Type также используется для расширения глобального пространства типов методов за пределы исходных 255 значений. Значение Vendor-Id = 0 отображает исходные 255 возможных типов в пространство из 2^32-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...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5.8. Experimental

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

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

В этом разделе приведено руководство для IANA в части регистрации значений, связанных с протоколом 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» IETF» IETF» IETF» IETF» (IETF Consensus), «стардартизация» (Standards Action).

Для регистрационных запросов, где следует консультироваться с указанными экспертами, ответственность за выбор таких экспертов ложится на руководителя направления IESG. Смысл заключается в том, что любое выделение значений должно сопровождаться публикацией RFC. Но для выделения значений до публикации RFC может использоваться заключение указанного эксперта, который может одобрить выделение значений, когда станет ясно, что RFC будет публиковаться. Эксперт будет направлять запрос в рассылку рабочей группы EAP (или ее преемника, заданного руководителем направления) для обзора и комментариев, включая Internet-Draft. До истечения 30 дней эксперту следует принять или отвергнуть регистрационный запрос и опубликовать свое решение в рассылке EAP WG или ее преемника, а также проинформировать 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 (Параметры защиты), содержащий перечисленные ниже описания.

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

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

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

7.3. Защита Identity

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

Однако при поддержке роуминга в соответствии с [RFC2607] может потребоваться нахождение подходящего внутреннего сервера идентификации до выполнения идентификационной транзакции. Связанная с областью часть NAI [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-атаку, получая доступ в сеть, а также возможность расшифровывать трафик между легитимным партнером и сервером.

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

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

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

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, который впоследствии используется для создания временных сеансовых ключей (TSK) используемых с выбранным криптографическим набором. Каждый криптонабор отвечает за спецификацию создания ключей 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 могут взломаны методом тупого перебора. Для поддержки систем, требующих стойких ключей, поддерживающим генерацию ключей методам EAP следует обеспечивать возможность генерации ключей MSK и EMSK с эффективной стойкостью не менее 128 битов.

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

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

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

Поскольку 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:

В 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 модулю криптонабора.

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

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. Нормативные документы

  1. [RFC1661]Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
  2. [RFC1994]Simpson, W., "PPP Challenge Handshake Authentication Protocol (CHAP)", RFC 1994, August 1996.
  3. [RFC2119]Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  4. [RFC2243] Metz, C., "OTP Extended Responses", RFC 2243, November 1997.
  5. [RFC2279]Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998.
  6. [RFC2289]Haller, N., Metz, C., Nesser, P. and M. Straw, "A One-Time Password System", RFC 2289, February 1998.
  7. [RFC2434]Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
  8. [RFC2988]Paxson, V. and M. Allman, "Computing TCP's Retransmission Timer", RFC 2988, November 2000.
  9. [IEEE-802]Institute of Electrical and Electronics Engineers, "Local and Metropolitan Area Networks: Overview and Architecture", IEEE Standard 8022, 1990.
  10. [IEEE-802.1X]Institute of Electrical and Electronics Engineers, "Local and Metropolitan Area Networks: Port-Based Network Access Control", IEEE Standard 802.1X, September 2001.

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

  1. [RFC793]Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
  2. [RFC1510] Kohl, J. and B. Neuman, "The Kerberos Network Authentication Service (V5)", RFC 1510, September 1993.
  3. [RFC1750]Eastlake, D., Crocker, S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994.
  4. [RFC2246] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January 1999
  5. [RFC2284] Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication Protocol (EAP)", RFC 2284, March 1998.
  6. [RFC2486] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC 2486, January 1999.
  7. [RFC2408] Maughan, D., Schneider, M. and M. Schertler, "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, November 1998.
  8. [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
  9. [RFC2433] Zorn, G. and S. Cobb, "Microsoft PPP CHAP Extensions", RFC 2433, October 1998.
  10. [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy Implementation in Roaming", RFC 2607, June 1999.
  11. [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G. and B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661, August 1999.
  12. [RFC2716] Aboba, B. and D. Simon, "PPP EAP TLS Authentication Protocol", RFC 2716, October 1999.
  13. [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
  14. [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 2960, October 2000.
  15. [RFC3162] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6", RFC 3162, August 2001.
  16. [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings ("stringprep")", RFC 3454, December 2002.
  17. [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003.
  18. [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.
  19. [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers Considered Useful", BCP 82, RFC 3692, January 2004.
  20. [DECEPTION] Slatalla, M. and J. Quittner, "Masters of Deception", Harper-Collins, New York, 1995.
  21. [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.
  22. [KRBLIM] Bellovin, S. and M. Merrit, "Limitations of the Kerberos authentication system", Proceedings of the 1991 Winter USENIX Conference, pp. 253-267, 1991.
  23. [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.
  24. [PIC] Aboba, B., Krawczyk, H. and Y. Sheffer, "PIC, A Pre-IKE Credential Provisioning Protocol", Work in Progress, October 2002.
  25. [IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", January 2004.
  26. [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.
  27. [IEEE-802.11] Institute of Electrical and Electronics Engineers, "Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications", IEEE Standard 802.11, 1999.
  28. [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.
  29. [KEYFRAME] Aboba, B., "EAP Key Management Framework", October 2003.
  30. [SASLPREP] Zeilenga, K., "SASLprep: Stringprep profile for user names and passwords", March 2004.
  31. [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, 2003.
  32. [DIAM-EAP] Eronen, P., Hiller, T. and G. Zorn, "Diameter Extensible Authentication Protocol (EAP) Application", Work in Progress6, February 2004.
  33. [EAP-EVAL] Zorn, G., "Specifying Security Claims for EAP Authentication Types", Work in Progress, October 2002.
  34. [BINDING] Puthenkulam, J., "The Compound Authentication Binding Problem", Work in Progress, October 2003.
  35. [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.
  36. [IEEE-802.11i-req] Stanley, D., "EAP Method Requirements for Wireless LANs", February 2004.
  37. [PPTPv2] Schneier, B. and Mudge, "Cryptanalysis of Microsoft's PPTP Authentication Extensions (MS-CHAPv2)", CQRE 99, Springer-Verlag, 1999, pp. 192-203.

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

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

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

Bernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052 USA
Phone: +1 425 706 6605
Fax: +1 425 936 6605
EMail: moc.tfosorcim@adranreb

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: ude.tirem@bjl

John R. Vollbrecht
Vollbrecht Consulting LLC
9682 Alice Hill Drive
Dexter, MI 48130 USA
EMail: ude.hcimu@vrj

James Carlson
Sun Microsystems, Inc
1 Network Drive
Burlington, MA 01803-2757 USA
Phone: +1 781 442 2084
Fax: +1 781 442 1677
EMail: moc.nus@noslrac.d.semaj

Henrik Levkowetz
ipUnplugged AB
Arenavagen 33
Stockholm S-121 28 SWEDEN
Phone: +46 708 32 16 08
EMail: moc.ztewokvel@kirneh

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

Николай Малых, moc.milib@hkylamn