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