RFC: 4422
Оригинал: Simple Authentication and Security Layer (SASL)
Предыдущие версии: RFC 2222
Категория: Предложенный стандарт
Дата публикации:
Авторы: ,
Перевод: Николай Малых

6.1. Активные атаки

6.1.1. Перехват

Когда клиент выбирает уровень защиты SASL, обеспечивающий по крайней мере защиту целостности, такая защита работает как средство против активных атак с перехватом соединений и модификацией данных протокола, передаваемых после организации защитного уровня. Реализациям следует разрывать соединение, когда службы уровня защиты SASL сообщают о потере целостности данных.

6.1.2. Атаки, направленные на снижение уровня защиты

Важно, чтобы все чувствительные к защите согласования протокола выполнялись после организации уровня защиты с обеспечением целостности данных. Протоколы следует разрабатывать так, чтобы согласование, выполненное до установки защитного уровня, можно было проверить после организации этого уровня. Согласование механизмов SASL относится к числу таких согласований.

Когда клиент согласует с сервером механизм аутентификации и/или другие функции защиты, активный атакующий может вынудить к выбору наименее защищенного варианта сервиса из числа возможных. Например, атакующий может подменить список анонсируемых сервером механизмов или список поддерживаемых клиентом функций в отклике с выбором механизма. Для защиты от этого типа атак реализациям не следует анонсировать механизмы и/или функции, которые не соответствуют минимальным требованиям безопасности, а также не следует начинать или продолжать аутентификационный обмен, который не удовлетворяет минимальным требованиям безопасности. Кроме того, следует проверять, что результат аутентификационного обмена в части защиты соответствует требованиям безопасности.

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

Для детектирования атак, направленных на снижение уровня защиты до минимального из числа поддерживаемых (или ниже), клиент может определить поддерживаемые сервером механизмы SASL до аутентификационного обмена и после установки согласованного уровня защиты SASL (обеспечивающего по крайней мере целостность данных) с помощью механизма определения возможностей, предоставляемого протоколом. Если клиент видит, что полученный с обеспечением целостности список (полученный после создания защитного уровня), предлагает более сильный механизм, нежели содержатся в полученном ранее списке, клиенту разумно предположить, что первый список был изменен атакующим и следует закрыть нижележащее соединение транспортного уровня.

Инициированный клиентом обмен SASL, включающий выбор механизма SASL, происходит в открытой форме и может быть изменен активным атакующим. При разработке новых механизмов SASL важно обеспечить предотвращение вынужденного атакующим выбора наименее надежного варианта защиты путем простого изменения имени механизма SASL и/или запросов и откликов.

Многоуровневое согласование функций защиты более открыто для атак, направленных на снижение уровня. Разработчикам протоколов следует избегать в протоколах предложения использовать согласование функций защиты на верхних уровнях (например, «поверх» согласования механизма SASL), а разработчикам механизмов следует избегать низкоуровневого согласования защитных функций в своих механизмах (например, ниже согласования механизма SASL).

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