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

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

7.4. MITM-атаки

При туннелировании EAP с использованием протокола, опускающего идентификацию партнера, возникает потенциальная уязвимость к MITM-атакам, более подробно описанная в работах [BINDING] и [MITM].

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

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

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

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

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

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