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) сторона могут повторить идентификацию в любой момент. Рекомендуется не сбрасывать значения счетчиков неудачных попыток, пока идентификация не завершится успешно или в результате разрыва канала.