RFC: 3748
Оригинал: Extensible Authentication Protocol (EAP)
Предыдущие версии: RFC 2284
Категория: Предложенный стандарт
Дата публикации:
Авторы: , , , ,
Перевод: Николай Малых

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

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

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

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

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

Недостатки:

  • При использовании с PPP протокол EAP требует добавления нового типа идентификации в PPP LCP, что ведет к необходимости обновления реалиаций протокола PPP. Это также является отклонением от предыдущей модели идентификации в PPP с согласованием конкретного механизма идентификации в процессе LCP. Аналогично, реализациям коммутаторов и точек доступа требуется поддержка [IEEE-802.1X] для использования EAP.
  • Когда идентифицирующая сторона отделена от внутреннего сервера идентификации, усложняется анализ защиты и распространение ключей (если оно требуется).
2007 - 2017 © Русские переводы RFC, IETF, ISOC.