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

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

7.12. Канальный уровень

Существует ряд вопросов надежности и безопасности индикации нижележащего уровня в PPP, ЛВС IEEE 802 и беспроводных ЛВС IEEE 802.11:

  • PPP. Индикация канального уровня типа LCP-Terminate (индикация отказа в канале) и NCP (индикация успешного создания канала) не идентифицируются и не защищаются в плане целостности. Следовательно, атакующий с доступом к каналу может использовать обманную индикацию.
  • IEEE 802. Кадры IEEE 802.1X EAPOL-Start и EAPOL-Logoff не идентифицируются и целостность их не защищена. Следовательно, атакующий с доступом к каналу может использовать обманную индикацию.
  • IEEE 802.11. В IEEE 802.11 индикация канального уровня включает кадры Disassociate и Deauthenticate frames (индикация отказов в канале), а также первое сообщение 4-этапного согласования (успешная организация канала). Для этих сообщений не обеспечивается идентификация и защита целостности и, хотя они не являются пересылаемыми, атакующий может использовать обманную индикацию, находясь в зоне доступа.

В IEEE 802.11 кадры данных IEEE 802.1X могут передаваться, как кадры класса 3 с индивидуальной адресацией, и, следовательно, такие кадры можно пересылать. Это ведет к тому, что кадры EAPOL-Start и EAPOL-Logoff могут быть подменены идентифицированным атакующим при включенном режиме предварительной идентификации, несмотря на использование идентификации и защиты целостности.

В IEEE 802.11 индикация «падения канала» является ненадежной индикацией наличия проблем в канале, поскольку уровень сигнала может меняться сам по себе и может находится под влиянием интерференции радиоволн, создаваемой атакующим. Для предотвращения ненужных сбросов разумно подавлять такую индикацию вместо ее передачи непосредственно в EAP. Поскольку EAP поддерживает повторную передачу пакетов, этого достаточно для устойчивости к временной потере связи.

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

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