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

RFC 3748, Страница 6 из 46

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-атак.

Страница 6 из 46

2007 - 2022 © Русские переводы RFC, IETF, ISOC.